コーチングプログラミングで楽しく成長する - ハピネスチームビルディング[4]

この記事の初出は、Software Design 2022年7月号です。

すぐ答えを教えるのはいいことなのか？

あなたは、チームのメンバーから相談を受けたとき、どのように答えているでしょうか？
過去の私は、メンバーから相談された時に、すぐに対応方針を提示し、その対応を間違えないように具体的な手順も説明していました。
しかし、答えを教えるだけでは、メンバーに問題を解決する能力がなかなか身に付きませんでした。
一般的にもティーチング(教える)だけだと、その考えや知識が定着しづらいと言われています。
ある時、自分の行動を振り返り、常に答えを教える事は、メンバーの成長機会を減らして成長を妨げてしまっていたと気付きました。
その反省から、現在の私はコーチングのような問いかけで、自分で答えにたどり着いてもらう事を心掛けています。
今回は、その具体的なやり方を紹介します。

自分で答えにたどり着いてもらう

問題を解決する能力を高めるためには、問題を解決するための思考を本人が繰り返して訓練する事が必要だと考えました。
そこで私は、答えを教えるのでなく質問する事で、自分なりに考えて自分で答えにたどり着いてもらう方法を実施してみました。
それが「コーチングプログラミング」と名付けた方法です(名前にプログラミングと付いていますが、プログラミング以外にも仕様検討や計画検討など、様々なシーンで活用します)。
自分で答えにたどり着く事は、以下の効果があるため、やる価値があると判断しました。

1. 質問をきっかけに、自分で思い出した知識は定着しやすい(「テスト効果」と呼ばれています)

2. 自ら理解した状況を「自己説得」と呼び、行動の変化に繋がりやすい
   (詳細は書籍『 エンジニアリング組織論への招待 』(広木大地 著、技術評論社、2018年)の86ページを参照)

そして3年間やってみた結果、良い効果がありました。
私はこれまで十数人の若手育成の経験がありますが、コーチングプログラミングをやらない時と比べてやった時の方が成長速度が格段に速いと感じています。
そしてなにより、メンバーが「質問をもとに自分でひらめいて答えにたどり着くと、達成感があって楽しい」と言っているので、この連載のテーマである「楽しいチーム開発」をする上でも、とても良い効果がありました。

具体的な会話例

以下に、私と新人のメンバーＭさんとのビデオ通話での会話例を記します。
設計について相談中に、新しく作るクラスの名前を決める時の会話です。
新しいクラスの名前が自分で考えられないＭさんに対して、質問を繰り返して自分で答えにたどり着く体験をしてもらいました。
ポイントは「最終的な答え(今回の場合はクラス名)」にたどり着くために必要な途中の思考を1つずつ一緒に考えていく質問をする事です。

Ｍ「なるほど分かりました！新しくpublicなクラスをつくって、
       そのクラスの中で、さっきの処理をやればいいんですね！」
私「その通り。では、その新しいクラスの名前は何になりますか？」
Ｍ「うーん、分からないです」
私「では、そのクラスの責務を考えましょう。
       そのクラスの責務は何です？」
Ｍ「うーん、分からないです」

私「では、そのクラスで行う、さっきの処理がなんだったのか、
       もう1回教えてもらっていいですか？」
Ｍ「えーと、Factoryクラスのインスタンスを作成して、
       それをLocatorに設定します」
私「それが責務に近いですね。
       でもその処理は、実は複数の事をやっていますね？」
Ｍ「はい、Factoryのインスタンスを作成する処理と、
        Locatorにそれを設定する処理の2つです」
私「このクラスの責務として、重要なのはどっちです？」
Ｍ「LocatorにFactoryを設定する処理です」
私「そうですね。では、このクラスの名前は何になりますか？」
Ｍ「LocaterにFactoryを設定するから、LocaterSetterとか？」

私「なるほど、いいですね。ただ、さらに改善できるかもしれません。
        LocatorにFactoryを設定する必要性を考えてみましょう。
        もしその設定をしなかったら、どうなるんでしたか？」
Ｍ「その後にLocatorを使う処理で失敗します」
私「そうですね。つまり、単に『何かを設定する処理』という意味でなく
      『必ず最初にやっておかないといけない処理』ということですね。
       クラス名の改善案は浮かびますか？」
Ｍ「えーと、うーん、浮かばないです」

私「『必ず最初にやっておかないといけない処理』というのが、
       今まで設計したクラスにもありましたね。それを参考にしましょう」
Ｍ「あ、前に設計したクラスは、
      『必ず最初にやっておかないといけない処理』として、
       Initializeメソッドで初期化をしていました」
私「ということは、今回作るクラスの責務は、何になりますか？」
Ｍ「Locatorを初期化することです」
私「では、そのクラス名は？」
Ｍ「LocatorInitializerです」
私「いいですね。全部自分で考えて設計できましたね！」
Ｍ「はい、どういう考え方で、設計をしていくのか分かりました！」

答えにたどり着いた時、Ｍさんはとても嬉しそうな表情で興奮気味に話してくれました。

テキストコミュニケーションでの例

コーチングプログラミングは、ビデオ通話だけでなく、テキストコミュニケーションでも活用できます。
ただ、テキストコミュニケーションの場合は、何度も質問を繰り返すと、答えにたどり着くために時間がかかりすぎるため、なるべく1回だけの質問で答えにたどり着くように心掛けています。

以下に、私とメンバーＡさんとのSlackでのテキストコミュニケーションの例を記します。

Ａ「XXX機能のインポートの仕様について、
       インポート直後にメッセージダイアログの表示は不要ですよね？」
私「メッセージダイアログ無しでもシステムの状態がユーザーに伝われば
       OKですよ。どんなユースケースでも伝わりますか？」
Ａ「よく考えたらエラー発生時は、エラーの原因を伝える必要が
       ありましたので、その場合はメッセージダイアログを表示します」
私「おみごと！」

上記は「エラー発生時に必要ですよ」と教えるのでなく「どんなユースケースでも問題ないか」を質問する事で、自分で答えにたどり着いてもらいました。

まとめ

私はコーチングプログラミングを、プログラミング以外にも「どんな仕様にするか」や「どのタスクから進めるか」など、仕様検討や計画検討など、様々なシーンで活用しています。

答えを教えるだけなら1分で終わることがコーチングプログラミングを行うと15分かかる事もあるため、現実的にはすべての機会にこれを行う事はできません。
それでも、やったらその分、着実に成長すると感じるので、私は可能な範囲でなるべく実施しています。
メンバーが成長してくれれば、その後の開発生産性が上がるため、この活動で余分にかけた時間は1年以内に確実に回収できていると感じています。

また、注意点として、事前にこれを行う事の意義をチーム内で共有して、皆で納得した上でやる必要があります。
それができていないと、メンバーが「自分のタスクを早く終わらせる事」を優先して考えるため「なんで早く答えを教えてくれないのか」という不満に繋がるかもしれません。

私のチームの場合は、この連載でこれまで紹介してきた施策で「主体的な行動で成果が出る事」による楽しい体験を繰り返して、「成長して様々な事を主体的に提案する事が楽しい」という価値観を皆で共有できていました。
そのため、皆が前向きに取り組んでくれて、今では「コーチングプログラミングをやってもらって良かったので後輩にもやります」と言ってくれています。

楽しく成長するためにお勧めの方法なので、試してみてはいかかでしょうか。

---

次回の記事はこちら↓

前回の記事はこちら↓