LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

外部エンジニアが書いた基本設計書が届いたものの、分量が多くてどこから読めばよいか分からない。読んではみたが、承認してよいのか判断がつかない——。社外の技術者に開発を頼む現場でよく聞く悩みです。外部エンジニアの設計レビューとは、社外の技術者が作った設計書を、発注側が要件と照らし合わせて確かめ、指摘を返し、承認して確定させるまでの一連の作業を指します。

見る範囲と照らす資料を先に決めておけば、限られた時間でも要点を外さずにレビューできます。ただし、細かな部分の整合は作る側に確かめてもらう前提になります。本記事では、開発の現場を預かるマネージャーに向けて、技術レビューとの違い、レビューの対象、観点、要件定義書との突合、承認と記録、進み具合の数え方、つまずきやすい点を整理します。

外部エンジニアの設計レビューとは

設計書のレビューには、大きく2つの見方があります。1つは、設計の中身が技術的に妥当かを見る技術レビューです。処理方式やデータの持ち方、性能や障害への備えなどを確かめます。もう1つは、設計書が発注側の決めた要件を漏れなく、ずれなく反映しているかを見る設計レビューです。どちらも「レビュー」と呼ばれますが、見る人も照らす資料も違います。

外部エンジニアが設計を担う場合、技術レビューは作る側の中でも行われます。これに対して、要件と照らし合わせる設計レビューは、要件を決めた発注側でなければ行えません。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100）は、国の情報システムの設計について、発注側のプロジェクト推進組織が設計・開発事業者に設計の内容の報告を求め、確認したうえで「課題等の指摘又は指導を行う」流れを定めています。^*1 民間企業が従う決まりではありませんが、社外に設計を頼むときの手順を考える手がかりになります。

技術レビューを社外に頼むときの契約上の位置づけは、外部エンジニアの技術レビュー、契約で分ける検証と監査の違いで整理しています。

発注側が見るのは基本設計

デジタル庁の「実践ガイドブック」（DS-120）は、発注側が設計書をレビューする対象を、基本的に基本設計で作られた成果物としています。理由として挙げているのは、基本設計の成果物が、発注者側で用意した要件定義書と事業者の作る成果物との「界面になる」ことです。^*2 基本設計より後は、基本設計をもとに詳細設計や実装が進むため、その間の整合を確かめるのは基本的に作る側の責任範囲だとしています。

同じガイドブックは、基本設計を、発注者から示された要件を理解して実際のシステムの設計に落とし込む工程、つまり発注者と事業者のあいだのインタフェースになる工程と位置づけています。基本設計書は、テストのもとになる文書でもあり、保守・運用の段階では設計を変えるときの要になる文書でもあります。

設計書は分量が多く、すべてを念入りに読む時間は取りにくいものです。ガイドブックは、要点を押さえて対象を絞る工夫をしながら、内容を省かずにレビューするよう求めています。詳細設計を読まない代わりに、作る側の中で詳細設計と基本設計の整合をどう確かめたかを、報告として受け取っておくと把握しやすくなります。

基本設計書の構成を確かめる

中身を読む前に、まず目次を見ます。ガイドブックは基本設計書の構成例を示し、全体編、機能編、データ編といった全体の組み立てをまず確かめ、そのうえで観点が満たされているか、分かりやすい目次になっているかを確かめるよう勧めています。 構成例の一部は次のとおりです。

ガイドブックが特に留意する点として挙げているのは2つです。データと機能・処理のつながりを含めた全体を見渡せる文書になっているか。データに関する設計と定義が一か所に漏れなく書かれるようになっているか。 機能ごとの処理内容を読み始める前に、全体編とデータ編がそろっているかを確かめておくと、後で設計書どうしの整合を見るときの足場になります。

設計レビューの観点

ガイドブックは、レビューの観点として2つを示しています。1つ目は、設計書と要件定義書との整合性、そして設計書どうしの整合性が取れているか。2つ目は、テスト計画で確かめる内容と設計書の内容が合っているか、要件定義で示した内容がテスト計画で網羅されているかです。^*2 設計書だけを読むのではなく、要件定義書とテスト計画を横に並べて読むことになります。

標準ガイドラインは、設計の対象ごとに、発注側が何と照らして確かめるかを書き分けています。 まとめると次の表になります。

機能の設計では、作る側に「要件定義との整合性の確認結果」の報告まで求めている点が目を引きます。^*1 外部エンジニアに設計を頼むときも、設計書と一緒に、要件のどこをどう反映したかの説明を出してもらう形にしておけば、発注側のレビューはその確認から始められます。技術レビューで見る処理方式や構成の妥当性は、表の設計の準備と非機能の設計に当たり、社内で難しければここだけ別の外部エンジニアに頼む方法もあります。

要件定義書との突合

ガイドブックが「忘れがちな突合作業」として注意を促しているのが、要件定義書との照らし合わせです。設計書を確かめる段階では、それまでの設計会議で詰めた内容を思い出しながら読むことが中心になりがちで、会議の議題にならなかった内容を反映し忘れることがあるといいます。 当初の要件定義で決めた項目が漏れなく設計書に反映されているかを、レビューの大前提として確かめ直すよう求めています。

手段として挙げられているのが、要件と設計を対応づけた表（RTM：要件トレーサビリティマトリクス）です。表の左側に要件定義書の項目を要件の単位ですべて並べ、右側に設計書案の対応する部分があるかを確かめ、正しく反映されていれば「反映済」とします。要件から変えたものは、変えた理由をはっきりさせ、変えることをプロジェクトとして承認したかも確かめます。^*2

外部エンジニアが自分たちの管理ツールで突合をしているなら、その結果を見せてもらいます。ガイドブックも、作る側がツールで突合しているときは、発注側がその内容を確かめるよう書いています。 ただし「反映済」の欄を眺めるだけでは足りません。何件かを選んで設計書の該当ページを実際に開き、要件の文言どおりに書かれているかを確かめると、表が設計書の実態とずれていないかが分かります。

承認と記録の残し方

レビューの結果をどう確定させるかは、契約に書いておく事柄です。IPAと経済産業省の「情報システム・モデル取引・契約書」〈第二版〉は、外部設計書を作る工程について、発注側が作って受注者が支援する形（A案）と、受注者が作って納める形（B案）の2つの条文案を用意しています。 外部エンジニアが外部設計書を書いて納めるなら、B案の形が近くなります。

B案では、発注側は契約で定めた点検期間のうちに、外部設計書が確定した要件定義書と外部設計検討会での決定事項に適合しているか、論理的な誤りがないかを点検します。適合して誤りがないことを承認した証として、双方の責任者が外部設計書承認書に記名押印します。合わない部分や誤りが見つかれば、受注者が期限内に修正版を作り、発注側が改めて点検します。^*3

照らす相手の一つである外部設計検討会は、外部設計書を作るために必要な事項をはっきりさせたり、内容を確かめたりする場です。検討の結果は議事録に記録され、双方はその結果に拘束されるとされています。検討会で要件定義書の内容を変えようとして、作業期間や委託料などの条件を変える必要が出た場合は、契約の変更の手続によるとしています。^*3 標準ガイドラインも、認識の違いを防ぐため、発注側が議事録の正確性を確かめて修正する手順を、設計・開発の実施要領に盛り込むよう求めています。^*1

見落としやすいのが、点検期間の扱いです。B案では、点検期間のうちに発注側が書面で具体的な理由を示して異議を述べなければ、期間の満了をもって外部設計書を承認したものとみなされます。^*3 レビューが終わらないまま期間が過ぎれば、確かめていない設計書が確定することになります。点検期間は、設計書の分量とレビューに割ける人の時間から逆算して決めておきたいところです。実際の契約でどう定めるかは、契約書と社内の法務担当に確かめてください。

進み具合の数え方

レビューは、設計の進み具合を数える区切りにもなります。ガイドブックは、文書の進捗を計上するルールの例として、次のような段階を示しています。

0〜50%は作る側の担当者が作業に合わせて計上し、60%で作る側の中のレビューが終わり、70%でその指摘を反映し終えます。80%で発注側のレビューが終わり、90%で指摘を反映し終え、最後の段階は発注側の最終確認です。^*2 書き終わったかどうかと、発注側のレビューを通ったかどうかを分けて数えられます。ガイドブックは、こうしたルールがなく担当者の判断に委ねると「進捗率90%」のまま数週間が経つようなことになりかねないとしています。^*2

設計の工程で定点観測する値として、ガイドブックはスケジュールと生産性の予実のずれに加え、品質の状況（信頼度成長曲線など）で、適切なレビューが安定して行えているかを確かめるよう挙げています。レビューにかける時間の見積もり方は、設計レビューの工数、ページあたりの平均で見積もる落とし穴で扱っています。

つまずきやすい点

1つ目は、説明が分からないまま承認してしまうことです。設計の内容は専門的で、作る側の資料は発注側から見て分かりにくくなりがちです。ガイドブックは、分からないからといって説明をうのみにして判断したり、判断を遅らせたりしてはいけないとし、発注側が理解できるように丁寧な説明や資料のまとめ直しを求めるのが近道だとしています。^*2

2つ目は、その逆で、出し直しを求めすぎることです。同じ箇所は、説明や資料の出し直しを過度に求めると、進捗の遅れを引き起こす要因にも、関係の悪化の原因にもなると注意しています。指摘は、要件と合わない点、論理的な誤り、分からない点に分けて返すと、作る側も直すべきものと説明すべきものを区別できます。

3つ目は、変更が記録に残らないことです。レビューの途中で、要件そのものを変えたくなることがあります。標準ガイドラインは、設計・開発の実施要領に変更管理の手順を書き、変更の内容に応じて影響する範囲（要件定義や設計など）を判断するよう求めています。変えた理由と承認を記録に残しておけば、外部エンジニアが交代したあとも経緯をたどれます。

まとめ：設計レビューで確かめておきたい3つの点

外部エンジニアの設計を発注側がレビューするうえで、確かめておきたい点は3つです。第一に、発注側の設計レビューは基本設計の成果物を対象にし、要件定義書との整合と設計書どうしの整合を確かめること。第二に、要件定義書の項目を一覧にして設計書の対応箇所と突き合わせ、変えた要件は理由と承認を残すこと。第三に、承認の手順と点検期間を契約で決め、期間内に異議を述べなければ承認とみなされる形かを確かめておくことです。設計を任せる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」2026年6月12日（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。第3編第7章「設計・開発実施計画の策定」2)ア（コミュニケーション管理）・ク（変更管理）、「設計の実施・管理」1)〜6)を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（DS-120）」2026年6月12日（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf）。出典：第3編第7章 設計・開発のStep.2-2E（表7-5 基本設計書の構成例）、Step.3-1A・B（表7-6 工程別観測定量値と確認観点、表7-7 進捗計上ルールのサンプル）、Step.4-1A（レビューの観点、参考7-5 忘れがちな突合作業）を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：IPA・経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉」2025年4月8日更新（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：ソフトウェア開発委託基本モデル契約書の外部設計の条項（第19条・第21条・第22条のA案、B案の外部設計検討会と外部設計書の承認及び確定）と解説、参考文書8（外部設計書承認書）を参照（確認日2026年10月2日）（2026年10月確認）

Tweet