今回は御縁があってKDDIアジャイル開発センター（KAG）さんとMIXIの合同イベントに登壇いたしました。
今回のテーマが「SRE観点での技術負債」ということで、私の方からは以下のようなお話をさせていただきました。
このブログではいつものようにライナーノーツとしてお伝えしきれなかったところなどを書いていこうかなと思います。
技術負債とは？
まず、このイベントのテーマである「SRE観点での技術負債」ってなんだろう？と引っかかったので、ここをブレイクダウンしていかないと自分の中でブレてしまいそうだなと思いましたので、技術的負債の定義を経てSRE観点の技術的負債の定義からさせていただきました。
技術的負債については色々な説があると思いますが、なるたけ新し目の説を扱おうということで（古いと時流と合わない可能性が高い）、「Defining, Measuring, and Managing Technical Debt」というGoogleで研究職をやっているCiera Jaspan, Collin Greenの両氏の論文を論拠の土台とさせていただきました。
スライドでも述べましたが、この論文は技術的負債のカテゴライズ・測定・管理について研究した結果であり、これを基にGoogle社内で数年に渡って改善を行った結果として技術的負債は減ったようです。（とはいえ定量的な数値などが提示されていないので根拠が薄い）
さて、ではその技術的負債の種別とはどのようなものがあるのでしょうか？Google社内で専門家に対してのヒアリングを行った結果、以下の10個のカテゴリが判明しました。一覧の説明を少し手直ししましたので、ここで改めて掲示しておきます。
- 移行が必要なモノ、または進行中のモノ：スケーリング・依存関係・非推奨などが要因で移行をしなければいけないが、していない or 進行中
- ドキュメント：ドキュメントが足りていない、完全ではない、見つけにくい
- テスト：テストが足りていない、脆弱である（Flaky Testだったり）
- コード品質：適切な設計がされていない、プロトタイプ/デモ版のままである
- 廃止・放棄されたコード：廃止されたり、利用されていないデッドコードが残っている
- コードの劣化：時間経過とともにリファクタリングが必要になったコードが残っている
- チームに必要な専門知識が不足：離職・移動によって人材が不足していたりチーム内で知識を共有する場がない
- 依存関係：依存先の不安定さ、変化に対する耐性がない、または管理不足である
- 移行の失敗か、放棄：2つのバージョンが並列で動いている
- リリースプロセス：リリースプロセスやリリースの監視に対して更新、移行、保守をしていない
この10個のカテゴリがGoogle社内でのインシデント発生要因になった頻度順に並んでいます。つまり、移行をサボっていたことによるインシデントが一番多いということですね。
このように大別された技術的負債を測定して、管理しましょうということが書かれているのですが、そちらの内容の詳しいことは論文をご参照ください。
専門知識の不足については、「プロジェクトコードでTODOコメントが存在することはコード劣化の可能性があり、専門知識が不足している可能性もある」と書かれてもいて、コード劣化と密接な関係にあるというカテゴリは別だが因果関係が近しいパターンもあるようです。
この前提を基に、SRE文脈に変換したのがスライド上に載せてある一覧ですね。
ここで大事なことは「複数の視点を持ちましょう」ということです。プロダクトコードについてのみではなく、自分たちが作ったプラットフォーム・ツール・仕組みについても技術的負債の意識を持たなければいけません。
口頭で喋ったことの補遺
ドキュメントの項で説明したのですが、GitHubのCopilot for Docsは期待していたのですが去年の12月に出たプレビュー終了通知には何の説明もなく非常に残念ですね・・・
GitHub Next • Technical Preview Sunsets
こういったAIを利用したドキュメント管理には期待をしているので、ベスト版がどなたかによって確立された際には徹底的に真似していきたい所存です。
コード品質ではオライリーのソフトウェアアーキテクチャメトリクスの話を少し挟みました。
こうったコード品質メトリクスを静的解析し、結果をPRに貼り付けていけば品質向上の意識付けになるんじゃないかな〜というお話でした。
おわり
今回、登壇させていただきましたが他の登壇者の方々の発表内容の方が数段面白く、正直自分の実力不足を感じました。
もう少し、定義の部分はサッと終わらせて個々にフォーカスした方が面白かったのかな〜とか色々考えましたが、反省は次の登壇に活かしたいと思います💪
