今年、はじめてのアドベントカレンダーに挑戦しています。
本記事はワインバーグさんにまつわるAdvent Advent Calendar 2025の23日目の記事です。
読書メモ。2025年78冊目。（2025/12/23記載）
10年ぶりに読んだ『ライト、ついてますか』の感想をまとめます。
10年前に自分が何を学んだかのふりかえりと、今の学びを整理します。
10年前のワインバーグ
10年ほど前、エンジニアの私にとってひとつの転機がありました。
エンジニアとして8年目ぐらいを迎えた頃ですが、それまでSES企業で与えられたタスクをこなしていくことが中心の仕事の進め方をしていました。
それが、プライムでのエンジニアリングの仕事をする環境に移り、それまで以上に自分で考えることが重要になっていきました。
そして、それまでまともに読んでこなかった技術書を読み始めました。
『エクストリームプログラミング』、『達人プログラマー』、『人月の神話』、『リーダブルコード』など名著と呼ばれるものを読み込んでいった記憶があります。
そのなかに、ワインバーグの著作がありました。
最初に出会ったのが『ライト、ついてますか』だったのか、『スーパーエンジニアへの道』だったのか、今では覚えていません。
ただ、その頃の私にとって大きな学びになったことだけは覚えています。
今のように一冊ずつ感想を書き留めることをしていなかったため、当時の自分が何を学んだのかを今になっては思い出すことができません。
今回も調べて見つかったのは『スーパーエンジニアへの道』に対する簡単な感想だけでした。
最近、ワインバーグさんのこの本を読んでいます。いわゆるリーダーシップについての本。1991年出版ですが、名前以外は古びない。リーダーシップとは絶対的なものではなく、有機的なものであるという出だしから、考えさせられます。とても面白い。https://t.co/hqW9nZ9cGb
— 幡ヶ谷亭直吉@技術書典19こ07 (@asagayanaoki) 2016年1月14日
ただ、それ以来、自分にとって『ライト、ついてますか』がずっと記憶にこびりつく一冊になっていました。
いつか読み直したいと考えていたところ機会を見つけられずにいました。
今回、o0hさんがワインバーグに関するアドベントカレンダーを開始するというツイートを見つけ、これを機会にとありがたく参加させていただきました。
10年前の『ライト、ついてますか』を思い出す
今回、『ライト、ついてますか』を読んで驚いたことは、確かに当時読んだはずで、自分にとって大きな学びになったと思ったはずが、内容をほとんど覚えていないことでした。
ただ、読みながら気づいたことは、当時読んだ他の書籍と違って、エンジニアの話に限定せず本を楽しめたことでした。
技術書を読むよりも、ヴォネガットやブコウスキーのようなアメリカ文学の系譜として楽しんでいたのかも知れません。
また、20代の頃の2次請け、3次請けでのエンジニアとしての経験から、「問題」に対する間接的な立場から気づきが大きかったのだと思います。
10年ぶりの『ライト、ついてますか』を味わう
10年に1度と言わず、1年に1回でも学びのある一冊と思いました。
抽象度が高いため、その時々の自分が置かれたコンテキストに沿って気づきがありそうです。
今回も多くの学びがありました。メモした内容からふりかえります。
メモ
問題の共通理解
自然発生的日常的な問題を、曖昧さを含まない一つただ一つの形で定義することなど不可能である。だが一方、問題についての何らかの共通理解がなかったら、解答を出してみたところで、まず間違いなく間違った問題に対する解答と成り終わる。
ふりかえりを最善の改善策を出すためではなく、課題に対するチームとしての認知の醸成のために扱うことの重要性と同じだと気づきました。
問題という抽象度の高い事象を、より具体的なレベルですり合わせる必要がある。
目的と手段
ユーモアのセンスのない人のために問題を解こうとするな。
目的は問題解決そのものであって、問題解決に当たる手段ではない。
ただし、手段にこだわる人に対して、いくら最適な問題解決のための手段を伝えても、理解は得られないかも知れない。
手段の目的化
解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意
手段にこだわればこだわるほど、問題解決という目的を見失いがち。
また、エンジニアとしての経験を積めば積むほど自分の経験がノイズになります。
それも、過去の経験が目的から焦点をそらし、手段に対する選択肢を狭めている気がします。
設計家の不適合
問題の転嫁という問題は設計家、つまりほかの人々のために問題を事前に解くことを商売にしている連中の存在によって一層面倒なことになる。設計家はビルの持ち主と同様、自分たちがやったことのもたらす結果を経験するということのまずないものである。だから設計家は絶えず不適合を作り出す。ここで不適合とは、その解決策とつき合わなければならない人間とうまく合わないような解決策のことをいう。
『エクストリームプログラミング』でケント・ベックが書いた、「アレグザンダーは、建築家の自己中心的な関心事は、施主の関心事と一致していないと指摘している。建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、重要な情報を見逃している。それは、施主がどのように生活したいかという情報だ。」との共通点を感じました。
今年自分が『The DevOps ハンドブック』で学んだ関心事の一致の重要性について、今年10年ぶりに読んだ2冊に書いてあったことに驚きました。
自己組織化
他人が自分の問題を自分で
完全に解けるときに、
それを解いてやろうとするな関係者たちは問題についてよりよく理解し、感じをつかんでいた。また彼らの解答は「自分たちの」解答だったから、それを実施して行く上での気の入れようが違っていた。
おせっかいは本人のためにならない。
いかに本人たちが自分たちで問題を解決できるように支援をするのか。
その問題が解消する経験自体が本人たちの成長に繋がる。
気づきを促す
彼女はまた、およそ免許をもっているほどの運転者なら、何もかもいってやらなければならないほどパかではない、と仮定した。彼らには
ライト、ついてますか？
とだけいってやれば十分なのだった。もし彼らがそれでは間に合わない程度にしか頭がよくなかったというなら、彼らはバッテリー上がりよりはもっと重大な問題にいくらでもぶつかっているはずであった。
「SREがいるだけで本番障害が減る」、「QAがレビューするというプロセスがあると、レビュー前にも品質があがる」といった話を聞いた覚えがあります。
誰かにとやかく言われたことは残らないので、いかに本人たちが気づく状態を設けるか。
価値実現
それはすべての問題解決志望者が、 およそどんな問題にであれ、本気で問題に手をつけようとする前には必ず発してみなければならない問いなのだ。それはこうだ。
私はそれを本当に解きたいか？
こんな問いはショッキングに見えるかも知れないが、「解答」が得られてみたらそれはちっともほしいものではなかったという事例に、もうわれわれは何度もお目にかかっている。
問題を解くことで何を実現したいのか。解く前に考える。
解く価値が無い問題は、いくら解いても仕方がない。
ましてや、本書が翻訳された1987年より、私が読んだ10年前より、今の方がずっと時代の変動が大きいし、問題の解答に対する価値観も移ろいやすい。
まとめ
10年ぶりに読んだ『ライト、ついてますか』に今回も多くの学びを得ることができました。
問題、または問題解決という普遍的で抽象度の高い内容だからこそ、その時その時の置かれた状態に置き直して読むことができるのだと思います。
また、その抽象度の高い内容を更に物語形式で表現しているため、本当に理解し切るためには何度も読む必要がありそうです。
今度は10年と言わず、思い出したタイミングで読み直したいと思いました。
最後に
今回、きんじょうさんのアドベントカレンダーのおかげで『ライト、ついてますか』を読み直すことができました。
また、読後にreadline.fmの特集を聞いて、書籍に対する理解を深めることができました。
きんじょうさんの本の話を聞くといつもわくわくして、つい積んでしまいます。
貴重な機会をありがとうございました。
