開発組織のマネジメント：採用からオンボーディングで始まる一貫した生産性向上戦略

開発組織のマネジメント：採用からオンボーディングで始まる一貫した生産性向上戦略 1

1 自己紹介開発組織の課題と取り組み今後の戦略まとめ 2

自己紹介愛知県名古屋市出身 1989生まれ • ビジネスエンジニアリング株式会社 • タイムチケット • MUGENUP(システム部長) •
D2Cスタートアップ • hokan ◦ EM(2021~2025) ◦ 人事責任者(2023~2024) • matsuri technologies EMや開発責任者として開発部門のマネジメントを専門に、 • 採用 • 開発生産性向上をリード趣味：ボクシング SNS：@tonarinoharuki 前島治樹エンジニアリングマネージャー

　エレガントパズル 5 読みました？

　導入 6 2.4.1 エンジニアが増えるほど問題も増える生産性を高めるために、多くのエンジニアをまとめ上げるのは難しいものである。その難しさは、自走できるエンジニアをどれだけ早く育成できるかにより決まる。

　開発組織の課題と取り組み 7 ◦ 開発組織が抱える問題 ◦ 採用〜オンボーディングの仕組みとその効果 ◦ スキルマトリクスの作成と活用 ◦ 生産性指標の可視化と活用

開発組織が抱えやすい問題点 8 • POやテックリード、メンバーとのコミュニケーションにギャップがあり、意思疎通ができていない • それによる要件把握の理解が不足し、スプリント内に間に合わせないといけないというプレッシャー • そこから広がるシステム設計への影響
• 生産性の低下システム設計はコミュニケーション構造に従う

現状と理想プロジェクトマネジメントプロダクトマネジメントテクノロ
ジーマネジメントピープルマネジメントピープルマネジメントが最も薄い状態、スプリントや技術選定にも影響プロジェクトマネジメントプロダクトマネジメントテクノロジーマネジメントピープルマネジメント現状目指す姿 9

現状の問題と中期リスクの概要 2024年2Q   2024年3Q   採用/採用広報   人材教育・育成   開発生産性
  2024年4Q   ・短期的な解決策としてターゲット　組織全体の課題認識や共感性の欠如共感性や課題認識ができず短期で離職と離脱がハイレイヤーも発生開発組織の閉鎖性から母集団形成が困難・エンジニアとしての成長の見通し・負債解消の方向性がない・エンジニアとしての挑戦が見えない・コミュニケーション不足による工数圧迫エンゲージメント低下開発意欲が低下踏ん張れるエンジニアで頑張り続けて疲弊状態でパフォーマンス低下スキルとナレッジが定着せず開発組織が成長しないプロダクト品質の低下無理にリリースする状態 10

エンジニアリングマネージャーのミッション 11 社会的価値あるサービスを安定して提供し続ける市場価値が高いエンジニアリング組織の構築中長期開発生産性の向上プロダクト開発の負債改善コミュニケーションの効率化 1~3ヶ月で成果を出す
エンジニアマネジメント

ミッション達成のための課題 ◦ 採用〜オンボーディングの仕組みと効果検証 ◦ スキルマトリクスの作成と活用 ◦ 生産性指標の可視化と活用

生産性向上に向けたジャーニーマップ採用要件環境適応開発ONB チームONB スキル向上キャリア構築生産性向上成果：SP〇〇の開発
新しいキャリア入社前~入社3ヶ月入社3ヶ月以上退職後退職後コミュニケーション 13 ① ②

採用要件の見直し方バリュー基準環境適応性開発スキル Elite ・カルチャーマッチ・パーソナリティ自身で道を切り開く能力得意領域でスペシャリストとして活躍（社内役職、資格）・考えながら仕事をしている
・社会人スキル：エンプラの顧客コミュニケーション・出身企業：大手 SIer、ITコンサル経由、メガベンチャー・ドメイン知識：保険ドメインや特定業界理解、技術領域に関する知識。・技術的スキル：フルスタック、要件定義・要件を聞いた段階でイメージの中では実装が完了している High ・カルチャーマッチ・パーソナリティ　自身の置かれた状況で期待以上の成果を出す努力　キャリアや成功のイメージが明確・考えながら仕事をしている・社会人スキル：エンプラの顧客コミュニケーション・出身企業：大手 SIer、toBプロダクトベンチャー・ドメイン知識：保険ドメインや特定業界理解、技術領域に関する知識。・技術的スキル：フロント &バックエンド、インフラ・要件を聞いた段階で何を実装すれば良いか設計までイメージできている Middle ・カルチャーマッチ・パーソナリティ一つ一つ業務を着実にこなして目標達成に向けた自立性・社会人スキル： toBシステム開発・出身企業：地方・中堅 SIer、toB案件の受託、シリーズ A前後スタートアップドメイン知識：得意な技術領域に関する知識。技術的スキル：フロント、バックエンドどちらかで複数言語・要件を聞いて、なんとなく実装イメージがわいている 14

入社エンジニアのセグメント別ONB バリュー基準想定年収環境適応例：開発 ONB チーム ONB Elite 800万〜1200万
・環境適応への準備・会社理解・業界理解・開発理解各プロダクト機能のユースケース 1ヶ月後デモンストレーション 1ヶ月後の明確な目標設定 High 600万~800万・環境適応への準備・会社理解・業界理解・開発理解バグバッシュデイ : 新入社員が入社初期にバグバッシュデイに参加し、既存のバグを修正するペアプロ：メンターによる SPの1~3の開発を一緒に行う 1ヶ月での成果振り返り 2ヶ月後の明確な目標設定 Middle 500万~700万・環境適応への準備・会社理解・業界理解・開発理解・hokanで働く上でのスタンス浸透バグバッシュデイ : 新入社員が入社初期にバグバッシュデイに参加し、既存のバグを修正するペアプロ：メンターによる SPの1~3の開発を一緒に行うドキュメントの更新   デモンストレーション 3ヶ月後の明確な目標設定それぞれのセグメントの認識合わせ、 ONBへの投資対効果の把握 15

バリューとは何か 1. バリュー創出の期間 a. 推奨期間: エンジニアは入社後 1～3ヶ月以内に顕著なバリューを出すことが期待される。 i. プロダクトの理解、チームにおける役割の把握、 SP8のチケット
を対応できるようになるなど初期の成果の提供が含まれます。 2. 初期投資期間と投資内容 a. 投資期間: 最初の1~3ヶ月間は投資期間とし、以下に重点を置きます。 i. カルチャー: 企業文化の理解と適応。 ii. ドメイン知識: 保険ドメインや特定の技術領域に関する知識。 iii. 技術的スキル: 必要な技術スタックのトレーニング。 3. エンジニアの初期の成果創出において重要な要素 a. 一番大事なこと: オンボーディングプロセスの充実。 b. 新入社員向けの包括的なオンボーディングプログラムを提供 c. 教育とすり合わせ : 技術トレーニング、メンター制度、定期的なフィードバックセッション。 4. 平均勤続年数と投資回収期間 a. 平均勤続年数: 2年。 b. 投資回収期間: エンジニアが初期投資を回収し、事業に対してプラスの ROIを提供するまでの期間は通常 1年以内が目標 16

一人当たりの投資回収期間の例合計初期投資コスト:1200万合計収益：1300万投資回収期間：0.923年（約11ヶ月）初期投資コストの例 (一人当たり ) • 採用コスト: 250万(年間)
• オンボーディングコスト: 50万 • 給与と福利厚生: 8,000,000（年間）合計初期投資コスト: 250万 + 50万+ 800万 = 1200万エンジニアの生産性による収益増加（一人当たり）の計算（直接 ARRで見積もれないため間接的な要素として最終的には ARRに貢献する） • 新機能開発：年間800万 • 新機能がもたらす新規顧客の獲得や既存顧客の満足度向上。 • パフォーマンス改善：年間100万 • システムの効率化によるコスト削減や顧客のリテンション率向上。 • 技術的負債の解消：年間200万 • メンテナンスコストの削減やバグ修正による顧客満足度向上。 • プロセス改善：年間100万 • 開発サイクルの短縮と効率化によるリリース機能の増加。 17

グラフで表した場合 18 エンジニア生涯価値： 1エンジニアあたりの利益 ×勤続月数プレボーディングオンボーディング

早期バリュー創出のために行うこと • 早期のバリュー創出 :   a. 新しいエンジニアが最初の3ヶ月以内に小さなプロジェクトで成果を出す。  i. 会社理解と業界理解 
1. 入社前から的確なオンボーディングプログラムを提供し、カルチャー、歴史とドメイン知識の習得を支援。  b. 継続的な教育とサポート: メンター制度や1on1、定期的なトレーニングを通じて、新入社員が開発理解を早々にでき早期に高いパフォーマンスを発揮できるようにサポート。  20

オンボーディングにおける各領域の優先度   • 会社の戦略理解  a. ミッションとバリュー: 企業理念、長期的な目標、成長計画。   b. カルチャー：歴史、誰が誰とどういう関係値か、どういう人が評価されるか、会話スタン
ス  • ドメイン理解  a. 業界理解: 業界構造の全体像、規制、トレンド、競合他社。   b. 業務プロセス理解  c. プロダクト理解: 具体的な使い方、機能、設定方法、オプション。   • テクノロジー理解  a. 使用する技術スタックや開発ツールの勉強会   i. バックエンド、フロント、インフラに分解して個々に不安点がある技術領域  21

会社の理解がオンボーディングにおいて最も重要な理由 1. 企業文化への適応 • カルチャーや人間関係を理解することで、迅速に職場に適応しやすくなる。会社の価値観、期待される行動などを理解することで日常の業務やチーム内でのコラボレーションが円滑になる。 2. エンゲージメントの向上
• カルチャー、社会貢献、個人の willと会社の方向性の一致を理解することで、新入社員は自分の仕事が会社の成功にどのように貢献するかを理解できる。 • 目標設定や優先順位の付け方が明確になる。 3. コミュニケーションパスの円滑化 • 価値観や期待される行動、人間関係を理解することで、社内でのコミュニケーションが円滑になります。これにより、不安感や誤解、摩擦を減らし効率的な業務遂行を支援する。 22

hokan入社社員セグメントごとのオンボーディングとゴールセグメントオンボーディングゴール Elite ・プログラム: 会社理解、業界理解、開発理解との差分を軸に提供。・メンター制度: EMによる毎週1on1設定
・チームコミュニケーション：全体 1on1、ご飯・ドキュメント: 詳細なマニュアル、 FAQ、内部Wikiの提供。・学んだことをチームに対してプレゼン、理解度を確認・具体的なキャリアマップが描けている・1ヶ月で一つストーリー (SP5)を開発してリリース・2スプリント目でSP8~13の開発のリリース目処が立っている High ・プログラム: 会社理解、業界理解、開発理解との差分を軸に提供。・メンター制度: EMによる2ヶ月毎週1on1設定・チームコミュニケーション：全体 1on1、ペアプロ、ご飯・ドキュメント: 詳細なマニュアル、 FAQ、内部Wikiの提供。・学んだことをチームにプレゼン、理解度を確認・2ヶ月で一つストーリーを開発着手・バグバッシュデイ: 新入社員が入社初期にバグバッシュデイに参加し、既存のバグを修正・3ヶ月でSP5~8の開発のリリースメドが立っている Middle ・プログラム: 環境適応とプロダクトとの技術スタックとの差分を軸に提供。・メンター制度: EMによる3ヶ月毎週1on1設定・チームコミュニケーション：モブプロ、ペアプロ、ご飯・ドキュメント: 詳細なマニュアル、 FAQ、内部Wikiの提供。・学んだことをチームに対してプレゼンさせて、理解度を確認・3ヶ月で一つストーリー (SP3)を開発着手・バグバッシュデイ: 新入社員が入社初期にバグバッシュデイに参加し、既存のバグを修正・Tech div内でプロダクトdemo 23

hokan入社中社員(試用期間後)セグメントごとのコミュニケーション設計セグメント M1〜M2 S1~S3 自走・毎週の1on1（昇格から3ヶ月）・幹部勉強会・登壇機会・隔週ot毎週1on1 ・マネジメントトラックによる
・キャリア構築・Q定期懇親会設計（withCTO）・montly ランチ（ withリーダー、EM、部門長）要育成・毎週1on1 ・部門長、EMから継続サポート・マネージャー勉強会・毎週1on1 ・キャリア構築とスキル教育・個々の自己分析プランの策定・定期懇親会（withリーダー、EM） 24

コミュニケーション設計改善による想定の成果指標 • 既存社員 ◦ ストーリーポイント合計 ◦ サイクルタイムの改善 ◦ レビュー対応スピード •
入社社員 ◦ オンボーディング後の開発リードタイム ◦ オンボーディング期間終了から最初のスプリントのSP ◦ サーベイによる満足度 • 全体 ◦ slackレスポンススピード ◦ 発言量 25

プレボーディングブックとはプレボーディングブック共有入社前(1~3ヶ月) ブック読了入社前(1~3ヶ月) 理解度確認入社初日課題 •
情報提供不足 : 新入社員が入社前に必要な情報が不足している。 ◦ 会社理解 ◦ 業界理解 ◦ 開発理解 • 期待のすり合わせ :新入社員と会社側の期待が一致していない。スムーズにキャリアをスタートできるよう、必要な情報を提供する 26

プレボーディングブックとは (一例) 会社理解入社前に最低限インプットして欲しい業界理解開発理解 27

オンボーディングプロセスの基本設計 3ヶ月でバリューを出すためにはインプット学習アウトプット入社社員がアウトプットを出すためには、インプットと学習支援、インプットからアウトプットへの変換率を上げることが必要   • インプット  a.
トレーニングセッション: 新入社員向けのオンボーディング・トレーニングプログラムの提供。  b. メンター: 社員による1on1、ペアプロ、交流の場設計  c. ドキュメント: 詳細なマニュアル、FAQ、内部Wikiの提供。  • アウトプット  a. OJT研修: 実際のプロジェクトに参加させ、実務を通じて開発  b. フィードバックセッション: 定期的な1on1ミーティングで書いたコードをチーム内でレビュー、コミュニケーション、スタンスにおけるフィードバックを提供。  c. デモンストレーション: プロダクトについて実際にデモンストレーション  d. 学んだことをチームに対してプレゼンさせて、理解度を確認  28

オンボーディングプロセスの詳細設計共通オンボーディングフロー初回1on1 プランニングフォローアップ • 初回1on1事前準備 ◦ コミュニケーションガイドラインから質問リストを作成 ◦
過去の経歴、チーム経験を事前に把握しておく • 初回1on1 ◦ エンジニアの過去から現在の理解 ◦ ファクトの収集 • プランニング ◦ 以下の三つの軸でプラン ▪ 会社理解・適応 ▪ 業界理解 ▪ 開発理解 • フォローアップ 29

コミュニケーションガイドライン • 基本ルール ◦ プライベートな内容は自分から聞かない。ログを取らない ◦ 個人の状況、課題に合わせて傾聴 ◦ 静かな環境で参加する ◦
1on1中はカメラをつけ、カメラオフやミュートは原則しない ◦ 1on1の内容は集積する • 基本的な質問集（以下をそのまま誰にでも当てはめてそのままの表現で質問しないこと！！！） ◦ 例： ▪ 上長について、マネージャーについて • あなたの仕事をサポートするために、私がもっとできることは何ですか？ • フィードバックはどういう形で受け取るのが好きですか？ ▪ コミュニケーション • 最近一番話しているのは誰ですか？ • 最近全然話していない人はいますか？ 1on1するマネージャー以上が同じクオリティでできるようにする 30

オンボーディング期間の具体的なアウトプット • 仕様理解  a. バグ修正  i. 既存システムのバグを修正し、ソフトウェアの品質を向上  1. 目的：インシデントへの対応スピードの土台作り  b.
小規模な機能追加  i. ユーザーに直接的な価値を提供する小さな機能を追加。  1. 目的：SP8以上のチケットを対応できるようにする仕様把握  c. コードのリファクタリング  i. 依存関係の少ないコードのリファクタリング  1. 目的：今のコードの課題について理解  d. テストケースの作成  i. 単体テストやE2Eテストを追加し、システムの信頼性を向上させる。  • ドキュメントの更新  a. プロジェクトドキュメントを整理し、チームの生産性を向上させる。  31

オンボーディング期間の評価指標 32 成果指標目的評価プレボ理解度入社前の最低限のインプットを終え、 ONBへの理解度を上げやすくする。プレボの理解度 (S~D)
初期タスクの完了環境設定や初期コード変更を迅速かつ正確に完了することで、開発する環境にスムーズに適応し早期に開発可能な状態になること。初期タスクの完了率 or 完了時間チームへの統合チームメンバーとの初期コミュニケーションを活発化させ、早期にチームの一員として認識されること。・自己紹介 1on1の実施率・全体 1on1後のコミュニケーションパスの増減フィードバックの質と量オンボーディングプロセスの改善点を早期に収集し、適応することで、プロセスを迅速に最適化すること。 ONB対象者からのフィードバック内容と量 GitHubのプルリクエストのリードタイムプルリクエストのオープンからマージまでの時間を計測し、通常の開発フローに適応できるか判断するため・コミットからオープンまでの平均時間・オープンからレビュー依頼までの平均時間。・マージまでのリードタイム ※スプリントと関係ない開発も考慮。

スキルマトリクスと評価 33

スキルマトリクスの作成と活用目的エンジニアとしての現在のスキルを可視化し、今後目標とするスキルや理想の自身の姿はどのスキルが必要になるか、メンバーとリーダーが共通認識を持ってプロダクト開発や自己成長をするため 34

スキルマトリクス

スキルマトリクス 37

職種・役職マップ 38

・等級「役割（ミッション）」基準の等級制度でであり、ミッショングレード制となる。「役割（ミッション）」とは職責を果たすために、期待される行動を簡潔に示したもの。たとえ能力があってもその役割を果たしていなければ、その等級の評価は受けられない。役割（ミッション）ベースの等級制度である。必ずしも「等級＝役職」ではなく、期待役割に応じて等級を上げていくため「等級≒役職」ケースもあります。役職・ポストに関係なく、等級を上げていくことができる柔軟性を持たせた設計となります。・役職会社が定める、役割・期待・責任範囲・求められる能力・経験といったものの基準に段階で分け
たものを「役職」と呼ぶ。開発部においての分類は以下の通り。別途、等級によっては全社指定の役職「Div長」「室長」などの任命もある。等級・役職とは 39

職種・役職定義（汎用）等級役割・期待  参考能力・資格・要件  E1~ VPoE  ・会社の競争力の源泉につながる技術貢献を行っている   ・人材市場において得難い、希少な技術能力を保有している  
・会社のビジネス戦略を理解した上で、技術戦略を示すことができる   ・特定の技術に関する偏りない技術理解があり、会社が保有していない新しい技術も、短期間でいち早く習得し、組織への技術浸透を行うことができる   ・技術選定や設計におけるバランス感覚を保有しており、様々な意見、考えに対して柔軟に取り入れる発想を持ち、豊富な実績からエンジニアのロールモデルとして尊敬される対象として期待される  ・M3までの期待役割、ミッションを継続的に達成することのみを条件とし役員に選任される  M3 シニアEM   ・組織全体に関わるエンジニア採用戦略、組織戦略を策定できる   ・事業成長の強みにつながる開発生産性の最大化のノウハウを他社事例踏まえて持っており、 hokanの開発生産性を向上できる   ・複数事業、プロダクトの開発戦略の改善を通じて、生産性の最大化に貢献している   ・設計レビュー、開発プロセスのレビューといった業務を通じてだけでなく、高度にフィードバックや 1on1目標設定を各チームに実行責任を果たせる。   ・チームごとの組織課題を早期に予測し、解決方針を各リーダーとともに認識合わせ、実行をする役割が期待される   ・自分が関与していない他プロジェクトの工数見積に対して能動的にレビューを役割が期待される   ・スキルマトリクスの開発スキル平均4以上  ・その他のスキル平均5以上  40

職種・役職定義マネジメント等級役割・期待   参考能力・資格・要件   M2 エンジニアリングマネージャー
  ・自分のチームのエンジニアの採用戦略を策定し、実行に移せる   ・組織全体の強みにつながるような、開発標準、開発プロセスの改善による、生産性の最大化のノウハウを保有している   ・社内標準な技術を持つエンジニアと比較した場合に、一つの目安として２.５倍以上の生産性を発揮している  ・開発プロセス（KPT、Daily Meeting、ブランチ戦略、issue/Pull Requestの運用など）の改善を通じて、生産性の最大化に貢献している   ・設計レビュー、開発プロセスのレビューといった業務を通じてだけでなく、面談やSlackにおいて、メンバーからの技術的な質問に答えたり、能力開発に関するアドバイス、指導を行う役割が期待される   ・自分が関与していない他プロジェクトの工数見積に対して能動的にレビューを役割が期待される   ・スキルマトリクスの開発スキル平均4以上   ・その他のスキル平均4.5以上   M1 エンジニアリングリード  ・自チームのエンジニア採用について、見極めができる   ・特定のプロダクトやメンバーとだけでなく、性質の異なるプロダクトや性格が異なるメンバーとでも、技術的な専門性とリーダーシップを発揮してメンバーをリードできる   ・チーム開発におけるプロセス、情報共有の方法や、会議設計について、方針を策定して手本を示してリードすることができる   ・メンバーのコードレビューの実施を通じて、品質担保と育成を実施するという意識を持って業務を遂行できている  ・リードエンジニアの能力に合わせて上手くリードエンジニア業務を分担した上で、育成観点で支援やアドバイスを行うことができている   ・コミュニケーションをとり、バランスをとった仕様調整を行うことができる   ・見積りに対してレビューを能動的に行う役割が期待される   ・スキルマトリクスの開発スキル平均4以上   ・その他のスキル平均4以上   41

職種・役職定義プロフェッショナル等級役割・期待  参考能力・資格・要件  P+ VPoT   ・経営視点を持って技術戦略
を提案し実行に移すために、開発部門に説明責任を果たすことができる・会社のビジネス戦略を理解した上で、技術戦略を示すことができる・組織の競争力の源泉になる技術設計の勝ちパターンを構築し、組織知として展開している・hokanのトップ技術者として後進が育つエンジニア育成戦略に責任を果たす・P3までの期待役割、ミッションを継続的に達成することのみを条件とし役員に選任される・メンバーからの信頼もあること P3 シニアテックマネージャー   シニアQAマネージャー   ・社内標準な技術を持つエンジニアと比較した場合に３倍以上の生産性を発揮している・サーバーサイド、モバイル、フロントエンド、SRE、デザインの６つの技術分野のうち、３つの分野で社内でもトップレベルの技術力、豊富な知識を持つ・その中でも特定の技術分野に関しては、業界、コミュニティでも先端の技術レベルを持つ・幅広い技術分野あるいは複数プロダクトを横断した設計、実装を同時に行うことができ、通常では発揮できないプロジェクトのクオリティ、アジリティの実現と高い生産性の発揮をすることができている・技術選定や設計におけるバランス感覚を保有しており、様々な意見、考えに対して柔軟に取り入れる発想を持ち、豊富な実績からエンジニアのロールモデルとして尊敬される対象として期待される・複数の特定技術分野に関して（※目安としては一つの分野で５年以上の習熟した経験を持ち）、それぞれが社内でもトップレベルの技術力、豊富な知識を持つ・その中でも特定の技術分野に関しては、業界、コミュニティでも先端の技術レベルを持つ（※目安としては10年以上の習熟した経験を持ち） 42

職種・役職定義等級役割・期待参考能力・資格・要件 P2 テックマネージャー QAマネージャー・本部長など意思決定者と議論した上で、開発をリードできている・要件定義、設計、実装、テスト、障害対応など、開発で求められる幅広い領域での役割を行う事ができる・新しい技術やサービスに対する知識習得に対して積極的であり、影響ないシステムで検証した上で、技
術のライフサイクルをおさえた技術選定を行う事ができている・特定のプロダクト、チームだけでなく、会社全体に関与して、組織に貢献することができている・登壇、書籍出版、雑誌寄稿など情報発信を行い会社の技術広報の貢献も期待される・外部コミュニティとのネットワーキングを定期的に行い、最新の技術情報を獲得できている・技術的な英語でのやり取り（読み書き）・低レイヤーな技術についても知見がありディスカッション可能・スキルマトリクスの平均 4以上 ◆参考資格スキル・IPAシステムアーキテクト試験（SA）・AWS 認定ソリューションアーキテクト　プロフェッショナル P1 テックリード QAリード・複数の言語、技術標準選定、アプリケーション開発の経験だけでなく、インフラ含めたシステム全体の設計を行う事ができる・アーキテクチャの拡張性やライフサイクルを考慮した設計を行う事ができる・システム開発全体の標準 (プロセス、ドキュメント体系、採用技術 )について、最適な選択を行う事ができる・仕様調整段階から関与して、システムの課題、ドメインの課題、要求に対して、会議体の場でディスションを行いながら、顧客に対して様々なアイデアや、技術的解決方法、実現方法、設計上のリスクを意見するができる・S3以下のエンジニアの技術スキルにおける育成プランを一緒に作成し、実行をサポートできる・非常に高い技術力と分析力を持ち、5年以上の開発経験・スキルマトリクスの開発スキル平均4以上 ◆参考スキル・IPAデータベーススペシャリスト試験（DB）合格 43

職種・役職定義等級役割・期待   参考能力・資格・要件   S3 リードエンジニア  サブリードエンジニア  ・サービス要求に対して、システム化要件として再構成、定義する事ができている
  ・対象システムに必要なビジネス・業務知識を理解している   ・システム全体の中で一部アプリケーション・プラットフォームの設計を行っている   ・アプリケーション開発に必要な開発標準の最適な選択を行う事ができている   ・設計やコードのレビューを行っている   ・アソシエイトの育成、メンタリングを行っている   ・業務の期限は守りかつアソシエイトの模倣となり、難しければ周囲に報告して調整できる   ・スキルマトリクスの開発スキル平均3以上   ※自身が関わっているプロダクトの技術スタック   ・スキルマトリクスのその他のスキル平均3以上     ◆参考資格スキル   ・IPA 応用情報レベルの知識があること  S2 アソシエイト  ・下記のいずれかの技術領域の一部について専門的な知識、経験を保有して独力で実装を行う事ができるが、一部については指導を受ける必要がある   - SRE   - QA   - サーバーサイド/フロントエンド   - モバイル   ・開発標準、定められた開発プロセスに沿ってチーム開発を行う事ができる   ・担当するプロダクトについての実装をレビューやアドバイスをもらった上で独力で実施できる   ・社内でナレッジ・知見を持っている人を把握していて、ケースに応じて教わる相手を使い分けて学ぶ事ができている     ◆参考資格スキル   ・IPA 基本情報レベルの知識があること  S1 ジュニアアソシエイト  ・下記のいずれかの技術領域の一部について未経験あるいは経験が浅く、実務を行うまでに指導を受ける必要がある  - SRE   - QA   - サーバーサイド/フロントエンド   - モバイル   ・開発標準、定められた開発プロセスに沿ってチーム開発を行う事ができる   ・担当する機能開発についての実装をレビューやアドバイスをもらった上で独力で実施できる   普段から技術的なアウトプットを行なっている   44

生産性指標の可視化と活用 45

何を追えば生産性が上がっていると言えるか • 既存社員 ◦ ストーリーポイント合計 ◦ サイクルタイムの改善 ◦ レビュー対応スピード 47

findy team+の活用: サイクルタイム分析 48

findy team+の活用: レビュー分析 49

findy team+の活用: チーム比較(個人比較 2024/5入社) 50

結論 Findy team+めっちゃいいい・・・・フル活用しましょう！ 51

ただし、計測は大事だが目的にしない • 可視化は楽しい！ ◦ データで考えすぎない • 指標だけを改善しようとしない ◦ 組織の状態を全て表してはいない 52
課題解決の解像度を上げ続ける

今後の戦略 54 ◦ 売上、利益など経営指標への接続 ◦ 今後の開発組織の展望

売上など経営指標への接続 55 エンジニア生涯価値： 1エンジニアあたりの生産性 (利益)×勤続月数プレボーディングオンボーディング

ARRなど経営指標への接続 56 エンジニアの生産性を上げ続ける先に、どんな経営指標と紐づくのか？ • 売上成長（ Revenue Growth） • 解約率（Churn Rate）
• 製品投入までの時間（ Time to Market）

売上など経営指標への接続 57 経営 Tech SWE BS, PL 工数、予算生産性指標 •
見ている指標が違うので、適切に経営まで接続する必要がある

　まとめ 58 エンジニアが増えるほど問題も増える生産性を高めるために、多くのエンジニアをまとめ上げるのは難しいものである。その難しさは、自走できるエンジニアをどれだけ早く育成、強化できるかにより決まる。

開発組織のマネジメント： 採用からオンボーディングで始まる一貫した生産性向上戦略

開発組織のマネジメント： 採用からオンボーディングで始まる一貫した生産性向上戦略

More Decks by haruki

Other Decks in Programming

Featured

Transcript

開発組織のマネジメント：採用からオンボーディングで始まる一貫した生産性向上戦略

開発組織のマネジメント：採用からオンボーディングで始まる一貫した生産性向上戦略