新卒エンジニアが中途エンジニアのピアメンターをやってみた

はじめに

新卒1年目の私が、中途エンジニアの方のピアメンターを行いました。ピアメンターというのは、年次や技術力が近いもの同士で行うメンタリングです。

本記事は、そのピアメンター活動のまとめです。

• メンター初心者が何を考えて指導に当たったか
• 技術力が近いもの同士でも効果はあるのか
• メンティーはどのような点を難しいと感じているのか

あたりは参考になるのではないかなと思います。

来年は新卒の後輩方も入社されるので、その準備という意味合いもあります。

事前調査

今回のメンターに当たって、念頭に置いていた考え方・方法です。
以下の本を参考にしました。

• 自分の頭で考えて動く部下の育て方 上司1年生の教科書

• エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

あくまで現時点での仮説なので、これがベストではないと思います。今後メンターを行なっていく中で、より洗練させるための叩き台、といった位置付けです。

メンターの役割

• 「メンティーの課題を解決する」ことではなく、「"メンティーが自立的に課題解決する状態"に導く｣こと
• 自立的に課題解決する状態とは？ => 「弊社で活躍している人」から抜粋
  • 姿勢:他責でなく自責
  • コミュニケーション:自分の意見に対して判断を求める
  • ロジカル・クリティカルシンキング:前提条件が正しいか確認
  • スピリット:思考・コミュニケーション効率

メンターがやるべきこと: 1. 課題を分解する

• 解けないパズルを、「ひとりでも」解けるパズルに変換する
  • 「ひとりでも」解ける -> 自己効力感
• SMARTのフレームワーク
  • 特にSAR
    • Specific （具体的に）
    • Achievable （達成可能な形で）
    • Relevant （関連性を示す）
  • これを意識してタスクを渡す

メンターがやるべきこと: 2. 仮説思考を促す

• 自立的な問題解決 = 仮説思考
  • レベル1: （指示があるまで何もしない）
  • レベル2: ｢何をすればいいですか？｣
  • レベル3: ｢こうしようと思うんですけどどうですか？｣
    • -> レベル3になってもらう
• ソクラテスの問答法(産婆術)
  • 「相手の質問や答えに対し、新しい情報を加味して、新たに質問する」ことを繰り返す
    • メンターはあえて正解を教えない
  • 自分で答えに辿り着く -> 自己効力感

実際にやってみた

背景：レベル感やタスク内容

• お互いのレベル
  • メンター（筆者）：新卒1年目のWebエンジニア。業務内のコードは大まかに理解してきたが、基礎的な知識はキャッチアップ中の段階。
  • メンティー：中途入社数ヶ月目のWebエンジニア。ジュニアレベルでの入社。ソフトウェア工学のバックグラウンドと、少人数でのサービス開発の経験がある。チーム開発の経験に乏しい。
• 扱ったタスク
  • 自社サービス内の、期間限定のキャンペーン機能。
  • メンティーにとっては入社してから最も大きなタスク
• 期間
  • 全体で3週間ほど
    • 仕様の擦り合わせや、設計、既存コードの理解に1週間
    • 実装・レビュー・テストに2週間

メンターとしてサポートした内容

• 設計全般
  • 企画・仕様の理解
  • DB、バックエンド、フロントエンド
  • どのモデルやコンポーネントが使えそうかのアドバイス
• テスト・レビュー・リリースなどのフロー決め
  • レビューやテストの順序をどうするか
  • リリース順序をどうするか（いくつかのブランチに分けて開発をしていました）
  • ディレクターサイドに伝達すること

細かい実装自体はある程度1人でこなせそうだったため、設計と、チームでの動き方などのサポートを重点的に行いました。

感想

メンティーからのフィードバック

開発する上で

• 勉強になったところ
  • 企画の意図や仕様の擦り合わせのやり方
• 苦労したところ
  • バックエンドの設計
  • スケジュールの見積もり
  • フロントエンド全般

メンティーとして

• 助かったところ
  • 必要があったら手伝ってくれるという安心感
  • 適度な進捗確認（頻繁すぎず、放置しすぎず）
  • 設計の段階で、使うコントローラやメソッドまで確認できた
    • デメリット・起こりうるエラーを指摘
  • 「〜さんはどうしますか？」という質問
    • 「まず自分の考えをまとめ、それについて意見を求める」という習慣がついた
• もっとこうして欲しかったところ（メンターへの改善要望）
  • より上位の人に相談すべき高度な問題も2人で悩んでしまっていた

メンター（筆者）の振り返り

Good

全体としては上手くいった部分が多かったように思います。

設計の段階で、使うコントローラやメソッドまで確認できた

メンティーがまだサービス全体のコードに慣れていなかったので、設計の段階から、必要に応じてソースの中身まで一緒に読むようにしていました。

最初のうちは、コード全体の構造を掴めていないので、トップダウン・抽象的に考えるよりも、ボトムアップ・実装などの具体例を使う方が、理解が進むのかもしれません。
実は深く意識していた部分ではなかったので、良い気づきになりました。

「まず自分の考えをまとめ、それについて意見を求める」という習慣がついた

仮説思考の部分は、今回最も強く意識していた部分だったので、この言葉を聞けて安心しました。

個人的な考えですが、「〜さんならどうしますか？」という聞き方は、相手との関係性によっては「詰められている」と受け取られる場合があります。今回は上手くいきましたが、これは僕の伝え方が良かったというよりは、むしろメンティーに助けられた部分が大きい印象です。今後ここをどうクリアするかは課題の1つです。

Bad

根本的な問題点も浮上しました。

より上位の人に相談すべき高度な問題も2人で悩んでしまっていた

私自身の開発スキル不足が露呈した形です。メンター（筆者）のスキルが不足しているために判断に迷う問題は、一旦切り分け、上司などより詳しい方に相談すべきでした。特に「決め」の問題に関しては、早めにヘルプを求めるべきだったなと感じています。

当たり前ですが、知らないことは教えられません。まずはエンジニアとして十分なスキルを身につけることも、メンターの責務だなと感じました。

まとめ

他者をサポートする・導くというのは、難しい役回りである一方で、メンター・メンティー双方に得るものがあります。また、1人のエンジニアの方が1日でも早く戦力になってくれるのは、チーム全体としてもメリットです。

来年は新卒の後輩方も入社されるので、さらに試行錯誤を重ね、メンターに関する知見を貯めていきたいです。