LASSIC Media らしくメディア

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

基本設計をフリーランスのエンジニアに頼むことにしたものの、着手の日に何を渡せばよいのか、納品のときに何がそろっていれば受け取ってよいのかが決まっていない——。上流工程を社外の専門人材と進める現場では、こうした迷いが起こりがちです。上流工程の基本設計とは、要件定義で決めた内容をもとに、画面や帳票のように使う人が見て分かる形へシステムを具体化する工程を指します。

渡すものと受け取るものを先に決めておけば、着手してから資料を探し回ったり、納品の後に足りない設計に気づいたりする手戻りを減らせます。ただし、書き方のルールを決めることや、関係者と合意することは、発注する側の仕事として残ります。本記事では、デジタル庁の標準ガイドラインとその解説書をもとに、基本設計の範囲、着手前に渡すもの、書き方のルール、受け取る設計の中身、社内で合意する場面、指摘と修正の記録の残し方を整理します。

上流工程の基本設計とは

手がかりにするのは、デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100）です。2026年6月12日にデジタル社会推進会議幹事会が決定した、国の情報システムの整備と管理のルールを定めた文書です。民間企業が従う義務はありませんが、発注する側が設計の工程で何をするのかが順に書かれています。設計の進め方について、ガイドラインは「画面、帳票等の利用者にとって直接的に理解することができる基本設計を行った後に、機能を実現するための詳細設計を行う」としています。^*1 基本設計は、使う人が見て確かめられる形を決める段階だと言えます。

あわせて公表されている解説書（DS-110）は、発注する側がまとめた要件定義をもとに、設計を担う事業者がその内容を理解したうえで設計するのが一般的だとしています。そのうえで、発注する側は設計の報告を受け、要件定義の全ての内容が意図したとおりに反映されているかを基本的な観点として確かめるとしています。^*2 基本設計を社外の人に頼んでも、要件定義と照らし合わせる役は頼む側に残るということです。

なお、ガイドラインのこの章はウォータフォール型の開発に合わせて書かれていて、アジャイルを選んだ場合は同じ作業が繰り返し起こるものとして読み替えるとしています。以下も、要件定義の後に基本設計をまとめて行う進め方を前提にします。

フリーランスに任せる範囲

フリーランス活用で基本設計を頼むとき、相手に書いてもらうのは設計の文書です。画面の構成と項目、帳票の様式、データの項目、外部のシステムとのやり取り、夜間などにまとめて動かす処理（バッチ）の設計がこれに当たります。使う技術の選び方について提案を受けるのも、相手の経験が生きるところです。

一方、社内に残るのは、設計の中身が要件定義に合っているかを確かめる役と、ほかの部署や関係者と調整して決める役です。解説書は、設計を具体化するなかで他の関係者に影響しそうな事項が分かったときに、その内容を関係者に共有し、対処を決め、合意することを求めています。^*2 業務部門や他のシステムの担当者と話す場を設けるのは頼む側なので、調整の窓口は社内の担当者が持っておくと進めやすくなります。

この線引きは、着手の前に相手と言葉で確かめておきます。書く人、決める人、確かめる人が分かっていれば、相手も迷ったときに誰へ聞けばよいかが分かります。

着手前に渡すもの

まず渡すのは、確定した要件定義書です。ガイドラインは、設計・開発の工程に入る前に、要件定義の内容についての認識の食い違いを防ぎ、決まっていない事項への対応方針を決めるため、関係者と内容を確かめて調整したうえで要件定義を確定するとしています。^*1 未確定の項目が残っているなら、どれが未確定で、いつまでに誰が決めるのかを一覧にして一緒に渡します。

次に、いまの業務とシステムで扱っているデータです。解説書は、データの設計にあたって、現状の把握と分析の段階で集めた内容を、集めた後に変更があれば最新の内容にして事業者に渡し、確認を求めるとしています。^*2 既存のシステムがあるなら、項目の一覧と実際のデータの例があると、データの移行も見すえた設計を進めやすくなります。

3つ目は、システムの全体の形についての決定です。解説書は、設計の準備で求める「システム方式の設計」を、要件定義で考えた全体構成の案について、事業者の提案を踏まえて使う技術を決め、システムの構成を確定することだとしています。クラウドのサービスや既存の製品をすでに決めているなら、その前提を最初に伝えます。決めていないなら、提案を受けて社内で決める日を予定に入れておきます。

環境の予定も抜けやすいところです。解説書は、各種環境に係る計画を、いつどの環境が必要か、誰がいつ環境を構築するか、誰がどの環境を利用するかを計画することだとしています。^*2 フリーランスに検証用の環境を使ってもらうなら、その準備を社内で誰がいつ行うかも、ここで決めておきます。

最初に決める書き方のルール

設計書の書き方は、相手に任せきりにせず、着手のときに決めます。解説書は、設計の記述が過度に特定の技術に依存せず、一貫性を持ち、第三者が客観的に理解できるものになるよう、設計の記述要領を定めて徹底することを求めるとしています。目的は、開発やテストの効率を上げることと、将来の改修や更改のときに特定の事業者に縛られないことです。^*2

フリーランスに頼む場合、この点はとくに効いてきます。契約が終わった後に設計書を読むのは、社内の担当者か、次に加わる別の人だからです。解説書も、設計・開発の成果物は運用と保守の工程でも参照されるため、第三者でも理解できるよう、標準的な技術用語を用いて作る必要があるとしています。用語の一覧、図の書き方、画面や項目の番号の振り方を着手してすぐにそろえておくと、後から読む人にも分かる設計書になります。

基本設計書そのものの形について、解説書は、システムの保守の中心となる文書であるとして、データに関する設計と定義を1か所にまとめて書き、機能や処理のつながりを含めて全体を見渡せる内容にするよう求めています。^*2 画面ごとの設計書を積み上げるだけでなく、全体の構成とデータの定義をまとめた文書があるかを確かめます。

書き方が守られているかは、早めに見ます。解説書は、設計の前か、設計を始めて早い段階で、記載要領を確かめたり、先にできた設計の内容を確かめたりすることが望ましいとしています。最初の画面1つ分の設計書ができた時点で読み合わせれば、残りの設計書に同じ直しを広げずに済みます。

受け取る設計の中身

ガイドラインは、機能の設計として、要件定義の機能要件を具体化・詳細化した画面、帳票、データ、外部インタフェース、バッチ等に関する設計の内容とともに、「要件定義との整合性の確認結果」の報告を求めるとしています。^*1 受け取るのは設計書だけではありません。要件のどの項目を、どの設計で満たしたのかを示した対応の表も、あわせて受け取ります。

データの設計について、解説書は、システムが格納するデータの種類、形式、構造、項目、権限等を具体化することだと説明しています。^*2 項目の一覧に加えて、誰がどのデータを見られ、変えられるのかまで書かれているかを確かめます。

非機能の面では、要件定義の非機能要件をもとにした、クラウドのサービスやミドルウェアなどの構成と設定の設計が対象です。さらに、ガイドラインは、設計の対象に移行・運用・保守の設計と教育の計画を含めるとしています。解説書によれば、機能と非機能の設計と並行して移行・運用・保守の設計を進めるのは、システムを動かすのに要る作業や機能を漏れなく考えるためです。基本設計を頼む範囲にこれらを含めるかどうかは、着手前に決めておきます。

社内で合意する場面

基本設計を進めると、要件定義の段階では見えなかったことが出てきます。解説書は、設計内容の合意が必要になる場合の例として、次の6つを挙げています。^*2

6つ目は国の機関に特有の場面ですが、残る5つは民間のシステムでも起こります。どれも、フリーランス本人だけでは決められず、業務部門や他のシステムの担当者の判断が要るものです。解説書は、調整が遅れると活動に大きな影響を与えることが多いため、判明し次第、できる限り早い段階で関係者と共有し、対処を合意することが重要だとしています。

このため、合意が要る事項に当たったら、相手が作業を止めて待つのではなく、決める人と期限を書いて社内に上げる流れを先に決めておきます。週に1回の打ち合わせで未決の事項をまとめて確かめる形にしておけば、判断待ちが積み上がっていくのを早く見つけられます。

指摘と修正の記録

設計書を読んで直してほしい点が見つかったときの扱いも、解説書に書かれています。提出された内容に不備、不足、過剰、不一致又は矛盾がある事項を課題として整理し、課題の箇所と指摘の内容を明らかにした管理表にまとめて伝えるとしています。^*2

直し方は、受けた側が決めて終わりにはしません。解説書は、事業者が対応方針を検討して修正の箇所と内容を提案し、発注する側と合意したうえで直すとしています。さらに、修正の前後を記録し、修正の理由や、直さなかった箇所の理由を残すことで、後の工程で疑問が出たときの判断の材料にするとしています。

フリーランスとの間でこれを形にするなら、指摘の一覧に「指摘」「対応の案」「合意した日」「直したか、直さないならその理由」の欄を作り、双方が同じ一覧を更新します。契約が終わった後に「なぜこの画面はこうなっているのか」と聞かれても、一覧をたどれば答えられます。なお、指摘から要件そのものの見直しが要ると分かったときは、解説書は、その見直しを変更管理の対象として扱うとしています。

外部に委託するときに確認しておきたい点

フリーランス活用で上流工程の基本設計を頼む前に、渡す資料の一覧、書き方のルール、受け取るものの一覧、合意が要る事項の上げ方を1枚にまとめておきます。候補者には、画面や帳票の設計書を書いた経験に加えて、要件との対応の表を作ったことがあるか、移行や運用の設計まで担ったことがあるかを聞くと、頼む範囲と経験が合っているかを判断しやすくなります。

上流工程で発注する側に残る責任はフリーランス活用で上流工程を任せるとき、発注側に残る責任とはで扱っています。

基本設計の前の段階はフリーランス活用で上流工程の業務要件整理、書き出す8つの項目にまとめました。

受け取った設計書のレビューにかかる工数は設計レビューの工数、ページあたりの平均で見積もる落とし穴で整理しています。

まとめ：基本設計で確かめておきたい3つの点

フリーランス活用で上流工程の基本設計を頼むうえで、確かめておきたい点は3つに整理できます。第一に、確定した要件定義書と未確定の事項の一覧、いまのデータ、システムの全体構成の決定を着手前に渡すこと。第二に、設計書の書き方のルールを着手のときに決め、納品では設計とあわせて要件定義との整合性の確認結果を受け取ること。第三に、合意が要る事項を社内で早く決め、指摘と修正の理由を一覧に残すことです。この3点を踏まえておけば、「設計書は届いたが、要件のどれが入っていないのか誰にも分からない」という事態を避けやすくなります。基本設計を書ける人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（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年（令和8年）6月12日 デジタル社会推進会議幹事会決定。第3編第7章の冒頭（ウォータフォール型を前提にした記載とアジャイルの読み替え）、2.「設計・開発工程に入る前の要件定義の内容の調整・確定」、4.「設計の実施・管理」の本文と1)設計の準備・2)機能の設計・3)非機能の設計を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：2026年（令和8年）6月12日 デジタル庁。第7章1.の解説(1)の記載事項の表（エ 成果物に関する事項）、4.「設計の実施・管理」の趣旨と解説(1)(2)(4)(5)(6)(7)(8)を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：デジタル庁「標準ガイドライン群」（https://www.digital.go.jp/resources/standard_guidelines）。DS-100とDS-110の現行版として上記のファイルが案内されていることの確認として（確認日2026年10月2日）（2026年10月確認）

Tweet