開発チームにおけるティーチングとコーチングの使い分け

ソフトウェア開発の現場で、レビューや設計の議論、障害調査のときに「話が噛み合わない」「メンバーがなかなか自力で動けない」と感じることはありませんか？

もしかすると、その原因は技術力不足ではなく、「教えること（ティーチング）」と「引き出すこと（コーチング）」の使い分けが適切にできていないからかもしれません。

特に経験豊富なエンジニアほど、「正解が見えているのにあえて教えない」アプローチは想像以上に難易度が高いものです。今回は、両者の違いと使い分け、そして経験者ゆえに陥りがちな罠と対策についてまとめました。

そもそもteachとcoachは何が違うのか

2つの言葉は、語源をたどるとその役割の違いがよく分かります。

teachとは正しい道や目印を指し示すことであり、showやpoint outと言い換えることができます。つまり、知っている人が知識や答えを直接渡すアプローチです。一方で、coachの語源はハンガリーの町名に由来する「四輪馬車（coach）」であり、大切な人を望む目的地まで送り届けること。主役はあくまで乗客（相手）であり、コーチはその人が進みたい方向への移動をサポートする役割を担います。

これを開発の現場に置き換えると、「答えを指し示すか」「相手が目的地にたどり着くのを支えるか」という考え方の違いが生まれます。

2つのアプローチの違い

この表から分かるように、ティーチングは正解を素早く提示するための方法で、正確な手順を指し示したい場合に効果的です。コーチングはゴールを示した上で相手に考えさせる必要があり、時間がかかりますが対話の積み重ねにより、自走力が育つという利点があります。このように、どちらが優れているという訳ではありませんが、状況に応じて両者を使い分けることにより、議論の価値を高めることができます。

なぜ正解を知っている人ほど「相手の気付きを引き出す」のが難しいのか

ここからは、正解を知っていても相手の気付きを引き出すことが難しい理由を、具体例から考えてみます。

具体例で考えてみる

ある開発者は、アプリの処理速度が異常に遅いという不具合の調査に時間を要しています。データベースのクエリログを見たあなたは、ループ内で不要なDBクエリが多発しており、取得処理を1行直せば直ることを発見しました。そこで、あなたは「ここで無駄なクエリが走ってるから、まとめて取得するように直しておいて」と指示しました。これにより、アプリの不具合はすぐに解消しました。

一見すると、あなたのサポートにより不具合に迅速に対応できたというシンプルな話に思えますが、このメンバーはあなたの指示通りプログラムを直しただけで、次回同じ問題に自力で気づく思考プロセスは身についていません。では、同じような状況で答えを言いたい気持ちを抑え、「ログを見てみて、ループの中で気になる動きはない？」などと問いかけるとどうなるでしょうか？同じクエリが何十回も実行されていると本人が気づき、自力で解決策にたどり着けるかもしれません。

しかし、実際に相手の気付きを引き出そうとすると様々な問題に直面します。

気付きを引き出す行為を阻むもの

先ほどの例では、あなたは誰よりも早く問題の原因に気付いていました。それなのに相手に合わせて丁寧なヒアリングをしていると何が起きるでしょうか…？結果は明白で、答えが見えている人ほど、わずかな指示で終わるものを時間をかけて対話することに心理的コストを感じてしまうのです。また、問題を引き起こす過程を1つずつ説明しようとしても、自身はすでに答えを知ってしまっているため「なぜ相手がここに気づかないのか」が直感的に理解しにくくなります。その状況を打開するため、まずは相手に問いかけることもできますが、無意識に「自分の頭の中にある正解」を当てさせるクイズになってしまい、相手がその空気を読むだけの時間になることさえあります。

相手に何かを考えさせるためには、単なる問いではなく次のステップに進むためのヒントを与える必要があります。つまり、指導者側は「正解を当てさせる問い」をやめ、思考の範囲を絞るヒントを出すことに集中することが有効です。

正解ではなくヒントをもらいにいく

ここまで答える側の葛藤や対応を見てきましたが、実はこの問題は、答える側だけでなく質問する側の工夫次第でさらなる改善が見込めます。具体的には、議論の目的を「正解を教えてもらうこと」から「自力で進めるためのヒントをもらうこと」に切り替えるという方法です。先ほどの例で言うならば、以下のような質問の仕方をすると良いでしょう。

• まずは、どのログやファイルから着目すべきか、切り口だけ教えてもらえますか？
• いまは〜が原因だと疑っています。この仮説を確かめるには、次にどの指標を見れば良いでしょうか？
• A案とB案で迷っています。判断する上で見落としているリスクはありますか？
• 自分で考えたいので、前に進めるためのヒントだけください

現場での使い分け

以上のように、コーチングはメンバーの自走力を育てるのに役立ちますが、常にヒントだけを聞いたり話したりしていては議論が前に進まないこともあります。そのため、以下のようにティーチングと組み合わせ、状況に応じて使い分けると効果的です。

1. ティーチングが適している場面

• コーディング規約やセキュリティ要件など、議論の余地がないルール
• ドメイン固有の業務仕様や過去の経緯など、調べても出てこない前提知識
• システム障害中など、育成より復旧スピードが最優先の緊急対応

2. コーチングが適している場面

• 納期と拡張性のトレードオフなど、唯一の正解がない設計方針の議論
• クラス設計やモジュール分割など、構造の良し悪しを学んでほしい場面
• 再発防止策やチーム改善など、当事者意識を持って深掘りしたい振り返り

明日から使えるちょっとした工夫

1. 「なぜ」ではなく「どんな背景・意図で」と聞く

「なぜこう書いたの？」は責められているように聞こえやすいため、相手が防衛的にならず前提条件を共有できる聞き方に変換します。

• 避けた方が良い聞き方: 「なんでキャッシュ使ってないの？」
• 適切な聞き方: 「キャッシュを使わない構成にした意図や、想定しているアクセス頻度を教えてもらえますか？」

2. 目的や価値観を聞く

指示は相手の思考を止めがちですが、実現したいことや重視した点にアプローチすることで、主体的な行動を引き出せます。

• 避けた方が良い聞き方: 「なんでそのやり方でやるの？」
• 適切な聞き方: 「何を実現したくてその方法を選びましたか？」

おわりに

ティーチングは正解を渡すものであり、コーチングは正解にたどり着く思考プロセスを渡すものです。正解を知っている人ほど、あえて言わずに問いを投げる難易度は上がります。しかし、相手に正解を覚えさせるのではなく、正解に気付いてもらうことは主体性を育む上で重要です。また、質問側も答えではなく次の一歩のヒントを求める姿勢を持つと互いに会話が噛み合いやすくなります。コーチングは単独で行うこともできますが、指導者と学習者の双方が協力して行えば議論の質が高まります。そのための第一歩として、レビューや議論が噛み合わないときに「今どちらのスタンスで話しているか」をお互いに意識するだけでも、チームの自走力はぐっと高まるのではないでしょうか。