プロダクトの技術的負債とPMはどう向き合うべきか
コメント
選択しているユーザー
技術的負債は、技術とビジネスの両方の問題を含んでいるということを具体的に説明するいい記事だと思います。この記事にも書かれているように、技術的負債の項目を明らかに（定義）して、その影響と改善コストを見積もり、対処する範囲や優先度を決めていくというやり方が王道だと思います。
洋書ですが、Philippe Kruchten等が書いた『Managing Technical Debt—Reducing Friction in Software Development』(Addison Wesley, 2019)という書籍では、系統的に技術的負債に対処する方法が説明されています。また、この書籍の内容の要約を、以下のページに掲載しています。
https://m3tlab.wordpress.com/%e8%97%a4%e4%ba%95-%e6%8b%93%e3%81%ae%e7%a0%94%e7%a9%b6%e3%81%a8%e5%ad%a6%e3%81%b3%e3%81%ae%e3%82%b5%e3%82%a4%e3%83%88/%e8%aa%ad%e6%9b%b8%e3%83%a1%e3%83%a2%e3%80%8emanaging-technical-debt-reducing-friction-in-software-development%e3%80%8f/
注目のコメント
「技術的負債を解消したいが経営判断でさせてくれない」という状況はそろそろ無くなってきた気がします。どの会社もエンジニアに気持ちよく働いてほしいですから。
逆に、技術的負債の解消タイミングをエンジニアの肌感覚に任せるしかないという状況が増えてきたのではないでしょうか。
記事では部屋の掃除に例えていますが、部屋の汚れは誰の目にも一目瞭然なのに対して、ソフトウェアの汚れは一目で全容を把握するのが難しいです。
だからこそエンジニアやCTOと話すことが必要と書いているのだと思います。
実のところ、ソフトウェア業界のベストプラクティスはもう少し進んできているように感じています。
何が具体的に技術的負債であるかを一目で把握するのは難しいですが、技術的負債が増えていることを可視化する方法はかなり揃って来ました。
例えばライブラリのアップデートが滞っていたり、自動テストが無いコードが増えていたり、サイトが遅くなっていたり。これらは既に簡単に可視化できます。
こういう指標が悪化傾向にあれば、必ず技術的負債が溜まっているので、少なくとも横ばいにしていくコストをかけ続けるのがベストプラクティスとされています。これなら逐次話し合って判断する必要が無いのでスピードが出せます。
（それでも可視化できない設計レベルの技術的負債というのもあり、その場合は話し合いが必要です）プロダクトをリリースしたのち、機能アップデートを続けていくとどんどんシステムが複雑になって手をつけられなくなる（技術的負債）。なので、どこかで返済する必要があるけど、その場合は新機能の開発が止まってしまう。プロダクトマネージャーはどう向き合ったらよいのか。
リクルートがQuipperを買収した際に既存サービスの技術的負債の返済を諦め、システムを乗り換えたというのは知らなかったです。
SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”
https://newspicks.com/news/4277094
メドピアCTOが明かす、技術的負債を乗り越えるためにやったこと
https://newspicks.com/news/4273932
