■ 1. 概要
- ITエンジニアのコミュニケーションにおいて言葉の選択が結果を左右する
- 著者は「正確・論理的に説明すれば伝わる」という思い込みを克服し人への伝え方を変えた
- 人はコンパイラではなく立場・感情・文脈によって解釈が異なる
- 4冊の書籍から「ITエンジニアのピンチを救う言葉」を紹介する
■ 2. 「なぜ」ではなく「いつ」と問う
- 出典: 『「なぜ」と聞かない質問術』中田豊一 著
- 「なぜ」の問題点:
- 問われる側に圧力・説明責任・問題の責任を押し付ける効果がある
- 「なぜなぜ分析」は偶然性やプロセスの特殊性を無視し特定個人のミスを根本原因とする傾向がある
- 繰り返されるとメンバーのモチベーションが萎縮しミスが報告されなくなる
- 「いつ」による事実質問の効果:
- 「いつ設定を変えたか」「いつGOサインが出たか」と問うことで責任追及なしに事実を収集できる
- 心理的圧迫を解消しながら責任の所在により速くたどり着ける
- 応用原則:
- 事実質問は「考えさせるのではなく思い出させる」
- 過去形・時間・主語を意識して問う
■ 3. 「なぜ」ではなく「うれしいのは」と問う
- 出典: 『伝わるコードレビュー』鳥井雪・久保優子・諸永彩夏 著 島田浩二 監修
- 力関係のある質問の問題点:
- ベテランから新人への「このメソッドを使ったのはなぜ？」は意図不明で受け手を不安にさせる
- 質問の背景・理由・求める回答を明示しないと意図が伝わらない
- 「うれしいのは」という問い方の効果:
- 「このメソッドを使うとうれしいのは何？」とすることで「採用するメリットの主体」が明確になる
- 「メリット」という言葉より誰にとっての価値かという焦点が鮮明になる
- 実践上の留意点:
- コードレビューのコメントには質問の背景・意図・求める回答を含める
- 評価軸の両面を言い換えるだけの問いより価値と結びつく主体を問う問いが有効
■ 4. 解くべき問題を見極める問い
- 出典: 『ライト、ついてますか』D.C.ゴース・G.M.ワインバーグ 著 木村泉 翻訳
- 「問題への飛びつき」の弊害:
- 学校教育により最初に見つけた問題を素早く解こうとする癖がつく
- 本当に解くべき問題かどうかを吟味せず固執すると誤った解決策に至る
- 問題再定義の方法:
- 「問題文をどう変えたら解答を変えられるか」と自問する
- チケット予約の例: 「予約処理を間に合わせる」ではなく「リクエストを受け付ける」に問題を再定義することで処理分離という発想につながる
- 「ライト、ついてますか」の事例:
- トンネルでのバッテリー上がりの問題を「バッテリーが上がる」でも「消し忘れ」でもなく「ドライバーに気づいてもらう」と再定義した
- ヘルプデスクの「コンセントを抜いて挿し直してください」も同様の問題再定義の実践例
- 本質: 問題の定義次第で解答はいくらでも変わる
■ 5. 「問題ない症候群」への対処
- 出典: 『スーパーエンジニアへの道』G.M.ワインバーグ 著 木村泉 翻訳
- 問題ない症候群の特徴:
- 問題の内容を理解せずに「問題ない」と答える
- 問題ではなく解決策を説明し始めた場合に症候群と判断できる
- 見分け方の手順:
- 難しい問題を提示する
- 「問題ない」と言われたら「その問題とは何か説明してください」と問う
- 相手が解決策を説明し始めたなら症候群と判断する
- 著者の実体験:
- データ移行プロジェクトで営業が「問題ない」と遮り代替データを提示
- 移行ファイルに欠落・フォーマット崩れが多発しスケジュールが大幅遅延
- 「その問題とは何か」と問うことで問題把握の有無を早期に確認できた
- 対処の原則:
- 「問題ない」は思考停止ワードとして扱う
- 「その問題とは何か分かっているか」という問いからリスタートする
■ 6. まとめ
- 良い問いの定義:
- 事実と判断を明確にする
- 価値と結びつく主体を明らかにする
- 本当に解くべき問題に焦点を合わせる
- 「私たちは何を解決しようとしているのか」というメタ的視点を与える
- 各書籍のエッセンス:
- 「いつ」: 事実を炙り出し人による判断を一旦保留する
- 「うれしいのは」: 質問の背景・意図を伝え回答者の価値判断基準を示す
- 「解くべき問題はこれか」: 誰にとっての問題かによって解答が変わることを意識する
- 「その問題とは何か」: 問題定義の曖昧さを放置しないための問い