こんにちは、GA technologiesでソフトウェアエンジニアをしている周です。
現在は新卒3年目のエンジニアとして開発に携わっています。
普段は新機能の実装や課題解決に向けて手を動かすことが多く、育成のような立場とはあまり縁がありませんでした。
プロジェクトリーダーとして進捗管理をすることはあっても、「誰かを育てる役割」を明確に求められることはありませんでした。
そんな自分が、半年前にはじめて新卒メンバーのメンターを任されました。
正式に「この人のメンターです」と宣言され、日々のタスクの進め方からメンタル面のフォローまで、一人のメンバーに継続的に伴走する立場になりました。
日々の開発やレビューはこれまで通り続けながら、その横で1on1をしたり、タスクの進め方やメンタル面を見たりする、通常業務とメンター業を並走させるイメージで関わっていました。
半年間の伴走を経て、メンティーは「ほぼ一人でプロジェクトを任せられる」とチームリーダーから評価されるまで成長しました。
ここでは、その半年間で自分の視点がどう変わったのかをまとめていきます。
この記事で想定している読者
この記事は、次のようなエンジニアを想定して書いています。
自分もまさにこのタイプで、何の準備もない状態からいきなりメンターを担当することになりました。
この記事では、そんな自分が現場で試行錯誤する中で、
- 相手が内容を理解しやすく、内省を促しやすいフィードバックだったか
- 相手のフェーズに合った伝え方だったか
この2つの視点を、具体的なエピソードで紹介します。
視点の変化
相手が内容を理解しやすく、内省を促しやすいフィードバックだったか
メンターをやっていると、「これはうまくいかなかったね」という出来事はどうしても出てきます。
最初のうちは、自分もつい
- 「ここが良くなかったね」
- 「次からは気をつけよう」
のように、フィードバックだけをそのまま口にしてしまうことが多くありました。
ただ、これだと「なんとなく注意された」という印象だけが残りやすく、次にどうつなげるかが見えにくいな、という違和感もありました。
そこで途中から、フィードバックの仕方をガラッと変えることにしました。
意識したのは、「フィードバックする前に、まず事実を一緒に確認する」ということです。
例えば、プロジェクトMTGがうまく回らなかったときは、こんな感じで話しました。
- 昨日の14時のプロジェクトMTGで
- アジェンダと実際の議論の内容がズレたまま進行してしまって
- 結果として30分経っても結論が出なかった
先に「何が起きていたか」を一緒に並べてから、「じゃあ次どうするか」を考えます。
- 最初にMTGのゴールを共有してから話し始めてみる
- 10分ごとに一旦ゴールとズレていないか確認してみる
といった具合に、次の手を一緒に出していくイメージです。
エンジニアの仕事に寄せて言うと、
「なんとなく調子悪いから直して」ではなく、「この操作をするとこういうログが出て、この挙動になっている」
というところまで状況を揃えてから対処する、という感覚に近いです。
こういうやり方を続けるうちに、
- 相手が状況を頭の中で再現しやすいか
- 自分で「次はこうしてみようかな」と考えやすいか
といった点を、フィードバックのたびに自然と気にするようになりました。
この「事実→行動→影響」を順番に整理する考え方は、いわゆるSBI型のフィードバックです。
詳しく知りたい方は、以下の記事を読んでみてください。
相手のフェーズに合った伝え方だったか
もう一つ、メンターとして関わる中で強く感じたのは、相手の成長段階に合わせて伝え方を変えることの大切さです。
印象に残っているのが、タスク漏れが何度か続いたときのことです。
そのとき自分は、
- 「タスクはGitHubのissueに起票するといいよ」
- 「Slackはあとで読むに入れておくと漏れにくいよ」
といったアドバイスをしていました。
自分の感覚としては「おすすめしているつもり」でしたが、メンティーからすると「やってもやらなくてもいいTips」に聞こえていたようで、タスク漏れは何度も起きました。
ここで「ちゃんと伝えたはずなのに」と相手側に原因を置いてしまうのは簡単です。
ただ、落ち着いて振り返ってみると、
- メンティーはまだ業務に慣れておらず、そもそもタスク管理の型がない状態
- そこに「こうするといいよ」とだけ言っても、運用イメージが湧きづらい
というズレがありました。
そこで途中から方針を変えました。
- タスクは必ずGitHubのissueに起票する
- Slackでタスクに関する連絡があった場合は、ブックマークして後で確認できるようにする
「提案」ではなく今のフェーズでは必須のルールとして扱う形にしたイメージです。
しばらくこの運用を続けた結果、タスク漏れはほぼ発生しなくなりました。
この経験から、「伝えたかどうか」ではなく、
「今のこの人のフェーズに、この伝え方は合っていたか」
という観点で、自分側のコミュニケーションを振り返るようになりました。
こうした考え方はSL理論というものでした。
詳しく知りたい方は、以下のサイトを見てみてください。
自分がやってしまっていたのは、本来はS1のリーダーシップスタイルを取るべき場面だったのに、S3寄りの関わり方をしてしまっていたという点だと思います。
おわりに
半年間メンターをしてみて感じたのは、「育成」が、思っていたほど特別なスキルではなかったということです。
やっていることを分解してみると、どれも普段の開発でやっていることに近いです。
- 現状を観察して、事実ベースで状況を整理する
- 状態に応じてアプローチを切り替える
- 問題が起きたとき、個人ではなく仕組みから見直す
最初はメンターという役割に不安もありましたが、いつもエンジニアとしてやっている考え方をそのまま使えばいいんだ、と思えるようになってきました。
この記事で書いた2つの視点、
- 相手が内容を理解しやすく、内省を促しやすいフィードバックだったか
- 相手のフェーズに合った伝え方だったか
は、どれも「一度意識すると、そのあともずっと使い回せる考え方」だと思っています。
同じように、育成のやり方が分からず迷っている人にとって、少しでも役に立てばうれしいです。
株式会社GA technologiesの公式アカウントです。 「テクノロジー×イノベーションで、驚きと感動を生み続ける」というミッションのもと、不動産をはじめ、さまざまな産業のビジネス変革に取り組んでいます。
Discussion