ソフトウェア開発に関わる人であれば、一度は「技術的負債」（「コード負債」と呼ばれることもあります）という言葉を聞いたことがあるのではないでしょうか。

技術的負債とは、ソフトウェア開発において「スピード」を優先したことで引き起こされる、目に見えないコストのことを指します。

開発スピードとコードの品質、この両者はいわばトレードオフの関係にあります。スピードを優先することで、実は目に見えない技術的な負債が発生しており、それが将来的な開発効率やビジネスの成長に影響する可能性があるのです。

「早くリリースする」ということは、いわば時間の「前借り」をしているということを意味します。通常の「負債」と同じように、現時点での便益を得られる分、後でそれを返済する必要がある…ということですね。

しかし、現代の変化が非常に速い世の中においては、早くプロダクトを世の中に出してフィードバックをもらい、素早くプロダクトを磨く、いわゆるリーンな開発が重要です。特にスタートアップにおいては、将来の開発効率を犠牲にスピードを重視しなければならないシーンも多くあります。

今回は、この「技術的負債」について、そもそもの定義や成り立ちから、その原因と種類、さらには実際に技術的負債に立ち向かう企業の事例までを、徹底的に解説いたします。

非エンジニアの方にもわかりやすいように心がけましたので、ソフトウェア開発に関わる方はぜひ読んでみてください。

＜目次＞

• そもそも「技術的負債」とは何か？ その成り立ちは？
• なぜ技術的負債が生まれるのか？
• 技術的負債の分類（2分類→4分類→13分類）
• 技術的負債は「悪」？ どう向き合うべきなのか？
• 技術的負債への取り組み事例【スタートアップから大手まで5選】
• • 「触れば誰でも怪我をする」巨大アプリケーションの負債を返済 / ラクスル
  • 5年不在だった「CTO」就任で、技術的負債をプロジェクト化 / カミナシ
  • 「Go to クラウド」を合言葉にチームで技術的負債に立ち向かう / 日本航空
  • 老舗ソフトウェア会社の「文化的負債との戦い」8年間 / ウィングアーク１ｓｔ
  • ディスプレイ広告における10年以上の技術負債を返済 / ヤフー

そもそも「技術的負債」とは何か？ その成り立ちは？

技術的負債（technical debt）とは、もともとソフトウェア開発者のワード・カニンガム氏が1992年に作った言葉です。彼は”アジャイルマニフェスト”の17人の著者の一人であると同時に、wikiを発明した人とも言われています。

彼は、短期的な利益とソフトウェアの長期的な実行可能性を比較検討する方法を説明するために、この言葉を使いました。

よりわかりやすい言葉で言うと、技術者ではないステークホルダーに、なぜリファクタリング（※）のために予算を確保する必要があるのかを説明するために、技術的負債という比喩を用いたのです。

※外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること。いわばコードを整理整頓する作業のことを指す。

数年後、カニンガム氏は、技術的負債という言葉を最初に思いついた時のことをこう話しています。

借りたお金があれば、他の方法よりも早く何かをすることができますが、その場合、そのお金を返すまで利子を支払うことになります。私は、お金を借りるというのは良い考えだと考えました。

ソフトウェアを急いで作って経験を積むというのは良い考えだと思いますが、もちろん、そのソフトウェアについていろいろ学ぶうちに、いずれは身につけた経験を反映するようにプログラムをリファクタリングして、その借金を返済するのです。

※参考：https://www.productplan.com/glossary/technical-debt/

カニンガム氏の発言の通り、技術的負債とは、「時間」を前借りするものです。借りた分の時間は、「技術的負債の返済」という形で、後に返す必要があります（金銭的な負債と同じですね）。

ここから先は、技術的負債がなぜ生まれるのか、どう向き合うべきなのか、といった点をより深堀りしていきます。

なぜ技術的負債が生まれるのか？

そもそもコードを書く時に、「技術的負債を生み出そう」と思っている人は一人もいないはずです。しかし、多くの企業が実際に技術的負債に関する課題を抱えています。

では、なぜ技術的負債が生まれるのでしょうか？

Project Management Instituteの VP兼チーフサイエンティストのスコット・アンブラー氏は、以下のように述べています。

技術的負債は、ITチームが特定の開発作業（きれいなコードを書く、簡潔な文書を書く、きれいなデータソースを構築するなど）を見送って、特定のビジネス期限を守る必要があるときに発生します。

それは避けられないことであり、市場投入のスピードが重要なとき、リソースが限られているとき、情報が不完全なときなど、ビジネスとして正しい意味を持つこともあります。

上記はひとつの考え方ですが、技術的負債が発生する代表的な原因としては、ほかにも以下のようなものが挙げられます。

1. 時間的なプレッシャー
2. 複雑すぎる技術設計
3. （既存の）規格との整合性の悪さ
4. スキル不足
5. 最適でないコード
6. リファクタリングの遅れ
7. 不十分なテスト
8. 属人化や開発者の入れ替わり

なかでも、最初に挙げた「時間的なプレッシャー」は、事実上すべての組織に存在するものと言えます。ソフトウェアの設計や実装の決定が、ビジネスの目標や納期とぶつかることはよくありますが、コードの最後の一行まで完璧になるのを待っていては、ビジネスのあるべきスピードにとても追いつかないためです。

加えて、ソフトウェア開発を取り巻く技術は常に変化しています。コーディング言語、開発者用フレームワーク、ライブラリなど、開発に必要とされる技術は年々陳腐化したり、サポートされなくなったりする可能性もあります。

このように、技術的負債は多様な原因で発生するため、それを避けることはほとんど不可能であると言えるかもしれません。

実際、Skuid社の CTO 兼 EVP of Engineering である マイク・ダンシング氏は以下のように述べています。

ソフトウェアが書かれる場所ならどこでも、技術的負債が現実に存在する（Wherever software is written, technical debt is a reality.）

だからこそ、開発チームのリーダーは、組織の技術的負債を管理し、管理可能なレベルに維持する方法について考える必要があります。加えて、「技術的負債を適切に管理することがなぜ重要であるか」を組織内の他の人に伝えることができるようになる必要があります。

※参考：https://www.outsystems.com/glossary/what-is-technical-debt/
https://agilescrumguide.com/blog/files/7-Causes-of-Technical-Debt-and-How-to-Avoid-It.html

技術的負債の分類（2分類→4分類→13分類）

技術的負債が発生する原因は多岐にわたりますが、一方で技術的負債それ自体にも多くの種類があります。長年にわたり、ソフトウェア開発者は、技術的負債を分類し、伝える新しい方法を模索してきました。

まず、各種ソフトウェア開発本の著者として知られるスティーブ・マコネル氏は、2007年に、技術的負債には2つのタイプがあることを示唆しました。具体的には、下記の通りです。

・意図的な技術的負債：戦略的手段として意識的に引き受ける技術的負債
・意図的でない負債：下手な仕事をした結果の非戦略的な負債

そしてその数年後、ソフトウェア技術者であるマーティン・ハウワー氏はマコネル氏の概念をさらに進化させた “Technical Debt Quadrant “を発表しました。

「Quadrant」とは「4象限」の意味で、彼は、「意図」と「文脈」という2軸を用いて、技術的負債を4つのカテゴリーに分類することを試みました。

具体的には、技術的負債はまず意図的なのか・不注意なのかによって分類され、そしてさらに、それが慎重な負債なのか・無謀な負債なのかによって区別されるといいます。

ですがここまでの分類では、負債の具体的な性質や内容について直接対応していません。そこで2014年に、Software Engineering Instituteは、「Towards an Ontology of Terms on Technical Debt」として、技術的負債の13の種類と、それぞれについての主要な指標を発表しました。具体的には、以下の通りです。

※長いので、かなり省略して記載しています。「Towards an Ontology of Terms on Technical Debt」は、こちらからダウンロードが可能ですので、気になる方はぜひご覧になってみてください。

• アーキテクチャの負債…プロジェクトアーキテクチャで発生する問題。通常、コードへの単純な介入では解決できないため、より大規模な開発活動が必要となる。
• ビルド負債…ビルドを難しくし、より多くの時間や処理を不必要に消費させる問題。
• コード負債…ソースコードに見られる問題のことで、コードの可読性に悪影響を及ぼし、保守が困難になる。
• 欠陥負債…ソースコードに既知および未知の欠陥（バグ）がある場合。蓄積すると、後で修正することが困難になる。
• 設計の負債…ソースコードを分析することによって発見される、設計における問題。
• ドキュメンテーションの負債…ソフトウェア文書に見られる問題。文書の欠落、不適切、不完全を指す。
• インフラに関する負債…開発活動を遅らせたり、妨げたりする可能性のあるインフラの問題。
• 人の負債…開発活動を遅らせたり、妨げたりする可能性のある人の問題。トレーニングや採用の遅れ、専門知識の属人化なども含まれる。
• プロセスの負債…非効率的なプロセスの問題。
• 要件の負債…要件定義が不完全、要件に対して実装が不十分、といった問題。
• サービス負債…（開発に必要な）Webサービスの選択、構成、および運用に関連する問題。
• テスト自動化負債…継続的インテグレーションとより速い開発サイクルをサポートするための、開発テストの自動化に伴って発生する作業。
• テストの負債…テスト活動の品質に影響を及ぼす可能性のある問題。

▼実際の「Towards an Ontology of Terms on Technical Debt」記載の図表

※参考：https://www.productplan.com/glossary/technical-debt/

このように、技術的負債とひと言で言っても、その種類は多岐に渡ります。

だからこそ、自社の開発においてどの部分がボトルネックとなっているのか、もしくはボトルネックとなる可能性があるのかを、常に観察、管理することが重要になるのです。

技術的負債は「悪」？どう向き合うべきなのか？

ここまで、技術的負債とはどんなものなのか、ということを説明してきましたが、技術的負債とは本当に「悪い」ものなのでしょうか？

金融における負債と同様に、技術的負債が良いものか悪いものかということに関しても、いくつかの考え方があります。しかし近年では、「技術的負債は本質的に悪いものではない」という見解が一般的です。

この変化の速い世界においては、ほとんどのソフトウェア開発会社は、市場や競争力から、早く開発しリリースするようプレッシャーを受けています。特にスタートアップは、「リリースするか、潰れるか」という二択のプレッシャーにさらされることも珍しくありません。

多くの開発チームは日々、技術的負債を背負うか、リリースを遅らせるかのトレードオフを迫られています。しかし、これまで見てきた通り、技術的負債が影響を及ぼす範囲は、実際にコードを書いている開発者の領域に限りません。

前出のスティーブ・マコネル氏は、技術的負債に対する考え方は、会社の理念だけでなく、部門や役割によっても大きく異なると指摘しています。彼の主張は、

• 一般的に技術スタッフよりもビジネススタッフの方が、技術的負債に対して寛容であるようだと感じる。
• 経営陣はトレードオフを理解したがる傾向があるが、技術陣の中には、技術的負債がゼロであることが唯一の正解だと考える人もいる。
• 一方で、技術陣は技術的負債をビジネス担当者に説明しなければならないことが多く、そしてビジネス担当者はすぐにその意味を理解できない可能性がある。技術的負債は目に見えにくいため、無視もされやすい。

このように、それぞれの立場からの考えも異なるため、技術的負債の良し悪しをシンプルに判断することは大変難しく、それぞれのケースにおける文脈が重要になります。

先ほどから何度か記載している通り、特にスタートアップでは、いち早くビジネスの成果をあげるために完璧なコードよりスピードを優先することも珍しくありません。

そこでここからは、実際に企業が技術的負債に対してどのように判断し、どのように対応しているのか、各社の具体的な取り組み事例をご紹介していきたいと思います。

※参考：https://www.construx.com/resources/whitepaper-managing-technical-debt/

技術的負債への取り組み事例【スタートアップから大手まで5選】

では、実際に日本の企業がどのように技術的負債に向き合っているのかを見ていきます。スタートアップから大手企業まで、幅広い取り組みを紹介していきますので、ぜひ参考にしてみてください。

「触れば誰でも怪我をする」巨大アプリケーションの負債を返済 / ラクスル

※出典：成長事業の代償「技術的負債」を解消する！既存ラクスルの「解体」が生んだ新たな価値

ラクスル株式会社では、2017年に「Raksul Platform Project」を立ち上げ。「触れば誰でも怪我をする」PHP40万行、JavaScript10万行という規模の巨大なアプリケーションが抱えた技術的負債の返済に着手しました。

その目的は、「既存のラクスル」の解体。一枚岩のシステムを機能ごとに小分けすることで、それぞれ独立したチームがアジャイルに顧客へと価値を届けられる状態を目指したといいます。

結果として、技術的負債を大きく返済することに成功。創業当初から描いてきた「印刷産業を変えるプラットフォームになる」ための事業の多角化や、海外の人材を活用した開発体制の構築も実現されたそうです。

こうした取り組みを進める中では、ビジネスサイドから「早く新しいもの作ってくれよ」「リファクタリングなんて、エンジニアのエゴではないか」と言われる可能性もあると思います。

ですから、エンジニアではないメンバーの理解を促進するための取り組みがとても大切です。そのためには、まず定期的に発信するということ。繰り返し飽きるまで、わかりやすく伝えることが必要です。

（中略）その際には、「困っている」みたいなニュアンスより、「明るい未来が待ってるぞ」という感じで、ポジティブなニュアンスを出していくことがキーポイントかなと思いますね。

▼社内報でも、技術的負債解消プロジェクトについて周知

5年不在だった「CTO」就任で、技術的負債をプロジェクト化 / カミナシ

※出典：「CTO不在」の5年間を乗り越えて。進化し続けるカミナシのエンジニア組織の現在地

2016年に創業し、2021年にはシリーズAで総額約11億円の資金調達を実施するなど、順調に成長を続けてきた株式会社カミナシ。同社では実は、組織の技術的トップであるCTOは、創業以来ずっと不在の状態でした。

その弊害として、不具合対応がうまく回らなかったり、技術的負債が蓄積したりといった「成長痛」を感じるシーンも増えていったといいます。

そんな中、2022年7月1日に同社のCTOに就任したのが原 トリ（通称：トリ）さん。トリさんの入社により、スタートアップに求められる「短距離走とマラソン」のうち、「マラソン」ができる組織が構築されつつあり、技術的負債を解消するためのプロジェクトも開始することができたそうです。

（CEO諸岡さん）これまでのカミナシは、基本的に僕と河内というビジネスサイドの人間がツートップで引っ張ってきました。そうすると、事業が伸びていけば、基本的には会社は順調だと思っちゃうんですよ。

ですが一方で、技術的には負債が溜まっていって、不具合が増えたり、新機能開発がままならなくなってきたり…といった成長痛を実感していたところもありました。（中略）今になって、その分の苦労をしている部分はありますね。

（CTOトリさん）これは正論ですが、技術的負債は、機能開発と並行して常に返し続けていかなきゃいけないものなんです。「負債を返済するぞ」とプロジェクト化してしまってる時点で、エンジニアリング組織としては完全に間違っていて。カミナシでは今回プロジェクト化してしまいましたが（笑）。

ただ、我々も含めてスタートアップは、正論だけでは会社としてのゴールを達成できないこともあり得ます。（中略）ですので、特にPMFするまでは、継続的に負債を返済するのは難しいことだっただろうと思います。

「Go to クラウド」を合言葉にチームで技術的負債に立ち向かう / 日本航空

※出典：「技術的負債」解消は数年がかりで、JALや日清食品などIT先進8社の挑戦

日本航空（JAL）では「Go Toクラウド」という合言葉を掲げ、技術的負債の返済プロジェクトに取り組んでいます。

クラウド活用を前提に、全社のITシステムのアーキテクチャから開発・運用体制、IT人材のスキルや組織体制までを刷新。既存システムが抱えていた技術的負債を減らすとともに、将来の発生を最小限に抑える土台を築こうとしています。

具体的には、2024年までに、全社のシステムのうち、クラウドで動かしているシステムの割合を7～8割まで高めることを目指しています。旅客系基幹システムのみならず、基幹業務システムや顧客向けシステムを順次見直し、開発生産性の向上やシステムトラブルの防止を図っています。

その根底にあるのは、クラウドネイティブな最新技術を随時取り込めるようにしてはじめて、技術的負債の抑制につながるとの考えです。

本プロジェクトをリードするのは、「クラウドCoE（センター・オブ・エクセレンス）」と呼ばれる組織。Go Toクラウドに基づく技術的負債返済プロジェクトで中核的な役割を果たしているといいます。

老舗ソフトウェア会社の「文化的負債との戦い」8年間 / ウィングアーク１ｓｔ

※出典：老舗ソフトウェア企業は文化的負債をどう解消するか　プロセス・コミュニケーション・要件管理における改善事例

帳票とデータ活用・BIを基点に、情報活用と業務効率を活性化させるソフトウェアを提供するウイングアーク１ｓｔ株式会社。

1993年にその前身となる事業部が誕生した同社では、長い歴史の中で溜まっていた「文化的負債」を解消すべく、ソフトウェアプロセスの改善というアプローチを取ってきたそうです。

文化的負債とは、あまり聞き慣れない言葉ですが、オライリージャパンの「Effective DevOps」によると、「採用や雇用などの決定、コミュニティの基準、あとは組織の階層構造、会社の文化が最終的に生み出しているもの」と定義されているそうです。

具体的に同社が抱えていた文化的負債としては、下記の14点が挙げられています。

（編集者の心の声：…これ、めっちゃくちゃ興味深いですね！！）

これらの課題に対して同社がどう立ち向かったのか、生々しいストーリーがこちらのイベントレポートに書かれているので、ご興味のある方はぜひご覧になってはいかがでしょうか。

ディスプレイ広告における10年以上の技術負債を返済 / ヤフー

※出典：10年以上の技術負債を返済してわかったこと 〜 ヤフーのディスプレイ広告におけるレスポンス生成刷新事例

続いてご紹介するのは、ヤフー株式会社の事例です。同社が展開するディスプレイ広告は10年以上前から（※2022年時点）存在するプロダクトですが、その過程で配信可能な広告種別が増えるなど、仕様が変化していったといいます。

それに伴い、当初のシステムの実装が最新の仕様に対して不適切となり、技術的負債となっていたそうです。

そこで、最新の仕様に合わせてシステムの処理（広告レスポンス生成）を刷新することで技術的負債に対応していきました。2020年12月からプロジェクトを開始し、2022年3月に切り替えが完了するという、大規模な取り組みとなったようです。

結果的に、技術的負債の返済によってシステムがシンプルになり開発効率が改善したことに加え、広告デザインの管理・運用コストが低減するメリットが得られたといいます。例えば、アプリバナーの広告デザイン変更時、A/B テストに掛かる時間が 7営業日から 3営業日に短縮されたそうです。

終わりに / 技術的負債に関する無料ウェビナーも開催します！

各社の技術的負債への取り組み、いかがでしたでしょうか。やはり、負債は負債である以上、あまりにも溜め込みすぎてしまうとその解消に多くの労力がかかることが感じられたかと思います。

当媒体では、2022年9月1日（木）に、カミナシ社、atama plus社、キャディ社をゲストに迎え、技術的負債への向き合い方をテーマにした無料イベントを開催します！

記事ではお伝えできない、より生々しいお話が聞けるかと思いますので、ご興味のある方は、ぜひご参加いただければと思います。

▼無料ウェビナーのお申し込みはこちら！！