コンサルティング部のメンター制度と案件振り返りの紹介

メンター制度の紹介

AWS事業本部コンサルティング部には、AWSエンジニア、ソリューションアーキテクト（SA）、エキスパートソリューションアーキテクト（ESA）のロールがあります。新しくジョインされた方は AWSエンジニアもしくは SAとしてスタートし、ESAを目指していただきます。ESAは1人前のエンジニアという形です。AWSエンジニアやSAには、ESAが案件ごとにメンターがつき、気軽な相談先になったりクラスメソッドの仕事のお作法のレクチャーなどを行います。

コンサル部では、AWS環境の構築やコンサルティングなどを行います。構築やコンサルティング案件が終わったら、メンターとメンティで案件の振り返りを行います。先日私がメンターをした案件で振り返りを行ったところ、メンティから良い振り返りができたことと、振り返りについての知見をシェアして欲しい旨のフィードバックをいただきました。この記事では私が振り返りに関して意識していることを紹介します。

メンティが入社間もない場合は、メンターがフロントに立ち一緒に案件対応することもあります。一緒に案件対応しないケースでは、私は主に以下をメンティのレベル感にあわせて行います。

• 成果物のレビュー
• ネクストアクションの確認
• 全体のスケジュール感の確認
• 進捗、困ったことはないかの確認
• ミーティングの同席
• メンティからの相談にのる
• お客様とのやり取りの確認
• 案件Slackチャンネルの確認

メンターがメンティの活躍ぶりを知っていたり、メンティがフォローを必要としていない場合、メンターはメンティからの相談にのるだけといった薄いフォローを行う場合があります。メンターとしては薄いフォローに入り実質なにもしていないケースもありますが、そのような場合の振り返りに苦労しているかたも多いかと思います。お客様とのやり取りの確認と案件Slackチャンネルの確認については、案件がうまくいっているかの把握のためにも行いますが、振り返りの観点ではお世辞を言わないためとGOODポイントに共感するためにやっています。詳しくは後述します。

振り返りページについて

振り返りは30分程度のMTG形式で行います。MTG前にメンティーが以下に関する問いが書かれたページを作成しページに記載する形で回答します。問いに答える形で進めると振り返りがよりよくできると考えています。具体的な問いは後述します。

• お客様の課題について
• 案件について
• 自分（各自）について
• メンターからメンティへ
• メンティからメンターへ

振り返りMTGの進め方

メンティが用意してくれたページをお互いに見ながら、加筆していく形で振り返りをすすめます。メンターはMTGの心構えとして、メンティに興味関心を持ち振り返りを支援するんだ！という気持ちを持ちます。メンターが薄いフォローにはいり実質なにもしていないケースでは特に注意が必要です。"なにもフォローしていないからわからないんだよなぁ"などという気持ちを振り払います。振り返りは平等な関係の中で行います。メンターとメンティという関係からメンターの力関係が強くなりやすいです。

問い：お客様の課題について

各項目ごとに問いの背景やポイントを説明します。以下の問いにこたえる形で案件の概要の再認識を行います。メンティとメンターの目線をあわせます。

• お客様の課題について
  • お客様の課題はなんでしたか
  • 今回の案件で何をすることで上記課題を解決に近づけることができましたか

メンターは案件や課題解決のためのアクションについて不明点があれば、質問します。直近の振り返りでは、"お客様のセキュリティに関する課題を解決できた"ということだったので、課題を解決できたと感じた理由について追加でお聞きしました。問いに対する答えはメンティの中にあります。メンティが思い出すように話していれば振り返りができているはずです。

メンターは問いの中でアドバイスをしたくなるタイミングがあると思いますがアドバイスはせずに、問いを通して振り返りを促進します。アドバイスはメンティから求められたら行います。メンティの発言が問いから脱線しても構いません。振り返りから逸脱している状態が長く続いた場合は、メンターから軌道修正します。多少の脱線は許容したほうが、振り返りはうまくいくようです。脱線したかのように見えていても、最終的には振り返りにつながっていることがよくあります。

問い：案件について、自分（各自）について

仕事なのに満足度とは何事か！と思われるかたもいるかもしれません。数値として示してもらうことで、メンターからすると案件に対するメンティの気持ちを把握しやすくなり、問いの設計に役立ちます。ポジティブな発言が多くても満足度が低いこともありますし、その反対もあります。GOODポイントについては、メンターが本当に素晴らしい感じたらその旨を伝えます。素晴らしいと思っていないのに素晴らしいというとお世辞になってしまい、お世辞であることがメンティに伝わってしまいます。メンターがGOODポイントを素晴らしいと感じない場合は、問いを深堀りしていくことでGOODポイントの背景を知っていきます。よりよくできるポイントについても同様です。

• 案件について
  • 満足度は？（10段階）
  • その理由は
  • 準備は十分でしたか
  • しておけば良かった準備はありますか
  • GOODポイントは
  • よりよくできるポイントは
  • 何が大変でしたか
  • どうやって乗り越えましたか
• 自分（各自）について
  • この案件で見えてきた長所は
  • この案件で見えてきたよりよくできる箇所は
  • アウトプットについて
    • 案件対応で得た知識をアウトプットしましたか
    • アウトプットしたもの/出来そうなもの
  • アラートについて
    • 必要に応じてアラートをメンターorリーダーに事前に連携できましたか
  • 稼働時間について
    • 稼働時間は適切でしたか
    • 高負荷な状況は発生しませんでしたか
    • 体調に問題はありませんでしたか
  • 案件の売り上げは把握していますか
    • その上で適切なタイムマネジメントはできていましたか
    • 過剰な稼働だった場合、特別な理由はありましたか

アウトプットしたもの/出来そうなものについては、画面共有して見せてもらっても良いと思います。先日はとてもわかりやすいお客様向けの手順を見せてもらいました。実物を見せてもらうことで、メンティが感じたGOODポイントやよりよくできる箇所に共感できるようになります。

問い：メンターからメンティへ

メンターからメンティへGOODポイントやよりよくできるポイントを改めて伝えます。新しいことを伝えるというよりは、問いの中でお互いが認識したことを繰り返す形になるはずです。

• メンターからメンティへ
  • メンティのGOODポイントは？
  • よりよくできるポイントは？

問い：メンティからメンターへ

メンティからメンターにフィードバックをもらいます。

• メンティからメンターへ
  • 案件対応さらによくするためにどういったフォローがあると嬉しいですか？
    • 例
      • 苦手な分野のフォロー
      • フロント対応
      • 案件マネジメント
      • 稼働の効率化
      • など

直近では、以下のようなフィードバックをいただきました。

• 案件開始時にネクストアクションを聞いてくれた
  • 自分の考えていたネクストアクションに自信が持てました
• 全体のスケジュール確認をしてもらえた
• 途中で進捗確認をポーリングしてもらえた

私からは、メンティがAWSエンジニアであること、また初めてメンターをやるかただったので手厚めに見ようということで、ネクストアクションや進捗確認をしたことを伝えました。ネクストアクションやスケジュールへの考えがしっかりしていたので、進捗確認は週に1回程度Slackベースで簡易的に行いました。振り返りでは、メンティの気持ちやアクションの背景を問いで深堀りしますが、メンターとしてどのような背景でアクションしていたのかも深堀りして考えながら伝えると良いと思います。案件振り返りの場がメンターの振り返りの場にもなるはずです。

まとめ

振り返りは平等な関係の中で、問いを使って行います。問いを通して、メンティの考えやアクションの背景を深堀りします。メンターは不明点があれば振り返りページにない問いについても質問します。メンティが気持ちよく話してくれれば良い振り返りができているはずです。メンティからメンターへのフィードバックについても、過度に受け止めるぞと考えなくて良いかと思います。平等な関係の中で実現可能性などを話し合います。

メンティが一人で案件を対応できる場合、メンターは深く関与しないケースが多くあります。その場合でも、問いの設計をうまくやり気持ちよく喋ってもらうことで振り返りに貢献できると思います。振り返りで行う問いの答えはメンティの中にあります。メンターは求められたらアドバイスをしますが、メンティが考え答えを見つける手助けをすることを優先します。

振り返りに正解はないと思いますが、どなたかの参考になれば幸いです。