技術書は気に入った一節を見つけるだけでいい
ということで、私の例をいくつか出してみようと思います。
モノリスからマイクロサービスへ
マイクロサービス・アーキテクチャの著者による、モノリスからの移行をガイドするような雰囲気のするこの本ですが、この本は第6章「終わり」にから、この一節です:
他人の事例から学ぶべき教訓があるのは事実だが、自分のコンテキストでうまく機能するアプローチを見つけるには、時間をかけなければならない。
これはあらゆるプラクティスに言えることで、私は事あるごとに「スクラムをそのまま導入するのは無駄だ」とか「守破離っていうやつは苦手だ」とか言い続けているんですが、それはつまり、先人のプラクティスは様々な状況（コンテキスト）があるなかで成功した事例であり、コンテキストが異なる現場に持ち込んでもうまく機能するかは未知なのです。なので、そのプラクティスが前提としているコンテキストとソリューションを理解しつつ、自分たちのコンテキストを理解しつつ、何ができるかを探る必要がある。マイクロサービスもそれを失うと、境界を失ったコンポーネント群の複雑なネットワークができるだけのはずです。
オブザーバビリティ・エンジニアリング
私が翻訳に関わることができた（光栄なことに！！）この本からは、第10章「オブザーバビリティへの取り組みをチームへ適用する」の2節「最大の問題点から始める」を紹介しましょう。この節のタイトルで、もうすでに素晴らしいですね。
簡単に始められる問題を選んではいけません。オブザーバビリティが使われることを期待されるような難しい問題を選んでください。
新しい取り組みを始めるとき、「小さく始める」ことの重要性がしばしば語られます。まあそれはそれで重要なやり方ではあるんだけど、小さく始めるというのが効果的であるとも限らないどころか、そのトライの効果が低く見られてしまいがちというのが、この節で警告されていることでしょう。あなたに必要なのは、何かにトライすることでしょうか？それとも、課題を解決することでしょうか？
レガシーコード改善ガイド
「テストがないコードはレガシーコードだ」という、これほど明確かつ効果的な定義は、レガシーコード業界や技術的負債業界において、他に見たことがありません。まあこれも一節といえばそうなんですが、「定義」ではなく「一節」を引用してみます。第24章「もうウンザリです。何も改善できません」から。これももうタイトルで期待が最高潮です。
私は、数百万行ものレガシーコードを扱っているいくつかのチームを訪れたことがあります。これらのチームは、毎日が挑戦であり、物事をより良くする機会であるととらえ、仕事を楽しんでいました。はるかに優れたコードを持っていても、落胆しているチームを見たことがあります。仕事に対する姿勢が重要なのです。
この本が書かれたのは2004年。この記事の執筆時点では、21世紀ももうすぐ四半世紀が過ぎようとしています。私がウェブ企業に転職したのは12年前、2011年の頃でしたが、最初の仕事の多くは、既存コードをテストコードでカバーする必要がありました。一方でここ2-3年で作られたコードはおそらく20-30年前に作られたコードよりもモジュール化され、実行効率もよく、ドメインの課題がよく表現されたコードになっているはずです。もちろん、テストコードも一般的になってきている。そんな中でもやはり、状況にそぐわなくなってきたコードは多くあります（おそらくこれが「技術的負債」の一つの形態でしょう）。それをなんとかするにはどうしたらいいのでしょうか。開発者体験というキーワードを出す人もいますが、うーん、どうかなぁ、一般論として従業員満足度は重要ですが、結局、解決するのは開発者自身であり、何かを「より良くする」にフォーカスするマネジメントだと思うのでした。
システム運用アンチパターン
20年近く前にタイムスリップしてしまったので、すこし現代に戻ります。冒頭第1章「DevOpsを構成するもの」の1.1.2「DevOpsは何でないか」から。
ツールは価値を提供しません。DevOpsはまず人、次にプロセス、そしてその次にようやくツールについて考えるのです。
オブザーバビリティのようなソリューションを売り込む職業としてよく語られるのは、「うちのツールはこれができます！」みたいなツールのケーパビリティをプッシュすれば売れるわけではなく（いや、実際、それでも売れてしまうんだけど）、「あなたの課題はこうやって解決できます！」という売り方をやろうという話題で、まあそれはそうなんですよね。ツールはベストプラクティスの実装であり、上で書いたようにプラクティスはコンテキストに対して有効であり、コンテキストはそれぞれの現場にある。つまり、ソリューションとコンテキストをつなぐのが我々のような存在であるわけです。それをつなぐためには、「我々の課題はなんだろうか」ということを検討して認識し、解決するためのアイデアにオープンな状態を作っておく必要がある。そして、そのためには、21+1/4世紀の技術水準で使えるツールについて、ふんわりとでも知っておく必要がある。何かをやるには、リテラシーがもっとも重要です。プラクティスやツールについて背景を含めて理解し、そしてそれを使わないことを躊躇しないようにしましょう。
アジャイル・レトロスペクティブズ
また昔に戻りました。忙しい。「ふりかえり」のプラクティスを紹介しているこの原著は2006年なのかな、日本語訳は2007年のこの本からは、第1章「レトロスペクティブ -- チームの点検と改善」の1.2「データを収集する」から、Carlyという人物がプラニングミーティングでブチ切れたことを反省する下りで、この一節です:
「Carly、君が冷静じゃなかったことはみんな分かっているんだ。でも、君が話してくれたからこそ、問題を解決することができたんだよ」
ブチ切れるという状況がどこまで酷かった想像するのは難しいとして、人間は時として（常に？）感情的なものであり、うまく行かない状況に苛立ち、それが表面に出てしまうこともあるでしょう。みなさんはよくできた社会の大人なので、ブチ切れることは良くないことであり、反省するものであろうと思います。本人のネガティブな感情をいつまでも引きずることなく、共有し、他の人の視点を入れることで、次に進むことができる。そういうことを表明する場面としても「ふりかえり」は有効なわけです。現代において「心理的安全性」として語られる状況を作るための、一つのやり方じゃないですかね。
エリック・エヴァンスのドメイン駆動設計
いわゆる「DDD本」として有名で、かつ、内容について度々面倒な議論が起こりがちなこの本ですが、これもから20年前、2003年に書かれた分厚い本です。第8章「ブレイクスルー」の冒頭から:
この種のブレイクスルーは、テクニックではなく、出来事である。
この文章に行き着くまでも重要なんですが、「一節」というに若干長いので詳しくは読んで頂くとして、つまり、リファクタリングで徐々に整理していくとそういう小さな改善だけではどうしようもなくなる場面は出てきて、「こりゃーなんとかせんといかんな」という状況に遭遇するらしいです。しかもそれは、いつ来るか事前に予測するのは難しいし、もしかして来ないかもしれない（それはそれで、ドメインモデルがいい感じに作られている証拠かもしれません）。こういう「本格的になんとかせんといかん」という状況って、みなさんぶち当たっているものでしょうか？そこから実際になんとかできる状況にいますか？この分厚い本には、このブレイクスルーにぶち当たる前後の状況がいろいろ紹介されていると考えることもできるので、そういう視点で眺めていただくと良いかなと思うことがあります。個別のパターンやプラクティスに着目した議論が多すぎて、DDD論争には不毛さを感じます。
まとめ
ということで、本棚を眺めて、なにかまとめられそうな本をピックアップしてみました。なんか私の傾向が出てしまってますね…。ここで紹介した本以外にも「気に入った一節」を持つ本はもちろんありますし、ここで紹介した本の中でも、他にも多くの「引用すべき一節」があるはずだと思っております。
みなさんはいかがでしょうか？
Discussion