この記事は、「ワインバーグさんにまつわるAdvent Calendar 2025」25日目の寄稿です。
本当は20日目の記事として寄稿したかったものの、師走のバタバタにやられた結果最終日の滑り込みとなってしまいました。アドカレは計画性を持って早めに書いておくべきですね、反省です...。
（師走は意外と後半の方がバタバタするので、前半に寄稿登録しておくのが吉かもしれない、と今年になって気がついた）
「ライト、ついてますか」は23日目の幡ヶ谷亭直吉さんの「10年ぶりの『ライト、ついてますか？』――過去と今の問題を捉え直す」でも取り上げられているので、そちらもぜひご覧ください。
愛聴しているポッドキャスト「readline.fm」で4回（EP147〜EP151）にわたって紹介されていて、そういえば読んでいなかったと思い読み始めたジェラルド・M・ワインバーグさんの著作「ライト、ついてますか」のご紹介です。
ポッドキャスト中でも語られていた通り、ボリュームも少なくて文字も小さくなく、とても読みやすい一冊でした。通勤などでまとまった時間が取れたら、1日で読んでしまえる本じゃないかと思います。
序文にこんな文章があります。
問題「誰も序文なんか読まない」
解答「序文を第1章」と呼んだらいい。
解答によってつくり出された新問題 第1章は退屈だ
解答 第1章なんかやめて、第2章を第1章と呼んだらいい。
この本は、まさにこうした問題発見についての本です。
あるエピソードに対して、以下のような問いを立てて問題の定義を掘り下げていきます。
何が問題なのか？
問題は本当のところ何なのか？
それは誰の問題なのか？
どこから来ているのか？
われわれはそれを、本当に解きたいのか？
以下、一章の引用です。
未熟な問題解決者は、きっととくべき問題を定義する時間を惜しんで解答にとびつくものである。経験を積んだ問題解決者すら、社会的圧力にさらされると、この「急ぎたい」という気持ちに負ける。負けてしまえば、解答はたくさん見つかるが、それが説くべき問題の解答だという保証はない。
「イシューからはじめよ」「解像度を上げる」などのような、「課題解決」における観点やアプローチをテーマにした名著はありますが、本書では問題を抱えているのは誰か？にフォーカスしていて、それが自分だという人ごとにあなたの問題の本質は何ですか？をたずねてみる、という切り口から、問題解決の手がかりを思索しているのが印象的です。
エンジニアリング的な文脈で捉えると、「仕様が明確ではないが、とりあえず実装してから考える（結果考慮が漏れて手戻りが発生してしまう）」のようなやりがちの失敗と重ねることができるかもしれません。問題を抱えているのは誰か？は、プロダクトエンジニアリング的には「ユーザー目線を持つこと」とも重ねられそうです。
第4部の「トンネルのかなたのあかり」というエピソードの中では、こんな問題が語られていました。
停電のときに大事故が起こるのを防ぐために、主任技師がこんな標識を掲げることにしました。
注意 前方にトンネルがあります。ライトをつけてください。
結果、どうなったのか？今度はトンネルを出た後にライトを消し忘れ、バッテリーを上げてしまう車が続出してしまいます。
ここで主任技師は悩みます。
「出口にどんな案内を出せばいいのか？」
悩む技師は入口と同じような問題が起こらないように、まず徹底的に詳細で厳密な文言を考えました。
もし今が昼までライトがついているならライトを消せ
もし今暗くてライトが消えているならライトをつけよ
もし今が昼間でライトが消えているならライトを消したままとせよ
もし今暗くてライトがついているならライトをついたままとせよ
もちろんこれは不採用です。走行中にこんなに長い文言を読める人はいないでしょう。
余談ですが、ここのきんじょうさんの、フローチャートくらい直感的にしないといけないね、とツッコミが適切でした（readline.fmでは、4章はPART3で扱われています）。フローチャート、論理的思考の整理術としてよくできているなぁと思います。（しみじみ）
最終的に主任技師は、強くこの問題を解決したいという動機を持っているのは誰か？という視点に立ち戻り、運転手たちがこの問題を解決したいと思っているという仮定のもと
ライト、ついてますか？
と書いた案内標識を出すことにした、というエピソードです。
エレガントさを感じるタイトル回収章です。これは誰の問題なのか？と立ち止まってちょっと視点を切り替えてみるだけで、何をどこまで説明する必要があるのか。相手の持つ前提知識や情報量などでも求められる説明は変わってきます。
げんえいさんがポッドキャストのなかで、標識が短いから多言語対応しやすかったらしい、というお話をされていました（このエピソードの舞台となっているスイスは公用語が4カ国語あるので多言語対応が大変だが、ひと言で言えたらいいよね、という副次的効果があったとのこと）。
結果的に、一つの設計判断で複数の制約を同時に解いているのにアハ体験的な美しさがあります。
日常のちょっとした視点の切り替えはもちろん、ソフトウェアエンジニアリング的にも設計や要件定義における課題に抽象化できそうな示唆が多く詰まった一冊だと思います。
よい機会なので、ぜひワインバーグさんのほかの著作も読んでみたいと思います。
