第5話 コーチングプログラミングで成長を加速
誰に対しても、リスペクトの気持ちを持つ。
そういう決意で、後輩の真山さんとのペアプログラミングを始めてみたところ、新たな発見がいくつもあった。
今まで私は「自分の方が上、自分が教える」というスタンスだった。
しかし、ビジネスパートナーとして対等な関係だと思って接することで、真山さんが持っている知見を教えてもらうということが起きた。
「チェリーピック、便利ですね」
私がつぶやいたそれは Git というバージョン管理システムのコマンドだ。
Git の使い方については私より真山さんの方が詳しかった。
今まで後輩に教えてもらうという行動をしたことがなかったが、これからは誰に対しても学びを得ようという真摯な姿勢が大切だとあらためて感じた。
「それにしても真山さん、Git について凄く詳しいですね。凄く勉強になりました」
「いえいえ、そんな。でも、実は Git のコマンドは、学生時代にハマって色々試して遊んでたんです」
「なるほど！それが今しっかり活きてるんですね」
お互いに笑い合いながら、自然と学び合える空気ができていた。
この雰囲気がとても嬉しかった。
そんな中、ある機能について真山さんが質問してきた。
「ここのインポート機能って、インポート直後にメッセージダイアログの表示はいらないですよね？」
いや、それは違う。
エラーケースを考慮すれば、メッセージダイアログは必要だ。
しかし、私はその回答を言うことに戸惑っていた。
昨日までは、さんざん「違うよ、それはこうすべき」と言って真山さんを否定し、自分こそが正しいというスタンスでやってきた。
その姿勢を反省したばかりだ。
こういう時は、なんて言えばいいんだろうか。
その時、私は昨日、ギルドの Slack で見た「テスト効果」という言葉を思い出して、とっさにこう返した。
「UXの基本として、システムの状態がユーザーに伝わることが大切ですよね。メッセージダイアログ無しでも伝わるならOKです。どんなユースケースでも伝わりますか？」
真山さんは、少し考えた後、はっとして答えた。
「あっ、よく考えたらエラー発生時は、エラーの原因を伝える必要がありました！その場合はメッセージダイアログを表示した方が良いです！」
「はい、私もそれが良いと思います」
私は心の中で「お見事！」と叫んだ。
そして、さきほど思い浮かんだ「テスト効果」を使った新しい施策を思いつき、真山さんに提案しようと考えた。
「今の判断、すごく良かったですね。私が『どんなユースケースでも』って聞いただけで、自分で考えて答えにたどり着いてましたね」
「ありがとうございます。聞かれて初めて、エラーケースのことを見落としてたことに気づきました」
「それ、大事なポイントです。私も昨日、ギルドっていうIT系のオンラインコミュニティで教えてもらったんですけど、『テスト効果』というものがあって、質問をきっかけに自分で思い出した知識は定着しやすいって言われているんです。
ただ教えてもらうよりも理解が深くなって、記憶にも残りやすいんです」
「確かにエラーケースの時に必要だよ、って教えてもらうだけだったら、あまり印象に残らなかったかもです」
「それと、昨日読んだ『エンジニアリング組織論への招待』って書籍に書いてあったんですけど、コーチングのような問いかけをきっかけに、自分で答えにたどり着いた方が、その後の行動変化に繋がりやすいとも言われているんです。
さっきのテスト効果と合わせて、これらの理論をもとに新しい手法を思いついたんですけど、聞いてもらっていいですか？」
「はい、もちろんです」
「その手法は、仮で『コーチングプログラミング』っていう名前にします。それは、コーチングのような問いかけのスタイルを意識的にやる方法です。たとえば、クラス設計とか仕様検討のときに、さっきみたいな問いかけを通して、真山さんに自分で答えにたどり着いてもらうという手法です」
これは「自分の方がスキルが高い」という前提の手法だ。
でも間違ってないと思う。
相手をリスペクトすると言っても、経験値の多い自分が、新人の真山さんを育成することは業務上 必要なことだ。
「自分の方がスキルが高いから指導する」という考え方と「相手をリスペクトする」という考え方は相反しないはずだ。
真山さんは、少し考えた後、笑顔で答えた。
「はい、良いと思います。実はさっき、野島さんに『どんなユースケースでも』っていうヒントをもらって、自分でエラーケースのことをひらめいた時に、ちょっと達成感があったんです。だから楽しいかもしれませんし、やってみましょう」
真山さんから色よい返事をもらって、私たちは、さっそくコーチングプログラミングを試すことにした。
「じゃあ、さっき話してた新しく作るクラスの名前は何が適切ですか？」
「うーん、分からないです」
「では、そのクラスの責務を考えましょう。そのクラスの責務は何です？」
「うーん、分からないです」
分からないが続いてしまったが、これはしょうがない。
よくよく考えれば、今まで新しくクラスを作る時のクラス名は、すべて私が付けていた。
だから、真山さんはクラス名の付け方を知らないし、クラスの責務というのも、私があまり教えてこなかった。
それを踏まえて、あらためてコーチングプログラミングを続けた。
「では、そのクラスで行う、さっきの処理がなんだったのか、もう1回教えてもらっていいですか？」
「えっと、Factoryクラスのインスタンスを作成して、それをLocatorに設定します」
「それが責務に近いですね。でもその処理は、実は複数の事をやっていますね？」
「はい、Factoryのインスタンスを作成する処理と、Locatorにそれを設定する処理の2つです」
「このクラスの責務として、重要なのはどっちです？」
「LocatorにFactoryを設定する処理の方が重要です」
「そうですね。では、このクラスの名前は何になりますか？」
「LocaterにFactoryを設定するから、LocaterSetterとか？」
「なるほど、いいですね。ただ、さらに改善できるかもしれません。LocatorにFactoryを設定する必要性を考えてみましょう。もしその設定をしなかったら、どうなるんでしたか？」
「その後にLocatorを使う処理で失敗します」
「そうですね。つまり、単に『何かを設定する処理』という意味でなく『必ず最初にやっておかないといけない処理』ということですね。クラス名の改善案は浮かびますか？」
「えーと、うーん、浮かばないです」
「『必ず最初にやっておかないといけない処理』というのが、今まで設計したクラスにもありましたね。それを参考にしましょう」
「あ、前に設計したクラスは、『必ず最初にやっておかないといけない処理』として、Initializeメソッドで初期化をしていました」
「ということは、今回作るクラスの責務は、何になりますか？」
「Locatorを初期化することです」
「では、そのクラス名は？」
「LocatorInitializerです」
「いいですね。全部自分で考えて設計できましたね！」
「はい、どういう考え方で、設計をしていくのか分かりました！」
答えにたどり着いた時、真山さんはとても嬉しそうな表情で興奮気味に話してくれた。
その後も、コーチングプログラミングを何度かやってみた。
そして、分かったことがある。
答えを教えるだけなら1分で終わることがコーチングプログラミングを行うと15分かかる事もあるため、現実的にはすべての機会にこれを行う事はできない。
それでも、やったらその分、着実に成長してくれたように感じる。
真山さんが成長してくれれば、プロジェクトの生産性が上がるため、この活動で余分にかけた時間は成長することで十分に回収できそうだと感じた。
この時、自分が考えた手法で、チームメンバーが楽しく成長してくれるという体験に私は酔いしれていた。
きっと、このプロジェクトはうまくいく。
そう信じられた。
そう、この時までは ――――――――。
アルフォンス・エルリック氏は
「何かを得るためには同等の代価が必要になる」
と語った。
つまり、対価を払えば、結果はついてくる。
成果も、成長も、絆も。
そう信じていた。
でも、現実は残酷だった。
「等価交換」なんて、ただの幻想だったのかもしれない。
