SES失敗事例と改善策
失敗が起きる典型パターンと早期サイン
SESでつまずく現場には共通点があります。要件が曖昧なまま着座させる、工数前提で人数だけ増やす、窓口が一人に集中してボトルネック化、成果物とレビュー基準が無い、交代やバックフィルのルール未整備、の5つです。進行初期に以下のサインが出たら、黄色信号と見て立て直しに入るべきです。
- 質問がチャットに溜まり未回答のまま24時間を超える
- デイリーが30分を超え、ふりかえりが実質作業報告会になる
- コードレビューの待ち時間が平均48時間を超える
- 稼働率90％超が2週間続き、学習と改善の時間がゼロ
- スプリントでデモできる完成定義（DoD）を誰も言語化できない
この段階で「頑張る」よりも、スコープ・体制・作法を見直す方がコストは小さく済みます。
規模別に起きやすい落とし穴と対処
小規模プロダクト: 案件化が早すぎて仕様が空洞
数名チームで多いのが「口頭合意で開発開始→仕様の二重化→手戻り」です。対処は、着座前にSOW（作業範囲記述）へ最低限の粒度で落とすこと。画面遷移図、非機能要件の閾値（応答600ms以内など）、データライフサイクル、禁止事項（本番直書き禁止など）を1枚でよいので明文化します。下書きはChatGPTやClaudeで骨子を起こし、現場で赤入れするとスピードが出ます。
中規模チーム: ロール未定義でPMが全部やる
10名前後で起きるのが「PMが調整・レビュー・採用面談・進捗管理を一人で抱える」状態。RACI（責任分担）を先に引き、レビュアを固定、レビューSLO（例: PRは24時間以内に一次レビュー）を決め、週次のリスクレビューを「数字で」回します。ベロシティ、バグ修正リードタイム、レビュー待ち時間の3指標が崩れたら早期に交代・増員・スコープ整理を選びます。
大規模/長期: ナレッジが散り、属人化が進む
人の入れ替わりが前提になるため、オンボーディングキットを常に最新化します。アーキテクチャ図、環境構築手順、用語集、権限申請フロー、テスト方針の5点セットが1クリックで手に入る状態を作り、更新責任者を明確にします。Copilotを用いたコーディング標準、Geminiでのドキュメント要約など、更新の手間を自動化する工夫も有効です。
身近な企業活用例: 従業員200名規模の製造業での基幹刷新
背景: 老朽化した販売管理の刷新。社内IT3名に対し、SES5名を投入。開始3ヶ月で遅延が2スプリント分、障害対応が夜間に偏在、レビュー待ちが平均72時間になりました。
失敗の要因:
- スキルミスマッチ: ETLとSQLチューニングが鍵なのにWebフロント中心の人員が多数
- 窓口一極集中: 問い合わせが情報システム部の1名に集中しボトルネック化
- DoD不明確: 「テスト観点」が属人的でUAT通過率が低迷
- 契約の穴: 交代リードタイムやバックフィルの定義がなく、合わない要員の是正が遅延
立て直し策（着手から2週間で実施）:
- スキルマトリクス公開と再編成: 必須を「ETL/SQL/バッチ/取引先EDI/監視運用」に定義し、合わない2名は交代。交代SLOを「5営業日以内に候補提示、10営業日で着座」に設定。
- シャドー期間: 新着座は1週間ペアでレビュー同席。以降は週2回の設計レビューを固定化。
- レビューSLO: PR一次レビューは24時間以内、変更行数1,000行超は分割必須。レビュー遅延は自動通知。
- テスト強化: ChatGPTとClaudeでテーブル定義から境界値テスト案を自動生成、テスト観点の抜けを機械的に洗い出し。
- 要件の書式統一: Geminiで既存仕様書を見出し・用語を正規化、差分を見える化。
- 負荷の平準化: 問い合わせを3名のローテーションで一次受け。SLAは「4営業時以内に初動」。
結果（8週間後）:
- レビュー待ち時間: 72時間→19時間
- バグ修正リードタイム中央値: 7.0日→2.1日
- UAT一発通過率: 41%→78%
- 超過工数: 月150時間→30時間に圧縮
ポイントは「人を増やす」ではなく、交代基準・レビューSLO・テスト観点の標準化という“運用ルール”を整えたことです。最適化の副産物として、Copilotの提案を活かしたリファクタでバッチ処理の実行時間も32%短縮できました。
すぐ導入できる改善テンプレート
1. スキル定義と見極め
- 必須/歓迎/NGの3区分でスキルを定義（例: 必須=SQL最適化/ジョブ管理、歓迎=監視設計、NG=運用夜勤不可）
- 面談は30分で実技1問・失敗談1問・アーキ志向1問の計3問に固定
- コードサンプルが出せない場合は、システム構成図と障害復旧の手順を口頭で説明してもらう
2. 契約・体制の押さえどころ
- SOWに「役割・成果物・レビュー基準・稼働上限・交代SLO・バックフィル費用負担」を明記
- 週次のQBRライト（数値レビュー）: ベロシティ、レビュー遅延、障害起票→クローズのリードタイム
- セキュリティ: 権限は役割ベース、持ち出しデータの範囲とログ保全を先に決める
3. オンボーディング5点セット
- アーキ図と依存一覧（SaaS、外部API、バッチ）
- ローカル・検証環境の構築手順（15分で起動できる粒度）
- 用語集（業務・社内略語）
- 権限申請フロー（最短ルートと代替手段）
- レビュー/テスト方針（DoD、SLO、例外の扱い）
4. 運用KPIと意思決定ルール
- KPI: レビュー待ち時間、UAT通過率、バグ修正リードタイム、オンボーディング完了までの稼働日
- 意思決定: 2スプリント連続で閾値悪化→交代 or スコープ再設計を原則先に検討
- 可視化: バーンダウン/アップ、レビュー遅延ヒートマップを常時掲示
SESは「人を置く」サービスではなく、「チームの一部を設計して運用する」行為です。失敗事例の多くは、人よりも設計とルールに原因があります。上記の具体策はどれも翌日から始められます。常駐エンジニア事業として価値を最大化するには、現場で回る仕組みと、交代を含む健全な選択肢を最初から組み込むことが近道です。
