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

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

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

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

　エレガントパズル 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エンジニアあたりの利益 ×勤続月数 プレボーディング オンボーディング 

グラフで表した場合 19 エンジニア生涯価値： 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 

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

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

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

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

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

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

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

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

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

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

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

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

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