これまで一緒に働いてきた中で「この人はすごい」と思ったマネージャーには、共通するクセがありました。知らないことを聞かれたとき、ごまかさずに「わかりません」と言うことです。曖昧にはぐらかすこともなく、ただ一言、「わからないので、調べましょう」。
最近このことをよく考えるのは、自分自身がプロジェクトをリードする立場になって、ごまかしたくなる誘惑を実感しているからです。会議で質問されて、5人が答えを待っている場面での「わかりません」は、負けを認めるような気分になります。でも実際は逆で、たいていの場合それが一番強い一手です。
ごまかしは必ずバレる#
ソフトウェアの世界は変化が速すぎて、全部を頭に入れておける人はいません。そしてエンジニアは、知ったかぶりを驚くほど敏感に見抜きます。一度でも「知っているふり」を見破られると、チームはそれ以降、あなたの本当の答えまで割り引いて聞くようになります。逆に、知らないことを認めて、その穴をきちんと埋めに行くマネージャーの言葉は信頼されます。本物の答えかどうか、みんなちゃんと聞き分けているのです。
「わかりません」は答えではなく出発点#
大事なのはその後です。「わかりません」で終わったら、ただの投げっぱなしです。いいマネージャーは、そこからより良い質問を組み立てます。「今使っているものと比べてどうか」「この前提が外れたら何が壊れるか」。そして、その質問を適切な人にぶつけます。どのチームにも、データベースに住んでいるような人や、フロントエンドの厄介なエッジケースを全部知っている人がいるものです。全部を自分で知っている必要はありません。誰が知っているかを把握して、実際に聞きに行けばいいのです。
意思決定の質が上がる#
ソフトウェアの意思決定は後々まで残ります。だからこそ、「ここは確信がある」「ここは推測だ」と正直に区別する価値があります。わからない部分を先に認めておけば、決めた後ではなく決める前に足りない情報を集められますし、反対意見のある人も声を上げやすくなります。それこそ、一番聞くべき声です。決めたら理由を説明する。間違っていたら、それも認める。マネージャーが自分の失敗を認められないチームほど、正直さが早く失われていく場所はありません。
難しい話ではありません。質問をして、自分より詳しい人の話を聞いて（自分より詳しい人は必ずいます）、推測で話すときは推測だと言う。それだけです。「わかりませんが、調べてみましょう」という一言は、ごまかして切り抜けたどんな答えよりも、私の信用を積み上げてくれました。