この記事はClassi developers Advent Calendar 2022の1日目の記事です。
こんにちは!開発本部で本部長をしているid:tetsuro-itoです!今年もこの季節がやってきましたね。僭越ながら昨年に引き続きトップバッターを努めます。
昨年の記事では、本部長に就任したあとで取り組んだ最初の内容をお伝えいたしました。今年もその路線を踏襲して、今年取り組んだ施策の内容や現時点での結果などをお伝えいたします。最後までお付き合いいただけると嬉しいです。
開発本部の抱えていた課題
開発本部はプロダクト開発部、開発支援部、データAI部の3つの部署によって形成されていますが、全体の7割ほどのメンバーがプロダクト開発部に所属し、残りを他の2つの部署のメンバーが構成するという歪な偏りがありました。加えて、当時のプロダクト開発部の部長が大半のエンジニアのレポートラインの上長として位置付けられており、部長1人が評価する人数が多く、大変でした。 さらに、上長の管掌範囲が広く、日々の仕事を評価しにくいために、所属しているチームのPdMがそれぞれのエンジニアの働きぶりの申し送りを行っていました。日々の働きぶりの観点の申し送りでは問題がありませんが、別の職能を持ったメンバーが申し送りを行うため、評価の観点では必ずしも機能していたとは言い難い状態になっていました。
また、Classiでは組織のパルスサーベイ1として、Wevoxというツールを導入しており、定期的に組織の状態を定量的にモニタリングし、施策を打っていく取り組みを行っています。そのパルスサーベイのスコアもあまり良い状態ではありませんでした。開発本部は月に一度、本部メンバー全員が集まって情報共有を行う「開発本部全体会」を行っています。そこで全員でWevoxのスコアを見て、何を改善していけばよいかのワークを行ったりもしました。
その結果、多くのメンバーが指摘したのが、「自己成長」という項目のスコアが低いということでした。これはエンジニアリング領域における能力開発、キャリア開発などを責務としている開発本部では、由々しき問題であると考え、すぐに対応策を検討しました。
まずはじめに取り組んだこと
まず一番はじめに取り組んだことは、現状の組織構造のas-isをきちんと把握するために可視化です。すると、前述した組織上の課題が非常に複雑な形となって姿を現しました。
上記のように、レポートラインが偏った構成になっていたり、入れ子の構造となっていたりと複雑な様子が明らかになりました。そこで、まずは組織の構造に階層を取り入れて、その役割を付与することにしました。
まず、本部長および部長、副部長をエンジニアリングマネージャーとして括りました。また、この集合をEM Boardと称して、開発本部における問題解決や組織運営に責務を持つような役割を定義しました。
また、部長とメンバーの間にユニットリーダーという役割を新たに定義し、それぞれのユニットを束ねてもらう役割を作りました。エンジニアのユニットという概念も定義し、下記のような定義を行いました。
- 1ユニットあたりの最大の人数は5人まで
- ユニット内の役割はユニットリーダーとユニットメンバーのみ
- ユニットリーダーは評価時に申し送りを行う
- ユニットリーダーは評価者ではない
- ユニットのメンバーとプロジェクトのメンバーが一致しないこともある
このような構造を取り入れ、開発本部メンバーのレポートラインを整理した結果が下記です。
このようにこれまでの偏った構造を是正し、ある程度適正なマネジメントサイズを意識してレポートラインを再構築しました。また、レポートラインにエンジニア以外の職能のメンバーが入ることをやめました。これにより、評価の納得性や不透明性も改善しようと試みました。
新設したユニットリーダーへのお願いや対応
これまでリーダーではなかったメンバーが突然リーダーに任命されても、すぐにはうまく立ち振る舞うことは難しいだろうと考えていました。そのため、ユニットリーダーへの依頼事項を非常にシンプルにし、下記の2つの事項をお願いすることにしました。
- ユニットメンバーとの1on1を月に1回以上行う
- ユニットメンバーの目標設定の相談に乗り、評価時には申し送りを書く
仮説を持って制度を検討したものの、検証できていない段階であったため、まずは今年の上期の半年間を利用して検証することにしました。 当然、ユニットリーダーからは不安や戸惑いの声もあがりました。そうした場合にEMとの1on1の中で相談してもらったり、ユニットリーダー間での相談などを推奨するなどの対応をしてきました。
また、1on1をする上で、コーチングの概念をインプットしてもらうべく、人事系の顧問の方に研修を行なっていただきました。1ヶ月程度の期間で全3回の講義やトレーニングを実施していただきました。全体のゴール設計や各回の位置付けは下記の通りです。
- 全体ゴール
- Visionに向かうための強固なエンジニアリングチーム
- 個人の成長を促進できる組織の実現
- EM・ULのスキルアップによって
- 成長促進可能な組織構造によって
- コーチングの効用や機能しないケースの理解
- 初回の内容
- コーチング、1on1とは何かが説明できる
- 場の設定ができる
- 信頼感をもっていただく振る舞いができる
- 傾聴とはどういうことか?を体得する
- 2回目の内容
- 傾聴を体得する
- さまざまな質問を使うことができる
- 3回目の内容
- 自分の成長ポイントを発見する
- 成長実感がもてるアプローチができる
研修実施後にユニットリーダーが各々でメンバーたちとの1on1を実践し、1〜2ヶ月後にフォローアップの研修を入れることで、インプットと実践のバランスを意識したトレーニングを実施しました。
ユニット制度の効果検証
このように新たな制度設計、役割を付与し、トレーニングも課しながら半年間の実践を行いました。この制度の効果検証として、ユニットリーダー、ユニットメンバーそれぞれにアンケートを実施し、制度の改善や効果の検証を行いました。詳細は割愛しますが、調査項目としては下記のような内容を設計しています。
ユニットリーダー向けの調査項目
- メンバーとの1on1の実施頻度
- 自分の振る舞いの点数
- 理由
- どんな話題を話したか
- EMとの1on1の頻度
- EMとの1on1の満足度
- どんな話題を話したか
- 制度の改善点
ユニットメンバー向けの調査項目
- リーダーとの1on1の実施頻度
- 1on1の満足度
- 理由
- どんな話題を話したか
- 制度の改善点
すべての結果を紹介することは難しいので、いくつかを抜粋して紹介します。 まずは1on1の実施の頻度についての結果です。
オーダーでは月に1回以上の1on1をお願いしていましたが、実態としてそのオーダー通りの実施は3割程度で、それよりも多い週に1度や隔週に1度の頻度で開催している実態が明らかになりました。
また、ユニットリーダーが自身の振る舞いについてつけたスコアはかなりのばらつきがあり、試行錯誤していた形跡が見て取れます。
ユニットリーダーは悩みながら試行錯誤していたのですが、それを受けていたメンバーの1on1への満足度の分布は下記の通りでした。
当初、私たちが想定していたものよりも平均的に大きな満足度のスコアとなっていました。これは非常に良い結果でもあると考え、引き続きこの路線を踏襲することにしました。この調査だけでなく、当初見ていた組織のパルスサーベイでも改善傾向が出ており、今回の施策の効果はいずれのメトリクスでも検証ができた状態になりました。
おわりに
制度を始めてみて、最初の振り返りとしてはまずまずの成果が出たと認識しています。しかし、まだまだ始まったばかりです。制度の設計や運用に課題がないわけではありません。今回さまざまな改善点や意見もあがってきました。そうした改善点も組み込んでいき、よりよい制度の運用を目指して、引き続き組織の取り組みを推進していきたいと思っています。
明日はid:aereal さんの投稿です。楽しみです!
- パルスサーベイ(Pulse Survey)は、会社が社員の満足度や心の健康度を把握するための調査です↩