技術的負債とは
なんらかの問題が起こったとき、技術チームはしばしば妥協策を取ります。
しかし、実はこれは、最善の対応にかかるコストの支払いを先延ばしにしているにすぎません。
また、借金と同じように、技術的負債にも “利子” が発生します。
プロジェクトの成長に伴って、問題への対処はどんどん難しくなり、コストもかさんでいきます。
「技術的」とついていますが、普通の負債と変わらないんですね。
早く返済しないと利子が増えていき、どんどんと返す期間が伸びていく、と。
いっそ無かったことに、または見なかったことにしたいですね…。
技術的負債はなぜ生まれるのか
そんな技術的負債はなぜ生まれてしまうのでしょうか？
また、なぜ大きく膨れ上がってしまうのでしょうか？
1. 知識の喪失/外的環境の変化
同じプロジェクトにずっと同じ人が同じポジションで携わることは非常に稀です。
普通のプロジェクトですと、初期の立ち上げと、その後の運用とでメンバーが入れ替わることが多いです。
そのため、プロジェクトの知識を受け継ぐためにドキュメントを作成することがよくあります。
しかし、そのドキュメントも最初に作ってからメンテナンスがされなかったり、
ドメイン（業務）に着目して作られておらず、業務の変化に対応できない場合は資産ではなく負債になります。
また、伝言ゲームと同じで、最初の意味・意図は途中でどんどんと変わっていってしまいます。
最初の意味・意図が正常に受け継がれたとしても、周囲の環境が立ち上げ当初と変わっている場合もあります。
周囲の環境が変わってしまっては、たとえドキュメントが正しく受け継がれたとしても、当初の目的を果たせません。
このようにして知識が失われ、周囲の状況は変化し、システムがレガシーなものへとなっていきます。
2. 必要な変更の規模が大きくなる/変更に必要な時間は短くなる
最初から複雑化つ巨大な物を作るプロジェクトは稀です。
どんなサービスも、小さくスマートに始めることが多いです。
そこから、新機能の追加であったり、既存機能の改善という形でアップデートを繰り返していきます。
初めのうちはそこまで問題ではありません。少しの変更で新たな要望に応えていけます。
この時に、将来のことを考えて修正を行ったとします。
しかし、残念なことに、その時に考えた状況と、実際に迎えた状況は大きく異なることが多いです。
結果として、意図しない形で負債が発生します。
また、ビジネスはどんどん加速していくので、システムの変更もそのスピードについていくことが求められます。
ここでシステム改修に時間をかけないため「妥協策」を選ぶことがよくあることです。
結果、その「妥協策」がじわりじわりとシステム変更にとっての障害物、つまりは技術的負債となることがあります。
それなら「妥協策」を選ばなければいいではないか！と、思いますが、「ビジネス」はそれを許してくれません。
時間は有限です。また、大抵のチャンスは一瞬です。
妥協しなかった結果、良いものが出来上がったとしても、時を逸してしまっては元も子もありません。
私は技術的負債をよく「ジェンガ」に例えてイメージします。
限られた時間でピースを抜いて、積み上げる必要があるならば、取りやすいところ取ってしまいますよね。
結果として、後半になればなるほど、改修の難易度が上がっていくのです。
今、我々の目の前にある技術的負債とは、絶妙なバランスの上に成り立っているのです。
技術的負債と向き合う/理想を考える
さて、そんな技術的負債ですが、そのままにしておく訳にはいきません。
そのままにしていては、もう手が付けられません。
下手に触ったら崩れるのが目に見えています。
目の前にある複雑に積み上がったジェンガ（技術的負債）、、、どうしましょう？
その1. 見なかったことにして、危険を承知で突き進む
危険を承知で突き進んだ結果、それまで積み上げてきたものは崩れてしまうことでしょう。
その2. 最初からやり直す
リニューアルプロジェクトです。
20万人月の作業を1人でやる話 〜1万7千年生きたSE〜 なんてネタもありました。
※最終的には３５万人月になったようですが…
最初からやり直すとしても、要件を整理したりで時間を要するので簡単にはいきません。
溜まりに溜まった負債は、そう簡単になくなりません。
仮に最初からやり直すとした場合、潔く色々なものを捨て去るのが良い気がします。
その3. コツコツと積み上げ直していく
これは現時点で自分が考える理想案です。
具体的にはチームを2つに分けて取り組めたらいい、と考えています。
- とにかく速度優先！ガンガン進めるチーム（とはいえ、多少は考えて作る）
- 堅牢な土台を築いていくチーム（最初のチームが作ったものをリファクタしていく）
作った端からガッチリ固めていけば堅牢なものができあるのでは！と思っています。
スピードも落とさないのでビジネスにもついていけるはず！
ただ、この案にも欠点があります。
まずコストですね。単純計算で2倍のコストが発生します。
チーム2つ分の稼働費用が発生します。
また、後から追いかけるチームが先をいくチームに追いつけなくなる可能性もあります。
追いつけなかった場合、先をいくチームはスピード優先で作ったものに更なる改修を行うため
意図せずに負債が発生してしまいます。
まとめ/所感
技術的負債に立ち向かう道のりは、長く険しいですね。
夏休みの宿題のように後回しにはできないので、日々コツコツと向き合うのが理想ではあります。
作ったその時は良くても、後々振り返った時には絶対にレガシーなものになってしまうのはよくあることです。
覚悟を決めて、日々、自分が作ったものをキレイにしていきたい、と頭では思うのですがね…
現実とは厳しいものです。
残念ながら今回の考察では、どのように立ち向かうのが良いのか答えを出せませんでした。
これからも日々、考察を重ねて参りたいと思います。