5.3 開発生産性が悪いと調整コストが膨れ上がる
悪影響のパターンを4つ見ていきます。結論から言うと、開発生産性が悪いと調整コストが膨れ上がります。つまり、無駄な追加予算（人件費）が発生し、プロジェクトにおいても遅延しやすい状況になります。
5.3.1 そもそもやりたい施策に稼働率が手一杯でアサインができない
これもマネイジメントラインの立ち回りをしている人にはよくあります。経営層やプロダクトマネージャーからの「売上・利益目標に達するために（この施策を実行するために）プロジェクト化したい」というオーダーは存在します。中には、市場の流れから当初計画になかったものがトップダウンで来ることも当然あります。
その中で、PMや開発マネージャー、開発チームは既存プロジェクトにかけている工数や工期のバランスを考えながら、優先度を変えたりスコープを変更したりします。難しいのはシステムのことを考えるとできるだけ、一つひとつ作りきってから次にいかないと負債が溜まってくるので、途中での計画変更や案件の入れ替えはしたくありません。
PMとしては、ソフトウェアの中身までは操作可能変数ではないので、優先度判断とスコープ判断、追加予算を使うなどが可能な武器になります。開発生産性＝開発速度がないと稼働率が100％になり、PMが関与できる余白がなく、既存計画で精一杯になります。
5.3.2 プロジェクトを進める中で、計画が見積もりよりも大きくズレてくる
次に見積もりに関する課題です。実際に計画よりもズレてしまうのは、スコープクリープといった仕様の変更や設計ミスといった部分もありますし、単純に開発スキルの問題もあるでしょう。
一方、現場を見てみると「見積もり」に関する価値とフェーズへの誤認があるように思えます。それにより、要求が抽象的な状態から見積もりを外さないように、時間をかけて見積もり作業をしたり、バッファを多く積んだり精度を高めようとします。見積りの根拠を示すために、その精度を高める努力をはじめるのは本質的ではありません。フェーズによる部分もあります。
「見積もり」には、以下4つの側面があると考えています。
- 施策の合否を判断するための「見積もり価値」
- 納期・スケジュールの管理のための「見積もり価値」
- 設計のセンスやシステムの複雑性を検知するための「見積もり価値」
- 自分たちの予測精度をあげるための「見積もり価値」
1.の施策のGoを判断するために、見積もりは今まで述べてきた超概算見積もりが当てはまります。その施策にお金を出すべきかを判断するために用いられ、「1000万の費用を想定していたが、1億円かかった」という実はエンジニアは薄々わかっていた状態を回避する意味もあります。超概算のため精度は低くてもOKです。大枠、1人月なのか5人月なのか、10人月かかるのかが分かれば、おおよその予算計画は立てられます。
2.もイメージしやすく、こちらの見積もりは詳細設計による見積もりに入っているため、精度は高いかもしれませんが、施策の遂行している中での予実管理に使うものです。当初の予定としてN日までのところまで終わっていないといけない計画見積もりでしたが、実際は少し遅れているのでどこでリカバリーするのかを判断するために有効なデータになります。
そして、3.および4.が見落としがちな「見積もり価値」。3.の設計のセンスやシステムの複雑性は、主に開発チーム内で使われるシーンです。何かの要件を満たす実装をする中で、その達成プロセスは考える人の分だけ枝分かれしていきます。
チームが成熟していくと、おおよそ処理を追加する箇所や、手を入れないといけないアーキテクチャはシステムを共有しているため一致してきます。それが現れてくるのが「見積もり」です。改めて考えてみると、見積もりというのは、抽象的な要件に対してどのアプローチで攻めていき実現するのかを示す羅針盤となるものです。出力としては、「何人日」「何人月」「何スプリント」といった数値で出てきますが、入力処理は全然違ってきます。
同じ内容の機能を作る中でも、チームに存在するメンバーや保有しているシステムの熟練度、内部品質によって見積もりは大きく変わってきます。0→1を作るときは1人月だとしても、古いシステムに手をいれることになると5人月かかることはザラにあります。また、エンジニアのレベル的に、ジュニアなメンバーなのかシニアなメンバーなのかでも大きく違います。
こうした見積もりを通して、そのチームの状態、システムの状態を表出化させて議論を作り出します。設計のミスや漏れをチームとして防ぐ意味もあります。加えて、チーム外への現状の説明責任にも使えます。リファクタリングの重要性を組織として測る基準としても使えるでしょう。
4.についても、3.にあるような見積もりによってチーム、システムの状態を覗き見ることができるのであれば、チームの成長の目標値として使えます。現状のチームだと、「Aという機能を作るのに5人月かかるが、みんなの利用は1人月である」という共有された目標をバッファなどを使わずに議論することで、どうしたらそれが達成できるのか、問題点はどこにあるのかを洗い出していく定量データとしても使えます。同時に、自分たちを客観視して予測精度をあげていくためにも使えます。開発スピードをあげるために、獲得するべき速さは意識するところから始まります。
また、見積もりにおいては「バッファ」という考え方があり、適切に伝えるケースと悪用するケースがあります。
悪用するケースは、自分たちの保全のために使われるものです。上の4つのケースで言えば、2.のところでどうしても読めない部分がある場合（例えば、法令対応や何かしらの監査対応部分で絶対に納期がずらせない場合）には、バッファを積んだ状態で見積もり予算の優遇を多少効かせるという方法はアリだと思います。
一方、3.および4.の場合、バッファを積んでしまうと自分たちの成長機会と現状把握の部分の計算が狂うため、バッファは積まないほうが良いでしょう。
4つの「見積もり価値」のフェーズごとの使いどころも考えてみます。実施前→開発開始→リリースを考えてみると、1.の施策の合否判断は「実施前」。2. は開発開始〜リリースまでの間であり、3.は実施前と開発の間もしくは開発中でしょう。4.はリリース後に自分たちの振り返りのために使っていきます。
見積もり精度による組織摩擦を回避するためには、こうした見積もりのフェーズ（どのレイヤーの「見積もり価値」のことを言っているのか）をビジネス側やエンジニア側で認識し、話し合いをして決定していくことが重要でしょう。
5.3.3 プロジェクトのどこを犠牲にするのかの判断調整をその都度行う
次にこうした事態が起こると、何を犠牲にするべきかを考えはじめます。「時間」「予算」「スコープ」「品質」のどれかです。
最も優先的に犠牲にされるのは、品質である現場が多いでしょう。時間（リリース日）はそのままで、予算もそのまま（人件費の追加はなし）、スコープ（提供価値の範囲）はそのままでエンジニアリング観点での品質を犠牲にするパターンです。これは内部品質（Internal Quality）であることが多いです。例えば、上で述べた簡単に思える改修であっても、システムのコアな部分に手をいれる必要がある場合に、暫定的な対応でハードコーディングしてしまうなどで、工数を削減したりテストコードを十分に追加したりせずに、おおよそこういう対応をすると、異常系の部分での対応が漏れ、リリースしても不具合が発生します。そして上で述べたシステム障害による組織摩擦のループにもつながってきます。
次にスコープを削るケースです。時間（リリース日）はそのままで、予算もそのまま（人件費の追加はなし）、品質も今後のことを考えそのままで、スコープを一旦削ります。ユーザー価値を検証できる最低限の機能（MVP：Minimum Viable Product）を見極め、スコープを削り、リリースします。そのあとで本来計画した価値提供を行っていきます。ある意味、時間軸のおける機能の提供ポイントと、範囲を意図的に変えている状態で、その機能が売上を上げるものであればリリースした時点で売上が立つため、損失が最小限に抑えられます。
一方、スコープを見誤るとユーザー体験に影響が出るため、スコープを削った状態の機能を触ったユーザーが初期離脱して戻ってこなくなります（リテンションレートが下がっていきます）。この場合にも注意が必要です。
この2つ以外の時間・予算を犠牲にする場合も見ていきます。予算の場合には、主に人件費を投入します。エンジニアやプロジェクトマネージャーを投入し、立て直す方法です。一見、有効そうな手段に見えますが、投入する人員のレベル感によっては逆効果にもなります。
多くの開発現場はチーム開発で行っているため、そのチームならではのやり方や文化が存在します。新しいメンバーが参画する際には、入ってきたメンバーがいち早く生産性を出せるためにオンボーディングと呼ばれるフローを行い、それなりにコストをかけていきます。
プロジェクトの途中で投入された人員が多ければ多いほど、オンボーディングコストは跳ね上がっていきますし、急な人材確保のために行う採用の精度はあまり高くなく、チームに合わない人材を投入することにもつながっていきます。チーム開発は、1人の合わない人材によって崩れやすいです。本来であれば最も大事にするべき「誰と働くか」の部分が、疎かになってしまいます。
ブルックスの法則とも言い、この法則は、「プロジェクトが遅れている時に、人員を追加してもスケジュールの遅れを取り戻すことはできない」という内容を核とした有名な法則のひとつです。
時間を犠牲にする場合は、単純にリリース日を後ろにすることを意味します。この手段を取ることが多いのは、スコープを削れる範囲が少ないからです。また、そもそも納期という概念を作る必要がない場合、後ろにすることが多いです。
逆に何も犠牲にしない場合は、既存のメンバーでスコープも変更せず、品質も変えないとなると、生産性を劇的に向上させるか、稼働時間を増やす（残業する）ことを意味しています。稼働時間を増やすことは、予算（人件費）が増えることも同時に意味しているので、この4つに関しては、複合的にグラデーションをかけながら、何を犠牲にして進んでいくかを考えることになるでしょう。
こうした調整はムダな工数が生まれるので、時間的にも感情的にも悪い影響が生まれ、間違った失敗を引き起こしがちになります。
とはいえ、プロセスを前に進めていると必ずと言っていいほど方向転換が必要になります。
開発生産性が高いと不確実性への対応ができるようになり、柔軟に変更や手戻りに対応できることが強みにもなります。
5.3.4 スコープクリープによって追加予算の調整承認が必要
最終的には、計画からズレた差分を取り戻すために、前述したスコープを削ったり追加で人件費を投入したりすることも多い中で、必ず報告と承認がPMとして必要になります。
プロジェクトを進めつつリスク管理をする中で、追加予算や計画のズレの承認をもらうために資料を作る工数も必要になるでしょう。そもそも開発生産性が高い組織においては、プロジェクトマネジメント自体が不要になるケースもあり、本質的には理想なのかもしれません。
5.4 PMの武器は開発組織の"生産性"
以上が、プロジェクトマネージャー目線での開発生産性に関するペインの話でした。プロジェクトを進める中で、間違いなくPMの武器は開発組織の生産性の高さです。生産性が高いとある意味やらなくても良い作業を省くことができ、本来プロジェクトのアレンジではなく、プロダクトマネジメントとしてやっていきたい「ユーザーのために何を作るべきか」「どういったユーザー体験が良いか」といったクリエイティブな作業に時間を使うことができます。
