• ノウハウ
  • |Remogu(リモグ)" />

    【案件の立ち上げ】要件定義で決まる前提と、確かめておく項目を解説

    監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

    「要件定義で決まる範囲」を示す図です。作る/決める/残すを並べています。強調しているのは決めるです。ここが本体と添えています。

    📘 この記事でわかること

    • 立ち上げ時に明示される検査完了の期日や報酬条件が、後にどこまでの作業を担うかの基準になること
    • 現行システムへの対策や画面・帳票の見直しが、確認する文書に新しく加わっていること
    • 品質を優先し文書中心で進む現場の前提と、契約時に確かめておきたい項目をあわせて整理

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

    リモートワーク案件特化のエージェント|Remogu(株式会社LASSIC運営) リモートの案件を探す フルリモートの案件を見る

    1. 最初の物差しとなる明示項目

    起点となる検査完了の期日と報酬の支払期日

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

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

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

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

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

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

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

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

    図1:要件定義で決まる範囲
    図1:要件定義で決まる範囲 明示される項目 検査を完了する期日 報酬の額と支払期日 立ち上げ時に示される 後で負う範囲 検査の基準 支払いの流れ 立ち上げの内容がもと 立ち上げの内容が基準

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

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

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

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

    では、対象となるシステムの状態によって、この明示される項目にどのような内容が加わるのでしょうか。

    2. 追記された現行システムへの対策

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

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

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

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

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

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

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

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

    では、同じ基本方針に追記されたもう一つの項目、画面や帳票の見直しは何を示すのでしょうか。

    3. 項目に加わった画面や帳票の見直し

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

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

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

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

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

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

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

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

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

    図2:文書に残る決めごと
    図2:文書に残る決めごと 基本方針に追記された項目 現行システムへの対策 複雑化した現行システムへの対策を追記 画面や帳票の見直し 画面や帳票の見直しについて追記

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

    4. 品質を最優先に置く利用企業側の前提

    品質を最優先に置く、システム利用企業側の姿勢

    IPAの調査では、システムを利用する側の企業が、品質を最も優先する事項として捉えていることが示されています3。品質は、出来上がったシステムの仕上がりに関わる事項です。

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

    品質が最優先という前提が分かっていれば、要件定義の打ち合わせで、確認の基準をどこまで細かく詰めるかを、委託元と話す手がかりになります。

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

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

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

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

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

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

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

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

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

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

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

    現場の前提を整理する

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

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

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

    6. 文書中心で進む要件と設計

    ドキュメント中心で進む要件定義と設計

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

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

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

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

    広がりが限られる、モジュール性やデータモデルを意識した設計

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

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

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

    図3:現場の進め方の前提
    図3:現場の進め方の前提 品質を最優先 利用企業側が捉える最優先事項 手法はウォーターフォールが主流 依然としてウォーターフォール型が主流 要件定義と設計は文書中心 ドキュメント中心の要件定義と設計

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

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

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

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

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

    契約の手間や、モデル契約への認知が十分でない状況があるため、要件定義の段階で確認する項目は、案件ごとに自分で確かめる必要があります。要件定義の内容が明確であれば、契約のたびに詰め直す箇所を絞れます。立ち上げの段階で確認事項をまとめておくことが、契約面の手間を減らすことにもつながります。

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

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

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

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

    図4:立ち上げで確かめる項目
    図4:立ち上げで確かめる項目 取引の手間が課題 手間や工数を課題に挙げる企業 モデル契約を知らない モデル契約を知らないとする企業 取引条件の明示義務違反に該当した割合 41.3% 取引条件の明示義務違反:1,126件(41.3%)

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

    8. よくある質問

    デジタル庁の基本方針には、どのような項目が追記されましたか

    長期間の改修で複雑になった現行システムへの対策が追記されました2。あわせて、画面や帳票の見直しについても追記されています2。

    モデル契約を知らない企業は、どのくらいありますか

    IPAの調査では、モデル契約そのものを知らないとする企業も多いことが示されています3。

    取引条件の明示義務違反は、どのくらい確認されていますか

    公正取引委員会の運用状況では、取引条件の明示義務違反が1,126件(41.3%)です4。

    リモートワーク案件をお探しの方へ

    Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。

    前提が読めれば範囲を置けます。リモートの案件を見てみてください。

    フルリモートの案件を見る30秒で無料登録

    会員登録無料 / 案件閲覧・相談は無料

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

    出典・参考情報

    *1 公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット(2026年7月・2026年10月確認)
    *2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策(2026年・2026年10月確認)
    *3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸(2025年4月・2026年10月確認)
    *4 公正取引委員会「令和7年度におけるフリーランス・事業者間取引適正化等法第2章の運用状況」2番目に多い違反(2026年6月・2026年10月確認)