1．修正を伝える前に、判断の理由を確かめる

たとえば、入力値が空の場合の処理が抜けていたとします。「空の場合の処理を追加して」で修正は進められます。しかし、その担当者が入力条件を知らなかったのか、知っていても確認を忘れたのかは、その指示だけでは分かりません。同じ修正が必要でも、教える内容は変わります。

そこで、質問する前にリーダー自身が仮説を置きます。「画面側で必ず入力されると思っていたのかもしれない」「正常に動く条件に意識が向き、例外の確認が抜けたのかもしれない」。何を確かめたいかが決まると、質問も具体的になります。

前者なら「この項目には、どんな値が渡ってくる想定で実装した？」、後者なら「入力条件のうち、どこまで動作を確認した？」と聞けます。相手の返答に合わせて仮説を見直し、仕様の理解を補うのか、確認の手順を一緒に考えるのかを決めます。

「なぜこんな実装にしたの？」と理由だけを迫ると、相手が弁明に追われることもあります。私は、説明してもらいたい対象を、人格や能力ではなく、仕様・前提・確認した事実に置くべきだと考えています。担当者の考え方が分かれば、助言する箇所も絞れます。

2．次に確かめることを、本人の言葉にする

修正方法を理解したかどうかは、「分かりました」という返事だけでは確かめきれません。今回の指摘を、次の実装で何に使うかまで言葉にしてもらいます。

たとえば「次は例外処理に気をつけます」で終わらず、「APIへ渡す値が空のときと、想定外の値のときの動きを、レビューに出す前に確認する」と整理します。そのうえで、仕様書やテスト結果のどこに確認内容を残すかを決めます。確認の仕方は、チームの開発ルールに合わせます。

ここでリーダーが確認項目を全部書いて渡すと、担当者が自分で考える部分まで引き受けてしまいます。まず本人に挙げてもらい、足りない条件を補う。次のレビューでは、前回決めたことを何に当てはめ、どんな結果を確かめたかを聞きます。

もちろん、リリース直前の重大な不具合など、その場で明確な指示が必要な場面もあります。問いかけだけで進めようとせず、必要な修正と優先順位を示します。そして落ち着いた段階で、なぜその判断が必要だったかを振り返る時間を取ります。

研修では、答えを知っている側の関わり方を練習する

技術力がある人ほど、成果物を見れば修正案がすぐ浮かぶでしょう。若手リーダーの研修では、その知識を、相手の判断力を育てるためにどう使うかを扱いたいと考えています。

今回の課題に合わせた演習例なら、簡単な詳細設計とレビューコメントを題材に、リーダー役・担当者役・観察役に分かれます。リーダー役は、担当者がどこで判断を誤ったのか仮説を立て、確かめる質問を用意します。担当者役の説明を聞いた後で助言し、次の実装で確認することを本人に整理してもらいます。

観察役は、質問の数ではなく、やり取りの中身を見ます。相手の前提が分かったか。助言の理由が伝わったか。担当者が次に行う確認を説明できたか。役割を交代し、同じコメントでも伝え方によって何が変わるかを確かめます。この演習は設計例であり、既存の標準教材や実施実績を示すものではありません。

次のレビューを、育成の振り返りに使う

研修後には、職場で試すレビューを一つ決めます。担当者の判断理由を聞いた場面と、次回の確認について合意した内容を、機密情報を含まない形で記録します。

次の研修では、「対話を意識した」という感想に加えて、担当者の説明や成果物の確認方法がどう変わったかを振り返ります。自分で確認条件を挙げられたか。迷った段階で相談できたか。リーダーが先に答えを言ってしまった場面はなかったか。上司にも可能な範囲で関わり方を見てもらえば、自分では気づきにくい癖も検討できます。

指摘が減ったかどうかは、案件の難しさにも左右されます。私が育成の手がかりにしたいのは、メンバーが判断の根拠を説明し、確認し、必要なときに支援を求められるようになったかです。その行動を見ながら、次に練習することを決めます。

レビューを任せられる若手リーダーを育てるために

人間力教育センターのリーダー育成アカデミーでは、メンバーの育成指導や対話など、各社の課題に合わせたテーマを、研修・職場での実践・振り返りにつなげて設計します。相手の考えを受け止める姿勢と、品質に責任を持って判断する力を、仕事のスキルと一緒に育てていきます。

コードの修正は指示できるが後輩の判断力が育たない、レビューが特定のリーダーに集中している。そうした課題があれば、対象者に任せたい役割と、今のレビューの進め方から、育成の内容を考えませんか。回数や実施時期が決まる前でもご相談いただけます。