システム開発に関するお仕事をしていれば、よく耳にするであろう「技術的負債」という言葉。
色々と認識が揃いにくいことや、可燃性があることで有名です。
そこで、認識の揃いにくさの理由、話題が可燃性であることの理由を踏まえた上で、よりよい名前はないだろうかという話につなげたいと思います。
なぜ「技術的負債」の認識はずれやすいか？
技術的負債は Ward Cunningham が作ったメタファです。
何らかの業務上の利益を得るために一時的に好ましくない設計を 意図的に 選び、それを負債として考えます。
負債には利子があり、それはどんどん膨らんでいくのでいつか返済する必要があります。
こういった内容を開発者ではない経営者などのステークホルダーに伝えるための表現として存在する言葉です。
その上で、さらに議論は進み 意図的ではない 設計上の不備かそうではないかの区別には意味がないのではないか、という説がでてきます。
あくまでステークホルダーへの説明用の概念なら純粋に設計不備が積み重なると、どこかで解消しないと利子がどんどん膨らみますよ、ということを伝えることが一番大切だからです。
詳しくは以下を参照ください。
ここで、「技術的負債」という言葉を用いる人には大きく分けて 3 つのパターンが考えられます。
- Ward Cunningham が初期に提唱した「意図した設計判断」のみを技術的負債と考えることに賛同する人
- Martin Fowler が上記の記事で語るように「設計不備」における意図の有無とは関係なく技術的負債と考えることに賛同する人
- どちらの説とも関係なく単に「不備のある設計のコードはすべて技術的負債」と考えている人
2 と 3 は結果的に同じ意見なのですが、 3 の人にとって元々の起源の「意図」の話や、技術的負債という言葉がステークホルダーへの説明用として存在していることは特に考慮されていないことがある。
なぜ「技術的負債」は可燃性が高いか？
技術的負債の可燃性の高さは以下のような経験によるのではないか、と想像しています。
- 他者が作成した好ましくない設計によるコードの後始末をした
- 好ましくない設計をする人と同じコードを触らざるを得ず、ストレスが溜まった
- 好ましくない設計をした人による影響で障害対応に頭を悩ませた
こんなかんじの人が思い出すのは主に「意図していない設計の不備」です。
そしてその解決策を考えると、
- その場に優れた開発者しか採用されていない
- 優れた開発者を育てる体制があり長期的には優れた開発者しかいない状態になりやすい
などの状態を作り出す必要がありそうで、それはかなり難易度が高そうです。
結果として、設計上の不備を多く生み出す開発者に悩まされるが、解決もされず不満を抱え続けている方を刺激するのが「技術的負債」という言葉になるのでは、と考えます。
技術的負債に変わる名前
こういった経緯から、技術的負債という言葉に対して思い浮かべる内容は揃いにくく、燃えやすいという状態になります。
では、新しい定義と名前を割り当ててそれが普及すればいいのではないかと考えたわけです。
ただ、たぶん私は業界のデファクトとなるような名前を広めるような影響力も説得力もないので、どなたかそのあたりに強い方の発言を誘発するぐらいの情報を出せればいいかなと思っています。
ということで自分なりに考えてみました。
定義
必要なのはステークホルダーに説明するために使える用語であること。
開発者の間でも無用な誤認が発生しないこと。
設計の不備が積み重なると保守や追加の開発にかかるコストがどんどんと積み上がっていくということが、開発者以外にも伝わることです。
意図的であるかどうかの部分はどちらかというと重要事項ではないと捉えます。
そのあたりはちょうど最近公開された t-wada さんのスライドがわかりやすいです。
それを踏まえ、この概念の定義は
プログラムの設計不備が積み重なると、バグの発生率をあげる。
また、その複雑性から追加の機能開発の速度を遅らせる。
設計不備は、未熟・不注意・状況を加味した意図したものなど様々な要因で発生する。
結果としてこの設計不備の蓄積によりプロダクトが生み出すビジネスの価値がバグにより下がりやすく、新たな価値を作り出すためにかかる時間も伸びる。
そのため、こういった設計不備の存在は常に把握可能にし、その上で継続的に解消していく必要がある。
とします。
技術的虫歯
技術的虫歯 というのを考えました。
- 設計不備は虫歯の餌となる → バグの増加
- 虫歯が増えると食事をしにくくなる → 開発速度の低下
- 悪化し続けると歯そのものがだめになる → プロダクトの破綻
- 悪くなりすぎる前に治療が必要 → リファクタリングの必要性
- 最初から適切に手入れしていると健全 → 採用、教育、モブプロなどの重要性
きっと、他の人がもっといい名前を考えてくれる人がでるでしょう（泣き言）
まとめ
技術的虫歯を作らないためにどうすればいいかというと、メインは採用と教育ということになりそうです。
採用に関して、理想は最初から一定品質以上のプログラムを開発できる開発者ばかりになることです。
次点として、そういった開発者になるべく学習を継続してプログラミングの腕をあげていく意欲がある人を揃えることです。
エンジニア採用激化の時代になかなか難易度が高いですが、エンジニアに訴求する EVP をいかに作り込むかが重要になりそうです。
教育に関しては「学習を継続してプログラミングの腕をあげていく意欲がある人」に対して
- ペアプロ、モブプロなどによる技術面での成長機会の提供
- 学習支援（書籍購入支援、イベント参加支援、社内勉強会 etc）
- t-wada さんのような方を召喚する
などを行う感じでしょう。
※循環的複雑度の継続的測定とかの話もあると思いますが、ここでは割愛。
いくら問題を検出しても開発者が腕を上げる意欲を持っていなかったら解消されないので
