こんにちは、エンジニアマネージャーやってます堀越( @tkt_horikoshi )です。本投稿はFLINTERSアドベントカレンダーの5日目の記事となります。
先日、社内のオフライン勉強会がありましてチーム内での教育の取り組みや、部署を跨いだ支援の仕組みについて発表したのですがせっかくならブログにもということで執筆に至りました。
はじめに
エンジニアマネージャーになったことでチームビルディングや組織開発の側面に関心を持つようになったので、直近でトライしている取り組みをシェアできればと考えています。
尚、本投稿で紹介する取り組みはチーム内で出た提案や他部署での取り組みを真似たりしているものでまだまだ道半ばです。
同じくチームビルディングや組織開発に関心を持たれている方、情報交換などできればと思っているので是非コメントなどお寄せください。
後進の育成支援
関心を持ったきっかけ
古くからの友人、Hさんの開発チームのお話を聞いたことがきっかけでした。
Hさんの開発チーム状態遷移
Hさんのチームは組織都合によるチーム移動や、チームメンバの退職といった影響を受けて以下のように状態遷移していったとのことです。ちなみにこういうの弊社でもよくある気がしています。
突然ふってきた厄災
前段の話、特に赤丸の部分は予測が立てづらく残されたメンバーからすると厄災のようなもので辛みが多いなと感じています。
特に唯一残された古株メンバは所属期間が長くドメイン知識、チーム内の技術スタックにも精通しているためあらゆるタスクが集中する傾向にあります。また、ここでいう古株メンバは大抵はリーダーやマネージャーを担っている可能性が高く、開発以外のセカンダリなタスクもガツガツ入って来ます。他のメンバの協力をあおいで負荷を分散をする必要があります。
また、上記の状態は明らかに単一障害点なので急ぎ古株メンバが抜けてもプロジェクトを回せる状態を目指す必要があります。
育成支援の必要性を実感
人手不足解消の手段は、採用活動、他チームからのメンバ移動要請、などなどありますが経験上そう都合良く良い人が来る可能性は低いですし、結局のところ新メンバにはオンボーディングや何かしらの支援が必要になります。
上記をふまえ、まずは既存のメンバを対象に何かしら育成を支援する仕組みを作る必要があると考えたわけです。
目指したい状態
チームの出力について考えると、シニアのメンバで固めたチームとサポートが必要なジュニアのメンバを含むチームとでは当然ながら異なってきます。
シニアメンバで固めたチームは個人の出力がダイレクトに反映されるのに対し、サポートが必要なジュニアのメンバがチームに所属していた場合は対象のメンバが十分な出力を出すのにサポートのコストがかかるため出力が下がります。
ここではサポートにコストがかかることが悪いという主張をしたいのではなく、むしろ組織の成長のためには絶対に必要なものなので雰囲気でやらずに仕組み化するなどしてチームメンバの成長を高速化したいというのがモチベーションです。
そのため、サポートのクオリティを高めて理想状態までのスパンを最短にするというのが後進の育成支援の目標になると考えています。
後進の育成支援 - 取り組み紹介
スキルロードマップ
近隣チームでの取組みを真似したものですがお気に入りです。
以下のようにチームにて求められるスタックを行項目とし、優先度*1、チーム内で求められるレベル感などを表で表現したもので、定期的に振り返りを行ってキャッチアップの状況を入力します。
振り返りの際には以下のようなテンプレートで議事録を残しています。
スキルロードマップは以下のような点がGood!!だと感じています。
- いま必要なスタックが明確になる（実はそこを補えば出力が30 → 60になったりする）
- スキルアップのためのHowをみんなで考え実践できる
- 定期でフィードバックサイクルを回し成長実感が得られる
QA Time
こちらはシンプルに毎日固定で15分対面でのQAの時間を確保するというものです。リモートワークが主となっている現在はビデオチャットで行っています。
以下のような点がGood!!だと感じています。
- Slackへの質問書き起こし負荷軽減（何がわからんのかわからん時あるもんね）
- そのままスルッとペアプロに入れる
- 雑談をしてリフレッシュ
育成者を探す
後進の育成は一人でやる必要はありません。後輩の面倒見の良い人を見つけ、担当してもらうということは目的達成のスピードを更に加速させます。幸いにも私のチームには適任者が所属していたこともあって非常に良い成果が出ているなと感じています。
以下のような点がGood!!だと感じています。
- 育成支援などもチームで行う方が後進にとっては刺激になる
- 教育にかかる負荷を分散できる
- 育成者にとっては新しいキャリアになる
その一方で適任者を探すというのは実際には難しいと感じています。
というのも 技術力が高い ≠ 教えるのが上手い というのがあるので教育担当者は教えるのが上手い人が担当し、技術に長けた人はメインタスクは開発タスクとしつつを教育担当者がカバーしきれな技術領域をサポートしてもらうというような構成にするのがベターだと考えています。
当たり前のように聞こえますが実際にはなんとなくチームの中で技術に長けた人が教育を任されるというような状況は少なくないように感じています。
また、後進の育成や教育などはボランティアになりがちなのでしっかりと評価できるよう成果を吸い上げて評価軸に組み込むといった動きが上長には必要だと考えています。
部署間連携
1チームに閉じてしまっているリスク
一番詳しい人が限界値
そのチームの中で一番詳しい人*2が限界値だという話があります。これもある意味では単一障害点でその人が知らないことは他のチームメンバも知らない可能性が高いです。
また、チーム内の技術的知見は普段の業務に依存するところがあるためチームで扱う技術以外の知見は積極的に育ちません。
上記の状態をふまえると、何かわからないことがあっても近くの人に聞いて解決できる状態のほうが安心感あるし組織としては強いだろう、と考えているわけです。
部署間連携 - 取り組み紹介
【検討中】チームスキルマップ開示
こちらはまだ企画の段階でまだ導入までは進んでいません。
他部署のエンジニアマネージャーとチーム間で援護射撃し合える仕組みを作りたいよねという話をしました。これに対し、まずはお互いを知るところからというのでチームスキルマップをお互いに開示するのはどうかという話が出ました。
チームスキルマップとは下記のようにチームで扱うスタックに対してチームメンバの誰がどのレベルで精通しているかというのを表形式で表したものです。以下は弊社とあるチームのチームスキルマップです。
チームスキルマップ自体には
- チームの弱み強みを把握できる
- 個人の関心領域も明確化して戦略的なタスクの割り振りができる
といったGood!!なポイントがあり、これを開示することで
- 他部署へ開示することで他チームの特性を把握でき、部署間を跨いだ支援のきっかけになる
という仮説を立てています。
ただし、個人名が入ったチームスキルマップはセンシティブな情報なので開示するのはデリカシーに欠けるのではないか、チーム毎のバス係数*3だけ開示するのはどうかといった議論をしていて大筋この方針に倒れそうです。
その他...（まあ、よくある取り組みっすね）
その他、部署を跨いで交流があるのはまあ、他社さんでもよく取り組まれているようなコンテンツになってしまうなあ。
- 読書会
- 最近参加したのは、「ミノ駆動本」と「RDRA 2.0」
- 勉強会
- アドベントカレンダー
- オフライン勉強会も実施傾向にある
まとめ
- 後進の育成支援
- スキルロードマップ
- QA Tme
- 育成者を探す
- 部署間連携
- 【検討中】スキルマップ開示
- 他社でもよくあるような取り組み
- 読書会、勉強会、アドベントカレンダー、オフライン勉強会
終わりに
是非、みなさんのお話も聞かせてください。
明日はGANMAチーム orehahtiya さんの fluxcd の導入に関する記事です。お楽しみに。
*1:早くできるようになって欲しい項目ほど高い
*2:リーダーとかマネージャーとか
*3:https://ssaits.jp/promapedia/glossary/bus-coefficient.html
