Findyのエンジニア爆速成長の事例 2024年夏

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンド リードをしている @shoota です。

先日、END【フルスタックエンジニアへの道!】React と TypeScript の修行をした話 というタイトルで、フルスタックエンジニアを目指すためのフロントエンドの修行の記事を投稿いたしました。 こちらの記事では React / TypeScript において個人学習程度のレベルにあった END が、機能開発を自走可能になるまでの内容が書かれています。

そこで本記事では、END の成長と挑戦をサポートし、実際に指導にあたった私がメンター視点での話をいたします。

育成のはじまり

Findy Team+の開発メンバーはバックエンド・フロントエンドにそれぞれ主軸を置きつつ、多くのメンバーがその垣根を超えた貢献ができることを目指しています。 そのなかでバックエンドを主軸としていた END がフロントエンド領域に集中して挑戦したいという話が持ち上がりました。

フロントエンドメンバーの比率が少なく、「片手間ではなく集中して挑戦する」という決意もあり、自分としても前向きに指導担当をさせてもらいました。

下準備

ゴール設定

急に育成をするとなっても何となく始めてしまうとちゃんと成長できているのか、育成をサポートできているのかどうかがわからなくなります。 まずはじめに私がしたのは、エンジニアリングマネージャー(EM) とのすり合わせでした。

具体的には次のような質問から「どのくらいの時間でどこまでできるようになるのか?」をある程度の幅で決めていきました。

  • メンティーが目指すゴールはどのレベルか?
  • EM の期待するゴールはどのレベルか?
  • どれくらいの育成期間をとるか?

ゴールのレベルもざっくりと 3 段階を想定しました。

  1. 基本はバックエンドを主軸としつつも、状況にあわせてフロントエンドも書けるようになりたい
  2. バックエンド・フロントエンドに分け隔てなく両輪で活動できるようになりたい
  3. フロントエンド主軸に移りたい

結果 2 番目のレベルをイメージしながら、「フルスタックな動きをキャリアの目標として想定しつつ、まずはフロントエンドを自走できるレベル」「とりあえず 3 ヶ月」で目指してみようとなりました。

助走をしてもらう

もともと個人で React は書いたことがあるといっても、Team+の膨大なコードの前に立つとなかなかどこから手を付けたらよいかと不安になるものです。 なのでまずはメンティーの心の準備体操として、フロントエンドの考え方をまとめた読み物を書きました。

読み物

MVC アーキテクチャやオブジェクト指向といった馴染みの概念と照らしながら、どんなパラダイム・シフトが待っているのかをブログのように書いておきました。 このほか、これまでにもフロントエンドの設計や React の思想などに関する社内記事を書いていたので、それらも合わせて共有しておきました。

実践

育成の方針と実践

自分で調べたり考えたりしたことがいちばん身につくので、基本的には寄り添い過ぎず、私のなかでいくつかのゲートを設けて見守ることを計画しました。

私はこれまでもジュニア層のフロントエンドエンジニアの育成経験があったので、これらのゲートが多くの人がぶつかる壁であることを知っており、これをクリアできてそうかをみながらサポートの強弱をつけていく算段です。

成長ステップ

  1. React に Props を渡して単純な HTML を出力するコンポーネントを書ける
  2. コンポーネントを組み合わせた大きなコンポーネントを型を含めて書ける
  3. ユーザーインタラクションのハンドラーを純粋な関数として書ける
  4. バックエンド API との通信インターフェースを理解し、コード生成ができる
  5. データとコンポーネント間を TypeScript をつかって型安全かつ整合してつなぐことができる

多くの場合に Step. 3 と Step. 5 がよく詰まるポイントで、ここを乗り切るための知識や理解のための伏線を張っていくように、ドキュメントなどをプルリクエストや Slack でどんどん渡していきました。 特に Step. 5 がジュニア層の鬼門で、それまでの React Component の積み上げと API の型定義を同時に整理しなければならないため、データとビジュアルの責務分離、そのための関数と型の設計などで苦戦します。

渡した資料の中で、誤読しやすいものや前提知識が多く必要なものは口頭で補足するなどしながら、これまでの理解度を測って次のステップに必要なものを選んでいくようにしました。 こうして Step. 5 を乗り越えるための理解が積み上がるように進路補正をしていきました。

トレードオフ

このように挑戦するメンティー側にはいろいろな壁を超えるための頑張りが必要になってきますが、一方でサポートするメンター側も、自分のパフォーマンスを維持し続けるのが難しくなってきます。 どれくらいの厚みのサポートが必要かは個々人によって違いますが、少なくともメンターの 20%くらいはサポートに力を注ぎたいものです。

Findy では Findy Team+ を使って自分のパフォーマンスを計測する習慣がありますが、私は育成に際してこの数値がある程度は落ち込むことを覚悟の上で、その落ち込み幅をできるだけ小さくすることにも挑戦していました。

私のマネージャーにもこの想定の落ち込み幅のすり合わせをし、育成と自己パフォーマンスのバランスをとっていることを 1on1 などで話しています。

パフォーマンスを可視化することで数値の変動にきちんと理由付けをできるのが Findy Team+ を使っていく最大の利点です。

3 ヶ月の成果と分析

プルリクエストの可視化

実際には想定よりも成長速度が安定していたので最初の 2 ヶ月弱で設定したゴールに到達しそうでしたが、とりあえずはそのまま 3 ヶ月間みっちりと進めてみました。

難易度が高すぎないタスクを中心に実施してもらってはいたものの、最終的にフロントエンドへのプルリクエスト数は私とほぼ同等かそれ以上が出せるようになっていました。

Team+のグラフで可視化してみると次のようになりました。

青が私、オレンジがEND

メンティーの分析

先ほどのメンター(私)とメンティー(END)の両方の PR 作成数でした。これをメンティー(END)だけに絞ると、中盤に数値の谷があります。 実はこれが狙い通りで、前述の想定した Step と期間を照らし合わせることで成長の過程が見えてくるようになります。

育成方針とパフォーマンスの谷

はじめは単純な HTML 合成のための Component 作成(Step. 1, 2)で伸びていく数値が、ユーザーインタラクションの実装 (Step. 3) が始まると徐々に鈍化していきます。

インタラクションの実装に慣れてくるとバックエンド API との連動 (Step. 4) のイメージもつきやすきなってきますが、いざこれらをつなごうとすると考慮することが一気に増えるため、数値が下がっています。 そしてこの鬼門を乗り越えると、またぐんぐんと順調に伸びていく事がわかります。

メンターの分析

次に自分がメンターをしている期間にどれくらいのパフォーマンス影響があったかを見てみます。 同じ期間での私の PR 作成数をグラフにすると、何ともつまらないくらいに変化が少ないグラフになりました。

メンターのPR作成数

しかしこれには秘密があります。

まずメンターを始めてからメンティーのプルリクエストはすべてレビューしており、すぐに自分のパフォーマンスに対する影響を感じていました。 具体的には次のようなことを、プルリクエストがあがるごとに都度実施していたためです。

  • 設計意図を汲み取りにくい構造になっている部分を読み解く
  • 厳密でない型定義によって型チェックをすり抜けている箇所がないかチェックする
  • 指摘内容とともに実装サンプルを書いたり、その理由を示すリファレンスを探して提示する。

そこでマネージャーと相談して、自身のプルリクエスト作成数が 4 以下にならないように水準を維持していくことを宣言し、レビューの濃度を調整していったのです。 (それまでの私の平均プルリクエスト作成数は 5.6〜5.8 程度でした)

「そこまで狙い通りにプルリクエスト数を調整できるものか?」と思われるかもしれません。

しかし自分のパフォーマンスを落としては開発が進まず、また一方でメンバーの成長にも投資しなければ全体の生産性が高まりません。この実績と投資のバランスを自分の数値を軸にすることで全体最適を図っていったのです。

もっと自分がプルリクエストを書ける状況でもその分は育成への投資に使いました。こうしてマネージャーと合意したパフォーマンスを維持しながら、最大限の育成を進めるのは意外と難しくありません。

所感とまとめ

今回の育成期間の全体を通して、おおむね計画どおりに進めることができました。もちろんメンティーのポテンシャルの高さやメンターの経験もあってのことですが、次のような点が成功への道しるべになったと思います。

  • メンティーのゴール設定を 技術リードとエンジニアリングマネージャーの両者 で合意してから開始したこと
  • 適切なステップとぶつかる壁を用意したこと
    • 成長のための「適度なストレス」を感じ続けられるようにすることで、モチベーションを維持
    • 最も大きな谷を超えるための準備としてサポートを意識した
  • メンターのパフォーマンスへの影響とその保証ラインも適切に設定し、そのパフォーマンスラインを指標として サポートの厚みを可変できるようにしたこと

これらによって、開始時に設定したゴールを超えて爆速で成長してもらえました。

卒業の様子

最後に、「メンティーの分析」であげた END のプルリクエスト作成数グラフをもう一度みてみると、非常にゆるやかなダニングクルーガー曲線になっており、非常に興味深いなと思いました。

成長したいエンジニアを探しています!!

バックエンド主軸のあなたでもフロントエンド開発を自走できるレベルまで成長することが出来ます。

もちろんフロントエンドが大好きなあなたも、リードエンジニアを目指してスキルアップできることでしょう!

ぜひ、ご応募お待ちしております (∩´∀ `)∩

herp.careers