🛠️
技術的負債に対する考え方とシェルフィーの努力
はじめに
大佐って誰？何者？とかは下の記事を読んでいただけるとわかってもらえるかもしれません。
今回初めて自分で記事を書くので、何について書こうか迷ったんですが・・
これは今後変わらない取り組みだろうというものを書きたいと思い、
今回は、シェルフィーが「技術的負債」についてどう向き合っているか、をまとめました。
そもそも技術的負債とはなにか
一言に技術的負債と言っても、会社によってそれが何を意味するかは様々ですし、私はそのどれもが正解だと思っています。
なぜなら会社ごとに状況や目指す姿が違うためです。もっと言えば会社のフェーズによっても変わると思います。
では私が現在弊社が抱えている技術的負債とは何かと聞かれたら
「プロダクトを取り巻く状況とズレているもの（仕様・コード）」
と、答えます。
ユーザーの状況や今後のプロダクトの方向性とズレた仕様やコードによって、
主に下記デメリットがあり、ユーザーへの価値提供の遅れや本質的な価値のズレにつながると考えています。
- 複雑性が上がり、想定外にバグが増える
- 想定外の箇所で時間がかかり、工数が増える
- より新しく効率的な取り組みがしづらい
- 上記に伴い、モチベーションが下がり生産性が落ちる
技術的負債によるトラブルを少なくする取り組み
シェルフィーでは、技術的負債の解消は会社全体として投資する対象と捉えています。
では具体的に何をしているのかというと、常時、開発チームの何割かの力を技術的負債の解消に使う、という体制をとっています。
この体制にしたきっかけは2020年に起きました。
当時は「年内にプロダクトを1機能特化から複数の機能を拡張できるように作り替える」というミッションの元、かなり無理をしてギリギリの所で開発をしていました。
無理をした結果、リリースは2週間延び、さらにリリース後も大きなバグが頻発しました。
事業戦略的に見てもプロダクトが足を引っ張っていて、控えめに言って大失敗と言う他ありません。
もちろん、各メンバーは自分の持てる力を最大限発揮してくれていましたし、持てるベストは尽くしたと考えています。
ただ、私も経営陣も、会社全体として自分たちの開発力を過信していたことが一番の原因であり、反省すべきポイントだと思っています。
追い打ちをかけるように、目の前の状況を乗り越えた後も大変でした。
プロジェクト中に溜め込んでしまった技術的負債が後の開発メンバーの認知負荷の高さや改修時の影響範囲の広さに繋がって、生産性が落ちてしまっていたからです。
当時、仕様検討や業務理解が甘いまま機能を作ってしまったり、言語仕様やフレームワークの理解が浅い状態でミドルウェア化をしてしまったりしていました。
この状況になって、「技術的負債に向き合うことは事業会社として、IT企業として死ぬほど大事だ」ということに気付かされました。
気付かされたというよりは「頭ではわかっていたが本当の意味で理解はしていなかった」と言う感覚になりました。
技術的負債が多い状況では、シンプルな実装でも複雑にせざるを得なかったり、別の機能を追加できない仕様になってしまったり、
事業を伸ばすための開発や、そもそも正しいものにリファクタリングするためにも多大な時間が必要になってしまいます。
実は2020年のプロジェクトが後半にさしかかったあたりから、プロダクト担当役員の石川は
「プロダクトチームのリソースの何割かを『守り』（事業に直接つながらない開発生産性の維持や向上）に使わないと、プロダクトと事業がズレていくのではないか？」
という危機感を持っていました。
プロダクトと事業がずれる事で本来短期間で開発ができるものが長期間かかってしまい、
業界の変化に追いつけなくなったり、その時間分本来できたはずの改善のサイクルを回すことができなくなってしまいます。
プロダクトチームとして、
「会社の成長・事業の成長のために最大のスピードと最大のバリューを出す」
というチームの存在意義に反してしまうことは本当に避けたい事態です。
さらに、この事態まで進んでしまったときはズレも大きく、無くすのは難しい上に時間もかかります。
実際に技術的負債を抱えてしまった今、
そんな状況を二度と作らないためにも、できるだけ小さいうちに常にズレを整える体制が必要だと考え、常に守りに「も」向き合っている状況を作っていくことをプロダクトチームの組織化戦略の一つに落とし込むことにしました。
石川と私で、技術的負債の増える速度と解決するために必要なチーム力の総量を計算し、チーム全体の3割の力を使えば解決の速度が上回るだろうと結論づけました。
それを未来の開発速度（＝事業成長速度）の低下を防ぐための戦略として経営会議で提案をしたのですが、CEOを含む経営メンバーからポジティブな反応を得られたときは、正直ホッとしたと同時に、理解あるメンバーに囲まれてよかったなと思いました。
今とこれから
「やりたいこと」を「高速」で「やれる」能力を、ソフトウェアの文脈で確保する。
これがプロダクトチームとして会社に貢献できることだと考えています。
チームの3割の力を守りにも割けるようになったことで、
実際に取り組んでいるメンバーだけではなく、機能開発や改善をしているメンバーも
日々の情報収集の感度が上がったり、日々の開発で技術的負債につながるようなものを見つけたら自然と議論して解決したり、
技術的負債は全員で向き合うものという意識がついてきたように見受けられるのも嬉しい気づきでした。
一方で、今もなお生産性の妨げとなっている箇所や機能もありますし、
リファクタリングをしたい箇所やそもそもの方針から定めたいところもまだまだ残っています。
プロダクト開発だけではなく、チームの枠組みや仕組み、ルールを整えるなどメンバーがストレートに進めるような環境を作ったり、
事業の成長と負債の予防・解消を「両軸」と呼べるくらいバランス良く強化していきたいと思っているので、気になったら是非お話ししましょう！ね！