2.2 フロー状態を妨げる、組織の摩擦による"不安"の定量化
ここからはフロー状態の重要性が、なぜ見落とされるのかを考えていきます。
フロー状態が阻害される原因の一つは、組織の摩擦が関係していると考えています。「摩擦」とは、開発者が直面するあらゆる種類の障害や遅延のことで、これには組織で動く中で生まれてくる不明瞭な要件、不十分なツール、コミュニケーションの障壁、納期への意識があります。
この摩擦の正体を最近考えていると、「不安の定量化」ではないかと気が付きました。そもそもエンジニアリングは、外から見ると非常に不確実性に飛んでおり中身がブラックボックスで、なぜ他社だとできることが自社ではできないのか、または工数がかかるのかはエンジニア以外のメンバーにはなかなか理解しづらいところです。エンジニアはそんな不確実な状態に慣れすぎています。
ソフトウェア開発は、システム、プロダクト、組織のどこを切り取っても複雑に絡み合っており、作る機能の見積もり工数も正確には当たらないですし、システムが急激に思いもよらない挙動をします。ソースコードの意図が掴めずスパゲッティー状態になっていることもしばしばです（たまに自分がそのようなコードを書いていることもあります）。
エンジニア以外から見ると、なぜ簡単そうな仕様実装がこんなにも時間がかかったり、逆になぜこんな難しそうなことが一瞬でできるのか、なぜ多くのバグがでるのかイメージがつきづらいものです。
こうしたエンジニアとその周辺にいるステークホルダーとは、多少なりとも摩擦があります。その摩擦が多い場合には、エンジニアと沢山話をして理解するしかありません。ボトルネックの最終地点、あらゆる根幹がシステムに多く、それを作っているのがエンジニアだからです。
そうなるとエンジニアは説明責任からは逃げられません。フロー状態の時間がどんどん無くなっていきます。進捗を管理する、マネージャーやPMからその都度会話の場を設定しては、効率が悪いので定例会のような決まった時間に場を用意します。Slackでも疑問点があれば聞きます。それはエンジニアしか知り得ない情報が多いからです。ブラックボックスなものは、PMが考えても答えがでないからです。
すると前述した通り、タスクのタイムボックスの違いでまとまった開発の時間が取れなくなります。さらに目標スケジュールに間に合わせようと開発時間を伸ばしていくので、根本的なブラックボックスを組織間で取り除く作業時間もなくなっていきます。
状況を知るためには、以下の事象が発生します。
- WBSの詳細化が求められる（細かすぎるとすぐにズレるので「管理のための管理」が増える）
- 開発生産性をチームのためではなく存在価値に使う（自社のエンジニアの生産性を確かめたくなる）
- 説明責任の時間が増える（詳細を知りたいので、PMやマネージャーと開発リーダーとの会話時間が増加し、開発時間が減る）
これらはどれも一定数必要なものですが、時間をかけすぎては開発する時間がなくなり本末転倒になりがちです。特に開発生産性の可視化については、監視のために使うことはアンチパターンで、自分たちのケイパビリティー向上のために使わなければ逆効果になるケースもあります。
よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です（プルリクエスト数など）。自分たちのために行っていれば極端にハックする意味がないことは明白ですが（開発が早くなっていないのは自身では理解している）、チーム外のために開発生産性を存在価値のために提供すると、事象が起きやすいので気をつけたいところです。
2.2.1 プロジェクトの失敗は、"見積もり"の失敗である
ここで、よく摩擦が生まれる箇所としてプロジェクトの遅れによる失敗について考えてみます。マーティン・ファウラー氏の言葉を借りれば、プロジェクトの遅れの1つの誤解は、納期の遅れによる失敗、予算がオーバーしたことによる失敗ではなく、失敗したのは見積もりの失敗であるということです。
"Rather than saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. "
「プロジェクトが遅れた、またはコスト超過したために失敗したと言うのではなく、失敗したのは見積もりだと私は主張します」
引用 : WhatIsFailure
開発組織のケイパビリティー（能力）が定量化できないとすると、ソフトウェア開発の完了予定日は「自分たちが"予測通り"に達成できたか」でしかありません。目標を高く設定していれば、工数・予算・品質の部分で失敗の確率は上がりますし、目標を低くしていれば成功確率は上がります。
以下は、プロジェクトの失敗レポートとして有名なカオスレポートと日本のプロジェクトの失敗レポートです。
「CHAOS REPORT 2015」
CHAOS REPORT 2015は、ソフトウェア開発を以下の6つの項目によって分析したプロジェクトの成功・失敗に関するレポートです。
- OnTime（時間通り）, OnBudget（予算内）, OnTarget（目標達成）, OnGoal（目的達成）, Value（価値）, Satisfaction（満足度）
2011〜2015年のデータを見ると、Medium（普通）サイズの開発規模だと、失敗の確率は26%。逆に想定通りに完了した成功確率がわずか 12% になっています。当然ですが、大規模な開発になればなるほど失敗の確率は高くなります。これは大規模のほうが不確実性が高く見積もしにくいからと見ることもできます。
業界別で見ると小売業が最も高い成功率であり、一方で失敗率が高いのは政府系です。北米は成功率が高く、アジアは低いと色々なデータが見れます。
「企業IT動向調査報告書 2023」
一方、アジアである日本のデータを一般社団法人日本情報システム・ユーザー協会（JUAS）が提供しているデータを見てみます。下図は、工数×規模別（人月）に予定通りに完了したか、予定より遅延したかを表している図です。規模別に22年度の最新データを見ると、予定通りになる確率が 14〜32% で、遅延した確率が 17%〜52% になっています。ここでも規模が大きいほど予測（見積もりとのズレ）が難しいことが分かります。
次にその原因についてですが、その多くは計画時の考慮不足や仕様変更（スコープクリープなど）、システムの複雑さが挙げられています。規模が小さければ、当然先が見えやすければ計画時の考慮不足も減りますし、同時にスコープの追加や変更も検査・適応が効く範囲になるでしょう。
2.2.2 そして、"見積もり"はだいたい外れる
見積もりが大事という話がある一方、その見積もりもだいたい外れるというデータです。x軸に計画（見積もり）があり、y軸が実績数値ですが、緑の線より上にあるものは予定通りに完了、下にあるものは計画時よりも遅延しています。見積もりが小さい（左下）のときはおおよそ計画通りに完了しますが、計画が大きければ大きいほど完了時間のズレは大きくなります。
こうしたデータを見たときに、見積もり（設計力とも言える）の精度が上がらない以上、プロジェクトの成功・失敗に大きな影響があります。見積もり精度を上げるには組織の経験学習、ひいてはエンジニアのスキルレベルによります。設計力が強いエンジニアが組織の中にいるだけでこうした問題は解決する方向に進みます。
2.2.3 摩擦を減らすには、互いに信頼を獲得すること
ただし、必ずしも強いエンジニアが多く存在しているわけではありませんし、根本的なセクショナリズムの解決方法でないと思っています。本来は、開発組織に信頼があれば、このようなフロー状態を阻害する組織摩擦は起きにくいです。
信頼が積み上がっていれば、そもそもチーム外から開発速度や生産性について大きな関心が生まれることは少ないです（少なくとも存在価値の監視のために使うもの）。逆に信頼を積み上げていくために開発生産性の可視化をしていく考え方もありますが、その場合は第1回で述べた組織レイヤーごとに開発生産性の意味を変換しながら伝えていく必要があります。
2.2.4 開発の投資対効果を測るのは難しい
また、ソフトウェア開発の成果（投資対効果）を定量化するのは、非常に難しいことも関係しているでしょう。生産性とは、アクティビティの入力とその出力を観察することで判断できます。
そうなるとソフトウェア開発の成果を正しく測定する必要があります。技術投資額とそれに対するリターンはP/L（損益計算書）では確認できるかもしれませんが、機能やプロジェクト（特にリプレイス案件）ごとに判断は難しいですし、時間軸として半年後や1年後、数年後を見据えて「今やっておくべきこと」がソフトウェア開発では多く存在します。逆にプロモーションやキャンペーン、機能開発というのはリリースした直後に数値（例えば売上）として跳ね返ってくるので、投資に対する時間軸のズレと技術投資への判断軸の難化も投資対効果を見る上で難しい点の1つです。
ここまでで、見積もりの不完全性によって摩擦が起き「フロー状態」を妨げられることで、さらに時間がなくなり開発生産性が上がってこないという話を述べてきました。次回は、生産性が低いチームを強くするための「順番」について紹介します。
参考資料
- MAKER'S SCHEDULE, MANAGER'S SCHEDULE | Paul Graham
- DevEx: What Actually Drives Productivity | Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler
- The SPACE of Developer Productivity | Nicole Forsgren,Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler
- How Do Interruptions Affect Productivity? | Duncan P. Brumby, Christian P. Janssen & Gloria Mark
- 開発生産性の低下による、事業の失敗はなぜ起こるのか | 石垣 雅人
- CHAOS REPORT 2015 | The Standish Group International, Inc.
- WhatIsFailure | martin fowler
- CannetMeasureProductivity | martin fowler
