レガシーモダナイゼーションについて書かれた「Kill It with Fire」を読んだ
- 「Kill It with Fire」は「レガシーモダナイゼーション」について書かれた良書である
- 過酷なレガシーモダナイゼーションを成功裏に終わらせるためのフレームワークが説明されており、考え方の参考にできる
- 日本からでも電子書籍を容易に購入可能
「Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)」という目を引くタイトルの本を読んだ。なかなか有用な本だった。この本は割と最近発売された本で、当然ながら日本語訳なんてものは存在しない。
どんな本か
技術的負債（Technical debt）に対して適切な措置を怠り続けた結果、拡張性や保守性が悪くて維持管理コストも高い陳腐化したシステムが出来上がってしまうことがある。
これはある程度長期にわたり運用されたシステムだとよくあることだろう。
これらの問題を解消して近代化を図る一連の作業は レガシーモダナイゼーション と呼ばれている。この本はレガシーモダナイゼーション計画を実行するための方法論について書かれたものである。技術的な何かだけでなく、非技術的な障害への対応とかマネジメントとかに多くが割かれている本である。
ちなみにInfoQに著者へのインタビューが掲載されている。こちらも見ると良い。
https://www.infoq.com/articles/modernize-maintain-future-proof-systems/
この本において一貫している考え方
- 古いシステムは価値をもたらしている成功したシステムである
- レガシーモダナイゼーションは非常に難しい
- momentum（モメンタム・ヤル気・勢い）は重要で、momentumを喪失すると失敗する
- レガシーモダナイゼーションを行う理由は、流行に乗るためではなくさらなる価値をもたらすためである
全体的な感想
なかなかおもしろかった。自分の中ではかなりオススメな本。
実際に陳腐化した有用なシステム（つまりレガシーモダナイゼーションの必要があるシステム）と向き合っている私にとっては有用だった。
レガシーシステムとかレガシーコードを取り扱った多くの既存の書物は「古いシステムはヤバイ」みたいなことしか書かれていなかったり、エンジニア主体での技術寄りの考え方（例：レガシーコードを書くのをやめてコードの質を上げるためには）しか書いてなかったりする。
しかしながらこの本は（少なくとも日本国内で流通している）多くの書物と違い、方法論（技術的なものも、非技術的なものも）を主に取り扱っている。
この手の知識は意外にも体系的に文書化されているものが少ない。なのでこの手の知識を得られるという意味では貴重だった。
この本には考え方のフレームワークが色々と書かれており、どんなシステムでも使える万能ソリューション（銀の弾丸）が書かれているわけではない。
そのままの形で実業務に役立てるという感じではないが、考えるきっかけとしては間違いなく有用だろう。
この本で取り上げられている内容は正直言って泥臭い。読めば読むほど、ああこれあるあると思ってしまうかもしれない。
ある程度以上の経験を積んだエンジニアであれば誰しもが経験していそうな気がする。だからこそ自分だったらどうするかというのを考えられそうに思う。
あと、この本は
レガシーモダナイゼーションの必要があることを大前提に書かれている
ので、レガシーモダナイゼーションするかしないかの判断は別である。
たとえば価値をもたらしていないシステムは維持する必要がないのでシステムを捨てるという判断ができるし、最新システムについていけない人間や業務を見捨てる判断ができるなら躊躇なくシステムのスクラップアンドビルドができるだろう。
そもそも「Kill It with Fire」ってどういう意味？
直訳すれば「火で殺せ」だが、これは極端な嫌悪感を示すインターネットスラングである。日本語圏では見ない表現ではある。
この本における「Kill It with Fire」とは何か？
陳腐化したシステムを目の当たりにした経験の浅いエンジニアが、「こいつは超古いレガシーシステムだ！クソコード！」って感じの極端な拒否反応を反射的にすることがよくある。まさに「Kill It with Fire」である。
このような過激な反応から急進的な意思決定を行った場合、大量の資源と時間をとりあえず投入することに繋がる。
そして長期的に良くない結果を生んだり、他部署や他社からの信頼を損ねてしまったり、そもそも計画が終わらず頓挫してしまったりする。
技術的に難しいから失敗するのではなく、技術面以外で失敗してしまうのだ。
ある程度以上の経験を持つエンジニアなら、一度はこんな感じのシチュエーションを実体験しているのではないだろうか。
結局のところ、
陳腐化したシステムをガムシャラに力づくで新しくするだけでは価値をもたらさない
のだ。
この本ではそのような「Kill It with Fire」をふまえて、過酷なレガシーモダナイゼーションを成功裏に終了させることについて書かれている。
つまり本の内容と過激なタイトルは逆である。
購入方法
日本からだとAmazonでKindle版を購入するのが一番お手軽だと思われる。
Kindle版で不満があるのなら、No Starch Pressから買うと良い。PayPalで決済可能。
https://nostarch.com/kill-it-fire
目次と概要
日本語訳については内容の正しさを保証しない。気になるなら本を買って読んでほしい。
初めの2章で陳腐化したシステムが生まれてしまった理由について考察するための手がかりを示し、以降ではレガシーモダナイゼーションの際に遭遇する課題を解決する手法について述べている。
Chapter 1: 歴史は繰り返す（Time Is a Flat Circle）
1960年代から現代までのテクノロジーの歴史について触れ、テクノロジーの進歩は長い歴史で同じアプローチを繰り返しながら少しずつ進んでいるということが書かれている。
Chapter 2: 共食いコード（Cannibal Code）
なんでこんな題なんだと思うかもしれないが、これは本文を読めばわかる。
この章では人間の都合や歴史的経緯で決められた「人工的な一貫性」と、それと対比する「技術的な一貫性」について書かれている。
人工的な一貫性を説明するための例として、以下をあげている
-
コーディング規約がなぜか1行80文字のルールを守っている
- 現代は高解像度ワイドモニターの時代なので、あえて守り続ける理由はないはず
-
LinuxはUnix風のルックアンドフィールをそのまま使い続けている
- Unixとコードのつながりを持たない、いわゆるUnixライクシステムのことを指している
-
コンピューターの黎明期にはALGOLではなくCOBOLが流行った
- ALGOLは現代につながるプログラミング言語の要素を一通り備えている
- COBOLはコンピューターについて詳しくない人でもとりあえず使える
人工的な一貫性は技術面以外での利益を得るため、あえてもうけられていることがある。
全体を通して、エンジニアは技術的な一貫性の価値を過大評価しがち（人工的な一貫性の価値を過小評価しがち）だが、良く考えたうえで難しい決断をするべきだということが書かれている。
Chapter 3: アーキテクチャの評価（Evaluating Your Architecture）
レガシーモダナイゼーションのためには、計画をまとめることが必要である。
そのためには、まず現状を評価してシステムの癖を知ることが重要である。
特に「技術的負債」「パフォーマンス問題」「システムの安定性」といった3つの典型的な問題を例として、問題解決のためにはどのような観点から評価すれば良いかということについて書かれている。
Chapter 4: なぜレガシーモダナイゼーションは難しいのか？（Why Is It Hard?）
レガシーモダナイゼーションは非常に難しく、失敗することが多い。その理由について書かれている。
あえてこれ以上の内容は書かない。ある程度の経験を積んだエンジニアであれば、この章の内容に既視感があるのではないだろうか。
Chapter 5: やる気の構築と保護（Building and Protecting Momentum）
（注：ビジネス系メディアではカタカナ語の「モメンタム」をそのまま使用している例が多いが、私は日本語で書きたいので「やる気」ということにしている）
近代化改修計画は、途中でやる気がなくなったために頓挫するケースがかなりある。
このように意気消沈によるプロジェクト失敗を防ぐためにはどうするべきか、何がやる気を生み何がやる気を削ぐのかについて書かれている。
Chapter 6: レガシーモダナイゼーションへの途中参加（Coming in Midstream）
ここまでは、レガシーモダナイゼーションに計画段階から参加する場合について書かれていた。
でも現実はそうはいかない。
暗雲が立ち込めている進行中のレガシーモダナイゼーションに、途中から助っ人として突っ込まれたりするのだ。
このような場合に、問題が悪化しない状態まで持っていくための動き方について書かれている。
Chapter 7: 運命としてのデザイン（Design as Destiny）
（注：何を言いたいのかはなんとなくわかるが、良い日本語訳が思いつかなかったので一旦このような題にしている）
ここで言われているデザインは、いわゆる「デザイン思考（Design Thinking）」のDesignである。ゆえに日本語の「デザイン」よりも意味は広い。
この章では、デザイン思考を技術面での意思決定やインセンティブ設計に応用し、チームが自律的に問題を定義できるようにすることについて書かれている。
ちなみに、解決方法ではなく問題の定義に重点を置くというのはデザイン思考の基本的な考え方らしい。 https://blog.btrax.com/jp/design-thinking-difference/
Chapter 8: 破壊的変更（Breaking Changes）
レガシーモダナイゼーションでは何らかの大きな変更を加えることになる。
もちろんいつも完璧に成功するわけがなく、大抵は多かれ少なかれ事故る。
この章では失敗を恐れず挑戦することと、失敗から学んで強くなることについて書かれている。
Chapter 9: レガシーモダナイゼーションを終わらせるには（How to Finish）
システムは無限に更新され続けることも多く、システムの開発には終わりがないかもしれない。
しかしながらレガシーモダナイゼーションには終わりが存在するはずである。
この章では、レガシーモダナイゼーションの完了のためどのような目標を定めるかについて書かれている。
完了条件が定義されていない場合、終わりそうで終わらなくなり最終的に頓挫してしまうのだ。
Chapter 10: 将来性の担保（Future-Proofing）
レガシーモダナイゼーションが完了すればもう改修はない…というわけにはいかない。
使用方法が変わったり、単純に劣化したりといった理由で改修が必要になる。
ここまでの記述のとおり、レガシーモダナイゼーションは非常に手間のかかる特殊で大規模な作業である。何度もやりたいものではない。
この章では、システムを通常の作業で容易に保守可能にすることについて書かれている。
つまり、再度のレガシーモダナイゼーションを不要とするにはどうするかということである。