Step.5 機能要件の定義

既に定められた業務要件に基づき、業務要件を満たすために情報システムの機能に求められる要件を定義していきます。

開発の進め方や採用する技術によって具体的な作業の進め方は異なることがありますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。

個々の領域について要件を定める

【標準ガイドライン関連箇所：第３編第５章第２節1)イ】

  • 注記

バッチ処理とは、データの処理を即時実行（オンライン処理）せず、「10分ごと」や「毎日午前０時」などのあらかじめ決められたタイミングでまとめて実行する処理のこと。

機能要件として定義しないといけない内容は、機能、画面、帳票、情報・データ、外部インタフェースの５つです。要件定義の対象となる情報システムによっては、このうちの一部を定義しない場合もあります。例えば、バッチ処理しかしない情報システムであれば画面の定義は不要となりますし、他の情報システムと連携しないWebサイトであれば外部インタフェースの定義は不要となります。

機能に関する事項

「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。基本的に「入力」・「演算(処理)」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ１つの機能です。情報システムが提供する形は様々ですが、それらを「機能」として一覧化して整理するために用いるのが、「情報システム機能一覧」と呼ばれるドキュメントです。

「情報システム機能一覧」は、業務で求められる要件を情報システムで実現するために何が必要かを「機能」で表現したものであり、その概要や処理方式等を併せて記載し、情報システムの設計・開発を行う事業者に、情報システムに求められる要件を正しく伝えます。

  • 表5-3

情報システム機能一覧

情報システム機能一覧は、基本的に１つの情報システムについて１つ作成します。（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）一覧では、１機能の情報を１行で表現し、この情報システムで使用する機能は全て定義されます。

この一覧は、業務要件の内容を詳細化し、そこから機能要件を取り出すことで作成することができます。例えば「○○申告書をオンラインで作成する」という1つの業務要件は、「申告内容を新規登録する」「申告内容を更新する」「申告内容を削除する」「○○申告書を作成する」「○○申告書をＰＤＦでダウンロードする」等に分解できます。ここから、必要な機能を特定します。

１つの機能が複数の業務要件に使われることもあります。同じ機能を重複して記載しないようにしてください。

情報システム機能一覧は、後工程の開発・設計で構築作業のインプットとなりますが、構築範囲や対象を特定する情報ともなります。事業者が設計・開発に関する作業を計画する際、機能を1つの単位として考えることが多いため、発注者としてはこの一覧の内容まではしっかり理解し、この一覧を利用して事業者と会話できるようにしてください。

また、忘れがちなのが情報システムを管理するために必要な機能です。ユーザアカウントの追加削除、マスターデータの更新等、各種バッチ処理の実行、ログの記録や検索等、システム管理者が操作するための機能等も忘れずに検討してください。

クラウドサービス、パッケージ製品と比較できる粒度で整理

昨今のクラウドサービスやパッケージ製品は、様々なものが開発され、提供されています。「こんなものはないだろう。」といった先入観は持たず、まずは世の中にあるかどうかを確認し、採用が可能かを検討しましょう。

採用可否の判断の１つは、クラウドサービスやパッケージ製品が提供する機能群と、求める機能群との適合性です。正確に比較するには、双方の機能を同じ粒度に揃えることがコツです。具体的にはその機能が扱う情報を「入力」・「演算(処理)」・「出力」の何れかに分解できるレベルに揃えることが１つの指針となります。

これにより、何が既にある機能で、何が新しく追加しなくてはいけない機能なのかを判別することができます。

画面に関する事項

情報システムの画面は、利用者が業務の流れの中で情報システムとやり取りを行う窓口となるため、画面上で取り扱う情報の種類、画面を構成する要素の配置は、利用者の業務効率や満足度に大きな影響を与えます。

この画面に関する要件を取りまとめるドキュメントは、一般的に画面一覧、画面イメージ（画面モックアップ）、画面遷移図、画面設計方針書（画面設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。

  • 画面一覧

画面一覧とは、情報システムで実現する全ての画面の要件を画面の単位で定義し、一覧化したものです。これにより、画面ごとの入出力要件や該当機能等を把握できます。

画面一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１画面の情報を１行で表現し、対象とする情報システムで使用する画面が全て記載されます。画面の要件は、該当機能を実現する画面をイメージしながら、画面名、画面概要、入出力要件等を整理し記述します。複数の機能で同一の画面を使用する場合もあることに注意してください。

  • 表5-4

画面一覧

  • 画面イメージ（画面モックアップ）

画面イメージ（画面モックアップ）とは、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。HTML等で作ることで具体的な処理が組み込んでいないだけでほぼ実現したい画面の最終形になっているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方をされます。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。

要件定義の段階では、改修などの少数の画面に特定されている場合は別ですが、基本的には全画面のうち代表的なものについてのみ画面イメージを作成します。後工程で画面ごとに内容を確定させますので、要件定義の段階では代表的なものや特徴的なものが定義されていれば通常は十分です。

既存の情報システムがある場合は、その画面をベースに、追加・変更箇所がわかるようにする方法もあります。

  • 図5-4

画面イメージの定義例

  • 画面遷移図

画面遷移図とは、画面間の遷移を図に表したもので、画面間の関係や画面の流れをイメージすることできます。

画面遷移図は、画面と画面とを線で結び、矢印で方向を示すことで、どの画面からどの画面に遷移するかを示します。画面遷移図を見ることで、情報システムで実現する画面群全体を俯瞰的に捉えることができます。その情報システムにおける基本的な画面遷移パターンと比べて、特殊な画面遷移をしている個所は、特別な理由が無ければ修正し、基本的な画面遷移パターンに合わせることで、統一感のある使いやすい情報システムとなります。

  • 図5-5

画面遷移図

  • 画面設計方針書（画面設計ポリシー）

画面設計方針書（画面設計ポリシー）とは、画面設計を行う際の方針や遵守すべきルールを記載したものです。構築する情報システム全体として、どんな画面にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての画面をこの方針書に基づき設計していくことになります。

画面設計方針書は、既存情報システムや類似情報システムを参考にして、基本的な画面デザイン、ボタンの配置、画面遷移、操作手順等を検討した結果が記載されます。標準ガイドライン解説書「第３編第５章２．1)ウa) ユーザビリティ及びアクセシビリティに関する事項」の定義内容との整合にも気をつけてください。

基本的には、画面デザインはシステム全体を通じて統一することが好ましいです。利用者にとっても操作方法を覚えやすくなりますし、システムを維持運用する観点からも改修等が行いやすくなるからです。とはいっても、業務の内容によっては、その業務に特化した専用画面を作ったほうがよいこともあるでしょう。統一するか、個別に作り込むか、最終的にはその画面を見る人の利便性を重視して、決めていきましょう。

画面イメージや画面遷移図を細かく決めすぎない

画面に関する事項の検討は、実際に利用する業務実施部門の職員の意見を取り入れることにより、利用者の満足度向上につながります。一方で、現場職員の意見を聞きすぎると、微細な点にまで議論が及び、いつまでも要件が確定しないという事態に陥りがちです。

また、詳細に決めすぎると、クラウドサービスやパッケージ製品の採用を検討するときに、「適合するものがない」「大幅なカスタマイズが必要」という結論に至る弊害が考えられます。

要件定義で定める内容は、あくまで作業規模の見積りとなる元情報及び、具体的なレイアウト・画面遷移を設計するに当たっての要求事項に過ぎません。最終的には、設計段階で画面レイアウトの詳細を決めますので、この段階では不必要に詳細部分にまで入り込む必要はありません。

  • 注記

ソフトウェアフレームワークとは、アプリケーションを開発する際に必要となる汎用的な機能や部品等をまとめて提供し、アプリケーションの枠組みとして機能するソフトウェアのこと。

設計の技術的な前提条件を明記する

画面の設計・開発において前提となる各種標準やミドルウェア、ソフトウェアフレームワーク等が事前に決定されている場合は、それらの前提となる環境を画面設計方針書に詳細に明記します。また、画面イメージを検討する際には、それらの前提を踏まえた上で方針を決定してください。ミドルウェアやフレームワーク等によっては、出力イメージの実現に多大な工数が必要となる場合や実現不能となる場合があり、画面イメージが方針に沿っていないと設計時に大幅な手戻りを招く可能性があります。

帳票に関する事項

情報システムの帳票とは、サービス・業務で使用するために情報システムから出力した紙やＰＤＦ形式等の電子帳票を指します。帳票は、利用者が業務上意識して用いられるものであるため、業務の内容やきっかけと結びついた重要な情報を持ちます。

帳票に関する要件を取りまとめるドキュメントは、一般的に帳票一覧、帳票イメージ、帳票設計方針書（帳票設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。

  • 帳票一覧

帳票一覧とは、サービス・業務で使用する全ての帳票の要件を帳票の単位で定義し、一覧化したものです。これにより、帳票ごとの入出力要件や入出力形式、該当機能等を把握できます。気をつけたいのは、帳票一覧には情報システムが入出力しないものも記載する点です。明確に区別した上で、サービス・業務で取り扱う全ての帳票を記載することにより、管理がしやすくなります。

帳票一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１帳票の情報を１行で表現します。

帳票一覧は、業務の流れを意識して整理する抜け・漏れが防ぎやすいため、業務フロー図と整合性を取って作成します。帳票概要は、誰が、どのような契機で、何のために、帳票をどうするかを記述します。また、入出力形式として紙、電子ファイル（ＰＤＦ等）の形式も明確にします。

  • 表5-5

帳票一覧（例）

  • 帳票イメージ

帳票イメージとは、画面イメージと同様に、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。Excel等で作ることで詳細な項目まで表現されているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方があります。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。

要件定義の段階では、改修などの少数の帳票に特定されている場合を除き、全ての帳票に対して帳票イメージを作成することは無く、代表的な帳票から選定して、異なる種類分を作ります。後工程で帳票ごとに内容を確定させますので、代表的・特徴的なものが定義されていれば、通常は十分です。既存情報システムの帳票があればそれを基に、今回追加変更したい内容がわかるように情報を加えます。基になるものがないような新規のサービス・業務の場合は、紙やホワイトボード等にイメージを描きながら、職員と事業者とが対面で内容を擦り合わせます。

法定帳票等、既にフォーマットが決定しているものは、その内容を明示します。

  • 図5-6

帳票イメージの定義例

  • 帳票設計方針書（帳票設計ポリシー）

帳票設計方針書（帳票設計ポリシー）とは、帳票設計を行う際の方針や遵守すべきルールを記述したものです。構築する情報システム全体として、どんな帳票にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての帳票をこの方針書に基づき設計していくことになります。

帳票設計方針書は、作成した帳票一覧や帳票イメージ以外にも、既存情報システムや類似情報システムを参考にして、基本的な帳票デザイン、種類、様式、項目や罫線等の構成要素を検討した結果が記載されます。

帳票のレイアウトイメージを細かく決めすぎない

画面に関する事項と同様に、帳票レイアウトイメージも過度に細かく決めすぎないことが重要です。ここで決めた内容は、具体的なレイアウトを設計するに当たってのイメージ（要求事項）として扱われ、設計結果（確定したもの）として扱わないよう留意してください。

なお、法定帳票やOCRで読み取りをする帳票等、帳票レイアウトが確定しているものについては、レイアウトの定義を要件として明記します。

  • 帳票のレイアウトイメージは、要求事項を伝えるための表現方法として使用し、具体的なレイアウト等の設計結果を示すものとは区別して記載すること。

  • 帳票の利用目的を考慮し、法定の帳票や外部連携に用いる帳票等、業務の処理において不可欠な帳票を優先して整備する。

  • 複数の機能で同一の帳票レイアウトを使用する場合は、１つの帳票に複数の機能を紐付ける形で整理する等、帳票の種類がわかるように記載する。

  • 法定帳票等、帳票レイアウトが確定している場合は、遵守しなくてはいけない点（項目が満たされていればよい、配置も同一でなくてはならない、印刷位置をミリ単位で厳守しなくてはならない等）を明確に記載する。

設計の技術的な前提条件を明記する

帳票の要件として、「紙面に記載する情報」「紙面のレイアウト」に関して定義が必要であることは、想像がつきやすいのですが、「帳票を生成する方式」や「出力先」も要件の重要な要素です。バラバラの要件では、情報システムの構築にかかる費用見積りが過度に高くなる可能性があるため、同じような要件は可能な限り統一し、共通化できるように整理しておくことが有効です。

  • 帳票の設計・開発において前提となる各種標準やミドルウェア、フレームワーク等が事前に決定されているときは、それらの前提となる環境を詳細に明記すること。

  • 出力先として複数のプリンタを使用し、プリンタの印字方式に制限があるとき、出力用紙にカーボンコピー用紙を使用する等の条件があれば、補足にその旨を記載すること。

データに関する事項

ここで定義する情報システムのデータとは、情報システムの中（データベース等）で管理されるものであり、利用者にとっては目に見えないものですが、当該情報システム内で使われるのはもちろん、国民共有の財産であるという認識に立ち、広く一般に利活用されることを想定したものでなければなりません。

一方、こうしたデータの利活用を効果的なものにするためには、当然のことながら、データそのものの品質が十分に確保されていなければなりません。

すなわち、「データの利活用」と「データの品質確保」は、情報システム構築の際に欠かせない重要な要件となっています。

そこで、要件定義フェーズでは、プロジェクト計画書で記載した「データ利活用の方向性」に基づいて、情報システムで管理するデータの利活用や品質確保のための考え方を盛り込んだ、データに関する定義を記載します。具体的には、以下の分類に沿って、利活用するデータを識別・再構成し、各々の括りごとに、データ要件として定義します。

  • 図5-7

    データの利活用と品質確保

データ要件の定義にあたり、既存の情報システムのデータについては現行の機密性レベルや標準化レベル等の品質を改善すること、新規の情報システムのデータについては品質を十分に確保できるような定義を行うよう努めましょう。具体的な要件定義ドキュメントの説明に入る前に、これらデータの利活用方針や品質確保のための考え方や留意事項を、以下に順を追って説明します。

オープンデータの範囲と公開方法

  • オープンデータの定義と分類

「オープンデータ基本指針」（平成29年５月30日高度情報通信ネットワーク社会推進戦略本部・官民データ活用推進戦略会議決定）において定義されている内容を踏襲しますが、さらに以下の分類を行います。（図5-8参照）

  • オープン可能データ：情報システム上に存在するデータのうち、以下のものを除くすべてのデータ。

    • 個人情報が含まれるもの
    • 国や公共の安全、秩序の維持に支障を及ぼすおそれがあるもの
    • 法人や個人の権利利益を害するおそれがあるもの
    • 法律等によって用途が制限されているもの

  • オープン状態データ：オープン可能データのうち、外部から人為的な手続きを経ずに取得できる状態（ダウンロードサイト、Web-API公開など）になっているデータ。

  • オープン待機データ：オープン可能データのうち、外部から申請等の手続を経て取得できるデータ。

  • 注記

    オープンデータは機械判読性に基づいた公開レベルによってレベル１（★１）～レベル５（★５）の５段階に分類される。この評価指標を「５スターオープンデータ」といい、PDFは★１、XLSは★２、CSVは★３に該当する。

    「５スターオープンデータ」

    https://5stardata.info/ja/

  • 図5-8

    オープンデータの分類

  • オープンデータの範囲と公開方法

上記「オープンデータの定義と分類」に基づき、情報システムで管理するデータに関し、以下の情報を定義します。

  • オープン可能データの識別 後述の「データ一覧」の「公開可否」列に明記する。オープン可能データ以外については、その理由も「公開不可の理由」列に記述する。

  • オープン状態データの一覧（「オープンデータ一覧」として一覧化） オープン状態データの名称、概要・用途（メタ情報）、利用者及び公開の範囲、利用目的、利用頻度・特徴、実装方式、処理方式等を記述する。

    この時、オープン可能データの中で、オープン状態データの割合ができるだけオープン待機データより大きくなるようにしましょう。また、オープン状態データの中でもPDF形式よりはCSV形式、さらにはWeb-APIの公開というように、より活用の幅が大きくなるような公開形式を計画してください。

    なお、オープン可能データの中にも、利用者ニーズに差があったり、意味のある公開データにするためには多大のコストがかかるものが存在したりします。利用者ニーズの大小や費用対効果を勘案の上で公開の範囲や優先度を決定するよう心がけてください。また、オープン待機データについては、そのメタ情報を公開し、様々な公開ニーズの発掘に努めましょう。

データの品質確保のための考え方

データ機密性定義と管理方法

ここでは要件定義として明らかにしておくべきデータの機密性定義とその管理方法について説明します。情報セキュリティに関する全般的な事項、つまり機密性、信頼性、可用性などに関する全体的なことは別章の「情報セキュリティに関する事項」及び「信頼性に関する事項」を参照してください。

個人情報漏えいのニュースは報道等で大きく取り上げられ、その管理責任が問われることも頻繁に起きている状況が続いています。情報システムを構築し管理する組織としては、その重要性を認識し、システムの構築段階からデータに関する取り扱いを明確化し、適切に対応していくことが求められています。

要件定義においては、情報システムで取り扱うデータに関して機密性レベル別に分類し、その管理方法を定義しておく必要があります。システム内に存在することになるデータに関して、その機密性を認識し、分類し、またその管理方法を「データ要件」として記述することにより、その後の設計・開発作業に確実に繋げていくことができます。

下表5-6は、行政文書に関して整理した参考例ですが、個人情報等もこの分類で対応させて管理方法等を決めると分かりやすい整理ができます。なお、下表5-6の記載内容はあくまで参考であり、最終的な秘密文書の定義の判断は、行政文書の管理に関するガイドライン（https://www8.cao.go.jp/chosei/koubun/hourei/hourei.html ）を参照の上、決定することに留意してください。

  • 表5-6

    参考：行政文書に関する整理（電子的管理を含む）

「特定秘密の保護に関する法律」（内閣官房　平成２５年法律第１０８号） https://www.cas.go.jp/jp/tokuteihimitsu/

「特に厳格な管理を要する行政文書の取扱い等に関するマニュアル案（概要）」（内閣府　令和元年７月２５日）

https://www8.cao.go.jp/koubuniinkai/iinkaisai/2019/20190725haifu.html

まだ明確に定義できないデータもあると思いますが、特に機密性の高いデータに関しては、その洗い出しと分類、及び管理方法を可能な限り具体的に記述しておきましょう。情報の管理責任は発注者側にあります。その重要性を再認識し、要件として定義することが、情報漏えい等の問題を起こさない最も重要な作業の一つであると言えます。

整理する内容としては、データ名称、個人情報／特定個人情報の有無、保管方法（別の端末には置かない等）、暗号化有無、格付・取扱・アクセス制限設定（人、プログラムから等）、履歴管理（更新、参照者の特定レベル）、運用管理／手順のレベル等です。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(2) データ一覧」を参照ください。　

マスターデータの標準化

マスターデータとは、「データを利用してサービスを実現するときに必要となる基本情報のことです。例えば、目的に合わせた基本データ集として整理された台帳のようなものや、個人、組織、事業所、場所等の基本情報をリスト化したもの」（マスターデータ等基本データ導入実践ガイドブックより）です。例えば情報システムでは事業所の情報（会社名、事業所名、事業所番号、事業内容、住所、従業員数等）の一覧が電子リスト（マスターデータのこと）として定義され、システム内の各機能（プログラム）から参照することにより、事業所番号を入力するだけで関連する事業所の情報を画面に表示して選択を促すというような処理で利用されます。

  • マスターデータの標準化の重要性

    上記のとおり、一つの情報システム内でも様々なプログラムから参照されるマスターデータは、その情報の特徴から他のシステムでも同じような情報が必要になることが多くあります。例えば事業所の例では、一つのシステムに限らず、事業所情報を必要とするシステムは多数あります。それらシステム毎に事業所のマスターデータを定義していたのでは非効率ですし、また使用するコードや項目も異なり、システム間で情報を連携する場合など、そのままでは情報交換することができなくなります。そういった非効率さをなくし連携までの時間を短縮するためにも、マスターデータは同じ目的で使用したい人達のために、より広いシステムの範囲で同じ内容のものを参照することが重要ということになります。そのレベルは、地方自治体も含めた国全体で一元化し標準化するべきもの、省庁内で一元化し標準化するべきもの、あるいは部局内同種の業務で一元化し標準化するべきもの、などその標準化の範囲はそれぞれで最適なものを決定していく必要があります。現行システムで既にマスターデータが存在するものについては、その標準化レベルを改めて確認し、最適な標準化のレベルに向けて計画的に改善していきましょう。政府情報システムとしては、自分達主導でより広範囲の標準化を目指すことを基本とします。また、一般公開することで民間の利用も促し、社会全体として効率よくかつ均質化したサービスも提供できるようになります。

  • マスターデータ定義の考慮点

    要件定義では、マスターデータとして分類されるものを定義し、その標準化レベルと公開方針等を決定します。分類とその考慮事項は下記を参照ください。

  • 表5-7

マスターデータの分類と考慮事項

※マスターデータの公開に関しては、オープンデータとしてe-Govデータポータル（https://data.e-gov.go.jp/info/ja ）への公開を推奨する。

  • マスターデータの要件定義書への記載

    要件定義としては、データ一覧をマスターデータとマスターデータ以外（トランザクションデータ、入出力ファイル等）に分けて作成し、データ名、概要・用途（メタ情報）、規模情報、マスターデータ分類、分類選択理由、標準化レベル（国際標準、国内標準、省庁標準、部局標準）、公開有無と範囲等を記載します。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(2) データ一覧」を参照ください。

    なお、要件定義フェーズではまだ項目の詳細は決まらないかもしれませんが、メタ情報として可能な範囲で具体的に記述してください。より詳細な設計・導入の手順などは「マスターデータ等基本データ導入実践ガイドブック」を参照ください。

データ項目（コードを含む）の標準化

データ項目とは、情報システム内で取り扱う電子化された情報の基本単位と言えます。例えば、書籍名、著者名、貸出日、出版社コード等、その各々が異なる一意の対象を表します。また、データ項目の中には、出版社コードのように出版社を特定するためにコードとして表すことも広く使われています。コードはＮ個の記号（例：ＡＢ５ＦＤＳ）やＭ桁の番号（例：９９０５６３）などで表すこともあります。

一方、情報システムでデータ項目を取り扱うということは、紙に書かれた文字情報を人が読むのと大きく異なります。人は紙に書かれた文字の多少の揺れや歪みを理解できるので、「貸出日」と「貸出し日」は表記が異なるだけで同じ意味の言葉であると理解できます。一方、コンピュータは情報システム内のデータ項目を機械的に読むため、「貸出日」と「貸出し日」を別物として認識してしまいます。データ項目をそれぞれ別物と認識したらそのデータ項目を扱う処理も別となり、大きなトラブルにもなりかねません。よって、情報システムで取り扱うデータ項目は厳格な定義と扱いが求められます。

  • データ項目（コードを含む）の標準化の重要性

    データ項目（コードを含む）の中には、他のシステムでも同じ目的で使うものが多くあります。それらの項目は、同じ項目名で同じ意味定義で設計されていると、お互いの連携をスムーズにかつ間違いなく行うことができます。つまり、マスターデータと同様に、より広範囲なデータ項目（コードを含む）の標準化を行えば、より効率的に短期間で他との連携ができることになります。また、データ項目やコードを一般公開することで民間での利用も促すことができます。「データ流通時代」と言われる今後のデジタル社会において、常にデータ項目及びコードを標準化しオープンデータとして公開することを念頭に要件定義を行うことは非常に重要です。

  • データ項目（コードを含む）の標準化の考慮点と要件定義書への記載

    要件定義書では主要なデータ項目とコードを洗い出し、発注者としてそれらの定義を行います。最終的には基本設計工程で全てのデータ項目とコードが定義されることになりますが、業務上主要なデータ項目とコードについては発注者がその標準化レベルを決め、意味を定義し、事業者に指示する形にすることが重要です。マスターデータと同様に、発注者（自分達）主導でより広範囲の標準化を目指しましょう。また、多くのデータ項目やコードは業務の方向性・範囲と密接に関係していますので、その点でも、発注者側がデータ項目やコードを定義することで、要件及び仕様の連携が確実かつ正確に行われることにも繋がります。

  • 主要なデータ項目及びコードについては、要件定義書に記載すること。より広い範囲での標準化を目指すこと。

  • また基本設計工程では全てのデータ項目（コード含む）の厳格な意味定義を行うこと、及び標準化の推進を事業者にも促すこと。

  • なお、コード及びコード以外のデータ項目標準化に関して、「コード（分類体系）導入実践ガイドブック」、「文字環境導入実践ガイドブック」及び「行政基本情報データ連携モデル」を業務の方向性・範囲に応じて参照することを推奨する。

要件定義としては、「データ定義」に標準化レベル（国際標準、国内標準、省庁標準、部局標準）、「コード一覧」にコード標準化分類、分類選択理由、標準化レベル等を記載します。詳細は本ガイドブック別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」の「(3) データ定義」及び「(5) コード一覧」を参照ください。

ライフサイクルを通じたデータの品質確保

異なる機能や画面から同じデータを修正、削除できるようにすることはよくありますが、その際に部分的な観点から処理を行ってしまうとデータの不整合が発生しかねません。

一貫性や完全性等の観点からデータの品質を確保するためには、情報システムの中で扱うデータについて重複なく全体を定義した上で、それらのデータが設計時点だけでなく運用時点でも品質が保たれるようにライフサイクルでの管理を行うことが重要です。

データに関する要件を取りまとめる際には、このような観点を踏まえたうえで、データモデル、データ一覧、データ定義、CRUD マトリクス、コード一覧、コード内容定義、オープンデータ一覧等のドキュメントを整備することが重要です。これらのドキュメントは、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります）。また、これらのドキュメント間の整合性を保つとともに、画面や帳票の要件を定義したドキュメントとも整合性を保つことが望まれます。

  • 表5-8

データの要件を取りまとめる際に整備するドキュメント例

これら7つのドキュメントの詳細や機能一覧との関係性については、別紙「要件定義書標準テンプレート」の「2.4. データに関する事項」を参考にしてください。

  • 図5-8

情報・データ定義作業のイメージ

後の工程で作られる情報に関する設計書等のドキュメントは、専門的な情報や記法で記載されることが多く、内容を詳しく理解するには難しいものになります。したがって、ここで作成するドキュメントとそれら専門的なドキュメントとの内容を同期させることを事業者に依頼し、専門的なドキュメントを見なくても、要件が充足しているかをチェックできるようにしてください。

  • 参考5-3

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

  • 事例5-2

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

外部インタフェースに関する事項

情報システムの外部インタフェースとは、サービス・業務の内容を実現するために、自分の情報システムが他の情報システムと連携して情報を受け渡す仕組みです。情報連携の内容や形式・仕組みには様々なものがあり、明確に定義する必要がありますが、連携先である他の情報システムの都合もあるため、双方の要件を出し合い、すり合わせることが必要となります。

この外部インタフェースに関する要件を取りまとめるドキュメントは、一般的に外部インタフェース一覧と呼ばれるものです。情報システム機能要件一覧との整合性も意識しながら作成を進めます。

外部インタフェース一覧では、他の情報システムと連携する全ての情報をそれぞれの情報の単位で定義し、一覧化します。これにより、情報ごとの相手先情報システムや送受信のタイミング、条件等を把握できます。

外部インタフェース一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１つの連携情報を１行で表現し、対象とする情報システムと他の情報システムと連携が全て記載されます。要件には、連携先の情報システムとの送受信のタイミングや送受信の際の条件も、明確にして定義します。

なお、連携先となる情報システムの要件が確定していない等により、要件定義の段階で定義できない外部インタフェースの内容については、その理由を記述します。また、障害発生時や緊急時の代替手段が規定されていれば、それらも記述します。

外部インタフェース一覧で記載した連携は、情報システムが出来上がってからのテストにおいて、１つ１つテストを実施する必要があります。相手先の情報システムが同時に構築中の場合や改修が行われた場合等により、要件定義時に合意した内容が時間の経過とともに変更されていることがあります。連携先との意思疎通が不十分なときは、情報システムがリリースされて初めて問題に気付くことも少なくありません。

そういったトラブルを未然に防ぐために、事業者や相手先情報システムのＰＪＭＯと連携して、意思疎通が不十分とならないよう対策をしてください。

  • 表5-9

外部インタフェース一覧

情報システム関連図で連携イメージが伝わるようにする

新たに整備する情報システムと他の情報システムとの連携は、情報システム関連図を作ることで、イメージが伝わりやすくなります。

この図を中心とし、次に示す点に留意して、表5-9に示す外部インタフェース一覧に要件を整理します。

  • データ互換性の確保のためにデータ変換が必要となる場合が多いことから、
  • 注記

プロトコルとは、情報システムを構成する機器同士が通信をする際の手順や規約などを定めたもの。ネットワーク間で双方の機器が理解できる同じプロトコルを使わないと通信は成立しないため、インターネット上のプロトコルの大部分はRFCという形式で技術仕様が公開されている。

やり取りするデータだけでなく、物理的なインタフェース、プロトコル、フロー図、文字コード、データフォーマット、取り扱う値の範囲、通信の速度等について、可能な限り詳細に記載する。

  • 双方の情報システムが取り扱う情報の格付の区分等が異なる場合に、機密情報を連携することにより情報セキュリティ対策が不十分とならないよう、連携の方向や内容等に十分留意する。

  • データベースの所在国についても十分に留意する必要がある。例えば、個人情報保護法第2条第2項に規定する個人情報又は番号法第2条第5項に規定する個人番号を蓄積するデータベースについては、国内法が適用される場所に制限する必要があることを認識し、問題がないことを確認することが考えられる。

  • 要件定義の段階で定義できない外部インタフェースがある場合には、その理由を含めて記載すること。

  • 障害発生時や緊急時の代替手段が規定されている場合は、それらも記載すること。

必要な機能を漏れなく抽出し検討する

【標準ガイドライン関連箇所：第３編第５章第２節1)イ】

要件定義を進めていくと陥りやすいのは、優先度の高いやりたい事だけを定義してしまうことです。業務要件では、毎日行う業務ばかりに議論が集中して、日常的に実施頻度の少ない業務の議論は後回しになりがちですが、機能要件でも同様のことが発生します。

  • 事例5-3

要件の考慮不足がスケジュール遅延に繋がる

画面操作を例とすると、基本的な機能やよく使う機能の要件は忘れない代わりに、めったに発生しないデータの処理手順や誤入力した際の回復処理については議論が抜けがちになります。これらは要件定義漏れとして、テストをすり抜け、リリース後発覚してトラブルとなるおそれがあります。

誤入力の回復が簡単にできないと職員が認識している場合、本来行う基本的な業務で過度に慎重になってしまい、その業務のシステム利用が敬遠されてしまうことも考えられます。また、特別な処理が必要になったときに、運用事業者によるデータベース操作によるデータ補正等のアプリケーション機能以外での対応が必要となり、運用・保守費用の増大に繋がりかねません。

このような事態に陥らないためには、業務要件から機能要件を抽出する際、業務の流れに沿った通常のシステム操作パターンを十分に検討し、発生し得る操作を漏れなく抽出することが重要です。また一方で、非常に頻度の低い操作や、回復処理を全て機能として盛り込む必要はありません。発生頻度が極度に低いものは、運用対応と判断して妥当な場合もあります。

「人は間違うもの」という前提で、「ここで間違えたらどうやって訂正する？」「一連の操作を丸ごと取り消ししたくなったら？」等を抽出して、特殊な操作や回復方法を適切に検討しましょう。

実現手段ではなく、求める結果を記載する

【標準ガイドライン関連箇所：第３編第５章第２節1)イ】

要件定義では、その情報システムが「どのように処理するか」ではなく、「結果としてどうなるか」を定義します。これは、要件定義段階で実現手段を定義してしまうことで、情報システムの専門家である事業者が、最適な実現手段を提案できなくなってしまうためです。

特に、新規構築ではなく、既存の情報システムの更改をする際には注意が必要です。既存の情報システムに問題があるにもかかわらず、使い慣れていることを理由に既存の情報システムの機能を踏襲して要件を記載してしまうことがあるためです。

このように記載してしまうことで、新たな形での機能提案が得られず、新しい情報システムに既存の情報システムの悪い面が継承されてしまい、更改の目的が果たされないこととなります。また、新システムで提案される新しい方式では、既存システムで行っている処理が不要になる可能性がありますが、要件として記載されていた場合、設計・開発事業者がその処理を不要と判断することが難しくなります。

既存の情報システム関連資料は、新たな情報システムを設計・開発するための重要な情報であることは間違いありません。ただし、これらは参考資料として提示し、既存の情報システムと機能を同一にする必要はないことを明示してください。