[{"data":1,"prerenderedAt":633},["ShallowReactive",2],{"site-schema":3,"article-ja-government-information-system-requirements-specification-guide":88,"article-related-ja-government-information-system-requirements-specification-guide":620},{"@context":4,"@graph":5},"https://schema.org",[6,72,79],{"@type":7,"@id":8,"name":9,"alternateName":10,"legalName":15,"foundingDate":16,"numberOfEmployees":17,"taxID":18,"url":19,"logo":20,"founder":21,"contactPoint":23,"address":37,"location":43,"sameAs":63},"Organization","https://joinx.co/#organization","JoinX哲煜科技",[11,12,13,14],"JoinX","TWJOIN","哲煜科技","哲煜科技股份有限公司","JoinX Co., Ltd.","2016-04-28",80,"43774383","https://joinx.co","https://joinx.co/images/logo-with-name.png",{"@id":22},"https://joinx.co/#person-jack-lee",[24],{"@type":25,"contactType":26,"url":27,"telephone":28,"email":29,"areaServed":30,"availableLanguage":33},"ContactPoint","customer service","https://joinx.co/contact-us","+886-2-8771-9095","service@joinx.co",[31,32],"TW","JP",[34,35,36],"zh-Hant","en","ja",{"@type":38,"streetAddress":39,"postalCode":40,"addressLocality":41,"addressRegion":42,"addressCountry":31},"PostalAddress","民生東路二段170號8樓","104","台北市中山區","台灣",[44,51,57],{"@type":45,"name":46,"address":47},"Place","JoinX 台中辦公室",{"@type":38,"streetAddress":48,"postalCode":49,"addressLocality":50,"addressRegion":42,"addressCountry":31},"台灣大道二段360號21樓C室","40453","台中市北區",{"@type":45,"name":52,"address":53},"JoinX 高雄辦公室",{"@type":38,"streetAddress":54,"postalCode":55,"addressLocality":56,"addressRegion":42,"addressCountry":31},"民族一路80號2樓之一(B4)","807","高雄市三民區",{"@type":45,"name":58,"address":59},"JoinX 東京辦公室",{"@type":38,"streetAddress":60,"postalCode":61,"addressLocality":62,"addressCountry":32},"東五反田5-22-37 Office Circle N 五反田 9樓","141-0022","東京都品川區",[64,65,66,67,68,69,70,71],"https://www.crunchbase.com/organization/twjoin","https://www.facebook.com/JoinX.TW","https://tw.linkedin.com/company/%E5%93%B2%E7%85%9C%E7%A7%91%E6%8A%80","https://www.youtube.com/c/joinstuido%E5%93%B2%E7%85%9C%E7%A7%91%E6%8A%80","https://medium.com/twjoin","https://www.104.com.tw/company/1a2x6bjomb","https://clutch.co/profile/twjoin","https://www.goodfirms.co/company/twjoin",{"@type":73,"@id":22,"name":74,"alternateName":75,"jobTitle":76,"worksFor":77,"url":78},"Person","李秉哲","Jack Lee","創辦人暨執行長",{"@id":8},"https://joinx.co/about",{"@type":80,"@id":81,"url":19,"name":9,"alternateName":82,"publisher":83,"inLanguage":84},"WebSite","https://joinx.co/#website",[11,13,9],{"@id":8},[85,86,87],"zh-Hant-TW","en-US","ja-JP",{"id":89,"title":90,"audience":91,"author":92,"authorUrl":93,"body":94,"category":540,"cover":541,"ctaFirstContent":542,"ctaFirstLinkText":543,"ctaFirstLinkUrl":544,"ctaLastContent":545,"ctaLastLinkText1":546,"ctaLastLinkText2":93,"ctaLastLinkUrl1":544,"ctaLastLinkUrl2":93,"ctaMiddleContent":93,"ctaMiddleLinkText":93,"ctaMiddleLinkUrl":93,"ctaServiceName":547,"dateModified":548,"description":100,"extension":549,"faq":550,"hasCoverTitle":556,"hasCtaFirst":557,"hasCtaLast":557,"isDescriptionFirst":557,"locale":36,"meta":558,"navigation":557,"path":559,"readingMinutes":560,"seo":561,"sources":562,"stem":576,"tables":577,"takeaways":609,"template":616,"time":617,"type":618,"__hash__":619},"content/ja/article/government-information-system-requirements-specification-guide.md","政府情報システムの要件仕様書はどう書く？要件・機能から検収までの整理方法","政府機関の担当者、情報システム担当者、情報システムプロジェクトの窓口","JoinX編集部",null,{"type":95,"value":96,"toc":503},"minimal",[97,101,104,107,112,115,118,121,124,127,130,133,137,140,143,177,180,183,186,189,193,196,199,204,207,210,214,217,221,224,228,231,235,238,242,245,249,252,256,259,262,265,269,272,275,278,281,284,287,290,294,297,300,303,306,326,329,332,336,339,342,345,348,352,355,358,372,375,378,381,398,401,405,408,411,415,418,422,425,429,432,436,439,443,446,450,453,456,459,462,465,468,472,475,479,482,486,489,493,496,500],[98,99,100],"p",{},"政府情報システムの要件仕様書で重要なのは、すべての画面・ボタン・技術的手法を先に決め切ることではありません。システムがどの問題を解決するのか、誰が使うのか、どの業務プロセスを完了させる必要があるのか、どのデータを扱うのか、既存環境と制約は何か、そして最終的に開発成果が要件を満たしていることをどう確認するのかを、明確に説明することです。",[98,102,103],{},"情報システムの外部委託開発を準備している政府機関にとって、要件仕様は、ベンダーがプロジェクトをどう理解し、開発範囲をどう評価し、その後の設計・開発・テスト・検収をどう進めるかに直接影響します。",[105,106],"article-cta",{},[108,109,111],"h2",{"id":110},"政府情報システムの要件仕様書に決まったフォーマットはあるのか","政府情報システムの要件仕様書に決まったフォーマットはあるのか？",[98,113,114],{},"現在、すべての政府機関、すべての情報システム案件にそのまま適用できる単一の要件仕様書フォーマットは存在しません。各機関は、自らの規定、調達方式、システムの性質、プロジェクトの要件に応じて実際の内容を決める必要があります。",[98,116,117],{},"要件仕様書が本当に解決すべき問題は「どのテンプレートを使うか」ではなく、次の点です。",[98,119,120],{},"この文書は、機関と開発ベンダーがプロジェクト範囲について共通理解を築けるほど明確になっているか？",[98,122,123],{},"経済部水利署及び所属機関の現行「情報関連システム開発・保守注意事項」を例にとると、情報システムの開発・保守を、システム評価、要件・システム分析、システム設計、プログラム開発、システムテスト、教育訓練、システム稼働、システム保守の8つのライフサイクル段階に分け、要件仕様書、要件ヒアリング記録、設計仕様書、テスト計画書、テスト報告書などの参考フォーマットを提供しています。同規範の最終改正は2024年8月21日です。",[98,125,126],{},"ただしこれは経済部水利署及び所属機関の管理規範であり、すべての政府機関が同じフォーマットやプロセスを採用しなければならないと書くことはできません。",[98,128,129],{},"本当に参考にすべきなのは、その背後にある考え方です。",[98,131,132],{},"要件は孤立した入札文書ではなく、その後の設計・開発・テスト・稼働の出発点である、という点です。",[108,134,136],{"id":135},"なぜ要件は機能リストから始めてはいけないのか","なぜ要件は機能リストから始めてはいけないのか？",[98,138,139],{},"「案件管理」「オンライン申請」「会員管理」は、システムにおおよそどの機能が必要かを示すだけで、本当の開発範囲を定めるには不十分です。",[98,141,142],{},"要件仕様に「オンライン申請機能を構築する」の一文しかないとします。業務の観点からは要件は十分明確に見えます。しかしシステム開発の観点では、まだ多くの問いに答えがありません。",[144,145,146,150,153,156,159,162,165,168,171,174],"ul",{},[147,148,149],"li",{},"申請者はログインが必要か？",[147,151,152],{},"本人確認はどの方法で行うか？",[147,154,155],{},"どのデータと添付書類を入力する必要があるか？",[147,157,158],{},"送信後の案件は誰が受け付けるか？",[147,160,161],{},"上長の承認は必要か？",[147,163,164],{},"データに誤りがある場合、差し戻しか、補正か？",[147,166,167],{},"補正後はどのプロセスに戻るか？",[147,169,170],{},"申請者は進捗を照会できるか？",[147,172,173],{},"審査結果はどの方法で通知するか？",[147,175,176],{},"担当者にはどのような統計とレポートが必要か？",[98,178,179],{},"これらは「オンライン申請」という機能名を変えるものではありませんが、システムの開発範囲に非常に大きな違いをもたらしえます。",[98,181,182],{},"したがって要件は「システムにどの機能が必要か」だけでなく、「誰が、どのような状況で、システムを通じてどの業務を完了する必要があり、完了後にどのような結果が生まれるのか」を問うべきです。",[98,184,185],{},"たとえば「システムは案件照会機能を提供する」とだけ書くのではなく、次のように具体化できます。担当者はログイン後、案件番号、申請者、申請日、案件ステータスで所属部門の案件を検索し、案件の基本情報と処理履歴を閲覧できる。",[98,187,188],{},"ここまで書いて初めて、開発チームはログイン、ロール権限、条件検索、案件データ、履歴記録といった、実際に開発が必要な内容を特定できます。",[108,190,192],{"id":191},"政府情報システムの要件仕様書では何を先に確認すべきか","政府情報システムの要件仕様書では何を先に確認すべきか？",[98,194,195],{},"政府情報システムの要件は、まず「目的、ロール、プロセス、機能、データ、連携、非機能要件、検収」の8つの観点から確認でき、重要なのは機能の数を追うことではなく、システムの境界を明確にすることです。",[98,197,198],{},"プロジェクトごとに規模と要求は異なりますが、システム開発の観点からは、少なくとも次の8つの観点を先に確認できます。",[200,201,203],"h3",{"id":202},"_1-プロジェクトの目的","1. プロジェクトの目的",[98,205,206],{},"なぜこのシステムが必要なのか。現在の業務のやり方でどのような問題が起きているのか。構築後に何を改善したいのか。",[98,208,209],{},"たとえば本当の要件は「案件管理システムが必要」ではなく、現在の案件がメール、Excel、紙の間に散在しているため部門横断の照会が難しく、処理の進捗を把握できない、ということかもしれません。",[200,211,213],{"id":212},"_2-利用者とロール","2. 利用者とロール",[98,215,216],{},"誰がシステムを使うのか。市民、担当者、上長、システム管理者、他の機関はそれぞれどの業務を完了する必要があるのか。ロールごとに、どのデータを閲覧・修正・処理できるのか。",[200,218,220],{"id":219},"_3-業務プロセス","3. 業務プロセス",[98,222,223],{},"一つの業務は開始から完了までどのステップを経るのか。通常のプロセスに加えて、差し戻し、補正、取消、再申請、部門横断の処理などの例外にはどのようなものがあるのか。",[200,225,227],{"id":226},"_4-機能要件","4. 機能要件",[98,229,230],{},"各ロールはシステムを通じてそれぞれどの操作を完了する必要があるのか。機能はできる限り実際のプロセスに結びつけ、機能名を単独で列挙しないようにします。",[200,232,234],{"id":233},"_5-データ要件","5. データ要件",[98,236,237],{},"システムはどのデータを作成・照会・保存・インポート・エクスポート・交換する必要があるのか。既存データを新システムへ移行する必要はあるのか。",[200,239,241],{"id":240},"_6-システム連携","6. システム連携",[98,243,244],{},"既存のアカウント、データベース、他の政府情報システム、サードパーティAPIとの連携は必要か。データは誰が提供し、どの方法で交換するのか。",[200,246,248],{"id":247},"_7-非機能セキュリティ要件","7. 非機能・セキュリティ要件",[98,250,251],{},"「何をするか」に加えて、利用量、性能、互換性、権限、セキュリティ、適用されるサイバーセキュリティ要件も考慮する必要があります。",[200,253,255],{"id":254},"_8-テストと検収","8. テストと検収",[98,257,258],{},"重要な機能が完了するたびに、それが元の要件を満たしていることをどう確認するのか。どの条件を満たせばシステムを正式に納品できるのか。",[98,260,261],{},"要件仕様クイックチェックリスト",[98,263,264],{},"この8項目は、すべての政府案件が法令上使わなければならない固定の章立てではなく、開発要件がすでに完全なシステム境界を形成しているかを確認するための整理手法です。",[108,266,268],{"id":267},"機能要件はどこまで細かく書くべきか","機能要件はどこまで細かく書くべきか？",[98,270,271],{},"機能要件は、ベンダーが利用シナリオと開発範囲を理解できる程度に詳細であるべきですが、必要がない場合にまですべてのUI、技術アーキテクチャ、実装方法を先に指定し切るべきという意味ではありません。",[98,273,274],{},"たとえば「システムは権限管理機能を提供する」とだけ書いても、本当の作業量は見積もりにくいままです。さらに一歩進めて、一般担当者は所属部門の案件のみ照会・処理できる、部門長は所属部門の案件を閲覧し指定された承認を実行できる、システム管理者はアカウントとシステム設定を管理できる、と書けば、開発チームはロールとデータアクセスの関係を理解できます。",[98,276,277],{},"一方で、本当の要件がシステムに特定の機能と効果を実現させることだけなら、特定のプログラミング言語、データベース製品、パッケージを指定する必要があるかどうかは別途判断が必要です。",[98,279,280],{},"行政院公共工程委員会の「政府調達法第26条執行注意事項」は、不特定のベンダーが競争入札する技術仕様は、機関が機能・効果・特性などの面で必要とするものに限定すべきであり、競争制限にあたるかどうかは、その仕様が機関の本当の需要を超えているかで判断すべきだとしています。",[98,282,283],{},"したがって要件仕様の核心は「技術をどこまで細かく書けるか」ではなく、「どの条件が機関にとって本当に必要で、かつベンダーが知っておくべきものか」です。",[98,285,286],{},"市場にどのような適切な技術ソリューションがあるかまだ分からない場合、工程会の現行注意事項は、機関が技術仕様を定める際、関連する公開閲覧制度に基づいて処理する場合を除き、政府調達法第34条第1項に基づきベンダーに参考資料の提供を公開で求め、検討のうえ定めることができると明記しています。",[98,288,289],{},"これは、業務要件と技術ソリューションを、要件整理の初日に同時にすべて決める必要は必ずしもないことも意味します。",[108,291,293],{"id":292},"見落とされやすく開発範囲に直接影響する要件とは","見落とされやすく、開発範囲に直接影響する要件とは？",[98,295,296],{},"プロジェクトの見積もり、アーキテクチャ、スケジュールに本当に差を生むのは、多くの場合主要機能ではなく、データ、利用量、権限、連携、セキュリティ、既存環境です。",[98,298,299],{},"たとえば、どちらも「案件管理システム」と呼ばれる2つのシステムがあるとします。一方は内部の10名だけが使い、もう一方は多数の市民のオンライン申請と照会に対応する必要があります。機能名はよく似ていても、アカウント管理、トラフィック、システム容量、データセキュリティ、インフラの要件はまったく異なりうるのです。",[98,301,302],{},"データ移行も同様です。新システム稼働後に長年の過去案件を保持する必要があるなら、要件は「新しい案件システムを開発する」だけではなく、データの棚卸し、フォーマット整理、項目対応、データ変換、検証、新旧システムの切り替えも同時に扱う必要があります。",[98,304,305],{},"また、既存システムとの連携が必要な場合も、「システムはAPI連携を提供する」とだけ書くのではなく、次の点を確認する必要があります。",[144,307,308,311,314,317,320,323],{},[147,309,310],{},"どのシステムと連携するのか？",[147,312,313],{},"インターフェースは誰が提供するのか？",[147,315,316],{},"どのデータを交換するのか？",[147,318,319],{},"どのくらいの頻度で交換するのか？",[147,321,322],{},"交換に失敗した場合はどう処理するのか？",[147,324,325],{},"どのような権限とセキュリティ上の制約があるのか？",[98,327,328],{},"水利署の現行内部規範を例にとると、その要件仕様の注意項目には、データの年間増加量、主要およびピーク時の利用者数、ピーク時間帯、ネットワークトラフィック、サーバー容量、既存アプリケーションおよびサードパーティ製コンポーネントとの互換性、データ互換性、情報セキュリティ防護要件などの分析が含まれています。",[98,330,331],{},"これは、機能の数がシステム開発規模を判断する唯一の基準ではないことを改めて示しています。だからこそ、異なるベンダーが同じ要件を受け取ったのに大きく異なる価格を提示する場合、どこが高いかという話とは限らず、実はそれぞれ異なる開発範囲を見積もっている可能性があるのです。",[200,333,335],{"id":334},"なぜセキュリティも要件段階で確認すべきなのか","なぜセキュリティも要件段階で確認すべきなのか？",[98,337,338],{},"政府情報システムにとって、セキュリティはシステム完成後に一度検査を補うものではありません。",[98,340,341],{},"現行の「サイバーセキュリティ管理法」第10条は、公務機関または特定非公務機関が適用範囲内で情報通信システムの構築・運用または情報通信サービスを外部委託する場合、適切な受託者を選任し、有効なサイバーセキュリティ管理体制の構築を求めてその実施を監督し、双方の権利義務と契約違反時の責任を書面の契約に明記しなければならないと定めています。",[98,343,344],{},"2026年1月7日に公布された現行の「サイバーセキュリティ責任等級区分弁法」第11条も、各機関が自ら開発または外部委託で開発する情報通信システムについて、附表9に基づき情報通信システムの防護要件の等級区分を完了し、附表10に定める防護基準に従って管理措置を実施しなければならないと定めています。",[98,346,347],{},"したがって、システムがログイン、権限、個人情報、機微情報、システム間のデータ交換に関わる場合、関連する要件はシステムアーキテクチャと開発方法に直接影響しえます。要件段階で早く確認するほど、後になってシステムの大幅な修正が必要だと分かるリスクを下げられます。",[108,349,351],{"id":350},"要件仕様はどのようにテストと検収までつながるのか","要件仕様はどのようにテストと検収までつながるのか？",[98,353,354],{},"良い要件は「システムは何をするか」に答えるだけでなく、「最終的にそれが完成したことをどう証明するか」にも答えられるべきです。要件をテスト可能なシナリオに変換できるほど、その後の検収で共通基準を築きやすくなります。",[98,356,357],{},"要件に「市民は案件の処理進捗を照会できる」と書かれているとします。実際にテストに入ると、さらに次の点を確認できます。",[144,359,360,363,366,369],{},[147,361,362],{},"市民は規定の方法で照会できるか？",[147,364,365],{},"異なる案件ステータスは正しく表示されるか？",[147,367,368],{},"権限のない人は案件を閲覧できないようになっているか？",[147,370,371],{},"案件が存在しない場合、システムはどう応答するか？",[98,373,374],{},"元の要件が曖昧な「案件照会を提供する」の一文だけで、検収段階になって初めてこれらの条件を議論し始めると、「機関はもともと含まれていると考えていた」と「ベンダーは元の要件にこの内容はなかったと考えていた」の間にギャップが生じやすくなります。",[98,376,377],{},"水利署の現行の情報システム開発・保守規範を例にとると、そのシステムテスト段階では、計画書、要件仕様、設計関連文書に基づいて機能テストを行い、テスト結果が要件仕様と設計の期待に合致しない場合はさらに対応することになっています。同様に、これは水利署及び所属機関の制度であり、すべての機関が統一的に採用する検収方法ではありませんが、システム開発の非常に重要な原則を示しています。要件、設計、テスト、検収は互いに切り離されるべきではない、ということです。",[98,379,380],{},"したがって、要件仕様が完成したら、項目ごとに次の点を確認できます。",[144,382,383,386,389,392,395],{},[147,384,385],{},"この要件は誰が使うのか？",[147,387,388],{},"どの条件で発動するのか？",[147,390,391],{},"期待される結果は何か？",[147,393,394],{},"失敗や例外の場合はどう処理するのか？",[147,396,397],{},"最終的にどう検証するのか？",[98,399,400],{},"重要な要件が最後の問いに答えられないなら、通常はさらに明確化が必要だということです。",[108,402,404],{"id":403},"要件が次の段階に進める状態とは","要件が次の段階に進める状態とは？",[98,406,407],{},"要件は、すべての画面と技術的な詳細を決め切らなければ準備完了とみなせないわけではありません。より重要なのは、プロジェクトの問題、利用者、プロセス、データ、主要機能、制約条件、検収の方向性が十分に明確になっていることです。",[98,409,410],{},"まず次のいくつかの問いで判断できます。",[200,412,414],{"id":413},"要件はすでに理解可能か","要件はすでに理解可能か？",[98,416,417],{},"異なる人が要件を読んだとき、「このシステムは何を解決するのか」についておおむね一致した答えが得られるでしょうか。",[200,419,421],{"id":420},"システムの境界は形成されているか","システムの境界は形成されているか？",[98,423,424],{},"どの機能が本プロジェクトに属し、どれが外部システム、他部門、サードパーティサービスの協力を必要とするかが分かっているでしょうか。",[200,426,428],{"id":427},"主要プロセスは完全か","主要プロセスは完全か？",[98,430,431],{},"通常のプロセスだけでなく、差し戻し、補正、取消、異常、権限不足の場合の処理も見え始めているでしょうか。",[200,433,435],{"id":434},"重要なデータは棚卸しされているか","重要なデータは棚卸しされているか？",[98,437,438],{},"どのデータを作成・保存・移行・交換する必要があるかが分かっているでしょうか。",[200,440,442],{"id":441},"開発上の制約は開示されているか","開発上の制約は開示されているか？",[98,444,445],{},"たとえば既存環境、デプロイ方法、情報セキュリティ、互換性、その他プロジェクトの必要条件です。",[200,447,449],{"id":448},"検収の方向性を説明できるか","検収の方向性を説明できるか？",[98,451,452],{},"少なくとも、重要な機能が完了した後、どのシナリオで成果を確認する予定かを説明できるでしょうか。",[98,454,455],{},"これらの問いにおおむね答えられるなら、要件は「システムを作りたい」から「このシステムが主に何を解決するのかが分かっていて、どう作るかの評価に進める」段階へ前進しています。",[98,457,458],{},"逆に、いまはまだ「プロセスをデジタル化したい」「案件管理プラットフォームを作りたい」「オンライン申請を導入したい」といった方向性しかなくても、プロジェクトを始められないわけではありません。その場合はまず次のことを行うのが適切です。",[98,460,461],{},"現行プロセスの棚卸し → 利用者・要件ヒアリング → データと既存環境の棚卸し → システム境界の整理 → 機能と技術の評価",[98,463,464],{},"そのうえで段階的に正式な開発要件を形にしていきます。",[108,466,467],{"id":467},"政府情報システムの要件仕様に関するよくある質問",[200,469,471],{"id":470},"政府情報システムの要件仕様書はすべての画面を描き終えなければなりませんか","政府情報システムの要件仕様書は、すべての画面を描き終えなければなりませんか？",[98,473,474],{},"必ずしもそうではありません。現在、すべての政府情報システム案件に適用される「入札前にすべてのUI画面を完成させなければならない」という通則はありません。ワイヤーフレーム、フローチャート、画面イメージ、その他の文書が必要かどうかは、個別案件と機関の規定によって決まります。開発の観点からは、初期段階で利用者、プロセス、機能、データ、システムの境界を先に確認することのほうが重要です。",[200,476,478],{"id":477},"機能を細かく書くほどベンダーの見積もりは必ず正確になりますか","機能を細かく書くほど、ベンダーの見積もりは必ず正確になりますか？",[98,480,481],{},"要件が明確であるほど、一般に見積もりの不確実性は下がりますが、「細かく書く」ことがすべての実装方法を指定することを意味するわけではありません。見積もりに本当に影響するのは、利用者規模、権限、データ量、既存システムとの連携、データ移行、セキュリティ、デプロイ、検収要件なども含まれます。",[200,483,485],{"id":484},"政府情報システムの要件で特定の技術を指定できますか","政府情報システムの要件で特定の技術を指定できますか？",[98,487,488],{},"案件の必要性と適用される政府調達規定に基づいて判断する必要があります。行政院公共工程委員会の現行注意事項は、不特定のベンダーが競争入札する技術仕様は、機関が必要とする機能・効果・特性などの必要要件に限定し、実際の需要を超えて不当に競争を制限することを避けるべきだとしています。",[200,490,492],{"id":491},"セキュリティ要件は要件仕様の段階で確認する必要がありますか","セキュリティ要件は要件仕様の段階で確認する必要がありますか？",[98,494,495],{},"案件に適用されるセキュリティ規定に基づいて評価する必要があります。現行の「サイバーセキュリティ責任等級区分弁法」第11条は、各機関が自ら開発または外部委託で開発する情報通信システムについて、防護要件の等級区分を完了し、対応する防護基準に従って管理措置を実施することをすでに定めているため、セキュリティはシステム完成後に初めて確認するものではありません。",[200,497,499],{"id":498},"要件がまだ明確でない場合先に市場にどのような手法があるか調べてもよいですか","要件がまだ明確でない場合、先に市場にどのような手法があるか調べてもよいですか？",[98,501,502],{},"適用される政府調達手続きに従って市場情報を収集できます。行政院公共工程委員会の「政府調達法第26条執行注意事項」は、関連する条件の下で、機関が政府調達法第34条第1項に基づきベンダーに参考資料の提供を公開で求め、検討のうえ技術仕様を定めることができるとしています。実際の手続きは、個別案件と機関の調達権限に従って進めます。",{"title":504,"searchDepth":505,"depth":505,"links":506},"",2,[507,508,509,520,521,524,525,533],{"id":110,"depth":505,"text":111},{"id":135,"depth":505,"text":136},{"id":191,"depth":505,"text":192,"children":510},[511,513,514,515,516,517,518,519],{"id":202,"depth":512,"text":203},3,{"id":212,"depth":512,"text":213},{"id":219,"depth":512,"text":220},{"id":226,"depth":512,"text":227},{"id":233,"depth":512,"text":234},{"id":240,"depth":512,"text":241},{"id":247,"depth":512,"text":248},{"id":254,"depth":512,"text":255},{"id":267,"depth":505,"text":268},{"id":292,"depth":505,"text":293,"children":522},[523],{"id":334,"depth":512,"text":335},{"id":350,"depth":505,"text":351},{"id":403,"depth":505,"text":404,"children":526},[527,528,529,530,531,532],{"id":413,"depth":512,"text":414},{"id":420,"depth":512,"text":421},{"id":427,"depth":512,"text":428},{"id":434,"depth":512,"text":435},{"id":441,"depth":512,"text":442},{"id":448,"depth":512,"text":449},{"id":467,"depth":505,"text":467,"children":534},[535,536,537,538,539],{"id":470,"depth":512,"text":471},{"id":477,"depth":512,"text":478},{"id":484,"depth":512,"text":485},{"id":491,"depth":512,"text":492},{"id":498,"depth":512,"text":499},"技術情報","/images/blog/government-information-system-requirements-specification-guide.webp","政府情報システムの要件を整理中だが、プロセス、権限、データ、検収の境界についてまだ合意がとれていませんか？\u003Cbr/>JoinXは実際の業務プロセスから開発範囲の棚卸しをお手伝いします。","要件整理の相談を予約する","/contact-us","情報システムは、最初の打ち合わせですべての答えを決め切る必要はありませんが、少なくとも「いま何を解決したいのか」は把握しておく必要があります。\u003Cbr/>JoinX（哲煜科技）は、プロジェクトの実情に応じて、要件整理、プロセスと機能の企画、UI／UXデザインから、システム開発、テスト、本番公開まで、業務要件を実行可能なシステム計画へ段階的に落とし込むお手伝いをします。\u003Cbr/>政府・公共機関の案件は、適用される政府調達手続き、入札書類および個別案件の規定に従って進める必要があります。","30分の要件すり合わせを予約する","政府情報システムの要件整理","2026/09/02","md",[551,552,553,554,555],{"question":471,"answer":474},{"question":478,"answer":481},{"question":485,"answer":488},{"question":492,"answer":495},{"question":499,"answer":502},false,true,{},"/ja/article/government-information-system-requirements-specification-guide",10,{"title":90,"description":100},[563,566,569,571,574],{"name":564,"issuer":565},"情報関連システム開発・保守注意事項（経済部水利署及び所属機関）","経済部水利署（内部規範）",{"name":567,"issuer":568},"政府調達法第26条執行注意事項","行政院公共工程委員会",{"name":570,"issuer":568},"政府調達法 第34条第1項",{"name":572,"issuer":573},"サイバーセキュリティ管理法 第10条","現行法規",{"name":575,"issuer":573},"サイバーセキュリティ責任等級区分弁法 第11条","ja/article/government-information-system-requirements-specification-guide",{"s3:18":578},{"type":579,"cols":580,"head":581,"rows":584},"table","160px 1fr",[582,583],"確認項目","先に問うべきこと",[585,588,591,594,597,600,603,606],[586,587],"プロジェクトの目的","なぜこのシステムを構築するのか？いま最大の問題は何か？",[589,590],"利用者","どのようなロールがあるか？各ロールは何ができるか？",[592,593],"プロセス","一つの業務は開始から完了までどう進むか？",[595,596],"機能","各プロセスにはどのシステム操作が必要か？",[598,599],"データ","データはどこから来るか？何を保存・移行する必要があるか？",[601,602],"連携","既存システム、アカウント、APIとの連携は必要か？",[604,605],"制約","既存環境、セキュリティ、性能、互換性の要件は何か？",[607,608],"検収","最終的に要件が確かに実現されたことをどう証明するか？",[610,611,612,613,614,615],"すべての政府情報システムに適用できる固定の要件仕様書フォーマットは存在しません。機関、システム、調達案件ごとに要件が異なるため、実際の文書は機関内部の規定、入札書類、プロジェクトの性質に合わせて調整する必要があります。","要件は「案件管理」「会員管理」といった機能名だけでは足りません。誰が使い、どう操作し、データがどう流れ、どのような例外があり、機能完了後にどのような結果が生まれるべきかまで説明する必要があります。","要件を整理する際は、プロジェクトの目的、利用者、プロセス、機能、データ、システム連携、非機能・セキュリティ要件、テスト・検収の8つの観点からシステムの境界を確認できます。","機能要件はベンダーが範囲を理解できる粒度で書く必要がありますが、すべての技術を先に指定すべきという意味ではありません。政府調達の技術仕様は原則として、機関が必要とする機能・効果・特性を達成するために必要な要件に限定し、不必要な競争制限を避けるべきです。","開発範囲に本当に影響するのは、主要機能だけではないことが多いものです。データ移行、利用者数、ピーク時のトラフィック、ロールと権限、API連携、既存環境、セキュリティ要件はいずれも、システムアーキテクチャ、スケジュール、コストに直接影響しえます。","良い要件仕様は、テストと検収まで一貫してつながっているべきです。重要な要件はそれぞれ「システム完成後、この要件が本当に実現されたことをどう確認するか」に答えられるのが理想です。","structured","2026/09/01","blog","2B6SHNSgvSPuFMmau-N8gAqt2C7XnLt7vz4cjUVevp0",[621,625,629],{"title":622,"path":623,"time":624},"物流管理システムはどう選ぶ？配車、配送の受領確認、既存システム連携のポイント","/article/logistics-management-system-guide","2026/10/08",{"title":626,"path":627,"time":628},"受注管理システムはどう選ぶ？既製ソフト・ERP・カスタム開発の比較","/article/order-management-system-guide","2026/10/07",{"title":630,"path":631,"time":632},"製造業の生産管理システムはどう選び、どう設計する？BOM・製造指図・外注加工・原価管理のポイント","/article/manufacturing-production-management-system-guide","2026/10/06",1791447831879]