貯まった問題との付き合い方――割れた窓の法則、エントロピーの法則に見る技術的負債が起こる理由：問題解決力を高めるコツはプログラミングの原則・思考にあり（終）（1/4 ページ）

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。最終回は、「割れた窓の法則」「エントロピーの法則」から「技術的負債」が起こる理由や、貯まった問題との付き合い方を示す。

[上田勲，著]

連載目次

書籍の中から有用な技術情報をピックアップして紹介する本シリーズ。今回は、秀和システム発行の書籍『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則（2016年3月22日発行）』からの抜粋です。

ご注意：本稿は、著者及び出版社の許可を得て、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

なお書籍では、ソフトウェア業界で高名な、よいコードを書くための「プリンシプル」を紹介しています。プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」などのことです。具体的には、「技術的負債」「割れた窓の法則」「エントロピーの法則」などのプリンシプルがあります。こうした各プリンシプルについて、「それは何なのか（＝What）」「それはなぜなのか、なぜ必要なのか（＝Why）」「ではどう使えばよいのか、どうすればよいのか（＝How）」を中心に解説する構成になっています。

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップしていきます。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出していただければ幸いです。

最終回は、「割れた窓の法則」「エントロピーの法則」から「技術的負債」が起こる理由や、貯まった問題との付き合い方を示します。まずは「技術的負債」とな何かから紹介しましょう。

※編集部注：前回記事「1つの解決策を永続的な決定とするのは無理がある――曳光弾とプロトタイプ、ユーザーからのフィードバック」はこちら

技術的負債

　英語　　Technical debt

　What　〜問題コードは「借金」である

　プログラミングには2つの道があります。1つは、時間がかかっても、きれいなコードを書く道です。もう1つは、素早く汚いコードを書く道です。

　十分に時間があれば、常に「時間がかかっても、きれいなコード」を選択すべきです。一方、時間がなかったり、修正の緊急度が高い場合には、「素早く汚いコード」を選択する場合もあります。

　ただし、「素早く汚いコード」を選択した場合、このソフトウェアは、いわば「負債」を抱えることになります。これを技術的負債と呼びます。

　技術的負債は、コードにおける「修正しにくい」「理解しにくい」といった、問題のある汚いコード部分のことです。「障害そのもの」のことを指しているわけではありません。障害の温床、障害の発見の妨げとなる、問題のあるコードを指しています。この問題部分を「負債」、すなわち「借金」に喩えています。

　実際のビジネスにおいて、一時的に「負債」を抱えることは、もちろんあります。そして、それをすぐに返済すれば、何ら問題ありません。しかし、負債には利子が発生します。長引けば、その利子は膨らみ、返済が困難になってきます。そして、そもそも負債を抱えすぎれば、返済不能に陥ることになります。

　これは、コードでも同じです。

　一時的に「汚いコード」を許容しても、時間を置かないうちに「返済」すれば、それほど問題にはなりません。この場合の返済とは、変更前に戻り、時間があればやっていたであろう正しい方法、つまり「きれいなコード」に修正することです。

　しかし、すぐに返済できなかった場合、「利子」が発生します。汚いコードがソフトウェアに残り続けると、問題が大きくなるのです。負債コードを読むには時間がかかります。そこに修正を加えるとなると、さらに汚いコードになり、ソフトウェアの動作も不安定になってきます。利子は複利となり、指数関数的に膨らんでいくのです。

　そして、利子が膨らみすぎたり、多数の負債を許容することによって、負債を抱えすぎてしまった場合、返済不能に陥ります。つまり、「機能追加」も「保守」もできない、不安定でアンタッチャブルなコードと化してしまうのです。

　こうなると、もうこれ以上、ユーザーに価値を提供できなくなります。

　Why　〜問題コードとうまく付き合う方法

　技術的負債は悪循環を生みます。

　コードが理解しにくいと、機能追加に時間がかかります。また、障害の発見にも時間がかかりますし、障害の修正そのものにも時間がかかります。

　時間がかかるということは、影でまだ返済の終わっていない負債が膨らむということです。さらに、そのチームが本来するはずであった、もっと価値のある仕事をする時間を失ってしまった、ということにもなります。

　ただし、ソフトウェア開発において、「時間を借用する」という考え方は、やるべきことを何とかやり遂げながら、リスクのあるマイルストーンを達成するのに役立つ戦略です。その時点では、完璧なコードは書けないかもしれませんが、いくぶん手抜きをすれば、最低限の完了基準を満たすコードなら書けるかもしれません。たとえソフトウェアが一時的に不完全な状態になっても、それが責任を持って管理されているなら、この「手抜き」は理に適っています。

　とはいえ、借金が支払えないでいると、やがて追い詰められていきます。借金を返済せずに、将来を担保にして借用し続けると、より危険にさらされていきます。

　そこで、技術的負債の考え方を取り入れ、この借金をコントロールしていかなければなりません。負債を忌み嫌うのではなく、その存在を認知し、うまく付き合っていく必要があります。

　How　〜問題コードを管理する

　プログラミングに「技術的負債」の考え方を取り入れ、問題コードを管理しましょう。

　技術的な負債の利子を想像すると、代償が高すぎて、とてもそんな余裕はないと思うかもしれません。しかし、深刻な障害が発生した時、できる限り早く修正をするか、大きな損失を覚悟するかの選択を迫られた場合は、素早く汚いコード修正を選ぶのは、誤った選択ではありません。

　ただし、そこで終わってはいけません。技術的負債は、素早く返すことが何よりの対策です。リリースして難を凌いだら、ただちに変更前の状態に戻り、そこから本来あるべき「きれいなコード」に修正します。そのコードのことを覚えているうちに、担当者がまだいるうちに、素早く返済するのが一番確実です。

　そして、すぐ次のリリースにその修正を組み込むようにします。これは、クレジットカードで何かを買って借金を作っても、月末に入金すれば利息を支払わなくて済むのと同じです。

　このように運用できれば、ビジネスが必要とする迅速な対応を提供できるとともに、プロジェクトを借金地獄に追い込まなくて済むようになります。

　仮に返済の時間がなかった場合は、せめて、その本来書くべきであったコードの設計を、ドキュメントに残しておきましょう。

　発展1　〜コードをきれいにする意義を説明

　この「技術的負債」という喩えは、コードに詳しくない人に対して、コードをきれいにしておく活動の意味と、そのために必要な時間の意味を、理解してもらう材料になります。「汚くても動いているからよい」「動いているものをわざわざ触る必要がない」「動いているものこそ正しい」という考え方の人は、少なからず存在します。コードをきれいにする必要性は、コードを書いて、保守した人でないと、実感しにくいものです。上司がコードを書かない場合など、活動時間の捻出のため、その説得に役立てましょう。

　発展2　〜問題コードの誘因

　問題コードと、それが広がってしまう誘因には、以下の要素が考えられます。

• 経験不足のプログラマ
• 締切りのプレッシャー
• 読みにくいコード
• 特殊化されたコード
• 不要に複雑なコード
• 単に悪い設計

　また、以下のようなチームの文化が、その誘因であることも考えられます。

• きれいなコードを書こうとしない。
• 不明瞭なコードがあっても受け入れてしまう。
• リファクタリングに時間を割かない。
• リリース直前になって回帰テストを実行する。
• 膨大な依存性を抱えた古いシステムのリプレースを躊躇する。
• 安易にコードをブランチさせる。

　これらの誘因を意識して、汚いコードの蔓延を前もって防ぐようにしましょう。

　ただし、そこから漏れ落ち、汚いコードになってしまった部分があれば、それは技術的負債として管理しましょう。

　関連1　〜技術的病気

　技術的負債は、コードの問題部分を「借金」に喩えていますが、「病気」に喩えられることもあります。

　「病気」のソフトウェアは、どこかに変更を加えると、関連のない別の箇所が壊れてしまう状態です。放っておいても治らずに、悪化するばかりです。「手術」をしなければなりません。外科医が「手術」を恐れずに病気を治すように、コードに変更を加えることを恐れず、積極的にシステムを改良します。

　システムにおいて「手術」とは、「リファクタリング」です。リファクタリングには、時間と労力はかかりますが、プロジェクトが進む中で、その投資は十分回収できます。それどころか、何倍もの利益となって返ってきます。

　さらによいのは、「病気」のシステムを治すことが、プロジェクトのメンバーにとって経験になることです。その経験によって、ソフトウェアは本来どうあるべきかを全員が理解するようになり、ソフトウェアについてのエキスパートになるのです。

　したがって、積極的に「手術」、つまりリファクタリングを行うべきです。変更を恐れてはいけません。動かないことは、体を悪化させるだけだからです。

　ただし、改良はゆっくり少しずつ加えていき、都度テストを実行します。一度に大幅な変更を加えるのは危険です。それが元で大変な問題が発生し、結局、せっかく途中まで進めた改良を、全部やめてしまうことになりかねません。

　関連2　〜暫定ソリューション

　技術的負債と似た概念に、「暫定ソリューション」があります。

　時間がない時に、その場しのぎに作られるのが「暫定ソリューション」です。

　暫定ソリューションは、開発中のソフトウェアに正式に属さないものとして、切り離して作られます。作った当初はあくまで「ドラフト」と考えられており、時間がなくて本来守るべき規約やガイドラインに従うことができないため、後で修正することが前提となっています。

　ところが、暫定ソリューションには「慣性の法則」が働きます。いったん暫定ソリューションができると、既成事実化するのです。既に存在していて、一応役に立っていて、一応皆に受け入れられていると、その状況を今すぐ変える必要性をあまり感じません。本当は暫定ソリューションも早くシステムに統合すべきなのですが、重要な仕事はほかにもたくさんあるので、どうしても後回しになります。

　結局、暫定ソリューションは「暫定」と言いながら、いつまでも修正されずに残ることになります。「その場しのぎ」のはずが、長生きしてしまうのです。

　ただ、暫定ソリューションを始めからいっさい作らない、というのは非現実的です。問題解決が間に合わない場合が出てきてしまいます。

　よって、暫定ソリューションについても、技術的負債と同じように管理する必要があります。

出典書籍

『アート・オブ・アジャイルデベロップメントー組織を成功に導くエクストリームプログラミング』James Shore 他, オライリー・ジャパン（2009）

関連書籍

『パターン指向リファクタリング入門〜ソフトウェア設計を改善する27の作法』ジョシュア・ケリーエブスキー, 日経BP社（2005）

『プログラマが知るべき97のこと』和田卓人他, オライリー・ジャパン（2010）