会社情報
採用情報
お問い合わせ
Article

発注側が知っておくべき開発プロセス：要件定義から納品まで

高田晃太郎
発注側が知っておくべき開発プロセス：要件定義から納品まで

大規模ITプロジェクトでは、予算超過や納期遅延、想定価値未達が繰り返し指摘されている¹。スタンドイッシュ・グループのCHAOSレポートでも、規模や複雑性が増すほど成功率は伸び悩む傾向が長年報告されている²。統計の定義や年度で揺れはあるとしても、発注側がプロセスの要所を握らなければ結果が運任せになりがちなのは確かだ。多くの現場で観測される傾向として、成果の差はベンダーの腕前そのものより、発注側がどれだけ明確な意思と基準を持ち、開発プロセス（要件定義〜検収・運用移行）を設計できているかに強く依存する。そこで本稿では、要件定義から納品・運用移行までを、CTOやエンジニアリーダーが握るべき決定点とエビデンスに基づく指標で読み解く。曖昧な善意より、合意可能な事実と検証可能な基準に寄りかかるのが生産的だ。

失敗を減らす視点と全体像：成果から逆算し、合意可能な基準を先に作る

プロジェクトの滑走路に立ったとき、最初に決めるべきは工程表ではない。顧客価値と事業KPI、そしてそれを技術的に担保する非機能要件（NFR）を、受入基準と測定方法まで含めて言語化することが第一歩になる。工程はその後に付いてくる。つまり、ロードマップの順序は価値の定義、受入の定義、実装の定義だ。価値は売上や運用コスト削減、NPS（顧客推奨度）やアクティブ率の改善などで語れ、受入はユーザーストーリーと検収観点で語れる。実装はアーキテクチャ方針、スプリント計画、CI/CD（継続的インテグレーション/デリバリー）と品質計画で語る。こうした分解は、ベンダーが変わっても再利用できる。

この全体像の中で、発注側がリードすべき合意文書は三つある。ひとつはSOW（Statement of Work：作業範囲記述書）で、成果物、前提、スコープ境界、依存関係、マイルストーン、支払いを定義する。次に受入条件（Acceptance Criteria）で、振る舞い、品質、セキュリティ、パフォーマンスの最低基準と検証手順を定める。最後に変更管理規程で、スコープ変更をどう評価し、いつ合意し、どう記録していくかの手続きを決める。これらはプレイブックとして前もって雛形を用意しておくと、コンディションの悪い案件でも規律を保てる。合意可能な基準を先に作ることが、後戻りのコストを決定的に下げる。

プロジェクト健全性のモニタリングにはDORAメトリクスを素直に使うのが合理的だ³。目標値の一例として、デプロイ頻度は週1回以上、変更のリードタイムは1日〜1週間⁴、変更失敗率は0〜15%程度⁵、平均復旧時間は1時間〜1営業日を目安に置く。これらは「どう作るか」の指標に見えるが、実のところ「いつ価値を検証できるか」に直結する⁷。発注側がこの期待値を明示し、契約やSOWに組み込むと、ベンダー側の実装方針も健全な方向に収束しやすい。

契約モデルとガバナンス：アジャイルでも契約はアジャイルにしない

アジャイル開発を選ぶなら契約も流動的に、という誤解が根強い。しかし法的拘束力や支払い条件は安定していなければいけない。時間準拠（T&M：準委任）に成果マイルストーンを重ねるハイブリッド、または固定価格に変更予算（Change Budget）を明示する方式が、発注側の裁量と透明性のバランスを取りやすい。重要なのは、支払いを作業量ではなく検証可能な成果基準に紐付けることだ。例えば「P95（95パーセンタイル）レイテンシ200ms以下を本番相当で計測し、セキュリティ静的解析（SAST）で重大脆弱性ゼロ、ユーザーストーリーX〜YがUAT（User Acceptance Testing：受入テスト）合格」という組み合わせなら、客観性が担保される。

意思決定のボトルネックを防ぐには、RACI（責任分担マトリクス）と決定ログを用意し、スプリントレビューに発注側の意思決定者が必ず出る運用にする。会議体は少なく深く、スクラムに合わせて二週間ごとにレビュー、月次でステアリング、四半期でスコープ見直しが妥当だ。これだけでも、曖昧な期待と実装の乖離は目に見えて減る。

要件定義の実務：ビジネスの言葉をテスト可能な仕様に落とす

要件定義で最も大きな落とし穴は、言葉の粒度の揃っていない期待が仕様書に混在することだ。発注側がやるべきは、ビジネス成果をユーザー中心の振る舞いに変換し、さらにテスト可能な事実に落とす翻訳作業である。MoSCoW（Must/Should/Could/Won’t）やWSJF（Weighted Shortest Job First）のようなプライオリティ付け手法を使い、依存関係を可視化する。ここで品質やセキュリティ、可用性といった非機能要件も同じテーブルに並べ、単に「速い」「安全」ではなく、計測の条件と数値の閾値を前もって決める。テスト可能でない要件は要件ではないと心得ると、文書の質が一段上がる。

ユーザーストーリーと受入基準：振る舞いで語る

ユーザーストーリーは短い一文で済ませがちだが、受入基準までをワンセットとして扱うと検収が格段にスムーズになる。Gherkinで書くと、振る舞い、条件、期待結果が判定しやすい。

Feature: 注文確定
  Scenario: 在庫がある商品の注文
    Given カートに在庫10のSKU Aを1個入れている
    When 注文を確定する
    Then 注文が作成され、在庫が1減り、ユーザーに確認メールが送信される
    And P95レスポンスが200ms以下である

この程度の具体性があれば、実装側の解釈の自由度は適切に制限され、テストや検収の議論も建設的になる。性能やセキュリティの観点も受入基準に同居させると、後工程での手戻りが目に見えて減る。

APIファーストの仕様化：OpenAPIを契約に近づける

システム間連携が絡むなら、API仕様は会話ではなくアーティファクトとして固定する。OpenAPIを中心に、スキーマ、エラーモデル、スロットリング、認可方式までを書く。

openapi: 3.0.3
info:
  title: Orders API
  version: 1.0.0
paths:
  /orders:
    post:
      summary: Create new order
      security: [{ bearerAuth: [] }]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewOrder'
      responses:
        '201':
          description: Created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'
        '429': { description: Too Many Requests }
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
  schemas:
    NewOrder:
      type: object
      required: [items]
      properties:
        items:
          type: array
          items: { $ref: '#/components/schemas/Item' }

モックサーバーと契約テストを並走させ、ブレーク変更はバージョニングと移行期間の規約でコントロールする。仕様がコードと一体化すれば、進捗は無用な会議ではなくパイプラインの結果で示せる。

非機能要件（NFR）：SLOと計測条件をセットで記す

非機能要件は数値だけでは意味がない。どのような負荷で、どのような環境で、どのように計測するかまで書くことで、検収可能になる。例えば、P95レイテンシ200ms以下（本番相当のデータ量、同時接続500、TLS有効、WAF有効、CDNキャッシュミス時）、可用性SLO（Service Level Objective）99.9%（月間、計画停止除外ルール明記）、変更失敗率15%未満（四半期、重大度定義あり）といった形だ。こうした定義はSOWと受入基準に重複して記し、品質を契約上の成果に昇格させる。

実装・品質・リスク管理：パイプラインに真実を語らせる

健全なプロジェクトほど、真実は会議室ではなくCI/CDが語る⁶⁷。ビルド、テスト、静的解析、セキュリティ検査、デプロイ、リリース判定までを自動化し、可視化された基準で進む。人は良かれと思って例外を許すが、パイプラインは例外を許さない。ここでの要は、発注側がパイプラインの合格基準とダッシュボードを握ることだ。

CI/CDの合格条件：DoDをコード化する

Definition of Done（DoD）は文書だけでなく、パイプラインの条件として実装する。ユニットテストと統合テストの合格、ステートメントカバレッジ80%（クリティカル部分は90%）、SAST/DAST（静的/動的解析）の重大脆弱性ゼロ、依存ライブラリの既知脆弱性は高以下ゼロ、ライセンス違反ゼロ、OpenAPI契約テスト合格、パフォーマンステストの閾値達成、リリースノートと運用Runbookの更新完了、といった基準を引き金にする⁶⁷。

# GitHub Actions の一例
name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm run lint && npm test -- --coverage --watch=false
      - run: npm run snyk:test
      - run: npm run oas:validate && npm run contract:test
      - run: npm run perf:smoke

このような合格条件を可視化することで、議論は「頑張ります」から「どの条件が落ちていますか」に変わる。DORAメトリクスの基礎と併せてダッシュボード化すれば、進捗は毎日測れる³。

変更管理：速く変えるために、変え方を固定する

スコープ変更は悪ではない。真に悪いのは、変更の経路が定義されていないことだ。変更要求（ECR）は課題管理に記録し、影響評価はエンジニアリング、プロダクト、オペレーションの三者の観点で短文のインパクトノートにまとめる。週次のトリアージで優先度と費用見積もりを合意し、承認済みの変更だけがバックログに入る運用にする。アジャイルを理由に口頭合意を積み上げると、四半期末に辻褄合わせの大規模リスケが待っている。深呼吸して、アジャイルにおけるスコープ変更管理の原則に立ち返るのがよい。

セキュリティと法務：ランタイムまで含めて契約する

セキュリティは「やる」ではなく「どこまでを、何で証明するか」で語る。SAST/DASTと依存脆弱性スキャン、コンテナ署名とSBOM（Software Bill of Materials）、秘密情報の管理、脅威モデリングの実施有無など、証跡の種類を先に決めると対話が早い。法務面では、データの所在（リージョン）、ログの保持期間、個人データ処理の範囲、ソースコードの知的財産権とライセンス、第三者コンポーネントの遵守をSOWに入れる。実務上は、セキュアなランタイム構成の責任境界（例：ベンダーはアプリ、発注側はクラウド基盤）を図示して合意するのが効く。

受入・納品・運用移行：検収はイベントではなくプロセス

納品は一度のイベントだが、検収は準備の積み重ねだ。UATに至るまでに、ステージングでのパフォーマンス条件、セキュリティ診断の是正、運用Runbookの整備、監視・アラートのしきい値設定、オンコール体制の合意が済んでいることが望ましい。ここまでが合格しない限り、UATでの不合格率は高止まりし、現場は疲弊する。受入計画をスプリント計画と並走させ、リリース候補ごとに小さく通す設計にするのが最善だ。

SOWと検収の具体化：支払いを事実に結びつける

支払いマイルストーンを作業の完了宣言ではなく、検証済みの事実に繋ぐと、プロジェクトは安定する。簡単なSOW条項の例を示す。

Milestone M2: API機能リリース候補
- 成果物: /orders のPOST, GET, 認可（OAuth2）
- 受入基準: UATでのシナリオ10件合格、P95 < 200ms（条件X）、SAST重大0、DAST高以上0
- 証跡: CI/CDログ、UATレポート、性能テストレポート、SBOM、Runbook v1.2
- 支払い条件: 受入基準達成後10営業日以内に請求可

ここまで書けば、議論は早い。さらに、受入テストの観点を発注側が所有し、ケースの優先度やデータの準備責任を明確にする。運用移行では監視項目とアラート閾値、エスカレーション、バックアップと復旧演習の結果をセットで合意する。

決定の記録：ADRとRAIDログで後戻りを減らす

議論の末に決めたことは、必ず残す。アーキテクチャ決定記録（ADR）は、後から参加したメンバーへの最速の説明責任になる。ひな形は簡素でよい。

# ADR-001: 認証方式をOAuth2に統一
Context: 複数のクライアント、将来のB2B連携、監査要件
Decision: Authorization Code with PKCE を採用、IdPはXXXを使用
Consequences: 実装コスト増だが、委任とスコープ管理が容易。モバイルとの整合性良好
Alternatives: Cookieベースセッション、APIキー、mTLS（保守性の観点で不採用）

RAID（Risks, Assumptions, Issues, Dependencies）ログは、課題の沼を設計図に変える。重大リスクと前提は週次で確認し、依存関係の遅延がクリティカルパスに触れた瞬間に、スコープやリソースのリプランを提案できる状態を保つ。

データ移行とリリース戦略：切替の痛みを計画で減らす

ゼロダウンタイムや段階的リリースは簡単ではないが、計画で痛みを減らせる。スキーマの後方互換、デュアルライティング、リードレプリカを使ったバックフィル、フィーチャーフラグでの段階的展開、カナリアとロールバックの基準などを事前に定める。ここでも基準は具体的に、例えば「リリースから15分以内にエラーレートが0.5%を超えたら自動ロールバック」「ヘルスチェック3連続失敗でデプロイを停止」といったものだ。発注側がこれらの判断基準を握ることで、切替時の意思決定速度が上がり、障害の影響を抑えられる。

まとめ：発注側が握るべきは、判断の軸と測り方

要件定義から納品・運用移行までを通して、発注側がプロジェクトを健全に導く鍵は明快だ。価値を言語化し、受入を事実で定義し、その事実を自動で測る仕組みを持つこと。この三点が揃えば、ベンダーの違いによる成果のばらつきは小さくなる。逆に、曖昧な期待と口頭合意に頼るほど、後工程の痛みは増幅して戻ってくる。今日できる小さな一歩として、SOWと受入基準の雛形、CI/CDの合格条件、ADRとRAIDログのテンプレートを自社用に整備してみてほしい。どれも明日から使えるし、次の案件でも再利用できる資産になる。もし自社に合う型がまだ見つからないなら、自社のKPIとNFRに合わせて調整していこう。判断の軸と測り方を先に決めることで、プロジェクトは必ず軽く、速く、確かになる。次の案件では、何から手を付けますか。

参考文献

  1. McKinsey & Company. Delivering large-scale IT projects on time, on budget and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  2. Business Analyst Times. Project Failure Statistics (Standish CHAOS findings cited). https://www.batimes.com/tag/project-management/page/32/?Itemid=123&id=238&option=com_content&task=view
  3. 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
  4. Atlassian. DevOps metrics – Lead time for changes. https://www.atlassian.com/devops/frameworks/devops-metrics#:~:text=Lead%20time%20for%20changes
  5. Atlassian. DevOps metrics – Change failure rate. https://www.atlassian.com/devops/frameworks/devops-metrics#:~:text=Change%20failure%20rate
  6. Atlassian. Continuous delivery pipeline: principles. https://www.atlassian.com/continuous-delivery/principles/pipeline
  7. Forsgren, N., Humble, J., Kim, G. DevOps Metrics. Communications of the ACM, 2018. https://cacmb4.acm.org/magazines/2018/4/226366-devops-metrics/fulltext