開発体制設計と役割分担の最適化

開発が遅い、品質が安定しない、会議が多いのに決まらない——こうした兆候の多くはスキルではなく体制設計に起因します。何を誰がいつ判断し、どこまで自動化し、どの指標で進捗と健全性を測るか。受託の現場では、顧客側の承認プロセスや契約条件が絡むため、体制と責務の粒度を一段細かく設計する必要があります。

目的・制約から逆算するチーム編成とスコープ管理

体制を決める順番は「目的→制約→構造→道具」。まず事業KPI（例：新規登録、CVR、獲得単価）を技術KPI（リードタイム、デプロイ頻度、変更失敗率、MTTR）に翻訳し、そこから必要な専門性と人員配置を逆算します。

• スコープの棚卸し：必須・延期・将来の仮説に三分割。延期項目には「再判断の条件」を書く
• 制約の明文化：納期、予算、法対応、既存システム依存、承認ゲートの回数とSLA
• 構造の選択：顧客接点に直結するストリーム単位の開発チーム＋横断の品質・SRE支援チームを基本に、領域の複雑度で増減

例えば6カ月・6名で顧客向けポータルを週次リリースしたいなら、モノリス＋強い自動テストの構成を優先し、マイクロサービスは分割コストと運用負荷を見積もって慎重に。受託では「承認待ち」がボトルネックになりやすいため、成果物の最小単位（UIモック、API契約、テスト観点リストなど）を小さく切って、承認サイクルを短く設計します。

役割分担はRACIで“決めきる”。受託特有の承認者も明確に

肩書きではなく責務で設計します。代表的な責務は次の通りです。

• プロダクト責任：価値仮説、優先順位、受け入れ基準の最終決定（顧客側担当が担うことを前提）
• デリバリーPM：範囲・コスト・納期のトレードオフ管理、変更要求の影響評価
• エンジニアリングマネージャ/テックリード：技術選定、アーキテクチャ、品質基準、レビュー方針
• QA/テスト：リスクベースの計画、非機能要件の検証、リリース判定の根拠提示
• SRE/プラットフォーム：CI/CD、監視、セキュリティ、インシデント対応

RACI（Responsible/Accountable/Consulted/Informed）で重要判断の表を1枚用意します。例：

• 仕様凍結：R=プロダクト、A=顧客責任者、C=PM/QA、I=開発全員
• 技術選定：R=テックリード、A=EM、C=QA/SRE、I=PM/顧客技術窓口
• リリース可否：R=QA、A=PM、C=SRE/プロダクト、I=顧客関係者

判断プロセスも時間制約で設計します。技術RFCは24時間でレビュー、反対意見がなければ自動承認。顧客承認は「差分スクリーンショット＋受け入れ条件チェックリスト＋影響範囲」のセットで提出し、SLAを48時間と明示します。

フローと会議体は“短く・定型化”し、レビューSLAを数値で回す

会議は意思決定のための装置として設計します。

• 週次ステアリング：顧客責任者・PM・プロダクトで、リスク・変更要求・予算消化を合意
• スプリント（2週）：開始時に優先順位と受け入れ条件を確定、終了時はデモと次スプリントの着手可否だけを決定
• デイリー15分：ブロッカー共有と割り込みのトリアージのみ

レビュー運用は数値を持ち込みます。

• PRは1本400行以内、2名レビュー、SLAは24時間
• 静的解析・単体テストはPR作成時に自動実行、失敗時はレビュー不可
• 受け入れ条件はGiven-When-Thenで記述、テスト観点と1対1に紐づけ

リリースはフィーチャーフラグと段階的リリースを基本に、ロールバック手順を1ページで常備。DORA指標（リードタイム、デプロイ頻度、変更失敗率、復旧時間）を週次で可視化し、改善ターゲットを1つに絞って回します。

自動化とAIの使いどころ。責務の摩擦を道具で最小化する

CI/CDは「チケット→PR→ビルド→テスト→ステージング→承認→本番→変更履歴配信」を一気通貫で連携。権限は“開発者はステージングまで自由、本番はリリースマネージャが責任”の二層に分離します。IaCで環境差異をなくし、監視・アラートはサービス水準（SLO）に直結させます。証跡として、レビュー記録・テスト結果・承認ログを自動保存し、受託の納品要件に耐える形で保管します。

AIは人の判断を補助し、レビューSLAを守るために使います。

• 要件たたき台や受け入れ条件の言語化にChatGPTとClaudeを併用して観点漏れを減らす
• コード補完とテスト生成にCopilotを活用し、PRの初期品質を底上げする
• 多言語のユーザー向け文言レビューや画像代替テキスト案の作成にGeminiを使い、非機能品質を短時間で確保

身近な企業活用例：地域でECと実店舗を運営する中堅小売（社員120名）の再構築

状況：社内エンジニア2名＋外部ベンダー複数でサイト改修を継続。リリースは月1回、承認待ちでキューが詰まり、障害時の復旧が平均8時間。受注ピークで機会損失が発生。

失敗の要因：役割が曖昧で、仕様凍結の決定者が毎回変わる。PRのサイズが大きくレビュー滞留。顧客側承認に必要な証跡がバラバラでやり直しが頻発。

改善：受託側でデリバリーPMとQAリードを専任化し、RACIを1枚で合意。PR上限400行・レビューSLA24時間を設定、テスト自動化を整備。承認パッケージ（差分キャプチャ、受け入れ条件、影響範囲）を定型化。要件定義時にChatGPTとClaudeでテスト観点リストを先出し、Copilotで単体テストの雛形を自動生成。多言語表記はGeminiで初稿を作り、編集コストを圧縮。

結果：デプロイ頻度は月1→週2、リードタイムは平均20日→6日に短縮。変更失敗率は25%→8%に低下、復旧時間は8時間→70分。繁忙期の在庫同期遅延が解消され、カート離脱率が改善。

体制設計は「誰が・何を・どの速度で決めるか」を合意し、道具で担保する営みです。受託開発ソリューション事業では、顧客の目的と制約を翻訳し、役割・フロー・自動化・証跡までを一体で設計できるかが、納期と品質、ひいては事業成果を左右します。現場が迷わず動ける体制を先に作ることが、最短の近道になります。