技術的負債解消の軌跡～現場と経営をつなぐ実践事例～に参加してきた
会の概要
以下、イベントページから引用です。
技術的負債は、成長するプロダクトや組織において避けられない課題です。
その解消に向けた優先順位付けや組織的な取り組み方を模索されている方に向け、開発組織と経営層を繋ぎ、組織的に技術的負債解消へ取り組まれたお二人のパネルディスカッションを開催します。
DMM.comで第1開発部などの開発組織を率いる石垣氏と、弁護士ドットコムのクラウドサイン事業部を率いる井田氏をお迎えし、お二人の技術的負債解消の事例を伺い、開発組織と経営層を繋いだプロセスやその成功の秘訣についてを以下テーマに沿って深掘りします。
- それぞれの技術的負債のキャッチアップと優先順位付けの具体的方法
- 経営層やチームを巻き込み、技術的負債解消への合意を得るためのプロセス
- チームにおける役割分担と組織的な取り組み方
視聴者の皆様にとって、自社での技術的負債解消の取り組みを進めるための実践的なヒントをお持ち帰れるイベントを目指します。
会の様子
技術負債の「予兆検知」と「状況異変」のススメ
最初に石垣さんから話がありました。
健全なソフトウェア→変更容易性が低いソフトウェア→健全なソフトウェアの順にソフトウェアは遷移するということで、変更容易性が低いソフトウェアになるための予兆を検知することがまず大切だという話がありました。
石垣さん的には、
- 計画見積もりと実績値の差分
- コードの変更やレビューにかかる時間の増加傾向
- 障害変数の再発防止策完了件数
- エンゲージメントスコア
が予兆検知に使えるということでした。また、経営者に対して技術負債に関する説明をする際には、「コスト」ではなくて「投資」であるということを説明するようにしていたそうで、保守開発と新規開発の割合を合意するようにしている(優先度の話はしない)ということです。
技術負債の解消をするのは、既存チームがやる場合も専門部隊チームがやる場合もそれぞれあるそうですが、既存チームであれば新規開発と保守開発の割合を客観的に決めるのが難しいことや新規チームであれば既存のプロダクトチームとの連携が必要になることがあるため、どちらも一長一短であるということでした。
技術的負債解消の取り組みと専門チームのお話
続いて井田さんから話がありました。
井田さんが所属しているチームのプロダクトでは、エンハンス開発をしていく中でどうしても改善できない課題があり、改善チームを増やすという決断をしたそうです。
ただし、経営者視点で言えば、「なんでこんな事になってるの？」「エンジニアの能力が低いんじゃないの？」みたいな話に気をつけないとなりがちなため、「技術的負債」という単語ではなくて例え話で経営陣には説明するようにしていたということでした。
パネルディスカッション
講演の後はパネルディスカッションがありました。以下、テーマと回答を常体かつ一問一答形式かつ常体で記載していきます。
技術的負債を抑制するための工夫とは？
- 設計段階で負債が溜まりやすいため、リファクタリング研修などの受講をしてもらうようにしている
- 必ずDesign Docを書くようにしており、開発Lane以外の人たちもレビューしやすいようなプロセスを整備している
技術的負債を解消するために経営層をどう説得したのか？
- 発表にあった通り例え話を使ったのだが、理解がある経営者だったというのは一つポイントとしてあったと思う
- なぜやらないといけないか？がまるで伝わらないということはあんまりない印象がある。ただ、結果論的な話を言うと出してほしい機能が経営者視点で一定速度で出ているならそんなに文句をいってくるみたいなことはない
- 実態としてはそんなにうまくいっているかというとそんなこともない気はしている。事業的に繁忙期なときは負債が溜まるような開発をしている。そのため、期に応じてどれくらい負債解消するのかのコミュニケーションを取ったりしている。ただしこのあたりはエンジニアリングマネージャーのコミュニケーション能力に依存している
今苦労している人がこれからうまく回していくためにどのようなことをやっていけるといいか？
- PLを経験したり事業の予算感を見られるようにしている
- 経営層を含むステークホルダーが何を考えているのか？というのを知るのが大切
技術的負債解消の取り組みに関してお互いに聞いてみたいことは？
- (ソフトウェア開発の速度にどこまで技術的負債が関与しているのか？の切り分けはどう判断しているのか？) 当然メンバーのスキル間というのも半分くらいはあると思っている。一方で半分は環境起因によるものもあるはずなので例えばパイプラインみたいなものを見ている
- (経営層の言語化はスタートラインだと思っていて、その後に本当に良くなったよ、の報告で工夫していることは何があるのか？) 明確に説明できることとできないことを切り分けしていて、説明できるパフォーマンスが良くなったことなどは、定量的に説明をしている
- (技術的負債の返却をするときの人数感は？) 4-8人のチームを2つ専門チームとしてアサインしている。バックログはわけていて、その専門チーム専用のバックログがある
Q&A
パネルディスカッションの後はQ&Aがありました。以下、テーマと回答を常体かつ一問一答形式かつ常体で記載していきます。
技術的負債解消を金額として算出した事例はあるか？
- ライブラリの更新とかは難しいが、機能的なところに関しては人月でどれくらい早くリリースできるようになったのか？を説明したりしている
- 数値をハックできるリスクが高いと思うので無理に定量化しないのも大切だと思っている
技術的負債の管理に工夫していることは？
ビルド環境の更新やコードの複雑度など直接顧客に対する価値にならないものの進め方を知りたい
- どういう顧客価値に繋いでいくのか？を説明する
- これも直接顧客の価値になるのでそのように説明する
セキュリティマネジメントにおけるリスク可視化と負債解消の事例はあるか？
- 損失被害額の算出をしておくのが大切
今まで経験した中で一番大きかった技術的負債は？
- 大規模検索基盤のパフォーマンス悪化
- ID基盤のリプレース(APIも100-200本あった)
会全体を通した感想
時間としては一部ではありましたが、経営陣に対して技術的負債をどのように説明するのか？という話から一歩先に進んだ話も多くされていたのが、非常によかったです。
イベントの中ではそこまで触れられていませんでしたが、前提として負債を一定定量化して常に可視化されているというところは当たり前にやられているし、その数値に関してもなるべく精度高く取れるように様々な工夫をされているんだなあというのが印象的でした。：
