ID:82300さん

開発2課 約20名（プロパーエンジニア6名＋業務委託チーム複数）。課長と連携しながら、プロパーチームの直接マネジメントと業務委託チームの開発進行管理を担当。アジャイル導入・リテンション施策・採用戦略・技術選定まで幅広く推進。

チームが自律的に判断・行動できる状態を設計し、組織変動が続く中でもチームの開発機能を維持すること。具体的には以下の3点が責務でした。 1. ウォーターフォールからアジャイルへの変革を推進し、開発生産性を向上させること 2. 組織不信が広がる状況下で、メンバーのリテンションを確保すること 3. 「開発生産性の向上」という抽象的な組織方針を、チームが実行可能な具体施策に落とし込むこと

#### 入社時の状況と想定 ウォーターフォール中心の開発体制をアジャイルへ変革するフェーズにコミットする形で入社しました。入社時の役職は開発管理で、課長の下で業務委託4チームの開発進行管理と新規プロパーチームの立ち上げを担当。その後の人事制度改変によりチームリーダーとなり、プロパー6名のチームを直接マネジメントしつつ、課全体約20名の開発組織運営を課長と連携して推進しました。 アジャイル変革自体は入社時に想定していましたが、以下は入社後に直面した想定外の構造的課題でした。 #### 問題・障害 **① 組織の急激な変動と信頼の毀損** 組織再編に伴い、評価制度・勤務体制・開発フローが短期間に急変しました。マネジメント層の対応に起因する組織不信が部門全体に広がり、他部署から多数の退職者が発生。さらに2025年5月には直属の上司（課長→部長に昇格後）も退職し、同年6月からは他部署と兼務の新任課長の下で、現場のマネジメント判断の比重がより自身に寄る体制となりました。 **② 抽象的な組織方針** 組織方針として「開発生産性の向上」は掲げられていましたが、具体的な施策や優先順位はチーム側で設計する必要がありました。何をどこまでやるかの判断基準が不在の中で、チームが迷わず動ける状態を作る必要がありました。 **③ デプロイメント頻度の低さとリリース体制の属人化** デプロイメントが月2回程度にとどまり、リリースのたびにメンテナンス日を設けてシステムを停止する必要がありました。また、リリースを実行できるチームが1チームに限られており、他チームはリリースのたびにそのチームに依存していました。 #### 工夫・打ち手 **チーム自走化の設計** 「自分がいなくてもチームが自律的に判断・行動できる状態」を設計目標に据えました。私の役割は仕組みの設計者であり、最終的にはその仕組みの運用をチームに委譲して自分が不要になることがゴールです。 まず「開発生産性の向上」という抽象的な組織方針に対して、チームとプロセスの密結合を解体するという具体的な方針仮説を立てました。開発プロセスの中で無駄になっている部分をピックアップし、一つずつ潰していく形です。具体的には以下のような施策を進めました。 - リリース作業が特定チームに紐づいていた「属チーム性」を排除し、全チームがリリースできる体制を構築 - SREチームと連携してWebサーバを2台構成に冗長化し、無停止リリースを実現 - QAチームと会話し、過剰なテスト工数を整理。どんなテストが本当に必要かを合意形成 - スライドで作成していた冗長な要件定義書を、GitHub Issueレベルで十分という合意を形成し、ドキュメントの軽量化を実現 チーム内の意識改革としては、プロセスの中で閉じた意識になっていたメンバーに対して、プロセスの外に足を踏み出して実験することを促しました。「失敗したら戻せばいい、うまくいけばそれで進めましょう」というスタンスで小さな成功体験を積み重ねてもらい、自分たちで改善できるという意識を醸成しました。 - チームの成熟度に合わせて関与レベルを段階的に変化させました（具体的指示 → 支援的 → 委任的） - Working Out Loudで非同期の業務状況を共有し、時短勤務メンバーもキャッチアップ可能な環境を整備しました **リテンション施策** - メンバー一人ひとりに対して月1回の1on1を実施し、長期的なキャリアストーリーの構築を支援しました - チーム単位で自作のレトロスペクティブを実施し、半年前との比較で成長・停滞を可視化しました - 会社方針を自分の言葉で噛み砕いて伝え、メンバーの不満には共感しつつ構造的な背景を共有しました - メンバーの強みを言語化し期待を伝えつつ、組織課題との整合性を明示しました **アジャイルトランスフォーメーション** - 全チームへのスクラム導入を主導。ただし画一的な適用ではなく、チームごとの特性（プロパー/業務委託、新規開発/保守運用）に応じた運用へ柔軟にアレンジしました - バッチサイズの縮小を段階的に推進し、品質を維持しつつリリース負荷を低減しました - 保守運用チームには「1dayスプリント運用」を設計・導入し、日次で状況把握と優先度判断ができる体制に転換しました - チームの成熟に合わせてスクラムから発展させ、最終的にはXPとカンバンの要素を取り入れたチーム独自のプロセスへ進化させました #### 成果 - 組織不信により他部署から多数の退職者が出る状況下で、直接マネジメントするプロパー6名のチームからは退職者ゼロを維持 - デプロイメント頻度を課全体で月2回程度→週1〜2回に改善（約4倍） - メンテナンス日のシステム停止が不要になり、無停止リリースを実現。リリース可能なチームも1チーム→全チームに拡大 - 一部のチームで自律的な改善サイクルが定着し、コーチとしての伴走から委任へ移行

マーケティングリサーチ企業のWebアンケートカスタマイズ開発チーム（14名）のチームリーダー。年間1,500件超の案件運用における進捗管理・業務サポート・勤怠管理（36協定遵守指導）・キャリア支援・技術指導を担当。

年間1,500件超の案件を14名で安定的に運用しつつ、新規メンバーが半年以内に戦力化する再現性のある体制を構築すること。具体的には以下の2点が責務でした。 1. 中堅・ベテランしか対応できない案件が多く属人化していた状態を解消し、チーム全体のキャパシティを向上させること 2. 新規メンバーの立ち上がりを仕組み化し、個人の力量に依存しない育成体制を作ること

#### 問題・障害 **① 属人化による人材のボトルネック** チームが扱う案件には多様なバリエーションがあり、複雑な案件は中堅・ベテランしか対応できませんでした。特定のメンバーに負荷が集中し、チーム全体のキャパシティが個人の力量に依存する構造になっていました。 **② 新規メンバーの戦力化に時間がかかる** オンボーディングの仕組みが体系化されておらず、新規メンバーの立ち上がりは先輩のOJTに依存していました。教える側のスキルや時間によって育成品質にばらつきがあり、戦力化までの期間が読めない状態でした。 #### 工夫・打ち手 **ナレッジマネジメントによる属人化解消** - 中堅・ベテランしか対応できなかった案件を分析し、何が難しさの要因かを構造的に整理しました - 案件ごとの機能出現率を分析し、頻出パターンを再利用可能なプログラムとして整備。クライアントへの提供速度を大幅に改善しました - プログラム構成の簡易化と動画・テキストマニュアル化により、入社半年以内のメンバーでも対応可能な体制を整備しました **人材育成システムの設計** - 目標管理・マニュアル整備・業務フローの明確化により、新規メンバーが半年以内に戦力化する教育制度を構築しました - オンボーディング動画を作成し、教える側のスキルに依存しない再現性のある育成プロセスを実現しました - 36協定遵守指導を含む勤怠管理で、育成のスピードと持続可能な働き方のバランスを維持しました #### 成果 - 2023年度は9名を受け入れ、全員を既存メンバーと同等の量的アウトプットを出せる水準まで育成 - 属人化の解消により、チーム全体のキャパシティが向上 - 自身の離職後もチームが自走を継続（自走化設計の再現性を実証）