第５章 要件定義
デジタル・ガバメント推進標準ガイドライン 実践ガイドブック
第５章 要件定義
目次Step.1 要件定義の活動全体の流れ
Step.2 要件定義の事前準備
１ 要件定義で職員が得た知識は貴重な財産
２ プロジェクト計画や業務要件を把握する
Step.3 ＲＦＩの実施
１ ＲＦＩを理解し、必要な資料を準備する
A. ＲＦＩの意義と用途を理解する
B. ＲＦＩに必要な資料を準備する
２ 公平性等を確保したヒアリングを行う
３ 収集した情報を基に資料を更新する
A. ＲＦＩや発注前ヒアリングの結果を整理する
B. 既存の資料を最新化する
Step.4 要件定義の全体像
１ 構成要素を把握し要件を定義する
２ 機能の優先順位は改善後の業務で判断する
３ 一貫性をもった論理的な記載とする
４ 要件定義書は継続的にメンテナンスする
Step.5 機能要件の定義
１ 個々の領域について要件を定める
A. 機能に関する事項
B. 画面に関する事項
C. 帳票に関する事項
D. ファイルに関する事項
E. 情報・データに関する事項
F. 外部インタフェースに関する事項
２ 必要な機能を漏れなく抽出し検討する
３ 実現手段ではなく、求める結果を記載する
Step.6 非機能要件の定義
１ 個々の領域について要件を定める
A. ユーザビリティ及びアクセシビリティに関する事項
B. システム方式に関する事項
C. 規模に関する事項
D. 性能に関する事項
E. 信頼性に関する事項
F. 拡張性に関する事項
G. 上位互換性に関する事項
H. 中立性に関する事項
I. 継続性に関する事項
J. 情報セキュリティに関する事項
K. 情報システム稼働環境に関する事項
L. テストに関する事項
M. 移行に関する事項
N. 引継ぎに関する事項
O. 教育に関する事項
P. 運用に関する事項
Q. 保守に関する事項
２ システム方式を決定する
Step.7 要件定義終了後の対応
１ 定義内容を関係者に共有する
２ プロジェクト計画書に反映して最新化する
事例・参考の一覧
事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる
参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係
様式例：業務要件定義書、機能要件定義書、非機能要件定義書のひな形
様式例：機能要件定義書のひな形
参考：砂上の楼閣を防ぐデータ・マネジメント
事例：要件の考慮不足が設計開発工程の遅延に繋がる
事例：非機能要件が機能要件に影響することもある
参考：最適なシステム構成
参考：拡張性要件の記載例
参考：上位互換性要件の記載例
参考：オープンな標準的技術又は製品の採用を求める場合の記載例
参考：事業者交代時の対応を求める場合の記載例
参考：継続性に関する事項の記載例
参考：業務継続の分かれ目
参考：最低限記述すべき情報セキュリティ対策要件
参考：クラウドサービスの要件例
参考：運用要件（バックアップ）の記載例
Step.1 要件定義の活動全体の流れ
要件定義は、事業者に任せることができるでしょうか？
要件定義では、業務要件、機能要件、非機能要件の大きく３種類の要件を決めていきます。特に情報システムに直接関わる機能要件と非機能要件は専門的な内容を多く含むため、内容を検討する際にその道のプロである事業者から支援を受けることはあるでしょう。
しかし要件定義の実質部分を事業者に丸投げしてしまっては、その先のプロジェクトは絶対にうまくいきません。家を建てるときに、どんなに優秀な建築士が支援したとしても、施主が自身の考えを伝えて様々な選択肢から判断しなければ、施主にとっての理想な家ができないことと同じです。つまり、情報システムを作る場合には、その情報システムをどのようなサービス・業務に利用し、どういった利用者がどの程度活用して情報・データを収集・分析などを行い、サービス・業務の目的を達成するかについてPJMO（主に制度所管部門及び業務実施部門が中心）がまとめておくことが重要です。
ここでは、要件定義を進める際に発注者として最低限知っておくべき知識・ノウハウについて、説明します。
本ドキュメントの構成は、次のとおりです。
Step.2 要件定義の事前準備
要件定義を行う前に、これをやっておくとその後の作業をスムーズに進めることができる事前準備について説明します。
Step.3 ＲＦＩの実施
要件定義では、ＲＦＩ等の情報収集を行うことにより、様々な情報を複数の事業者から収集し、情報システム構築の方向性や実現性、適用可能な技術等の情報を把握することができます。しかし、漠然と情報提供を依頼して、収集・整理するだけでは効果が限られます。
ここでは、ＲＦＩ等の情報収集を行うに当たり、何に気をつけて作業を進めればよいかを説明します。
Step.4 要件定義の全体像
要件定義では、業務要件、機能要件、非機能要件で定めた各項目の内容を定義します。これらの項目の多さや相互に関連する複雑性が、要件定義をより専門的なものとして難しく感じさせる要因ともなっています。
ここでは、要件定義の全体の構造と大まかな内容について説明します。これにより、各項目の位置関係を認識することで、その後の作業の理解を助けます。
Step.5 新しい機能要件の定義
機能要件を具体的に検討し、ドキュメント化する作業は事業者が行うことが多いものですが、発注者として最低限理解しておかなければいけない知識やノウハウを説明します。
Step.6 新しい非機能要件の定義
非機能要件というと、機能要件以上にどんな内容を決める作業なのか想像できないものかもしれません。
ここでは、機能要件と同様に、発注者として最低限理解しておかなければいけない知識やノウハウを説明します。
Step.7 要件定義終了後の対応
要件定義が完了したあとの処理について説明します。要件定義が終わると、ひとまずほっとするところですが、関係者への要件定義内容の共有等、忘れずに実施すべきことを記載しています。
Step.2 要件定義の事前準備
要件定義の作業に入る前の開始準備として、今直面している検討対象の内容にかかわらず、心得ておくべきことがあります。
ここでは、準備に必要な具体的な内容について、紹介していきます。
１ 要件定義で職員が得た知識は貴重な財産
【標準ガイドライン関連箇所：第３編第５章全般】
要件定義を担当した職員は、要件定義を行うことにより、サービス・業務の企画内容、情報システムの要件に係る背景、決定経緯、理由等のドキュメントには表現が難しい暗黙知（職員が暗黙のうちに有する、長年の経験や勘に基づく知識）などの知識を収集しつつ可能な限り客観的にドキュメント化（言語化）し、形式知として蓄積していきます。これらの知識は、設計・開発以降の工程において、詳細な仕様の決定、設計のレビュー、要件変更の決定や受入テストのシナリオ作成等の際に、重要な材料となります。
要件定義を担当した職員が途中で異動してしまい、これらの知識がなくなってしまうことで、設計・開発以降の工程で、無駄な作業の発生、誤った判断、実現したい内容からのかい離、利用者視点での品質の低下が発生し、プロジェクト全体の目標達成に影響を与えてしまうことが少なくありません。
このため、ＰＪＭＯは、これらの知識を有する職員が継続的にプロジェクトに取り掛かれるよう調整する必要がありますが、これらの知識を日常的に整理・文書化し、やむを得ず、これらの知識を有する職員がプロジェクトを離れてしまうときに、十分な引継ぎを行うよう備えておくことが重要です。
また、要件定義を複数人で行いクロスチェック等を行うことで、複数人にこれらの知識が蓄積され、相互に深めていく方法も効果的です。
| 事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる
ある省の業務システム開発プロジェクトにおいて、プロジェクト立上げ時から一人でＰＪＭＯを担当していた職員Ａさんが、設計・開発工程の途中で、異動することになりました。後任にはＡさんとは異なる情報システムの経験を持つＢさんが着任しました。急に決まった異動だったため、引継ぎ資料を準備する時間もなく、プロジェクトで作成したドキュメントの概要を、口頭で説明することで精一杯でした。 
Ａさんが担当していた期間中、設計・開発事業者は、各機能の要件定義までの詳細な経緯をＡさんに確認し、それを踏まえて設計・開発を進めていました。交代後、Ｂさんも同様に確認を受けましたが、Ａさんから詳細な検討経緯等については引継ぎを受けていなかったため、Ｂさんは自身の経験に基づいた判断で、設計・開発事業者に回答や指示を行いました。その結果、開発された情報システムはＡさんが当初目指していた目的を達成しないものとなってしまいました。 
この事例では、Ａさんが自身に蓄積された設計・開発工程までに得た知識を、日常的に文書化しておけば、引継ぎ資料として活用できたはずです。また、突然の担当者の交代は、人事異動だけではなく、急病や家族の介護等、不可抗力で発生することもあります。このことを想定し、各工程への関わりを複数名で行う体制を構築することにより、知識の蓄積がＡさん一人だけに集中する事態を避けられたはずです。 リリースまでには大量かつ多岐に渡る情報が発生するため、個人の頭の中だけに残すことは不可能です。連続して蓄積された知識は、情報システム開発における様々な作業で不可欠なもののため、主要な担当職員の交代は、プロジェクトの成否に大きな影響を及ぼします。情報システムの開発には、連続して蓄積された知識がとても重要なため、それらを残すための日常的な備えが必要です。 |
２ プロジェクト計画や業務要件を把握する
【標準ガイドライン関連箇所：第３編第５章全般】
要件定義では情報システム等に関わる詳細な要件も検討するため、どうしても各論に目がいきがちとなります。しかし、それぞれの要件は、政策目的やプロジェクト目標の達成、利用者への価値の提供のためにあることを忘れないでください。
例えば、関係者の要望を単に取り入れようとし、情報システムに求める要件が過度に増加することが多々ありますが、このような場合には、その要件の上位に当たる、法令、政策目的・目標の実現やプロジェクト目標の達成まで立ち返り、必要十分な情報システム化の範囲を選択することが大切です。
このため、要件定義を開始するに当たって、まずは、政策目的、目標、対象範囲、サービス・業務企画の方向性等、実施計画等を把握し、プロジェクトとして達成すべきゴールを把握します。その後、サービス・業務企画の活動でまとめた業務要件定義書を確認し、サービス・業務から見た情報システムに対する要求を理解した上で、要件定義を行う範囲を特定します。
Step.3 ＲＦＩの実施
ＲＦＩ（Request For Information）は、情報システムに関する様々な情報を収集するために事業者に対して、構築しようと考えている情報システムに関わる、技術的な情報や動向、参考事例等の提供を依頼する活動です。
ただし、ＲＦＩを実施するために必要な資料の準備やスケジュール等、進め方の要点を捉えずに実施すると、有益な情報を十分に得られないこともあります。
このＳｔｅｐでは、ＲＦＩを実施するに当たり、何に気をつけて準備を行い、取得した情報を使って、どのように資料を更新していくかについて解説していきます。
１ ＲＦＩを理解し、必要な資料を準備する
【標準ガイドライン関連箇所：第３編第５章第１節1)】
ＲＦＩでは、主に具体的な調達を想定して必要な情報を収集します。必要な情報が集まるかどうかは、情報提供を依頼する事業者に対して、こちらが何を考え、どのようなことを実現しようとしているかを正確に伝えるかどうかに掛かっています。
ここでは、ＲＦＩに向けて資料を準備する際のポイントについて、見ていきましょう。
A. ＲＦＩの意義と用途を理解する
要件定義に必要な情報は、世の中の技術動向やサービスの動向、各種事例、要件を実現する方式に関するものなど多岐にわたり、担当者の知識や経験のみで網羅的かつ詳細に把握することは困難です。
しかし、必要な情報を入手しないまま要件定義を行った場合は、費用対効果に優れた手法を採用できない、優れた先進事例を取り込むことができない等のリスクがあり、さらには、その後の調達手続や設計・開発段階において、入札における不落や開発の手戻り等が発生することになります。
そのため、ＲＦＩを通じて必要な情報を入手し、要件を実現する上で必要な解決策や技術的な課題等を明確にしていきます。
ＲＦＩは、例えば以下のような情報を入手するために行います。
ＲＦＩで求める情報の例
・
市場にあるサービスの種類及びその動向
・海外や国内の類似の事例とその教訓
・新たな技術の動向や製品のライフサイクル
・想定する要件を実現する方式とその実現可能度や制約事項
・概算の予算規模
・大まかな工程やスケジュール
・著作権や法的な制約
・実現に際してのリスク 等
ＲＦＩは、その用途に応じて、プロジェクトの様々なタイミングで活用することが可能です。新たなサービス・業務を開始するプロジェクトにおけるＲＦＩのタイミングの例を、以下に示します。大規模なプロジェクトでは、最新のサービス・技術の採用や計画の妥当性の確認を十分に行う必要があるため、サービス開始年度の３ヵ年前を目安として情報収集を始めることを推奨します。
図5-1 ＲＦＩのタイミング例
| 参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係
事業者から情報を収集するための代表的なやり方には、ＲＦＩ（Request For Information、資料提供依頼）、資料提供招請、意見招請の3つがあります。 このうち、要件定義を行うための情報収集には、ＲＦＩ、資料提供招請を用います。両者の大きな違いは、資料提供招請には、実施の条件や期間等の定めがある点です。 意見招請は、調達前に仕様書案に対する意見の提出を行うことが出来るようにするものであり、調達案件が80万ＳＤＲ以上の調達額と見込まれるものについては、原則必須となります。詳細は、標準ガイドライン「第６章３．4) 意見招請の実施」を参照してください。 これらの手続きは、「供給者の利便及び競争力のある内外の供給者による市場参入機会の確保に資するとともに透明性、公正性及び競争性の高い調達手続とする」ことが目的です。事業者からの情報収集に当たっては、標準ガイドラインのルールに従うとともに、「政府調達手続に関する運用指針」（平成26年３月31日関係省庁申合せ）を参考にしてください。 |
B. ＲＦＩに必要な資料を準備する
ＲＦＩでプロジェクトの成功に向け役に立つ情報を入手するためには、発注者側がどのような事を考え、何をしようとしているかを正確に伝えるため、ＲＦＩのために資料を準備する必要がありますが、この資料作成に負担を感じ、ＲＦＩを見送ってしまうという判断をしてしまうかもしれません。
しかし、資料の作成は、ポイントを押さえて、これまで収集・作成した資料を活用すれば、それほど難しいことはありません。以下に、ＲＦＩに必要な資料とその作成ポイントを示します。資料では意図が伝わりにくいこともあるため、説明会や個別ヒアリングを合わせて行うことも検討しましょう。
| 資料の種類 | ポイント |
|---|---|
| 調達の概要 | 事業者がプロジェクトの目的・概要・ＲＦＩの概要等の全体像を把握するための資料で、プロジェクト計画書から政策目的、目標、サービス・業務企画の方向性等を集め、資料をまとめます。サービス・業務企画や予算要求で業務や情報システムの概要資料を作成している場合は、それを利用することで事業者が全体像を効率的に把握する役に立ちます。 |
| その時点における検討内容、要件案の概要等 | サービス・業務企画で作成する業務要件定義書やＲＦＩ時点の要件定義の定義書を利用します。未確定の項目や提案を求める項目については、その旨を明記しましょう。また、前提条件や制約等がある場合は、必ず記載してください。 |
| 資料提供を求める内容等 | ＲＦＩの趣旨（何の情報を何のため求めているのか）、ＲＦＩで求める内容を記載します。要件定義書の未確定の項目や提案を求める項目をサマリすると事業者が網羅的に検討しやすくなります。 |
| 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等 | 各府省のルールを確認し、過去のＲＦＩの記載を参考にすると効率的に作成することができます。 |
表5-1 調達に必要な資料
２ 公平性等を確保したヒアリングを行う
【標準ガイドライン関連箇所：第３編第５章第１節2)】
ＲＦＩを行うほど要件が確定していない場合等には、事業者に対して説明会や個別ヒアリングを行い、情報を収集する方法があります。事業者と直接ヒアリングすることは、資料では伝わりにくい目的や意図を伝えるのに有効です。しかし、発注前ヒアリングについても、ＲＦＩと同様に公平性・競争性を確保する必要があるため、ＲＦＩと同様に標準ガイドラインのルールに従うとともに、「政府調達手続に関する運用指針」（平成26年３月31日関係省庁申合せ）を参考にしてください。
３ 収集した情報を基に資料を更新する
【標準ガイドライン関連箇所：第３編第５章第１節3)】
ＲＦＩや発注前ヒアリングの結果、有用な情報が集まりました。これらを踏まえて、要件定義を始めましょう。でも、ちょっと待ってください。その前に一手間加えるだけで、要件定義が効率的に行えるようになります。
では、要件定義を行う前のちょっとした工夫を見ていきましょう。
A. ＲＦＩや発注前ヒアリングの結果を整理する
ＲＦＩにて複数の事業者から入手した資料や事業者とのヒアリング結果は、それぞれが独立した資料として残っているはずです。要件定義で入手した情報を十分に活用するためには、以下の観点で情報を整理し、資料としてまとめます。また、整理した結果から、より費用対効果が高い実現方式の検討や、リスク定義への追加等を行い、プロジェクト計画の変更を検討し、必要な更新を行います。
結果を整理する観点
・
複数事業者の情報を内容ごとに比較し、メリット、デメリットを評価する。事業者の提案はメリットを中心に行われるため、デメリットにも目を向けて評価する。
・費用、目的との適合性等の複数の軸で総合評価する。
B. 既存の資料を最新化する
既存のサービス・業務や情報システムは、プロジェクトが進行している最中にも改善や機能追加が行われる可能性があります。既存のサービス・業務や情報システムの資料はサービス・業務企画時点で収集しますが、要件定義を開始する時点で最新化を行いましょう。調達後に変更内容が判明した場合は、追加のコストがかかる可能性がありますので、留意してください。
Step.4 要件定義の全体像
要件定義は、業務要件、機能要件、非機能要件で構成され、各要件には多数の項目が定義されており、それぞれの内容は項目間で影響し合っています。
このＳｔｅｐでは、この要件定義全体の構造を説明した上で、要件定義全般にわたって気を付けるポイントを解説します。
１ 構成要素を把握し要件を定義する
【標準ガイドライン関連箇所：第３編第５章第２節1)ア】
要件定義の内容は定義する項目が多数あるため、詳細を検討していく中で、どこかで同じ内容を検討してはいないか、本当に漏れがないか、と不安になってくることがあります。
まずは、要件定義の構造と定義する項目を俯瞰し、要件の上位に当たる、政策目的・実現する目標、達成すべきプロジェクト目標に沿って、何をどこで定義するのか、それぞれの項目がどのように関連しているかを理解しましょう。要件定義は、それぞれの項目の整合性を逐次取りながら定義することで、無駄なく、漏れなく、効率的に検討していくことができます。
図5-2 要件定義の構成要素とポイント
この実践ガイドブックの別紙として、業務要件、機能要件、非機能要件のそれぞれのひな形を用意しています。これを活用すれば、基本的な部分についての漏れをなくすことができます。
ただし、これらの要件定義を作成する時点では、全ての項目をきっちりと定義することが難しい場合もあります。未確定の項目は、後の工程で定義されることになります。このときに関連する項目に変更がある場合があるため、関連する項目の変更漏れがないように、未確定の項目の関係性がわかるようにしておくことが大切です。
また、定義書が一通り作成された後、以下の観点で最終確認を行うことで、定義漏れを防ぐことができます。
| 確認の観点 | 解説 |
|---|---|
| 必要性 | 政策目的・目標の実現やプロジェクト目標の達成への貢献といった有効性の観点及び費用対効果の観点を踏まえ、実現すべき機能要件及び非機能要件のみが定義されていること。 |
| 網羅性 | 業務要件が漏れなく定義され、その実現のために備えるべき機能要件及び非機能要件が漏れなく定義されていること。 |
| 具体性 | 機能要件及び非機能要件を実現する複雑さ、難易度、調達コストに影響する不確定要素が可能な限り排除されていること。 |
| 定量性 | 業務及び情報システムの規模等が定量的に示され、性能等に関する計測可能な指標と具体的な目標値が設定されていること。 |
| 整合性 | 業務要件、機能要件、非機能要件の内容に矛盾がないこと。また、関連する他のプロジェクトの要件定義内容と整合的であること。 |
| 中立性 | 調達コストの削減、透明性向上等を図るため、要件定義内容が特定事業者に不必要に依存したものでないこと。 |
| 役割分担の明確性 | 業務の実施体制が明確であること。また、情報システムのテスト、移行、引継ぎ、運用、保守に関して、関係府省等も含め、自府省と事業者との役割分担が明確であること、 |
| 情報セキュリティ | 自府省の情報セキュリティポリシーを遵守するために必要な対策が漏れなく定義されていること。 |
表5-2 要件定義内容を確認する観点
| 様式例：業務要件定義書、機能要件定義書、非機能要件定義書のひな形
業務要件定義書、機能要件定義書、非機能要件定義書のひな形を本章別紙としてまとめています。    |
２ 機能の優先順位は改善後の業務で判断する
【標準ガイドライン関連箇所：第３編第５章第２節1)イ】
要件定義で検討する機能は、必ずしも全てを実現できるわけではありません。予算やスケジュールの関係から、実現する機能を絞らなければならないことはよくあります。
機能の実現要否を検討する際には、政策目的やプロジェクト目標との関係、費用対効果等の観点を主眼として優先順位を判断していきます。また、機能を代替する方法（業務担当者の手作業や運用・保守作業にする等）も合わせて検討します。
３ 一貫性をもった論理的な記載とする
【標準ガイドライン関連箇所：第３編第５章第２節】
要件定義の内容を記した文書は、ＰＪＭＯと事業者がサービス・業務や情報システムの目指すべき姿を共有するとともに、事業者との契約上の合意文書となる重要なものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。
そのため、要件定義の内容は、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。
・曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト関係者間の認識齟齬を防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。
・業務要件定義書のインプットであるサービス・業務企画の内容とも整合の取れた区分、順番で機能を記載する。業務の単位ごとに記載する場合も、共通処理機能を識別できるように整理する等、機能数を把握できるように記載する。
・機能の説明は、箇条書き等にして簡潔に記載する。既存のサービス・業務や情報システムの変更を行う際の要件定義では、追加・変更となる要件が明確になるよう、変更箇所の記載ルールを定めて記載を統一する。
４ 要件定義書は継続的にメンテナンスする
【標準ガイドライン関連箇所：第３編第５章第２節】
要件定義が確定した後、設計・開発等を実施していく中で、要件定義の内容に漏れや誤りを発覚することはよくあります。これらは、プロジェクト管理要領の変更管理及び事業者との取り決めに従って管理されますが、要件定義書自体の修正が行われないことが多々あります。要件定義書は、プロジェクト関係者に情報システムの要件を正確に伝達するためのものであるため、変更が発生した際は常に最新化を行いましょう。
また、要件定義書の情報は、後工程である設計・開発において、設計情報のインプットとなる以外にも、各種テストのインプット情報にも、運用開始後における継続的なサービス・業務改善活動の基礎情報としても利用されます。しかし、メンテナンスという名の下、内容が変質したり、事業者側に有利な内容に変わってしまったりすることがあるため注意し、継続的な維持・管理を心掛けてください。
Step.5 機能要件の定義
既に定められた業務要件に基づき、業務要件を満たすために情報システムの機能に求められる要件を定義していきます。
開発の進め方や採用する技術によって具体的な作業の進め方は異なることがありますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。
１ 個々の領域について要件を定める
【標準ガイドライン関連箇所：第３編第５章第２節1)イ】
機能要件として定義しないといけない内容は、機能、画面、帳票、情報・データ、外部インタフェースの５つです。要件定義の対象となる情報システムによっては、このうちの一部を定義しない場合もあります。例えば、バッチ処理しかしない情報システムであれば画面の定義は不要となりますし、他の情報システムと連携しないWebサイトであれば外部インタフェースの定義は不要となります。(注記:バッチ処理とは、データの処理を即時実行（オンライン処理）せず、「10分ごと」や「毎日午前０時」などのあらかじめ決められたタイミングでまとめて実行する処理のこと。 )
様式例：機能要件定義書のひな形 機能要件定義書のひな形を本章別紙としてまとめています。  |
A. 機能に関する事項
「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。基本的に「入力」・「演算(処理)」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ１つの機能です。情報システムが提供する形は様々ですが、それらを「機能」として一覧化して整理するために用いるのが、「情報システム機能一覧」と呼ばれるドキュメントです。
「情報システム機能一覧」は、業務で求められる要件を情報システムで実現するために何が必要かを「機能」で表現したものであり、その概要や処理方式等を併せて記載し、情報システムの設計・開発を行う事業者に、情報システムに求められる要件を正しく伝えます。
| No. | 機能 ＩＤ | 機能 分類 | 機能名 | 機能概要 | 処理 方式 | 利用者 区分 | 現状の機能との差異 | 補足 | ||
|---|---|---|---|---|---|---|---|---|---|---|
| 入力 | 処理 | 出力 | ||||||||
| 1 | XXXX | ○○申請書登録 | ○○登録機能 | 記載事項の入力 | ・・・ | ・・・ | オンライン | ○○申請者 | ・・・ | ・・・ |
| 2 | XXXX | ○○申請書出力 | ○○出力機能 | 出力方式の選択 | ・・・ | 申請書の出力 | オンライン | ○○申請者 | ・・・ | ・・・ |
| 3 | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | |
表5-3 情報システム機能一覧
情報システム機能一覧は、基本的に１つの情報システムについて１つ作成します。（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）一覧では、１機能の情報を１行で表現し、この情報システムで使用する機能は全て定義されます。
この一覧は、業務要件の内容を詳細化し、そこから機能要件を取り出すことで作成することができます。例えば「○○申告書をオンラインで作成する」という1つの業務要件は、「申告内容を新規登録する」「申告内容を更新する」「申告内容を削除する」「○○申告書を作成する」「○○申告書をＰＤＦでダウンロードする」等に分解できます。ここから、必要な機能を特定します。
１つの機能が複数の業務要件に使われることもあります。同じ機能を重複して記載しないようにしてください。
情報システム機能一覧は、後工程の開発・設計で構築作業のインプットとなりますが、構築範囲や対象を特定する情報ともなります。事業者が設計・開発に関する作業を計画する際、機能を1つの単位として考えることが多いため、発注者としてはこの一覧の内容まではしっかり理解し、この一覧を利用して事業者と会話できるようにしてください。
また、忘れがちなのが情報システムを管理するために必要な機能です。ユーザアカウントの追加削除、マスタデータの更新等、各種バッチ処理の実行、ログの記録や検索等、システム管理者が操作するための機能等も忘れずに検討してください。
クラウドサービス、パッケージ製品と比較できる粒度で整理
昨今のクラウドサービスやパッケージ製品は、様々なものが開発され、提供されています。「こんなものはないだろう。」といった先入観は持たず、まずは世の中にあるかどうかを確認し、採用が可能かを検討しましょう。
採用可否の判断の一つは、クラウドサービスやパッケージ製品が提供する機能群と、求める機能群との適合性です。正確に比較するには、双方の機能を同じ粒度に揃えることがコツです。具体的にはその機能が扱う情報を「入力」・「演算(処理)」・「出力」の何れかに分解できるレベルに揃えることが１つの指針となります。
これにより、何が既にある機能で、何が新しく追加しなくてはいけない機能なのかを判別することができます。
B. 画面に関する事項
情報システムの画面は、利用者が業務の流れの中で情報システムとやり取りを行う窓口となるため、画面上で取り扱う情報の種類、画面を構成する要素の配置は、利用者の業務効率や満足度に大きな影響を与えます。
この画面に関する要件を取りまとめるドキュメントは、一般的に画面一覧、画面イメージ（画面モックアップ）、画面遷移図、画面設計方針書（画面設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。
● 画面一覧
画面一覧とは、情報システムで実現する全ての画面の要件を画面の単位で定義し、一覧化したものです。これにより、画面ごとの入出力要件や該当機能等を把握できます。
画面一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１画面の情報を１行で表現し、対象とする情報システムで使用する画面が全て記載されます。画面の要件は、該当機能を実現する画面をイメージしながら、画面名、画面概要、入出力要件等を整理し記述します。複数の機能で同一の画面を使用する場合もあることに注意してください。
| No. | 画面 ＩＤ | 画面 分類 | 画面名 | 画面 概要 | 画面入出力要件 | 画面設計 要件 | 該当 機能 | 利用者 区分 | 補足 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | XXXX | 申請書作成画面 | ○○申請書作成 | ○○申請書の作成画面 | 表示方法：・・・ 入力操作概要：・・・ | Ｗｅｂブラウザで表示可能であること。 | 機能ＩＤ: XXXX | ○○申請者 | |
| 2 | XXXX | ○○申請書確認 | ○○申請書の作成確認画面 | 表示方法：・・・ 入力操作概要：・・・ | ・・・ | 機能ＩＤ: XXXX | ○○申請者 | ||
| 3 | XXXX | 申請書登録画面 | ○○申請書登録 | ○○申請書の登録画面 | 表示方法：・・・ 入力操作概要：・・・ | ・・・ | 機能ＩＤ: XXXX | ○○申請者 | |
| 4 | XXXX | 申請書出力画面 | ○○申請書出力 | ○○申請書の出力方法確認画面 | 表示方法：・・・ 入力操作概要：・・・ | ・・・ | 機能ＩＤ: XXXX | ○○申請者 |
表5-4 画面一覧
● 画面イメージ（画面モックアップ）
画面イメージ（画面モックアップ）とは、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。HTML等で作ることで具体的な処理が組み込んでいないだけでほぼ実現したい画面の最終形になっているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方をされます。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。
要件定義の段階では、改修などの少数の画面に特定されている場合は別ですが、基本的には全画面のうち代表的なものについてのみ画面イメージを作成します。後工程で画面ごとに内容を確定させますので、要件定義の段階では代表的なものや特徴的なものが定義されていれば通常は十分です。
既存の情報システムがある場合は、その画面をベースに、追加・変更箇所が分かるようにする方法もあります。
図5-4 画面イメージの定義例
● 画面遷移図
画面遷移図とは、画面間の遷移を図に表したもので、画面間の関係や画面の流れをイメージすることできます。
画面遷移図は、画面と画面とを線で結び、矢印で方向を示すことで、どの画面からどの画面に遷移するかを示します。画面遷移図を見ることで、情報システムで実現する画面群全体を俯瞰的に捉えることができます。その情報システムにおける基本的な画面遷移パターンと比べて、特殊な画面遷移をしている個所は、特別な理由が無ければ修正し、基本的な画面遷移パターンに合わせることで、統一感のある使いやすい情報システムとなります。
図5-5 画面遷移図
● 画面設計方針書（画面設計ポリシー）
画面設計方針書（画面設計ポリシー）とは、画面設計を行う際の方針や遵守すべきルールを記載したものです。構築する情報システム全体として、どんな画面にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての画面をこの方針書に基づき設計していくことになります。
画面設計方針書は、既存情報システムや類似情報システムを参考にして、基本的な画面デザイン、ボタンの配置、画面遷移、操作手順等を検討した結果が記載されます。標準ガイドライン解説書「第３編第５章２．1)ウa) ユーザビリティ及びアクセシビリティに関する事項」の定義内容との整合にも気をつけてください。
基本的には、画面デザインはシステム全体を通じて統一することが好ましいです。利用者にとっても操作方法を覚えやすくなりますし、システムを維持運用する観点からも改修等が行いやすくなるからです。とはいっても、業務の内容によっては、その業務に特化した専用画面を作ったほうがよいこともあるでしょう。統一するか、個別に作り込むか、最終的にはその画面を見る人の利便性を重視して、決めていきましょう。
画面イメージや画面遷移図を細かく決めすぎない
画面に関する事項の検討は、実際に利用する業務実施部門の職員の意見を取り入れることにより、利用者の満足度向上につながります。一方で、現場職員の意見を聞きすぎると、微細な点にまで議論が及び、いつまでも要件が確定しないという事態に陥りがちです。
また、詳細に決めすぎると、クラウドサービスやパッケージ製品の採用を検討するときに、「適合するものがない」「大幅なカスタマイズが必要」という結論に至る弊害が考えられます。
要件定義で定める内容は、あくまで作業規模の見積りとなる元情報及び、具体的なレイアウト・画面遷移を設計するに当たっての要求事項に過ぎません。最終的には、設計段階で画面レイアウトの詳細を決めますので、この段階では不必要に詳細部分にまで入り込む必要はありません。
設計の技術的な前提条件を明記する
画面の設計・開発において前提となる各種標準やミドルウェア、ソフトウェアフレームワーク等が事前に決定されている場合は、それらの前提となる環境を画面設計方針書に詳細に明記します。また、画面イメージを検討する際には、それらの前提を踏まえた上で方針を決定してください。ミドルウェアやフレームワーク等によっては、出力イメージの実現に多大な工数が必要となる場合や実現不能となる場合があり、画面イメージが方針に沿っていないと設計時に大幅な手戻りを招く可能性があります。（注記：ソフトウェアフレームワークとは、アプリケーションを開発する際に必要となる汎用的な機能や部品等をまとめて提供し、アプリケーションの枠組みとして機能するソフトウェアのこと。)
C. 帳票に関する事項
情報システムの帳票とは、サービス・業務で使用するために情報システムから出力した紙やＰＤＦ形式等の電子帳票を指します。帳票は、利用者が業務上意識して用いられるものであるため、業務の内容やきっかけと結びついた重要な情報を持ちます。
帳票に関する要件を取りまとめるドキュメントは、一般的に帳票一覧、帳票イメージ、帳票設計方針書（帳票設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。
● 帳票一覧
帳票一覧とは、サービス・業務で使用する全ての帳票の要件を帳票の単位で定義し、一覧化したものです。これにより、帳票ごとの入出力要件や入出力形式、該当機能等を把握できます。気をつけたいのは、帳票一覧には情報システムが入出力しないものも記載する点です。明確に区別したうえで、サービス・業務で取り扱う全ての帳票を記載することにより、管理がしやすくなります。
帳票一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１帳票の情報を１行で表現します。
帳票一覧は、業務の流れを意識して整理する抜け・漏れが防ぎやすいため、業務フロー図と整合性を取って作成します。帳票概要は、誰が、どのような契機で、何のために、帳票をどうするかを記述します。また、入出力形式として紙、電子ファイル（ＰＤＦ等）の形式も明確にします。
| No. | 帳票ＩＤ | 帳票名 | 帳票概要 | 入出力の区分 | 帳票入出力要件 | 帳票設計要件 | 入出力形式 | 該当機能 | 利用者区分 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | XXXX | ○○申請書 | ○○申請用 | 出力 | モノクロ印刷 | 用紙サイズ：A4 用紙の指定：XX | 紙 | 機能ＩＤ: XXXX | ○○申請者 |
| 2 | XXXX | △△申請書 | △△申請用 | 出力 | カラー印刷 | 用紙サイズ：A4 用紙の指定：XX | ＰＤＦ | 機能ＩＤ: XXXX | △△申請者 |
| 3 | XXXX |
表5-5 帳票一覧（例）
● 帳票イメージ
帳票イメージとは、画面イメージと同様に、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。Excel等で作ることで詳細な項目まで表現されているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方があります。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。
要件定義の段階では、改修などの少数の帳票に特定されている場合を除き、全ての帳票に対して帳票イメージを作成することは無く、代表的な帳票から選定して、異なる種類分を作ります。後工程で帳票ごとに内容を確定させますので、代表的・特徴的なものが定義されていれば、通常は十分です。既存情報システムの帳票があればそれを基に、今回追加変更したい内容がわかるように情報を加えます。基になるものがないような新規のサービス・業務の場合は、紙やホワイトボード等にイメージを描きながら、職員と事業者とが対面で内容を擦り合わせます。
法定帳票等、既にフォーマットが決定しているものは、その内容を明示します。
図5-6 帳票イメージの定義例
● 帳票設計方針書（帳票設計ポリシー）
帳票設計方針書（帳票設計ポリシー）とは、帳票設計を行う際の方針や遵守すべきルールを記述したものです。構築する情報システム全体として、どんな帳票にしていきたいか、どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての帳票をこの方針書に基づき設計していくことになります。
帳票設計方針書は、作成した帳票一覧や帳票イメージ以外にも、既存情報システムや類似情報システムを参考にして、基本的な帳票デザイン、種類、様式、項目や罫線等の構成要素を検討した結果が記載されます。
帳票のレイアウトイメージを細かく決めすぎない
画面に関する事項と同様に、帳票レイアウトイメージも過度に細かく決めすぎないことが重要です。ここで決めた内容は、具体的なレイアウトを設計するに当たってのイメージ（要求事項）として扱われ、設計結果（確定したもの）として扱わないよう留意してください。
なお、法定帳票やOCRで読み取りをする帳票等、帳票レイアウトが確定しているものについては、レイアウトの定義を要件として明記します。
・帳票のレイアウトイメージは、要求事項を伝えるための表現方法として使用し、具体的なレイアウト等の設計結果を示すものとは区別して記載すること。
・帳票の利用目的を考慮し、法定の帳票や外部連携に用いる帳票等、業務の処理において不可欠な帳票を優先して整備する。
・複数の機能で同一の帳票レイアウトを使用する場合は、１つの帳票に複数の機能を紐付ける形で整理する等、帳票の種類がわかるように記載する。
・法定帳票等、帳票レイアウトが確定している場合は、遵守しなくてはいけない点（項目が満たされていればよい、配置も同一でなくてはならない、印刷位置をミリ単位で厳守しなくてはならない等）を明確に記載する。
設計の技術的な前提条件を明記する
帳票の要件として、「紙面に記載する情報」「紙面のレイアウト」に関して定義が必要であることは、想像がつきやすいのですが、「帳票を生成する方式」や「出力先」も要件の重要な要素です。バラバラの要件では、情報システムの構築にかかる費用見積りが過度に高くなる可能性があるため、同じような要件は可能な限り統一し、共通化できるように整理しておくことが有効です。
・帳票の設計・開発において前提となる各種標準やミドルウェア、フレームワーク等が事前に決定されているときは、それらの前提となる環境を詳細に明記すること。
・出力先として複数のプリンタを使用し、プリンタの印字方式に制限があるとき、出力用紙にカーボンコピー用紙を使用する等の条件があれば、補足にその旨を記載すること。
D. ファイルに関する事項
情報システムを利用する際にはさまざまな目的から、一時的あるいは継続的に情報システムからファイルを出力、入力することがあります。例えば、何らかの集計データを情報システムから出力、または入力するＣＳＶファイルやＥｘｃｅｌファイルがこれに当たります。
ファイル一覧は、基本的に1つの情報システムについて1つ作成します。（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）これにより、ファイルごとの入出力要件や入出力形式、該当機能等を把握できます。
なお、ファイル形式については、業務の一連の流れの中で活用しやすいように、再利用や追加修正が容易な形式となるように留意してください。
| No. | ファイル ＩＤ | ファイル名 | ファイル 概要 |
入出力の区分 | ファイル形式 | 該当 機能 | 利用者 区分 |
|---|---|---|---|---|---|---|---|
| 1 | XXXX | ○○集計 | ○○集計 | 入力/出力 | ＣＳＶ | 機能ＩＤ: XXXX | ○○担当者 |
| 2 | XXXX | △△データ | △△データ | 出力 | 機能ＩＤ: XXXX | △△担当者 | |
| 3 | XXXX |
表5-6 ファイル一覧（例）
要件の特性に併せてファイルの形式を決定する
ファイルには様々な形式があります。代表的なものをいくつかご紹介しますので、要件の特性に応じて使い分けてください。
・情報システムから表形式のデータを取り出したり、またはデータを取り込んだりする際に用いる形式として、ＣＳＶ形式があります。ＣＳＶとは、Comma-Separated Valueの略称で、データ（値）をカンマ（,）で区切ったテキストファイルです。このファイルの特徴は、特定のソフトウェアに依存しておらず、様々な表計算ソフトやテキストエディタ等で表示・編集が行える点です。そのため、データの交換や配布にも広く使われています。同様の特徴を持つ形式として、タブでデータを区切るＴＳＶ形式（Tab-Separated Value）等があります。
・ファイルの内容をフォーマット化したり、または、複雑な計算式を指定しておく際に用いる形式として、Ｅｘｃｅｌ形式があります。要件によっては便利な形式ですが、ＣＳＶ形式で十分なファイル形式をＥｘｃｅｌ形式とすると、構築や運用に関わるコストが増える要因にもなりますので、適切に選択するよう注意してください。
・情報システムから文書形式のデータを取り出したり、またはデータを取り込んだりする際に用いる形式として、ＸＭＬ形式があります。ＸＭＬとは、Extensible Markup Languageの略称で、データ（値）をタグと呼ばれる要素で区切ったテキストファイルです。ＣＳＶ形式と同様にデータの交換や配布にも広く使われています。ＣＳＶ形式やＴＳＶ形式との違いは、データが必ずしも表形式になっていないものも構造化して表記できる点です。いずれも、オープンデータ等でも用いられる形式となっています。
E. 情報・データに関する事項
ここで定義する情報システムの情報・データとは、情報システムの中（データベース等）で管理されるものであり、利用者にとっては目に見えないものです（目に見えるときは、画面や帳票の要素となって登場します）。
異なる機能や画面から同じデータを修正、削除できるようにすることはよくありますが、その際に部分的な観点から処理を行ってしまうとデータの不整合が発生しかねません。
一貫性や完全性等の観点からデータの品質を確保するためには、情報システムの中で扱う情報・データについて重複なく全体を定義した上で、
それらのデータが設計時点だけでなく運用時点でも品質が保たれるようにライフサイクルでの管理を行うことが重要です。
この情報・データに関する要件を取りまとめる際には、データモデル、データ一覧、データ定義、CRUDマトリクス、コード一覧、コード内容定義等のドキュメントを整備することが重要です。これらのドキュメントは、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります）。また、これらのドキュメント間の整合性を保つとともに、画面や帳票の要件を定義したドキュメントとも整合性を保つことが望まれます。
| No. | ドキュメント名 | 説明 | 補足 |
| 1 | データモデル | ・
画面や帳票などに含まれる情報を抜き出して、意味のある単位（識別キー）ごとにまとめた情報の集合体である「データ」と、他のデータとの関連を1枚に表現した図で、ER（Entity
Relationship）図という表記法で記述します。 ・ 基本的に1つのデータ項目は、必ずどこか１ヶ所のデータのみに属するようにデータを定義します（これを「正規化」と言います）。 ・ データモデルには「概念データモデル」「論理データモデル」「物理データモデル」の3種が存在しますが、要件定義では「概念データモデル」を定義する事が多いです。 ・ また、情報システムによっては要件定義時点でデータモデル定義を必要としないものもあります。 |
|
| 2 | データ一覧 | ・
データがどのようなまとまりの単位になっているかを一覧形式で示す表で、データモデルやデータ定義の目次として利用されます。 ・ データの用途や保存期間、データ件数などを定義します。 |
|
| 3 | データ定義 | ・ データ一覧にあるデータのまとまり単位にそれぞれに含まれるデータ項目の内容・説明を示す表です。 ・ １つ１つの項目がどのような意味を持ち、どのような表現やルールで記録されるかなどを定義します。 |
|
| 4 | CRUDマトリクス | ・ データが、機能一覧で定義した機能の時系列の流れの中でどう変化するのかを定義します。CRUDとは、C:Create（生成）、R:ReadまたはRefer（参照）、U:Update（更新）、D:Delete（削除）の頭文字を取ったものです | |
| 5 | コード一覧 | ・ その情報システム内で使用するコードの用途や構造を定義します。 | |
| 6 | コード内容定義 | ・ コードの値ごとに意味を持たせた場合の、コード値と意味の一覧です |
表5‐7 情報・データの要件を取りまとめる際に整備するドキュメント例
これら６つのドキュメントの詳細や機能一覧との関係性については、別紙「機能要件定義書のひな形」の「第５章 情報・データに関する事項」を参考にしてください。
後工程で作られる情報に関する設計書等のドキュメントは、専門的な情報や記法で記載されることが多く、内容を詳しく理解するには難しいものになります。したがって、ここで作成するドキュメントとそれら専門的なドキュメントとの内容を同期させることを事業者に依頼し、専門的なドキュメントを見なくても、要件が充足しているかをチェックできるようにしてください。
なお、各府省が保有するデータを活用し易い形で公開することによって、国民や民間企業等の外部関係者がデジタル技術を効率的に活用できるようにすることも重要です。
「世界最先端デジタル国家創造宣言・官民データ活用推進基本計画」（令和元年６ 月14日 閣議決定）では、オープンデータ・バイ・デザインとして、各府省が保有するデータを原則公開するとしています。情報・データに関する要件を定める際には、保有するデータをオープンデータとして公開することも併せて検討してください。また、オープンデータとして公開する場合には、行政が提供するデータであるため、オープンデータの利用者に配慮し、公開するデータの品質（一貫性や完全性等）を適切に維持できるよう継続的に管理していくことを予め検討してください。
| 参考：砂上の楼閣を防ぐデータ・マネジメント
社会・環境変化に応じてサービス・業務の質を継続的に維持又は向上していくためには、サービス・業務を進め方の改善を行う工夫が必要となります。その工夫を生み出すためには、サービス・業務に関係する情報・知識・知恵も必要となります。では、情報・知識・知恵はどうやって生まれるのでしょうか？ サービス・業務の目的に応じて様々な文書や帳票類を作成又は取得するなどし、それらに対しての確認や処理を行い、何らかの結果を生み出してサービス・業務を実施していくことが多いと思います。サービス・業務で扱う文書や帳票類には様々なものがあり、紙で扱うものもあると思いますが、現在ではそのほとんどが文書作成ソフトや表計算ソフト等を利用してデジタル処理を行うことが多いと思います。例えば、何らかの数値を集めて統計処理の対象となる統計データの場合には、デジタル処理することがほとんどだと思います。また、行政文書については、公文書等の管理に関する法律（平成二十一年法律第六十六号）第二条において、電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。）も文書と定義されています。統計データ、電磁的記録による文書、つまりデータを日常的に扱い、サービス・業務を遂行していることになります。さらに、「世界最先端デジタル国家創造宣言・官民データ活用推進基本計画」（令和元年６ 月14日 閣議決定）において、官民データを活用して証拠に基づく政策立案（EBPM）を推進することが示されており、政策立案というより高度なデータ活用が期待されています。 サービス・業務の遂行に必要となるData（データ）、Information（情報）、Knowledge（知識）、Wisdom（知恵）の関係性を示したのがDIKWモデルです。このモデルは1980年代に検討された思考モデルであり、その後改良され多くの分野で定義されていますが、その代表的なものを下図に示します。 DIKWモデルから考えると、「情報」の品質はデータの品質に影響を受け、同様にして「知識」の品質は情報の品質の影響を受け、「知恵」の品質は知識の品質に影響を受けることになります。つまり、すべての土台となるデータの品質が情報・知識・知恵に影響を与えることになるので、品質の悪いデータから導かれた情報・知識・知恵を利用してサービス・業務を遂行する場合には、十分な価値を提供できないと考えられ、砂上の楼閣になりかねません。誤ったデータを利用してデータサイエンスによる高度な分析を行ったとしても、その分析結果が正しいと言えるでしょうか？ 
サービス・業務の目的の達成に必要となるデータの項目、その意味や内容などを表すデータの定義を十分に行わないと、データを使いたいときにすぐに引き出して利用できない、誤って不適切なデータを利用して誤った結果を導き出してしまうなどサービス・業務に支障をきたすかもしれません。つまり、品質の低い（不完全な、不正確な、有効期限切れなど）データは、誤用又は誤解を招くリスクがあります。このリスクを回避するためには、場合によっては語の整理を行い、サービス・業務に特化した辞書（用語集）を作成・管理するのもよいでしょう。また、ある意味を表す言葉が1語に決まれば問題ないのですが、似た意味を持つ語を複数用いることを許す場合には、カテゴライズして類語辞書を作成・管理することも必要です。 サービス・業務が安定的にその目的を達成していくためには、データの意味定義だけではなく、入力・取得したデータの中身について次のような評価軸（例）で継続的に確認しつつ適切に品質を管理することが重要です。 ・一貫性：データに不整合はないか？一貫して表現されているか？ ・完全性：データに欠損はないか（すべての要素は揃っているか）？ ・正確性：表現すべき「現実世界」の対象や事象を正しく表しているか？ ・精度：データの詳細度（有効桁数等）は十分か？誤りやノイズはないか？ ・一意性（重複排除）：同じ実体を示すデータに重複はないか？ データ品質を適切に管理するためには、時間推移に伴う社会・環境変化を考慮し、データの更新・修正のタイミングや廃棄の考え方を検討した上でデータライフサイクル（計画、設計と実装、生成・取得、格納・維持、利用、強化、廃棄）の管理を行うことが必要となります。いつまでも古いデータだけを用いていたのでは、適材適所でないサービス・業務を提供するおそれが強まり、目的を達成できずじまいになりかねません。 「デジタル手続法（情報通信技術の活用による行政手続等に係る関係者の利便性の向上並びに行政運営の簡素化及び効率化を図るための行政手続等における情報通信の技術の利用に関する法律等の一部を改正する法律（令和元年法律第16号））」が令和元年５月31日に公布されたので、今後、データをさらに活用して行政のデジタル化を推進していくことになり、これまでのITガバナンスの強化だけではなく、データ・ガバナンスの強化も必要となります。加えて、サービス・業務の質を継続的に維持又は向上していくためには、前述したデータの意味定義及び品質管理、そしてデータライフサイクルの管理を含めたデータ・マネジメントをプロジェクトの全体を通して行う、すべての土台となるデータの適切なマネジメントが不可欠です。 また、ＰＪＭＯは、調達手続を通じて、サービス・業務企画や要件定義の内容等が事業者に明確かつ十分に伝達されるようにするのと同様に、データ定義を十分に行ったうえでその内容等を事業者に明確かつ十分に伝達されるようにすることが求められます。このとき、特にデータを活用する実際のサービス・業務に深く関与する制度所管部門や業務実施部門が主体性を持って対応することが重要です。 |
F. 外部インタフェースに関する事項
情報システムの外部インタフェースとは、サービス・業務の内容を実現するために、自分の情報システムが他の情報システムと連携して情報を受け渡す仕組みです。情報連携の内容や形式・仕組みには様々なものがあり、明確に定義する必要がありますが、連携先である他の情報システムの都合もあるため、双方の要件を出し合い、すり合わせることが必要となります。
この外部インタフェースに関する要件を取りまとめるドキュメントは、一般的に外部インタフェース一覧と呼ばれるものです。情報システム機能要件一覧との整合性も意識しながら作成を進めます。
外部インタフェース一覧では、他の情報システムと連携する全ての情報をそれぞれの情報の単位で定義し、一覧化します。これにより、情報ごとの相手先情報システムや送受信のタイミング、条件等を把握できます。
外部インタフェース一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１連携情報を１表現し、対象とする情報システムと他の情報システムと連携が全て記載されます。要件には、連携先の情報システムとの送受信のタイミングや送受信の際の条件も、明確にして定義します。
なお、連携先となる情報システムの要件が確定していない等により、要件定義の段階で定義できない外部インタフェースの内容については、その理由を記述します。また、障害発生時や緊急時の代替手段が規定されていれば、それらも記述します。
外部インタフェース一覧で記載した連携は、情報システムが出来上がってからのテストにおいて、１つ１つテストを実施する必要があります。相手先の情報システムが同時に構築中の場合や改修が行われた場合等により、要件定義時に合意した内容が時間の経過とともに変更されていることがあります。連携先との意思疎通が不十分なときは、情報システムがリリースされて初めて問題に気付くことも少なくありません。
そういったトラブルを未然に防ぐために、事業者や相手先情報システムのＰＪＭＯと連携して、意思疎通が不十分とならないよう対策をしてください。
| No. | 外部インタフェース ＩＤ |
外部インタフェース名 | 外部インタフェース概要 | 相手先システム | 送受信区分 | 送受信データ | 送受信タイミング | 送受信の条件 | 補足 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | XXXX | 申請者情報連携 | 申請の審査に関わる申請者の情報を○○システムから日次で取得する。 | ○○システム | 受信 | 申請者情報 | リアルタイム | 日次 | |
| 2 | XXXX | 申請結果連携 | 審査において承認された申請情報を○○システムに日次で提供する。 | ○○システム | 送信 | 承認済申請情報 | リアルタイム | 日次 | |
| 3 | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ |
表5-8 外部インタフェース一覧
情報システム関連図で連携イメージが伝わるようにする
新たに整備する情報システムと他の情報システムとの連携は、情報システム関連図を作ることで、イメージが伝わりやすくなります。
この図を中心とし、次に示す点に留意して、表5-8に示す外部インタフェース一覧に要件を整理します。
・データ互換性の確保のためにデータ変換が必要となる場合が多いことから、
やり取りするデータだけでなく、物理的なインタフェース、プロトコル、フロー図、文字コード、データフォーマット、取り扱う値の範囲、通信の速度等について、可能な限り詳細に記載する。 (注記:プロトコルとは、情報システムを構成する機器同士が通信をする際の手順や規約などを定めたもの。ネットワーク間で双方の機器が理解できる同じプロトコルを使わないと通信は成立しないため、インターネット上のプロトコルの大部分はRFCという形式で技術仕様が公開されている。)
・双方の情報システムが取り扱う情報の格付の区分等が異なる場合に、機密情報を連携することにより情報セキュリティ対策が不十分とならないよう、連携の方向や内容等に十分留意する。
・データベースの所在国についても十分に留意する必要がある。例えば、行政機関個人情報保護法第2条第2項に規定する個人情報又は番号法第2条第5項に規定する個人番号を蓄積するデータベースについては、国内法が適用される場所に制限する必要があることを認識し、問題がないことを確認することが考えられる。
・要件定義の段階で定義できない外部インタフェースがある場合には、その理由を含めて記載すること。
・障害発生時や緊急時の代替手段が規定されている場合は、それらも記載すること。
２ 必要な機能を漏れなく抽出し検討する
【標準ガイドライン関連箇所：第３編第５章第２節1)イ】
要件定義を進めていくと陥りやすいのは、優先度の高いやりたい事だけを定義してしまうことです。業務要件では、毎日行う業務ばかりに議論が集中して、日常的に実施頻度の少ない業務の議論は後回しになりがちですが、機能要件でも同様のことが発生します。
事例：要件の考慮不足が設計開発工程の遅延に繋がる 従来、紙で取り扱っていた申請書の管理を、オンライン入力してデータ保存できるサービスを構築することにしました。 テストの段階で、申請者が届出書に記載した内容に誤りがあった場合や、職員が情報を入力する際に間違ってしまった場合等に関する考慮が不足しており、情報システムにも修正や削除をする機能が備えられていないことが明らかになりました。従来から修正や削除の処理はありましたが、紙処理での手作業の場合は自由に作業ができたため、業務マニュアルには削除等の対応方法は記載されていませんでした。その業務マニュアルどおりにシステム機能を検討してしまったために、必要な機能の考慮が漏れてしまったことが原因でした。 
その結果、業務手順の見直しから機能の検討、追加の設計・開発、テスト等が必要となり、リリース時期に影響を与える程のスケジュール遅延が発生してしまいました。 手作業の業務をシステム化検討する際は、通常よく行う作業（上記の例では、入力や参照）だけではなく、業務マニュアルに記載されていなくても職員が暗黙的に行っている作業（上記の例では、申請内容の誤りや間違いへの対応）も含めて検討し、作業を漏れなく洗い出す必要があることに留意してください。 |
画面操作を例とすると、基本的な機能やよく使う機能の要件は忘れない代わりに、めったに発生しないデータの処理手順や誤入力した際の回復処理については議論が抜けがちになります。これらは要件定義漏れとして、テストをすり抜け、リリース後発覚してトラブルとなるおそれがあります。
誤入力の回復が簡単にできないと職員が認識している場合、本来行う基本的な業務で過度に慎重になってしまい、その業務のシステム利用が敬遠されてしまうことも考えられます。また、特別な処理が必要になったときに、運用事業者によるDB操作によるデータ補正等のアプリケーション機能以外での対応が必要となり、運用・保守費用の増大に繋がりかねません。
このような事態に陥らないためには、業務要件から機能要件を抽出する際、業務の流れに沿った通常のシステム操作パターンを十分に検討し、発生し得る操作を漏れなく抽出することが重要です。また一方で、非常に頻度の低い操作や、回復処理を全て機能として盛り込む必要はありません。発生頻度が極度に低いものは、運用対応と判断して妥当な場合もあります。
「人は間違うもの」という前提で、「ここで間違えたらどうやって訂正する？」「一連の操作を丸ごと取り消ししたくなったら？」等を抽出して、特殊な操作や回復方法を適切に検討しましょう。
３ 実現手段ではなく、求める結果を記載する
【標準ガイドライン関連箇所：第３編第５章第２節1)イ】
要件定義では、その情報システムが「どのように処理するか」ではなく、「結果としてどうなるか」を定義します。これは、要件定義段階で実現手段を定義してしまうことで、情報システムの専門家である事業者が、最適な実現手段を提案できなくなってしまうためです。
特に、新規構築ではなく、既存の情報システムの更改をする際には注意が必要です。既存の情報システムに問題があるにもかかわらず、使い慣れていることを理由に既存の情報システムの機能を踏襲して要件を記載してしまうことがあるためです。
このように記載してしまうことで、新たな形での機能提案が得られず、新しい情報システムに既存の情報システムの悪い面が継承されてしまい、更改の目的が果たされないこととなります。また、新システムで提案される新しい方式では、既存システムで行っている処理が不要になる可能性がありますが、要件として記載されていた場合、設計・開発事業者がその処理を不要と判断することが難しくなります。
既存の情報システム関連資料は、新たな情報システムを設計・開発するための重要な情報であることは間違いありません。ただし、これらは参考資料として提示し、既存の情報システムと機能を同一にする必要はないことを明示してください。
Step.6 非機能要件の定義
既に定められた業務要件に基づき、業務要件を満たすために情報システムの非機能に求められる要件を定義していきます。
ところで、非機能とはなんでしょう？機能は想像がつきやすいと思いますが、非機能となるとどんなことを決めたらよいかわかりづらいですよね。
情報システムの専門家ではない職員のみで、多岐にわたる非機能要件を全て定義することは、通常困難です。技術的な厳密な定義を説明してもさらにわかりづらくなると思いますので、発注者側にとってわかりやすい具体例を示しながら非機能を説明しつつ、その要件として何を定義しなければならないかを解説していきます。
１ 個々の領域について要件を定める
【標準ガイドライン関連箇所：第３編第５章第２節1)ウ】
非機能要件として定義しないといけない内容は次に挙げる17個の内容（A～Qまで）です。
機能要件の場合は、内容の一部を定義せず、調達時の事業者の提案に委ねることもありますが、非機能要件の場合は基本的に全ての項目を定義します。もちろん、情報システムやプロジェクトの特性によって、定義すべき内容の量は異なります。
項目は細分化されていますが、実は経験的に理解している内容が多くありますので、それらを見ていきましょう。
A. ユーザビリティ及びアクセシビリティに関する事項
情報システムは、提供するサービス・業務の利用者が、使いやすいと実感することにより利用が促進され、使いやすさは利用者の満足度や業務効率の向上に大きく寄与します。本項では、「使いやすさ」をユーザビリティとアクセシビリティという２つの軸で明らかにします。
ユーザビリティとは、利用者がサービス・業務を利用して実施したいことを、ミスなく効率的に行うために必要となる事項であり、アクセシビリティは、目的の情報へのたどり着きやすさを指します。どちらも利用者の年齢、身体的制約、利用環境等の違いによる配慮が必要です。
| No. | 利用者区分 | 利用者の種類 | 特性 | 補足 |
|---|---|---|---|---|
| 1 | ○○申請者 | ・・・ | 60歳以上の割合：○○％ | |
| 2 | ○○入力担当者 | ・・・ | 業務の環境上、片手で必要な入力を行う必要がある マウス入力が困難な環境で使用する | |
| 3 | ○○決裁者 | ・・・ | 対象手続に関する知識レベルが高い | |
| 4 | ・・・ | ・・・ | ・・・ |
表5-9 情報システムの利用者の種類、特性
次に整理した特性をグループ化して、ユーザビリティ、アクセシビリティの分類を作成します。例えば画面の構成や操作のしやすさ等を分類として定義し、次に分類ごとにどのような使いやすさを実現したいかをユーザビリティ要件として示します。
また、当該情報システムの特性に鑑みて日本産業規格（JIS）への準拠や多言語対応等の要件を整理し、情報へのアクセスの容易さをアクセシビリティ要件として示します。
| No. | ユーザビリティ 分類 |
ユーザビリティ 要件 |
補足 |
|---|---|---|---|
| 1 | 画面の構成 | ・ 何をすればよいかが見て直ちにわかるような画面構成にすること ・ 無駄な情報、デザイン及び機能を排し、簡潔でわかりやすい画面にすること ・ 十分な視認性のあるフォント及び文字サイズを用いること ・ 画面の大きさや位置の変更ができること |
|
| 2 | 操作方法のわかりやすさ | ・ 無駄な手順を省き、最小限の操作、入力等で利用者が作業できるようにすること ・ 画面上で入出力項目のコピー及び貼付けができること 業務の実施状況によっては、ショートカットや代替入力方法が用意されること（例えば、片手だけで主要な操作が完了することが求められたり、マウスを利用することが困難であったりする場合が考えられる） |
|
| 3 | 指示や状態のわかりやすさ | ・ 操作の指示、説明、メニュー等には、利用者が正確にその内容を理解できる用語を使用すること ・ 必須入力項目と任意入力項目の表示方法を変えるなど各項目の重要度を利用者が認識できるようにすること ・ システムが処理を行っている間、その処理内容を利用者が直ちにわかるようにすること |
|
| 4 | エラーの防止と処理 | ・ 利用者が操作、入力等を間違えないようなデザインや案内を提供すること ・ 入力内容の形式に問題がある項目については、それを強調表示する等、利用者がその都度その該当項目を容易に見つけられるようにすること ・ 電子申請等については、確認画面等を設け、利用者が行った操作又は入力の取消し、修正等が容易にできるようにすること ・ 重要な処理については事前に注意表示を行い、利用者の確認を促すこと ・ エラーが発生したときは、利用者が容易に問題を解決できるよう、エラーメッセージ、修正方法等について、わかりやすい情報提供をすること |
|
| 5 | ヘルプ | ・ 利用者が必要とする際に、ヘルプ情報やマニュアル等を参照できるようにすること |
表5-10 ユーザビリティ要件
| No. | アクセシビリティ 分類 | アクセシビリティ 要件 | 補足 |
|---|---|---|---|
| 1 | 基準等への準拠 | 広く国民に利用され公益性の高い情報システムであるため、日本産業規格JIS X8341シリーズ、「みんなの公共サイト運用モデル」（総務省）、ＸＸ省ウェブアクセシビリティ指針等に従い、アクセシビリティを確保した設計・開発を行うこと（※引用した基準は例示である） | |
| 2 | 指示や状態のわかりやすさ | 色の違いを識別しにくい利用者（視覚障害のかた等）を考慮し、利用者への情報伝達や操作指示を促す手段はメッセージを表示する等とし、可能な限り色のみで判断するようなものは用いないこと | |
| 3 | 言語対応 | 本情報システムでは、日本語のほか、ＸＸ語で記載されたコンテンツに対応すること |
表5-11 アクセシビリティ要件
B. システム方式に関する事項
「システム方式」では、定義された業務要件のうち、情報システムが処理・実行する範囲について、情報システムとして動作するために必要となる「道具」の具体的な実現方法を明確にします。
| No. | 全体方針の分類 | 全体方針 | 補足 |
|---|---|---|---|
| 1 | システムアーキテクチャ | 本情報システムのシステムアーキテクチャは、【メインフレーム型／クライアントサーバ型／Ｗｅｂサーバ型／政府共通プラットフォーム利用型／外部サービス利用型／スタンドアロン型】とする | |
| 2 | アプリケーションプログラムの設計方針 | 情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）間の疎結合、再利用性の確保を基本とする | |
| 3 | ソフトウェア製品の活用方針 | 広く市場に流通し、利用実績を十分に有するソフトウェア製品を活用する アプリケーションプログラムの動作、性能等に支障を来たさない範囲において、可能な限りオープンソースソフトウェア（ＯＳＳ）製品（ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェア製品）の活用を図る。ただし、それらのＯＳＳ製品のサポートが確実に継続されていることを確認しなければならない |
|
| 4 | システム基盤の方針 | 政府共通プラットフォームが提供する稼働環境を可能な限り活用し、可用性に優れたシステム構成とする |
表5-12 情報システムの構成に関する全体の方針
ツール等を利用し、システムライフサイクルコストを削減する
アプリケーションの開発ツールは日々進歩しています。例えばノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、コストの削減等が見込める場合等には、積極的に採用を検討してください。
・ＲＦＩ等を通じて事業者から得た情報を踏まえ、実現性が十分であること及びコスト効率を高めることを基本として方針を検討する。また、必要に応じて新技術の適用可能性も検討する。
・システムアーキテクチャ及びシステム基盤の方針の検討は、〈府省共通システムが提供する稼働環境、サービス等の利用の検討〉及び〈クラウドサービスの活用の検討〉も踏まえて行う。
・ソフトウェア製品の選定においては、機能要件や非機能要件から適切なソフトウェア製品を選定できるよう、留意する。
C. 規模に関する事項
「規模」とは、情報システムを使うユーザの数や取り扱う情報量を指します。利用者が多ければ単位時間当たりで多くのリクエストを処理できる能力が必要となりますし、情報量が多ければ、より大容量のデータベース等が必要になります。要件定義では「利用者は最大100人、平日は常時80人、土日は基本的に休みのため10人未満」といった要件を定量的に示します。
次に示す各表では、機器やデータ等の量について整理し、想定可能な最大値を要件として示します。
| No. | 機器の区分 | 機器の用途 | 機器数 | 設置場所 | 補足 |
|---|---|---|---|---|---|
| 1 | クライアント端末 | 窓口入力用 | XX | 本省○階○○室 | |
| 2 | プリンタ | 証明書出力用 | XX | ○局○○室 | |
| 3 | ・・・ | ・・・ | ・・・ | ・・・ |
表5-13 機器数及び設置場所
| No. | データ区分 | データ量 | 補足 |
|---|---|---|---|
| 1 | 操作ログ | 最大XXMB | |
| 2 | ○○用データ | 最大XXMB | |
| 3 | 個人用フォルダ | 最大XXMB |
表5-14 データ量
| No. | 項目 | 処理件数 | 補足 |
|---|---|---|---|
| 1 | アクセス数 | ・ 定常時：XX件/日 ・ ピーク時：XX件/日 ・ ピーク特性：○月に年間の処理のXX％が集中 |
|
| 2 | ○○操作件数 | ・・・ | |
| 3 | ○○処理件数 | ・・・ |
表5-15 処理件数
| No. | 利用者区分 | 利用者数 | 補足 |
|---|---|---|---|
| 1 | ○○申請者 | ・ 同時アクセス可能人数：XX人 ・ アクセスの同時到達量：XX回/min ・ 利用時間帯：XX時～XX時 |
|
| 2 | ○○入力担当者 | ・・・ | |
| 3 | ○○決裁者 | ・・・ |
表5-16 利用者数
過度の規模要件は、過度の情報システム投資を招く
「大は小を兼ねる」と言いますが、過大は無駄を招きます。「十分な」といった曖昧な表現を避け、「○○人」「××件」といった定量的な表現とすることで、適切な規模要件を設定してください。
・情報システムの規模は、性能や信頼性に関する要件を検討する際の前提条件であり、機器の仕様や配置等の設計、調達コストに影響を与える。
・過度の規模要件を規定することは、過度の情報システム投資を招くことになる。
設置場所を開示するべきでない場合の記載方法
設置場所が不特定多数の者に知られることが情報セキュリティ上問題あるサーバ等の機器については、「○○県内」「東京都23区内」といった記載にとどめ、詳細については契約締結後、受注者のみに開示するものとし、設置場所が特定できないように配慮してください。
・建物やフロア等、ネットワーク接続要件を考慮して、設置場所を記載する。例）厚生労働省X階XX室、XX局XX室
・情報セキュリティの観点からみて、設置場所を明示する場合、設置場所に関する情報は広く一般に公開するものではない。このため、この情報については、非開示覚書(NDA)を交わした上で、閲覧等によって開示することを考慮する。
D. 性能に関する事項
「性能」とは、情報システムの能力を指します。能力を測る指標には、応答性能やスループット（処理性能）等があります。ネットショッピングで例えると、商品を検索し検索結果のリストが表示され、特定の商品を選択すると詳細情報が表示される、という一連の流れが一般的ですが、検索ボタンや選択ボタンを押してから、次の画面が表示されるまでの時間が応答性能です。スループットは、一度にどれだけの量を処理できるかという性能で、通常時でも大量に注文が発生するバーゲンセール開催中でも、定義した応答性能が担保されるということを表します。経験があるかもしれませんが、ネットショッピング中に検索結果が返ってこないと、購買する意欲が下がってしまいます。性能はサービス・業務の質に大きな影響を与えます。また、スループットを担保するためには、ハードウェアや回線増強等の投資が必要です。
性能に関する事項は、費用と性能のバランスをとって定義しましょう。
| No. | 設定対象 | 指標名 | 目標値 | 応答時間達成率 | 補足 |
|---|---|---|---|---|---|
| 1 | ○○処理 | レスポンスタイム | 定常時：X秒以内 ピーク時：X秒以内 |
90％ | |
| 2 | ターンアラウンドタイム | 定常時：X秒以内 ピーク時：X秒以内 |
90％ | ||
| 3 | サーバ処理時間 | 定常時：X秒以内 ピーク時：X秒以内 |
平均値 | ||
| 4 | ○○処理 | レスポンスタイム | 90パーセンタイル | ||
| 5 | ターンアラウンドタイム | 90パーセンタイル | |||
| 6 | サーバ処理時間 | 平均値 |
表5-17 応答時間
| No. | 設定対象 | 目標値 | 補足 |
|---|---|---|---|
| 1 | ○○処理 | XX件/秒 | |
| 2 | |||
表5-18 スループット
多機能化で情報システムの性能が大きく劣化しないようにする
ユーザ要望や企画の実現、運用保守コストを削減するために、複数の画面や帳票の統合を検討することがありますが、統合することにより、次に示すようなデメリットが発生することもあります。
・ひとつの画面や帳票で取り扱う項目や機能が増えるため、画面の表示や帳票出力までの処理に時間がかかるようになる。
・システム処理そのものに加え、途中で発生したエラーのリカバリー処理も統合することにより複雑化するため、テスト工数の増大も含め、かえって保守コストが増加することもある。
このような事態を避けるために、画面標準等で、一つの画面や帳票に盛り込む情報量の基準の設定や、現在画面や帳票が分割されている理由を、業務面だけではなくシステム面からも確認しておくことが重要です。
現場の職員は一つの画面や帳票で多岐に渡る業務を行いたいと要望しがちですが、視認性や操作性の観点から、ストレスを感じることなくスムーズに使える範囲内で、適切に分割する方が有効です。
| 事例：非機能要件が機能要件に影響することもある
ある省の既存情報システムを更改するプロジェクトにおいて、改善検討を行うことになりました。現状調査の結果、画面で指定する組織名称のプルダウンの内容が異なるだけで、他の項目はほぼ同一の類似した画面が複数存在していることが判明しました。保守コスト削減の観点から、類似画面を統合することにしました。 その結果、統合した画面では、組織名称のプルダウンに全組織（数千）が表示されることになり、画面表示時に大量の組織名称の情報を取得するため、画面表示までの性能が大幅に劣化し、当該画面を通じて行う業務の効率が低下してしまいました。 
機能要件では問題がないと見える事柄も、非機能要件では全く違った影響が発生することがあります。この例では、非機能要件のうち、規模に関する事項を検討することで機能要件自体の見直しが発生しました。既存情報システムがある場合は、非機能面において現在の仕様になっている経緯や背景も確認した上で、改変を行いましょう。 |
想定値ではなく実測値等から真に必要とされる性能を指定する
性能を検討していくと、つい安全な方向に結論を倒しがちです。性能の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意してください。
・要求事項の記載は、できるだけ定量的な表現となるようにすること。
・過度な性能要件を設定して調達コストを押し上げることのないよう性能要件の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意すること。
・常時・定期のモニタリングが必要な場合には、個別部分の性能、トランザクション量等について明示し、組み込みの必要性を指定すること。
E. 信頼性に関する事項
「信頼性」とは、情報システムが持つ故障への耐性の度合いのことを指します。一般的には平均故障間隔（分又は時間）で評価します。平均故障間隔の値が小さければ小さいほど信頼性は高いと言えます。
情報システムを、構成する要素（サブシステムやネットワーク等）に分解し、情報システム全体での年間稼働率を踏まえて、各要素の信頼性に係る指標や目標値を要件として示します。
参考：最適なシステム構成 情報システム全体の信頼性はサーバや周辺機器、クラウドサービスだけでなく、サービス提供者と利用者を結ぶネットワーク等を含めて検討する必要があります。 例えば以下のような稼働率の要素で構成されたシステムは、サーバはシックスナインの稼働率を確保していますが、ネットワークや負荷分散装置を含めた稼働率はスリーナインを下回っています。
このように、局所的に高い稼働率を確保しても、他の構成要素の稼働率が低ければシステム全体の稼働率は低くなります。 高い稼働率を確保するには、信頼性の高い機器や冗長な構成が必要となり、コストがかかるため、過剰な構成とならないよう、業務要件に沿った設計が重要です。 デジタル・ガバメント推進標準ガイドラインでは、情報システムに求められる稼働率について、以下のような参考情報を示しています。 表 1 システムプロファイル
表 2 システムプロファイルから考えるシステム基盤に係る非機能要件のモデル
表：デジタル・ガバメント推進標準ガイドライン（別紙５）から一部抜粋 信頼性の高いシステムは構築だけでなく、維持にもコストがかかります。業務要件の求める稼働率を大きく上回るような過剰な設計とならないように留意しましょう。
注記 表5-19 可用性要件 F. 拡張性に関する事項「拡張性」では、将来の利用者の拡大やデータ量の増加に備えて、情報システムの処理性能を維持するための、ハードウェア、ソフトウェアの対処方針を、要件として定量的に示します。想定する拡張が必要となるケースを、提供するサービスや業務と併せて具体的に記載することが重要です。「利用者数がX倍になる」だけではなく、「○○サービスを利用する部署がY倍になるため」といった、拡張の背景を記載することにより、設計時に考慮しやすくなります。 (注記 ＭＴTRとは、システムを復旧・修理するまでにかかる平均時間のこと。ＭＴTRはMean Time To Repairの略。 )
G. 上位互換性に関する事項「上位互換性」とは、主にソフトウェア製品において、新しいバージョンの製品で古いバージョンの製品が利用できることを指します。代表的な製品は上位互換性がありますが、バージョンアップに伴い、帳票作成ツールの場合レイアウトが崩れたり、ブラウザの場合画面のレイアウトや特定のボタンが動作しなくなったりといった、一部の機能に限り上位互換性がないこともあります。 当該情報システムを構成するソフトウェア製品において、将来予想されるバージョンアップ時の対応可能性について、定義時点において明確にできる範囲内で、具体的な対象とバージョンアップ時の対処方針を要件定義書に記載します。 各製品のバージョンアップポリシーを踏まえて、コストを検討する 機能追加等のバージョンアップが頻繁に行われる製品を利用する場合、バージョンアップ後のテストに係るコストが膨大なものとなり、費用対効果が著しく悪化する可能性が高くなります。 したがって、製品の選定に当たってはバージョンアップ後のテストの簡略化等を検討するとともに、費用対効果が見込める場合には、OS・ミドルウェア等の乗換についても積極的に検討してください。 ・バージョンアップは将来の不確定要素であることから、上位互換性を過度に要求する場合、事業者が応札に対して慎重になる可能性や、リスクを見込んだ高額な調達コストとなる可能性があることに留意する。
H. 中立性に関する事項「中立性」とは、情報システムを構成する要素が、特定の技術や製品に特化しないことを指します。いわゆるベンダーロックインを排除するためには、重要な要素です。 特殊なツールを利用する場合、将来的に他の製品への乗り換えが困難にならないよう、中立性の観点から問題のないツールであることを要件として示します。
I. 継続性に関する事項「継続性」では、当該情報システムを構成する要素（サブシステム、サービス等）に分解し、情報システム全体での目標復旧時間を踏まえて、各要素の継続性に係る指標や目標値を要件として示します。
表5-20 継続性要件 クラウドサービスとオンプレミスは継続性の確保方法が異なる 例えば、クラウドサービスを利用する場合には、オンプレミスのようにテープ等の媒体で別途保管する必要はなく、クラウドサービスプロバイダが提供するバックアップサービスを利用すればよいと考えられます。ただし、バックアップサービスには様々な種類が存在することに鑑み、選択する手法が妥当なものであることを確認できるようにすることが重要です。(注記:オンプレミスとは、発注者が自ら情報システムに必要な機器（サーバ、ネットワーク、ソフトウェア製品等）を調達し、情報システムの運用を行うこと。)
J. 情報セキュリティに関する事項「情報セキュリティ」とは、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。機密性とは、ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保することです。完全性とは、情報が破壊、改ざん又は消去されていない状態を確保することです。可用性とは、情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することです。 ここでは、自組織において定められた情報セキュリティポリシーを遵守するために必要な情報セキュリティ対策の内容について、具体的に記載してください。 個々の業務について記載するのではなく、業務分類等、グループ単位で記載します。また、ユーザ認証において、求められる要件（例えば、社内の認証サーバと連携できること等）があるときは、それらも記載します。
表5-21 情報セキュリティ対策要件 当該情報システムに実装する機能や画面に対して、利用者の権限に応じた管理レベルを記載します。
表5-22 権限要件 想定されるリスクの概要と対策について記載します。
表5-23 リスク一覧 定義に当たっては、自府省の情報セキュリティポリシーを参照するとともに、必要に応じて「政府機関の情報セキュリティ対策のための統一基準群」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（平成23年４月28日内閣官房情報セキュリティセンター）等を参照し、必要な対策を漏れなく記載しましょう。 当該情報システムに求めるセキュリティ要件については、次に示す「最低限記述すべき情報セキュリティ対策要件」を参考にして、表5-21で示した様式を参考に記載してください。
リスクの概要と対策を定義する ・リスクが多様化しているので、なるべく多くのリスクの洗い出しを行うこと。 ・当該情報システムの格付けに見合った情報セキュリティ対策を行うこと。 ・公開されるWebサイト等のドメインについては、利用者がわかりやい政府サイトとするとともに、政府サイトに似せたサイト上で個人情報を収集する等といったフィッシング等のセキュリティ事故が起こりにくい環境を実現すること。 第三者による脆弱性検査を実施する 当該情報システムに対して修正を行う場合、その改修が影響する範囲を対象として第三者による脆弱性検査を実施します。 第三者による脆弱性検査を実施するか否かの判断に当たっては、下表の観点を考慮し、案件ごとに判断してください。なお、第三者による脆弱性検査を実施しない場合には、実施しない理由を明確にします。また、第三者による脆弱性検査は、当該調達に基づく改修が影響する範囲を対象とし、情報システムとしての脆弱性がないことを検査するものであり、実装されたセキュリティ機能の検査を行うものではないことに留意してください。
表5-24 脆弱性検査の観点 K. 情報システム稼働環境に関する事項「情報システム稼働環境」とは、当該情報システムに係る、クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等を明らかにすることを指します。稼働環境には、運用、保守、研修、検証等に必要な環境も含めます。 「システム方式」は構成要素ごとの方針を示すものですが、情報システム稼働環境は、もう一段階分解し、構成要素の内容を具体的に示します。 
図5-7 ハードウェア構成図
表5-25 ハードウェア構成
表5-26 ソフトウェア構成
表5-27 ネットワーク構成
表5-28 施設・設備要件 クラウドサービスを利用する場合は、サービスに関する要件を記載します。オンプレミスで構築する場合は、ハードウェア構成、ソフトウェア構成、ネットワーク構成、施設・設備等の要件の定義に加えて、情報システムのハードウェア構成図も記載します。なお、記載に当たっては、仮想化による物理的な機器の削減についても考慮するとともに、将来的な拡張予定についても、その範囲を識別できるよう留意します。 レンタル/リース/買取の特徴を理解して、選択する 以前は高額なハードウェア製品が多く存在していましたが、昨今は製品価格が下落傾向にあるため、リースよりも買取の方が最終的には安価になることもあります。プロジェクトの特性に併せて、最適な方式を検討しましょう。 なお、事業者より見積りを取得する際には、「一式」ではなく、製品ごとの本体価格を提示するよう依頼し、機器単位で比較ができるよう留意してください。
表5-29 レンタル・リース・買取の比較表 クラウドサービス/オンプレミスの特徴を理解して選択する 稼働環境に係る要件を記載する場合、クラウドサービスとオンプレミスでは記載内容が異なることを理解して進めてください。 ・情報システムの稼働環境は、システム方式と同様に情報システム設計の基本的な前提条件であるため、定義時点において明確にできる範囲内で要件定義書に記載する。なお、将来的な拡張性要件を記載する場合、今回の調達対象を明確にするように注意すること。 ・クラウドサービスを利用する場合、サービスによって可用性に係るSLAが異なること、使用状況に応じてリソースを変動させることができること等から、厳密に構成を確定せず、想定構成を参考として記載するに留め、実際構成は適宜受注者に提案することを求める形とすること。また、運用・保守、移行、刷新等既存の情報システムがある場合も同様に実施すること。 調達仕様書において利用するクラウドサービスの要件については、次の記載例を参考にして定めてください。
バージョンアップと新規調達した場合とを比較・検討する 保有するソフトウェアと同一のソフトウェアを調達する場合には、バージョンアップ ※と新規調達の両方を検討し、より低額となる方法で提案可能な要件とします。なお、保有するソフトウェアの一覧（使用権の保有数等含む）は、閲覧資料一覧表に含め、応札希望者に提示してください。 ※ ライセンスが引き継ぎ可能であるか、現行事業者等に確認が必要です。 ・技術の検討に当たっては、国際標準規格や日本産業規格等のオープンな標準に基づく技術を選択すること。 ・調達から納入までの期間に技術の進展が見込まれる製品については、必要に応じて『**以上で最新のものを納入する』等の変更可能指示を入れておくこと。 ・特定製品に依存しないように留意すること。 ・特定製品を指定する必要がある場合には、その理由を明確に記載すること。 ・バージョンアップと新規調達でコストを比較し、より低額となる方法を選択すること。 ・現行情報システムと新たな情報システムを並行稼働する期間を設けるときには、新旧ライセンスを保有する費用が発生することがあるため、費用を事前に確認しておくこと。 L. テストに関する事項情報システムのテストには、ソフトウェアの設計に基づいて事業者が行うテストと、発注者及び情報システムの利用者の視点で行うテストが存在します。 テストに関する要件には、実施するテストの内容や方法、環境等を示します。 上記の点に留意し、情報システムの設計・開発等におけるテストについて、テストの種類、目的、内容等を記載します。
表5-30 テストに関する要件 なお、それぞれのテスト工程の中でも、様々な観点からテストを行います。その詳細については、実践ガイドブック「第７章 設計・開発」に記載しています。要件定義をする際には、ぜひ第７章の記載も読んでみてください。情報システムの特性により、テストの観点も大きく変わってきますので、それぞれの情報システムに見合ったテストを実施できるように要件を決めることが重要です。 テストに関する各作業を、誰が行うのか明確に記載する テストには、「テスト項目の作成」「テスト実施環境の準備」「テスト実施」「テスト結果の判定」等、様々な作業が存在します。それぞれの作業を誰がいつまでに行うのか明確にしてください。 ・テストを行う上で必要な関係者との連絡調整やその実施者、また、テスト環境の準備や費用負担等、誰が行うのか明確に記載すること。 過剰な要求は避ける テストは、数多く実施すれば品質が上がるというわけではありません。当該テストの目的を踏まえて、必要十分なテスト内容・量を調整してください。 ・事業者に対してテスト環境の過剰な要求は避けること。 ・必要以上に厳密なテスト等の過剰な要求は避けること。 M. 移行に関する事項移行には、データ移行、システム移行及び業務運用移行の３つの要素があります。大規模な情報システムにおいては、既存の情報システムから新しい情報システムにデータ移行とシステム移行（新情報システム稼働）を行い、一定期間並行稼働させた後に、業務運用移行を行う場合もあります。他方で、中小規模の情報システムにおいては、３要素全ての移行を休日に実施する場合もあります。 いずれの場合においても、業務の安定的な継続が最重要課題であるため、移行の各ステップにおいて状況を評価し、最悪の場合でも既存の情報システムへ切り戻せるような計画と、プロセスの準備を要求しておくことが必要です。 移行元である既存の情報システム、業務、運用について、対象を漏れなく抽出します。抽出に当たり、既存の運用・保守事業者の協力が不可欠となるため、事前に移行調査に必要となる既存事業者の要員確保について調整しておくことが重要です。移行対象の抽出後、移行に際する制限事項を整理します。例えば、月次の締め処理がある業務の場合、「月末の締め処理が完了するまでは移行不可」といった事項を明確にします。 ここでは、移行先への移行手段を詳細に記載する必要はありません。移行手段は設計・開発工程にて詳細化します。
表5-31 移行対象データ
表5-32 移行対象業務
表5-33 移行対象システム N. 引継ぎに関する事項情報システムの構築及びテストが完了し本番運用に移行する際、又は年度の節目等で事業者や要員が交代する場合、円滑な業務運営を維持するためには、あらかじめ引継ぎ項目を整理し、想定しておくことが重要です。 現在その作業を担当している事業者を「引継ぎ元」と定義し、その事業者が担当している作業を「引継ぎ内容」として明らかにします。基本的には事業者ごとに作業・成果物等を定義した契約が存在しているため、その内容を基に整理すると効率的です。
表5-34 引継ぎ事項 O. 教育に関する事項「教育」とは、情報システムの利用者が、その情報システムの機能を理解し、効率的に運用していくために必要となる、利用者に対する操作研修等を指します。特に官公庁においては人事異動に備え、教育資料や年に数回程の操作研修を実施する等の対応が必要です。 業務要件定義で作成した業務フロー図等を参考に、教育対象者の範囲を定めます。基本的には業務フロー図に表現されている全てのアクター（役割）が、教育対象者の候補となりますが、対象者の役割、所属する組織、場所等を考慮し、教育効果や費用を考慮して教育内容や用いる教材等について要件として示します。
表5-35 教育対象者の範囲、教育の方法 以下の表では、教育に用いる教材等についての要件を示します。
表5-36 教材の作成 P. 運用に関する事項情報システムの運用とは、実稼働させているアプリケーションの仕様や、ソフトウェア、ハードウェア等の構成変更を原則として行わずに、稼働状態をあらかじめ定めた品質基準に基づき維持することであり、今ある環境を正常な状態に保ち続ける活動とも言えます。詳細な内容は情報システムの運用設計において検討しますが、運用要件の内容によって、情報システムの機能要件及び非機能要件に求める事項が異なることもあるため、基本的な要件はここで定義しておきます。
情報システムをリリースした後、実際に運用業務に必要となる作業は、標準ガイドライン解説書「第３編第９章２．解説ア運用業務 表9-1」で示す事項になりますが、要件定義では、これら具体的な作業を設計するための方針を示します。 ・ 運転管理・監視等要件 ・ 運用サポート業務 ・ 業務運用支援 Q. 保守に関する事項「保守」と「改修」の違いが混同されてしまうケースがよくありますが、機能要件に変更を加えずにプログラム修正のみを行うことが「保守」、機能改善を目的としたプログラム修正作業が「改修」です。保守は「機能要件を変えずにプログラム修正する」という特徴があるため、現状の各種ドキュメントを正しく管理することが重要です。 アプリケーションやインフラの作業に着目しがちですが、ドキュメントの保守という観点を忘れないようにしてください。 保守作業には大別すると以下に示す４種類があります。
表5-37 保守作業の種類 なお、アプリケーションプログラム及びソフトウェア製品の保守要件については、表5－37を踏まえ、訂正に係る保守（是正保守、予防保守）と改良に係る保守（適応保守、完全化保守）を区別して検討します。 ・ アプリケーションプログラムの保守要件 ・ ハードウェアの保守要件 ・ ソフトウェア製品の保守要件 ・ データの保守要件 ・ 保守実績の評価と改善 ２ システム方式を決定する【標準ガイドライン関連箇所：第３編第５章第２節1)エ】 機能要件と非機能要件を定義することで、情報システムの全体像が明らかになっていきますが、それを実現するためのハードウェア・ソフトウェアや機能等の構成は必ずしも一つではありません。クラウドサービスを活用した案や独自にハードウェアから用意する案、また、サーバと配置する機能の組合せ等、複数の構成案があります。これらの比較検討を行い、事業者からの提案・見積りを踏まえ、最適な方式を選択する必要があります。 このため、システム方式として選択可能な方式を、複数案取りまとめます。伝達のしやすさを考慮し、図表形式で取りまとめることも有効です。 また、システム方式によって、要件を実現するための難易度が異なることがあるため、要件の優先順位も併せて検討します。 Step.7 要件定義終了後の対応要件定義に係る作業が一通り終わり、ほっとするところですが、実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。 ここでは、それら作業とポイントについて解説します。 １ 定義内容を関係者に共有する【標準ガイドライン関連箇所：第３編第５章第２節2)】 要件定義書が出来上がることで、関係者にとって整備しようとしている情報システムの内容がより具体的に理解しやすくなり、これまでは意識していなかった考慮点や抜け漏れが発見できる可能性があります。 そのため、作成した要件定義書を関係者に確認してもらい、その結果明らかになった変更要望や新たな課題は、ＰＪＭＯ内で対応方針を検討し、業務要件に反映した上で、再度関係者と共有してください。内容によっては機能要件のみが変更対象となるものもありますが、機能要件の前提や根拠となる業務要件を必ず確認することが重要です。加えて、要件定義書完成時点で、当初の計画に対して工期や費用がどう変化したかについて評価し、プロジェクト計画に反映していくことが望まれます。評価の仕方や内容に不安がある場合は、ＰＭＯや府省ＣＩＯ補佐官に支援を求めてください。 これにより、業務要件から機能・非機能要件を定義する過程で発生した変更点の確認や、要件を「見える化」した結果、「イメージしていた内容と違う」といった認識齟齬が発見でき、関係者一同が合意した要件定義書として確定できます。 また、役割が異なる複数の関係者が確認することにより、曖昧な内容や難解な箇所を修正でき、後続工程で事業者を含む第三者が理解しやすい内容になります。 ２ プロジェクト計画書に反映して最新化する【標準ガイドライン関連箇所：第３編第５章第３節】 これで要件定義書が確定しました。要件定義のゴールは間近です。 要件定義書を作成する過程で、プロジェクト計画書に記載されていた内容とのかい離が発生した項目があるのではないでしょうか。 要件定義に係る作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。要件定義を開始した段階のプロジェクト計画書は、サービス・業務企画を受け、一通りの項目が詳細化されている状態です。本章の作業結果により変更が必要な箇所を確認し、更新してください。今回実施した内容を基にプロジェクト計画書を最新化することにより、次の調達や設計・開発において、今回の作業を基に修正したプロジェクト計画書の内容に沿って作業を進められるため、準備作業が減ります。 また、人事異動が発生しても、最新のプロジェクト計画書を整備しておけば、プロジェクトの全体像からこの時点で詳細化された情報まで正確な情報で引継ぎができます。 |