- よく新人のころに言われた「15分自分で考えてわからなかったら、人に聞け」というアドバイスがある
- １人であれこれ悩んだ末に、結局答えにたどり着かなかった場合よりも、すぐに誰かに質問して答えを得た方が、本人にとってもチームにとっても良いという考え
- いい考えだと思うが、場合によってはこのアドバイスが、当人や周りを苦しめるきっかけになってしまうかもしれない
- 僕もよく苦しんだ
問題点
- 聞く人と聞かれる人が固定化されてしまう可能性がある
- よく聞く人はたいていチームの新参者で、よく答える人はたいていチームのベテランさん
- 新人「この件わからないけど、また○○さんに聞いたら、しつこいって思われるかなぁ……😓」
- ベテランさん「うーん、俺ばっかり質問に答えるの、正直しんどいなぁ😭」
- 他のあまり詳しくないチームメンバーが質問されないことで、そのメンバーが知見を深めるきっかけも失われてしまう
- よく聞く人はたいていチームの新参者で、よく答える人はたいていチームのベテランさん
- 聞く人の「調べる力・考える力」が養われなくなってしまう
- なんでもかんでもすぐに人に聞いていたら本人の自走力が育たない、というのもよく聞く話
- 「聞かないことが罪である」という認識を生むことも
- メンバー「あれ、このタスクまだできてないの？ どうして？」
- 本人「すいません、ここの部分がわからなくて困ってて……😢」
- メンバー「ちょっと、困っているなら何で聞かないの😠 30分考えてわからなかったら質問してって言ったよね😠」
- 本人「ご、ごめんなさい……😭」
- ちょっと待って！ どうして彼は質問しなかったのだろう？
- 質問できなかった要因がどこかに潜んでいるのかもしれない
- タスクが終わらなかった原因が、はたして本当に「本人が質問しなかったせい」なのだろうか？
- N分考えて質問する、を徹底した結果、かえって「質問が多い人」と思われる可能性がある
- 「まーたすぐこの人は質問してるなぁ😫 もう少し自分で調べてよ😫」と周りに思われることがある
- ところが、本人としては「30分悩んだけどわかりませんでした、すみません😢」
- 次第に「わからない…😭 でもまた質問したら嫌がられるかなぁ😵 でももうN分を過ぎてるし😵 どうしよう😭」という悲劇を生んでしまう
- この問題の背景には、「わからないという状況が高頻度で、同じ人に発生してしまっている」という要因がある
- その人は入社したてかもしれないし、そもそも開発経験が薄いのかもしれない。はたまた、ドキュメントが整備されていなくて調べようがないのかもしれない……
改善方法
- 新人がいる場合、「必要に応じて尋ねてもらう」ではなく、定期的な質問会を実施する
- 例えば入社して1~2週間は、毎朝15~30分ほど質問タイムを設ける（雑談のきっかけにもなる）
- 入社したての人がわからないのは当然なので、入社後の一定期間は専用の質問タイムを設ける
- 尋ねるときは、個人ではなくチーム全体に尋ねる
- ベテランの〇〇さんに聞きたくなるところを、ぐっと堪える
- ベテランの〇〇さんは、自分が答えたくなるのもぐっと堪える
- 〇〇さん（……ここは我慢だ😵 メンバーの成長のためだ😵）
- ただし、お見合いになるのを防ぐために、チームリーダーなどが適度に回答を割り振る
- わからない人「すいません、この部分がわからないんですけど😭」
- リーダー「なるほど……△△さん、このあたりって何かご存知です？」
- △△さん「あ、そうですね、ちょっと確認してみます…😳」
- ドキュメントを整備する
- わからないことが多いという理由の一つに、暗黙知がたくさん潜んでおり、人に聞かなくてはわからないという状況が発生しているのかもしれない
- 質問に応じた人が「そりゃあ聞かないとわかんないよな😅」と感じた場合、今一度社内用ドキュメントの整備を検討する
- 聞くではなく、「つぶやく」を利用する
- Slackのtimesを開き、メンバーにそこに入ってもらう
- わからないこと・つまづいたところがある場合は、そこに書き込む
- わからない人「うーん、Dockerコンテナが起動せず失敗しちゃうなぁ😫」
- わかる人「おや、困っているようですね！😄 どのコンテナですか？😄」
- わからない人「ありがとうございます😭 実はMySQLのコンテナが……😫」
- 困っていることを共有することで、助けてもらったり、他人がつまづいている箇所を顕在化したりすることができる
- また、困りごとの共有という名目でtimesに入ってもらうことで、メンバー間の交流を促進する
- 「聞く」という行為にグラデーションを設ける
- timesでつぶやく
- 緊急度は低く、自分でもなんとかなりそうな雰囲気だが、一応困っていることを共有する
- 気軽に困りごとを投稿することで、他メンバーが当人の進捗やタスク内容を把握するのにも役立つ
- チャット上で尋ねる
- N分以上試行錯誤したものの、どうしてもうまくいかないので、チームメンバーの助力を仰ぎたいとき
- 緊急度
- 通話・画面共有をお願いして尋ねる
- テキストによる質問では限界がある場合や、緊急度・重要度が高い場合はこうする
- チャットやtimesとは異なり、同期的なやりとりを求めるため、このお願いが一定の人に集中してしまうと、相手の負担にもなりうる。
- 「相手の時間を奪う」という考え方は個人的には嫌いだけど、相手の時間を尊重することも大事。日頃感謝を伝えたり、誠実な姿勢で相手にお願いしたりしよう。
- 個人的に大事だと思うのが、「ちょっとわからないことがあるので通話いいですか？」よりも、「これこれこの点で困っており、○○さんのご意見をうかがいたいです」という風にお願いすること。質問の目的や理由を伝えると、答える側の心理的ハードルが下がる。
- 定例会議のときに、ついでに尋ねる
- 緊急度が低い場合や、定例会議が間近にあるとき
- 定例会議では、全員が「会話する」という態度で望んでいるため、コミュニケーションを取ることに対する抵抗感が薄れている
- ただし、「定例会議ではよく質問するのに、それ以外の場ではあまり聞いてこない」人がいる場合、ひょっとしたらチームが「気軽に質問できない雰囲気」を醸成してしまっているかもしれない
- そういう場合は、まずは質問の雰囲気・文化作りを優先する
- timesでつぶやく
「N分ルール」のアドバイスが十分に活きるのは、メンバー同士の相互的なやりとりが活発なチームでの話
- 聞く人・聞かれる人が固定化されているチームだと、回答の負担が偏ってしまったり、質問者に心理的なプレッシャーを与えたりすることがある
- 積極的に質問し、積極的に答えるチーム文化を醸成することで、チーム全体の開発力底上げにつながるはず
- なにも新人の早期戦力化だけが目的じゃない
- 「N分わからなかったらすぐに聞け！」ではなく、「このチームのメンバーは、壁にぶち当たっても平均N分で解決に至ることができる」という発想になれたらいいよね