こんにちは。
ファインディ で Tech Lead をやらせてもらってる戸田です。
弊社では沢山のエンジニアがJOINしてくれておりますが、2年ほど前から「成長が期待ができる」エンジニアの採用もするようになりました。
そのため、エンジニアの教育についても様々な取り組みを行っており、それらの取り組みを明文化してエンジニア教育メソッドとしてドキュメント化を行いました。
そこで今回は、ドキュメント化された弊社のエンジニア教育メソッドの一部を公開したいと思います。
それでは見ていきましょう！
教育メソッドの目的
まず教育メソッドを作成した目的について説明します。教育メソッドには次のように定義しました。
- 組織全体の「人数だけではない拡張性」を高める - 人数が倍になったら全体のアウトプット数が3倍になるような組織を目指す - チーム内だけで継続して育成することができるようになる
ありがたいことに直近数年の弊社のエンジニア採用は順調に進んでおり、フルタイムだけで50人を超える規模になりました。
しかし、増えた人数に対して組織全体のアウトプット数が思ったよりも伸び切らないという悩みも出てきました。
伸び悩んでいた背景に、急激に人数が増える中でエンジニア達に対するサポートが追いついていないということがありました。これまでにない成長をしてきた我々にとって新しい課題でした。
当時は開発組織全体を見ている自分が特定のチームに一時的に入ってサポートすることで対応していましたが、これでは人数が増えてもスケールしづらいという課題が出てきました。1人で見ることが出来る人数には限界があるからです。
そこで自分が直接サポートする必要がないように、各チーム内で継続して育成するための指標、教科書としての教育メソッドを作成することになりました。
教育メソッドの一部を紹介
目の前のことに集中
- 記載されている教育メソッドの中で、一番重要なのがこれ - 他のことに目移りしているエンジニアが伸び悩む - 伸びる理由は人それぞれだが、弊社の環境で伸び悩んでいたエンジニアの全員に共通していたのがこれ - 目の前の一つのことに集中するように促す - 一定の等級以上に上がるまでは、問い合わせ対応や障害調査からは外し、与えられたタスクに集中してもらう - やることが無いのであれば、やることを一緒に探して考える - コードを一緒に追っていけば、小さなリファクタやテスト追加など必ず何か見つかる - 一緒に探して考えることが重要 - 「やりたいこと」ではなく「やるべきこと」に集中してもらう
作成した教育メソッドの中での最重要項目となっています。
inputした内容以上のoutputは出ないと考えており、まずinputを優先してもらうためにも重要な内容と言えるでしょう。
新しい環境が目新しく映り、やりたいことが沢山出てきたり、色々なことに興味が出るのは当然のことです。しかし1つのことを集中してやり切ることが出来なければ、他のことを並行してやり切ることは難しいのです。
そのため一定以上の等級、レベル感に上がるまでは、とにかく目の前のタスクだけに集中してもらうように促しています。
やりたいことをやらせてあげたい気持ちはありますが、まずは目の前の「やるべきこと」に集中してもらうことが重要です。
色々なことを一度に叩き込むのではなく、段階を踏んで1個ずつ確実に覚えていく
#### 3段階に分けて確実に覚えていく - 基礎 - スキルマップを参照 - 手数 - 小さい修正内容でいいので、適切な粒度でPull requestを沢山作る - 量は質に転化する - 質と理解 - 正しいコードを理解して利用する - Pull requestでコメントを貰うことは問題ではない - 問題はコメントの内容 - セルフレビューで防げるようなことに対してのコメントは質が低い - 実装内容やパフォーマンスなど、本質に近いものに対するコメントを貰うことはOK #### クリアできるところ、つまずくべきところは分けて考える - セルフレビューで防げる指摘は、技術力や経験に関係なくクリアできるはず - テストや型定義、非同期処理やPromiseなど、難易度が高くて重要な要素はつまずいても問題ない - つまずくべきところでつまずいているかが重要 - 難易度が高いところでのつまずきが増えてきたということは成長している証拠 - 同じ失敗を繰り返さないことが重要
まず
- 基礎
- 手数
- 質と理解
の3段階に分け、段階を踏んで1個ずつ確実に覚えていくようにします。
基礎に関してはエンジニアの職種別にスキルマップを用意しており、自分に必要とされている項目をその都度覚えてもらいます。
手数に関しては、とにかく小さい修正でもいいので適切な粒度でPull requestを作り続け、大量のフィードバックを得るようにします。
量は質に転化すると言われているように、手数が増えれば増えるほど結果的に質と理解が深まっていき、最終的にはスピードが身に付きます。
また、指摘事項が多い場合はPull requestの粒度が大きすぎるケースが多く、そういったケースでは粒度を細かくしてPull requestを作り直してもらいます。一度に100個指摘されて100個覚えるよりも、1個指摘されて1個覚えることを100回繰り返すほうが覚えやすいからです。
この時、クリアできるところ、つまずくべきところは分けて考えています。
例えばlintやtypoでの指摘はセルフレビューである程度防げるはずであり、技術力や経験に関係なくクリアできるはずです。この指摘が多い場合は指導します。
逆にテストコードや型定義など難易度が一定以上高い要素に対する指摘を貰うことは問題ありません。次に同じような指摘をもらわなければ良いのです。
このように一度に全てのことを詰め込んで覚えてもらうのではなく、段階を追って覚えるべきタイミングで1個ずつ覚えてもらうことを重要視しています。
正しい方法を正しい手順で作業する
- 正しい方法と手順を徹底するよう促す - 既存コードを変更するならば、まずは該当するテストコードの存在を確認 - テストが漏れてるなら、まずはテストケースの追加を先に行う - etc - スピードは気にしない - まずは正しい方法と正しい手順を身に付ける。そこから手数を増やし、結果的にスピードが身に付く。 - スピードは後から勝手に付いてくるものであり、最初から求めるべきものではない
開発や業務を進めるうえで、スピードを求める前に正しい方法と手順を覚えることを優先します。
単純な例で言うと、既存実装を変更する際にはまず該当するテストコードの存在を確認し、テストが漏れている場合はテストケースの追加を先に行います。
正しい方法と手順に拘る理由は2点あります。
1つ目は本当の意味で理解するためです。正しい方法と手順には必ず理由と意味があり、それらを理解して作業を行うことで何故その作業が必要なのかを理解することに繋がります。
2つ目は結果的に最速になるのが正しい方法と手順だからです。一見遠回りに見える時もあるかもしれませんが、開発サイクルを回す上で結果的に一番速く効率的な方法と手順が身に付くようになります。
教育メソッドをより良いものにしていく
ドキュメント化された教育メソッドはGitHub上で管理されており、弊社エンジニアであれば誰でも閲覧して、変更提案のPull requestを作成することが出来るようにしました。
これは、今回作成した教育メソッドがver1.0という立ち位置であることを示しています。教育メソッドは会社のフェイズ、時代背景、開発組織の状態などに応じて変化し続けなければいけないものと考えているからです。
実際に教育メソッドを運用して気付いたことや、改善案やフィードバックがあれば積極的に提案してもらい、教育メソッドをより良いものにしていきたいと考えています。
まとめ
いかがでしたでしょうか？
今回は弊社のエンジニア教育メソッドの一部のみを公開しました。
実際に私がこの教育メソッドを適用して、とあるメンバーを3ヶ月程度サポートした結果、Findy Team+上の数値は次のように向上しました。
Pull request作成数の1日あたりの平均が4個だったのが2倍以上の9個に増加しました。彼は私のサポートが外れた現在も、引き続き高いアウトプットを出し続けることが出来ているそうです。個人差はありますが社内の他の事例でも一定の教育効果が出ており、今後の成長が楽しみです。
現在、ファインディでは一緒に働くメンバーを募集中です。
今は技術力や経験に自信は無いけど、弊社の環境で爆速成長したいエンジニアの皆さん。 是非一度カジュアル面談を受けてみませんか？
興味がある方はこちらから ↓ herp.careers
