上手にアドバイスをもらうための「質問の技術」

この記事で扱うこと、扱わないこと

この記事を読んでいただいて「思っていたものと違った」とならないために、先に何を扱うか、クリアにしておきます。

■この記事で扱わないこと

• 良い提案をするために、クライアントから情報を引き出すために質問する

• 部下を育成するたえに、考えさせるための質問をする

■この記事で扱うこと

• 上司や同僚から、上手くアドバイスを引き出すために質問する

• 有識者（その道にプロフェッショナル）から、仕事に役立つことを教えてもらうために質問する

…という前提で書き進めますので、「思ってたのとちげーじゃん」という方は、そっと記事を閉じてください。
「お、それ知りたかったんだよ」という方に向けては、限界まで細部までこだわって言語化した内容に仕上がっておりますので、しばしお付き合いください。

良い質問の前提となる2軸

良い質問は、自分と相手の頭が整っているときに成立する。

クソ質問：自分の頭が整っていない×相手の頭も整っていない

質問する側も、何を聞けばいいのかイマイチ定まっていない。
そんな状態で、質問に答えるための情報を何も持っていない相手に質問をしてしまう。

え、そんなことありえる？と思ったかもしれませんが、頭が真っ白なときって、平気でこういうムーブをかましちゃうんですよ。

社会人1年目に、コールセンターに新システムを導入するプロジェクトをやってたときの話。
エンジニアの方から、こんなことを質問されました。

「現在、EKS 上で稼働している Kubernetes クラスタを Helm Chart を使って継続的にデプロイする際、Argo CD と Flux CD のどちらを採用すべきか検討しています。既存の CI/CD パイプラインは GitLab CI で構成されており、Infrastructure as Code は Terraform を利用して AWS リソースを管理しているのですが、Terraform の state ファイルを S3 に置く場合と Git 管理する場合のセキュリティリスクと運用コストについても悩んでいます。さらに、アプリケーション自体はマイクロサービス構成で、サービス間通信を Istio Service Mesh で制御しているため、mTLS や Tracing のメタデータが増大し、Prometheus/Grafana を使った可観測性（Observability）のパフォーマンスへの影響も気になるところです。将来的にサーバレスアーキテクチャ（Lambda や Fargate など）とのハイブリッド構成を視野に入れていますが、すでに導入済みの Amazon SQS や EventBridge との連携も考慮すると、エンドツーエンドのトレースはどう設計するのがベストプラクティスでしょうか？ こうした複数の要素（CI/CD ツール選定、Terraform の state 運用、Service Mesh 上の可観測性、サーバレスとの連携）を総合的に見直す際、AWS Well-Architected Framework の Security と Operational Excellence の観点から、どのような設計アプローチが最適でしょうか？」

・・・冗談です。これは生成AIにテキトーに作らせた質問です。
でも、何を聞かれたか覚えてもないし理解もできていない、そんな質問をされました。

僕じゃ決められない。決める権限はクライアントが持っている。

そう思った僕は、伝書鳩としてクライアントに質問しに行きました。
「現在、EKS 上で稼働している Kubernetes クラスタを Helm Chart を使って継続的にデプロイする際、Argo CD と Flux CD のどちらを採用すべきか検討しています…（中略）。どちらを採用すべきでしょうか？」みたいな感じで、聞いた単語を頑張ってつなげて、自分でも何を喋っているかわからない状態で質問をしました。

クライアント「は、何言ってんの、お前？」
僕「…ですよね、すみません、出直してきます」
あのときの空気は今でも忘れません。

こんなポンコツムーブを昔はかましていました。
でも、頭が真っ白なときって、こういうことしちゃいませんか？

• 自分の頭が整理できていない状態で

• 見当違いな相手（質問に答えるための情報を持っていない相手）に質問してしまう

これだけは止めましょうね。

怠けた質問：自分の頭が整っていない×相手の頭は整っている

大学2年生のときの話なんですが、マザーハウス副社長の山崎さんの講演会に参加したことがありました。
あの頃は「誰も質問をしない中、質問をすること自体が素晴らしいこと」というクソみたいな自己顕示欲を持ってました。
そこで、山崎さんに質問しました。
「山崎さんのキャリアの成功要因は何でしたか？」と。

抽象的で、意図もよくわからないクソ質問。
そんなクソ質問に対しても、山崎さんは丁寧に「こういう前提でいうと」といくつかの前提を示しながら、丁寧に回答してくださったのを覚えています。
今にして思えば、大変失礼な質問をしてしまったなと反省しております。

ちょうどよい事例だと思い、顔を真っ赤にしながら書いていたわけなのですが、要は

• 相手がその分野のプロフェッショナル・担当者であるので答え自体は持っている

• しかし、質問の目的や範囲が曖昧なため、相手がどこを、どの程度まで答えればいいのか判断に困ってしまう

こんなこと、やっちゃってませんか？

もっと身近な例でいうと、グルメな同僚とランチ行くときに、「ランチどこ行きましょうか？」「何がオススメですか？」と聞いてしまう。
これ、考える負荷をぜーんぶ、相手に押し付けちゃってます。

せめて、
「最近は魚を食べていないので、焼き魚が食べられるオススメの定食屋とかあったりします？」
「この3つのお店が気になったのですが、○○さんのオススメどれですかね？」
…みたいに、質問の範囲を定めるなど、なるべく相手の思考負荷を下げるような努力をしたいところです。

独りよがりな質問：自分の頭は整っている×相手の頭は整っていない

独りよがりな質問、これには2パターンあります。

1つ目は、聞く相手を間違っているパターン。
例えば「納期を短縮するため、具体的な工程の組み替え案を知りたいです。だから○○の進捗管理データが欲しいです」という質問は、質問の意図も答えるべき範囲も明確なので、よさげな雰囲気が漂っています。
しかし、聞く相手が間違っていたら「それなら別の人に聞いてください」と言われて終わり。
自分のことばかり考えて、相手のことを配慮せずに質問してしまう。
そんなものは、独りよがりな質問です。

2つ目は、聞く相手に十分な情報を提供していないパターン。
僕がコンサルファーム出身なのもあって、大学生や若手社員から、コンサル会社でのキャリアについて質問をもらう場面があります。
そのときに「A社とB社に内定をもらったのですが、どっちがオススメですか？」と聞かれること、けっこう多いんですよ。
まあ、なんとも答えにくい。
「あなたがどんな状況に置かれていて、どんなキャリアを歩みたいのか」という情報がないことには、A社とB社どちらがオススメか、答えようがありません。
質問と向き合うにあたり、あなたと僕の間にある情報格差はなるべく埋めておく。
これが質問者としての礼儀作法です。

良い質問：自分の頭が整っている×相手の頭も整っている

以上の「悪い質問」の例を見ていくと、おのずと「良い質問」の輪郭もハッキリしてきます。

• 自分の頭が整っている：何に困っていて、何のために、何をどこまで聞きたいのかがクリアになっている

• 相手の頭が整っている：相手はこちらの質問に答えるための情報を持ち合わせている（ないし、こちらから必要な情報を提供している）

この2つが整っていて、はじめて「良い質問」が成立します。
逆にこの2つを整えないまま質問すると、ここまで述べてきた僕のクソみたいな失敗を再現するハメに。

良い質問をつくる手順書

では、どうやって「良い質問」をつくっていけばよいのか。
実は、それなりに再現性のある手順があります。