7.2 技術投資・IT投資と開発生産性の接続
企業の技術投資・IT投資を考えてみると、最終的には管理会計としてのB/S（貸借対照表）の資産や、P/L（損益計算書）でいう開発費用全般を考えていく必要があります。その下にはソフトウェア開発としての区分（新規開発・エンハンス・保守開発・運用・その他）を分けることで、B/Sに必要な資産化するものと、費用化するもの（経費）が区分しやすくなります。
また、現状のシステムを維持する工数と、新しく価値を作るのにかけられている工数にどれだけ時間をかけられているのかがわかります。新規開発・エンハンス・保守開発は、いわゆるソフトウェアに手を加える開発業務のため、その下にはLead Timeと呼ばれる案件の開始から終了までにかかる時間がとれます。
そこからは、一般的に開発生産性の議論でよく出てくるCycle Timeまで分析できます。Cycle Timeを開発開始〜リリースまでのスコープとすると、Four KeysやSPACEといった開発生産性のメトリクスや、チーム開発で言えばJIRAのチャートによるコンディション分析、フロー状態を管理するためのGoogleカレンダー（予定管理）といったソフトウェア開発現場の開発生産性のデータのことを指します。
第1回の「1.3.1 "開発生産性"という言葉は、レイヤーごとに意味が違う」で見てきた「Cycle Time」よりも上にある「Lead Time」データである「工数」「工期」「コスト」は、マネージメントレイヤー（PdMやEM）が主に関心事として見ているデータになります。ボトムに行くほど、各チームのルールや開発手法も変わってくるため、複数チームで1つのプロジェクトを達成するためには、工数や工期といった統一したデータが必要になります。
そうしないとプロジェクト管理（目標リリース）やリスク管理ができないからです。また、PdMが気にしているのは「このプロジェクトや機能開発にいくらかかるのか・かかったのか」です。そのため、予測としての工数に単価をかけて計算が必要なほか、実際に終わったタイミングで実績工数に対して単価をかけて予実を見ることも必要です。
7.2.1 現状を維持するための工数と新しい価値に使える工数
ソフトウェア開発は、以下に分解できると分析がしやすくなります。
- 新規開発：新しい価値を0から作る
- エンハンス開発：既存システムの拡張・変更
- 保守開発：資産価値の耐久年数を維持する・伸ばす（振る舞いを変えずに現状維持を行うリファクタリング・バージョンアップ）
- 運用：障害対応、問い合わせ対応
- その他：会議やその他開発以外の作業
1〜3は必要な開発区分で、4〜5は開発以外の区分です。開発区分でよくあるリスクとして、保守開発の中にあるリファクタリングやミドルウェア、言語のバージョンアップを行わないことが挙げられます。事業を伸ばすための新規開発やエンハンス開発をひたすら行っている現場が多く存在します。
当然、機能を追加したり、新しいプロダクトを作ったり、リリースした分だけ、その後の保守コストを考えなければなりません。つまり年数が長いほど、保守コストは増えていきます。保守開発では、適切に負債（保守コスト）が貯まらないようにドメインモデリングをし直したり、機能を捨てたりします。また、保守開発に適切な工数がさけていないと運用コストが跳ね上がっていきます。
例えば、営業メンバーによる「ユーザーのメールアドレスがほしい」という要望は、エンジニアに依頼されるケースがよくあります。エンジニアはデータ分析のツールがGUIではないことから、データストアに入り、SQLを叩いて持ってくるという運用コストがかかってしまいます。一つひとつの作業時間は少なくても、細切れに着手することでフロー状態が保てなくなり、重要な作業にも影響します。
保守開発により、営業メンバーでも適切な権限のもと、管理画面から操作してデータ取得できるインターフェースを作ることで、結果的に運用コストが減り、開発にかける時間は増えていきます。
区分を5つ分けることで、「現状システムを維持するのにかけられているコスト」と「新しい資産価値を作るコスト」を明確にすることができます。下図を見てみると、現状を維持するためのコストは、保守開発から運用や会議、その他です。そもそもここのコストが高いと、新しい開発にさける時間がありません。ここを明確にしないままにすると、「いまの開発組織は開発が遅い」「何をしているかがわからない」というハレーションの原因になります。
一方、B/Sを考えたときにも、資産化するべきもの（減価償却するべきもの）と費用化するべきものがわかりやすくなります。資産価値とは「新しい資産を作るか（新規開発）」「既存資産を拡張・変更するか（エンハンス開発）」「耐久年数を維持・伸ばしているか（保守開発）」の3つです。企業フェーズによってさまざまな考え方がありますが、資産化するものを多く作っていきたい（ユーザーに価値を多く届けていきたい）と考えれば、できるだけ費用化するもの（運用、会議その他）を減らし、資産化対象の開発を行うべきです。
第6回でみたように、この資産がもととなって、最終的には売上を作っていきます。P/Lという観点では、資産から作られた売上からあらゆるコストなどを引いたものが最終的な利益になります。このコストの部分は、我々の人件費から始まり、各種ツールやライセンス費、サーバーコストや資産の減価償却費となっていきます。
この現状維持コストと、新しい価値を作っている工数という側面に加え、資産化するもの・費用化するものを判断し、分析するために5つの区分をわけて管理するのは大事なことでしょう。
関連データとして、品質データも必要です。「なぜ、開発が遅いのか」を答えるときに、障害件数が多く、運用コストが大きくかかっているケースも多いでしょう。そういったチームには無理やり改善を求めるのではなく、ポストモーテムの傾向値から根本的に保守開発工数を増やし、改善に進むのがよいです。
技術負債の量を定量的に測る手法が多くありますが、「PdM/EMが気づくべき「技術負債」の異変〜予測精度の幅で捉える〜」（筆者の個人ブログ）には、工数の予測精度の幅で捉えることを述べています。
本来、技術負債とは現場のエンジニアが感じる理想と現実との乖離のことで、リファクタリングやリプレイスはその差分を少しでも埋めることを指します（その差分を本当に埋めることができるかは、エンジニアのスキルとシステムの複雑性によります）。そうなった場合、どこに一番その予兆があるかというと、工数の予測精度の幅があると仮定したときで、各予測フェーズでのズレを見ていくとわかります。
一番ズレが大きく、技術負債の予兆があるのは「超概算→設計」のフェーズです。一般的に「このぐらいだろう」という部分と、実際に設計をはじめたあとに出てくる見積もりの幅が大きいというのは、本来シンプルなところが複雑になっている可能性が多いです。
予測→実績の部分にももちろんありますが、ここはいろいろな理由が存在しており、スコープ・クリープ（途中での要件変更）やエンジニアのスキルなどがあるため、技術負債とは別の要因が多くあります。こういった障害件数やポストモーテムの分析、技術負債の傾向なども品質データとして持っていくことが必要です。
