Dain
古今東西のスゴ本（すごい本）を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。
はじめに
言葉の使い方ひとつで、コミュニケーションは変わる。
選んだ言葉が間違っていたがために、労力と感情を浪費した挙句、ババを引くことが沢山あった。
昔の私は、正確に論理的に説明すれば100％分かってくれると思い込み、常に厳密な物言いやメールの文面を心がけていた。だが、書いた通りに伝わらなかったり、書いてもいない内容が勝手に汲み取られたりした結果、話がこじれることが多々あった。「なんでこんな簡単なことが分からないんだ！」と腹を立てることもあった。
しかし、それは私の思い込みが原因であることに気づいた。人はコンパイラではない。立場や感情があり、文脈や背景に依存して解釈する。書いた通りに伝わるかどうかは、伝え方によるのだ。
ここに気づいてから、同じことを様々な言い方で伝えるように努力した。同時に、読んできた書籍の中から、うまく自分の考えを相手に伝える言葉や方法を拾い上げるようにしてきた。この記事では、そうやって蓄積してきた言葉のうち、「ITエンジニアのピンチを救う言葉」を授けてくれた本を選んでみた。
2. 『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』鳥井雪、久保優子、諸永彩夏 著、島田浩二 監修
3. 『ライト、ついてますか』D.C.ゴース、G.M.ワインバーグ 著、木村泉 翻訳
4. 『スーパーエンジニアへの道』G.M.ワインバーグ 著、木村泉 翻訳
「なぜ？」ではなく「いつ？」と聞く
「なぜ」と質問したくなる状況を思い出してみよう。
- なぜ、この設定を変えたの？
- なぜ、この関数を使ったの？
質問する側は、純粋に、理由を問うているだけかもしれない。だが、問われる側は、「なぜ？」に圧力や責任を感じる場合がある。特に、システム障害が発生し、その原因を調査している最中だ。
なぜ設定を変えたのかって？ そりゃ変更の依頼が来たからに決まっている。でも多くの場合、その依頼が正式のルートで来たのかとか、変更の手順が正当なものなのかとか、変更のタイミングや影響について十分に調査し、各方面への了承を取っているかとかは知らない。
最初から「なぜ設定を変えたのか？」と問う人は、その答えがいかなるものであれ、次の「なぜ」で更問いをして詰めてくる。しかし、依頼の妥当性だとか、変更の影響調査や、各方面への了承を取ったエビデンスの有り無しなんて、即答できない。そういう場合、質問者は「じゃあ、それ調べておいて（答えられないならオマエの責任ね）」と言い放つ。カッコ（）内は発話するかどうかは別として、そういうニュアンスで伝わってしまう場合がある。
「なぜ」と質問をするというのは、相手に説明責任を押し付けることになる。そして、質問の答えに対し、さらに「なぜ」を重ねて追及することで、説明責任だけでなく、問題の責任そのものを押し付けることができる。「なぜ」と問い続けていること自体、「変更したオマエの責任だ」と暗に言っているようなものだ。問われる側が感じる、この“詰め寄られ感”が圧力の正体だ。
ひょっとすると、質問者は、「そういうつもりじゃない」と言うかもしれない。だが、「そういうこと」になってしまう場合は、確かにある。そして、答える側も、事実を答えるというよりも、何か言い訳をさせられているような気になってくる。
これが、いわゆる「なぜなぜ分析」が嫌われる理由だ。
トラブルや失敗について、なぜなぜ分析をすると、状況の偶然性や、プロセスの特殊性がスルーされ、「誰か」のミスが根本原因とされてしまいがちだから。失敗には「犯人」がいて、そいつを探し出して処罰すれば、ミスは繰り返されないという発想だ。
「なぜなぜ分析」が積み重なると、質問される側のモチベーションは激減する。「真面目に答えてもムダ」「どうせ俺のせいにされる」という気分になる。これがチーム内で繰り返された場合、メンバーの意欲は萎縮し、ミスは報告されなくなり、チームの柔軟性は失われる。
解決策は「なぜ」を封印することだ。
代わりに、「いつ」と問うのだ。「いつ？」とは、事実を引き出す質問なのだ。
- いつ、設定を変えたのか
- いつ、設定変更のGOサインが出たのか
- いつ、変更の影響調査がなされたのか
すると、実際の変更作業をした人は、「指示書にあるタイミングで変更したけど、いつ影響調査がされたかどうかは知らない」と答えるかもしれない。すると、その指示書を出した人や、指示書そのものを作成した人、あるいは指示書の内容を検証した人に質問ができる。
「いつ」は、変更に関する事実を、責任を追及することなく集めた上で、その指示内容で妥当だと判断した人・チームの責任を問うことができる。質問される側の心理的な圧迫が解消されるだけでなく、質問者がより速く責任の所在にたどりつく方法である。
『「なぜ」と問わない質問術』は、こうした「いつ」から始まる質問を事実質問と定義する。
そして、「いつ」の他にも様々な事実質問のパターンを紹介する。「事実質問は、考えさせるのではなく、思い出させる」「過去形・時間・主語を意識する」など、応用の利く考え方が紹介されている。
「なぜ？」ではなく「うれしいのは？」と問う
一方で、「いつ」だと答えを引き出しにくいものもある。
純粋に、理由を問うている場合だ。先ほどの例だと、「なぜ、この関数を使ったの？」がそれにあたる。レビューコメント等で、こうした問いは発せられる。
ただ、問いを発する側と、問いを受ける側の力関係が違うとき、質問の意味が変わってしまう。『伝わるコードレビュー』に出てくるレビューコメントを例に挙げてみる。
Aさん：このメソッドを使ったのはなぜ？
Aさんはベテランプログラマーで、新人のBさんが書いたコードへのコメントがこれだ。Bさんは「このメソッドを使ってはいけなかったのだろうか？」と不安になり、どうやって回答を返したものかと悩む。
Bさんの様子を心配した先輩のCさんが間に入り、Aさんと少し話をしてきたところ、コメントはこう変わったという。
Aさん：[ask]このメソッドを使ったのはなぜ？ 同じことはcalc_amout(items)というメソッドでもできる。今のコードでも問題ないとは思うけれど、一応、こちらを選んだ判断基準が知りたい。
Cさんは普通に「あのコメントの意味は何でしょうか？このメソッドを使ってはいけないことでしょうか？」と聞いただけで、これだけ変わった。そして、このコメントならBさんは回答できる。
疑心暗鬼に陥る必要は無かったというオチなのだが、Aさんの最初のコメントが言葉足らずで、意図が伝わっていないのが原因になる。質問の背景や、質問をした理由を伝えた上で、何を答えて欲しいかを心がけることで、分かりやすいコメントになるという。
『伝わるコードレビュー』は、豊富な事例やTIPSを紹介しながら、PR（プルリクエスト）やレビューコメントの書き方や、効果的なレビューの進め方を紹介した一冊になる。レビューの指摘を的確に伝え、レビューを受ける側も納得感を持って改善できる技法集になる。
私は、質問の背景を伝えていることを明確にするため、「うれしいのは？」という問い方にしている。「このメソッドを使うことでうれしいのは何？」と聞くことで、「あなたがこのメソッドを使うメリット」を問う意図が明確になる。
それなら直接「メリット」「デメリット」という言葉を使えば良いかもしれぬ。
だが、メリットだと「誰にとってのメリットか」という焦点が少しボヤけるように見える。メリットとデメリットは、特徴の表と裏だからだ。
例えば、caseの条件文の中に、さらに細かくif文を入れるルールについて。条件が追加されるとき、caseを増やさなくていいし、柔軟性があるといえる。一方、可読性は落ちて条件の追跡が難しくなる。柔軟性を取るか、可読性を取るかは、それこそケース・バイ・ケースだ。
そんなとき、「このルールのメリットは？」と聞くのではなく、「このルールを採用すると、誰にとってうれしいの？」と聞く。そうすることで、評価軸の両面を言い直しただけに過ぎないメリ・デメリよりも、価値と結びつく主体が明確になる。
解くべき問題を意識させる問い
ITエンジニアにとっての「良い質問」の宝庫は、ジェラルド・M・ワインバーグの『ライト、ついてますか』だろう。
そのワインバーグ御大は、問題を「発見」し、質問をしたくなる気持ちをグッと抑えよと説く。
「ITエンジニアは顧客の課題を解決する」とか「ソリューションこそがITエンジニアの価値だ」なんて常日頃から言われている。そのため、顧客の悩みを聞いて、最初に見つけた問題らしきものに飛びつく傾向がある。
例えば、チケットの予約について。「先着順に人気アーティストの予約を扱うとき、リクエストが殺到し、予約処理が間に合わない」という悩みがあるとする。もし、「予約処理を間に合わせる」ことを解くべき問題だとするなら、「サーバを増やす」とか「回線を増強する」といった対策になる。
だがこれを、「本当に解くべき問題はそれか？」という視点から、もう一度考えてみる。予約や支払いといった重い処理を早く回すように頑張るのではなく、「リクエストに応える」ことを優先する。そう考えられるなら、「リクエストを受け付ける」処理と、「予約・課金をする」処理を分けるという発想につながる。
最終的には、「一定の期間にリクエストを受け付け、そこから当選者を先着順に選び、後日、予約と支払いをしてもらう」という解決策が提案できる。
ワインバーグは指摘する。私たちは、学校に通い過ぎたため、問題に飛びつく「癖」ができてしまった。問題を見つけ、できるだけ早く解こうとする。なぜなら、試験ではスピードがものを言うからだ。その結果、本当に解くべき問題なのかどうかを吟味せず、苦い結果にたどり着くまで、最初に見つけた問題に固執するというのだ。
問題は本当のところ何かを見極めるために、「問題文をどう変えたら、解答を変えることができるだろうか？」と自問せよという。
本のタイトルにもなっている、『ライト、ついてますか』の事例が分かりやすい。第13章の「トンネルのかなたのあかり」を要約すると、こんな問題となる。
ところが、観光客に問題が発生した。トンネルを抜けて展望台に到着してもライトがつけっぱなしで、展望台を散策した後、バッテリーが上がってしまうというトラブルが多発したのだ。
もし問題が「バッテリーが上がる」なら、展望台に充電施設を置けば解決する。一方で、維持費もかかるだろう。あるいは、もし問題が「ライトの消し忘れ」であるならば、トンネルの出口に「ライトを消せ」という標識を出せばよいだろう。けれども、夜中にライトを消してしまう可能性だってありうる。
色々考えて、こういう標識の案となった。
「もし今が昼間でライトがついているなら、ライトを消せ
もし今が夜間でライトが消えているなら、ライトをつけろ
もし今が昼間でライトが消えているなら、ライトを消したままにしろ
もし今が夜間でライトがついているなら、ライトはついたままにしろ」
厳密性はいいのだが、車の運転中に読む文章ではない。本当に解くべき問題は、「バッテリーが上がる」ではなく、「ライトを消す」ことでもない。ライトのON・OFFの必要性を「ドライバーに気づいてもらう」ことが重要になる。その結果、「ライト、ついてますか？」になったというのだ。
これ、「パソコンが起動しない！」という苦情の小話にもつながる。
ヘルプデスクに電話してくる人は、「何もしていないのにパソコンが壊れた！」「電源ボタンを押してもウンともスンとも言わない！」と言ってくる。この場合、電源コンセントが挿さっていない場合が、一定数ある。オペレータが「コンセントを確かめてください」というと、「馬鹿にするな！」と逆切れする。そうした、クレーマー一歩手前のお客に対しては、こう言うのだ。
「電源コンセントを一度抜いて、挿し直した上で、電源ボタンを押してください。」
もしコンセントが抜けていたのであれば、顧客を怒らせずに挿し直してもらえるし、コンセントが挿さっているのに起動しないのであれば、問題の切り分けができる。解くべき問題が、「お客に気づいてもらう」ことであれば、アドバイスの仕方が変わってくる。
「その問題」とは何か、教えてもらえますか？
『ライト、ついてますか』が入門書なら、『スーパーエンジニアへの道』はワインバーグの集大成とも言える。
読むたびに気づきが得られ、「良い質問」のエッセンスが見つかる。問題はいつだって、技術的なところよりも、人間的なところにあることが、よく分かる。
第6章の「問題ない症候群」のお話なんてまさにそう。
音声として耳に入ってくるが、中身を理解しておらず、「問題ない！」と答える連中がいる。これが厄介ごとを生むというのだ。
ずいぶん昔、まさにこうした悩みに頭を抱えたことがあったが、その頃はまだ、本書を読んでいなかった。そのため、連中を黙らせる魔法の質問―――「その問題とは何か、教えてもらえますか？」―――を知らなかったのだ。
問題ない症候群の見つけ方は以下の通り。
1. あなたが、プロジェクトにおける難しい問題を言う
2. 連中が「問題ない！」と言う
3. あなたが「そりゃすごい！『問題ない』とおっしゃるその問題とは何か、言ってみてくれませんか？」と言う
4. 相手が、問題そのものではなく、解決策を説明し始めたなら、「問題ない症候群」に陥っている。あなたが部屋を出ていくべき
私が巻き込まれた厄介ごとを例に説明しよう。
当時、新たなシステムの構築にあたって、顧客の既存のシステムからのデータを移行することが必要だった。スケジュールは厳しく、短期間で膨大なデータをスムーズに移行させることが課題だった。
そこで、顧客から移行データを提示してもらうよう依頼したところ、営業チームが「問題ない」と遮ってきた。
どうして問題ないと言えるのか？
それは、我々の手元にも代わりのデータがあると思っていたから。既存システムは日々データをファイルに出力している。そのファイルを取り込めば良い。日々のファイルを取り込ませる移行プログラムだけを「ちょちょっと」開発すれば、顧客の手を煩わすことなく、移行ができる。
今から考えると、顧客にいい顔をしたかったのだろう（誠にサービス精神あふれる営業だった）。そして、移行データを提示してもらう代わりに、日々のファイルを提示することで話を進めてしまった。
その後、起きたことを説明する。
提示された膨大なファイルに、欠けている日があった。あるいは、フォーマットが崩れていたり、データの抜けがあるファイルがあった。それもかなりの数に上った。というのも、顧客自身が日々のファイルを人手で修正したり改変していたからだ。
移行プログラムは、その度に異常終了し、原因を解析し、修正し、再度最初からやり直すハメになった。移行スケジュールは大幅に遅れ、最終的には、顧客からデータの一部を提示してもらうことで、なんとかサービス開始にまでこぎつけた。
営業は「移行プログラムの不具合のせい」だと顧客に説明し、開発チームに責任が押し付けられた。
今なら分かる。最初に「どうして『問題ない』と言えるのか？」と質問するのではなく、「その『問題ない』と言ってる問題とは何か、説明してください」と聞くべきだったのだ。
そこで「代わりのデータをもらう」案が出てきたら、営業は問題を把握しておらず、「問題ない症候群」に陥っていることに気づけただろう。データさえあれば良いのではなく、「短期間で膨大なデータをスムーズに移行する」という問題に向き合えていたかもしれぬ。
「それは問題ない」は思考停止ワードとし、「その問題とは何なのか分かってる？」という問いからリスタートする必要があるだろう。
おわりに
「良い問い」とは、事実と判断を明確にし、価値と結びつく主体を明らかにする。そして、本当に解くべき問題に焦点を合わせ、「私たちは何を解決しようとしているのか？」とメタ的な視点を与える。
『「なぜ」と聞かない質問術』は、「いつ？」という問いから始めることで、事実しか言えないような回答を強制し、人による判断をいったん保留にできる。もちろん人による判断も必要だが、まずは事実を炙り出すのが必須だろう。
『伝わるコードレビュー』は、PRやコメントに限定しているものの、質問そのものよりも、その背景や意図を十分に伝えておく必要性を強調する。そして、背景や意図は、回答者にとっての価値判断の基準を示す「うれしいのは？」という一言で引き出せる。
『ライト、ついてますか』は、「問題」そのものを定義する質問集とも言える。誰にとっての問題かによって、解答はいくらでも変わってくる。そして、顧客にとっての問題を解決するのがコンサルタントであるという、当たり前のことに気づかせてくれる。
『スーパーエンジニアへの道』は、問題の定義を曖昧なまま進めていくと、どんな酷い目に遭うのかの事例集とも言える。ワインバーグ先生に降りかかった厄介ごとの本質は、時代を経ても変わらない。
「いつ？」「うれしいのは？」「解くべき問題はこれ？」「その『問題』が何か、教えてください」……こうしたさり気ない問いが、ITの現場のピンチを助けるのかもしれない。
