仮説検証スタイルとアジャイル開発の関連性
勝間和代の本を読みながら、アジャイル開発との関連性についてメモ。
#ラフなメモ書き。
【元ネタの本】
昨今、外資系コンサルタントやMBAホルダーの思考スタイルであるフレームワーク思考、仮説検証スタイル、ロジカルシンキングなどが流行している。
それらの本を読んでみると、確かに実際の仕事で役立つ。
これらの本で興味深いと思ったのは、限られた情報の中で、精度の高い意思決定をする技術の重要性だ。
つまり、鮮度はいいけれど正確さが多少悪い判断の方が、遅くて正確な判断よりも重要である、と。
この意思決定のスキルは、中間管理職よりも経営者のように上級マネジメント職での基本技術のように思える。
実際、経営者は、動きの激しいマーケットの中で、素早く正しい舵取りを要求されている。
この意思決定の構造は何か?
それが仮説検証スタイルなのだろう。
つまり、限られた情報から、論理的に整合性が取れている仮説を一旦作り、それから行動すべき対策を導き出すことだ。
勝間和代の本では、この構造を「空-雨-傘」フレームワークと呼んでいる。
空は客観的な事実。
雨は人の解釈、主観。
傘は解釈に対する行動、対策。
「空-雨-傘」やロジックツリーなどのフレームワーク思考で、限られた情報から推論して一つの仮説を作る。
仮説があるからこそ自信を持って実行できる。
実行した結果を仮説から導き出される結果と比較して評価する。
それが検証プロセスになる。
その評価によって、仮説を更に修正して強化していく。
いわゆるPDCAサイクルにおけるCheckとAction。
この手法はアジャイル開発に似ている気がする。
アジャイル開発では、イテレーション又はスプリントと言う定期的な期間の中で、実現すべき要件をシステム化していく。
要件であるストーリーは、システムの観点から眺めれば曖昧であり、実装前にいくらきちんと設計しても、システムとして動作しなければ分からない所もある。
また、ストーリー通りに作ったとしても、顧客が受入テストで動かしてみたら、障害があるだけでなく、些細な機能を変更したい、などの改善要望も出てくるだろう。
開発者の戦略としては、与えられた要件から論理的整合性に矛盾なく動作するシステムをまずは作り、早くリリースしていく。
そして、顧客のフィードバックを受けて、仕様変更を受け入れる余力を保持できるように、設計も実装も開発チームの体制もあらかじめ作っておく。
与えられた要件のうち、一部は間違っていたり、あるいは、開発者が要件をきちんと認識できていなかった部分もあるかもしれない。
でも、間違った認識に基づいたとしても、ロジカルに設計して実装できたならば、後から修復は可能だと思う。
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」でも、下記の一節がある。
意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても、変わらずしっかりしているはずです。
つまり、意思決定のプロセスが正しく進んでいるならば、限られた情報で誤った方向に進んだとしても、検証プロセスを速める事によって、正しい方向へ軌道修正できる能力がある。
アジャイル開発へ仮説検証プロセスを意識的に取り入れたならば、現場リーダーは自信を持って意思決定できるのではないだろうか?
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
コメント