政府情報システム開発はどう計画する？要件定義・外部委託から検収までの要点

政府情報システムの開発で最初にすべきことは、多くの場合、使用する技術を決めることでも、作る機能の数を並べることでもありません。そのシステムがどの業務や公共サービスを支えるのか、誰が使うのか、どのデータを扱うのか、そして最終的にシステムが要件を満たしているかをどう判断するのかを確認することです。

情報システムの構築や外部委託開発を準備している政府機関にとって、要件の計画は、その後の調達範囲、ベンダーの見積もり、システム設計、情報セキュリティ、テスト、検収のすべてに影響します。初期段階で機能名しかなく、利用の流れ、データ、権限、検収方法が明確になっていなければ、入札が順調に済んだとしても、開発に入ってから要件の認識のずれが繰り返し生じるおそれがあります。

行政院公共工程委員会の「機関委託資訊服務廠商評選及計費弁法」（情報サービス事業者の選定・報酬算定規則）は、全体計画、システム統合、ソフトウェア開発、ソフトウェア検証、ソフトウェア保守、データベース構築、コンサルティングなどを「情報サービス」の範囲に含めています。ただし、実際の調達方式は、案件ごとの金額、性質、適用される規定に従って決める必要があります。

そのため、新しい政府情報システムを計画しているなら、まず次の6つの問いに答えてみるとよいでしょう。

• システムでどの業務や公共サービスを改善したいのか？
• どのような利用者がいて、それぞれの役割がどんな作業を完了する必要があるのか？
• システムはどのデータを扱う必要があり、既存データの移行は伴うのか？
• 他の政府システム、データベース、外部サービスとの連携は必要か？
• サイバーセキュリティ、個人情報、ウェブアクセシビリティなどの要件はあるか？
• 最終的に、どの機能、テスト、成果物を検収の根拠とすべきか？

この6点が明確であるほど、「システムを作りたい」という思いを、実際に調達・実行できる開発プロジェクトへと落とし込みやすくなります。

政府情報システムの開発は、なぜ機能の列挙から始めてはいけないのか？

情報システムの開発範囲は、機能名だけでは判断しにくいものです。

たとえば、要件仕様書に次のように書かれていたとします。

「案件管理機能を構築する。」

実際には、担当者が案件を登録・修正・照会できるだけの場合もあれば、市民によるオンライン申請、本人確認、部署をまたいだ案件の振り分け、上長の決裁、補正、通知、進捗照会、統計帳票、履歴の記録まで含む場合もあります。

どちらも「案件管理」と呼ばれますが、開発の規模はまったく異なります。

そのため、政府情報システムを計画する際は、「どんな機能があるか」よりも先に、次の点を確認する価値があります。

1つの業務が始まってから完了するまでに、どの人、どのデータ、どの処理を経るのか？

これは、すべての政府機関が同じ固定の開発プロセスに従わなければならないという意味ではなく、情報システムを計画するうえでの重要な原則です。

経済部水利署とその所属機関の現行規範を例にとると、「資訊相関系統開発与維護注意事項」（情報関連システム開発・保守に関する注意事項）は、情報システムのライフサイクルをシステム評価、要件・システム分析、システム設計、プログラム開発、システムテスト、教育訓練、本番稼働、システム保守の8段階に分け、要件仕様書、要件ヒアリング記録、設計仕様書、テスト計画書、テスト報告書などの参考書式も示しています。この規範は水利署とその所属機関の内部規範であり、すべての政府機関に共通する規定としてそのまま一般化することはできませんが、要件、設計、テスト、本番稼働が前後でつながっていることがわかります。

機関として本当に避けるべきなのは、要件が「機能名」の段階にとどまり、その後の設計と検収に共通の根拠がない状態です。

政府情報システムの要件仕様書では、まず何を確認すべきか？

要件仕様の目的は、担当部署に開発前の段階ですべてのボタン、画面、技術を決め切ってもらうことではありません。

より重要なのは、まずシステムの境界を定めることです。

たとえばオンライン申請システムを計画する場合、少なくとも次の点を明確にしておく必要があります。

誰が申請できるのか、どのような情報の提出が必要か、添付書類は必要か、申請後は誰が処理するのか、差し戻しや補正はあるか、どのような審査の役割があるか、申請者にどう通知するか、そして最終的にどの案件記録を保存する必要があるか。

こうした業務要件が確認できて初めて、開発チームはそれをさらに次の要素へと分解できます。

利用の流れ、機能、権限、データ構造、インターフェース、API、技術アーキテクチャ。

反対に、業務の流れが固まっていない段階で非常に細かい画面や技術的手法を先に指定すると、後の修正が増えるおそれがあるうえ、政府調達における公正な競争の要請にも注意を払う必要があります。

行政院公共工程委員会は、「政府採購法第二十六条執行注意事項」（台湾の政府調達法第26条の執行に関する注意事項）において、不特定のベンダーが競争入札する技術仕様は、機関が必要とする機能、効果、特性を達成するために必要な範囲に限るべきであり、目的または効果において不当に競争を制限してはならないとしています。

つまり、要件仕様を「詳しく」書くことは、「よく」書くことと同じではありません。

より重要なのは、次の点です。

説明すべき業務要件は十分に明確にしつつ、不要な技術指定によって解決策の幅を早い段階で狭めないこと。

要件がまだ固まっていない場合、政府機関はどのように事前調査を進められるか？

政府情報システムに特有なのは、担当部署が解決すべき課題はわかっていても、市場に現在どのような技術的手法があるのか、妥当な開発範囲をどう設定すべきかまではわからない場合があることです。

だからといって、仕様を自分たちだけで推測して決めるしかないわけではありません。

行政院公共工程委員会の「政府採購法第二十六条執行注意事項」は、機関が入札書類の技術仕様を定める際、「政府採購法」（台湾の政府調達法）第34条第1項の規定に基づき、ベンダーに参考資料の提供を公開で求め、機関で検討したうえで仕様を定めることができると明記しています。

言い換えれば、プロジェクトがまだ市場、技術、解決策が明確でない段階にあるなら、確信の持てない技術的な答えをそのまま仕様に書き込むのではなく、適用される調達手続きに従って、公開の市場情報収集の方法を活用することを検討できます。

これは情報システムでは特に重要です。

なぜなら、担当部署が最もよく把握しているのは、通常次のことだからです。

「今どこが使いにくいのか」

一方、開発ベンダーがよく知っているのは次のことです。

「その課題にどのような技術的な解決策があるのか」

政府情報システムの初期計画で本当に取り組むべきことは、調達の公正性を保ちながら、この2つを少しずつ結びつけていくことです。

政府情報システムを外部委託する際、入札前にどの条件を明確にすべきか？

政府の情報サービスの調達は、機能仕様だけで成り立つものではありません。

行政院公共工程委員会の「機関委託資訊服務廠商評選及計費弁法」によれば、入札書類には、案件の特性と実際の必要に応じて、サービス項目と作業範囲、ベンダーが備えるべきリソース、機関の既存の情報処理環境などを記載できます。サービス費用の算定も、情報サービスの種類、性質、規模、作業範囲、作業期間に応じて適切な方式を選ぶ必要があります。

情報システム開発においては、初期段階で機能以外に少なくとも次の項目を棚卸ししておくべきだということになります。

• 既存の情報処理環境とデプロイ条件
• 既存システムとデータソース
• 連携予定の外部システム
• 利用者の役割と権限
• データ移行の要件
• サイバーセキュリティ要件
• テストと検収の項目
• 本番稼働の方法
• 教育訓練やドキュメントの納品
• 稼働後の運用保守と保証の要件

すべてのプロジェクトで全項目が必要になるとは限りませんが、いずれかがベンダーの投入する人員、技術、スケジュールに影響するのであれば、開発が始まってから初めて確認するのは避けるべきです。

サイバーセキュリティはシステム完成後まで後回しにできない

政府情報システムにとって、セキュリティは開発完了後に「一度スキャンする」だけで終わる作業ではありません。

現行の「資通安全管理法」（台湾のサイバーセキュリティ管理法）第10条は、公務機関または特定非公務機関が、適用範囲内で情報通信システムの構築・運用保守や情報通信サービスを外部委託する場合、適切な受託者を選定し、有効なサイバーセキュリティ管理体制の構築を求めてその実施を監督するとともに、双方の権利義務と違約責任を書面の契約に明記しなければならないと定めています。

現行の「資通安全責任等級分級弁法」（サイバーセキュリティ責任等級区分規則）第11条も、各機関が自ら開発または外部委託で開発する情報通信システムについて、規定に従って防護要件の等級区分を完了し、対応する防護基準に従って管理措置を実施することを求めています。

そのため、ログイン、権限管理、個人情報、機密情報、システム間のデータ交換を伴うプロジェクトでは、セキュリティ要件をシステムアーキテクチャと要件定義の段階から組み込むべきです。

たとえば、

どの役割がどのデータを閲覧できるか、機密データをどう扱うか、システム間でどのように情報を交換するか、どのセキュリティ検査を完了する必要があるかは、いずれもシステム設計に影響しえます。

検収の直前になって初めて対応すると、手戻りが必要になるのはプログラムだけでなく、権限やデータのアーキテクチャ全体に及ぶ可能性が高くなります。

政府ウェブサイトや市民向けサービス窓口なら、ウェブアクセシビリティも考慮が必要

開発の対象が政府ウェブサイト、オンライン申請サービス、その他の市民向けウェブサービスである場合は、情報システムそのものに加えて、政府ウェブサイトに関する規範も確認する必要があります。

政府ウェブサイト運営交流プラットフォームの「政府網站服務管理規範」（政府ウェブサイトサービス管理規範）は現在、ウェブサイトのライフサイクルを、サイトの位置づけ、設計計画、開発・構築、データ移行、公開準備、運用管理の6つの実施領域に整理しています。そのうえで、開発・構築の段階では、情報セキュリティとウェブサイトサービスに関する規定への適合を確認するよう求めており、その中には「網站無障礙規範」（ウェブアクセシビリティ規範）も含まれます。

デジタル発展部の現行の「網站無障礙規範」は、知覚可能、操作可能、理解可能、互換性といった観点を網羅しており、たとえばキーボード操作、コンテンツの構造、フォーカス順序、エラーの特定、支援技術との互換性などが含まれます。

そのため、プロジェクト自体にアクセシビリティ要件がある場合は、ウェブサイトの完成後にまとめて修正するのではなく、UI/UXとフロントエンド開発の段階から組み込むほうが合理的です。

政府情報システムの予算は、なぜ機能の数だけで見積もれないのか？

政府情報システムの開発コストは、通常「機能がいくつあるか」だけでは決まりません。

たとえば、2つのプロジェクトがどちらも次の機能を備えているとします。

会員、案件管理、検索、帳票、管理画面。

一方は内部の職員10名だけが使うものかもしれません。もう一方は、市民のログイン、機関をまたいだデータ交換、多階層の権限、過去データの移行、セキュリティ検査、公開ウェブサイトのアクセシビリティ対応が必要かもしれません。

両者の機能名は似ていても、実際の開発範囲は大きく異なる可能性があります。

そのため、情報システムの開発範囲を見積もる際は、次のように分けて確認するのが適しています。

業務プロセス → 利用者の役割 → 機能 → データ → システム連携 → セキュリティ → 設計 → テスト → 本番稼働と納品

行政院公共工程委員会の情報サービスの費用算定規定も、単純に機能の数で費用を決めるのではなく、サービスの種類、性質、規模、作業範囲、期間などの要素に応じて、適切な算定方式を選ぶことを求めています。

したがって、プロジェクトの予算が限られている場合は、まず長い機能リストを作ってから1つずつ削るよりも、先に次の点を確認するほうが有益です。

第1フェーズでは、実際に使い始められるサービスの流れのうち、少なくともどの部分を完成させる必要があるのか？

これは政府の法規上の要件ではなくシステム計画上の提案ですが、開発範囲をコントロールするうえでは通常はより効果的です。

政府情報システムの開発途中で要件を変更できるか？

情報システムが要件ヒアリング、プロトタイプ、実地テストの段階に入ってから、一部の業務の流れを調整する必要があるとわかることは珍しくありません。

したがって本当に管理すべきなのは、「プロジェクト開始後は絶対に要件を変えない」ことではなく、次の点です。

要件を変更する際に、範囲、スケジュール、費用、検収の根拠をどのように合わせて調整するか。

たとえば、もともとの要件は担当者が案件を照会できるようにすることだったのに、後から機関をまたいだ案件の振り分けと自動通知が追加された場合、これはもはや画面の調整にとどまらず、新たな権限、業務の流れ、データ交換が関わってくる可能性があります。

明確な変更管理の方法がないと、次のような事態が起こりやすくなります。

機関側は元の機能の一部にすぎないと考え、ベンダー側は追加の範囲だと考える。

そのため、契約、作業範囲記述書、プロジェクト管理の仕組みの中で、要件の確定、変更の記録、影響評価の方法をあらかじめ定めておくほうが、「すべての要件を初日に確定させる」ことを求めるよりも、情報システム開発の実態に合っています。

行政院公共工程委員会は現在も、機関が情報サービスを調達する際の参考として「資訊服務採購契約範本」（情報サービス調達契約のひな形）を提供していますが、実際の契約内容は個別案件の要件と最新の規定に合わせて調整する必要があります。

政府情報システムの検収は、いつから準備を始めるべきか？

要件の計画段階から考え始めるべきです。

なぜなら、

要件仕様は何を作るかを決め、検収はそれが本当に完成したことをどう確認するかを決めるからです。

たとえば、次のように書くだけでは、

「オンライン申請機能を提供する。」

最終的に何をもって完成とするのか判断しにくくなります。

最初から次のようにシナリオを明確にしておけば、

申請者がログイン → 情報を入力 → 添付書類をアップロード → 送信 → 担当者が審査 → 補正 → 再審査 → 完了 → 結果を通知、

後から各ステップをテストシナリオや検収項目に落とし込みやすくなります。

水利署の現行の内部規範を例にとると、システムテストの段階では要件と設計の関連文書に基づいてテストを行うことを求め、テスト計画とテスト報告の参考書式も示しています。改めて強調しておくと、これは水利署とその所属機関の規範であり、すべての政府情報システムが法律上同じ文書やプロセスを採用しなければならないという意味ではありません。しかし、要件とテストの間にあるべきつながりをよく示しています。

そのため、政府情報システムの初期計画では、非常に実践的な確認方法として次の問いが使えます。

重要な要件のそれぞれについて、「最終的に完成したことをどう証明するのか？」に答えられるか。

答えられないなら、その要件はまだ明確化が必要だということです。

政府情報システムの開発ベンダーはどう評価すべきか？

情報システムの開発は、仕様が完全に固まった完成品を調達するのとは異なるため、機能の数や最低価格だけで判断することはできません。

行政院公共工程委員会の「機関委託資訊服務廠商評選及計費弁法」自体も、プロジェクト計画・管理能力、人員配置計画、関連する能力、その他案件の必要に応じて設定する項目を情報サービスの選定制度に組み込んでいます。実際の評価項目は、機関が個別案件と入札書類に基づいて設定する必要があります。

情報システム開発の観点からは、初期段階で特に次の点に注目するとよいでしょう。

第一に、ベンダーが機能一覧どおりに見積もるだけでなく、業務プロセスを理解できるかどうか。

「案件管理」を見たときに、案件のステータス、役割、例外的な流れ、履歴の要件について掘り下げて質問してくるか。

第二に、システムの境界を自ら指摘できるかどうか。

たとえば、どの機能が本システムに属し、どれに外部APIが必要で、どのデータが他の機関から提供されるのか。

第三に、検証の方法を明確に説明できるかどうか。

「できます」だけでなく、どうテストし、どう完成を確認するのかまで説明できるか。

第四に、セキュリティ、デプロイ、稼働後の運用保守がアーキテクチャの検討に含まれているかどうか。

これらは通常、「同じ10の機能を作るなら、どこが最も安いか」を単純に比べるよりも、情報サービスにおける実際の履行能力をよく反映します。

政府情報システム開発の核心は、仕様を多く書くことではない

政府情報システムは、要件の計画から本番稼働までに、調達、開発、セキュリティ、テスト、検収といった異なる段階を経ます。

これらの段階が円滑につながるかどうかを本当に左右するのは、仕様書のページ数ではなく、次の3つが一致しているかどうかです。

機関が本当に解決したい課題

↓

ベンダーが実際に開発するシステム

↓

最終的に検収に用いる基準

出発点が「市民の申請にかかる時間を短縮したい」であるにもかかわらず、要件には「案件管理システムを構築する」としか書かれておらず、最後の検収ではページが開くかどうかしか確認しないのであれば、すべての文書がそろっていても、システムは本来の課題を解決できていない可能性があります。

そのため、政府情報システムでは、技術を先に決めたり、最も網羅的な機能リストを追い求めたりするよりも、開発前に業務プロセス、利用者、システムの境界、データ、セキュリティ、検収方法を整理しておくことのほうが価値があります。

これらの条件が確認できて初めて、技術と開発の方向性が明確になります。

政府情報システム開発に関するよくある質問

要件の整理から始め、本当に開発でき、使われる情報システムへ

政府や公的機関で、新しい情報システム、オンラインサービス、ウェブプラットフォーム、業務のデジタル化といったニーズが生じたとき、開発の出発点は、完全に確定した機能一覧である必要はありません。

より重要なのは、まず現在の業務プロセス、利用者、データ、システム環境、期待する成果を整理し、それを段階的に実行可能な情報システムの要件へと落とし込んでいくことです。

JoinX（哲煜科技）は、カスタム開発とデザイン、AI導入、技術・AIコンサルティングのサービスを提供しており、プロジェクトのニーズに応じて、ウェブサイト、システム、アプリ、SaaS、AIアプリケーションの企画と開発に携わることができます。

政府および公的機関の情報システム案件では、協業にあたっても政府調達の関連手続きと個別案件の入札規定に従う必要があります。市場情報の収集、参考資料の公開募集、正式な調達案件のいずれの場合も、機関が採用する適法な手続きに沿って、それに応じた技術・開発に関する情報を提供いたします。