技術負債は積極的に借りなさい！技術負債は計画的に返しなさい！
エンジニアが経営者に「技術負債」という言葉で反論してきた時は、銀行からの借入金と同じように下記のように考えてください。
技術負債は積極的に借りなさい！
技術負債は計画的に返しなさい！
技術負債への正しい理解は『積極的に技術負債を借りて事業を前へ進めながら、事業が前に進んだら計画的に技術負債を返していく』ことです。
仮説の検証度合いに応じた適切な設計をしなさい！
市場や顧客や事業の理解の深さに応じて適切な設計をすべきです。新規事業がアイディアベースの段階で、市場や顧客への理解が空想レベルなら、ノーコードなどを使いプロトタイプを作りテストマーケをすることで、理解をキチンとすすめることが重要です。
技術負債の提唱者の説明を正しく読み解く
重要なポイントを抜粋していきます。
借入をすれば物事をより早く前に進めることができる
そして借入金には利子が発生します。
返済し終えるまでは利子を払い続ける
そしてここからが大事なポイントです。
お金を借りるのは良いアイデアだと、つまりソフトウェアを急いで世に出し、それによって学びを得るのは良いアイデア
ソフトウェアについての学びを深めるにつれてリファクタリングを行うことで、得られた経験をプログラムに反映
ソフトウェア開発の難しさは「プログラミングの難しさ」ではありません。ソフトウェアの対象である「市場・顧客・事業」を正確に理解することが難しいのです。
プログラムは書かれたとおりにしか動きません。状況や意図を察知して忖度して動いてくれることはありません。
つまり市場・顧客・事業を正確に理解できないから、適切なプログラムを書くことが難しいのです。
そしてプログラムを書きソフトウェアを事業に提供し顧客に利用していただき市場で評価されることで、市場・顧客・事業への理解が深まります。
現実への理解が深まる中で、ソフトウェアの設計と現実の食い違いが生じることを、技術負債と呼びます。
仕事のできないエンジニアの雑なコードは技術負債ではない
雑なコードを書くことには全く賛成しません
時間がないからという言い訳で、経験値やスキルがないエンジニアが適当なコードを書くことがあります。そしてそれを「技術負債」と言い訳することがあります。しかしながらそれは技術負債ではありません。
リリース優先で雑なコードを書いたものの、結局はきれいに書き直されていないコード
とはいえ実際に業務をしている中では、時間がなくて雑なコードを書いてしまうことがあります。エンジニアはそういう時に「技術負債」という言い訳をするのはやめましょう。「すみません雑なコードを書いて◯◯という不具合があります。直させてください。」と素直に謝るのが正解です。そうしないと本当に技術負債を借りたり返したい時に支障がでます。
とにかく技術負債は以下のことです
理解が不完全だとしても、目の前の問題に対する現時点での理解を反映するコードを書くこと
どちらかというとYAGNIの法則に近い概念です。
レガシーな技術は技術負債ではない
さらに以下も技術負債ではないと指摘しています。
古くなってしまった技術基盤（言語やインフラやフレームワーク）
これらは良く言えば減価償却済みの「技術資産」、老朽化した「技術資産」というのが正しいです。
この場合の適切な対処は、過去に投資した築いた資産が古くなってしまったことに向き合い、次の５年で何に投資すべきが経営戦略として考えて、適切な投資をしましょう。
結論
ソフトウェアを素早く何度もリリースし、経験や仮説検証から学びを得る開発手法
つまり市場・顧客・事業を100%理解することはできません。新規事業であればなおさら理解することは難しいです。完全に理解してからソフトウェアを設計することは無理なので、理解の不確実さを受け止めて、不確実さに応じた適切な手法で開発を行い市場や顧客や事業への仮説を検証すること。検証し理解が進んだら、理解に応じた設計へ見直し作り直していくことが重要です。
この記事が気に入ったらサポートをしてみませんか？