--- type: guideline title: Step.5 機能要件の定義 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.5 機能要件の定義 既に定められた業務要件に基づき、業務要件を満たすために情報システムの機能に求められる要件を定義していきます。 開発の進め方や採用する技術によって具体的な作業の進め方は異なることがありますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。 ## 個々の領域について要件を定める 【標準ガイドライン関連箇所：第３編第５章第２節1)イ】 - 注記 バッチ処理とは、データの処理を即時実行（オンライン処理）せず、「10分ごと」や「毎日午前０時」などのあらかじめ決められたタイミングでまとめて実行する処理のこと。 機能要件として定義しないといけない内容は、機能、画面、帳票、情報・データ、外部インタフェースの５つです。要件定義の対象となる情報システムによっては、このうちの一部を定義しない場合もあります。例えば、バッチ処理しかしない情報システムであれば画面の定義は不要となりますし、他の情報システムと連携しないWebサイトであれば外部インタフェースの定義は不要となります。 ### 機能に関する事項 「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。基本的に「入力」・「演算(処理)」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ１つの機能です。情報システムが提供する形は様々ですが、それらを「機能」として一覧化して整理するために用いるのが、「情報システム機能一覧」と呼ばれるドキュメントです。 「情報システム機能一覧」は、業務で求められる要件を情報システムで実現するために何が必要かを「機能」で表現したものであり、その概要や処理方式等を併せて記載し、情報システムの設計・開発を行う事業者に、情報システムに求められる要件を正しく伝えます。 - 表5-3 情報システム機能一覧
No.

機能

ＩＤ

機能

分類

 機能名 機能概要

処理

方式

利用者

区分

 現状の機能との差異 補足
入力 処理 出力
1 XXXX ○○申請書登録 ○○登録機能 記載事項の入力 ・・・ ・・・ オンライン ○○申請者 ・・・ ・・・
2 XXXX ○○申請書出力 ○○出力機能 出力方式の選択 ・・・ 申請書の出力 オンライン ○○申請者 ・・・ ・・・
3 ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・
情報システム機能一覧は、基本的に１つの情報システムについて１つ作成します。（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）一覧では、１機能の情報を１行で表現し、この情報システムで使用する機能は全て定義されます。 この一覧は、業務要件の内容を詳細化し、そこから機能要件を取り出すことで作成することができます。例えば「○○申告書をオンラインで作成する」という1つの業務要件は、「申告内容を新規登録する」「申告内容を更新する」「申告内容を削除する」「○○申告書を作成する」「○○申告書をＰＤＦでダウンロードする」等に分解できます。ここから、必要な機能を特定します。 １つの機能が複数の業務要件に使われることもあります。同じ機能を重複して記載しないようにしてください。 情報システム機能一覧は、後工程の開発・設計で構築作業のインプットとなりますが、構築範囲や対象を特定する情報ともなります。事業者が設計・開発に関する作業を計画する際、機能を1つの単位として考えることが多いため、発注者としてはこの一覧の内容まではしっかり理解し、この一覧を利用して事業者と会話できるようにしてください。 また、忘れがちなのが情報システムを管理するために必要な機能です。ユーザアカウントの追加削除、マスターデータの更新等、各種バッチ処理の実行、ログの記録や検索等、システム管理者が操作するための機能等も忘れずに検討してください。 クラウドサービス、パッケージ製品と比較できる粒度で整理 昨今のクラウドサービスやパッケージ製品は、様々なものが開発され、提供されています。「こんなものはないだろう。」といった先入観は持たず、まずは世の中にあるかどうかを確認し、採用が可能かを検討しましょう。 採用可否の判断の１つは、クラウドサービスやパッケージ製品が提供する機能群と、求める機能群との適合性です。正確に比較するには、双方の機能を同じ粒度に揃えることがコツです。具体的にはその機能が扱う情報を「入力」・「演算(処理)」・「出力」の何れかに分解できるレベルに揃えることが１つの指針となります。 これにより、何が既にある機能で、何が新しく追加しなくてはいけない機能なのかを判別することができます。 ### 画面に関する事項 情報システムの画面は、利用者が業務の流れの中で情報システムとやり取りを行う窓口となるため、画面上で取り扱う情報の種類、画面を構成する要素の配置は、利用者の業務効率や満足度に大きな影響を与えます。 この画面に関する要件を取りまとめるドキュメントは、一般的に画面一覧、画面イメージ（画面モックアップ）、画面遷移図、画面設計方針書（画面設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。 - 画面一覧 画面一覧とは、情報システムで実現する全ての画面の要件を画面の単位で定義し、一覧化したものです。これにより、画面ごとの入出力要件や該当機能等を把握できます。 画面一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１画面の情報を１行で表現し、対象とする情報システムで使用する画面が全て記載されます。画面の要件は、該当機能を実現する画面をイメージしながら、画面名、画面概要、入出力要件等を整理し記述します。複数の機能で同一の画面を使用する場合もあることに注意してください。 - 表5-4 画面一覧
No.

画面

ＩＤ

画面

分類

 画面名

画面

概要

 画面入出力要件

画面設計

要件

該当

機能

利用者

区分

 補足
1 XXXX 申請書作成画面 ○○申請書作成 ○○申請書の作成画面

表示方法：・・・

入力操作概要：・・・

 Ｗｅｂブラウザで表示可能であること。

機能ＩＤ:

XXXX

 ○○申請者
2 XXXX ○○申請書確認 ○○申請書の作成確認画面

表示方法：・・・

入力操作概要：・・・

 ・・・

機能ＩＤ:

XXXX

 ○○申請者
3 XXXX 申請書登録画面 ○○申請書登録 ○○申請書の登録画面

表示方法：・・・

入力操作概要：・・・

 ・・・

機能ＩＤ:

XXXX

 ○○申請者
4 XXXX 申請書出力画面 ○○申請書出力 ○○申請書の出力方法確認画面

表示方法：・・・

入力操作概要：・・・

 ・・・

機能ＩＤ:

XXXX

 ○○申請者
- 画面イメージ（画面モックアップ） 画面イメージ（画面モックアップ）とは、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。HTML等で作ることで具体的な処理が組み込んでいないだけでほぼ実現したい画面の最終形になっているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方をされます。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。 要件定義の段階では、改修などの少数の画面に特定されている場合は別ですが、基本的には全画面のうち代表的なものについてのみ画面イメージを作成します。後工程で画面ごとに内容を確定させますので、要件定義の段階では代表的なものや特徴的なものが定義されていれば通常は十分です。 既存の情報システムがある場合は、その画面をベースに、追加・変更箇所がわかるようにする方法もあります。 - 図5-4 画面イメージの定義例 ![](../assets/ds-120-ch05-image7.png) - 画面遷移図 画面遷移図とは、画面間の遷移を図に表したもので、画面間の関係や画面の流れをイメージすることできます。 画面遷移図は、画面と画面とを線で結び、矢印で方向を示すことで、どの画面からどの画面に遷移するかを示します。画面遷移図を見ることで、情報システムで実現する画面群全体を俯瞰的に捉えることができます。その情報システムにおける基本的な画面遷移パターンと比べて、特殊な画面遷移をしている個所は、特別な理由が無ければ修正し、基本的な画面遷移パターンに合わせることで、統一感のある使いやすい情報システムとなります。 - 図5-5 画面遷移図 ![](../assets/ds-120-ch05-image8.png) - 画面設計方針書（画面設計ポリシー） 画面設計方針書（画面設計ポリシー）とは、画面設計を行う際の方針や遵守すべきルールを記載したものです。構築する情報システム全体として、どんな画面にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての画面をこの方針書に基づき設計していくことになります。 画面設計方針書は、既存情報システムや類似情報システムを参考にして、基本的な画面デザイン、ボタンの配置、画面遷移、操作手順等を検討した結果が記載されます。標準ガイドライン解説書「第３編第５章２．1)ウa) ユーザビリティ及びアクセシビリティに関する事項」の定義内容との整合にも気をつけてください。 基本的には、画面デザインはシステム全体を通じて統一することが好ましいです。利用者にとっても操作方法を覚えやすくなりますし、システムを維持運用する観点からも改修等が行いやすくなるからです。とはいっても、業務の内容によっては、その業務に特化した専用画面を作ったほうがよいこともあるでしょう。統一するか、個別に作り込むか、最終的にはその画面を見る人の利便性を重視して、決めていきましょう。 画面イメージや画面遷移図を細かく決めすぎない 画面に関する事項の検討は、実際に利用する業務実施部門の職員の意見を取り入れることにより、利用者の満足度向上につながります。一方で、現場職員の意見を聞きすぎると、微細な点にまで議論が及び、いつまでも要件が確定しないという事態に陥りがちです。 また、詳細に決めすぎると、クラウドサービスやパッケージ製品の採用を検討するときに、「適合するものがない」「大幅なカスタマイズが必要」という結論に至る弊害が考えられます。 要件定義で定める内容は、あくまで作業規模の見積りとなる元情報及び、具体的なレイアウト・画面遷移を設計するに当たっての要求事項に過ぎません。最終的には、設計段階で画面レイアウトの詳細を決めますので、この段階では不必要に詳細部分にまで入り込む必要はありません。 - 注記 ソフトウェアフレームワークとは、アプリケーションを開発する際に必要となる汎用的な機能や部品等をまとめて提供し、アプリケーションの枠組みとして機能するソフトウェアのこと。 設計の技術的な前提条件を明記する 画面の設計・開発において前提となる各種標準やミドルウェア、ソフトウェアフレームワーク等が事前に決定されている場合は、それらの前提となる環境を画面設計方針書に詳細に明記します。また、画面イメージを検討する際には、それらの前提を踏まえた上で方針を決定してください。ミドルウェアやフレームワーク等によっては、出力イメージの実現に多大な工数が必要となる場合や実現不能となる場合があり、画面イメージが方針に沿っていないと設計時に大幅な手戻りを招く可能性があります。 ### 帳票に関する事項 情報システムの帳票とは、サービス・業務で使用するために情報システムから出力した紙やＰＤＦ形式等の電子帳票を指します。帳票は、利用者が業務上意識して用いられるものであるため、業務の内容やきっかけと結びついた重要な情報を持ちます。 帳票に関する要件を取りまとめるドキュメントは、一般的に帳票一覧、帳票イメージ、帳票設計方針書（帳票設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。 - 帳票一覧 帳票一覧とは、サービス・業務で使用する全ての帳票の要件を帳票の単位で定義し、一覧化したものです。これにより、帳票ごとの入出力要件や入出力形式、該当機能等を把握できます。気をつけたいのは、帳票一覧には情報システムが入出力しないものも記載する点です。明確に区別した上で、サービス・業務で取り扱う全ての帳票を記載することにより、管理がしやすくなります。 帳票一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１帳票の情報を１行で表現します。 帳票一覧は、業務の流れを意識して整理する抜け・漏れが防ぎやすいため、業務フロー図と整合性を取って作成します。帳票概要は、誰が、どのような契機で、何のために、帳票をどうするかを記述します。また、入出力形式として紙、電子ファイル（ＰＤＦ等）の形式も明確にします。 - 表5-5 帳票一覧（例）
No.

帳票

ＩＤ

 帳票名

帳票

概要

 入出力の区分

帳票

入出力

要件

帳票

設計

要件

入出力

形式

該当

機能

利用者

区分
1 XXXX ○○申請書 ○○申請用 出力 モノクロ印刷

用紙サイズ：A4

用紙の指定：XX

 紙

機能ＩＤ:

XXXX

 ○○申請者
2 XXXX △△申請書 △△申請用 出力 カラー印刷

用紙サイズ：A4

用紙の指定：XX

 ＰＤＦ

機能ＩＤ:

XXXX

 △△申請者
3 XXXX
- 帳票イメージ 帳票イメージとは、画面イメージと同様に、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。Excel等で作ることで詳細な項目まで表現されているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方があります。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。 要件定義の段階では、改修などの少数の帳票に特定されている場合を除き、全ての帳票に対して帳票イメージを作成することは無く、代表的な帳票から選定して、異なる種類分を作ります。後工程で帳票ごとに内容を確定させますので、代表的・特徴的なものが定義されていれば、通常は十分です。既存情報システムの帳票があればそれを基に、今回追加変更したい内容がわかるように情報を加えます。基になるものがないような新規のサービス・業務の場合は、紙やホワイトボード等にイメージを描きながら、職員と事業者とが対面で内容を擦り合わせます。 法定帳票等、既にフォーマットが決定しているものは、その内容を明示します。 - 図5-6 帳票イメージの定義例 ![](../assets/ds-120-ch05-image9.png) - 帳票設計方針書（帳票設計ポリシー） 帳票設計方針書（帳票設計ポリシー）とは、帳票設計を行う際の方針や遵守すべきルールを記述したものです。構築する情報システム全体として、どんな帳票にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての帳票をこの方針書に基づき設計していくことになります。 帳票設計方針書は、作成した帳票一覧や帳票イメージ以外にも、既存情報システムや類似情報システムを参考にして、基本的な帳票デザイン、種類、様式、項目や罫線等の構成要素を検討した結果が記載されます。 帳票のレイアウトイメージを細かく決めすぎない 画面に関する事項と同様に、帳票レイアウトイメージも過度に細かく決めすぎないことが重要です。ここで決めた内容は、具体的なレイアウトを設計するに当たってのイメージ（要求事項）として扱われ、設計結果（確定したもの）として扱わないよう留意してください。 なお、法定帳票やOCRで読み取りをする帳票等、帳票レイアウトが確定しているものについては、レイアウトの定義を要件として明記します。 - 帳票のレイアウトイメージは、要求事項を伝えるための表現方法として使用し、具体的なレイアウト等の設計結果を示すものとは区別して記載すること。 - 帳票の利用目的を考慮し、法定の帳票や外部連携に用いる帳票等、業務の処理において不可欠な帳票を優先して整備する。 - 複数の機能で同一の帳票レイアウトを使用する場合は、１つの帳票に複数の機能を紐付ける形で整理する等、帳票の種類がわかるように記載する。 - 法定帳票等、帳票レイアウトが確定している場合は、遵守しなくてはいけない点（項目が満たされていればよい、配置も同一でなくてはならない、印刷位置をミリ単位で厳守しなくてはならない等）を明確に記載する。 設計の技術的な前提条件を明記する 帳票の要件として、「紙面に記載する情報」「紙面のレイアウト」に関して定義が必要であることは、想像がつきやすいのですが、「帳票を生成する方式」や「出力先」も要件の重要な要素です。バラバラの要件では、情報システムの構築にかかる費用見積りが過度に高くなる可能性があるため、同じような要件は可能な限り統一し、共通化できるように整理しておくことが有効です。 - 帳票の設計・開発において前提となる各種標準やミドルウェア、フレームワーク等が事前に決定されているときは、それらの前提となる環境を詳細に明記すること。 - 出力先として複数のプリンタを使用し、プリンタの印字方式に制限があるとき、出力用紙にカーボンコピー用紙を使用する等の条件があれば、補足にその旨を記載すること。 ### データに関する事項 ここで定義する情報システムのデータとは、情報システムの中（データベース等）で管理されるものであり、利用者にとっては目に見えないものですが、当該情報システム内で使われるのはもちろん、国民共有の財産であるという認識に立ち、広く一般に利活用されることを想定したものでなければなりません。 一方、こうしたデータの利活用を効果的なものにするためには、当然のことながら、データそのものの品質が十分に確保されていなければなりません。 すなわち、「データの利活用」と「データの品質確保」は、情報システム構築の際に欠かせない重要な要件となっています。 そこで、要件定義フェーズでは、プロジェクト計画書で記載した「データ利活用の方向性」に基づいて、情報システムで管理するデータの利活用や品質確保のための考え方を盛り込んだ、データに関する定義を記載します。具体的には、以下の分類に沿って、利活用するデータを識別・再構成し、各々の括りごとに、データ要件として定義します。 - 図5-7 データの利活用と品質確保 ![](../assets/ds-120-ch05-image10.jpeg) データ要件の定義にあたり、既存の情報システムのデータについては現行の機密性レベルや標準化レベル等の品質を改善すること、新規の情報システムのデータについては品質を十分に確保できるような定義を行うよう努めましょう。具体的な要件定義ドキュメントの説明に入る前に、これらデータの利活用方針や品質確保のための考え方や留意事項を、以下に順を追って説明します。 #### オープンデータの範囲と公開方法 - オープンデータの定義と分類 「オープンデータ基本指針」（平成29年５月30日高度情報通信ネットワーク社会推進戦略本部・官民データ活用推進戦略会議決定）において定義されている内容を踏襲しますが、さらに以下の分類を行います。（図5-8参照） - オープン可能データ：情報システム上に存在するデータのうち、以下のものを除くすべてのデータ。 - 個人情報が含まれるもの - 国や公共の安全、秩序の維持に支障を及ぼすおそれがあるもの - 法人や個人の権利利益を害するおそれがあるもの - 法律等によって用途が制限されているもの - オープン状態データ：オープン可能データのうち、外部から人為的な手続きを経ずに取得できる状態（ダウンロードサイト、Web-API公開など）になっているデータ。 - オープン待機データ：オープン可能データのうち、外部から申請等の手続を経て取得できるデータ。 - 注記 オープンデータは機械判読性に基づいた公開レベルによってレベル１（★１）～レベル５（★５）の５段階に分類される。この評価指標を「５スターオープンデータ」といい、PDFは★１、XLSは★２、CSVは★３に該当する。 「５スターオープンデータ」 - 図5-8 オープンデータの分類 ![](../assets/ds-120-ch05-image11.png) - オープンデータの範囲と公開方法 上記「オープンデータの定義と分類」に基づき、情報システムで管理するデータに関し、以下の情報を定義します。 - オープン可能データの識別 後述の「データ一覧」の「公開可否」列に明記する。オープン可能データ以外については、その理由も「公開不可の理由」列に記述する。 - オープン状態データの一覧（「オープンデータ一覧」として一覧化） オープン状態データの名称、概要・用途（メタ情報）、利用者及び公開の範囲、利用目的、利用頻度・特徴、実装方式、処理方式等を記述する。 この時、オープン可能データの中で、オープン状態データの割合ができるだけオープン待機データより大きくなるようにしましょう。また、オープン状態データの中でもPDF形式よりはCSV形式、さらにはWeb-APIの公開というように、より活用の幅が大きくなるような公開形式を計画してください。 なお、オープン可能データの中にも、利用者ニーズに差があったり、意味のある公開データにするためには多大のコストがかかるものが存在したりします。利用者ニーズの大小や費用対効果を勘案の上で公開の範囲や優先度を決定するよう心がけてください。また、オープン待機データについては、そのメタ情報を公開し、様々な公開ニーズの発掘に努めましょう。 #### データの品質確保のための考え方 ![](../assets/ds-120-ch05-image12.png)データ機密性定義と管理方法 ここでは要件定義として明らかにしておくべきデータの機密性定義とその管理方法について説明します。情報セキュリティに関する全般的な事項、つまり機密性、信頼性、可用性などに関する全体的なことは別章の「情報セキュリティに関する事項」及び「信頼性に関する事項」を参照してください。 個人情報漏えいのニュースは報道等で大きく取り上げられ、その管理責任が問われることも頻繁に起きている状況が続いています。情報システムを構築し管理する組織としては、その重要性を認識し、システムの構築段階からデータに関する取り扱いを明確化し、適切に対応していくことが求められています。 要件定義においては、情報システムで取り扱うデータに関して機密性レベル別に分類し、その管理方法を定義しておく必要があります。システム内に存在することになるデータに関して、その機密性を認識し、分類し、またその管理方法を「データ要件」として記述することにより、その後の設計・開発作業に確実に繋げていくことができます。 下表5-6は、行政文書に関して整理した参考例ですが、個人情報等もこの分類で対応させて管理方法等を決めると分かりやすい整理ができます。なお、下表5-6の記載内容はあくまで参考であり、最終的な秘密文書の定義の判断は、行政文書の管理に関するガイドライン（https://www8.cao.go.jp/chosei/koubun/hourei/hourei.html ）を参照の上、決定することに留意してください。 - 表5-6 参考：行政文書に関する整理（電子的管理を含む）

分類1

分類2

分類3

概要説明

 備考

特定秘密

防衛、外交、特定有害活動、テロリズム関連でその漏えいが我が国の安全保障に著しい支障を与えるおそれのある情報。

クラウド不可

秘密文書

極秘文書

機密性3

行政事務で取り扱う情報のうち、秘密文書に相当する機密性を要する情報。

（特定の職員のみ取り扱い）

クラウド不可（インターネット接続端末への保存不可）

秘文書

機密性3

同上

クラウド可（インターネットからの侵入に対する適切な情報セキュリティ対策が必要）。

機密性2

行政事務で取り扱う情報のうち、秘密文書に相当する機密性は要しないが、漏えいにより、国民の権利が侵害され又行政事務の遂行に支障を及ぼすおそれがある情報（職員のみ取り扱い）。

要機密情報（機密性２以上）については、特にその取扱制限を検討する。

＊個人情報等に該当。

機密性1

機密性２情報、機密性３情報以外の情報。

（職員以外も取り扱い可）
- 注記 「政府機関等のサイバーセキュリティ対策のための統一基準（令和５年度版）」（NISC（内閣サイバーセキュリティセンター）　令和５年７月４日） 　 「行政文書の管理に関するガイドライン」（内閣府　平成２３年４月１日決定、令和２年７月７日一部改正） 「特定秘密の保護に関する法律」（内閣官房　平成２５年法律第１０８号） 「特に厳格な管理を要する行政文書の取扱い等に関するマニュアル案（概要）」（内閣府　令和元年７月２５日） まだ明確に定義できないデータもあると思いますが、特に機密性の高いデータに関しては、その洗い出しと分類、及び管理方法を可能な限り具体的に記述しておきましょう。情報の管理責任は発注者側にあります。その重要性を再認識し、要件として定義することが、情報漏えい等の問題を起こさない最も重要な作業の一つであると言えます。 整理する内容としては、データ名称、個人情報／特定個人情報の有無、保管方法（別の端末には置かない等）、暗号化有無、格付・取扱・アクセス制限設定（人、プログラムから等）、履歴管理（更新、参照者の特定レベル）、運用管理／手順のレベル等です。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(2) データ一覧」を参照ください。　 ![](../assets/ds-120-ch05-image12.png)マスターデータの標準化 マスターデータとは、「データを利用してサービスを実現するときに必要となる基本情報のことです。例えば、目的に合わせた基本データ集として整理された台帳のようなものや、個人、組織、事業所、場所等の基本情報をリスト化したもの」（マスターデータ等基本データ導入実践ガイドブックより）です。例えば情報システムでは事業所の情報（会社名、事業所名、事業所番号、事業内容、住所、従業員数等）の一覧が電子リスト（マスターデータのこと）として定義され、システム内の各機能（プログラム）から参照することにより、事業所番号を入力するだけで関連する事業所の情報を画面に表示して選択を促すというような処理で利用されます。 - マスターデータの標準化の重要性 上記のとおり、一つの情報システム内でも様々なプログラムから参照されるマスターデータは、その情報の特徴から他のシステムでも同じような情報が必要になることが多くあります。例えば事業所の例では、一つのシステムに限らず、事業所情報を必要とするシステムは多数あります。それらシステム毎に事業所のマスターデータを定義していたのでは非効率ですし、また使用するコードや項目も異なり、システム間で情報を連携する場合など、そのままでは情報交換することができなくなります。そういった非効率さをなくし連携までの時間を短縮するためにも、マスターデータは同じ目的で使用したい人達のために、より広いシステムの範囲で同じ内容のものを参照することが重要ということになります。そのレベルは、地方自治体も含めた国全体で一元化し標準化するべきもの、省庁内で一元化し標準化するべきもの、あるいは部局内同種の業務で一元化し標準化するべきもの、などその標準化の範囲はそれぞれで最適なものを決定していく必要があります。現行システムで既にマスターデータが存在するものについては、その標準化レベルを改めて確認し、最適な標準化のレベルに向けて計画的に改善していきましょう。政府情報システムとしては、自分達主導でより広範囲の標準化を目指すことを基本とします。また、一般公開することで民間の利用も促し、社会全体として効率よくかつ均質化したサービスも提供できるようになります。 - マスターデータ定義の考慮点 要件定義では、マスターデータとして分類されるものを定義し、その標準化レベルと公開方針等を決定します。分類とその考慮事項は下記を参照ください。 - 表5-7 マスターデータの分類と考慮事項

No

マスターデータ定義のケース分け

 考慮事項

1

外部から入手（購入あるいは利用）し、そのまま活用する場合

国内外の各種標準や関連団体等を調査し、その更新頻度／更新情報の入手方法、提供形態、保証／契約、意味定義の明確さ、項目数／レコード数の充足度　等を自システムの利用シーンと照らして決定する。

2

外部から入手し、項目を追加などして活用する場合

１に加え、追加項目の別ファイル／データベースでの管理方法（オリジナルが更新された場合の考慮）、更新同期等を考慮する。

3

自システムで作り公開する場合

（他も参照するマスターとして提供）

他システムの要件を満たすための調査あるいは調整有無とその工数・期間、公開範囲（公開項目）、公開方法（※）、詳細なメタ情報作成、更新運用等を考慮する。

4

自システムで作り公開しない場合

公開できない理由の明示

（１，２あるいは３で、極力他システムとのスムーズな連携の土台となるシステムを目指すこと。）
※マスターデータの公開に関しては、オープンデータとしてe-Govデータポータル（https://data.e-gov.go.jp/info/ja ）への公開を推奨する。 - マスターデータの要件定義書への記載 要件定義としては、データ一覧をマスターデータとマスターデータ以外（トランザクションデータ、入出力ファイル等）に分けて作成し、データ名、概要・用途（メタ情報）、規模情報、マスターデータ分類、分類選択理由、標準化レベル（国際標準、国内標準、省庁標準、部局標準）、公開有無と範囲等を記載します。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(2) データ一覧」を参照ください。 なお、要件定義フェーズではまだ項目の詳細は決まらないかもしれませんが、メタ情報として可能な範囲で具体的に記述してください。より詳細な設計・導入の手順などは「マスターデータ等基本データ導入実践ガイドブック」を参照ください。 ![](../assets/ds-120-ch05-image12.png)データ項目（コードを含む）の標準化 データ項目とは、情報システム内で取り扱う電子化された情報の基本単位と言えます。例えば、書籍名、著者名、貸出日、出版社コード等、その各々が異なる一意の対象を表します。また、データ項目の中には、出版社コードのように出版社を特定するためにコードとして表すことも広く使われています。コードはＮ個の記号（例：ＡＢ５ＦＤＳ）やＭ桁の番号（例：９９０５６３）などで表すこともあります。 一方、情報システムでデータ項目を取り扱うということは、紙に書かれた文字情報を人が読むのと大きく異なります。人は紙に書かれた文字の多少の揺れや歪みを理解できるので、「貸出日」と「貸出し日」は表記が異なるだけで同じ意味の言葉であると理解できます。一方、コンピュータは情報システム内のデータ項目を機械的に読むため、「貸出日」と「貸出し日」を別物として認識してしまいます。データ項目をそれぞれ別物と認識したらそのデータ項目を扱う処理も別となり、大きなトラブルにもなりかねません。よって、情報システムで取り扱うデータ項目は厳格な定義と扱いが求められます。 - データ項目（コードを含む）の標準化の重要性 データ項目（コードを含む）の中には、他のシステムでも同じ目的で使うものが多くあります。それらの項目は、同じ項目名で同じ意味定義で設計されていると、お互いの連携をスムーズにかつ間違いなく行うことができます。つまり、マスターデータと同様に、より広範囲なデータ項目（コードを含む）の標準化を行えば、より効率的に短期間で他との連携ができることになります。また、データ項目やコードを一般公開することで民間での利用も促すことができます。「データ流通時代」と言われる今後のデジタル社会において、常にデータ項目及びコードを標準化しオープンデータとして公開することを念頭に要件定義を行うことは非常に重要です。 - データ項目（コードを含む）の標準化の考慮点と要件定義書への記載 要件定義書では主要なデータ項目とコードを洗い出し、発注者としてそれらの定義を行います。最終的には基本設計工程で全てのデータ項目とコードが定義されることになりますが、業務上主要なデータ項目とコードについては発注者がその標準化レベルを決め、意味を定義し、事業者に指示する形にすることが重要です。マスターデータと同様に、発注者（自分達）主導でより広範囲の標準化を目指しましょう。また、多くのデータ項目やコードは業務の方向性・範囲と密接に関係していますので、その点でも、発注者側がデータ項目やコードを定義することで、要件及び仕様の連携が確実かつ正確に行われることにも繋がります。 - 主要なデータ項目及びコードについては、要件定義書に記載すること。より広い範囲での標準化を目指すこと。 - また基本設計工程では全てのデータ項目（コード含む）の厳格な意味定義を行うこと、及び標準化の推進を事業者にも促すこと。 - なお、コード及びコード以外のデータ項目標準化に関して、「コード（分類体系）導入実践ガイドブック」、「文字環境導入実践ガイドブック」及び「行政基本情報データ連携モデル」を業務の方向性・範囲に応じて参照することを推奨する。 要件定義としては、「データ定義」に標準化レベル（国際標準、国内標準、省庁標準、部局標準）、「コード一覧」にコード標準化分類、分類選択理由、標準化レベル等を記載します。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(3) データ定義」及び「(5) コード一覧」を参照ください。 ![](../assets/ds-120-ch05-image13.png)ライフサイクルを通じたデータの品質確保 異なる機能や画面から同じデータを修正、削除できるようにすることはよくありますが、その際に部分的な観点から処理を行ってしまうとデータの不整合が発生しかねません。 一貫性や完全性等の観点からデータの品質を確保するためには、情報システムの中で扱うデータについて重複なく全体を定義した上で、それらのデータが設計時点だけでなく運用時点でも品質が保たれるようにライフサイクルでの管理を行うことが重要です。 データに関する要件を取りまとめる際には、このような観点を踏まえたうえで、データモデル、データ一覧、データ定義、CRUD マトリクス、コード一覧、コード内容定義、オープンデータ一覧等のドキュメントを整備することが重要です。これらのドキュメントは、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります）。また、これらのドキュメント間の整合性を保つとともに、画面や帳票の要件を定義したドキュメントとも整合性を保つことが望まれます。 - 表5-8 データの要件を取りまとめる際に整備するドキュメント例 ![](../assets/ds-120-ch05-image14.jpeg)
No. ドキュメント名 説明
1 データモデル

  • 画面や帳票などに含まれる情報を抜き出して、意味のある単位（識別キー）ごとにまとめた情報の集合体である「データ」と、他のデータとの関連を1枚に表現した図で、ER（Entity Relationship）図という表記法で記述します。

  • 基本的に1つのデータ項目は、必ずどこか１ヶ所のデータのみに属するようにデータを定義します（これを「正規化」と言います）。

  • データモデルには「概念データモデル」「論理データモデル」「物理データモデル」の3種が存在しますが、要件定義では「概念データモデル」を定義する事が多いです。

  • また、情報システムによっては要件定義時点でデータモデル定義を必要としないものもあります。
2 データ一覧

  • データがどのようなまとまりの単位になっているかを一覧形式で示す表で、データモデルやデータ定義の目次として利用されます。

  • マスターデータとマスターデータ以外に分け、データの用途や保存期間、データ件数などを定義します。
3 データ定義

  • データ一覧にあるデータのまとまり単位にそれぞれに含まれるデータ項目の内容・説明を示す表です。

  • １つ１つの項目がどのような意味を持ち、どのような表現やルールで記録されるかなどを定義します。
4 CRUDマトリクス

  • データが、機能一覧で定義した機能の時系列の流れの中でどう変化するのかを定義します。CRUDとは、C:Create（生成）、R:Read又はRefer（参照）、U:Update（更新）、D:Delete（削除）の頭文字を取ったものです。
5 コード一覧

  • その情報システム内で使用するコードの用途や構造を定義します。
6 コード内容定義

  • コードの値ごとに意味を持たせた場合の、コード値と意味の一覧です
７ オープンデータ一覧

  • データ一覧で示したデータのうち、オープンデータとして扱うデータの一覧です。

  • 各オープンデータの利用者や実装方式、処理方式を定義します。
これら7つのドキュメントの詳細や機能一覧との関係性については、別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」を参考にしてください。 - 図5-8 情報・データ定義作業のイメージ 後の工程で作られる情報に関する設計書等のドキュメントは、専門的な情報や記法で記載されることが多く、内容を詳しく理解するには難しいものになります。したがって、ここで作成するドキュメントとそれら専門的なドキュメントとの内容を同期させることを事業者に依頼し、専門的なドキュメントを見なくても、要件が充足しているかをチェックできるようにしてください。

社会・環境変化に応じてサービス・業務の質を継続的に維持又は向上していくためには、サービス・業務を進め方の改善を行う工夫が必要となります。その工夫を生み出すためには、サービス・業務に関係する情報・知識・知恵も必要となります。では、情報・知識・知恵はどうやって生まれるのでしょうか？

サービス・業務の目的に応じて様々な文書や帳票類を作成又は取得するなどし、それらに対しての確認や処理を行い、何らかの結果を生み出してサービス・業務を実施していくことが多いと思います。サービス・業務で扱う文書や帳票類には様々なものがあり、紙で扱うものもあると思いますが、現在ではそのほとんどが文書作成ソフトや表計算ソフト等を利用してデジタル処理を行うことが多いと思います。例えば、何らかの数値を集めて統計処理の対象となる統計データの場合には、デジタル処理することがほとんどだと思います。また、行政文書については、公文書等の管理に関する法律（平成二十一年法律第六十六号）第二条において、電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。）も文書と定義されています。統計データ、電磁的記録による文書、つまりデータを日常的に扱い、サービス・業務を遂行していることになります。さらに、「世界最先端デジタル国家創造宣言・官民データ活用推進基本計画」（令和元年６ 月14日　閣議決定）において、官民データを活用して証拠に基づく政策立案（EBPM）を推進することが示されており、政策立案というより高度なデータ活用が期待されています。

サービス・業務の遂行に必要となるData（データ）、Information（情報）、Knowledge（知識）、Wisdom（知恵）の関係性を示したのがDIKWモデルです。このモデルは1980年代に検討された思考モデルであり、その後改良され多くの分野で定義されていますが、その代表的なものを下図に示します。

DIKWモデルから考えると、「情報」の品質はデータの品質に影響を受け、同様にして「知識」の品質は情報の品質の影響を受け、「知恵」の品質は知識の品質に影響を受けることになります。つまり、全ての土台となるデータの品質が情報・知識・知恵に影響を与えることになるので、品質の悪いデータから導かれた情報・知識・知恵を利用してサービス・業務を遂行する場合には、十分な価値を提供できないと考えられ、砂上の楼閣になりかねません。誤ったデータを利用してデータサイエンスによる高度な分析を行ったとしても、その分析結果が正しいと言えるでしょうか？

![](../assets/ds-120-ch05-image15.png)

サービス・業務の目的の達成に必要となるデータの項目、その意味や内容などを表すデータの定義を十分に行わないと、データを使いたいときにすぐに引き出して利用できない、誤って不適切なデータを利用して誤った結果を導き出してしまうなどサービス・業務に支障をきたすかもしれません。つまり、品質の低い（不完全な、不正確な、有効期限切れなど）データは、誤用又は誤解を招くリスクがあります。このリスクを回避するためには、場合によっては語の整理を行い、サービス・業務に特化した辞書（用語集）を作成・管理するのもよいでしょう。また、ある意味を表す言葉が1語に決まれば問題ないのですが、似た意味を持つ語を複数用いることを許す場合には、カテゴライズして類語辞書を作成・管理することも必要です。

サービス・業務が安定的にその目的を達成していくためには、データの意味定義だけではなく、入力・取得したデータの中身について次のような評価軸（例）で継続的に確認しつつ、適切に品質を管理することが重要です。

  • 一貫性：データに不整合はないか？一貫して表現されているか？

  • 完全性：データに欠損はないか（全ての要素は揃っているか）？

  • 正確性：表現すべき「現実世界」の対象や事象を正しく表しているか？

  • 精度：データの詳細度（有効桁数等）は十分か？誤りやノイズはないか？

  • 一意性（重複排除）：同じ実体を示すデータに重複はないか？

　データ品質を適切に管理するためには、時間推移に伴う社会・環境変化を考慮し、データの更新・修正のタイミングや廃棄の考え方を検討した上でデータライフサイクル（計画、設計と実装、生成・取得、格納・維持、利用、強化、廃棄）の管理を行うことが必要となります。いつまでも古いデータだけを用いていたのでは、適材適所でないサービス・業務を提供するおそれが強まり、目的を達成できずじまいになりかねません。

「デジタル手続法（情報通信技術の活用による行政手続等に係る関係者の利便性の向上並びに行政運営の簡素化及び効率化を図るための行政手続等における情報通信の技術の利用に関する法律等の一部を改正する法律（令和元年法律第16号））」が令和元年５月31日に公布されたので、今後、データをさらに活用して行政のデジタル化を推進していくことになり、これまでのITガバナンスの強化だけではなく、データ・ガバナンスの強化も必要となります。加えて、サービス・業務の質を継続的に維持又は向上していくためには、前述したデータの意味定義及び品質管理、そしてデータライフサイクルの管理を含めたデータ・マネジメントをプロジェクトの全体を通して行う、全ての土台となるデータの適切なマネジメントが不可欠です。

また、ＰＪＭＯは、調達手続を通じて、サービス・業務企画や要件定義の内容等が事業者に明確かつ十分に伝達されるようにするのと同様に、データ定義を十分に行った上でその内容等を事業者に明確かつ十分に伝達されるようにすることが求められます。このとき、特にデータを活用する実際のサービス・業務に深く関与する制度所管部門や業務実施部門が主体性を持って対応することが重要です。
- 参考5-3 コンピュータの内部処理とデータ項目定義

参考：コンピュータの内部処理とデータ項目定義

機能要件定義書のデータ定義では、データ項目のデータタイプや桁数等を厳格に定義することが求められています。ここではコンピュータ内部で行われるデータ処理の仕組みを通して、データ項目に対する厳格な定義の重要性を説明します。

よく「コンピュータはデジタルな処理を行う」ということや、「コンピュータは０と１だけで処理を行う」ということが言われています。画面に表示される様々な文字は私たちが読めるような形式になっていますが、０と１だけで処理が行われているというのはどういうことなのでしょうか。

コンピュータ内部では電気的信号で０と１を検出し、その２進数の値を用いて様々な処理を行います。文字を処理する例として、半角文字の‘A’は、コンピュータ内では０と１の集合、つまり２進数で（０１０００００１）２と表されます（ここではＵＴＦ-８という一般的な符号化形式を使用しています）。ただし、２進数で表すと文字列が長くなり分かりづらくなるので、その２進数をさらに変換して１６進数の形式で表すこともよくあります。（０１０００００１）2を１６進数に変換する場合、4桁ずつ（０１００）2と（０００１）２に分けられ、（０１００）2は（４）16、（０００１）２は（１）16となり、前者と後者を合わせて（４１）１６となります。

画面上にAという文字が表示されるとき、コンピュータ内部ではAという文字を（０１０００００１）2という０と１の組合せとして扱い、それを処理していることになります。私たちが通常使っている文字には、それぞれこのような値がひとつずつ割り当てられていて、それがコンピュータで内部処理されて画面などに文字として表示されるということになります。

ではなぜコンピュータで扱うデータに対して厳密な定義が重要なのでしょうか。ここでは情報システムでもよく入力する住所を例に説明します。例えば、「１丁目」と「一丁目」は人間には同じものだと理解できても、コンピュータは別のものとして理解し、別の住所として処理をしてしまいます。なぜなら、各文字には先ほど示したコンピュータ内で処理するための一意の値が割り当てられていて、「１丁目」は（ＥＦＢＣ９１Ｅ４Ｂ８８１Ｅ７９ＢＡＥ）１６、「一丁目」は（Ｅ４Ｂ８８０Ｅ４Ｂ８８１Ｅ７９ＢＡＥ）１６という値で定義され、「１」は（ＥＦＢＣ９１）１６、「一」は（Ｅ４Ｂ８８０）１６とそれぞれ別の値として扱うからです。（下線斜体は説明のため）。よって、本来同一のものとして扱われるべきデータが別物として扱われることにより、同じ住所と認識されず複数存在してしまうというトラブルを起こしてしまうかもしれません。住所の数字を算用数字で表すのか、漢数字で表すのか定義しておくことは重要なことなのです。

その他の例では、半角の‘A’は（４１）１６で全角の‘Ａ’は（ＥＦＢＣＡ１）１６となり、長さも値も全く別物になってしまいます。画面からの入力での全角と半角の違いは、人間にとっては同じことを意味していると認識できても、コンピュータの内部では全く違うものとして処理されるということです。

![](../assets/ds-120-ch05-image16.jpg)

ここで、AIを使えば同じ意味だと認識してくれるようになるのではないかという意見もあることでしょう。確かにそのとおりかもしれませんが、AIを使った処理を行うことで、コンピュータ内ではAIによる認識のために多くの処理と時間を要するのです。文字あるいは項目一つひとつにAI処理を施すとすると、莫大な処理時間あるいは高い処理性能が必要になります。

コンピュータは、基本的に０と１の組合せ列を素早く単純に処理する能力に長けています。私たちはそのようなコンピュータの内部処理を意識せずに使っていますが、この「単純で速い機械」（＝コンピュータ）を最大限に活用するためには、そこで処理させるデータの名称や意味、範囲に対する厳格な定義が非常に重要ということです。同様に、複数のコンピュータ間でデータをやり取りする場合でも、そのデータ一つひとつの定義が重要になります。標準化された、つまり同様の定義が与えられたデータを使うということがまさにデータ連携、データ流通を支える最も基本的かつ重要な事項です。

このようなコンピュータの内部処理を理解したうえで、情報システムの要件定義を行っていきましょう。
- 事例5-2 情報システムで管理するデータの保存期間

事例：情報システムで管理するデータの保存期間

Webサイトで行政手続ができる情報システムにおいて、利用者から提出されたデータは行政文書に該当し、1年以上保存する必要がありましたが、最低保存期間が満了していないにも関わらず、データが誤って廃棄されていました。これは、当該情報システムでは利用者による登録後約1か月を経過するとデータが自動で廃棄される仕組みになっていたためです。

情報システム内で作成されるデータについては、公文書管理法上の「行政文書」に該当する可能性が高いため、公文書管理のルールに則って、データの保存方法や保存期間を適切に設定することが必要です。
### 外部インタフェースに関する事項 情報システムの外部インタフェースとは、サービス・業務の内容を実現するために、自分の情報システムが他の情報システムと連携して情報を受け渡す仕組みです。情報連携の内容や形式・仕組みには様々なものがあり、明確に定義する必要がありますが、連携先である他の情報システムの都合もあるため、双方の要件を出し合い、すり合わせることが必要となります。 この外部インタフェースに関する要件を取りまとめるドキュメントは、一般的に外部インタフェース一覧と呼ばれるものです。情報システム機能要件一覧との整合性も意識しながら作成を進めます。 外部インタフェース一覧では、他の情報システムと連携する全ての情報をそれぞれの情報の単位で定義し、一覧化します。これにより、情報ごとの相手先情報システムや送受信のタイミング、条件等を把握できます。 外部インタフェース一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１つの連携情報を１行で表現し、対象とする情報システムと他の情報システムと連携が全て記載されます。要件には、連携先の情報システムとの送受信のタイミングや送受信の際の条件も、明確にして定義します。 なお、連携先となる情報システムの要件が確定していない等により、要件定義の段階で定義できない外部インタフェースの内容については、その理由を記述します。また、障害発生時や緊急時の代替手段が規定されていれば、それらも記述します。 外部インタフェース一覧で記載した連携は、情報システムが出来上がってからのテストにおいて、１つ１つテストを実施する必要があります。相手先の情報システムが同時に構築中の場合や改修が行われた場合等により、要件定義時に合意した内容が時間の経過とともに変更されていることがあります。連携先との意思疎通が不十分なときは、情報システムがリリースされて初めて問題に気付くことも少なくありません。 そういったトラブルを未然に防ぐために、事業者や相手先情報システムのＰＪＭＯと連携して、意思疎通が不十分とならないよう対策をしてください。 - 表5-9 外部インタフェース一覧
No.

外部インタフェース

ＩＤ

 外部インタフェース名 外部インタフェース概要 相手先システム 送受信区分 実装方式 送受信データ 送受信タイミング 送受信の条件 補足
1 XXXX 申請者情報連携 申請の審査に関わる申請者の情報を○○システムから日次で取得する。 ○○システム 受信 ＡＰＩ 申請者情報 リアルタイム 日次
2 XXXX 申請結果連携 審査において承認された申請情報を○○システムに日次で提供する。 ○○システム 送信 ファイル共有 承認済申請情報 リアルタイム 日次
3 ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・
情報システム関連図で連携イメージが伝わるようにする 新たに整備する情報システムと他の情報システムとの連携は、情報システム関連図を作ることで、イメージが伝わりやすくなります。 この図を中心とし、次に示す点に留意して、表5-9に示す外部インタフェース一覧に要件を整理します。 - データ互換性の確保のためにデータ変換が必要となる場合が多いことから、 - 注記 プロトコルとは、情報システムを構成する機器同士が通信をする際の手順や規約などを定めたもの。ネットワーク間で双方の機器が理解できる同じプロトコルを使わないと通信は成立しないため、インターネット上のプロトコルの大部分はRFCという形式で技術仕様が公開されている。 やり取りするデータだけでなく、物理的なインタフェース、プロトコル、フロー図、文字コード、データフォーマット、取り扱う値の範囲、通信の速度等について、可能な限り詳細に記載する。 - 双方の情報システムが取り扱う情報の格付の区分等が異なる場合に、機密情報を連携することにより情報セキュリティ対策が不十分とならないよう、連携の方向や内容等に十分留意する。 - データベースの所在国についても十分に留意する必要がある。例えば、個人情報保護法第2条第2項に規定する個人情報又は番号法第2条第5項に規定する個人番号を蓄積するデータベースについては、国内法が適用される場所に制限する必要があることを認識し、問題がないことを確認することが考えられる。 - 要件定義の段階で定義できない外部インタフェースがある場合には、その理由を含めて記載すること。 - 障害発生時や緊急時の代替手段が規定されている場合は、それらも記載すること。 ## 必要な機能を漏れなく抽出し検討する 【標準ガイドライン関連箇所：第３編第５章第２節1)イ】 要件定義を進めていくと陥りやすいのは、優先度の高いやりたい事だけを定義してしまうことです。業務要件では、毎日行う業務ばかりに議論が集中して、日常的に実施頻度の少ない業務の議論は後回しになりがちですが、機能要件でも同様のことが発生します。 - 事例5-3 要件の考慮不足がスケジュール遅延に繋がる

事例：要件の考慮不足が設計開発工程の遅延に繋がる

従来、紙で取り扱っていた申請書の管理を、オンライン入力してデータ保存できるサービスを構築することにしました。

テストの段階で、申請者が届出書に記載した内容に誤りがあった場合や、職員が情報を入力する際に間違ってしまった場合等に関する考慮が不足しており、情報システムにも修正や削除をする機能が備えられていないことが明らかになりました。従来から修正や削除の処理はありましたが、紙処理での手作業の場合は自由に作業ができたため、業務マニュアルには削除等の対応方法は記載されていませんでした。その業務マニュアルどおりにシステム機能を検討してしまったために、必要な機能の考慮が漏れてしまったことが原因でした。

![](../assets/ds-120-ch05-image17.png)

その結果、業務手順の見直しから機能の検討、追加の設計・開発、テスト等が必要となり、リリース時期に影響を与える程のスケジュール遅延が発生してしまいました。

手作業の業務をシステム化検討する際は、通常よく行う作業（上記の例では、入力や参照）だけではなく、業務マニュアルに記載されていなくても職員が暗黙的に行っている作業（上記の例では、申請内容の誤りや間違いへの対応）も含めて検討し、作業を漏れなく洗い出す必要があることに留意してください。
画面操作を例とすると、基本的な機能やよく使う機能の要件は忘れない代わりに、めったに発生しないデータの処理手順や誤入力した際の回復処理については議論が抜けがちになります。これらは要件定義漏れとして、テストをすり抜け、リリース後発覚してトラブルとなるおそれがあります。 誤入力の回復が簡単にできないと職員が認識している場合、本来行う基本的な業務で過度に慎重になってしまい、その業務のシステム利用が敬遠されてしまうことも考えられます。また、特別な処理が必要になったときに、運用事業者によるデータベース操作によるデータ補正等のアプリケーション機能以外での対応が必要となり、運用・保守費用の増大に繋がりかねません。 このような事態に陥らないためには、業務要件から機能要件を抽出する際、業務の流れに沿った通常のシステム操作パターンを十分に検討し、発生し得る操作を漏れなく抽出することが重要です。また一方で、非常に頻度の低い操作や、回復処理を全て機能として盛り込む必要はありません。発生頻度が極度に低いものは、運用対応と判断して妥当な場合もあります。 「人は間違うもの」という前提で、「ここで間違えたらどうやって訂正する？」「一連の操作を丸ごと取り消ししたくなったら？」等を抽出して、特殊な操作や回復方法を適切に検討しましょう。 ## 実現手段ではなく、求める結果を記載する 【標準ガイドライン関連箇所：第３編第５章第２節1)イ】 要件定義では、その情報システムが「どのように処理するか」ではなく、「結果としてどうなるか」を定義します。これは、要件定義段階で実現手段を定義してしまうことで、情報システムの専門家である事業者が、最適な実現手段を提案できなくなってしまうためです。 特に、新規構築ではなく、既存の情報システムの更改をする際には注意が必要です。既存の情報システムに問題があるにもかかわらず、使い慣れていることを理由に既存の情報システムの機能を踏襲して要件を記載してしまうことがあるためです。 このように記載してしまうことで、新たな形での機能提案が得られず、新しい情報システムに既存の情報システムの悪い面が継承されてしまい、更改の目的が果たされないこととなります。また、新システムで提案される新しい方式では、既存システムで行っている処理が不要になる可能性がありますが、要件として記載されていた場合、設計・開発事業者がその処理を不要と判断することが難しくなります。 既存の情報システム関連資料は、新たな情報システムを設計・開発するための重要な情報であることは間違いありません。ただし、これらは参考資料として提示し、既存の情報システムと機能を同一にする必要はないことを明示してください。