政府情報システムの要件仕様書に決まったフォーマットはあるのか？
結論
現在、すべての政府機関、すべての情報システム案件にそのまま適用できる単一の要件仕様書フォーマットは存在しません。各機関は、自らの規定、調達方式、システムの性質、プロジェクトの要件に応じて実際の内容を決める必要があります。
要件仕様書が本当に解決すべき問題は「どのテンプレートを使うか」ではなく、次の点です。
この文書は、機関と開発ベンダーがプロジェクト範囲について共通理解を築けるほど明確になっているか？
経済部水利署及び所属機関の現行「情報関連システム開発・保守注意事項」を例にとると、情報システムの開発・保守を、システム評価、要件・システム分析、システム設計、プログラム開発、システムテスト、教育訓練、システム稼働、システム保守の8つのライフサイクル段階に分け、要件仕様書、要件ヒアリング記録、設計仕様書、テスト計画書、テスト報告書などの参考フォーマットを提供しています。同規範の最終改正は2024年8月21日です。
ただしこれは経済部水利署及び所属機関の管理規範であり、すべての政府機関が同じフォーマットやプロセスを採用しなければならないと書くことはできません。
本当に参考にすべきなのは、その背後にある考え方です。
要件は孤立した入札文書ではなく、その後の設計・開発・テスト・稼働の出発点である、という点です。
なぜ要件は機能リストから始めてはいけないのか？
結論
「案件管理」「オンライン申請」「会員管理」は、システムにおおよそどの機能が必要かを示すだけで、本当の開発範囲を定めるには不十分です。
要件仕様に「オンライン申請機能を構築する」の一文しかないとします。業務の観点からは要件は十分明確に見えます。しかしシステム開発の観点では、まだ多くの問いに答えがありません。
- 申請者はログインが必要か？
- 本人確認はどの方法で行うか？
- どのデータと添付書類を入力する必要があるか？
- 送信後の案件は誰が受け付けるか？
- 上長の承認は必要か？
- データに誤りがある場合、差し戻しか、補正か？
- 補正後はどのプロセスに戻るか？
- 申請者は進捗を照会できるか？
- 審査結果はどの方法で通知するか？
- 担当者にはどのような統計とレポートが必要か？
これらは「オンライン申請」という機能名を変えるものではありませんが、システムの開発範囲に非常に大きな違いをもたらしえます。
したがって要件は「システムにどの機能が必要か」だけでなく、「誰が、どのような状況で、システムを通じてどの業務を完了する必要があり、完了後にどのような結果が生まれるのか」を問うべきです。
たとえば「システムは案件照会機能を提供する」とだけ書くのではなく、次のように具体化できます。担当者はログイン後、案件番号、申請者、申請日、案件ステータスで所属部門の案件を検索し、案件の基本情報と処理履歴を閲覧できる。
ここまで書いて初めて、開発チームはログイン、ロール権限、条件検索、案件データ、履歴記録といった、実際に開発が必要な内容を特定できます。
政府情報システムの要件仕様書では何を先に確認すべきか？
結論
政府情報システムの要件は、まず「目的、ロール、プロセス、機能、データ、連携、非機能要件、検収」の8つの観点から確認でき、重要なのは機能の数を追うことではなく、システムの境界を明確にすることです。
プロジェクトごとに規模と要求は異なりますが、システム開発の観点からは、少なくとも次の8つの観点を先に確認できます。
1. プロジェクトの目的
なぜこのシステムが必要なのか。現在の業務のやり方でどのような問題が起きているのか。構築後に何を改善したいのか。
たとえば本当の要件は「案件管理システムが必要」ではなく、現在の案件がメール、Excel、紙の間に散在しているため部門横断の照会が難しく、処理の進捗を把握できない、ということかもしれません。
2. 利用者とロール
誰がシステムを使うのか。市民、担当者、上長、システム管理者、他の機関はそれぞれどの業務を完了する必要があるのか。ロールごとに、どのデータを閲覧・修正・処理できるのか。
3. 業務プロセス
一つの業務は開始から完了までどのステップを経るのか。通常のプロセスに加えて、差し戻し、補正、取消、再申請、部門横断の処理などの例外にはどのようなものがあるのか。
4. 機能要件
各ロールはシステムを通じてそれぞれどの操作を完了する必要があるのか。機能はできる限り実際のプロセスに結びつけ、機能名を単独で列挙しないようにします。
5. データ要件
システムはどのデータを作成・照会・保存・インポート・エクスポート・交換する必要があるのか。既存データを新システムへ移行する必要はあるのか。
6. システム連携
既存のアカウント、データベース、他の政府情報システム、サードパーティAPIとの連携は必要か。データは誰が提供し、どの方法で交換するのか。
7. 非機能・セキュリティ要件
「何をするか」に加えて、利用量、性能、互換性、権限、セキュリティ、適用されるサイバーセキュリティ要件も考慮する必要があります。
8. テストと検収
重要な機能が完了するたびに、それが元の要件を満たしていることをどう確認するのか。どの条件を満たせばシステムを正式に納品できるのか。
| 確認項目 | 先に問うべきこと |
|---|---|
| プロジェクトの目的 | なぜこのシステムを構築するのか？いま最大の問題は何か？ |
| 利用者 | どのようなロールがあるか？各ロールは何ができるか？ |
| プロセス | 一つの業務は開始から完了までどう進むか？ |
| 機能 | 各プロセスにはどのシステム操作が必要か？ |
| データ | データはどこから来るか？何を保存・移行する必要があるか？ |
| 連携 | 既存システム、アカウント、APIとの連携は必要か？ |
| 制約 | 既存環境、セキュリティ、性能、互換性の要件は何か？ |
| 検収 | 最終的に要件が確かに実現されたことをどう証明するか？ |
この8項目は、すべての政府案件が法令上使わなければならない固定の章立てではなく、開発要件がすでに完全なシステム境界を形成しているかを確認するための整理手法です。
機能要件はどこまで細かく書くべきか？
結論
機能要件は、ベンダーが利用シナリオと開発範囲を理解できる程度に詳細であるべきですが、必要がない場合にまですべてのUI、技術アーキテクチャ、実装方法を先に指定し切るべきという意味ではありません。
たとえば「システムは権限管理機能を提供する」とだけ書いても、本当の作業量は見積もりにくいままです。さらに一歩進めて、一般担当者は所属部門の案件のみ照会・処理できる、部門長は所属部門の案件を閲覧し指定された承認を実行できる、システム管理者はアカウントとシステム設定を管理できる、と書けば、開発チームはロールとデータアクセスの関係を理解できます。
一方で、本当の要件がシステムに特定の機能と効果を実現させることだけなら、特定のプログラミング言語、データベース製品、パッケージを指定する必要があるかどうかは別途判断が必要です。
行政院公共工程委員会の「政府調達法第26条執行注意事項」は、不特定のベンダーが競争入札する技術仕様は、機関が機能・効果・特性などの面で必要とするものに限定すべきであり、競争制限にあたるかどうかは、その仕様が機関の本当の需要を超えているかで判断すべきだとしています。
したがって要件仕様の核心は「技術をどこまで細かく書けるか」ではなく、「どの条件が機関にとって本当に必要で、かつベンダーが知っておくべきものか」です。
市場にどのような適切な技術ソリューションがあるかまだ分からない場合、工程会の現行注意事項は、機関が技術仕様を定める際、関連する公開閲覧制度に基づいて処理する場合を除き、政府調達法第34条第1項に基づきベンダーに参考資料の提供を公開で求め、検討のうえ定めることができると明記しています。
これは、業務要件と技術ソリューションを、要件整理の初日に同時にすべて決める必要は必ずしもないことも意味します。
見落とされやすく、開発範囲に直接影響する要件とは？
結論
プロジェクトの見積もり、アーキテクチャ、スケジュールに本当に差を生むのは、多くの場合主要機能ではなく、データ、利用量、権限、連携、セキュリティ、既存環境です。
たとえば、どちらも「案件管理システム」と呼ばれる2つのシステムがあるとします。一方は内部の10名だけが使い、もう一方は多数の市民のオンライン申請と照会に対応する必要があります。機能名はよく似ていても、アカウント管理、トラフィック、システム容量、データセキュリティ、インフラの要件はまったく異なりうるのです。
データ移行も同様です。新システム稼働後に長年の過去案件を保持する必要があるなら、要件は「新しい案件システムを開発する」だけではなく、データの棚卸し、フォーマット整理、項目対応、データ変換、検証、新旧システムの切り替えも同時に扱う必要があります。
また、既存システムとの連携が必要な場合も、「システムはAPI連携を提供する」とだけ書くのではなく、次の点を確認する必要があります。
- どのシステムと連携するのか？
- インターフェースは誰が提供するのか？
- どのデータを交換するのか？
- どのくらいの頻度で交換するのか？
- 交換に失敗した場合はどう処理するのか？
- どのような権限とセキュリティ上の制約があるのか？
水利署の現行内部規範を例にとると、その要件仕様の注意項目には、データの年間増加量、主要およびピーク時の利用者数、ピーク時間帯、ネットワークトラフィック、サーバー容量、既存アプリケーションおよびサードパーティ製コンポーネントとの互換性、データ互換性、情報セキュリティ防護要件などの分析が含まれています。
これは、機能の数がシステム開発規模を判断する唯一の基準ではないことを改めて示しています。だからこそ、異なるベンダーが同じ要件を受け取ったのに大きく異なる価格を提示する場合、どこが高いかという話とは限らず、実はそれぞれ異なる開発範囲を見積もっている可能性があるのです。
なぜセキュリティも要件段階で確認すべきなのか？
政府情報システムにとって、セキュリティはシステム完成後に一度検査を補うものではありません。
現行の「サイバーセキュリティ管理法」第10条は、公務機関または特定非公務機関が適用範囲内で情報通信システムの構築・運用または情報通信サービスを外部委託する場合、適切な受託者を選任し、有効なサイバーセキュリティ管理体制の構築を求めてその実施を監督し、双方の権利義務と契約違反時の責任を書面の契約に明記しなければならないと定めています。
2026年1月7日に公布された現行の「サイバーセキュリティ責任等級区分弁法」第11条も、各機関が自ら開発または外部委託で開発する情報通信システムについて、附表9に基づき情報通信システムの防護要件の等級区分を完了し、附表10に定める防護基準に従って管理措置を実施しなければならないと定めています。
したがって、システムがログイン、権限、個人情報、機微情報、システム間のデータ交換に関わる場合、関連する要件はシステムアーキテクチャと開発方法に直接影響しえます。要件段階で早く確認するほど、後になってシステムの大幅な修正が必要だと分かるリスクを下げられます。
要件仕様はどのようにテストと検収までつながるのか？
結論
良い要件は「システムは何をするか」に答えるだけでなく、「最終的にそれが完成したことをどう証明するか」にも答えられるべきです。要件をテスト可能なシナリオに変換できるほど、その後の検収で共通基準を築きやすくなります。
要件に「市民は案件の処理進捗を照会できる」と書かれているとします。実際にテストに入ると、さらに次の点を確認できます。
- 市民は規定の方法で照会できるか？
- 異なる案件ステータスは正しく表示されるか？
- 権限のない人は案件を閲覧できないようになっているか？
- 案件が存在しない場合、システムはどう応答するか？
元の要件が曖昧な「案件照会を提供する」の一文だけで、検収段階になって初めてこれらの条件を議論し始めると、「機関はもともと含まれていると考えていた」と「ベンダーは元の要件にこの内容はなかったと考えていた」の間にギャップが生じやすくなります。
水利署の現行の情報システム開発・保守規範を例にとると、そのシステムテスト段階では、計画書、要件仕様、設計関連文書に基づいて機能テストを行い、テスト結果が要件仕様と設計の期待に合致しない場合はさらに対応することになっています。同様に、これは水利署及び所属機関の制度であり、すべての機関が統一的に採用する検収方法ではありませんが、システム開発の非常に重要な原則を示しています。要件、設計、テスト、検収は互いに切り離されるべきではない、ということです。
したがって、要件仕様が完成したら、項目ごとに次の点を確認できます。
- この要件は誰が使うのか？
- どの条件で発動するのか？
- 期待される結果は何か？
- 失敗や例外の場合はどう処理するのか？
- 最終的にどう検証するのか？
重要な要件が最後の問いに答えられないなら、通常はさらに明確化が必要だということです。
要件が次の段階に進める状態とは？
結論
要件は、すべての画面と技術的な詳細を決め切らなければ準備完了とみなせないわけではありません。より重要なのは、プロジェクトの問題、利用者、プロセス、データ、主要機能、制約条件、検収の方向性が十分に明確になっていることです。
まず次のいくつかの問いで判断できます。
要件はすでに理解可能か？
異なる人が要件を読んだとき、「このシステムは何を解決するのか」についておおむね一致した答えが得られるでしょうか。
システムの境界は形成されているか？
どの機能が本プロジェクトに属し、どれが外部システム、他部門、サードパーティサービスの協力を必要とするかが分かっているでしょうか。
主要プロセスは完全か？
通常のプロセスだけでなく、差し戻し、補正、取消、異常、権限不足の場合の処理も見え始めているでしょうか。
重要なデータは棚卸しされているか？
どのデータを作成・保存・移行・交換する必要があるかが分かっているでしょうか。
開発上の制約は開示されているか？
たとえば既存環境、デプロイ方法、情報セキュリティ、互換性、その他プロジェクトの必要条件です。
検収の方向性を説明できるか？
少なくとも、重要な機能が完了した後、どのシナリオで成果を確認する予定かを説明できるでしょうか。
これらの問いにおおむね答えられるなら、要件は「システムを作りたい」から「このシステムが主に何を解決するのかが分かっていて、どう作るかの評価に進める」段階へ前進しています。
逆に、いまはまだ「プロセスをデジタル化したい」「案件管理プラットフォームを作りたい」「オンライン申請を導入したい」といった方向性しかなくても、プロジェクトを始められないわけではありません。その場合はまず次のことを行うのが適切です。
- 01
現行プロセスの棚卸し
- 02
利用者・要件ヒアリング
- 03
データと既存環境の棚卸し
- 04
システム境界の整理
- 05
機能と技術の評価
そのうえで段階的に正式な開発要件を形にしていきます。
よくある質問
必ずしもそうではありません。現在、すべての政府情報システム案件に適用される「入札前にすべてのUI画面を完成させなければならない」という通則はありません。ワイヤーフレーム、フローチャート、画面イメージ、その他の文書が必要かどうかは、個別案件と機関の規定によって決まります。開発の観点からは、初期段階で利用者、プロセス、機能、データ、システムの境界を先に確認することのほうが重要です。
本文で引用した法令・基準
- 情報関連システム開発・保守注意事項（経済部水利署及び所属機関）経済部水利署（内部規範）
- 政府調達法第26条執行注意事項行政院公共工程委員会
- 政府調達法 第34条第1項行政院公共工程委員会
- サイバーセキュリティ管理法 第10条現行法規
- サイバーセキュリティ責任等級区分弁法 第11条現行法規
上記は執筆時点で引用した法令・基準です。改正される場合がありますので、実際の適用は所管官庁の最新の公告をご確認ください。