雑に書いた。
こちら（通称：わるだくみプロジェクト😈）の続き。機能廃止・技術負債の解消を真面目に考えて組織に接続した話。
とある事情で2月は手が空いていたので、1つのテーマに集中して想いを巡らせていた。そのテーマが「技術負債の解消」。正直タフだったので、もうできるだけやりたいくない笑
それでも将来的に役立つかもしれないのでメモとして書き残す。参考文献が一番参考になるかもしれない。先人たちがインターネットの海に残してくれたものに感謝するばかり。
なんで「機能廃止・技術負債の解消」のテーマ？
1ヶ月弱で完結するテーマで組織的にレバレッジが効きそうな活動だと判断して、上司に打診した
組織変更の間＆プロダクト開発チームは直近の開発内容が積まれている状態だった
別件でちょうど機能廃止の話が進んでおり、追加で見直しをして廃止できるものはないか？という機運の高まりがあった
やったこと
意思決定者（上司）と1ヶ月のスコープをすり合わせ
機能廃止の目的と技術的負債という概念の目線合わせ
廃止候補の機能リスト作成と定期的な運用整理＆起案、引き継ぎまでをスコープとして、開発チームがこの1ヶ月でチケットとしてスプリントに載せることはスコープ外とした
該当組織に起案＆後続の運用を引き継ぐスケジュールを明確化
廃止できそうな機能・廃止あるいは仕様変更ができると嬉しい機能をリストアップ
ビジネス部門にもプロダクト開発部門にも幅広く問いかけた。自分のtweetチャンネルで（）
運用が軽くなるだけでもメリットがあるので、廃止ありきではなく、仕様変更も選択肢に含めて検討した
リストアップしたものを観点ごとに点数付けして優先度を3グループに整理
①影響する顧客の規模
②影響の大きさ（顧客契約、開発生産性が上がる、運用コストが減る、QAコストが下げられる、インフラコストが下がるなどの総合評価）
③不確実性の低さ（確実に効果が出るといえるものは不確実性が低い）
④廃止するための労力（ざっくり規模見積もり）
優先度はインパクトが大きいあるいは即消すためのアクションができるもの(★★★)、少し検討が必要なもの(★★)、じっくり検討が必要なもの(★)といった具合い
RICEを参考にしつつ、なるべく比較できるように数字に変換した。利用規模はSQL書いたり、インフラコストを試算してもらったり
リストアップした機能ごとに「なぜ今消せない状態になっているのか、何が課題なのか？」を抽出して構造を整理
ここまでを諸々ドキュメンテーションしてSlackで広く周知
みんなでオーソライズする必要がなく、Just Doなアクションは適宜ステークホルダーと連携しながら廃止に向けて動いた
影響が軽微と判断していくつかの機能は提供を止めた
現状の課題感をもとに想定の運用を整理して運用を持つ横断チームの定例にて起案
大きく分けて3つ。詳細は流石に省くので、興味がある人はお話ししましょう
[A] 開発時に価値の小さい機能を作らないように検証を計画すること
[B] 継続投資するか撤退するかの基準を事前に設定して機械的に検証すること
[C] 継続投資した機能も時間と共に負債になる可能性があるので定期的に見直す会議体と役割の設定
起案のタイミングで質疑してステークホルダー間で認識そろえる
見直しをする予定の機能は見直し担当チームを割り振り、バックログにチケットとして積んでもらうこととした。締切ナシ、ただし四半期に一度は状況をトラッキングしていく運用でスタートさせる
見直し担当チームのリーダーの方々とは個別に話させてもらって、整理した情報のインプット・想定の進め方の共有をして引き継ぎ
思ったより色々やっていた。検討そのものはいろんな人の手を借りながら勧められたのでそんなにタフではなかった。すぐ助けてくれるみなさんに感謝するばかりです🙏
やってみてどうだったか
▼ そこそこうまくいったこと
職能横断の課題を推進者を立てて、推進することができた
組織横断の課題を横断課題としてissue raiseして捌けた
本質的にはコア価値を顧客に届けることに集中すべきで、そうでない営みがあるのは仕方ないが振り返りできていないのでは？というissue raiseになった。そこに対していくつか例示しながらアクションの方向性が示せた（多分）
検討にとどまらず、いくつかの機能は廃止／提供停止に向けてアクションできた
つまり、アクションできさえすれば提供を止められる物がそのまま残っていることに気づけた
ミドル〜シニア × 幅広い職種の人が賛同して後押ししてくれた
エンジニア、アーキテクト、SRE、QA、Sales、CSなど多くの観点が必要になる検討だったので、これは本当に力強かった
整理した廃止リストに対して担当チームを割り振ってバックログに積むところまで業務接続できた
これは上司の後押しが大きかったです。たいへん感謝します🙏
運用含めた設計ができた。役割を分けて検討の推進者と意思決定者を分けるのは機能しそうだと思えた
負債を完済することはできないという前提の目線合わせができた（多分）
▼ 難しかった
これだけ多様な観点が入るので、優先度付けが難しかった
RICEをベースに少しこねた指標を作ったが、直感のスコアリングの方がまだ機能していると思った。これは検討足りない
そもそもスポットで一覧に並べて優先度をつけるものではなくて、作るときに価値が届いているかを検証して、基準に満たなければ消すという判断をできる開発フローがある方が望ましいと、あらためて強く感じた
表面的な課題解決をしてしまっている機能がいくつかあって、顧客の運用に組み込まれているものがあり単純な機能廃止は難しいとわかった
仕様変更をして顧客のやりたい運用ができるようになれば迂回できると考えたが、個々の機能別に検討する時間はなかった
▼ 反省点
自分のtweetチャンネルで検討のやり取りをしたのは反省〜〜〜
いくつかの課題は根っこにある課題が一緒に思えたので、親課題を解くような探索と要件整理までいけるとよかったな〜〜〜
判断基準を明確にする検証計画の型化（企画書のフォーマットのアップデート）までいければよりよかったな〜〜〜
検討スコープがプラットフォームチームも含めた開発組織全体の話なのか、ストリームアラインドチームの話なのか、主語を明確にした上でドキュメントを書き始められるとよかったかもなあ〜〜〜
反省点はありつつも、少しは開発組織の運営を改善できたのではないかと思うのでヨシ！負債があるのはしょうがないけど、消せる組織の方が健全ですよね。
おわりに
こちらの名言と共に、結びとさせてもらいます。