続・技術的負債というメタファーについて
昨日 技術的負債というメタファというエントリーを書いたけれども、それから少し考えてみたら、間違ってたかなと思う所があったので、続編エントリーを。
わたしの感覚ですと、okuさんのエントリーの「汚い方」――Smart UI と、「綺麗な方」――Layered architecture で作られたソフトウェアは、同じものの汚い/綺麗というよりも、たまたまある領域では同じ目的につかえるけれども本質的には全く別の製品であって、それをわたしは「プレハブ」と「きちんとした家」に喩えました。
そして「プレハブで十分なところにきちんとした家を立ててもしかたがない」というジャッジが、真か否かを問うのに「技術的負債」というメタファに基づくモデルで語る領域じゃないんじゃないかしら？――というのが前回のエントリーのダイジェスト。
だけれども、わたしが間違っていたのは、okuさんの文脈でも技術的負債についてはすでによく語られていて、例えばファウラーの以下のエントリーはそのものズバリということになります。
ファウラーのエントリーでは以下、「プロジェクトのスタミナ」というキーワードを元に、このジャッジメントについて考察が続きます。
設計に関する作業には時間も労力もかかる。それは間違いない。でも、それだけの価値はある。 将来そのソフトウェアを成長させるのが楽になるからだ。設計をサボったら、短期的には時間の節約になるだろう。 でも、そのぶんだけ技術的負債はかさみ、後々の生産性を落としてしまう。 ソフトウェアの設計に力を入れると、あなたのプロジェクトのスタミナが向上するのだ。 成長する速度も上がり、長生きできるようになる。
設計を軽視したプロジェクトの問題は、設計を軽視したが故に、 コードベースがだんだん劣化して変更しづらくなるということだ。 その結果、生産性も下がる。というのが、グラフの勾配にあらわれている。 きちんと設計をすれば生産性もきちんと維持できるので、ある時点（design payoff line：設計償却線） に達すると、設計を軽視したプロジェクトよりも累積の納品量が上回るようになる。 そしてその後は、ずっと上回ったままだ。
この仮説から、こんな系を導ける。設計償却線に由来するものだ。 最初のリリースに含まれるある機能が仮にこの線より下にあるとすると、 設計を軽視してでも開発速度を追い求めた方がいいかもしれない。 でも、もしこの線より上にあるのなら、そんなトレードオフはまやかしだ。 納品予定の機能が設計償却線を上回る場合は、設計を無視すれば、必ず納期は遅れる。 これを技術的負債の用語で言い換えると、融資を受けたのにその元金をずっと使わずにいる状態に等しい。 ある一定の時期を過ぎてから使い始めると、支払う利息が増えてしまう。
oku さんの エントリーはファウラーのこのエントリーの payoff line がどこにあるかを 負債というメタファーでバインドした金融のモデルにて検証しようとしたもので、面白い試みです。ただ、この payoff line については ファウラー自身は
ここで気になるのが、じゃあ実際のところ、設計償却線はどのあたりにあるのかということだ。 設計＝スタミナ説に賛同してくれる人たちの間でも、この件については大きな見解の相違がある。 私は個人的に、一般に言われているよりもずっと低い位置にあると思っている。数ヶ月ではなく、数週間というあたりだ。 しかし、これはあくまでも個人的見解だ。
と言っていて、わたしもそれに同感です。
okuさんが例として示した「年単位の運用 / Smart UI VS. Layerd architecture」 では、なんぼなんぼでも「そんなトレードオフはまやかしだ」に該当するかと思われます。つまり okuさんのエントリーは「例」がいささか非現実的に感じるので、大本のアイデアも眉唾に感じてしまったということです。
ですが、そういう ノーデザインとグッドデザインの選択 自体を技術的負債という文脈で語る事自体は 的外れではないので、わたしの先のエントリーはダメダメでしたね...orz
* * *
その反省の上でもう一度語るならば、技術的負債は 運用保守にのみ関わるのではなく、リリース前の開発中の生産性にも関わるので、「初期開発コストと運用コストのバランス」の「初期開発コスト」として、SmartUIは そもそも安くつくのか？に疑問を感じます。
本当に「クソコード」は 初期開発コストが安くつくのか？ という問について、現実的なプロジェクトでは、概ね否かと思われます*1。喩え3ヶ月程度の短納期プロジェクトであったとしても、どんなに仕様がシンプルに思えたとしてもです。「安くつく」という感覚は、ファウラーのいうとおり「まやかし」に過ぎません。
では、oku さんのアプローチが当てはまるケースがないのかというと、それは「きちんとした設計」の中での「可能性への拡張性」へのジャッジメントとして、あるいは「きちんと設計仕様としたけれども、負ってしまった負債を返却すべきか」のジャッジメントとして、生きてくる話なのかな、と思います。「今から思えばこのモデルは間違っていた」というのを 直せずに保守し続ける……というのはよくあるお話であって、その「直したほうが得か否か」を客観的に判断できるのであれば、それはとてもナイスなことです。
ファウラーも語る通り、生産性は計測不能 だし、設計の品質もまた計測不能なので、okuさん的なお話で正しいジャッジを出来るのかについての検証は非常に困難に思えますし、できるとしても実際に適用する段において 正しいパラメータを導き出せるのかは、やはり難しいように感じます。
ですが、その「難しい感じ」を、金融のモデルを「技術的負債」に当てはめるアプローチがうまく扱えるかも、という話になっていると聞きおよび、「技術的負債」が比喩を超えてそういう面白いことになっているということを今日まで全然知らないでいましたので、きっかけを頂いた oku さんのエントリーには感謝です。
まとめにかえて
okuさんのところで紹介されていた
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays
のスライドがとてもよかったです。
古典的な（=わたしの）「技術的負債」についての認識を
- 適切に返却される分には、開発のスピードアップという意味では、むしろ望ましことですらありうる
- “技術的負債”は、技術者間のみならず、非技術者との間でのコミュニケーションに役立つ比喩であるべき
- そのために、どういう“負債”があるのかを分類・整理する
- まず意図的か、非意図的かに分類できる。次に無鉄砲に行われたか用心深く行われたかに分類できる
- そもそもこの比喩は「ダメなコード」を意図的に書くことを支持するものではない。そうではなく、あとでリファクタリングできるという認識が大事
と簡潔にまとめた上で（特に最後の１項が超大事！）、「技術的負債」という比喩がひとり歩きすることによる問題に触れ（前回のエントリーで書きたかったこと）、それでもあえて比喩を更に押し広げてみることに有用性を見出す
- 不確実性のもとでの意思決定プロセスについては、経済学やファイナンスにおいて蓄積がある。そうしたモデルが役に立ちうる(Kruchten et al.,2012)
- “負債”という比喩の可能性をもう少し押し広げてもよさそうだ
という面白いアプローチについて説明していて、読みやすく、誤解に基づく批判に先の杖をついてある、納得しやすい良資料でした。
ちゃんと読んでからエントリーを書けばよかったですね...。
