レガシーシステムと人生

Sansanアドベントカレンダーの3日目。

10月にｼｬのブログに記事を書いたのだが、そのとき「技術的負債」「レガシー」のどちらの言葉を使うかでけっこう迷った。ためしにググっていろいろな記事を漁ってみても、これらを区別していないケースのほうが多い。結局、実際の世の中では誰も気にしていない、という結論に至って「レガシー」を採用した。そんへんから書き始めて、レガシーのつらみから救われたい話とか、つらい人へ向けてポジティブな話を書いてみる。

技術的負債という比喩

「技術的負債」という言葉は、Ward Cunningham*1によってOOPSLA '92で発表された。1992年といえば、スーパーファミコンマウスが発売された年らしい。これはまったく関係ない。

ウォードは開発コストの増大を説明するために、会計的な「負債」という比喩を導入した。これがバズった（しらんけど）。

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.
出典: http://c2.com/doc/oopsla92.html

雰囲気、だいたい以下のようなことを言ってる。

最初にコードを出荷する行為は、負債を負うようなものである
多少の負債は、適切に書き直せば（＝負債を返済すれば）、開発スピードを向上させる
返済されないままでいると、「正しくないコード」によって時間（＝利子）が費やされる

その後Martin Fowler*2が、技術的負債を4象限に分類した。

To my mind, the question of whether a design flaw is or isn't debt is the wrong question. Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking.
出典: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

ウォードの報告やファウラーの記事においても、「技術的負債」という言葉は「メタファ」と読んでいる。メタファって雰囲気で比喩のことと知っているけど、実際はなにか。

メタファーの本質は、ある事柄を他の事柄を通して理解し、経験することである。
出典: https://www.taishukan.co.jp/book/b196366.html

メタファが本来持つ情報を付与することで、対象のある側面を説明することができる。注意すべきは、「ある側面」の射影であり、決して対象全体を表さないということ。仮に対象全体を表すとしたら、それは対象そのものやん、となる。

「技術的負債」においては、（本来の）会計的負債がもつ「利子」という構造を使って、技術的な情報を用いず技術的な課題を説明することになる。そのため、技術的負債というメタファがもっとも価値を発揮するのは、「技術的な課題は理解できないけど、（会計上の）利子という概念は理解できる」人間に対して、開発コストの消費を伝えたい場合になる。一般にその人間は経営層やマネージャだったりする。「このままだと利子を払い続けることになりますよ！！」みたいな。

ファウラーはそれを前提とした上で、「利息を払うことを選ぶか元本を返済することを選ぶかという判断」を委ねる際のさらなる情報として、技術的負債の分類を試みている。どういう経緯で生まれたものなのかがわかっていたほうが、判断しやすい。

objectmentor.booked.net

ここまでで明らかなとおり、「技術的負債」という言葉は、偉い人に技術の言葉を使わずにつらみを伝えるのに便利。一方で、エンジニア同士が問題の解決に向けて会話するときに使うと微妙。情報の欠損が激しすぎる。また、メタファはどこまでいってもメタファであって、コミュニケーションのための言葉でしかない。「技術的負債」に変わる新たな「技術的〇〇」という言葉がでてきても、一側面しか表さない。問題そのものを表す情報は「技術的」という部分に丸められているから。コストを示したいなら「負債」はすごくいいし、実際に使い続けられている理由だと思う。

レガシーという暗示

技術的負債と並んで、「レガシー」という言葉もよく使われる。こっちは原典があるわけではなく、単にレガシーという単語自体の意味から、古くからあるシステムやコードの修飾語として使われているっぽい。レガシーも一種のメタファといえる*3。レガシーという言葉自体は、「歴史の一部」や「昔から残っているもの」みたいな意味を持っている。

something that is a part of your history or that remains from an earlier time
出典: https://dictionary.cambridge.org/dictionary/english/legacy

『レガシーソフトウェア改善ガイド』では、ソフトウェア開発の文脈におけるレガシーという言葉を、「保守または拡張が困難な既存のプロジェクト」と定義している。前述のとおり、「レガシーソフトウェア」という言葉自体がもつ意味は「昔から残っているソフトウェア」ということでしかない。我々エンジニアが暗に持っている「昔から残っているコードは、保守または拡張が困難である」という知識を使って、レガシーという言葉を再定義している。これは、修辞学的には「暗示」と呼ばれる技法になる。

比喩は一部分を切り取るのに対し、暗示は対象そのものの表現により近い。ただし、暗示に使った言葉について、情報を共有する人間同士で共通の知識が必要になる。例えば、前述のようにある限定された領域で「古い＝保守または拡張が困難」という定義が共有されていれば、同じ対象を想起できる。技術的負債と比べると、実際に起きている事象を表現していそう。ただ問題は、定義が十分に共有されていない場合、あるいは定義自体の解釈が人間によって異なる点である。極端にいうと、レガシーという言葉を原義どおりに理解する人は、「古いコードは悪」という短絡的な思考になっても不思議はない。不思議ではないというか、人間は忘れる生き物だし、そういうことは普通にある。

古いコードはつらい、みたいな発想は、プログラミングという行為が製造工程ではなく設計工程であることに起因していそう。例えば、「車をメンテナンスする」という行為は、車が古くなってきたら掃除したり一部パーツをつけなおしたり、みたいな印象がある。対して、ソフトウェアは論理なので経年劣化しない。車の例えでいうと、設計図を作りなおしながらつかっていくことに相当する。製造はコンパイラがやる。

工学的なみかた

比喩や暗示で表現する方法は、具体的ななにかに射影することで、説明しやすくなる。これは文学的アプローチっぽい。対して、エンジニアが対象の問題を解決するためには、実際に起きている事象を明らかにする必要がある。これはモデル化、抽象化、であり、工学的アプローチっぽい。技術的負債を計測する試みはそこかしこでやられているっぽい。理想のこの問題を本来的に何と呼ぶかは、新たな言葉が必要だと思う。変更可能（必要？）性と変更困難性の両方を含意する言葉があればいいのかもしれない。

ちょうど最近、以下の記事をみた。

ソフトウェアは数年単位で書き直しが行われる。これは多くのリソースを消費するが、これによって市場の需要と変化に迅速に適応する企業の能力が保証される。コードを書き直すことで、蓄積されたコードのレガシーと複雑さを軽減すると同時に、知識とコードの所有権を新しいチームメンバーに移転することが可能になる。出典: www.infoq.com

書き直す投資意識と技術力、さすがGoogleと思う一方で、ひねくれた見方をすれば、Googleをもってしても「負債にならないコードを書く」ことができていないことを示唆している。「負債を作らないようにつくる」ことはすごく大事だしその精神で最高の設計をすべきだけど、未来の不確実性はでかすぎる。成長するプロダクトだと特に。過去のだれかが設計をミスっているわけではなくて、それを継ぎ足し継ぎ足しされてきた結果でしかない。

アカデミックっぽいところでいうと、技術的負債をテーマにした国際会議もある。2020年で3回目らしい。

2019.techdebtconf.org

これからは工学的アプローチがどんどん進んで、つらみから開放されたい。とはいえ、2018のをざっとみると、一部限定条件下でモデル化を試みている研究もあるものの、大半は静的解析やツールの紹介に留まっている。ソフトウェアの本質的な複雑性がある以上、今後数十年はつらみが続く気がする。

キャリア的なみかた

レガシー改善ばっかりやっているというと、心配されることが多いけど、自分としてはレガシー改善だからしんどいみたいなことはあまりない。うまくいかないときはレガシー改善だろうが新規開発だろうがしんどい。要求されるメンタリティは違う気がする。しんどそうと思う人がなぜそう思うか考えてみると、「先人が好き勝手にやったあとをなおす、損な役回り」的な印象があるっぽい。少なからず「負債」という言葉の功罪かもしれない。

自分と周辺の環境にかぎっていえば、そういうことはなくて、他のプロジェクトと同等に評価してもらっている雰囲気がある。ｳｪﾌﾞっぽいことをあまりやっていないかんじもあるけど、ILを読んだり、わからなすぎてOSSのコントリビュータに凸ったりもしなければならない。大前提、技術力は必須。変更しやすくするには、変更しやすいとはどういうことか知っている必要があるし、現在の状態からあるべき姿へ進む戦略も含めると、相当な能力が必要とされる。その点自分は無力中の無力。全然できてないから、できるようになりたい。

先述のとおり、Google様でもつらみがあるし、学問が解いてくれるのはまだしばらく先になりそうな状況。加えて市況的にも、ソフトウェアの内製化が進みそう。

www.sbbit.jp

これまでは外部品質が品質の大半を占めていたが、内部品質の重要性がさらに高まるかもしれない。例えば、人間のモチベーションという貴重な資産もこれまで以上に評価されるかも。DX（Developer Experience）と呼ばれたりする。変更しやすいシステムにすることができれば、中長期的な事業価値になるのはもちろんだし、同僚エンジニアや自分がその価値を感じられる。これらをふまえると、「変更しやすくする」技術の価値はこれから高まる気がするし、ソフトウェアの本質的な課題に向き合うおもしろみもある。がんばってください。