今さら技術的負債を再考した理由
以前、海外チームのエンジニアに技術的負債について説明する機会があったのですが、ニュアンスで理解していたり点と点では理解しているものの
「じゃあ技術的負債って一言で何よ？」
と考えた時に全く思い浮かべる事が出来なかったのと
「ネットの知識の受け売りじゃなくて自分なりの技術的負債の理解を腹落ちさせておくべきだろう」
と考えて、個人的な経験則に基づく技術的負債をまとめてみました。
技術的負債とは何なのか？
提唱者 ウォード・カニンガムさんのお言葉
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる
Wikipedia 技術的負債より引用
https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5
個人的な体験に基づく解釈
こういう技術的負債の説明記事とかスライドを何度と無く見て、何となくは理解出来てるのですが 「自分の言葉で表すならどうする？」 と考えた時に以下のような言い回しになりました。
アーキテクチャ及びソフトウェアの安定性と品質を担保出来ない何らかの事情があり開発を進めた場合において、その後発生する本来望まれないシステムの状態を指す。
個人的な解釈としては本来望まれないシステムの状態これが技術的負債にあたるという事で脳内は落ち着きました。
アーキテクチャとあえて入れているのですが、DevOpsが進み各クラウドサービスと密接に紐づくコードを書くケースも増えていたりします。 さらにコンテナアーキテクチャやInfrastructure as Codeの普及によってコードを書くという行為がアプリなのか？インフラなのか？の垣根がもはや無くなってきています。
開発チームによってはフルスタックにコードを書きつつクラウドでインフラを構築しているケースもあったりするので
もはや技術的負債はコードだけでなくアーキテクチャも入るのでは？
と個人的に思っております。
また、ここで指すアーキテクチャはインフラ構築だけでなくて、例えばビルドのパイプラインを構築するタイミングで本当はコッチのほうが良いんだけど、まあ時間無いしいいか。と後回しにしてしまったり。
- 開発→リリース→運用
この一連のサイクルのどこにでも技術的負債はあると思っています。
じゃあ本来望まれないシステムの状態とは？
伝家の宝刀運用でカバー
エンジニアであれば一度や二度、いやそれ以上見たことあるかもしれませんが、運用でカバーが必要になっているシステムも技術的負債にはいるのではないか？と思っています。
セキュリティ面に問題がある
本来一番雑に扱ってしまってはいけないのですが、どうしてもプロダクトの開発優先と言うか「動くもの」優先で開発した場合に後回しにしてしまったり。
パフォーマンスの低下を招くコードがある状態
大丈夫かなーと分かっていてもとりあえずリリースから数ヶ月は持ちこたえそうだしと思って投入！
せめてもの優しさでコメントアウトしてあったり。
冗長化、スケーラビリティが難しい状態
アーキテクチャ・インフラ寄りの負債だと思いますが、負荷上がってきたし並列でサーバーもっと増やそうか！とした時に「いや、実は・・」的なアレです。
メンテナンス性や拡張性に欠ける状態
コードでもインフラでも可能性あると思いますが、何か改善とか手を入れようとした時に「ああ、面倒だな」と感じてしまうあの状態です。
不要なコードが散見される
恐らく開発時に試行錯誤して作ったけど採用しなかったメソッドとかデバッグコードとか
動いているけど警告の出ているコード
動くけどLintで警告出てたり、ビルド時に警告出ていたりするコード
トレンドから遅れた技術を使い続けている状態
サポート切れているバージョンのOSや言語使っていたり
どうして起きるのか？
アーキテクチャ及びソフトウェアの安定性と品質を担保出来ない何らかの事情が発生する場合に起きる
何らかの事情って具体的にどんな場面か？
エンジニアの経験不足
先輩エンジニアとかテックリードあたりが助けてあげましょう。 コードレビューだったり、設計の経験が浅い場合は設計レビューしたりですかね。
プロジェクトマネージャーの経験不足
これも仕方ないですよね。 先輩PMとか経験あるエンジニアあたりが助けてあげましょう。 なぜこのタイミングでこんな要求ぶっ込むのが危険なのか？ コレ入れるとこの先こういうリスクあるよとか教えてあげましょう。
品質より開発速度を再重視した場合
あえて負債を負う戦略とも言えるかもしれません。 負債が起こる事を理解し、返済の必要性を理解した上でリリースなどを優先する場合です。 後述のプロジェクトマネジメントが最適に行われていないとは区別したいと思います。
プロジェクトマネジメントが最適に行われていない
めちゃくちゃなスケジューリングだったり、到底無理な差し込みだったり、信じられない仕様変更だったり。 まさに枚挙にいとまがありませんという感じです。
パワーバランスPMとエンジニア、チームリーダーだったりのパワーバランスによるところも実際あるかと思います。 組織が生み出す技術的負債も実際にはあるとは思いますが話すと長くなるのでまた別に機会に
十分な品質に仕上げるだけの適切な対価が支払われていない
社員にしろ外注にしろ安い対価では頑張れないです。 良いものを作りには相応のお金が必要です。
十分な品質に仕上げるだけの人員配置が行われていない
単純に人足りないよ！という状態です。 当然コードも設計もインフラも何もかも品質は落ちてしまいます。
何らか見えざる力が働いた時
社長、役員、クライアントなどなど何らかの強い影響力によって本来あるべきの神聖なる開発プロジェクトが破壊されるあの感じです。
技術的負債が増えるとどうなるのか？
- さらなる負債の発生を誘発する
- 不具合を誘発する
- 開発速度の低下
- 属人的な開発や運用の増加
- メンバーのモチベーション低下と離脱 などなど 結果的に開発コストが高くなり、開発時間も多くなってしまう
技術的負債は起こしたらいけないのか？
そんな事は無いと思います！起きます！確実に起きます！
例えば
- 時間もたくさんあって
- 予算も潤沢にあって
- メンバーもたくさん居て
- エンジニア全員があうんの呼吸で開発出来て
- 優秀なプロジェクトマネージャーが居て
- 経営層もステークホルダーも全員がエンジニアリングを理解していて
そんな桃源郷みたいなプロジェクトはあるわけないんです！！
なので発生するのが普通です。
一番大事なのは発生は良いけど放置したり見てみぬふりをする事です。
うまいこと付き合っていくのが良いアクションだと思います。
まとめ
技術的負債は文字の通り負債とか借金に例えられていますが、個人的にはもっとカジュアルなものだと思っています。
負債・借金だと何か特別感あると言うか重い気がしていて
風邪みたいなものだと思ってます。 みんな風邪ひくようにシステムも確実に風邪（技術的負債）が発生します。
大小あれど日常的に風邪はひくもので都度きちんと向き合って(病院に行って)リカバリ(薬飲んだり休んだり)すれば良いのでは無いでしょうか？ そして、またどっかのタイミングで確実に風邪はひきます。
この先の技術的負債とどう付き合っていくのか？についてはまた別の機会にでもまとめたいと思います。