Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays

マネジメント

JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。

ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライドにあるような話をしました。

「技術的負債」についてはよく語られ、盛り上がる、ネット上の技術論壇の定番ネタという感じで、いまさらなにか付け加えることもなかろうというものではありますが、そのあたりについていろいろ調べたりしており、巷間出回っている議論が不十分に思っていたので、この際だからとまとめてみました。しかし、本来はファイナンス理論を導きにモデルを作って検証するというプロセスを踏むはずのものなので、上述の通りまだ生煮えなものです。

とはいえまあ、あらためてTechnical Debt周りの論文、Web上の文書などを総覧して感じるのは、まだまだこの辺の議論は理論的整備がまったくもって充分には行われていない、ホットなものだなあということです。

特に、スライドにもあるように、近年の研究はネット上での議論とはだいぶ離れてきていて、かつ、ファイナンス理論の援用についてようやく端緒が開かれ始めたばかりという状況。自分自身、ざっくりとしたアイディアベースではあるものの、そうしたことを書いてきたので、発表や実践の形式は色々あるでしょうが、そういう問題についても、よりよい議論ができればと思っているところです。

また、トークの後には、トラック参加者全員によるパネルディスカッションが行われ、IIについてうるさいおじさんたちがあれこれ話すという感じでした。そこでも話しましたが、IIにせよなんにせよ、単にいままで行われてきたことに名前がついただけだよね、というものであるにせよ、そうした概念により問題についての認識が一般に可能となり、そのことでいまあるものがよりよくなっていくということはあるわけです。「技術的負債」という言葉も、そうしたものです。

ディスカッションの最後に、mirakuiさんの「Javaのようなライフタイムの長い言語によるシステムこそdisposableであるべき」という発言をうけて、「日本という国にはそうした伝統がある。伊勢神宮は長きにわたって継続してきたシステムだが、20年に一度作り替えられる。つまり、IIの前例をなしている。これを「式年遷宮アーキテクチャ」という」などといいましたが、元ネタは式年遷宮Infrastracture - さよならインターネットですので、合わせてご報告しておきます。

追記

この件、表現が難しいなあというものあって、スライドでうまく示せていなかったですね。「負債」とその「利子」というこれまでの比喩にくわえて「割引率」つまり、投資家からみるとリスク = 期待収益率であり、企業から見るとコミットすべき目標と見ることで、以下の認識利得があり得ると考えています。

  1. 劣化した比喩を精緻化することで、コミュニケーションにとっての有用性を再度高める
  2. "負債"をBSの資本構成とのアナロジーに基づき内容を分類し直すことで、それぞれに対して有効な対策を採ることを支援可能となる

(1)について。スライドのMcConnelさんのとこで引用した通り、単に「いろいろ大変なんですよー。〜が〜なって(以下、技術的詳細が続く)」というより、「負債」という、会計的な意味においてビジネスのひとたちと共通の語彙を使うことでコミュニケーションに有用とされていたわけですが、いまではその比喩の対応の少なさによって、問題が生じていることを問題視しています。

それを避けるために、もちろん「技術的負債」という言葉を使わないという選択肢はありますが、この発表では、その比喩をさらに「会計的な意味において」精緻化することで、その言葉が本来持っていた機能を回復できるのでないか、という意図を持っています。そのことにより、技術的な課題が経営層がふだん考えているような問題と対応しやすくなり、よって、そうした課題が解決されやすい状況が生まれることを期待しています。

(2)について。いままでは、全体的になんとなく「技術的負債だよねー」みたいなことになっていたわけですが、

  • 「負債」とその「他人資本調達コスト(利子)」のような、比較的安定していたり、ある程度コントロールが容易だったりするもの
  • 「資本」と「自己資本調達コスト」のような、比較的不安定であり、コントロールが難しいもの

という区分にそって技術的・組織的課題を分類することで、それぞれに対してより有効な手立てを考えられるのではないか、という感じです。

追々記

Kazuho's Weblog: 「技術的負債」をコントロールする定量評価手法への期待で言及していただきました。上述の「本来はファイナンス理論を導きにモデルを作って検証するというプロセスを踏むはずのもの」というのは、まさにkazuhoさんの記事で述べられているような定量的手法を探るということです。また、ソフトウェアエンジニアとして日々感じている技術的選択の問題についても、問題意識が一致しているように思います。

プラクティカルな定量的評価手法をどのあたりに落とすかというのは考えどころであるにしても、(進学してたら)いったん既存の議論を学習・整理した上でやってみたいと思っていたのですが、まだ具体的にこんな感じというイメージが描けていなかったので、どちらかというと定性的な面にスライドではフォーカスしている感じです。

ファイナンスとか金融工学との接合という意味では、たとえばReal Options Analysisなどは、まさに使えそうな感じがしています。ただその場合、それはつまりそういう理論を使えばいいだけなのでは？という話に限りなく近づくのかなあという気もするし、いちエンジニアとしてはそういう話でもないんだよなーとも思うので、定性的な整理というのもまた必要だとは思うわけです。