なぜ開発フレームワークは形骸化するのか

三つのフレームワーク、同じ結末

ステージゲート法は早期撤退のための仕組みである。しかし実務ではGoのための儀式になる。

フロントローディングは上流で問題を潰すための考え方である。しかし実務では帳票を埋める作業になる。

WBSはプロジェクトの抜け漏れをなくすための道具である。しかし実務ではテンプレートを埋めることが目的になる。

三つのフレームワークは設計思想も適用領域も異なる。しかし形骸化の末路は同じである。なぜか。

形骸化の共通構造

三つに共通するのは、以下の構造である。

フレームワークが組織に導入されると、担当者はフレームワークの「目的」ではなく「完了」を目指すようになる。ゲートを通過すること、帳票を埋めること、テンプレートを完成させること——それ自体が目標になる。本来の目的——プロジェクトを選別すること、上流で問題を潰すこと、抜け漏れをなくすこと——は後景に退く。

この構造が生まれる理由はシンプルである。人間は楽をする方向に動くからである。

ゲートは通過するために資料を整える。フロントローディングの検証会議は形式的に参加する。WBSの項目は根拠なく省く。いずれも、目的ではなくフレームワークの完了に向けた最適化である。個人の怠慢ではない。そういう構造の中に置かれれば、人間は自然とそう動く。

なぜ組織はフレームワークに頼りたがるのか

それでも組織はフレームワークを導入し続ける。なぜか。

フレームワークの導入は「何かをやった」という事実を生む。課題が認識され、解決策が選ばれ、展開された——このプロセス自体が、問題に取り組んでいるという証拠になる。しかしフレームワークの導入は課題解決の始まりではなく、多くの場合、課題解決をしたつもりになるための行為になる。

フレームワークは目に見える。導入の完了は確認できる。しかし「フレームワークが機能しているかどうか」は目に見えにくく、確認しにくい。だから組織は導入を評価し、機能を評価しない。

この構造が変わらない限り、次のフレームワークを導入しても同じ末路をたどる。

フレームワークは人間の行動原理を変えない

ここに、多くの組織が陥る根本的な誤解がある。

フレームワークを導入すれば、組織の行動が変わると思っている。しかしフレームワークは道具であり、道具は使う人間の行動原理を変えない。ハンマーを渡しても、打ちたくない釘を打つ人間にはならない。

「進めること」が評価される構造の中では、ステージゲートのKillは出ない。上流参加にリソースが割り当てられていなければ、フロントローディングの検証は形だけになる。省略判断が個人に委ねられていれば、WBSの項目は削られ続ける。

フレームワークの導入と、人間の行動原理の設計は、別の問題である。この二つを混同している組織は、フレームワークを導入するたびに書類の種類だけが増えていく。

では何が必要か

三つの記事を通じて見えてきた解決策には、共通のパターンがある。

評価設計を変える。ステージゲートであれば、担当者の評価軸を提案数・独自性に、レビュアーの評価軸を打率に変える。進めることではなく、選別することが評価される構造にする。

リソース配分を変える。フロントローディングであれば、品質・生産技術担当者を上流に厚く張る。足元の業務を多少穴開けてでも未来に投資する覚悟を持って、経営判断としてリソースを動かす。

判断を仕組み化する。WBSであれば、省略判断を個人に委ねず、技術レビューという構造で担保する。意図を理解させるだけでは不十分であり、判断の場に複数の目を通す仕組みが必要である。

これらの条件を整えれば完全に解決するとは言えない。しかし条件を整えなければ、確実に機能しない。フレームワークの機能不全は、フレームワーク自体の問題ではなく、フレームワークが機能する条件を整えていないことの問題である。

問い直すべきこと

フレームワークを導入している組織に問いたいことがある。

そのフレームワークは、目的のために設計されているか。評価設計は人間の行動原理と整合しているか。リソースは本当に割り当てられているか。判断は個人の良識に委ねられていないか。

フレームワークの名前を知っていることと、フレームワークを機能させることは、まったく別の話である。

各記事はこちら。

所属組織の見解ではなく、個人の意見・考察です。