SES活用の落とし穴：ありがちな失敗例とその回避策

**Standish GroupのCHAOSレポートでは、ITプロジェクトの完全成功率は低水準に留まることが繰り返し報告されています。**¹ 失敗の多くは要件やコミュニケーションに起因し、過去の調査でも「不完全な要件定義」や「ユーザー関与の不足」などが主要因として挙げられています。¹ 修正コストは後工程に進むほど増大し、初期に比べて桁違いに膨らみ得ることは古典的研究でも示されています。² 人手不足の慢性化で外部人材活用が常態化するなか、SES（システムエンジニアリングサービス。成果の完成ではなく作業の遂行を提供する準委任契約）は即戦力を素早く補う現実的な手段です。ただし、契約や受入の設計を誤ると、リードタイムの伸長、品質の分散、知の散逸といった形で損失が積み上がります。現場では同じ落とし穴が繰り返されがちです。以下では、その構造と典型的な失敗例、そして再現性のある回避策を、経営と現場の双方に役立つレベルで具体化します。なお、DevOpsの成熟度を測るDORA指標（デプロイ頻度、変更リードタイム、変更失敗率、平均復旧時間）も適宜参照しつつ、SES活用を定量的にマネジメントする観点を提示します。⁵⁶

SESの現実と、失敗が生まれる構造

SESは成果物の完成を約束する請負ではなく、時間と専門性を提供する準委任（Time & Materials）です。つまり、単価と稼働時間の掛け合わせがコスト算定の基礎になり、アウトカム（事業成果）ではなくアウトプット（作業量）の連続が可視化されやすい。ここに、発注側と受注側のインセンティブ非整合が生まれます。要件が曖昧なままチームに人を足すほど、目先の速度は上がって見えても、後戻りと仕様揺れのコストが雪だるま式に増える。特にプロダクトの探索フェーズ（仮説検証）では、探索と実装の境界が曖昧になり、誰もリスクを握らない空白地帯が生まれがちです。

**最大の構造的な問題は、指揮命令と責任の線引きが曖昧なまま稼働が始まることです。**準委任の枠組みでは、個々のエンジニアに対する直接の指揮命令や日常的な勤怠管理のあり方によっては、派遣と同等とみなされるリスク（いわゆる偽装請負）が指摘されます。現場の善意で「その場で指示して早く進める」運用を続けると、法務・労務上のリスクを抱えながら、責任の所在もぼやけるという二重の問題に発展します。³

指揮命令線の混線とグレーゾーンの拡大

日次のスタンドアップで発注側PMが外部個人に直接タスクを割り振り、評価や勤怠の調整も事実上行っている。席やアカウント、オンコールまで同列に扱う。こうした日常の積み重ねが、気づけば契約の想定を超える運用に陥らせます。形式上の契約は準委任でも、実態は派遣に近いという状態は、リスクの温床であり、プロジェクトの透明性を毀損します。³

「終わらない」準委任と受入基準の欠落

もう一つの構造的な罠は、受入基準（DoD: Definition of Done。完了の定義）が定義されないまま稼働が続くことです。成果物がいつ「終わった」とみなされるかを明文化しないと、レビューと手戻りが無限ループ化し、実質的な定額化を狙ったはずの人月が、際限なき追加説明と再修正に溶けていきます。チームは忙しいのに価値が積み上がらない。これは多くの場合、契約の問題というより、受入責任と品質基準を握れなかったプロセス設計の問題です。⁴

ありがちな失敗例：現場が直面する具体と兆候

まず目立つのは、レートカードの罠です。スキルマトリクスと単価帯が明確でないままアサインが進み、実力に対して高い単価が固定されると、途中の交代提案が出るたびに学習曲線がリセットされます。三カ月ごとにキーパーソンが抜けるたび、暗黙知がまた散逸し、速度と品質はじわじわと低下します。短期の単価交渉で得た小さなディスカウントより、チームの記憶を失う機会損失の方がはるかに高くつきます。

次に多重下請の影響です。発注から実装者までの層が増えるほど、情報は要約と再解釈を繰り返し、仕様のニュアンスは薄まります。レビューで露見する設計の勘違いは、必ずしも個人のスキルではなく、伝言ゲームで失われた前提に起因します。加えて、実装者が可視化されない構造では、品質の揺らぎが早期に見つかりにくい。チームは「忙しさ」を報告し続ける一方で、デプロイ頻度の低下や変更失敗率の上昇、平均復旧時間の伸びといったDORA指標のトレンドが悪化していきます。⁵

探索と実装の境界管理が崩れたケースも典型です。仮説検証と既存機能の保守が同じ人に混在し、どちらも中途半端になる。影響半径の大きい決定は決裁待ちのまま停滞し、細かな改修だけが積み上がる。ダッシュボード上のベロシティは維持されているのに、ビジネス指標は動かない。この乖離は、準委任の「時間提供」がプロダクトの「成果提供」に翻訳されていないサインです。

セキュリティを理由に権限が絞られすぎ、ログやメトリクスにアクセスできない外部メンバーが増えると、障害対応はさらに遅れます。一次情報に触れられない状況でバグを直すには、再現報告と指示待ちの往復が不可避です。オンコール体制も内製だけで抱えると、結局は外部のコードに内部だけで責任を負うという、誰にも得のない構図に陥ります。

回避策：契約・プロセス・チームを再設計する

第一に、契約の時点で成果を握ります。 SOW（Statement of Work。作業範囲記述）で業務範囲と非範囲を明確にし、受入基準を文章で定義します。準委任であっても、完了の判定材料をエビデンスまで含めて取り決める。例えば、受入はPR（プルリクエスト）のレビュー完了と自動テストの合格、ステージングへのデプロイ成功、必要な運用Runbook（手順書）の更新までを条件にする、といった粒度です。バックフィルの条件、交代時の引継ぎ成果物、転籍や買切りに関する取り決めも、情緒ではなく条項として先に置きます。

第二に、プロセスを計測可能にします。 DORA指標（デプロイ頻度、変更リードタイム、変更失敗率、平均復旧時間＝MTTR）や欠陥密度を、チーム横断で月次レビューします。⁵⁶ 実装の「見かけの速度」ではなく、価値の流れを示す指標で透明化することが重要です。スプリントの受入では、DoDに沿った証跡を残し、未達は次スプリントに繰り越す。探索の仕事はスパイク（調査タスク）として独立させ、成果は意思決定資料や実験ログとして管理し、開発タスクと混在させない。知識移転は計画に組み込み、外部メンバーの在籍期間に対して、内製メンバーへのペアリングやドキュメント化の比率を一定以上に設定します。⁴

第三に、権限と責任をチーム単位で束ねます。 混成チームには明確な責任者を置き、RACI（Responsible, Accountable, Consulted, Informed）の観点で意思決定、レビュー、運用、顧客折衝の誰が何を担うかを合意します。発注側が成果責任を持ち、外部は専門性の提供に集中する。オンコールでは、発報の一次対応とログ調査のアクセス権をチームで共有し、個人をまたいだボトルネックを解消します。セキュリティ上の制約は前提としつつ、監査可能な形で情報にアクセスできる運用を設計します。アクセス不能を前提にすると、障害復旧のMTTRは必ず悪化します。⁶

契約設計：準委任でも「受入」を前に出す

時間単価と人数だけの見積に終始しないことが要です。成果の定義、受入の証跡、交代時のナレッジ移転、品質基準違反時の是正、四半期ごとのQBR（Quarterly Business Review。四半期事業レビュー）を契約に組み込む。多重構造の抑制は、一次請け原則と実装者の素性開示、セキュリティ・労務の遵守声明で担保します。これらは形式ではなく、事業継続性のための保険契約です。³

プロセス設計：DoD・SOW・Exitをセットで持つ

着手前にSOWで境界を描き、スプリント単位のDoDで完了を定義し、契約終了時のExitプランで知の移転を担保します。Exitには、ドキュメントの所在、アーキテクチャ決定記録（ADR）、権限剥奪と委譲の手順、保守観点の欠落アラートなどを含めます。こうして、開始・進行・終了の三つの段で「終わり方」を決めておくと、途中の品質議論も建設的になります。⁴

人とチーム：二人三脚モデルで暗黙知を外に出す

キーパーツには内外のペアを組み、レビューと運用を共に担わせます。内製が仕様の妥当性を握り、外部が実装の厚みで支える。設計レビューは一段階増やし、外部が書いたコードは内製が責務を持って読む。ここでの「読む」は、動くかどうかではなく、運用できるかどうかを問う視点です。暗黙知はレビューでしか表に出ません。

投資対効果の見立てと、意思決定のための基準

SESの是非はコストだけでは決まりません。三名・六カ月・月単価百万円という素朴なモデルなら総額一千八百万円です。これは、同期間にプロダクトが生むキャッシュフロー、技術負債の圧縮、学習の蓄積で評価します。たとえば、変更リードタイムを二週間から三日に短縮できれば、仮説検証のループが加速し、失敗の単価が下がる。オンコールの平均復旧時間（MTTR）を四時間から一時間にできれば、SLA違反のペナルティと機会損失は目に見えて減ります。これらはすべて月次のDORA指標に落ちるため、投資対効果は数字で追えます。⁶

選定の場面では、供給側の成熟度を問うのが近道です。具体的には、DORA指標の実績を外部案件でどの程度語れるか、交代時の引継ぎ成果物が標準化されているか、セキュリティレビューの反復経験があるか、QBRの運用が文化として根づいているか、そして、こちらが握る受入基準にどれだけ前向きかを確認します。華やかな導入事例より、この五点への受け答えの方が、はるかに将来の手戻りを減らします。⁵

ブレークイーブンの目線をチームで共有する

投入コストを三カ月で回収するには、どれだけのリードタイム短縮、障害削減、チャーン抑制が必要か。仮説を数字に置き、四半期ごとに見直します。達成できない場合は、範囲の縮小か、契約の終了か、内製化への転換を選ぶ。意思決定のスピードはコストです。迷いを減らすのは、日々の小さな可視化の積み重ねに尽きます。

まとめ：SESを「時間の購入」から「学習の加速」へ

SESの価値は、人手不足の穴埋めではなく、事業の学習を加速することにあります。契約で受入を握り、プロセスで計測し（DORA指標で可視化し）、チームで責任を束ねる。これだけで、大半の落とし穴は回避できます。次のスプリントで何を変えますか。SOWに受入の証跡を追記する、スプリントレビューでDORA指標を読み合わせる、内外のペアを一組つくる。どれも今日から始められる小さな一歩です。小さく確実に、価値の流れを太くする。その先で、SESはコストではなく、競争優位の増幅器になります。

参考文献

Standish Group CHAOS Survey summary (spinroot.com). https://spinroot.com/spin/Doc/course/Standish_Survey.htm#:~:text=Overall%2C%20the%20success%20rate%20was,1
Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall.
企業法務ナビ: 偽装請負のリスクと労働者性の判断（日本法の概説）. https://www.corporate-legal.jp/matomes/2714#:~:text=%E3%81%BE%E3%81%9F%E3%80%81%E3%81%93%E3%81%AE%E5%A0%B4%E5%90%88%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E3%80%81%E5%AE%9F%E6%85%8B%E3%81%8C%E5%8A%B4%E5%83%8D%E8%80%85%E4%BE%9B%E7%B5%A6%E3%81%A7%E3%81%82%E3%82%8B%E3%81%AB%E3%82%82%E3%81%8B%E3%81%8B%E3%82%8F%E3%82%89%E3%81%9A%E3%80%81%E5%A7%94%E4%BB%BB%E5%A5%91%E7%B4%84%E3%82%84%E8%AB%8B%E8%B2%A0%E5%A5%91%E7%B4%84%E3%82%92%E7%B7%A0%E7%B5%90%E3%81%97%E3%80%81%E5%8F%97%E4%BB%BB%E8%80%85%E3%83%BB%E8%AB%8B%E8%B2%A0%E4%BA%BA%E3%82%92%E8%87%AA%E7%A4%BE%E3%81%AE%E5%8A%B4%E5%83%8D%E8%80%85%E3%81%A7%E3%81%82%E3%82%8B%E3%81%8B%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E6%89%B1%E3%81%86%E3%81%93%E3%81%A8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%94%E7%B4%B9%E4%BB%8B%E3%81%84%E3%81%9F%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
Scrum.org: What is the Definition of Done? https://www.scrum.org/resources/what-definition-done/#:~:text=Definition%20of%20Done%20is%20the,Done%20includes%20all%20of%20the
Atlassian: DORA metrics explained. https://www.atlassian.com/devops/frameworks/dora-metrics#:~:text=DevOps%20Research%20and%20Assessment%20,iterations%2C%20and%20insight%20into%20failures
Google Cloud Blog: Using the Four Keys to measure your DevOps performance. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance/#:~:text=At%20a%20high%20level%2C%20Deployment,DORA%2C%20for