LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

要件定義と設計工程の違い——何を決めるフェーズか

基本設計・詳細設計の外注とは、システム開発のライフサイクルにおける「設計工程」を外部パートナーに委託し、発注側の業務要件を具体的なシステム仕様へ変換してもらう取り組みです。

要件定義は「何を作るか」を発注側と開発側が合意するフェーズです。一方、設計工程はその合意を「どのように作るか」の仕様書に落とし込むフェーズです。両者は担当するアウトプットがまったく異なります。

IPA（情報処理推進機構）は「ユーザのための要件定義ガイド 第2版」（2019年）の中で、要件定義をビジネス要求定義（BR）・システム化要求定義（SR）・要件定義マネジメント（RM）の3つに整理しています^*1。設計工程はこのBR・SRで確定した要件を受け取り、開発可能な仕様書群へ変換する役割を担います。

外注を検討するうえで重要なのは、「要件定義は完了しているか」という確認です。設計会社は与えられた要件をもとに仕様を具体化しますが、要件そのものが曖昧なままでは仕様も曖昧になります。要件定義未了のまま設計を委託すると、その後の全工程に影響が及びます。

基本設計・詳細設計の成果物と外部/内部設計の区分

設計工程は大きく「基本設計（外部設計）」と「詳細設計（内部設計）」の2段階で構成されます。ソフトウェアライフサイクルプロセスの国際規格はJIS X 0160として標準化されており、IPAはこれをもとに日本の開発慣行を補ったガイド「共通フレーム」を提供しています。これらが日本の受託開発で広く参照されるプロセスの枠組みです^*2。

基本設計（外部設計）が決めること

基本設計は、ユーザーから見たシステムの外部仕様を定めるフェーズです。「どんな画面があるか」「どんなデータを入出力するか」「外部システムとどう連携するか」を可視化します。主な成果物は次の通りです。

• 基本設計書（システム方式設計書）
• 画面一覧・画面遷移図・画面レイアウト
• 機能一覧・機能仕様書
• 外部インターフェース仕様書（他システム連携定義）
• データ項目定義書（論理データモデル）
• 帳票レイアウト・出力仕様書

このフェーズのレビューでは、発注側（ユーザー部門）が「業務の流れと画面・機能が整合しているか」を判断できます。発注側の業務知識が直接試されるレビューポイントです。

詳細設計（内部設計）が決めること

詳細設計は、開発者が実装に使う内部仕様を定めるフェーズです。基本設計で定めた機能をプログラムのモジュール・クラス・処理ロジックに分解します。主な成果物は以下です。

• 詳細設計書（モジュール設計書・プログラム仕様書）
• クラス図・シーケンス図・フローチャート
• DB物理設計書（テーブル定義書・ER図）
• API仕様書（エンドポイント・リクエスト/レスポンス定義）
• エラー処理設計書・ログ設計書

詳細設計のレビューは技術的な内容が中心になるため、発注側が直接確認できる範囲は限られます。このフェーズではレビュー観点を事前に合意し、技術担当者や第三者レビュアーを関与させることが大切です。

設計工程を外注する際の進め方と体制

設計工程の外注を進める際は、「RFP（提案依頼書）の作成→ベンダー選定→キックオフ→設計作業→レビュー→成果物検収」というステップで進めます。各ステップで発注側が担う役割を理解しておくことが大切です。

ステップ1：RFPに要件と制約条件を明記する

RFP（Request For Proposal）には、要件定義書・業務フロー図・既存システム仕様書を添付します。設計の前提となる情報が不足していると、ベンダーは不確実性を見込んで見積もりを高く提示するか、仕様を誤認識したまま設計を進めます。

技術的制約（使用言語・フレームワーク・インフラ構成）と業務上の制約（業法への対応・既存ユーザーインターフェースとの整合）はRFPに漏れなく明記します。制約が後から追加されるほど、修正コストは大きくなります。

ステップ2：ベンダー選定——設計専門会社かフルサービス会社か

設計工程を外注するベンダーは大きく2種類に分かれます。「設計専門のコンサル・SI会社」と「設計から開発・保守まで一貫対応するフルサービス会社」です。

設計のみを切り出して専門会社に委託すると、設計品質は高まりやすい反面、後続の開発ベンダーへの引き継ぎで情報断絶が起こるリスクがあります。設計から開発を一貫して委託する場合は、設計書の流用性と開発工程への接続を事前に確認します。

ステップ3：キックオフで合意すべき4項目

プロジェクトのキックオフでは次の4項目を合意しておきます。これらが未定義のまま設計が始まると、後工程での認識齟齬が発生します。

• 成果物の定義と数量：どの設計書を何部納品するか
• レビュー頻度と参加者：週次か隔週か、発注側は誰が参加するか
• 変更管理ルール：要件追加・変更が発生した場合の対応手順
• 検収基準：どの状態になれば成果物を承認するか

体制——発注側に必要な役割

設計工程を外注する場合でも、発注側には最低限3つの役割が必要です。業務要件の意思決定ができるPM（プロジェクトマネージャー）、レビューで業務仕様の正確性を確認できるドメインエキスパート（業務担当者）、そして技術的な成果物を判断できる技術担当者です。

発注側の体制が整っていない場合、ベンダーからの質問に回答できず設計作業が止まります。設計工程の期間中は週に数時間のリソースを確保しておくことを推奨します。

発注側が用意すべき情報と検収ポイント

設計工程をスムーズに委託するには、発注側が事前に準備すべき情報があります。これらが不足していると、設計会社は仮定を置いて設計を進めるため、後から発注側との認識ずれが顕在化します。

発注側が用意すべき5種類の情報

• 要件定義書：機能要件・非機能要件・業務フローが記載されたもの（完成版）
• 現行システム資料：既存システムがある場合は画面仕様・DB構造・API仕様
• 業務マニュアル・帳票サンプル：業務の具体的な入出力を示す資料
• 技術制約一覧：使用言語・フレームワーク・インフラ・セキュリティポリシー
• 非機能要件定義書：性能要件・可用性要件・セキュリティ要件の数値目標

非機能要件（性能・可用性・セキュリティ）は機能要件と同等の優先度で準備します。IPAが公開した「非機能要求グレード」（2018年度終了）は、非機能要件を体系的に整理するためのフレームワークとして広く参照されてきました^*3。非機能要件が曖昧なまま設計が完了すると、後工程で仕様追加が発生します。

基本設計の検収ポイント——発注側が確認すべき5点

1. 業務フローと画面遷移が対応しているか（業務の流れが画面設計に反映されているか）
2. 機能一覧が要件定義書の機能要件をすべてカバーしているか（漏れがないか）
3. 外部システムとの連携仕様が双方向で定義されているか（送信・受信・エラー時の動作）
4. ユーザー権限ごとの画面・機能アクセス制御が定義されているか
5. 帳票・ダウンロードデータの項目が業務要件と一致しているか

詳細設計の検収ポイント——技術担当者が確認すべき5点

1. モジュール分割が適切で単一責任の原則が守られているか
2. DB物理設計でインデックスが適切に設定されているか（性能要件との整合）
3. API仕様書でリクエスト/レスポンスの型定義・エラーコードが網羅されているか
4. バッチ処理・非同期処理の設計が性能要件を満たす構成になっているか
5. セキュリティ設計（認証・認可・入力検証・暗号化）がポリシーに準拠しているか

上流の曖昧さが招く手戻り——外注前に防ぐ3つの対策

設計工程の外注で発生する手戻りの多くは、「要件定義の曖昧さが設計フェーズで顕在化する」パターンです。ここでは手戻りを事前に防ぐための3つの対策を整理します。

対策1：要件定義書にユーザーストーリーとアクセプタンス基準を含める

「ユーザーが何を達成したいか」を記述するユーザーストーリーと、「どの状態であれば要件が満たされたか」を定義するアクセプタンス基準をセットで要件定義書に含めます。これにより設計会社は「なぜそのUIが必要か」「どの業務ケースに対応するか」を把握でき、仕様の誤解を減らせます。

対策2：設計開始前に「設計前レビュー」する

設計作業を開始する前に、発注側と受託側で要件定義書を一読するレビューセッションを設けます。このセッションで受託側が感じた疑問点・不明点を洗い出し、回答を要件定義書に反映します。

設計前レビューで疑問を解消しないまま設計を進めた場合、後から大幅な仕様変更が発生するリスクがあります。半日から1日程度のセッションを設けることで、後工程での修正コストを抑えられます。

対策3：中間レビューのゲートを設ける

基本設計の中間段階（機能一覧・画面一覧が揃った時点）で中間レビューします。設計書が完成してから全体レビューをすると、根本的な設計方針の修正が大規模な手戻りにつながります。中間ゲートを設けることで、修正の影響範囲を最小化できます。

手戻りが詳細設計フェーズ以降に持ち越されると、その修正コストは基本設計フェーズでの修正と比較して大きくなります。これはソフトウェア工学の分野でウォーターフォール型開発の特性として広く認識されている事実であり、「上流での品質確保」が外注コスト管理の中心的な課題となります。

委託範囲の切り方——基本設計のみ・詳細設計のみ・一括の比較

設計工程の外注には「基本設計のみ委託」「詳細設計のみ委託」「基本設計から詳細設計まで一括委託」の3パターンがあります。自社の状況に応じた選択が大切です。

設計と開発を別ベンダーに分ける場合の注意点

設計を一社に委託し、開発を別の会社に委託するマルチベンダー体制では、設計書の引き継ぎが重要な管理ポイントになります。開発ベンダーが設計書を読み取れない場合、独自解釈による実装が発生します。

引き継ぎにあたっては、設計書のフォーマット・用語定義・前提となる技術スタックを開発ベンダーと事前に合意しておきます。設計ベンダーと開発ベンダーのキックオフに発注側が立ち会う機会を設けることも有効です。

内製化する際のリスクと必要スキル

設計工程を内製化するには、システムアーキテクト・業務アナリスト・UXデザイナー・DB設計者など複数の専門スキルが必要です。いずれか一つのスキルが欠けると、その領域の設計品質が低下します。

内製体制で設計工程を完結させようとする場合、必要なスキルセットとその習得に要する時間を事前に見積もる必要があります。スキル不足のまま設計を進めると、開発フェーズで仕様の穴が発覚します。

LASSICの設計工程外注支援——元請として担う役割

LASSICは、元請（プライムベンダー）としてシステム開発の設計工程を一貫して担う体制を持っています。発注側が要件定義を完了させた段階から参画し、基本設計・詳細設計の成果物を作成します。

設計工程の外注支援では、以下の3点において発注側との協働を重視しています。

• 要件の棚卸しサポート：要件定義書に不明点・矛盾点がある場合、設計着手前に発注側と一緒に整理します
• 中間レビューの実施：機能一覧・画面一覧の段階で発注側レビューを欠かさず設け、手戻りを上流で防止します
• 開発工程への接続：設計工程完了後、開発フェーズへシームレスに引き継ぐ一貫体制を持ちます

設計工程の外注を検討されている場合は、どのフェーズからパートナーを関与させるかも含めて、まず相談されることをお勧めします。

まとめ：設計工程外注を成功させる3つの判断軸

本稿では、基本設計・詳細設計の外注における進め方・成果物・手戻り防止の観点を整理しました。要点を3つに集約すると次の通りです。

第一に、要件定義が完了しているかを確認することです。設計工程の外注は「要件が確定した状態からスタートする」のが前提であり、要件が曖昧なまま委託すると設計全体の品質が低下します。

第二に、委託範囲（基本設計のみ・詳細設計のみ・一括）を自社の内製能力と照らし合わせて決めることです。委託範囲の切り方によって、発注側に求められる能力と体制が変わります。

第三に、発注側の体制（PM・ドメインエキスパート・技術担当者）と検収基準を事前に整えることです。ベンダーへ設計を委託しても、発注側の関与なしに高品質な成果物は得られません。設計工程は「委託すれば完了」ではなく、発注側と受託側が協働して進めるプロセスです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」（2019年）
2. *2　出典：IPA（情報処理推進機構）「国際規格SLCP：システム＆ソフトウェアのライフサイクル・プロセス」（2024年）
3. *3　出典：IPA（情報処理推進機構）「システム構築の上流工程強化（非機能要求グレード）」（2018年度終了）

Tweet