はじめに

この記事はサムザップ Advent Calendar 2022 の12/13の記事です。
昨日の記事は @fk_chang さんによる「新卒でいきなり運用タイトルに携わった自分がやってて良かったこと / やるべきだと思ったこと」でした。

概要

はじめまして！サムザップの樋口です。
社会人4年目となり、マネジメントや後輩の育成を行う機会がかなり増えてきました。
プロジェクトで定められている開発の方針を教えたり、技術的なアドバイスをする場合はある程度形が決まっていることが多いですが、マネジメントや育成には答えが一切ないのです...！
今回の記事も正解ではありません。あくまで個人的に意識している内容なので、これから育成に携わる時に全然やり方が分からない！と悩んでいる人が参考にしてみるくらいの気持ちで見てみてください。

ゴールを決める

まず、何ヶ月後にどのような状態になっていれば良いのか、ゴールを決めましょう。
自分が評価者であれば、対象となるメンバーの目標設定もその一つです。
ゴールを決める際にもセットで意識していることがあります。

マイルストーンを決めること
モチベーションは高いか
認識ズレはないか

ゴールを決めたとしても、関わるメンバーがやりたいこととズレているとうまくいきません。
意見を尊重して個々に合わせた方向性を定めることが大事になります。

育成中のコミュニケーション

目標達成に向けて、実際に動いていくフェーズです。
マネジメントする側は、本人やチームがちゃんと成長できる環境を整えたり成果を出せるようにするのはもちろんですが、成果をちゃんと吸収して発信していくことも大事な仕事だと思っています。

スポットを当てる

例えば、僕の場合トレーニーが最初のタスクを完了したとき、チーム全体に「◯◯さんが対応してくれたこのチケットがマージされました！vX-X-Xのおさわり会でぜひ見てみてください！」といった発信を行っています。
本人の成果をちゃんとマネージャーやトレーナーが外に出してあげることで本人の認知にも評価にも大きく繋がります。
人によっては自分でアピールしていくのが苦手、伝え方があまりよくない場合もあるのでマネージャー側でアピールしやすい環境を整えてあげたりフィードバックしてちゃんと成果を出した本人にスポットが当たるようにしてあげましょう。

自走の道標

言われたことをやるだけでは、フォローがなくなった時に臨機応変に対応できない人になってしまいます。
開発方針など決められたことは早めに伝えた方が良いですが、基本的には答えを教えるのではなく、答えに辿り着けるように道を示してあげることが大切です。

考えること	内容	補足説明
誰が	担当者・関わる人	誰がボールを持つのか誰に相談すれば良いのか
いつまでに	締め日	いつまでにやらないといけないのかいつまでにないと対応が進められないのか
何のために	課題・目的	どういう問題が発生しているのかゴールはどういう状態か
どのように	提案	例えばどういう方法なら解決できるのかメリデメは何なのか

個人的には最低限このあたりはコミュニケーションをする上で必要な情報だと思いますし、伝えるべきだと思っています。
この情報が伝えられていれば、相談された側は提案に対してのフィードバックや最適な方法を提示するだけで済むので、余計なやりとりもやらなくて済みますし外側から見ても丁寧なコミュニケーションだなと感じます。
この内容は普段ミーティングを行う際にも言えることだと思うので、意識してみると良いかもしれません。

フィードバック

目標に対して定期的に振り返りを行う機会があるかと思いますが、その時に必ず「Good」ポイントと「More」ポイントを伝えるようにしています。

Good
- スポットを当てると関係していますが、ちょっとした細かいコミュニケーションの配慮だったり少しでも良いポイントがあれば伝える
- モチベーションになる
- 自分の武器・強みになる
More
- 悪いことはちゃんと伝えないと成長に繋がらない
- ちゃんとプラス方向になるように伝える
- 失敗や悪い言動に対して、マイナス影響を考えられるようにする（自走の道標、思いやり）
- 人格を否定するような言い方にはしない

一度や二度の失敗は、どれだけベテランの人でも人間である以上誰でもあります。
なので、そこからちゃんと対策を考えてV字成長できるようにフィードバックしましょう。
指摘されたことをどう活かすかは本人の意識次第ですが、前に言われた失敗を繰り返すことなくどんどん成長している！と感じたらスポットを当てて褒めるフィードバックをすることも大切です。

実践している内容

価値観ブレスト

皆さんは「チームラーニング」というのはご存知でしょうか？

働く時間帯や環境、自分の不得手などを共有することで、チームで働きやすい状態を作ろうという取り組みのことです。
つまり、価値観を共有し合おうということですね！
ゴールを決める段階で、ある程度方向性は決められると思いますが、お互いの価値観を知っているか知っていないかでは普段の接し方やフィードバックの仕方などだいぶ変わってきます。
なので僕はトレーナーやメンターを担当した際に、価値観ブレストを実施するようにしています。
価値観ブレストというのは造語ですが、

他の人の考え方を否定しない
他の人の話に耳を傾けること
他の人と同じ意見でも構わない
実現方法は考えない
自分が心から実現したい価値観について話すこと

という方針のもと、以下のような内容でトレーナー・トレーニー同士出し合っています。

これにより、トレーナーはトレーニーの価値観を把握でき、トレーニーも先輩社員の意識をインプットして目線を上げることができます。

スキルマップ

スキルマップというのは、能力やスキルを、担当者・機能ごとに可視化した評価のことです。
もともと管理職や評価者が用いるものではありますが、エンジニアチームで取り入れたところ属人化している機能を洗い出すことができたり、窓口やコードのレビュワーに迷った場合にとりあえずリーダーに投げるということをせず一目で誰に頼ればいいのか分かるようになりました。

CEDEC2022のこちらの講演内容を参考に取り組んでいるものになります。

属人化を解決！スキルマップとモブワークを活用した安定したプロジェクト運営

僕の所属しているチームでは、５段階評価+チャレンジャー制度という形式でスキルマップをつけています。
５段階評価は、経験をもとに各自でつけてもらうようにしています。

判定	基準	詳細
★	◎でかつ設計者	他プロジェクトでも同様の機能を実装できる
◎	人に説明・教育でき、実装できる	◯以下の人や新人に説明できる担当者のフォローや他セクションとの連携ができる改修の設計ができる
○	自走して実装できる	フォローなしで改修や不具合修正ができる他セクションとの連携ができる少しなら質問が来た時に答えられる
△	フォローありで実装できる	簡単な不具合修正ができる教えてもらいながら設計や改修ができるキャッチアップに時間を要す場合はここ
-	触ったことがない	今まで一切触れたことがない機能

チャンレジャー制度は、後続のバージョンで開発する内容は積極的に○以下の人をアサインして、◎以上の人がサポートするフローです。
毎バージョンごとに更新とチャレンジャー決めを行うサイクルをすることで、属人化がどんどん減っていき、個人としても対応できる領域が増え一石二鳥になっています。
また、「引き継ぎ対象」というものを入れていますが、これは仮に一部のメンバーが異動や退職となった場合に、抜けた時の状況を可視化できるようにした機能です。上で添付した画像ではCさんの異動が決まった時を例として設定しています。

モブプロ/モブワーク

所属しているチームでは、毎週1時間ずつ使ってモブプロを行っています。
モブプロを行う目的として、

生産性の向上
進め方・技術など暗黙知の共有
属人化防止

があります。
初めはコーディングオンリーで実践していましたが、プログラミング以外の面（こういう場合は先にプランナーに確認した方がいいよねだったり、アセットの組み込みに関する内容だったり）も増えてきたのでモブワークになりつつあります。
モブワークはモブプロとほぼ形態は変わらず、プログラミングに限らず仕事全般が対象というイメージです。

流れとしては、まずモブ・タイピスト・アドバイザーの３種類に分かれます。

モブ：タイピスト、アドバイザー以外の全員。議論や指示を出す人。主に若手が担当。
タイピスト：モブの指示を受けて手を動かす人。指示されたこと以外は行ってはいけない。分からない場合のみ質問OK
アドバイザー：モブが指示した内容に補足だったりより良い方法があれば全体にアドバイスする人。主にキーマンが担当。

アドバイザーを設けた理由は、ベテランエンジニアやキーマンが指示しすぎてしまった場合その人のやり方に偏ってしまうため、なるべく若手が主体となって発言し議論を進めてほしいという目的がありました。
数ヶ月実施した今でも、普段当たり前のように使っている汎用コンポーネントが以外と知られてなかったことに気付けたりプラスの点が多かったので良い取り組みとなっています。

最後に

最初にも言いましたがマネジメントや育成に正解はありません。
これから管理職やトレーナーとなる方の助けに少しでもなれたら良いなと思っています。
ここまで読んでくださり、ありがとうございました！

明日は @kida_hironari さんの記事です。

エンジニアチームのボトムアップを目指す育成ノウハウを紹介！