はじめに

新卒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日でも早く戦力になってくれるのは、チーム全体としてもメリットです。

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

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