【メモ】チーム・ジャーニー第9話本読み会
本読み会に参加してご質問させていただき、ご回答をいただきました。毎週貴重なお時間をつくっていただき本当にありがとうございます。
本記事は、そのメモ。
【Q】プロダクトにとっての価値は、技術的負債の返済も含まれているのでしょうか？
【A】「技術的負債の返済」の必要性を「プロダクトにとっての価値」として論理的に説明可能である。
P.162 の「プロダクトづくりにおける3つの価値」のひとつ「プロダクト（にとっての）価値」の解説にある「プロダクトの変更可能性」に関する質問。
変更可能性は変更容易性と読み替えても構わないかもしれない。
「プロダクトにとっての持続可能性を担保する」ために「技術的負債の返済」は必要であると言える。
ビジネスチームと開発チーム間で共通理解を得にくい要素の一つなのでは？と思う。
長年悩みの種の一つであったが、「共通理解をつくる」糸口を見出せたのは非常に嬉しい。後々開発ができなくなるという事は話し合いの中で伝えてきたつもりだが、ピンと来ていなかったに違いない。「プロダクトにとっての価値」を知った事でよりよい対話ができそうだ。
スタートアップで資金がショートしてしまうような状況では違ってくるのかもしれない。
これまで「技術的負債の返済」に悩まされ、いつしかアウトプットが思うようにできなくなり、大きな痛みを伴って対応していく状況をいくつか間近で見てきた。そして私自身も当事者としていくつか体験してきた。
当事者のひとりは「5年、10年に一度の一大プロジェクトだ」などと意気揚々と発言していたと記憶しているが、そもそもそのような状況をつくらずに済むことはできなかったのだろうか、と改めてふりかえる良い機会にもなった。
ある人は「仕方ない」と語り、またある人は「偉くなるしかない」と語っていた。
手遅れになる前に私には何ができるのだろうか。
ステークホルダーと開発チームとの間で良好な関係をいかに築き、3つの価値について対話し、分断を埋めていく継続的な努力が必要だろう。
負債は資産？
どれくらい前の話が曖昧だが、技術的負債の返済について相談した際に「負債もまた資産」と力説？されたことを思い出した。
？？？
これにはついてはまた考えたい。
「技術的負債の返済」をうまく取り組んでいく方法
「プロダクトにとっての価値」を謳って何でもかんでもやれるわけではない。
ROI(投資利益率)のような定量化技法を使えば良さそうだ。
「工数に対する効果（費用対効果）」をある程度定量化できれば、効率よく返済ができそうだ。
マイクロサービスアーキテクチャ？
モノリシックなサービス開発が辛くなってきた際のソリューションの一つとして、マイクロサービスアーキテクチャがある。
こうった方面に舵切りを判断するのもプロダクトの持続可能性を担保するためだろう。
Shopifyは違う解決したみたいだけど
この記事が気に入ったらサポートをしてみませんか？