Step.6 非機能要件の定義

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

ところで、非機能とはなんでしょう？機能は想像がつきやすいと思いますが、非機能となるとどんなことを決めたらよいかわかりづらいですよね。

情報システムの専門家ではない職員のみで、多岐にわたる非機能要件を全て定義することは、通常困難です。技術的な厳密な定義を説明してもさらにわかりづらくなると思いますので、発注者側にとってわかりやすい具体例を示しながら非機能を説明しつつ、その要件として何を定義しなければならないかを解説していきます。

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

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

非機能要件として定義しないといけない内容は次に挙げる17個の内容（A～Qまで）です。

機能要件の場合は、内容の一部を定義せず、調達時の事業者の提案に委ねることもありますが、非機能要件の場合は基本的に全ての項目を定義します。もちろん、情報システムやプロジェクトの特性によって、定義すべき内容の量は異なります。

項目は細分化されていますが、実は経験的に理解している内容が多くありますので、それらを見ていきましょう。

ユーザビリティ及びアクセシビリティに関する事項

情報システムは、提供するサービス・業務の利用者が、使いやすいと実感することにより利用が促進され、使いやすさは利用者の満足度や業務効率の向上に大きく寄与します。本項では、「使いやすさ」をユーザビリティとアクセシビリティという２つの軸で明らかにします。

ユーザビリティとは、利用者がサービス・業務を利用して実施したいことを、ミスなく効率的に行うために必要となる事項であり、アクセシビリティは、目的の情報へのたどり着きやすさを指します。どちらも利用者の年齢、身体的制約、利用環境等の違いによる配慮が必要です。

• 表5-10

情報システムの利用者の種類、特性

次に整理した特性をグループ化して、ユーザビリティ、アクセシビリティの分類を作成します。例えば画面の構成や操作のしやすさ等を分類として定義し、次に分類ごとにどのような使いやすさを実現したいかをユーザビリティ要件として示します。

• 注記

「ウェブアクセシビリティ導入ガイドブック」

https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook/

また、当該情報システムの特性に鑑みて日本産業規格（JIS）への準拠や多言語対応等の要件を整理し、情報へのアクセスの容易さをアクセシビリティ要件として示します。アクセシビリティ要件の検討に当たっては、「ウェブアクセシビリティ導入ガイドブック」が参考になります。

• 表5-11

ユーザビリティ要件

• 表5-12

アクセシビリティ要件

システム方式に関する事項

「システム方式」では、定義された業務要件のうち、情報システムが処理・実行する範囲について、情報システムとして動作するために必要となる「道具」の具体的な実現方法を明確にします。

• 表5-13

情報システムの構成に関する全体の方針

• 事例5-4

他者提供のサービスを利用して開発する場合の注意点

• 注記

追加で発生する作業の例には、次のようなものがある。 クラウドサービス上で個別に機能を開発する場合、クラウドサービスのアップデートと個別開発機能の機能改修のサイクルが異なることが想定される。

クラウドサービスのアップデートは、左記の事例のように個別開発機能に影響し、障害の原因となり得る。

そのため、ＰＪＭＯがタイミングをコントロールできないクラウドサービスのアップデートが実施される前提で、情報システムの規模や構成に応じて検証環境の準備が必要であり、それを踏まえて個別開発機能の改修を計画する。

ツール等を利用し、システムライフサイクルコストを削減する

アプリケーションの開発ツールは日々進歩しています。例えばノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、コストの削減等が見込める場合等には、積極的に採用を検討してください。

• ＲＦＩ等を通じて事業者から得た情報を踏まえ、実現性が十分であること及びコスト効率を高めることを基本として方針を検討する。また、必要に応じて新技術の適用可能性も検討する。

• システムアーキテクチャ及びシステム基盤の方針の検討は、クラウドサービスの活用も踏まえて行う。

• ソフトウェア製品の選定においては、機能要件や非機能要件から適切なソフトウェア製品を選定できるよう、留意する。

規模に関する事項

「規模」とは、情報システムを使うユーザの数や取り扱う情報量を指します。利用者が多ければ単位時間当たりで多くのリクエストを処理できる能力が必要となりますし、情報量が多ければ、より大容量のデータベース等が必要になります。要件定義では「利用者は最大100人、平日は常時80人、土日は基本的に休みのため10人未満」といった要件を定量的に示します。

次に示す各表では、機器やデータ等の量について整理し、想定可能な最大値を要件として示します。

• 表5-14

機器数及び設置場所

• 表5-15

データ量

• 表5-16

処理件数

• 表5-17

利用者数

過度の規模要件は、過度の情報システム投資を招く

「大は小を兼ねる」と言いますが、過大は無駄を招きます。「十分な」といった曖昧な表現を避け、「○○人」「××件」といった定量的な表現とすることで、適切な規模要件を設定してください。

• 情報システムの規模は、性能や信頼性に関する要件を検討する際の前提条件であり、機器の仕様や配置等の設計、調達コストに影響を与える。

• 過度の規模要件を規定することは、過度の情報システム投資を招くことになる。

設置場所を開示するべきでない場合の記載方法

設置場所が不特定多数の者に知られることが情報セキュリティ上問題あるサーバ等の機器については、「○○県内」「東京都23区内」といった記載にとどめ、詳細については契約締結後、受注者のみに開示するものとし、設置場所が特定できないように配慮してください。

• 建物やフロア等、ネットワーク接続要件を考慮して、設置場所を記載する。例）厚生労働省X階XX室、XX局XX室

• 情報セキュリティの観点からみて、設置場所を明示する場合、設置場所に関する情報は広く一般に公開するものではない。このため、この情報については、非開示覚書(NDA)を交わした上で、閲覧等によって開示することを考慮する。

性能に関する事項

「性能」とは、情報システムの能力を指します。能力を測る指標には、応答性能やスループット（処理性能）等があります。ネットショッピングで例えると、商品を検索し検索結果のリストが表示され、特定の商品を選択すると詳細情報が表示される、という一連の流れが一般的ですが、検索ボタンや選択ボタンを押してから、次の画面が表示されるまでの時間が応答性能です。スループットは、一度にどれだけの量を処理できるかという性能で、通常時でも大量に注文が発生するバーゲンセール開催中でも、定義した応答性能が担保されるということを表します。経験があるかもしれませんが、ネットショッピング中に検索結果が返ってこないと、購買する意欲が下がってしまいます。性能はサービス・業務の質に大きな影響を与えます。また、スループットを担保するためには、ハードウェアや回線増強等の投資が必要です。

性能に関する事項は、費用と性能のバランスをとって定義しましょう。

• 表5-18

応答時間

• 表5-19

スループット

多機能化で情報システムの性能が大きく劣化しないようにする

ユーザ要望や企画の実現、運用保守コストを削減するために、複数の画面や帳票の統合を検討することがありますが、統合することにより、次に示すようなデメリットが発生することもあります。

• １つの画面や帳票で取り扱う項目や機能が増えるため、画面の表示や帳票出力までの処理に時間がかかるようになる。

• システム処理そのものに加え、途中で発生したエラーのリカバリー処理も統合することにより複雑化するため、テスト工数の増大も含め、かえって保守コストが増加することもある。

このような事態を避けるために、画面標準等で、１つの画面や帳票に盛り込む情報量の基準の設定や、現在画面や帳票が分割されている理由を、業務面だけではなくシステム面からも確認しておくことが重要です。

現場の職員は１つの画面や帳票で多岐に渡る業務を行いたいと要望しがちですが、視認性や操作性の観点から、ストレスを感じることなくスムーズに使える範囲内で、適切に分割する方が有効です。

• 事例5-5

  非機能要件が機能要件に影響することもある

想定値ではなく実測値等から真に必要とされる性能を指定する

性能を検討していくと、つい安全な方向に結論を倒しがちです。性能の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意してください。

• 要求事項の記載は、できるだけ定量的な表現となるようにすること。

• 過度な性能要件を設定して調達コストを押し上げることのないよう性能要件の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意すること。

• 常時・定期のモニタリングが必要な場合には、個別部分の性能、トランザクション量等について明示し、組み込みの必要性を指定すること。

• 事例5-6

概念検証により性能要件の実現可能性を確認する

信頼性に関する事項

「信頼性」とは、情報システムが持つ故障への耐性の度合いのことを指します。一般的には平均故障間隔（分又は時間）で評価します。平均故障間隔の値が小さければ小さいほど信頼性は高いと言えます。

情報システムを、構成する要素（サブシステムやネットワーク等）に分解し、情報システム全体での年間稼働率を踏まえて、各要素の信頼性に係る指標や目標値を要件として示します。

• 参考5-4

最適なシステム構成

• 表5-20

可用性要件

• 注記

ＭＴＢＦとは、システムが故障するまでの平均間隔のこと。

ＭＴＢＦはMean Time Between Failuresの略。

• 注記

ＭＴTRとは、システムを復旧・修理するまでにかかる平均時間のこと。

ＭＴTRはMean Time To Repairの略。

拡張性に関する事項

「拡張性」とは、情報システムの運用開始後に性能又は機能を向上させる場合に、容易に対応できる度合いを指します。性能については、将来の利用者の拡大やデータ量の増加に備えて、情報システムの処理性能を維持するためのハードウェア、ソフトウェアの対処方針を、要件として定量的に示します。機能については、将来の制度改正や技術の変化等に備えて、容易に改修を行うための設計指針やアプリケーションの改修方針を示します。想定する拡張が必要となるケースを、提供するサービスや業務と併せて具体的に記載することが重要です。「利用者数がX倍になる」だけではなく、「○○サービスを利用する部署がY倍になるため」といった、拡張の背景を記載することにより、設計時に考慮しやすくなります。

• 参考5-5

拡張性要件の記載例

• 注記

  IaCとは、「Infrastructure As Code」の略称。従来は手作業で行っていたOS、ミドルウェア等の導入や設定をコードで表現し、そのコードを実行することで自動的にインフラを構築する技術のこと。

• 注記

  CI/CDとは、「Continuous Integration／Continuous Delivery」の略称。アプリケーションを改修する際に発生するビルド、テスト、デプロイなどの作業を自動化することなどによって、継続的に（頻繁に）アプリケーションの改善を可能とする手法。

• 注記

ＢＲＭＳにおける、業務プロセス内の条件および処理の例として、勤怠管理システムにおける＜「18時15分以降の勤務時間」（条件）は「残業時間とする」（処理）＞というルールが挙げられる。組織内で17時45分以降の勤務を残業時間として扱うようにルールが変更された場合は、表などに示された条件を変更することで対応できる。

• 参考5-6

変化に強い情報システムの構築

上位互換性に関する事項

「上位互換性」とは、主にソフトウェア製品において、新しいバージョンの製品で古いバージョンの製品が利用できることを指します。代表的な製品は上位互換性がありますが、バージョンアップに伴い、帳票作成ツールの場合レイアウトが崩れたり、ブラウザの場合画面のレイアウトや特定のボタンが動作しなくなったりといった、一部の機能に限り上位互換性がないこともあります。

当該情報システムを構成するソフトウェア製品において、将来予想されるバージョンアップ時の対応可能性について、定義時点において明確にできる範囲内で、具体的な対象とバージョンアップ時の対処方針を要件定義書に記載します。

各製品のバージョンアップポリシーを踏まえて、コストを検討する

機能追加等のバージョンアップが頻繁に行われる製品を利用する場合、バージョンアップ後のテストに係るコストが膨大なものとなり、費用対効果が著しく悪化する可能性が高くなります。

したがって、製品の選定に当たってはバージョンアップ後のテストの簡略化等を検討するとともに、費用対効果が見込める場合には、OS・ミドルウェア等の乗換についても積極的に検討してください。

• バージョンアップは将来の不確定要素であることから、上位互換性を過度に要求する場合、事業者が応札に対して慎重になる可能性や、リスクを見込んだ高額な調達コストとなる可能性があることに留意する。

• 参考5-7

上位互換性要件の記載例

中立性に関する事項

「中立性」とは、情報システムを構成する要素が、特定の技術や製品に特化しないことを指します。特定の技術や製品に特化した構成とすると、ベンダーロックイン状態となってしまう可能性があるため、中立性に配慮する必要があります。

例えば、新規に情報システムを構築する際に、ある事業者が開発・販売している製品を利用しなければ運用・保守ができない構成にしたとします。その後、運用・保守業務を一般競争入札で調達しようとしても他の事業者ではその製品を入手できないなどの理由により、その製品を導入した事業者による一者応札となってしまいます。このような状態になることを防ぐために、特定の事業者の技術に依存せず、多くの事業者が扱える製品を採用するなど、中立性への配慮が必要です。

また、特殊なツールを利用する場合、将来的に他の製品への乗り換えが困難にならないよう、中立性の観点から問題のないツールであることを要件として示します。

なお、情報システムの調達において、ベンダーロックインを避けることを重視する場合には、中立性に関する事項を要件定義書に示すだけでなく、総合評価落札方式における加点項目とし、配点を高くすることも選択肢の一つです。

• 参考5-8

オープンな標準的技術又は製品の採用を求める場合の記載例

• 参考5-9

事業者交代時の対応を求める場合の記載例

継続性に関する事項

「継続性」では、当該情報システムを構成する要素（サブシステム、サービス等）に分解し、情報システム全体での目標復旧時間を踏まえて、各要素の継続性に係る指標や目標値を要件として示します。

• 表5-21

継続性要件

• 注記

オンプレミスとは、発注者が自ら情報システムに必要な機器（サーバ、ネットワーク、ソフトウェア製品等）を調達し、情報システムの運用を行うこと。

クラウドサービスとオンプレミスは継続性の確保方法が異なる

例えば、クラウドサービスを利用する場合には、オンプレミスのようにテープ等の媒体で別途保管する必要はなく、クラウドサービス提供者が提供するバックアップサービスを利用すればよいと考えられます。ただし、バックアップサービスには様々な種類が存在することに鑑み、選択する手法が妥当なものであることを確認できるようにすることが重要です。

• 参考5-10

継続性に関する事項の記載例

• 事例5-7

クラウドサービスのハードディスク障害によるデータ消失の責任

• 事例5-8

  クラウドサービスの外へのバックアップの検討

• 参考5-11

  業務継続の分かれ目

情報セキュリティに関する事項

「情報セキュリティ」とは、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。機密性とは、ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保することです。完全性とは、情報が破壊、改ざん又は消去されていない状態を確保することです。可用性とは、情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することです。

ここでは、自組織において定められた情報セキュリティポリシーを遵守するために必要な情報セキュリティ対策の内容について、具体的に記載してください。

個々の業務について記載するのではなく、業務分類等、グループ単位で記載します。また、ユーザ認証において、求められる要件（例えば、社内の認証サーバと連携できること等）があるときは、それらも記載します。

• 表5-22

情報セキュリティ対策要件

当該情報システムに実装する機能や画面に対して、利用者の権限に応じた管理レベルを記載します。

• 表5-23

権限要件

想定されるリスクの概要と対策について記載します。

• 表5-24

リスク一覧

定義に当たっては、自府省の情報セキュリティポリシーを参照するとともに、必要に応じて「政府機関のサイバーセキュリティ対策のための統一基準群」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（平成23年４月28日内閣官房情報セキュリティセンター）等を参照し、必要な対策を漏れなく記載しましょう。

当該情報システムに求めるセキュリティ要件については、次に示す「最低限記述すべき情報セキュリティ対策要件」を参考にして、表5-22で示した様式を参考に記載してください。

• 5-12

最低限記述すべき情報セキュリティ対策要件

リスクの概要と対策を定義する

• リスクが多様化しているので、なるべく多くのリスクの洗い出しを行うこと。

• 当該情報システムの格付けに見合った情報セキュリティ対策を行うこと。

• 公開されるWebサイト等のドメインについては、利用者がわかりやい政府サイトとするとともに、政府サイトに似せたサイト上で個人情報を収集する等といったフィッシング等のセキュリティ事故が起こりにくい環境を実現すること。

第三者による脆弱性検査を実施する

当該情報システムに対して修正を行う場合、その改修が影響する範囲を対象として第三者による脆弱性検査を実施します。

第三者による脆弱性検査を実施するか否かの判断に当たっては、下表の観点を考慮し、案件ごとに判断してください。なお、第三者による脆弱性検査を実施しない場合には、実施しない理由を明確にします。また、第三者による脆弱性検査は、当該調達に基づく改修が影響する範囲を対象とし、情報システムとしての脆弱性がないことを検査するものであり、実装されたセキュリティ機能の検査を行うものではないことに留意してください。

• 表5-25

脆弱性検査の観点

情報システム稼働環境に関する事項

「情報システム稼働環境」とは、当該情報システムに係る、クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等を明らかにすることを指します。稼働環境には、運用、保守、研修、検証等に必要な環境も含めます。

「システム方式」は構成要素ごとの方針を示すものですが、情報システム稼働環境は、もう一段階分解し、構成要素の内容を具体的に示します。

• 図5-9

ハードウェア構成図

① ハードウェアの種類を示す語句

　 例：サーバ、クライアント端末、ネットワーク機器等

② ハードウェアの台数を示す語句

　 例：１台、１個、１式等

③ 各ハードウェアの設置場所を示す語句

　 例：本庁、出先機関、データセンター、サービス提供者等

④ ハードウェア間のネットワーク接続形態を示す語句

　 例：ＬＡＮ、インターネット、専用線等

• 表5-26

ハードウェア構成

• 表5-27

ソフトウェア構成

• 表5-28

ネットワーク構成

• 表5-29

施設・設備要件

クラウドサービスを利用する場合は、サービスに関する要件を記載します。クラウドサービスの要件については、要件定義書標準テンプレートを参照してください。オンプレミスで構築する場合は、ハードウェア構成、ソフトウェア構成、ネットワーク構成、施設・設備等の要件の定義に加えて、情報システムのハードウェア構成図も記載します。なお、記載に当たっては、仮想化による物理的な機器の削減についても考慮するとともに、将来的な拡張予定についても、その範囲を識別できるよう留意します。

レンタル/リース/買取の特徴を理解して、選択する

以前は高額なハードウェア製品が多く存在していましたが、昨今は製品価格が下落傾向にあるため、リースよりも買取の方が最終的には安価になることもあります。プロジェクトの特性に併せて、最適な方式を検討しましょう。

なお、事業者より見積りを取得する際には、「一式」ではなく、製品ごとの本体価格を提示するよう依頼し、機器単位で比較ができるよう留意してください。

• 表5-30

レンタル・リース・買取の比較表

クラウドサービス/オンプレミスの特徴を理解して選択する

稼働環境に係る要件を記載する場合、クラウドサービスとオンプレミスでは記載内容が異なることを理解して進めてください。

• 情報システムの稼働環境は、システム方式と同様に情報システム設計の基本的な前提条件であるため、定義時点において明確にできる範囲内で要件定義書に記載する。なお、将来的な拡張性要件を記載する場合、今回の調達対象を明確にするように注意すること。

• クラウドサービスを利用する場合、サービスによって可用性に係るSLAが異なること、使用状況に応じてリソースを変動させることができること等から、厳密に構成を確定せず、想定構成を参考として記載するに留め、実際構成は適宜受注者に提案することを求める形とすること。また、運用・保守、移行、刷新等既存の情報システムがある場合も同様に実施すること。

バージョンアップと新規調達した場合とを比較・検討する

保有するソフトウェアと同一のソフトウェアを調達する場合には、バージョンアップ※と新規調達の両方を検討し、より低額となる方法で提案可能な要件とします。なお、保有するソフトウェアの一覧（使用権の保有数等含む）は、閲覧資料一覧表に含め、応札希望者に提示してください。

※ ライセンスが引継ぎ可能であるか、現行事業者等に確認が必要です。

• 技術の検討に当たっては、国際標準規格や日本産業規格等のオープンな標準に基づく技術を選択すること。

• 調達から納入までの期間に技術の進展が見込まれる製品については、必要に応じて『**以上で最新のものを納入する』等の変更可能指示を入れておくこと。

• 特定製品に依存しないように留意すること。

• 特定製品を指定する必要がある場合には、その理由を明確に記載すること。

• バージョンアップと新規調達でコストを比較し、より低額となる方法を選択すること。

• 現行情報システムと新たな情報システムを並行稼働する期間を設けるときには、新旧ライセンスを保有する費用が発生することがあるため、費用を事前に確認しておくこと。

オープンソースソフトウェアの特徴を理解して採用する

オープンソースソフトウェア（ＯＳＳ）には、先進的な機能が利用できるメリットがある一方で、不具合があってもサポートを受けられないなどのデメリットもあります。メリットとデメリットの両方を正しく理解した上で、プロジェクトの特性に合わせて、ＯＳＳの採用を検討しましょう。

• 表5-31

  ＯＳＳ利用のメリットとデメリット

ＯＳＳではあるものの、製品自体が有償化されていたり、ＯＳＳの入手は無償であってもサポートなどが有償化されていたりする場合があるため、ＯＳＳの採用を検討する際にコストを確認することが重要です。また、以下の理由で、管理コストが割高になる可能性があることに注意が必要です。

• ＯＳＳはサポート期間が一般的に短いものが多いため、バージョンアップなどの対応が増える場合があります。

• 注記

  ＥＯＬとは、「End Of Life」の略称。ソフトウェア製品などの使用期限のこと。サポートが終了し、修正・更新プログラムの提供が行われなくなる。

製品に複数のＯＳＳが包含されている場合、包含しているＯＳＳのサポート体制やサポート期間を含めて管理する必要があります。また、ＥＯＬがＯＳＳごとに異なるため、ＥＯＬの管理や脆弱性などの確認の実施が必要です。

ＯＳＳのライセンスには複数の種類があります。例えば、最も自由度が高い例としてApacheライセンスが挙げられます。これは、使用、複製、改変、再配布、ライセンス継承等について制限がなく、「Apacheライセンスを使用していること」を明記することだけが定められています。逆に、ＧＰＬ（General Public License）の場合は、以下４つのルールが定められています。

1. ソフトウェアは無償で利用可能

2. 著作権は表示しなくてはいけない

3. 複製、改変、再配布、販売は制限なし

4. 再配布する場合は、ＧＰＬライセンスにしなくてはいけない

ＧＰＬライセンスのソフトウェアをプロジェクトにあわせて改変して利用する場合、当該ソフトウェアはＧＰＬライセンスのルールが維持されることになり、複製や再配布を認めなくてはならなくなります。このようなＯＳＳのライセンスにおいて特に確認すべきポイントとこれらのポイントが代表的なＯＳＳにおいてどのように定められているかを以下に示します。

ソフトウェアの利用は無償でも、利用者ごとのカスタマイズが必要なライブラリの改変は有償である場合やサポートが高額である場合があるため、ＯＳＳを採用する際は、ライセンスの内容を詳細に確認することが重要です。

• 表5-32

  ＯＳＳのライセンスにおいて確認すべきポイント

• 注記

  派生物とは、あるプログラムの一部／全部を、改変／引用して作成したプログラムを指す。それ自体を改変した場合だけでなく、ライブラリなど他ソフトウェアと組み合わせた場合も派生とみなされる。

• 注記

  GPLは、改変したプログラムの配布を前提としており、サーバ上で動作するプログラムをネットワーク経由で利用する場合には、ソースコードの開示が求められない。

  一方、AGPL（GNU Affero General Public License）では、ネットワーク経由で利用する場合に、利用者にソースコードのダウンロードを可能とすることが定められている点が異なっている。

• 表5-33

  代表的なＯＳＳの比較

1. GPL（ライセンス条文 英文）

https://opensource.org/licenses/GPL-2.0　

https://opensource.org/licenses/GPL-3.0　

2. AGPL（ライセンス条文 英文）

https://opensource.org/licenses/AGPL-3.0　

3. LGPL（ライセンス条文 英文）

https://opensource.org/licenses/LGPL-2.1　

https://opensource.org/licenses/LGPL-3.0　

4. Apache（ライセンス条文 英文）

https://opensource.org/licenses/Apache-2.0　

5. MIT（ライセンス条文 英文）

https://opensource.org/licenses/MIT　

データマネジメントに関する事項

情報システムは管理するデータを登録、処理、記録するものであり、保有するデータの品質確保はサービス・業務を適切に運営するための生命線です。データ品質を保つためには、情報システムのライフサイクル全体を通してデータの管理状態を定期的に把握し、不具合が発見されれば直ちに原因を特定して対策を行うことが重要です。

また、広く国民に公開するデータに関しては、設計時点からデータの標準化（相互運用性）を意識し、利用しやすい形式（Web-APIやCSV形式など機械判読性の高い形式）にする等の工夫が必要です。

こうしたデータの重要性に着目し、データを情報資産として捉え、その利活用戦略からシステム実装に向けた設計や開発、さらに稼働後の運用、利用に至るまでのデータ品質の維持・向上をベースとした継続的、組織的な活動を「データマネジメント」と呼び、以下のような内容を検討・定義します。

• 表5-34

データマネジメントにおける定義内容

• 参考5-13

データマネジメント活動が防ぐデータ関連のトラブル

テストに関する事項

情報システムのテストには、ソフトウェアの設計に基づいて事業者が行うテストと、発注者及び情報システムの利用者の視点で行うテストが存在します。

テストに関する要件には、実施するテストの内容や方法、環境等を示します。

上記の点に留意し、情報システムの設計・開発等におけるテストについて、テストの種類、目的、内容等を記載します。

• 表5-35

テストに関する要件

1. 発注者もテスト計画を確認した上で、事業者に実施状況の報告を求め、報告書に記載されている実施結果に不足、誤り等が発生している場合は、課題等を整理し、指摘又は指導を行います。特に総合テストにおいては、発注者がテストシナリオやテスト評価方法の妥当性を確認し、過不足を指摘することで抜け漏れのないテストになるように関与します。

なお、それぞれのテスト工程の中でも、様々な観点からテストを行います。情報システムの特性により、テストの観点も大きく変わってきますので、それぞれの情報システムに見合ったテストを実施できるように要件を決めることが重要です。テストの観点のほか、各テスト工程におけるテストスケジュール、テスト環境、テストシナリオ等の情報は、事前にテスト計画書やテスト実施要領にまとめます。詳細については、実践ガイドブック「第７章Step.3-3 テストの計画を立てる」に記載しています。要件定義をする際には、ぜひ第７章の記載も読んでみてください。

テストに関する各作業を、誰が行うのか明確に記載する

テストには、「テスト項目の作成」「テスト実施環境の準備」「テスト実施」「テスト結果の判定」等、様々な作業が存在します。それぞれの作業を誰がいつまでに行うのか明確にしてください。

• テストを行う上で必要な関係者との連絡調整やその実施者、また、テスト環境の準備や費用負担等、誰が行うのか明確に記載すること。

過剰な要求は避ける

テストは、数多く実施すれば品質が上がるというわけではありません。当該テストの目的を踏まえて、必要十分なテスト内容・量を調整してください。

• 事業者に対してテスト環境の過剰な要求は避けること。

• 必要以上に厳密なテスト等の過剰な要求は避けること。

移行に関する事項

移行には、データ移行、システム移行及び業務運用移行の３つの要素があります。大規模な情報システムにおいては、既存の情報システムから新しい情報システムにデータ移行とシステム移行（新情報システム稼働）を行い、一定期間並行稼働させた後に、業務運用移行を行う場合もあります。他方で、中小規模の情報システムにおいては、３要素全ての移行を休日に実施する場合もあります。

いずれの場合においても、業務の安定的な継続が最重要課題であるため、移行の各ステップにおいて状況を評価し、最悪の場合でも既存の情報システムへ切り戻せるような計画と、プロセスの準備を要求しておくことが必要です。

移行元である既存の情報システム、業務、運用について、対象を漏れなく抽出します。抽出に当たり、既存の運用・保守事業者の協力が不可欠となるため、事前に移行調査に必要となる既存事業者の要員確保について調整しておくことが重要です。移行対象の抽出後、移行に際する制限事項を整理します。例えば、月次の締め処理がある業務の場合、「月末の締め処理が完了するまでは移行不可」といった事項を明確にします。

ここでは、移行先への移行手段を詳細に記載する必要はありません。移行手段は設計・開発工程にて詳細化します。

• 表5-36

移行対象データ

• 表5-37

移行対象業務

• 表5-38

移行対象システム

引継ぎに関する事項

情報システムの構築及びテストが完了し本番運用に移行する際、又は年度の節目等で事業者や要員が交代する場合、円滑な業務運営を維持するためには、あらかじめ引継ぎ項目を整理し、想定しておくことが重要です。

現在その作業を担当している事業者を「引継ぎ元」と定義し、その事業者が担当している作業を「引継ぎ内容」として明らかにします。基本的には事業者ごとに作業・成果物等を定義した契約が存在しているため、その内容を基に整理すると効率的です。

引継ぎ期間は 1 か月程度を設定するのが一般的ですが、十分ではないケースが多くみられます。引継ぎ期間が十分でない場合には、他の事業者が参入できなかったり、その後の業務運営に支障が生じたりするおそれがあるため、十分な期間を確保することが重要です。

また、事業者が情報システムを構成するソフトウェアのライセンスを保有している場合、事業者が交代する際にソフトウェアライセンスを引継ぎ先の事業者へ譲渡することが必要になります。ソフトウェアライセンスの契約条件によっては譲渡に制約が生じ、引継ぎ先の事業者による運用・保守作業に支障が生じる場合があります。そのため、譲渡可能なソフトウェアライセンスを調達する旨とソフトウェアライセンスの譲渡に関する制約がある場合はその情報を開示する旨を、要件定義書に記載しましょう。落札後 、ソフトウェアライセンスの契約条件を発注者・事業者間で合意した上で、ソフトウェアライセンスを調達しましょう。

事業者間の引継ぎにおける工夫は、「第7章 Step6-2 事例：異なる事業者間で引継ぎをスムーズに行う工夫」をご参照ください。

• 注記

引継ぎ計画書とは、情報システムの引継ぎに係る引継ぎ対象、引継ぎ体制、引継ぎ内容、引継ぎ方法、引継ぎスケジュール、理解度確認方法、完了条件等を記載した受託者が作成する資料のこと

• 表5-39

引継ぎ事項

教育に関する事項

「教育」とは、情報システムの利用者が、その情報システムの機能を理解し、効率的に運用していくために必要となる、利用者に対する操作研修等を指します。特に官公庁においては人事異動に備え、教育資料や年に数回程の操作研修を実施する等の対応が必要です。

業務要件定義で作成した業務フロー図等を参考に、教育対象者の範囲を定めます。基本的には業務フロー図に表現されている全てのアクター（役割）が、教育対象者の候補となりますが、対象者の役割、所属する組織、場所等を考慮し、教育効果や費用を考慮して教育内容や用いる教材等について要件として示します。

• 表5-40

教育対象者の範囲、教育の方法

以下の表では、教育に用いる教材等についての要件を示します。

• 表5-41

教材の作成

運用に関する事項

情報システムの運用とは、実稼働させているアプリケーションの仕様や、ソフトウェア、ハードウェア等の構成変更を原則として行わずに、稼働状態をあらかじめ定めた品質基準に基づき維持することであり、今ある環境を正常な状態に保ち続ける活動とも言えます。詳細な内容は情報システムの運用設計において検討しますが、運用要件の内容によって、情報システムの機能要件及び非機能要件に求める事項が異なることもあるため、基本的な要件はここで定義しておきます。

• 参考5-14

運用要件（バックアップ）の記載例

情報システムをリリースした後、実際に運用業務に必要となる作業は、標準ガイドライン解説書「第３編第９章２．解説（１）ア運用業務　表9-1」で示す事項になりますが、要件定義では、これら具体的な作業を設計するための方針を示します。

• *運転管理・監視等要件* コンピュータで行う処理と運用管理者等で行う処理の切り分け、情報システムの運用を行う時間、内容、手法、連絡等について記載します。記載に当たっては、保守要件との責任分界を考慮し、作業の抜け漏れ、重複等がないように定義する必要があります。特に、情報システムの障害発生箇所の切り分け、発生原因の追究と解消について、アプリケーションプログラム、ソフトウェア製品、ハードウェアそれぞれの保守事業者と連携し、単体では発生しない障害についても監視、切り分け、復旧が可能となるよう留意してください。 また、障害発生を検知した際に、障害対策の原因究明を行うために十分な情報をログ等として確実に記録したり、情報システムを継続的に運用する中で性能劣化が起きないよう定期的な測定と改善活動を行ったりするように留意してください。

• *運用サポート業務* 業務の実施に必要な体制以外に、情報システム利用者からの問合せ対応や操作研修等の運用サポート体制が必要となる場合は、その内容を記載します。

• *業務運用支援* 情報システムの稼働に当たり、業務実施部門が行う業務の運用支援作業について記載します。

保守に関する事項

「保守」と「改修」の違いが混同されてしまうケースがよくありますが、機能要件に変更を加えずにプログラム修正のみを行うことが「保守」、機能改善を目的としたプログラム修正作業が「改修」です。保守は「機能要件を変えずにプログラム修正する」という特徴があるため、現状の各種ドキュメントを正しく管理することが重要です。

アプリケーションやインフラの作業に着目しがちですが、ドキュメントの保守という観点を忘れないようにしてください。

保守作業には大別すると以下に示す４種類があります。

• 表5-42

保守作業の種類

なお、アプリケーションプログラム及びソフトウェア製品の保守要件については、表5－42を踏まえ、訂正に係る保守（是正保守、予防保守）と改良に係る保守（適応保守、完全化保守）を区別して検討します。

• *アプリケーションプログラムの保守要件* 情報セキュリティに関する脆弱性の修正や不具合等の確認及び修正、小規模な改修等の対応範囲や条件を記載します。記載に当たっては、情報システムの機能改修に相当する作業を含まないように留意してください。

• *ハードウェアの保守要件* 不具合の修理等の対応範囲や条件を記載します。

• *ソフトウェア製品の保守要件* 情報セキュリティに関する脆弱性の修正や不具合への対応（パッチの提供）、小規模な改善等を目的とするリビジョンアップや大幅な改修を伴うバージョンアップ等の対応範囲や条件を記載します。 ソフトウェアの修正・不具合への対応や機能追加等のバージョンアップについては、業務や他の情報システムとの連携に影響を及ぼす場合もあるため、適用前に必ず影響を調査し、総合的に検討を行った上で実施の是非を判断する必要があります。例えば、脆弱性や不具合に対するパッチを適用する場合は、適用した場合の業務への影響や適用しなかった場合のリスク評価等を実施した上で、パッチ適用の是非を判断します。また、新たな機能の追加が行われる場合も、追加した場合と追加しなかった場合それぞれのメリット・デメリットを比較するなどした上で、追加の是非を判断する必要があります。 なお、クラウドサービスのバージョンアップの方法はサービスごとに異なり、自動で適用されるものもあれば、自動で適用されないものもあります。利用するクラウドサービスのバージョンアップの方法を確認した上で、バージョンアップの情報を漏れなく把握し、適用前には必ず影響調査等を実施するように留意してください。

• *データの保守要件* 情報システムの設定データやマスタデータの更新作業等に関する要件を記載します。

• *保守実績の評価と改善* 情報システムの安定的な運用の維持と継続的な改善のために必要となる保守実績の評価、改善活動について記載します。

システム方式を決定する

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

「1-B. システム方式に関する事項」で検討した内容を他の要件の内容と調整し、情報システムの実現案として決定します。機能要件と非機能要件を定義することで、情報システムの全体像が明らかになっていきますが、それを実現するためのハードウェア・ソフトウェアや機能等の構成は必ずしも１つではありません。クラウドサービスを活用した案や独自にハードウェアから用意する案、また、サーバと配置する機能の組合せ等、複数の構成案があります。これらの比較検討を行い、事業者からの提案・見積りを踏まえ、最適な方式を選択する必要があります。

このため、システム方式として選択可能な方式を、複数案取りまとめます。伝達のしやすさを考慮し、図表形式で取りまとめることも有効です。

また、システム方式によって、要件を実現するための難易度が異なることがあるため、要件の優先順位も併せて検討します。