どうなったら“技術的負債”として扱われるようになるのか　マーティン・ファウラーなどの言葉から考える技術的負債の定義

「技術的負債」の定義

新田智啓氏：次に技術的負債ですね。「技術的負債とは」というところですが、ウォード・カニンガムという、外国のエンジニアの方が作ったメタファーになります。システムは粗雑なものが蓄積しやすくて、内部品質に欠陥が出ます。開発時に必要なかった追加の労力が必要になるところが、借金の利息に似ていて、エンジニアの感覚にフィットしたことで技術的負債（という言葉）がすごく流行った。

あとはマーティン・ファウラーですね。マーティン・ファウラーも技術的負債について語っていて、「意図的な借金であるか、無意識的な借金であるか。それが賢明なのか、無謀であるか」というところを軸にして、技術的負債の属性みたいなものを整理したりしていました。

そしてフィリップ・クルクテンですね。その価値が見えるかどうか。見えない部分か、見える部分か。そして価値がプラスかマイナスかというところで分類しました。そして「価値の見えない部分でマイナス部分が技術的負債なんじゃないか」と語っています。

（スライドを示して）プラスがアーキテクチャ、機能の特徴、マイナスがTechnical Debt、技術的負債とあります。技術的負債の中にアーキテクチャとか機能の特徴も含まれるのはちょっとモヤモヤした気持ちになったんですが、どちらにしろ内部の品質、見えない品質が大事ではあります。

「品質」と「非機能要件」

その品質は何なのか？　というところで、外部の品質・見える品質と、内部品質。あるいは機能要件と非機能要件みたいなものがあるのかなと。

もうちょっとだけ品質の話をすると、品質ってどの品質ですか？　と。「品質が良い」とか「悪い」とかがよく語られて。「バグがある」とか「ない」と言われるんですが、解消したい時に“品質”みたいなふわっとした言葉で解消しようとすると、みんなの方向がなかなか揃わないと思うんですね。なので、「品質」ということでどこを改善したいのか。どこが問題なのかを、もうちょっと解像度を高めて理解する必要があるかと思います。

あとは非機能要件ですね。機能要件はたぶんエンジニアじゃない人とかも含めていろいろ決めてくれるんですが、非機能要件の部分はエンジニアが決めなければいけない要件だと思います。

なので、パフォーマンスとかスケーラビリティだったり、アベイラビリティだったり、あまり気にせずに機能開発をしてしまうと負債が溜まりやすいのかなと思います。こういう、見えないところの機能要件に対しての非機能要件だったり内部品質だったりの解像度を高めて向き合う必要があるかと思います。

設計によって技術的負債は抑えることができる

技術的負債の話に戻ります。技術的負債という言葉がいろいろ流行った中で、「技術的負債」という言葉を生み出したウォード・カニンガムが、以下のように言っています。「技術的負債の比喩の中で、あとできれいなコードにするつもりで雑なコードを書くことも技術的負債の主な原因であるという考えが、他の原因と混同しています」と。これに私は賛同しません。

（スライドを示して）いっぱい文字が書いてあるんですが、まとめると、コードを書く時にはベストを尽くせ、と。雑に書くのは技術的負債ではなくて、ただの怠慢である。時間をかけろという話じゃなくて……。たぶん時間的な制限はあると思うんですね。その制限の中でベストを尽くすとか、あるいは自分の能力も限界があると思うので、能力の中での最高を出す努力が大事なのかなと。

あとは、実際にコードを書いてリファクタリングをする時に、「こういうふうになったらいいな」とか、「こういう助けになったらいいな」ということのベストを尽くすというところで、今だけじゃなくて未来を見ながらしっかり書くことが大事かと思います。

こうやって設計とかを重要視すると、動くものとかがなかなか出ず、「プログラマーの自己満足なんじゃないか」みたいなことが他の職種から見えたりするのでマーティン・ファウラーが（次に紹介する言葉のように）言及しているんですけど。

「それは自己満足のためじゃなくて、設計というのは技術的負債の発生を抑えることができるので、しっかりやっていくべきだ」という話があります。中長期的に見たペイオフラインというものがあって、それにはちゃんと向き合うべきだと。

「技術的負債」は“塵が積もって山となる”ように出てくる

あとは『A Philosophy of Software Design』というものがあって、この中の表現で対応方法みたいなものがすごくいっぱいあるんですが、最初のほうで「コードの複雑さというのはある日突然現れるんじゃなくて、塵が積もって山となるように徐々に出てきます」と（いう話があります）。いきなり出てくるわけではない。

突然出てくるものではないとなると、どういうふうになると技術的負債と呼ばれて、自分たちの技術的負債のリストに載せられるんだろうか。塵の状態だったらまだ気がついていないわけですよね。どうやったら技術的負債みたいなリストに載せられるのかというと、私の解釈ですが、エンジニアがやりづらいと感じた瞬間。ものすごく感覚値的なもの。気がついた時みたいな。

あとは、コードとかの構造を見て「もっとこうしたらいいのにな」みたいなアイデアが浮かんだ時。そういう「もっと良くしたい」みたいなことが思い浮かんだ時。それは負債というものを認知して、ある意味、次の価値を反映させたい気持ちなのかなと思っています。

なので、現在のシステムから満足できないところの差分が技術的負債と感じるところ。欲しい開発者体験、DXみたいなところの差分が技術的負債なんじゃないかなと思っています。

「開発者体験」と「生産性」

「開発者体験」という言葉はCTO協会の定義では、「開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や習慣、文化のことを指します」と。開発者体験は開発者、エンジニアが働きやすいだけの環境みたいに捉えられたり、「こうすると気持ちいいよね」と感じたりするかもしれませんが、そうではない。生産性を高めるための高速な仮説検証ができる状況ということですね。

生産性は何かというと、Wikipediaでは「生産性 = 産出量 / 投入量」（生産性 = アウトプット / インプット）と書かれています。インパクトチェーンみたいなものがあるんですが、投入したもののリソースと組織活動、チーム活動とかエンジニアの動きがアウトプットになります。

そして、エンジニアだったらシステムだったりをユーザーに使ってもらって、価値を感じてもらってアウトカムになる。それがムーブメントというか、社会的な動きになるとインパクトになるという流れになるのかなと解釈しています。

スタートアップが目指すのはたぶんインパクトのところだと思うので、アウトプットの量がたくさんあればいいというわけではなくて、その価値だったりインパクトがどういうふうに起こるのかを考える必要があって、その価値貢献のスピードが生産性に求められることだと思っています。なので量ではない。

本セッションで扱う「技術的負債」とは

そういったところで今回扱う技術的負債というのが何かを整理します。「負債」というと、触らなくても古い、例えばCOBOLとかの言語で作った20年前のシステムとかがあるかもしれませんが、それが順調に動いていて、お金が稼げていればそれは問題ないと思うんですよね。

ただそれに、なにか変更を加えたいとか、機能を加えたいと思った時にどうしようもなくなると思うので、その状態になると負債ですが、変更を加えたい状態がなければ、技術的にはもしかしたら直したいと思うかもしれませんが、そのままでいいと思います。

今困っているところで、それを直すと価値になるところの負債が解消すべき負債で、それを解消すると価値につながる。この解消することで価値につながる負債を今回扱う技術的負債として話したいかなと思っています。

というところで、技術的負債のまとめとしては、理想環境と現状のシステムとか環境の差分みたいなものが技術的負債。エンジニアの生産性を妨げて、追加の金利的な工数がかかるもの。システム内部の課題。雑なコードを書いたものではなくて、ベストを尽くして作ったもの。コードの複雑さは突然現れるものではなくて、塵のように積もって出てくる。そして今回は、技術的負債の解消によって価値が発揮されるものを“負債”として考えようと思っています。

ちょっと急がないといけないそうです。スタートアップで起こる変化のことを話していきたいと思います。ここまでが前提です。

（次回に続く）