技術的負債の語源とその解釈について
エンジニアとして仕事をしているとTechnical debtという言葉によく出会います。
エンジニアと一緒に仕事をしている方も耳にすることもあると思います。
負債という言葉から「良くないもの」「なかった状態にすることが望ましいもの」「放っておく期間が長くなるほど困る」というイメージを想像させます。
私自身もエンジニアではないチームメンバーにお伝えするときにこれらのイメージでお伝えすることが多いのですが、そもそもなぜ「負債」という言葉が選ばれたのか、技術的負債という言葉が生まれた背景をよく知らないなーということに気づき、改めて調べることにしました。
いつ生まれた言葉なのか
1992年に開催されたACMの国際会議のOOPSLA(Object-Oriented Programming, Systems, Languages & Applications)の論文発表が出典とされています。
ちなみにOOPSLAは2010年よりSPLASH(Systems, Programming, Languages, and Applications: Software for Humanity)という国際会議に統合されました。
人類のためのソフトウェアと冠して協議することを前提にした名前になったのはいいですね。
論文の著者はWard Cunningham氏。
当時キャッシュポートフォリオ管理システムのWyCASH+を開発していたときの経験をシェアした論文"Experience Report - The WyCash Portfolio Management System"を発表しました。
論文はACM公式サイトから無料で読めるのでぜひ読んでみてください。
下記リンクからeReaderかPDFボタンを押すことで読めます。
負債とは
この論文の中でCunningham氏はIncremental design repairという開発プロセスを通してシステムが解決すべき問題領域に幅広く対応できることの重要性を説いています。
同時に、Conversion workによってエンジニアが新しいシステムデザインに慣れ親しむこと、リリース時には古いシステムデザインのコードが除去されて簡素なコードのみが残ることも重要であると触れています。
このプロセスこそが顧客にとって適切なプロダクトを短期間で作ることに繋がると考えており、逆にこのプロセスを欠くとプロダクトは作れても顧客の要望に耐える柔軟性を失ったプロダクトになると発言しています。
We believe this process leads to the most appropriate product in the shortest possible time, Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product.
最初にリリースされたプロダクトコードはDebtになりがちと喩えています。
ようやく出てきましたね。
Incremental design repairによって現在の顧客要望に合わせたシステムデザインに変換するよう早く返済すればよいけど、返済が終わっていないシステムデザインの上で開発した時間だけ負債は利息のように貯まり、プロダクトの破綻を招きかねないよ、と。
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
ここまで調べてみて
Incremental design repairを取り入れることは大事であると同時に、常にincrementできるようにするために日頃から顧客要望を観察してシステムデザインを見直す、不要なコードを見つけて除去するなど少しずつでもいいからやり続けないといけないなと改めて感じますね。
ScrumにおけるIncrement deliveryを途絶えさせないための下地作りにも近そうです。
なぜ負債に喩えたのか？
この論文で技術的負債は早く返済するのが望ましいという主張は伝わりました。
気になるのが負債という言葉のチョイス。
負債という言葉は会計用語で他人資本とも呼ぶので、債務超過の事態を除けば負債があることは必ずしも悪い状態ではなさそうだしそんなに返済を急がないといけないの？と思う人もいそうですね。
その説明は2009年にCunningham氏本人が投稿した動画で語られています。
I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product done in Digitalk Smalltalk, and it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk.
WyCashのプロダクトにおけるリファクタリング（システムデザインの修正）を説明するために、負債という暗喩を作りました。WyCashはDigitalk社の Smalltalkで作られた初期の製品で、プログラムを修正することによって、まるで最初から理解していたかのように、かつSmalltalkで簡単に実現できるように見えるように、時間をかけてこのプロダクトに関する学習を蓄積することが私にとって重要だったのです。
The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.
WyCashは金融ソフトウェアで、私は上司に負債メタファーと呼んでいた金融の喩えを説明しました。もし私たちのプログラムを、その当時私たちが理解していた金融対象についての正しい考え方と一致させることができなければ、互いの理解の不一致につまずき続けることになり、それはローンの利息を払うようなもので、私たちのペースを落とすことになるというものでした。
つまり、金融ソフトウェアを作る会社に身を置く上司に「早期に返済すべきもの」として伝わりやすくするために負債という言葉を選んだことが窺えますね。
負債よりも責任？
先ほど負債は他人資本とも呼ぶという話をしましたが、同様の混乱を感じてDebtよりLiabilitiesのほうが望ましいのではという意見を発信した方がいます。
2016年にAllan Kelly氏が"Technical liabilities: not technical debt"という記事を投稿しました。
The big big problem with talking about “debt” is that debt is not necessarily a bad thing; debt is often good, particularly in a business context. This leads to misunderstanding between engineers and non-engineers and can even lead engineers into poor habits.
「負債」について話す上での大きな問題は、負債が必ずしも悪いことではないということです。特にビジネスの文脈では、借金はだいたい良いものです。これは、エンジニアと非エンジニアの間の誤解につながり、エンジニアを悪い習慣に導くことさえあります。
To many people in business – and particularly bankers – debt is good. Debt allows you to grow business and improve earnings. When an engineer says “This will add technical debt” the engineer thinks they are warning about something bad, but to a non-engineer business person, debt is often the preferred form of funding. So buying new capability with (technical) debt sounds like a good deal.
ビジネスに携わる多くの人々、特に銀行家にとって、負債は良いものです。負債は、ビジネスを成長させ、収益を改善することを可能にします。エンジニアが「これにより技術的負債が追加されます」と言うと、エンジニアは何か悪いことを警告していると思いますが、エンジニアではないビジネスパーソンにとって、負債は多くの場合資金調達の好ましい形です。したがって、(技術的な) 負債を抱えて新しい機能を購入することはお得に思えます。
Simply changing our language from Technical Debt to Technical Liability removes these problems.
Liability is something neither business and technical folk consider good.
私たちの言葉を技術的負債から技術的責任に変更するだけで、これらの問題（Cunningham氏の話に出た相互理解の不一致）は解消されます。
責任は、ビジネスや技術者のどちらも良いとは考えていません。
Let's talk about Technical Liabilities in our systems.
Technical liabilities that cost us because they create obligations – obligation which slow us down, obligations which must be repaid; and they create risks, we don’t know when an obligation is going to bite us.
システムの技術的責任について話しましょう。
次のような義務を発生させるためにコストがかかる技術的責任についてです： 我々の速度を落とす義務、返済しなければならない義務。これらの義務はリスクを発生し、義務がいつ私たちを苦しめるかわからないのです。
責任や義務という言葉だと確かにポジティブに捉えられることはなさそうですね。
両者ともに、早く返済することが重要であることを伝えるために考えた結果だと思います。
どう話せばエンジニア以外の方にも伝わるのか
技術的負債という言葉がエンジニアにとって普遍化して口に出やすいからこそ、その意図を正しく伝えるにはどうしたらいいかを常に意識してコミュニケーションをとらないといけないなと自戒を込めてまとめました。
変わらないビジネスもお客さんも存在しないので、変化に追従し続けるためにシステムデザインの課題をそのときのチームに分かりやすく伝えていこう。
読んでいただきありがとうございますー よろしければシェアもおねがいします🙏