「顧客提供価値を高めるための技術的負債への向き合い方〜Toriさんmotemenさんから学ぶ〜」に参加してきました
こちらのイベントに参加してきましたので、感想を記載します。
カミナシの「原トリさん」とはてなの「大坪さん」から自社の技術的負債に対してどのように取り組んだかの講演をいただきました。
技術負債としての向き合い方/最初に向き合ったもの
・カミナシでは身の丈に合った構造になっていなかった
‐ Clean Archtectureを意識して作られたと思われるが、身の丈に
合っていなくて、認知負荷が高い構造）
- ニセ OpenAPI YAML(YAMLはあったがクライアントSDKを
自動生成できてなくて不整合の状態）
- スケールアップしかできないバッチ処理
・はてなでは最初、自社サービス中心で設計されたインフラ基盤で、サービス多角化しづらい環境だった。
・なぜ技術的負債に向き合う意思決定ができたか？(逆に、CTOとして参入するまで判断できなかったのはなぜか？
⇒内部の分断(知識分断が多い)、外圧、状況が色々重なっての意思決定だった。
⇒技術的負債に対して取り組まねばと声は上がるものの、バックログを止めてこれらの対応をするという意志決定をする人がいなくて、判断ができない（対応する上での説明をするスキルが必要)
また問題は認識していても対応のアイデアを持ったスキルの人がいないと判断難しいので、組織としてのスキルレベルを上げるようなロングタームでの対応も必要
・システムのオーナーシップの境界線の引き直しがポイント。ただし、これが超大変。説明責任が必要(アカウンタビリティ)
負債への対応・苦労したこと
・スプリントの50%を負債返済に充てようね(5:5)は成立しなかった。
※実際は4くらいは問い合わせ対応だったので、最終的に負債返済に5%程度しか充てられなかった
⇒３スプリントはPO対応、１スプリントはCTOがステークホルダーとして内部品質だけを改善するようにして回している。
・終わりが見えづらく、疲弊してしまい、方針は良くても実行・計画が難しい。
⇒事業側のメンバーをしっかり巻き込んで仕切り直ししている。
・負債へ対応するチームへのモチベートをどうするか？
⇒やること自体の価値は感じるが、中間ゴール等の段階設計が重要。たとえば、対応するチケットについて１日で終わるようなタスクにしっかり分解するでも進んでいる形が見える
意思決定のポイント/アプローチで大事なポイント
・事業形態の変化のポイントでは技術的な方向性の判断が必要
（ただ、あとから考えると変化のポイントわかるが中の真っただ中にいると難しい)
・トレードオフを発見し、言語化して選択できるスキルが重要。ビジネスのクリティカルなトレードオフを言語化し素早く意志を持って決定する。
・優先順位のWhyをしっかり共有する
・技術的負債の改善対応をプロジェクト化しないよう、普段の開発で放置しない。（システムを可愛がっている状態にする！）
感想
・技術的負債への対応は言うは易し行うは難しで、本当に難しいとCTOさんの話を聴いて感じました。新しいシステムでの負債返済でもああなので、スパゲティー化した重厚長大なシステムは、もう見ないようにするしかないのか・・・・。。。
・トレードオフをしっかり言語化して、意思を持って選択していくという事は非常に心に響きました。
ありがとうございました。