Murga

個人的に言いたいコト・主張・気持ち。

質問は常に堂々としよう

人に質問する時に、

  • 「○○が動かないんですけど……」(← けど、何?)
  • 「○○を設定したら△△ってエラーが…出て……これって……○○の……バージョンが……」(← 何が質問したいの?)

っていう、尻すぼみになる質問の仕方をする人によく遭遇する。途中から消えそうな声で喋るから「文末までハッキリ堂々と喋りなさい」といつも言っている。

この質問の仕方は複数の理由から忌むべき聞き方なので、即刻止めよう。

  • 「○○が動かなくなってしまいました。どうすれば良いか皆目検討も付かないので教えていただけませんか?」
  • 「○○を設定したら△△というエラーが出ました。○○のバージョンが古いせいかと推測しているのですが、これに関する文献やノウハウはご存知ないでしょうか?」

このように、「助けて欲しいです」「このように手を差し伸べてほしいです」とハッキリ言おう。

前者が悪い質問の仕方である理由、後者のように聞くと良くなる理由を、自分なりに解説する。

日本語の構造上の問題

「尻すぼみな質問」の問題は、聞いている側がどういう質問なのか分からない点だ。

日本語の構造上、質問文というモノは文末が重要になる。「何々がどうなって、コレコレがあぁで、どれそれしたんですけど、」という手前の話はそこまで重要ではない。大事なのは文末なのだ。「でも解決しました。何の問題もありません」と文章が続くかもしれないし、「○○のファイルだけ足りないようなのでコレをください」という依頼かもしれないし、「もう結局何がなんだか分かりません!自分じゃ手に負えません!」という悲鳴かもしれない。聞いている側は質問者が何を求めているのか分からなくて、何を求めているかを探るために文末を早く聞きたいのだ。手前の補足情報は後で話せばいい。

聞かれた側が、望んでいる答えが何かを読み取って応答できるように、質問する側は文末の具体的なお願い・依頼・求めるアクションをハッキリ言わないといけないのだ。

相手に察してもらおうとしているその姿勢に問題がある

尻すぼみに話す人は、突き詰めて言うと、「途中まで言えば、相手は答えを話し始めてくれるだろう」という期待を抱いている。自分が困っていて、ちょうど良い救いの手を差し伸べてくれるよう、「察しろ」と思っているワケだ。

ふざけんな。

仕事上の分からないことは、一刻も早く解決して、その先に進んで成果を挙げないといけないのだ。どうせこの程度の質問の仕方をする連中のことだから、大したことのない問題でくだらない時間を浪費しているだけだ。そんなの先輩に聞いて5秒で解決しろ。解決して、その先の仕事をどんどん進めろ。

それなのに、「質問したいことは察してもらえますよね?」「私が教えて欲しいことは分かってますよね?」と言わんばかりの尻すぼみの質問の仕方。答える側も、あらかた察しが付いていたとしても、答える気が失せる。お前は自分のケツも拭けないのに、拭いてほしいタイミングで上手く拭けよ、と先輩上司に言っているワケだ。家族が介護してるワケじゃねえんだ、自分のことは自分で解決して自分で仕事を進めていくつもりで、主体性を持って質問に来い。

「僕はコレが分かりません。これが解決できれば、この先のタスクが完了できるんです。ココだけ教えてください」そういう態度で聞きに来て、必要なことを吸収して、「教えてもらったやり方で上手く行きました、構造の作業に進みます!」と主体的に仕事して欲しい。それが一番、周りの足を引っ張らない質問の仕方だ。

質問すること自体は悪くないから堂々と言おう

質問自体は悪いことではない。先程も書いたが、問題はサッサと解決して、早くその先の価値ある仕事に進むのが望ましい。そのためには、サッサと人に聞いてしまうというのは充分良い手段だ。

その現場にしかない情報は、どんどん周りから聞こう。直接回答をもらわなくてもいい。「どこどこのマニュアルに書いてあるよ」とか「この共有ファイルを見ておいて」とか、情報の在り処を教えてもらうだけでも良い。

辞書を引けば分かるような一般常識、ググればすぐに出てくることばかり質問するのは避けたいものの、その「一般常識」を、「その現場」に適用して良いのかどうかは判断が付かなかったりする。その場合はもはや「一般常識」ではなく「その現場特有の情報」になるのだから、その場にいる有識者に聞いて良いことだ。

もし、一般常識かもしれないが、調べ方が分からない、というのであれば、悩んでいる時間が無駄だから早く聞こう。「そんなことも知らねえのか、常識だぞ」と言われたとしても、「すみません知りませんでした、この現場で仕事をこなすために必要なことはすぐに吸収していきますから教えてください」と言えばいいのだ。

どうも、「質問する」という行為自体を、「他人に迷惑がかかるから極力避けるべき行為」とか、「負けを認める恥ずかしい行為」みたいに捉えている人がいるが、まことに自己中だなと思う。

質問すればすぐに解決できることを、もしくは質問しないと分からなかったようなことを、「聞いたら上司の時間を奪って迷惑かもしれないから」と聞かずに自力で調べていると、スケジュールが遅延して、マネージャが迷惑する。スケジュールの遅れを自分でなんとかしようとして質問せず、誤った成果物を提出すればレビュアーが困るし、もしそれが製品に混じってしまってバグを引き起こしたりしたら、利用者も、チームメンバも、皆が困る。

問題というのは先延ばしにすればするほど、顕在化した時の悪影響が大きくなるもので、そうなると多くの人員の多くの時間を奪うトラブルになる。そうなる未来を選ぶよりは、今5分間上司の時間を奪って、問題が小さな段階で早く解決した方が、周りの迷惑にならないで済む。

「聞いたら負け」「知らないと言うのが恥ずかしい」といった自分のくだらないプライドは、サッサと捨てよう。あなたは知らないし、自力で解決できない、低レベルな人間なのだ。そんな低レベルな人間が、自分のプライドを守るためだけに、周りに質問しないで知ったかぶりしてバグやトラブルを握りつぶして誤魔化していても、問題は必ずいつか顕在化する。そうなると皆が迷惑し、「あいつのせいで酷い目にあった」「あいつ嘘つきじゃねえか最低だな」と取り返しのつかない低評価を付けられる。いくら自分が否定しようとしても、給料や役職という具体的な形で、あなたの自己中心的かつ無能な様が露呈する。

だったらそうなる前に、「お恥ずかしいのですがコレが全然分からなくて、教えてください」と質問してしまい、吸収して自分のスキルにして、以後はバリバリ仕事をこなしていけば、「あいつ最初のうちはどうなるかと思ったけど、勉強熱心で頑張っているじゃないか」と評価してもらえる。

質問は、しなかった時のリスクや被害が大きくなることが多い。早い内に質問した方が、得られる効果や削減できる時間は大きい。

その問題すら解決できない人間が変に推測するな

「質問したら相手に迷惑かもしれない」「もうちょっと調べたら自分で解決できるかもしれない」といった推測は、全て誤っている。

管理職としては、問題があるなら早く知って軌道修正する時間に当てたいし、新人からの質問の量もその人の仕事の姿勢を評価する基準の一つになっているのだが、本人はそのことに気付いていない。

実際に質問したら、上司に「今は忙しい、後にしてくれるか?」と言われるかもしれない。でもそれは「以後質問しないようにした方が良い」ことにはならない。上司は「よく調べろよ」「前も言っただろ」などとは言うかもしれないが、「もう二度と質問しに来ないでくれるか」とは絶対に言わないはずだ。それは、上司としては問題を隠される方が困るから、忙しくても質問して欲しいからだ。「お忙しい中本当に申し訳ありませんが、教えてもらわないと先に進められない問題なのです。いつでも良いのでお時間をとってください」と、それでもお願いすれば良いことなのだ。

その問題自体を解決するためのアプローチとしても言える、よく言われている言葉としては、「推測するな、観測しろ」ということだ。「こうかもしれない」「こうしない方が良いかも知れない」ではなく、実際に実行して、その結果を確認するのだ。

  • 「こうしたら直せるか試してみよう、どれどれ、あぁダメだったか。でもエラーメッセージがちょっと変わったなぁ」
    • これも大事な観測。触ってみた場所が、問題の箇所に対して影響があることが分かった。
  • 「ココはコレに関係していないはずだから、こうしても解決しないはずだよな、試してみよう、どれどれ、おや?なぜか問題が解決した、どういうことだ??」
    • 無関係な場所が本当に無関係なのか検証することも大事。
    • 実際に試してみたら無関係ではなかった、ということもある。

質問する時の姿勢としても同じ。「今質問したら悪いかもしれない」「こんなこと聞いたら非常識だと思われるかもしれない」と推測して声をかけないのではなく、「今質問しても宜しいですか?困っておりまして。」と相手に聞いて確かめるのだ。「私は忙しいから、悪いけど○○さんに聞いてみて」などと言ってもらえるかもしれない。

変に推測せず、まずやってみる。ダメだったら「出直します」で良いのだ。素人の推測は大概間違っているから、推測せず観測しよう。

質問の仕方を定型化しておく

僕は後輩を新たに迎え入れる時、必ず以下のルールを伝えている。

  • 分からないことに出会ったら、5分調べてみる。
    • Google 検索や自分なりの試行錯誤。知識がない状態で「悩ん」でも答えは絶対に出ないから、ググって知識を仕入れて、それらを総合して「考える」こと。
  • 5分調べて分からなかったら、すぐ聞く。
    • 分からないことを放置するメリットはない。すぐに周りに助けを求めて解決を図る。
    • 「自分が困っている」ということを周りに共有するのもチームとしては大事なことだから、どんどん困っていることをアピールしろ。
  • 質問したい時に相手がどういう状況でも、必ず呼び止める。
    • 質問しない方が良いかは質問する側が考えることではない。迷惑がられてもいいから呼び止める。
    • 「今質問よろしいですか」「5分ほどお時間いただけますか」とか聞いて、ダメだったら別のタイミングに調整してもらえ。
  • 先に聞きたいことをハッキリ言え。詳細は後から言え。
    • 「Java の設定ファイルに加えた変更が反映されなくて困っている。どうしたら反映されるようになるか知りたい」コレを最初に言え。
    • 「○○ファイルをこう書き換えていて…」とか「このやり方は試したのですが…」とかはその後言え。

最初のうちは伝えていてもなかなか従ってもらえず、尻すぼみな質問をされるのだが、「分かんなくても堂々とハッキリ言い切れ」と繰り返し指摘していくと少し良くなってくる。

この辺のルールを、質問する側も、質問される側も、文書化して共有しておくと良いかなと思う。結局のところ、上司は上司で「部下にはこういう風に行動して欲しいんだけどなぁ〜 (← でもそれを直接は言わない)」と思ってるだけだったり、部下は部下で「よく分かんないけど質問するのは悪い気がするし〜 (← 本当に悪いかどうか確認していない)」と思い込んでいるだけだったりする。

文書化してお互いの姿勢を共有しておけば、「○○が分からなくて困っています」「5分調べたか?」「はい、文献に従ってコレとコレを試しましたがダメでした」「じゃあこのトラブルパターンかもしれないな、ちょっと見てみよう」と会話がスムーズに進められる。


質問はどんな場合・状況でも常に、ハッキリと、堂々と言い切るべきだ。それが相手のためになる質問の仕方だし、チーム全体が一番負担にならない、推奨される行動だ。

「良い質問」をする技術

「良い質問」をする技術