技術的負債とは？そして負債を完済する方法とは？(実例付)

製品分野に携わると、ソフトウェアの機能に関して、スピーディーな決断を迫られる状況に遭遇します。とりわけ DevOps チーム (開発運用混合チーム) では機能をリリースするために、とても多くの決断を迫られます。

スピードを最も重視した決断の結果を表現する用語として、技術的負債は用いられます。こういったすばやい、リアルタイムベースの決断はソフトウェアのアップデートの成功を左右します。しかし、良い決断と早い決断の間にはバランスが必要です。技術的負債を招く決断がネガティブな結果を生むのか、あるいは負債を負う価値が充分にあるのかは、何を決断するのかによって決まります。

この記事では、技術的負債の定義と、開発プロセスでスピーディーな決断を効果的に管理する方法を説明します。また、今後災難を回避する方法を理解できるよう、技術的負債の実例をご紹介します。

技術的負債とは何か？

技術的負債とは、効果的なソリューションではなく簡単なソリューションを選ぶことで生じる追加作業のコストを意味します。技術的負債は、ソフトウェア開発者の Ward Cunningham 氏が 1992年に初めて用いた造語ですが、この用語の意味は時代とともに進化してきました。

現在、技術的負債はコード負債とも呼ばれ、通常はソフトウェア製品開発において新しい機能を構築する際に、開発チームが早さを優先したコードを記述することで発生します。スピード重視のアプローチを採用することで、締め切り前に納品できる可能性は高まることから、負債を負う価値がある可能性はあります。しかし、管理を誤るとネガティブな結果を導きかねません。技術的負債を招く決断を行った後は、このようなネガティブな結果が必然的に生じて回避できない場合もあります。

技術的負債を効果的に活用できている方も、ネガティブな結果に終わった方もいらっしゃると思いますが、どちらの場合にも即座に正しい決断を下せるように、この記事では技術的負債に関する重要な事実を説明します。

技術的負債は敵か？

金融負債と同じように、技術的負債はプラスにもマイナスにも働きます。

場合によっては、ソフトウェア開発の締め切りを守り、品質の高いコードをスプリント内で納品するため、意図的に技術的負債を負うこともあります。その一方で、ソフトウェアのアップデートをリリースする際に仕方なくミスが発生し、その結果として負債が生じることもあります。

技術的負債の 4 象限

技術的負債には 4 つの原因があり、これは技術的負債の 4 象限と呼ばれます。技術的負債の 4 象限は Martin Fowler 氏が考案した概念であり、無謀、慎重、意図的、不注意の 4 つで構成されます。

技術的負債を 4 つの原因に振り分けることで、コードの問題の意図と背景を判断しやすくなります。一部のコード負債は意図的であり、良い負債に分類されますが、不注意で起きたコード負債は悪い負債に分類されます。

1. 慎重で意図的: 早く納品し、後々結果と向き合うことを覚悟した決断は、慎重で意図的な負債をもたらします。このタイプの負債は、製品への投資がそれほど大きくなく、またスピーディーな納品のメリットがリスクを上回る際に負います。

2. 無謀で意図的: 最高のコードを作成する方法を知りながら、スピードを優先する決断により、無謀で意図的な負債が生み出されます。

3. 慎重で不注意: 慎重で不注意な負債は、最高のコードを構築する欲求はあるにも関わらず、実装後により良いソリューションを発見する際に発生します。

4. 無謀で不注意: 無謀で不注意な負債は、チームが必要な知識を持たない状態で最高のコードを記述する試みを行うことで発生します。大方、チームはミスを犯していることに気づきません。

スピーディーな納品のための技術的負債は意図的ですが、不注意な負債は偶然起こるものであり、実装後に発生します。この違いについて、ソフトウェアエンジニアの Steve McConnell 氏は技術的負債の 2 つの総合的なタイプを挙げ、わかりやすく説明しています。それでは、それぞれのタイプを学び、技術的負債への理解を深めましょう。

技術的負債のタイプ

Construx Software でチーフソフトウェアエンジニアを務める Steve McConnell 氏は技術的負債には以下の 2 つのタイプが存在すると指摘しています。

• 意図的な技術的負債

• 意図しない技術的負債

1. 意図的な技術的負債

意図的な技術的負債は、組織が将来よりも現在を優先した決定を意図的に下す際に発生します。

このタイプの負債は短期のものもあれば、長期に及ぶものもあります。たとえば、以前の負債を解消するために短期的に意図的な負債を負うこともあれば、今後の大規模な負債を予防するために長期的に渡る負債を意図的に負うこともあります。

短期の負債: 短期の負債は、既存のリソースを活用する場合など、ピンポイントで受動的に負います。また、短期の負債には的を絞った負債もあれば、的を絞らない負債もあります。

• 的を絞った短期の負債: 具体的にそれとわかるショートカット (近道) が含まれます。

• 的を絞らない短期の負債: 多数の小規模なショートカットが含まれます。

長期の負債: 長期の負債は、締め切りに間に合わせるなどの大局的な理由で能動的に負います。

ご覧のとおり、負債のタイプは返済の期間を左右します。

2. 意図しない技術的負債

一方の意図しない技術的負債は、多くの場合、理解不足や偶発的なミスが原因で発生しますが、品質の低いコードに起因することもあります。たとえば、設計のアプローチがエラーを起こしやすい方法であった場合です。これは、必然的に起こるミスによる、意図的ではない負債です。

意図しない技術的負債は、チームが意図的に招いたものではなく、偶然発生したものと想定できます。通常は、ソフトウェアのアップデートを実装した後やプロジェクトを完了してから初めてミスに気づきます。

技術的負債を返済する方法

意図的に技術的負債を負うこともありますが、多くの製品チームは技術的負債の追跡と伝達に苦慮します。その結果、ソフトウェアのコードのギャップを解決しようと試みる際に、予想を上回る量の作業が必要になる恐れがあります。

技術的負債を管理し、負債の量の見える化を実現する方法が主に 2 つ存在します。

1. 追跡システム内で負債をリストアップする: 負債を招く度に、追跡システムに完済するために必要なタスクの推定の工数とスケジュールを併せて入力します。負債のバックログを使って、技術的負債の進捗状況を確認しましょう。90 日以上経過しているにもかかわらず未完済の負債は重大な問題として取り扱うべきです。

2. 負債リストをスクラムの製品バックログの一部として管理する: 各負債をスクラムの「ストーリー」として扱い、スクラムのその他ストーリーと同じように、製品バックログ内で負債を完済するための工数とスケジュールを推測します。

この 2 つの方法を使えば、技術的負債を効果的に追跡し、できるだけ早く、効率よく負債を完済できるようになります。クレジットカードの負債を完済する場合と同じように、どちらのアプローチも負債を完済するまで、少しずつ返済していきます。

技術的負債の例とその解決策

技術的負債の管理に加え、意図的および意図しない負債の原因を説明したので、続いて実例を見ていきます。

例 1: 意図的な技術的負債

• 説明: すばやく構築できるフレームワークを、パフォーマンスの問題や機能不足を理解した上で選択したケースが該当します。

• 解決策: ソフトウェア実装後に、不足するフレームワークの機能を補うアプリを追加で利用します。

• 負債: 製品の納期に間に合ったとしても、チームはローンチ後に機能を修正し、さらにそのための資金が必要になります。

例 2: 意図しない技術的負債

• 説明: 多くの若手の開発者が、タイトなスケジュールでソフトウェアの新しい機能のローンチに携わり、チームには各コードをレビューする経験豊富な開発者が不足しています。

• 解決策: 一時的にベテランの開発者を採用してサポートを依頼し、コードと適切な機能の確認作業を手伝ってもらいます。

• 負債: 大半の問題に対応できましたが、フルタイムのスタッフと一時的なサポートスタッフの間のコミュニケーションがうまくいかず、コード内で複数のバグを見逃してしまいました。そのため、チームはローンチ後にこれらの不具合を解消する必要があります。

ご覧のように、意図的な技術的負債と意図しない技術的負債には違いがありますが、どちらも時間をかけて負債を返済しなければなりません。技術的負債への解決策をブレインストーミングで挙げていくことで、負債をほとんど招くことなくソフトウェアのアップデートを予定どおりにリリースできるようになるでしょう。

見える化によって技術的負債を返済する

ソフトウェア製品のローンチに携わっていると、負債を避けられないときもあります。厳しい決断をする場合も、あるいはコードでミスをしてしまった場合も、アジャイル型のチームは、発生した技術的負債がソフトウェアのアップデートにどれほどの影響を与えるのかを把握できます。

負債を完済する上で重要なことは、返済を管理し、追跡することです。シナリオによって返済の種類は異なりますが、チームが明確に状況を理解し、コミュニケーションを取り合うことが、完済を早める上で効果的です。だからこそ、Asana では、プロジェクトの見える化に力を入れており、目の前の問題をチームで解決できるようにサポートしています。