技術的負債はどこにでもある
タイトルにあるように、
いくつかの開発チームと一緒に技術的負債を改善する開発や、それらに関する活動を行うことが多く
いろんな取り組みをしていく中で、よかったことがいくつかありました。
もちろん技術的負債を返すのは数ヶ月で終わるレベルのモノは多くなく、
何年から十数年もかかるものの方が多いはずですので、
すべて完了しているわけではないですが、その活動の中であくまで「今のところよさそう」というレベルのものです。
何番煎じかわからないくらいのものですが、
これを読んだ方が取り組んでいくにあたってヒントになればと思います。
普通の話しかありません。
会社全体で合意とSRE
これは当たり前ですが、念の為・・
以前もイベントでお話しさせてもらったりしましたが、
技術的負債は開発体験が悪くなり、モチベーションが上がらなくなるものでもあり、
そこから招く生産性の低下や色々なネガティブなものから、ビジネスに対してもコミットメントが著しく低下するようになります。
いろんな方面から見ても良いことにはつながらないことは明らかです。
しかし、会社や組織によっては技術そのものについてや、
エンジニアによる事業価値の最大化につながる基盤作りなどが
なかなか伝わらないこともあります。
これは諦めずにコミュニケーションをとってしっかり説明し、時間や予算をきちんと確保しなければならないです。
すでにサービス提供をしているシステムが対象になることが多く（サービス提供していないのに負債っていうのはないですね）
運用チームと負債返却などに当たるチームの二つが必要だったりします。
新しいサービスを提供したらもっと収益が伸びる！競合に！
色々あります。
しかし現状がその繰り返しの結果であることはきちんと理解してもらいます。
*もちろん予算確保などもあります
そしてビジネス側の観点でもしっかりと説明責任を果たすようにしていきます。
新しいサービスがなぜ必要なのか、収益を伸ばすのは新しい仕組みが必要なのか、
今あるものや、活動の仕方を変えるだけで最大化できないかどうか、
少ない時間で最大効果を発揮するものは何か、みたいなところも一緒に・・などなど
この辺りは書くと長くなるので、割愛します
うまくできない場合はみなさんの会社のCTOなどを巻き込んでみてください。
なぜすぐ開発にはいれなくなるのか、すぐできるのでは？
という定番の話などには、個人的にはAmazonなどで物を購入する生活で未開封が多くなった時に、
数年後に一発でみつけられるかどうかとか、家族の荷物混じってたらとか想像しやすい話を例えにすることが多いです。
まずは整理整頓などの大事さをしっかりと伝え、この辺りまでいくと会社としてはこうなっていきそうだ、
という将来の姿にいくためのものとして、あくまで事業の最大化・加速が目的であることをしっかりと。
こうした活動を実際にしてスタートしています。
（こういった支援もしております）
そして大事なのがSREの存在です。
お金や時間を使って進めていくものですから、今のサービスが実際にどうなっているかをしっかりと
理解できる状態にします。
これはサービスなどインタラクションの中で、どこがどうなっているのか、
それはこういった作り方をしてしまっているから、
などなどきちんと説明できるようにするためのものにもなり、
SLI/SLOのためでもあります。
憶測ではなくしっかりと数値化や可視化できる状態にします。
インフラレベルであれば色々なサービスがありますが、
サービスや体験としてどうなのかはツールの画面だけでは分かりません。
なのでしっかりSLI/SLOを文章化するなりが効果があります。
経営層も巻き込むのがよいことにつながることが多い印象でした。
作ったものはきちんと全体にも共有していきます。
SLIメニューはたくさんありますから、どれも参考にできるはずです。
この辺りの理解がそこまでない組織やチームの場合は、
Art of SLOsのワークショップを何十人も対象にして何回も実施しました。
意識作りと文化を作っていくのもやはり結局のところセットです。
この辺りを関係者でやることで、運用チームと負債返却チームなどできちんと連携をとり、
自動化して早くリリースできたけど、バグも増えて運用チーム辛いみたいな状態にならないように
しっかりやります。（ケースとして結構あります）
思想やコンセプトをしっかり・一緒に走る
負債返却となると、リプレイスなども多くなるので言語の選定だったりアーキテクチャ云々の話が必ずあります。
当たり前の話ですが、この時になぜそのアーキテクチャにするのかをしっかりと説明できるものにします。
これは手法が目的にならないように、
ドメインに対する理解がどのくらいあって、何を解決するために選んでいるか、などの観点でもあります。
この時に何かとてもガッチガチなものにしすぎないように気をつけています。
ある程度大きなものであったり、基盤システムのようなものは
しっかり作らないといけないため、ある程度堅くしなければなりません。
しかし大体方針を決めてから完成まで数年かかることが多く、
後になればなるほど当時考えたものがもう古い状態になります。
もちろん流行りに乗った方がいいものも多くありますし、
後知恵バイアスにならないように気をつけないといけないものでもありますが、
あくまである程度変わりゆくものだという前提で考えます。
ガッチガチなアーキテクチャを作り上げてしまうより、
思想やコンセプト・グランドデザインをしっかりと共有します。
リプレイスだ！こういうアーキテクチャでやろう、はもちろんみなさんやると思いますが、
チームの人が変わったりすれば、ガイドが目の前にあるコードだけになってしまいます。
もちろんドメインの理解や分析などができていない、
またはすっ飛ばしてしまっている場合は事前にしっかりと行います。
戦術パターンを実践するためではなく、全社できちんとコミュニケーションができるようにするため、
という温度感です。
そしてこの辺りの分析やモデリングは必ずワークショップを何回も実施します。
余談ですが、こうしたことを繰り返したことで文化的に良い方向になったところも多くあります。
エンジニアチーム以外とのコミュニケーションや、事業戦略にエンジニアが混ざったり色々変化が
これはまた違う機会に
むしろ戦術パターンをガッチガチに採用しないようにするのも選択肢としてやっています。
DOPなどであったり、ある程度モダンな技術に合わせたり、
ETL/ELT・イベントソーシングなどを利用することで切り離したりもすることも組み合わせるため、
全てに置いてガッチガチに採用するのは良いことではないこともあったからです。
話を戻して・・
思想やコンセプトは自分だけしかわからない状態にはせず、
かならず同じように理解して同じ景色がある程度見えるように意思疎通などを重ねます。
これは1on1とかもそうですし、色々やります。
コンセプトがないと色々破綻してしまうことが多かった・・
そしてチーム全体で共通認識を持ち、
入れ替わった時に同じ認識を持てるようにみんながしっかりコンセプトを話せる状態にします。
これは抽象度が高すぎないようにして、手法がガッチガチになりすぎない程よい抽象度に。
中長期すぎて想像しづらいものよりももうちょっと手前なものが認識しやすいです。
加えて実際に幾つかのリファクタリングであったり、リプレイスであったり、
インフラ設計やデータベースリファクタリング、
ソフトウェア以外のリプレイスなども一緒にやり、
目的に進むための技や知識を育てることをかならず取り組んでいます。
（チームによってはできないこともあります）
当たり前ですが言うだけの存在であればChatGPTだけで良いです
ドメイン知識と向かう方向を示すコンセプト、
そこに向かうための方法を実際に体験して、大変だけどやれそうだぞ！面白そう！
という状態をしっかりと作るように心がけます。
信頼関係づくりとかそういう観点でも良いと思います。（個人的には）
レビュー
色々やってみた中で一番しっくりきたのが、
コードレビューなどをGitHub上だけで終わらせず、
プロダクトやプロジェクトに関わるメンバーを集めてみんなでレビューをする、です。
圧迫面接のようなものではなく、あくまで平和的に実施することが条件ですが（当たり前）、
指摘というよりもコードの背景を教えてもらう、という趣旨です。
というのもコードだけであれば、何々っていう作り方の方が、とかこういう書き方の方が、
という話になりがちなんですが、
背景を知ることで「なるほど！」ということがたくさん知れたり、隠されたドメインの知識や
フローや組織の問題などが見えてきます。
技術的負債はそういったものにも原因がたくさんあり、
コードや実装の仕方だけではうまく付き合えないことがまぁまぁあります。
事態は複雑なのです。
他にも色々
他にもたくさんありますが、長すぎると読まなくなるのでこのあたりで。
負債返却のための技術的なアプローチは、
アクターモデルの導入がなんだかんだ非常に体験が良かったりしますので（規模によって合う合わないがありますが）
これはまたの機会に。
楽しく向き合いましょう！
