🚀

技術的負債のケーススタディを考えてみる

2023/06/13に公開

面白そうだったので考えてみる。

経営陣との方向性の調整

まず４つのDevOps指標(DORAメトリクス)やMTTx、広木大地氏のd/d/d指標などの開発指標をもとに相対的に開発チームのパフォーマンスが低いことを経営陣に説明し、課題感を共有する。
その上で今の状況踏まえどう対応するのが適切か話し合い、合意の取れた内容、経営状況や自分に与えられた権限を踏まえて方向性を決める。

特にベンチャーの場合は社長の考えが重要で、そこの合意形成が取れない限り難しい。
状況から逆説的に考えるに、「リファクタリングなんかやったら機能開発が遅れる〜」が社長含めた会社全体の考えの可能性が高い。
もしかしたら会社的に危機的状況にあり、実際に目先の機能開発が急務であるかもしれない。
「リファクタリングをすればすぐに劇的に効果が出る」とは言い難いため、中長期的視点でどの程度コストをかける余地があるのかしっかり合意形成する。

逆に経営状況にリプレースコストを担保する余裕があり中長期的視点で改善したいというのであれば、リプレースするのが一番手っ取り早い。
その場合は「今と全く同じ機能を担保はできない」って前提は念を押して共有した上で合意を取りたい。

完全なリプレースでなくとも部分的に切り離してリプレースする、新規機能から新しい基盤で作るなど方向性は様々ある。

ただ今回のケーススタディの場合はメンバーの設計意識が低いため、根本的な文化的なところが改善されない限り作り直したとしても同じことの繰り返しになりそうだし、中途半端なリプレースはむしろカオスになりそうではある。

変更エラー率の解消

経営状況的にリプレースはできないが、ある程度自由に権限与えるからなんとかしてくれってケースで考える。

一気に全部やるのは厳しいかつ文化を一気に劇的に変えるのはハレーションにつながりやすいため、まずは変更エラー率の改善にフォーカスを当てる。

ここはユーザ影響が大きい箇所なので、真っ先に解消したい。
さらに非エンジニア含め誰もが効果を体感しやすいため、ここで効果が得られれば信頼も得られ今後の動きも取りやすくなる。
かつここを意識することで「この書き方はエラーにつながりやすいから良くないよね」という視点がメンバーのコード品質への意識につながることも期待できる。

KPIに変更エラー率を加える

自分がひたすら頑張ったりDevOpsチームを立ち上げてそこに変更エラー率を追ってもらう方向もあるが、中長期的視点で考えると開発メンバー全員に意識が芽生えないといけない。
特に誰かが勝手に直してしまい実装者本人やレビューワーにフィードバックがいかないケースでは、永遠に状況が改善されない。
犯人探しをし叩くような空気感を醸成するべきではないが、とはいえある程度関係者が責任を負う構造にするべきだ。
なので各チームのKPIに変更エラー率を加え、自チームの変更エラー率の改善を目標に自律的に改善を進めてもらうようにする。
可能であればメンバーの人事評価指標にチームの変更エラー率も加える。

エラー発生時は障害報を書いてもらい、再発防止策の提案を必須化する。
具体的な方針は自律的に進めてくれるメンバーであれば細かく干渉しないで各チームに任せるが、まずはE2EテストやControllerレベルのテストを揃えていく方向性が良いと思われる。
テスティングピラミッドとは逆になるが、１つのテストでより広い範囲をカバーできた方が費用対効果は大きいため、ユニットテストを充実化するより効果を感じやすいからだ。
さらに今後リファクタリングに繋げいく上で、今の設計に合わせてユニットテストを充実させても多くは作り直しになるだろう。
まずは素早く広く包み込んだテストでコード全体を網羅し、テストが通れば安心という状況につなげたい。

また開発メンバーの人数も多いのでおそらく複数チームに分かれて開発していると思われる。
そのためチームごとの変更エラー率を可視化し、優秀なチームを表彰したり、定期的にチーム間でどのような取り組みをしたか共有する場を設けると良いかもしれない。

その間に自分はE2E基盤の構築やCI/CDフローの改善など、全体に影響のある基盤部分の改修に力を入れることになりそうだ。

設計に対しての意識を上げる

メンバーの技術に対する意識の低さが一番の問題なので、勉強会や輪読会などを開催し意識レベルで改善していく。
変更エラー率に対する意識が上がっていれば不具合の発生しづらいコードの書き方を考えることに繋がり、そこから神クラス、ミュータブルなどの問題点に自主的に気づく人も増えていることに期待したい。

また事前にテストコードが充実していればバグを恐れずに変更をできるようになるため、リファクタリングのハードルも下がっているはずだ。

ある程度全体として文化が醸成できたら、DevOpsチームを立ち上げてあとはそこに４つのDevOps指標の改善にひたすら取り組んでもらうのも良いかもしれない。

自分の立ち回りは一番足りない部分を埋める動きになりそう。
愚直にリファクタリングを進めるなり、ひたすらコードレビューするなり、機能開発に加わるなり、メンバーが自主的に改善を進めてくれるようになれば自由に立ち回ることができるようになっているはずだ。

おわりに

実際のところ「状況による」「話してみないとわからない」ってのが正解ではありますが、それだと思考実験にもならないのである程度状況決めうちで書きました。

一番の問題は『絶対的に状況が悪いこと』ではなく『課題が放置され改善が進まない文化』なので、それが何に起因するのかを考えるのが一番に思います。
たとえば他責的な文化であれば弱みを見せることができず今の状況の肯定を繰り返すことになりますし、エンジニアが信頼関係を築けていないと「やりたいことする口実を探してる！」となるかもしれません。
このケーススタディに対して「人を入れ替える」という意見も何個か見ました。
実際急激に文化を変える手っ取り早い手段だしそれで成功したケースも過去見たことあるので、選択肢として考えても良いのかもしれません。