【サルが書く】クネビンフレームワークを使って、関わっているプロダクトはスクラム開発が有用なのか判断する
わっきょい！
スクラム開発は導入自体そこまで難しくないですが、ほんとに導入して効果があるのかって疑問に思うときがあると思います。
特に業務に導入するときは、効果があるから導入しますと、周りを納得させる必要も出てくると思います。
そんなときにクネビンフレームワークを使って、プロダクトにスクラム開発を導入したときに効果的なのかということを判断したいと思います。
スクラム開発のメリット
スクラム開発のメリットとして、複雑な領域における検査と適応を行うことができる、という点があります。
ですが、かならずしもソフトウェア開発は複雑な領域に当てはまると安易に判断するのは危ないです。
クネビンフレームワークとは
クネビン（カネヴィン）フレームワーク Cynefin Frameworkとは、VUCAの世界において、実際の世界をどのようにとらえて、どのように考えて行動したらいいかを体系づけたものです。
デイビッド J. スノウドン David J. Snowden とメアリー E. ブーンMary E. Booneにより提言されました。
引用： https://iandco.jp/ooda/cynefin/
物事を領域に分けて、どのような行動をすればいいか体系づけたものです。
スクラムが効果的な領域
・複雑な領域
物事は予測できないことのほうが多い、後で振り返ることでわかる。
創発的な領域である
検査と適応を行う
安全に失敗できるような環境を作り、重要な情報を見つ出せるようにする必要がある。
このような環境では密なコミュニケーションが欠かせない
革新的な新規開発はこの状態に当てはまり、既存プロダクトに革新的な機能を追加するときも同様である
スクラムはこのように革新的なものを作るときに、検査を行い、適応させることでうまく当てはまる
無秩序かつ持続性のあるもの
スクラムが効果的でない領域
・込み入った領域
専門家が活躍する適切なプラクティス
正解を導き出すために専門家が必要な場合は有用
例えば保守作業のように、パフォーマンスを最適化する場合
シックスシグマのようなアプローチは特に有用
秩序的かつ持続性のあるもの
・単純な領域
単純な領域の場合は予め定義されていた解決方法で対応するほうが良い
スクラムを用いるより、手順化したほうが効果的
秩序的かつ瞬時性があるもの
・カオスな領域
プロダクトに致命的な不具合が発生したときには、素早い対応が必要である
すぐに解決しなければ、金銭的な損害、訴訟リスク等がある場合
そんなときスクラムを用いる余裕はない
プロダクトバックログの優先順位を決め、次のスプリントでなにをするかを考えている場合ではないから
無秩序かつ瞬時性があるもの
・無秩序
自分が上記の4つの領域にいない場合は、まずどれかの領域に状態を変化させることを優先させるべき
無秩序な状態でスクラムをする必要はない
・割り込み駆動
スプリント内で割り込みが多い場合はスクラムはあまり向かない状態です
割り込みが多いことで、スプリント内で終わるタスクに自身が持てなくなるため
バックログの中身や優先順位も頻繁に変更しなければなりません
割り込み駆動の場合はカンバン手法を取り入れることを検討したほうが良い
スクラムとカンバンはどちらもアジャイルなアプローチであります。
メリットデメリットはあるので、自分の関わっている領域を考慮して、プロダクトにあった手法で開発を行うことが大事
状況によっては新規開発はスクラム、保守はカンバンで行うのもいいかも
結局どんなときに効果的なの？
無秩序かつ持続性のあるものを扱うとき
はスクラムを導入すると効果的です。
手順を作ったほうがいい定期的な作業や、一つのことに深く踏み入れる必要がもの、スクラムをやっている暇がない短納期なもの、割り込みが多い場合はスクラムは効果的にでない場合が多いと思います。
Discussion