受託する側として案件に関わるとき、最初の打ち合わせで何を確認しておくかが、後の作業量を左右します。要件定義の打ち合わせで交わした言葉は、そのまま後工程の基準になります。案件の立ち上げでどこまで詳しく決めておくかによって、途中で確認し直す手間や、追加の作業を負う範囲が変わってきます。立ち上げの段階で押さえておきたい視点を、公的な資料をもとに整理しました。確認しておきたい項目は限られていますが、抜けると後の作業に響きやすい内容です。

1. 明示される項目が最初の物差しになる

検査を完了する期日と、報酬の支払期日が起点になる

案件を立ち上げる打ち合わせでは、最初にいくつかの項目が明示されます。公正取引委員会が示す資料には、給付の内容を検査する場合、検査を完了する期日を明示する事項に含めるとあります¹。検査の期日が定まっていないと、成果物を確認する工程がいつまで続くのか見通しにくくなります。

報酬の額と支払期日も、同じ資料が明示する事項として挙げている項目です¹。金額そのものだけでなく、いつ支払われるかまで立ち上げの段階で共有されているかどうかが、その後の作業計画に関わってきます。

この2つの項目は、案件の規模や技術分野が変わっても土台になる部分です。打ち合わせの記録に残っているかどうかを、まず確かめておきたいところです。

確認する項目が増えるほど、打ち合わせの時間も長くなりがちです。それでも、検査を完了する期日と報酬の額・支払期日という2つの基本項目を立ち上げの段階で共有しておくことが、後の工程を滞りなく進めるための前提になります。

確認しておきたい2つの項目

ここまで見てきた検査完了の期日と、報酬の額および支払期日は、どちらも同じ資料が明示する事項として挙げている項目です¹。次の表に、それぞれの内容と、確認する視点を整理しました。

明示される項目	内容	確認する視点
検査を完了する期日1	成果物を検査し終える期限	検査の工程がいつまで続くか
報酬の額および支払期日1	報酬の金額と、支払われる期日	金額と入金のタイミングが明確か

表にある2つの項目が、そのまま契約書や発注書に記載されているかどうかを確認する視点になります。記載が見当たらない場合は、打ち合わせの時点で委託元に確認しておくと、後の認識のずれを防ぎやすくなります。

出典：公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット（2026年7月改訂）をもとに作成

口頭でなく、立ち上げの段階で残しておきたい理由

立ち上げの打ち合わせで交わした内容は、時間が経つと記憶があいまいになりやすいものです。口頭でのやり取りだけに頼ると、検査の期日や支払期日について、後から確認し直す手間が発生します。

議事録やメールなど、文書として残る形で共有しておくと、途中で認識がずれたときに立ち上げの時点まで戻って確認できます。これは、要件定義の進め方が後の作業範囲をそのまま決めるという性質と結びついています。

次の章では、対象となるシステムの状態によって、この明示される項目にどのような内容が加わるかを見ていきます。

2. 現行システムへの対策が追記されている

複雑化した現行システムへの対策という項目

システムを長く運用していると、部分的な改修が積み重なり、当初の構成から複雑になっていきます。デジタル庁が示す基本方針には、長期間の改修で複雑になった現行システムへの対策という項目が追記されています²。

新しく作るシステムよりも、改修を重ねたシステムの方が、現状の把握に時間がかかります。立ち上げの打ち合わせで、対象のシステムがどのくらいの期間、どのような改修を経てきたかを確認しておくと、後の作業量を見積もりやすくなります。

現行システムの複雑さは、外から見えにくい部分です。打ち合わせの早い段階で、委託元がどこまで現状を把握しているかを共有してもらえると、要件定義の進め方も変わってきます。

立ち上げの打ち合わせで確認しておきたいこと

確認しておきたいのは、現行システムの改修履歴が資料として残っているかどうかです。残っていない場合、要件定義の作業の中で調査にあたる時間が必要になることがあります。

現行システムの利用者側の担当者が、これまでの経緯をどこまで把握しているかも確認しておきたい点です。担当者が入れ替わっている案件では、過去の改修の背景が資料以外に残っていないこともあり、聞き取りに時間がかかる場合があります。

対策が追記された背景を踏まえると、現行システムへの対応は、新規に作るシステムの要件定義とは異なる進め方が求められる場面もあります。立ち上げの段階でこの違いを共有しておくと、後の工程で認識のずれが生まれにくくなります。

次の章では、同じ基本方針に追記されたもう一つの項目、画面や帳票の見直しについて見ていきます。

3. 画面や帳票の見直しも項目に入っている

画面や帳票の見直しという項目

デジタル庁が示す同じ基本方針には、画面や帳票の見直しについても追記されています³。システムの内部構造だけでなく、利用者が直接目にする部分も、要件定義で確認する対象に含まれているという内容です。

画面や帳票は、利用する側の業務の流れに直接関わる部分です。内部の仕組みを変えなくても、画面の見せ方や帳票の項目が変わるだけで、利用者の作業手順に影響することがあります。

この項目が追記されたことは、要件定義が内部の仕様だけでなく、利用者が触れる部分まで含めて確認する範囲に広がっていることを示しています。

利用者の目に触れる部分だからこそ確認したいこと

画面や帳票の見直しを担当する場合、現在の画面や帳票がどのような業務で使われているかを、立ち上げの段階で聞いておくと後の設計がしやすくなります。

利用者側の担当者に直接確認できる機会があるかどうかも、打ち合わせの中で聞いておきたい点です。確認できる機会が限られている場合、要件を固める工程に時間がかかることがあります。

画面や帳票が複数の部署にまたがって使われている案件では、確認する相手も一人に絞れないことがあります。誰にどの範囲を確認するかを、立ち上げの段階で整理しておくと、後になって確認のやり直しが発生する場面を避けやすくなります。

画面や帳票の見直しも含めて、要件定義で確認する項目がどこまで広がっているかを、立ち上げの時点でつかんでおくことが、後の作業範囲を見通す手がかりになります。

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」をもとに作成

4. 品質を最も優先する現場が多い

システムを利用する企業側が、品質を最優先に置いている

IPAの調査では、システムを利用する側の企業が、品質を最も優先する事項として捉えていることが示されています⁴。速さや費用よりも、出来上がったシステムが正しく動くかどうかを重く見ている現場が多いということです。

品質を優先する現場では、要件定義の段階で確認する内容も、それに応じて変わってきます。仕様の一つひとつが、後の検査でどう確かめられるかまで見据えて決められる場面が増えます。

速さより品質という前提が現場にあると分かっていれば、要件定義の打ち合わせで、確認の基準をどこまで細かく詰めるかについても、委託元と話しやすくなります。

品質を優先する現場で、要件定義に求められること

品質を優先する現場では、仕様を決めたあとの確認作業も重視されます。要件定義の段階で、何をもって完了とするかを具体的にすり合わせておくと、後の検査がスムーズに進みます。

逆に、品質の基準があいまいなまま進めると、検査の段階になって認識の違いが表面化しやすくなります。立ち上げの打ち合わせで、品質に関する期待値を確認しておくことが、後の確認のやり直しを減らす一歩になります。

品質を優先する現場ほど、検証や確認にかける時間も長くなる傾向があります。要件定義の段階から、どのような確認方法を想定しているかを聞いておくと、後の工程にかかる時間の見通しが立てやすくなります。

次の章では、この品質を優先する現場で、実際にどのような開発手法が使われているかを見ていきます。

5. 開発手法はいまもウォーターフォールが主流

依然としてウォーターフォール型の手法が主流

IPAの同じ調査からは、開発手法についても現場の傾向が読み取れます。依然としてウォーターフォール型の手法が主流であることが示されています⁵。工程を順番に進め、後戻りを前提としない進め方が、いまも多く使われているということです。

仕様を並行して調整するやり方よりも、順番に固めていくやり方が、いまも中心にあります。ウォーターフォール型の進め方では、要件定義の段階で決めた内容が、後の工程の前提になります。途中で仕様を大きく変えることが難しい進め方だからこそ、立ち上げの段階での確認が重みを持ちます。

ウォーターフォール型の進め方では、前の工程が終わってから次の工程に進むのが基本です。要件定義の工程がどこまで丁寧に行われるかが、設計や実装といった後続の工程の進みやすさにも関わってきます。

案件によっては、部分的に別の進め方を組み合わせている現場もありますが、要件定義を最初にまとめて固める進め方が中心にある点は、押さえておきたい前提です。

現場の前提を整理する

ここまで見てきた、品質を最優先に置く傾向と、ウォーターフォール型の手法が主流である傾向は、どちらもIPAの同じ調査から読み取れる、現場の前提です。次の表に整理しました。

観点	現場の傾向
優先する事項	品質を最も優先する事項として捉えている4
開発手法	依然としてウォーターフォール型の手法が主流5

この2つの傾向を踏まえると、要件定義の段階でどこまで具体的に決めておくかが、後の進め方に与える影響の大きさが見えてきます。

6. 要件と設計は文書中心で進んでいる

要件定義と設計は、いまもドキュメントを中心に進む

同じ調査では、要件定義と設計の進め方についても示されています。依然としてドキュメントを中心に要件定義と設計が行われていることが分かっています⁶。仕様を文書としてまとめ、それをもとに合意していく進め方が、いまも中心にあるということです。

文書を中心に進める現場では、要件定義の段階で作成した文書の中身が、そのまま後の設計や検査の基準になります。立ち上げの打ち合わせで、どのような形式の文書を残すかを確認しておくと、後の工程で参照しやすくなります。

議事録だけでなく、仕様書や確認事項をまとめた文書が、要件定義の成果物として位置づけられているかどうかも、確かめておきたい点です。

文書の形式は案件によってさまざまです。仕様書という名称でなくても、確認事項をまとめたメモやチェックリストが、実質的に要件定義の成果物として扱われている場合もあります。どのような形式であっても、記録として残っているかどうかが重要です。

モジュール性やデータモデルを意識した設計は、まだ広がっていない

一方で、モジュール性やデータモデルを意識した設計に取り組む企業は、特にシステムを利用する側を中心に、依然として少ないことが示されています⁷。部品として組み替えやすい設計や、データの持ち方を整理した設計が、まだ十分に広がっていないという内容です。

この傾向を踏まえると、要件定義の段階で、将来的な変更のしやすさまで話し合われる場面は、多いとは限りません。変更のしやすさを重視したい場合は、立ち上げの打ち合わせで、あらためて話題に出しておく価値があります。

文書を中心に進める前提と、設計の作り込みがまだ広がっていない前提を合わせて見ると、要件定義の段階で残した文書が、案件全体を通じてどれだけ大きな役割を持つかが分かります。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

7. 契約の手間と、確かめておく項目

取引の手間や、モデル契約の認知の状況

IPAの調査では、契約に関する課題も示されています。システム開発の契約では、取引ごとに手間や工数がかかる点を課題に挙げる企業が多いことが分かっています⁸。契約のたびに条件を一から詰め直す負担が、現場の課題として挙がっているということです。

契約に関する課題は、手間だけではありません。モデル契約そのものを知らないとする企業も多いことが、同じ調査から読み取れます⁹。契約の型が広く共有されていない状況が、取引ごとの手間につながっている面もうかがえます。

契約の手間や、モデル契約への認知が十分でない状況は、要件定義の段階で確認する項目が、案件によってばらつきやすい背景にもなっています。契約のたびに条件を詰め直す手間は、要件定義の内容が明確であるほど小さくなる傾向があります。立ち上げの段階で確認事項をまとめておくことが、契約面の手間を減らすことにもつながります。

立ち上げで確かめておきたい項目

ここまでの内容と、実際に確認された義務違反の状況をあわせて、立ち上げの段階で確かめておきたい項目を整理しました。

確かめる観点	内容
取引の手間	取引ごとに手間や工数がかかる点を課題に挙げる企業が多い8
契約の型への認知	モデル契約そのものを知らないとする企業も多い9
取引条件の明示義務違反	1,126件（41.3％）10

公正取引委員会の運用状況では、取引条件の明示義務違反が1,126件（41.3％）にのぼることも示されています¹⁰。立ち上げの段階で、この記事で挙げてきた項目が文書として残っているかどうかを確かめておくことが、後の手間を減らす手がかりになります。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）／公正取引委員会「令和7年度におけるフリーランス・事業者間取引適正化等法第2章の運用状況」（2026年6月）をもとに作成

初めて委託元と直接契約する案件でも、要件定義の段階から関わりますか

要件定義への関わり方は案件によって異なります。立ち上げの打ち合わせで、どこまでの範囲を担当するかを委託元と確認しておくと、この記事で挙げてきた項目とあわせて、後の作業の見通しが立てやすくなります。分からない点は打ち合わせの場で早めに聞いておくと、後の認識のずれを防ぎやすくなります。

経験がまだ少ない場合、要件定義の項目をどう確認すればよいですか

検査を完了する期日や、報酬の額と支払期日といった項目は¹、経験の量にかかわらず立ち上げの段階で確認できる内容です。まずはこの2つの項目が文書に残っているかどうかから確かめていくと、抜け漏れに気づきやすくなります。

副業として関わる場合も、確かめておく項目は変わりますか

確かめておきたい項目そのものは、稼働の形にかかわらず変わりません。時間の使い方については、打ち合わせの段階で委託元と直接話し合っておくと、要件定義の進め方とあわせて無理のない稼働計画が立てやすくなります。稼働の時間帯や連絡の取りやすさについても、立ち上げの段階で共有しておくと、要件定義以降のやり取りがスムーズになります。

地方に住みながらリモートで参画する場合、要件定義の打ち合わせはどう進みますか

Remoguは、案件の90%以上がフルリモート可能です。要件定義の打ち合わせも、画面越しのやり取りが中心になる案件が多く、地方に住みながら参画しているメンバーもいます。まずは登録して、自分の状況に合う案件があるかを確かめてみましょう。

契約前にモデル契約書の内容を知らなくても問題ありませんか

モデル契約そのものを知らないとする企業も多いことが、IPAの調査で示されています⁹。委託元の側も同じ状況にあることは珍しくないため、分からない点は打ち合わせの段階で一つずつ確認していく進め方で十分です。まずは登録して、自分の経験に近い案件の要件定義がどのように進むかを確かめてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット（2026年7月・2026年9月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年・2026年9月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」業務側の見直し（2026年・2026年9月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年9月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年9月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年9月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年9月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年9月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」相手の前提（2025年4月・2026年9月確認）
＊10 公正取引委員会「令和7年度におけるフリーランス・事業者間取引適正化等法第2章の運用状況」2番目に多い違反（2026年6月・2026年9月確認）