PdM/EMが気づくべき「技術負債」の異変
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。
一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。
とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。
以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。（特に、1.と3.）
- 一般的な視点と現場システムへの理解度のズレ
- 詳細から開発手前での予測のズレ
- 予測工数と実績工数のズレ
ここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する
1.一般的な視点と現場システムへの理解度のズレ
例えば、決済システムに対して冪等性を担保するために冪等キー（Idempotency Key）を導入しようと考える。一般的に考えれば、同じIDのPayment IntentやInvoiceであれば、2回目以降の決済リクエストについてはデフォルトでエラーで返すなどの処理が考えれるため、施策の企画段階でコスト計算するときに2人月（約200万とする）という判断をしたとする。これはEMやエンジニア上がりのPdMといった一般的に開発がわかっているが現場で手を動かしていない人が見積もることもあるだろう。
しかし、現場のエンジニアがPRDやDDを書きながら超概算や詳細見積もりをしたところ10人月かかると言われたとする。よく開発現場ではあることである。
この2人月→10人月に関して、チーム開発でおおよそスキル感が同じメンバーであれば技術負債が溜まっている予兆として捉えてもよいだろう。つまり、一般的な0→1を作る一般的な見積もり場合に対して、5倍かかるということは影響範囲の大きさや手を加えないといけない箇所が複雑化・肥大化しているということである。もちろん、テストケースの肥大化などキレイいシステムを作っていても月日に応じて肥大化するものはあるため一概には言えないが予兆としては外れていないだろう
2. 詳細から開発手前での予測のズレ
実際にドキュメントベースでざっと見積もったものと、開発手前でバックログアイテムとして積んでいくフェーズでもズレるものもある。ただ、この幅はそこまで大きくないだろう。
特にチームで開発している場合、おおよそ集合知で同じようなestimateが可能になっていることが多いため、PRD→DD→Itemとなっても1つ1つの作業規模はズレないと思われる。
3. 予測工数と実績工数のズレ
ここが一番ズレることが多い箇所である。
実際にアイテムまで分解した状態での予測線というのものは、そのチームの見積もりとしてはベストな状態のものが出てくる。
ただ、実際には開発開始からリリースまででもいろいろなことが起きる。必然的に予測工数と実績工数のズレが出てくる。
理由は主に2つ。設計の欠陥が発覚するパターンと予想よりスキルが追いついていないパターン。あとはスコープクリープといった要件の変更があるが技術負債による影響とは関係ないので省略する。
予想よりも工数が膨らんだ場合でも工期を固定したままスコープをいじったり、人員を追加してどうにかすることが多いため、きちんとトラッキングしておいたほうが振り返りにも使える。
まとめ
開発チームではない外部のメンバーから見たときに、新規開発やエンハンス開発といった顧客価値に直接紐づく施策以外のIssue（リファクタリング等の内部品質や運用関連）の重要度を図るうえで、現状のシステム状況がどうなっているかを内部のコードを見て判断するのは難しい。その場合、こうしたシステムに対しての変数としての予測値と実測値を入力 / 出力の可観測性をモニタリングして予測するのも良い方法だと思います。
