「幼稚園じゃないんだよ」と、心の中で毎日思っている。
口には出さない。でも3人体制で回しているチームの現実は、なかなかそういうものだ。未経験から育てた2人と、自分の話を書いておく。
2人の部下——正反対のタイプ
1人目は、自分とほぼ同じ時期に入社した、当時アルバイトの新卒だった。完全に未経験。
最初に気になったのは会話だった。相手が喜ぶような言葉を選ぶ、変に丁寧に振る舞おうとする——でも実態が伴っていない。YesかNoで答えられるように質問しても、聞いていないことまで話し足してくる。要領を得ない。これが今も日常茶飯事だ。
ただ、根性はあった。どれだけ厳しく言ってもへこたれない。技術的には着実に伸びてきて、今では後輩の指導も任せている。会話が成立しない問題は、まだ悩みの種のままだが。
2人目は、自分が一次面接に関わって採用した人間だ。入社後、居眠りが始まった。やる気が見えない。他のメンバーが指導したが「お手上げ」と言ってきた。
自分で呼び出して面談した。次やったら上層部に報告すると伝えた。また居眠りした。本部長と人事部長に報告して、三者面談になった。本部長から「病院に行け」と言われ、今ナルコレプシーの疑いで受診している。
採用に関わった人間が問題を起こすのは、こたえる。
コーチング哲学——誰かに教わったわけじゃない
「答えを教えない。自分で考えさせる。相談にはいつでも乗るが、答えはこちらから出さない。」
これは誰かに教わったわけじゃない。自分が行き着いた方法だ。
教えられたことより、自分で考えて至ったことの方がはるかに定着すると気づいたから。自分がそういうタイプだった、というだけかもしれない。でも、それが今の指導の軸になっている。
質問が来たときの返し方はこうだ。
「どこで詰まってる？」
「エラーメッセージは何と言ってる？」
「自分ではどう解決しようとした？」答えを渡さない。問題を言語化させる。言語化できた瞬間、自分で解決策が見えることが多い。それでも進めないときは、ドキュメントのリンクだけ渡す。方向性だけ示す。コードの一部だけ見せて「残りは自分で」と言う。
詰まる体験が、一番の成長だと思っている。
タスクアサインは「失敗できる設計」で
最初のタスクは影響範囲を限定する。
× 「このAPIを実装して」（範囲が広すぎる）
○ 「このエンドポイントのバリデーション処理だけ書いて」最初の1ヶ月は、本番に影響しない・他の機能と独立している・1〜2日で完了できる、この3つを基準にした。失敗しても大丈夫な環境を用意した上で、あえて詰まらせる。
コードレビューは段階的に手を離した
| フェーズ | レビューのスタイル |
|---|---|
| 0〜3ヶ月 | 全行コメント。理由を必ず説明 |
| 3〜6ヶ月 | 重要な箇所のみ。「なぜ？」を質問形式で |
| 6ヶ月〜 | 大枠のアーキテクチャのみ。細部は任せる |
「こうしてください」ではなく「なぜこう書いた？」と聞く。説明できれば通す。説明できなければ一緒に考える。
接客業からの接続
小売業で主任をしていたとき、新人にレジ操作を教えていた。手順だけ教えると、イレギュラーな場面で動けない。「なぜこの手順なのか」を理解させることで、応用が効く。
エンジニア育成も同じだ。コードの書き方を教えるのではなく、「どう考えるか」を育てる。本質は変わらない。
育てながら、全部一人で回している
2人を育てながら、自分はコード管理・要件定義・技術管理・プロジェクト管理・タスク管理・採用・チーム設計まで全部やっている。
コーチングの話を書いていて思うのは、「育てる余裕がある状態でやっていたわけじゃない」ということだ。余裕がないまま、それでもやるしかなかった。
「幼稚園じゃないんだよ」と思いながら、明日もまた1on1をする。
関連記事: テックリードとして3年間、仮面を被り続けた話