--- type: guideline title: Step.6 非機能要件の定義 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.6 非機能要件の定義 既に定められた業務要件に基づき、業務要件を満たすために情報システムの非機能に求められる要件を定義していきます。 ところで、非機能とはなんでしょう？機能は想像がつきやすいと思いますが、非機能となるとどんなことを決めたらよいかわかりづらいですよね。 情報システムの専門家ではない職員のみで、多岐にわたる非機能要件を全て定義することは、通常困難です。技術的な厳密な定義を説明してもさらにわかりづらくなると思いますので、発注者側にとってわかりやすい具体例を示しながら非機能を説明しつつ、その要件として何を定義しなければならないかを解説していきます。 ## 個々の領域について要件を定める 【標準ガイドライン関連箇所：第３編第５章第２節1)ウ】 非機能要件として定義しないといけない内容は次に挙げる17個の内容（A～Qまで）です。 機能要件の場合は、内容の一部を定義せず、調達時の事業者の提案に委ねることもありますが、非機能要件の場合は基本的に全ての項目を定義します。もちろん、情報システムやプロジェクトの特性によって、定義すべき内容の量は異なります。 項目は細分化されていますが、実は経験的に理解している内容が多くありますので、それらを見ていきましょう。 ### ユーザビリティ及びアクセシビリティに関する事項 情報システムは、提供するサービス・業務の利用者が、使いやすいと実感することにより利用が促進され、使いやすさは利用者の満足度や業務効率の向上に大きく寄与します。本項では、「使いやすさ」をユーザビリティとアクセシビリティという２つの軸で明らかにします。 ユーザビリティとは、利用者がサービス・業務を利用して実施したいことを、ミスなく効率的に行うために必要となる事項であり、アクセシビリティは、目的の情報へのたどり着きやすさを指します。どちらも利用者の年齢、身体的制約、利用環境等の違いによる配慮が必要です。 - 表5-10 情報システムの利用者の種類、特性
No. 利用者区分 利用者の種類 特性 補足
1 ○○申請者 ・・・ 60歳以上の割合：○○％
2 ○○入力担当者 ・・・

業務の環境上、片手で必要な入力を行う必要がある

マウス入力が困難な環境で使用する
3 ○○決裁者 ・・・ 対象手続に関する知識レベルが高い
4 ・・・ ・・・ ・・・
次に整理した特性をグループ化して、ユーザビリティ、アクセシビリティの分類を作成します。例えば画面の構成や操作のしやすさ等を分類として定義し、次に分類ごとにどのような使いやすさを実現したいかをユーザビリティ要件として示します。 - 注記 「ウェブアクセシビリティ導入ガイドブック」 https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook/ また、当該情報システムの特性に鑑みて日本産業規格（JIS）への準拠や多言語対応等の要件を整理し、情報へのアクセスの容易さをアクセシビリティ要件として示します。アクセシビリティ要件の検討に当たっては、「ウェブアクセシビリティ導入ガイドブック」が参考になります。 - 表5-11 ユーザビリティ要件
No.

ユーザビリティ

分類

ユーザビリティ

要件

 補足
1 画面の構成

  • 何をすればよいかが見て直ちにわかるような画面構成にすること

  • 無駄な情報、デザイン及び機能を排し、簡潔でわかりやすい画面にすること

  • 十分な視認性のあるフォント及び文字サイズを用いること

  • 画面の大きさや位置の変更ができること
2 操作方法のわかりやすさ

  • 無駄な手順を省き、最小限の操作、入力等で利用者が作業できるようにすること

  • 画面上で入出力項目のコピー及び貼付けができること

業務の実施状況によっては、ショートカットや代替入力方法が用意されること（例えば、片手だけで主要な操作が完了することが求められたり、マウスを利用することが困難であったりする場合が考えられる）
3 指示や状態のわかりやすさ

  • 操作の指示、説明、メニュー等には、利用者が正確にその内容を理解できる用語を使用すること

  • 必須入力項目と任意入力項目の表示方法を変えるなど各項目の重要度を利用者が認識できるようにすること

  • システムが処理を行っている間、その処理内容を利用者が直ちにわかるようにすること
4 エラーの防止と処理

  • 利用者が操作、入力等を間違えないようなデザインや案内を提供すること

  • 入力内容の形式に問題がある項目については、それを強調表示する等、利用者がその都度その該当項目を容易に見つけられるようにすること

  • 電子申請等については、確認画面等を設け、利用者が行った操作又は入力の取消し、修正等が容易にできるようにすること

  • 重要な処理については事前に注意表示を行い、利用者の確認を促すこと

  • エラーが発生したときは、利用者が容易に問題を解決できるよう、エラーメッセージ、修正方法等について、わかりやすい情報提供をすること
5 ヘルプ

  • 利用者が必要とする際に、ヘルプ情報やマニュアル等を参照できるようにすること
- 表5-12 アクセシビリティ要件
No.

アクセシビリティ

分類

アクセシビリティ

要件

 補足
1 基準等への準拠 広く国民に利用され公益性の高い情報システムであるため、日本産業規格JIS X 8341シリーズ、「みんなの公共サイト運用ガイドライン」（総務省）、ＸＸ省ウェブアクセシビリティ指針等に従い、アクセシビリティを確保した設計・開発を行うこと（※引用した基準は例示である）
2 指示や状態のわかりやすさ 色の違いを識別しにくい利用者（視覚障害のかた等）を考慮し、利用者への情報伝達や操作指示を促す手段はメッセージを表示する等とし、可能な限り色のみで判断するようなものは用いないこと
3 言語対応 本情報システムでは、日本語のほか、ＸＸ語で記載されたコンテンツに対応すること
### システム方式に関する事項 「システム方式」では、定義された業務要件のうち、情報システムが処理・実行する範囲について、情報システムとして動作するために必要となる「道具」の具体的な実現方法を明確にします。 - 表5-13 情報システムの構成に関する全体の方針
No.

全体方針の

分類

 全体方針 補足
1 システムアーキテクチャ 本情報システムのシステムアーキテクチャは、【メインフレーム型／クライアントサーバ型／Ｗｅｂサーバ型／外部サービス利用型／スタンドアロン型】とする
2 アプリケーションプログラムの設計方針 情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）間の疎結合、再利用性の確保を基本とする
3 ソフトウェア製品の活用方針

広く市場に流通し、利用実績を十分に有するソフトウェア製品を活用する

アプリケーションプログラムの動作、性能等に支障を来たさない範囲において、可能な限りオープンソースソフトウェア（ＯＳＳ）製品（ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェア製品）の活用を図る。ただし、それらのＯＳＳ製品のサポートが確実に継続されていることを確認しなければならない
4 システム基盤の方針 クラウドサービス提供者が提供するサービス・機能を最大限活用した構成とする
- 事例5-4 他者提供のサービスを利用して開発する場合の注意点

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

ある省では、ローコード・ノーコード系のSaaSを利用して、電子申請システムを構築しました。

その際に、SaaSが提供する標準機能だけでは実装できない機能があり、JavaScriptを用いて個別に開発した機能（以下「個別開発機能」という）を作っていました。

このシステムが稼働した後で、ある日突然にシステムが正常に利用できないという障害が発生しました。原因究明や対応等に時間がかかったこともあり、数週間もサービスを停止する事態となってしまいました。

障害の原因は、個別開発機能の中でSaaSが提供するサービスの特定の部品（Class名）を参照している部分があり、その仕様がアップデートにより変更されたことでした。

SaaSを利用して新規システムを構築する場合、SaaSの提供者が提供する標準的なサービス・機能を最大限活用した構成とするのが望ましいといえます。個別開発機能の実装ありきではなく、SaaSの提供者が提供する標準的なサービス・機能に合わせて要件の変更を検討しましょう。

一方で、どうしても機能面での制約があり、個別開発機能を独自に実装することを検討する場合があります。その場合は、運用開始後の個別開発機能の保守等の作業が発生するため、SaaSの提供者が提供する標準的なサービス・機能だけで構成した場合とライフサイクルコストを比較しましょう。

上記を検討した結果、個別開発機能を実装すると判断した場合においては、サービスのアップデートの影響によるサービス停止のリスクを認識することが重要です。これを踏まえて、以下の対応の実施を検討しましょう。

  • 提供するサービスのアップデート情報を積極的かつ正確に利用者に事前通知するSaaSを選定し、アップデート情報をきちんと把握する。

  • サービス呼び出しに失敗した際には確実にアラートを発出し、そのアラートを検知して対応可能な仕組みを準備しておく。

  • サービスのアップデートのリリース前にテストが可能な場合は、検証環境において影響調査を行う。

なお、この事例はローコード・ノーコード系のSaaS上で個別に機能を開発する場合の注意点ですが、それ以外のアプリケーション開発においても同様の注意が必要です。ソフトウェア提供者が提供する標準的なAPIやライブラリ等を使わずに、個別開発を行い過ぎると、忘れた頃に予期せぬ障害等を招くおそれがあります。この点に留意して、個別開発は必要最低限に留め、継続性、保守性、中立性、コスト等を総合的に勘案して、開発方式の判断を行ってください。
- 注記 追加で発生する作業の例には、次のようなものがある。 クラウドサービス上で個別に機能を開発する場合、クラウドサービスのアップデートと個別開発機能の機能改修のサイクルが異なることが想定される。 クラウドサービスのアップデートは、左記の事例のように個別開発機能に影響し、障害の原因となり得る。 そのため、ＰＪＭＯがタイミングをコントロールできないクラウドサービスのアップデートが実施される前提で、情報システムの規模や構成に応じて検証環境の準備が必要であり、それを踏まえて個別開発機能の改修を計画する。 ツール等を利用し、システムライフサイクルコストを削減する アプリケーションの開発ツールは日々進歩しています。例えばノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、コストの削減等が見込める場合等には、積極的に採用を検討してください。 - ＲＦＩ等を通じて事業者から得た情報を踏まえ、実現性が十分であること及びコスト効率を高めることを基本として方針を検討する。また、必要に応じて新技術の適用可能性も検討する。 - システムアーキテクチャ及びシステム基盤の方針の検討は、クラウドサービスの活用も踏まえて行う。 - ソフトウェア製品の選定においては、機能要件や非機能要件から適切なソフトウェア製品を選定できるよう、留意する。 ### 規模に関する事項 「規模」とは、情報システムを使うユーザの数や取り扱う情報量を指します。利用者が多ければ単位時間当たりで多くのリクエストを処理できる能力が必要となりますし、情報量が多ければ、より大容量のデータベース等が必要になります。要件定義では「利用者は最大100人、平日は常時80人、土日は基本的に休みのため10人未満」といった要件を定量的に示します。 次に示す各表では、機器やデータ等の量について整理し、想定可能な最大値を要件として示します。 - 表5-14 機器数及び設置場所 | No. | 機器の区分 | 機器の用途 | 機器数 | 設置場所 | 補足 | |-----|------------------|--------------|--------|-------------|------| | 1 | クライアント端末 | 窓口入力用 | XX | 本省○階○○室 | | | 2 | プリンタ | 証明書出力用 | XX | ○局○○室 | | | 3 | ・・・ | ・・・ | ・・・ | ・・・ | | - 表5-15 データ量 | No. | データ区分 | データ量 | 補足 | |-----|----------------|----------|------| | 1 | 操作ログ | 最大XXMB | | | 2 | ○○用データ | 最大XXMB | | | 3 | 個人用フォルダ | 最大XXMB | | - 表5-16 処理件数
No. 項目 処理件数 補足
1 アクセス数

  • 定常時：XX件/日

  • ピーク時：XX件/日

  • ピーク特性：○月に年間の処理のXX％が集中
2 ○○操作件数 ・・・
3 ○○処理件数 ・・・
- 表5-17 利用者数
No. 利用者区分 利用者数 補足
1 ○○申請者

  • 同時アクセス可能人数：XX人

  • アクセスの同時到達量：XX回/min

  • 利用時間帯：XX時～XX時
2 ○○入力担当者 ・・・
3 ○○決裁者 ・・・
過度の規模要件は、過度の情報システム投資を招く 「大は小を兼ねる」と言いますが、過大は無駄を招きます。「十分な」といった曖昧な表現を避け、「○○人」「××件」といった定量的な表現とすることで、適切な規模要件を設定してください。 - 情報システムの規模は、性能や信頼性に関する要件を検討する際の前提条件であり、機器の仕様や配置等の設計、調達コストに影響を与える。 - 過度の規模要件を規定することは、過度の情報システム投資を招くことになる。 設置場所を開示するべきでない場合の記載方法 設置場所が不特定多数の者に知られることが情報セキュリティ上問題あるサーバ等の機器については、「○○県内」「東京都23区内」といった記載にとどめ、詳細については契約締結後、受注者のみに開示するものとし、設置場所が特定できないように配慮してください。 - 建物やフロア等、ネットワーク接続要件を考慮して、設置場所を記載する。例）厚生労働省X階XX室、XX局XX室 - 情報セキュリティの観点からみて、設置場所を明示する場合、設置場所に関する情報は広く一般に公開するものではない。このため、この情報については、非開示覚書(NDA)を交わした上で、閲覧等によって開示することを考慮する。 ### 性能に関する事項 「性能」とは、情報システムの能力を指します。能力を測る指標には、応答性能やスループット（処理性能）等があります。ネットショッピングで例えると、商品を検索し検索結果のリストが表示され、特定の商品を選択すると詳細情報が表示される、という一連の流れが一般的ですが、検索ボタンや選択ボタンを押してから、次の画面が表示されるまでの時間が応答性能です。スループットは、一度にどれだけの量を処理できるかという性能で、通常時でも大量に注文が発生するバーゲンセール開催中でも、定義した応答性能が担保されるということを表します。経験があるかもしれませんが、ネットショッピング中に検索結果が返ってこないと、購買する意欲が下がってしまいます。性能はサービス・業務の質に大きな影響を与えます。また、スループットを担保するためには、ハードウェアや回線増強等の投資が必要です。 性能に関する事項は、費用と性能のバランスをとって定義しましょう。 - 表5-18 応答時間
No. 設定対象 指標名 目標値 応答時間達成率 補足
1 ○○処理 レスポンスタイム

定常時：X秒以内

ピーク時：X秒以内

 90％
2 ターンアラウンドタイム

定常時：X秒以内

ピーク時：X秒以内

 90％
3 サーバ処理時間

定常時：X秒以内

ピーク時：X秒以内

 平均値
4 ○○処理 レスポンスタイム 90パーセンタイル
5 ターンアラウンドタイム 90パーセンタイル
6 サーバ処理時間 平均値
- 表5-19 スループット | No. | 設定対象 | 目標値 | 補足 | |-----|----------|---------|------| | 1 | ○○処理 | XX件/秒 | | | 2 | | | | | | | | | 多機能化で情報システムの性能が大きく劣化しないようにする ユーザ要望や企画の実現、運用保守コストを削減するために、複数の画面や帳票の統合を検討することがありますが、統合することにより、次に示すようなデメリットが発生することもあります。 - １つの画面や帳票で取り扱う項目や機能が増えるため、画面の表示や帳票出力までの処理に時間がかかるようになる。 - システム処理そのものに加え、途中で発生したエラーのリカバリー処理も統合することにより複雑化するため、テスト工数の増大も含め、かえって保守コストが増加することもある。 このような事態を避けるために、画面標準等で、１つの画面や帳票に盛り込む情報量の基準の設定や、現在画面や帳票が分割されている理由を、業務面だけではなくシステム面からも確認しておくことが重要です。 現場の職員は１つの画面や帳票で多岐に渡る業務を行いたいと要望しがちですが、視認性や操作性の観点から、ストレスを感じることなくスムーズに使える範囲内で、適切に分割する方が有効です。 - 事例5-5 非機能要件が機能要件に影響することもある

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

ある省の既存情報システムを更改するプロジェクトにおいて、改善検討を行うことになりました。現状調査の結果、画面で指定する組織名称のプルダウンの内容が異なるだけで、他の項目はほぼ同一の類似した画面が複数存在していることが判明しました。保守コスト削減の観点から、類似画面を統合することにしました。

その結果、統合した画面では、組織名称のプルダウンに全組織（数千）が表示されることになり、画面表示時に大量の組織名称の情報を取得するため、画面表示までの性能が大幅に劣化し、当該画面を通じて行う業務の効率が低下してしまいました。

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

機能要件では問題がないと見える事柄も、非機能要件では全く違った影響が発生することがあります。この例では、非機能要件のうち、規模に関する事項を検討することで機能要件自体の見直しが発生しました。既存情報システムがある場合は、非機能面において現在の仕様になっている経緯や背景も確認した上で、改変を行いましょう。
想定値ではなく実測値等から真に必要とされる性能を指定する 性能を検討していくと、つい安全な方向に結論を倒しがちです。性能の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意してください。 - 要求事項の記載は、できるだけ定量的な表現となるようにすること。 - 過度な性能要件を設定して調達コストを押し上げることのないよう性能要件の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意すること。 - 常時・定期のモニタリングが必要な場合には、個別部分の性能、トランザクション量等について明示し、組み込みの必要性を指定すること。 - 事例5-6 概念検証により性能要件の実現可能性を確認する

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

ある情報システムは、不特定多数の国民が同時に利用し、業務の特性上、高速なレスポンスが求められ、うまく動作しない場合には利用者に大きな混乱を招くおそれがあったことから、非機能要件の中でも特に性能面が重要でした。加えて、この情報システムは内部で複数の情報システムと連携した上で利用者にレスポンスを返す仕組みであったため、性能面で問題が発生する可能性が高いと考えられました。しかし、当該情報システムは、新規に構築するものであったため現行システム等の実測値から性能要件の実現可能性を判断することが困難でした。そこで、当該情報システムの設計・開発を行う前に概念検証（PoC）を実施し、性能要件の実現可能性を検証することにしました。

概念検証では、実際の情報システム間の連携を再現した簡易な情報システムを構築し、想定される最大の負荷をかけた状態で目標とする性能要件が実現可能かを検証しました。概念検証において性能を低下させる要因の特定と排除といった改善活動を繰り返し行うことで、最終的には目標値を大幅に上回り、性能要件が実現可能であることが確認できました。

また、概念検証を実施することで、発注者が実際の情報システムの利用場面をより具体的にイメージできたので、新たな機能追加等の要望が発生し、それらを盛り込むよう要件をブラッシュアップすることができたという副次的効果もありました。

現行システムがなく実測値の測定が困難な情報システムの場合には、性能要件の想定値を指定して設計・開発に着手することが多いですが、社会的な影響が大きい情報システムや性能によって評価が左右される情報システムなどでは、概念検証によって性能要件の実現可能性を検証することも有効です。
### 信頼性に関する事項 「信頼性」とは、情報システムが持つ故障への耐性の度合いのことを指します。一般的には平均故障間隔（分又は時間）で評価します。平均故障間隔の値が小さければ小さいほど信頼性は高いと言えます。 情報システムを、構成する要素（サブシステムやネットワーク等）に分解し、情報システム全体での年間稼働率を踏まえて、各要素の信頼性に係る指標や目標値を要件として示します。 - 参考5-4 最適なシステム構成

参考：最適なシステム構成

情報システム全体の信頼性はサーバや周辺機器、クラウドサービスだけでなく、サービス提供者と利用者を結ぶネットワーク等を含めて検討する必要があります。

例えば以下のような稼働率の要素で構成されたシステムは、サーバはシックスナインの稼働率を確保していますが、ネットワークや負荷分散装置を含めた稼働率はスリーナインを下回っています。

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

このように、局所的に高い稼働率を確保しても、他の構成要素の稼働率が低ければシステム全体の稼働率は低くなります。

高い稼働率を確保するには、信頼性の高い機器や冗長な構成が必要となり、コストがかかるため、過剰な構成とならないよう、業務要件に沿った設計が重要です。デジタル・ガバメント推進標準ガイドラインでは、情報システムに求められる稼働率について、以下のような参考情報を示しています。

表 1 システムプロファイル
分類 判断要素
TypeⅣ サービス停止等が起きた場合、これにより人命損害が発生する可能性があるもの又は想定される経済的損失が甚大であるもの
TypeⅢ サービス停止等が起きた場合、これにより身体への悪影響が発生する可能性があるもの又は想定される経済的損失が大きいもの
TypeⅡ サービス停止等が起きた場合、これにより経済的損失が少なからず発生するもの
TypeⅠ TypeⅡからⅣまでに該当しないもの
表 2　システムプロファイルから考えるシステム基盤に係る非機能要件のモデル
No. 大項目 主な非機能要求項目 TypeⅠ TypeⅡ TypeⅢ
TypeⅣ
1 可用性 稼働率 ・1年間で数日程度の停止まで許容できる（稼働率99%）。 ・1年間で1時間程度の停止まで許容できる（稼働率99.99%）。 ・1年間で数分間程度の停止まで許容できる（稼働率99.999%）。
2 障害目標復旧水準 ・データのリカバリーを伴う復旧において、週次のバックアップデータからの復旧を行う。 ・データのリカバリーを伴う復旧において、1営業日以内での復旧を目標とする。 ・データのリカバリーを伴う復旧において、数時間で障害発生時までの復旧を目標とする。

表：デジタル・ガバメント推進標準ガイドライン（別紙５）から一部抜粋

信頼性の高いシステムは構築だけでなく、維持にもコストがかかります。業務要件の求める稼働率を大きく上回るような過剰な設計とならないように留意しましょう。
- 表5-20 可用性要件 - 注記 ＭＴＢＦとは、システムが故障するまでの平均間隔のこと。 ＭＴＢＦはMean Time Between Failuresの略。 | No. | 設定対象 | 指標名 | 目標値 | 補足 | |-----|------------|----------------------|-----------------------------|------| | 1 | ○○サービス | 平均故障間隔（MTBF） | 平均故障間隔は8,760時間以上 | | | 2 | ○○サービス | 平均修復時間（MTTR） | 平均修復時間は24時間以内 | | | | | | ・・ | | - 注記 ＭＴTRとは、システムを復旧・修理するまでにかかる平均時間のこと。 ＭＴTRはMean Time To Repairの略。 拡張性に関する事項 「拡張性」とは、情報システムの運用開始後に性能又は機能を向上させる場合に、容易に対応できる度合いを指します。性能については、将来の利用者の拡大やデータ量の増加に備えて、情報システムの処理性能を維持するためのハードウェア、ソフトウェアの対処方針を、要件として定量的に示します。機能については、将来の制度改正や技術の変化等に備えて、容易に改修を行うための設計指針やアプリケーションの改修方針を示します。想定する拡張が必要となるケースを、提供するサービスや業務と併せて具体的に記載することが重要です。「利用者数がX倍になる」だけではなく、「○○サービスを利用する部署がY倍になるため」といった、拡張の背景を記載することにより、設計時に考慮しやすくなります。 - 参考5-5 拡張性要件の記載例

参考：拡張性要件の記載例

  • ＸＸ年に予定される全国展開が完了した場合、利用者数が1.5 倍になると想定されるが、これに伴い性能が落ちることのないよう、処理能力の向上やデータ保存領域の拡張等が容易に可能な構成とすること。

  • 本情報システムの刷新は、全国の拠点を地域で分割して段階導入を行うため、その段階導入のタイミングと併せて、ネットワーク機器やサーバ機器の予備のポートやスロットを用いて適宜最適な拡張が可能な構成とすること。
- 注記 IaCとは、「Infrastructure As Code」の略称。従来は手作業で行っていたOS、ミドルウェア等の導入や設定をコードで表現し、そのコードを実行することで自動的にインフラを構築する技術のこと。 - 注記 CI/CDとは、「Continuous Integration／Continuous Delivery」の略称。アプリケーションを改修する際に発生するビルド、テスト、デプロイなどの作業を自動化することなどによって、継続的に（頻繁に）アプリケーションの改善を可能とする手法。 - 注記 ＢＲＭＳにおける、業務プロセス内の条件および処理の例として、勤怠管理システムにおける＜「18時15分以降の勤務時間」（条件）は「残業時間とする」（処理）＞というルールが挙げられる。組織内で17時45分以降の勤務を残業時間として扱うようにルールが変更された場合は、表などに示された条件を変更することで対応できる。 - 参考5-6 変化に強い情報システムの構築

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

社会情勢の変化や利用状況の変化に対応して情報システムを改修する際、拡張性が低いと改修に時間がかかったり、大きなコストがかかったりしてしまいます。このような改修を迅速に低コストで実現できる、変化に強い情報システムを構築するためには、どのようなことに留意すればよいのでしょうか。

以下では、情報システムの構築における工夫をいくつかご紹介します。

  • 想定される変化を要件として示す

    要件定義の段階で、制度改正による計算式の変更のような将来起こり得る変化とともに、それらの変化への効率的な対応を拡張性要件として定めることが重要です。そして、これらの要件を実現するための工夫を技術審査における評価項目とすることで事業者の創意工夫を引き出すことができます。

    ある情報システムでは、定期的に発生する制度改正のたびに高額の改修コストがかかっていたことに加え、制度改正の成立日から施行日までの期間が短いため改修を短期間で行うことが負担となっていました。

    情報システムの刷新にあたって、制度改正の発生時期や改修にかけられる期間の短さなどを調達仕様書に具体的に提示した上で、解決方法の提案を事業者に求めたところ、ある事業者からＢＲＭＳ（ビジネスルールマネジメントシステム）の利用が提案されました。

    ＢＲＭＳは業務を遂行する上での判断条件及び処理（ビジネスルール）をアプリケーションから切り離して管理し、それらを表形式等で可視化します。制度改正等でビジネスルールを変更する際もコーディングなしにツール上で変更できるため迅速に対応することが可能です。

    当該事業者の提案どおりＢＲＭＳを採用したところ、制度改正の対応にかかるコストを削減でき、短期間での対応も可能となりました。

    なお、拡張性要件を定める際に、想定されるあらゆる変化への対応を求めると、構築コストが高額になってしまうおそれがあるため、影響範囲の大きい変化や、発生する可能性が高い変化などの観点で、本当に必要なものに限定することが必要です。

  • 変化に柔軟に対応できるシステム構成を採用する

    システム構成に関する工夫として、情報システムのうち変更が生じやすい箇所は、一から開発するのではなく、既存のツールやサービスを採用するという方法があります。

    例えば、セキュリティ対策としてID／パスワードによる認証から多要素認証へ認証方法を変更する可能性がある場合などには、主体認証にクラウドサービス（IDaaS）を採用するという方法があります。認証方法を変えたいときには、クラウドサービスの設定を変更すればよく、作り込んだ認証機能を改修する場合に比べて簡単です。

    また、クラウドネイティブと呼ばれるクラウド環境に最適化した設計・構築を行う方法もあります。具体的には、マイクロサービス、ＣＩ／ＣＤ、ＩａＣなどがあり、疎結合化、自動化等を組み合わせることで、環境の変化に対して迅速かつ少ない労力で対応できるようになります。

  • 変化に対応しやすい設計・開発を行う

    設計・開発の段階では、ハードコーディングに注意する必要があります。ハードコーディングとは特定の値やメッセージなどをソースコードに書き込むことであり、変更が生じやすい値などをハードコーディングすると、変更が生じるたびにアプリケーションの改修が必要になります。

    ハードコーディングを避ける工夫の一つに、外部ファイルを参照させる方法があります。変更を行うときは、ソースコードを修正しなくても、参照させる外部ファイルに手を加えればよいため、変更の負担が少なく済みます。

    なお、せっかく外部ファイルを参照させる方法を採用しても、外部ファイルを変更するたびに情報システムが正常に動作するかを細かくテストしていては、ハードコーディングと変わらなくなってしまいます。運用開始後はそのようなテストができるだけ不要となるように、外部ファイルの値を変更しても情報システムが正しく動作するかを設計・開発の段階でテストしておくことが必要です。

    また、情報システムが簡易なものであれば、コーディングに代わる開発手法として、ソースコードの記述なしで開発が可能なノーコード開発も選択肢の一つとなります。ノーコード開発では、あらかじめ用意されているパーツをドラッグ・アンド・ドロップするなどの直感的な操作で開発するため、変更が生じた際にもソースコードを修正する必要がありません。
### 上位互換性に関する事項 「上位互換性」とは、主にソフトウェア製品において、新しいバージョンの製品で古いバージョンの製品が利用できることを指します。代表的な製品は上位互換性がありますが、バージョンアップに伴い、帳票作成ツールの場合レイアウトが崩れたり、ブラウザの場合画面のレイアウトや特定のボタンが動作しなくなったりといった、一部の機能に限り上位互換性がないこともあります。 当該情報システムを構成するソフトウェア製品において、将来予想されるバージョンアップ時の対応可能性について、定義時点において明確にできる範囲内で、具体的な対象とバージョンアップ時の対処方針を要件定義書に記載します。 各製品のバージョンアップポリシーを踏まえて、コストを検討する 機能追加等のバージョンアップが頻繁に行われる製品を利用する場合、バージョンアップ後のテストに係るコストが膨大なものとなり、費用対効果が著しく悪化する可能性が高くなります。 したがって、製品の選定に当たってはバージョンアップ後のテストの簡略化等を検討するとともに、費用対効果が見込める場合には、OS・ミドルウェア等の乗換についても積極的に検討してください。 - バージョンアップは将来の不確定要素であることから、上位互換性を過度に要求する場合、事業者が応札に対して慎重になる可能性や、リスクを見込んだ高額な調達コストとなる可能性があることに留意する。 - 参考5-7 上位互換性要件の記載例

参考：上位互換性要件の記載例

  • クライアントＯＳのバージョンアップに備え、ＯＳの特定バージョンに依存する機能が判明している場合は、その利用を最低限とすること。

  • Ｗｅｂブラウザ及び実行環境等のバージョンアップの際、必要な調査及び作業を実施することで、バージョンアップに対応可能な情報システムとすること。
### 中立性に関する事項 「中立性」とは、情報システムを構成する要素が、特定の技術や製品に特化しないことを指します。特定の技術や製品に特化した構成とすると、ベンダーロックイン状態となってしまう可能性があるため、中立性に配慮する必要があります。 例えば、新規に情報システムを構築する際に、ある事業者が開発・販売している製品を利用しなければ運用・保守ができない構成にしたとします。その後、運用・保守業務を一般競争入札で調達しようとしても他の事業者ではその製品を入手できないなどの理由により、その製品を導入した事業者による一者応札となってしまいます。このような状態になることを防ぐために、特定の事業者の技術に依存せず、多くの事業者が扱える製品を採用するなど、中立性への配慮が必要です。 また、特殊なツールを利用する場合、将来的に他の製品への乗り換えが困難にならないよう、中立性の観点から問題のないツールであることを要件として示します。 なお、情報システムの調達において、ベンダーロックインを避けることを重視する場合には、中立性に関する事項を要件定義書に示すだけでなく、総合評価落札方式における加点項目とし、配点を高くすることも選択肢の一つです。 - 参考5-8 オープンな標準的技術又は製品の採用を求める場合の記載例

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

  • 提供するハードウェア、ソフトウェア等は、特定ベンダーの技術に依存しない、オープンな技術仕様に基づくものとすること。

  • 提供するハードウェア、ソフトウェア等は、受託者以外の者が市場で調達することが可能である製品を選定すること。

  • 提供するハードウェア、ソフトウェア等は、全てオープンなインタフェースを利用して接続又はデータの入出力が可能であること。

  • 導入するハードウェア、ソフトウェア等の構成要素は、標準化団体(ISO、IETF、IEEE、ITU、JISC等)が規定又は推奨する各種業界標準に準拠すること。

  • ノンプログラミングによる画面生成等プロトタイピング用のツール等を採用する場合には、当該ツールは中立性の観点から問題ないものを選定すること。
- 参考5-9 事業者交代時の対応を求める場合の記載例

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

  • 次期情報システム更改の際に、データ移行の妨げとなることや、特定の装置や情報システムに依存することを防止するため、原則として情報システム内のデータ形式はXML、CSV等の標準的な形式で取り出すことができるものとすること。

  • 特定の事業者や製品、技術等に依存することなく、他者に引き継ぐことが可能なシステム構成であること。
### 継続性に関する事項 「継続性」では、当該情報システムを構成する要素（サブシステム、サービス等）に分解し、情報システム全体での目標復旧時間を踏まえて、各要素の継続性に係る指標や目標値を要件として示します。 - 表5-21 継続性要件
No. 設定対象 指標名 目標値 補足
1 ○○システム

稼働率

（「年間実稼働時間」／「計画停止等を除いた年間予定稼働時間」×100）

 XX.X％
2

目標復旧時点

（バックアップデータの復旧時点）

 XX時間
3

目標復旧時間

（データ復旧までの時間）

 XX時間以内
4 ○○サブシステム 稼働率 XX.X％
5 目標復旧時点 XX時間
6 目標復旧時間 XX時間以内
- 注記 オンプレミスとは、発注者が自ら情報システムに必要な機器（サーバ、ネットワーク、ソフトウェア製品等）を調達し、情報システムの運用を行うこと。 クラウドサービスとオンプレミスは継続性の確保方法が異なる 例えば、クラウドサービスを利用する場合には、オンプレミスのようにテープ等の媒体で別途保管する必要はなく、クラウドサービス提供者が提供するバックアップサービスを利用すればよいと考えられます。ただし、バックアップサービスには様々な種類が存在することに鑑み、選択する手法が妥当なものであることを確認できるようにすることが重要です。 - 参考5-10 継続性に関する事項の記載例

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

  • 利用するクラウドサービスで提供される仮想サーバ等の可用性に係るSLAに留意し、各構成要素について適切に冗長化等を行うこと。

  • バックアップの取得については、クラウドサービス提供者から提供されるバックアップサービスを利用して差し支えない。ただし、適用するサービスの種類、同時被災しないことを前提としたバックアップサイトの場所、バックアップデータの取得時期及び保持期間（世代管理を含む）、自動化の程度等については、対象とするデータの性質等に応じて、業務に影響を与えず、かつ費用対効果が高いものを適宜選定すること。
- 事例5-7 クラウドサービスのハードディスク障害によるデータ消失の責任

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

クラウドサービス提供者に預けたデータがハードディスク障害によって消失した場合、クラウドサービス提供者の責任範囲については種々の議論がありますが、東京地裁では平成21年5月20日に以下のような判決がありました。

あるユーザ企業がサーバホスティング事業者の運営するサーバを利用してウェブサイトを運営していたところ、ハードディスク障害が発生し、プログラム・データが消失してしまいました。ユーザ企業は、これについて損害賠償を求める訴訟を提起しましたが、裁判所は以下のように述べて訴えを退けました。

「サーバは完全無欠ではなく障害が生じて保存されているプログラム等が消失することがあり得るが、プログラム等はデジタル情報であって、容易に複製することができ、利用者はプログラム等が消失したとしても、これを記録・保存していれば、プログラム等を再稼働させることができるのであり、そのことは広く知られているから、ユーザ企業らは本件プログラムや本件データの消失防止策を容易に講ずることができたのである。」

(東京地判平21.5.20判タ1308-260 より)

無論、裁判の結果は、個別の事情により異なりますが、上記の判決を見る限り、クラウドサービス提供者等にデータやプログラムを預ける際には、データ消失の対策としてバックアップの取得等を講ずることは、ユーザ側の責務であると考えられます。

しかし、データのバックアップ等消失対策を講じるためには別途費用が必要となる場合が多いため、ユーザは、各々のデータの重要性と対策にかかる費用について十分に検討し、バランスの良い対策をとる必要があります。
- 事例5-8 クラウドサービスの外へのバックアップの検討

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

ある情報システムにおいて、プログラムを含むクラウドサービス上のすべてのデータが消失し、利用できなくなりました。発注者と情報システムの運用事業者の間では、この情報システムを継続して運用することが合意されていたものの、運用事業者がクラウドサービスの利用継続手続きを怠っていたために、当初の契約期間満了とともにクラウドサービス上のデータが削除されたことがこの障害の原因でした。この障害により、クラウドサービス上に取得していたバックアップを含むすべてのデータが消失し、復旧が不可能な状態となってしまいました。

このような障害では、仮に災害対策環境を設置していたとしても、それが本番環境と同じクラウドサービスであるなど、条件が変わらない場合には、本番環境とともに消失するおそれがあることに注意が必要です。

対策としては、オンプレミスの環境や別のクラウドサービスなどを用意しておき、定期的にバックアップを保管することが考えられます。ただし、バックアップを取得するためには、これらの環境を用意したり、運用事業者にバックアップ作業を依頼したりするために追加の費用がかかります。また、バックアップを取得する対象や周期、データの保持期間などの検討も必要となります。

別の事例として、オーストラリアの年金基金（UniSuper）で発生した障害の件も教訓になります。クラウドサービスで稼働している情報システムのデータが、クラウドサービス提供者側の設定ミスによって削除されてしまいました。年金基金のシステムはクラウドサービス上で2つの地域に分散してシステムの二重化を行っていましたが、この両方のデータが削除されたのです。障害対応には時間がかかりましたが、幸いクラウドサービス上に別のバックアップデータを保存していたため、データを復旧することができました。

バックアップの検討にあたり参考となる考え方として、2012年にUS-CERT（米国のコンピュータ緊急対応チーム）が提唱した「3-2-1ルール」というものがあります。要点は「データはコピーして３つ保有（プライマリー1つ、バックアップ2つ）、2種類の異なる記録媒体に保管、コピーのうち１つは遠隔地に保存」という考え方です。

必ずしもこの考え方どおりに対応する必要はありませんが、当該情報システムの目標とする復旧水準と、対策に要する費用等を考慮して、バックアップの取得方法を総合的に判断する必要があります。
- 参考5-11 業務継続の分かれ目

参考：業務継続の分かれ目

業務を継続するためには、緊急時対応計画や業務継続計画を定めることが必要ですが、その計画に従って業務継続に係る目標が達成できるのか、また、計画や手順に抜け漏れがないか確認するために訓練を行うことが重要です。以下に業務継続に問題を起こさないように留意すべき3つの観点での訓練を挙げます。

  1. システムが全く使えない状況で業務を継続する訓練

長年利用している情報システムがあると、その情報システムが業務の大前提として組み込まれてしまい、いざ情報システムが停止した際に業務が大混乱してしまうことがあります。

次の2つの例を見てみましょう。どちらもシステムが全面停止するという深刻な障害に見舞われましたが、業務継続性の観点では全く異なる結果となりました。

  • 普段からシステム障害時に備えて紙台帳でも窓口業務をできるようにしていたため、実際に障害が発生した時に業務の効率は下がったものの来訪した利用者に対して必要なサービスを提供できた。

  • システムを過信し障害時の対応方法を想定できていなかったため、実際の障害発生時に窓口が大混乱し必要なサービスを提供できず、利用者にはシステム障害を理由に一度帰ってもらうことになった。

後者のようにならないように、災害発生やシステム障害等、さまざまな予期せぬ状況に対してできる限り業務を継続する準備や訓練が重要です。

  1. システム自体を災害対策拠点に切り替える訓練

多くのシステムでは年に1回程度、切替え訓練を実施しています。あるシステムでは、災害対策拠点を定義したものの、災害対策拠点に切替えてしまうと元の環境に戻せなくなることが事後的に判明したため、切替え自体の判断を慎重に求められることになってしまいました。要件定義の段階で、災害対策環境への切替えだけでなく、本番環境への復帰要否についても検討しましょう。

  1. バックアップからデータを戻す訓練

バックアップを取っているだけでは安心できません。いざという時に復旧できなければ意味がありません。定期的なバックアップからの復旧訓練の実施を検討しましょう。
### 情報セキュリティに関する事項 「情報セキュリティ」とは、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。機密性とは、ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保することです。完全性とは、情報が破壊、改ざん又は消去されていない状態を確保することです。可用性とは、情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することです。 ここでは、自組織において定められた情報セキュリティポリシーを遵守するために必要な情報セキュリティ対策の内容について、具体的に記載してください。 個々の業務について記載するのではなく、業務分類等、グループ単位で記載します。また、ユーザ認証において、求められる要件（例えば、社内の認証サーバと連携できること等）があるときは、それらも記載します。 - 表5-22 情報セキュリティ対策要件 | No. | 情報セキュリティ対策 | 対策に係る要件 | 補足 | |-----|----------------------|----------------|------| | 1 | 主体認証 | | | | 2 | アクセス制御 | | | | 3 | ログ取得及びログ管理 | | | 当該情報システムに実装する機能や画面に対して、利用者の権限に応じた管理レベルを記載します。 - 表5-23 権限要件 | No. | 機能 | 利用者区分 | アクセス権限 | 補足 | |----|----|----|----|----| | 1 | ○○申請処理 | 一般ユーザ | 自申請情報のみ登録・参照・変更・削除可能 | | | 2 | ○○申請処理 | 一般職員 | 自組織が担当する申請者の情報は登録・参照・変更・削除可能。他組織担当の申請者情報は参照のみ。 | | 想定されるリスクの概要と対策について記載します。 - 表5-24 リスク一覧
No. リスクの区分 リスクの概要と対策 補足
1 ・・・

インターネットからの不正アクセス等、外部からの攻撃を受ける可能性がある。

必要な対策を講じ、不正アクセス等の悪意ある攻撃を防ぐ。
2 ・・・

来訪者エリアと職員エリアで、同じネットワークを利用するため、来訪者エリアからの進入等の被害につながる可能性がある。

ネットワークの論理分割、セグメント分割、ファイアウォールやＤＮＺ等の設置により、進入を防ぐ。
3 ・・・

利用者が担当業務に関係のない情報を閲覧し、情報漏洩につながる可能性がある。

必要十分な権限制御を行い、利用者に業務に不必要な情報を閲覧させない。
定義に当たっては、自府省の情報セキュリティポリシーを参照するとともに、必要に応じて「政府機関のサイバーセキュリティ対策のための統一基準群」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（平成23年４月28日内閣官房情報セキュリティセンター）等を参照し、必要な対策を漏れなく記載しましょう。 当該情報システムに求めるセキュリティ要件については、次に示す「最低限記述すべき情報セキュリティ対策要件」を参考にして、表5-22で示した様式を参考に記載してください。 - 5-12 最低限記述すべき情報セキュリティ対策要件

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

  1. セキュリティ機能の装備

【情報システムの構築等の場合の記載例】

以下のセキュリティ機能を具体化し、実装すること。

  • 本調達に係る情報システムへのアクセスを業務上必要な者に限るための機能

  • 本調達に係る情報システムに対する不正アクセス、ウイルス・不正プログラム感染等、インターネットを経由する攻撃、不正等への対策機能

  • 本調達に係る情報システムにおける事故及び不正の原因を事後に追跡するための機能(情報システムに含まれる構成要素(サーバ装置・端末等)のうち、時刻設定が可能なものについては、情報システムにおいて基準となる時刻に、当該構成要素の時刻を同期させ、ログに時刻情報も記録されるよう、設定すること。)

  1. 脆弱性対策の実施

【情報システムの構築等の場合の記載例】

以下の脆弱性対策を実施すること。

(第三者による脆弱性検査を必要とする場合)

  • 本調達に基づく改修(新規構築/更改)が影響する範囲について、第三者による脆弱性検査を実施し、その結果を関係府省に書面にて報告すること。

(第三者による脆弱性検査を必要としない場合)

  • 本調達に基づく改修(新規構築/更改)が影響する範囲において、第三者による脆弱性検査を実施し、その結果を関係府省に書面にて報告すること。なお、脆弱性検査ツールを用いる等により客観的なテストが可能であれば、受注者で実施することも可とする。

  • 構築する情報システムを構成する機器及びソフトウェアの中で、脆弱性対策を実施するものを適切に決定すること。

  • 脆弱性対策を行うとした機器及びソフトウェアについて、公表されている脆弱性情報及び公表される脆弱性情報を把握すること。

  • 把握した脆弱性情報について、対処の要否、可否を判断すること。対処したものに関して対処方法、対処しなかったものに関してその理由、代替措置及び影響を納品時に関係府省に書面にて報告すること。

【情報システムの運用・保守・点検の場合の記載例】

以下の脆弱性対策を実施すること。

  • 機器及びソフトウェアについて、公表される脆弱性情報を常時把握すること。

  • 把握した脆弱性情報について、対処の要否、可否につき関係府省と協議し、決定すること。

  • 決定した対処又は代替措置を実施すること。

  1. 情報セキュリティが侵害された場合の対処

本調達に係る業務の遂行において情報セキュリティが侵害され又はそのおそれがある場合には、速やかに関係府省に報告すること。これに該当する場合には、以下の事象を含む。

  • 受注者に提供し、又は受注者によるアクセスを認める関係府省の情報の外部への漏えい及び目的外利用

  • 受注者による関係府省のその他の情報へのアクセス
リスクの概要と対策を定義する - リスクが多様化しているので、なるべく多くのリスクの洗い出しを行うこと。 - 当該情報システムの格付けに見合った情報セキュリティ対策を行うこと。 - 公開されるWebサイト等のドメインについては、利用者がわかりやい政府サイトとするとともに、政府サイトに似せたサイト上で個人情報を収集する等といったフィッシング等のセキュリティ事故が起こりにくい環境を実現すること。 第三者による脆弱性検査を実施する 当該情報システムに対して修正を行う場合、その改修が影響する範囲を対象として第三者による脆弱性検査を実施します。 第三者による脆弱性検査を実施するか否かの判断に当たっては、下表の観点を考慮し、案件ごとに判断してください。なお、第三者による脆弱性検査を実施しない場合には、実施しない理由を明確にします。また、第三者による脆弱性検査は、当該調達に基づく改修が影響する範囲を対象とし、情報システムとしての脆弱性がないことを検査するものであり、実装されたセキュリティ機能の検査を行うものではないことに留意してください。 - 表5-25 脆弱性検査の観点 | No. | 観点 | 判断条件 | |----|----|----| | 1 | 情報の重要度 | 漏えいや消失によって、深刻な損害を被る可能性がある重要な情報（個人情報等）を扱う情報システムの場合は、第三者による脆弱性検査を必須とする。 | | 2 | 外部アクセスの有無 | インターネット等の通信回線を介して外部から情報システムにアクセスしてサービスの利用、業務の遂行、情報システムの管理等を行う場合は第三者による脆弱性検査を必須とする。 | | 3 | 利用者の属性 | 不特定多数の利用者が情報システムを使用する場合は、第三者による脆弱性検査を必須とする。 | | 4 | その他 | 他の情報システムとの連携が生じる等、情報システムの特性に応じて、第三者検査を実施する。 | ### 情報システム稼働環境に関する事項 「情報システム稼働環境」とは、当該情報システムに係る、クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等を明らかにすることを指します。稼働環境には、運用、保守、研修、検証等に必要な環境も含めます。 「システム方式」は構成要素ごとの方針を示すものですが、情報システム稼働環境は、もう一段階分解し、構成要素の内容を具体的に示します。 - 図5-9 ハードウェア構成図 ![](../assets/ds-120-ch05-image20.png) ① ハードウェアの種類を示す語句 　 例：サーバ、クライアント端末、ネットワーク機器等 ② ハードウェアの台数を示す語句 　 例：１台、１個、１式等 ③ 各ハードウェアの設置場所を示す語句 　 例：本庁、出先機関、データセンター、サービス提供者等 ④ ハードウェア間のネットワーク接続形態を示す語句 　 例：ＬＡＮ、インターネット、専用線等 - 表5-26 ハードウェア構成
No. ハードウェア分類 ハードウェア名 ハードウェア要件 補足
1

コンピュータ本体:

サーバ機器

 Ｗｅｂサーバ
2

コンピュータ本体:

メインフレーム・汎用機
3

記憶装置:

ストレージ・ＮＡＳ等

データ量：XX

ディスクの回転数：XX
4

ネットワーク機器:

ＨＵＢ・ルータ・スイッチ等
- 表5-27 ソフトウェア構成
No. ソフトウェア分類 ソフトウェア名 ソフトウェア要件 補足
1 ＯＳ：サーバ用 Ｗｅｂサーバソフトウェア

機能：XX

バージョン：XX

必要ライセンス数：XX

保有済のライセンス内容：XX
2 ＯＳ：クライアント用 アプリケーションサーバソフトウェア
3

ミドルウェア：

Ｗｅｂサーバ

 Ｗｅｂサーバソフトウェア
4

ミドルウェア：

アプリケーションサーバ

 アプリケーションサーバソフトウェア
5 パーソナルソフトウェア：セキュリティ対策 アンチウイルスソフトウェア
- 表5-28 ネットワーク構成
No. 回線種別 ネットワーク要件 補足
1 高速デジタル専用線

・ネットワーク帯域：XX

・冗長構成：有/無

・通信回線装置におけるアクセス制御の設定：有/無

・暗号化：有/無

・通信プロトコル：XX
2 広域イーサネット網 ・・・
3 パケット通信網 ・・・
- 表5-29 施設・設備要件
No. 施設名 施設形態 施設・設備要件 補足
1 ○○施設 国有施設

・制震／耐震／免震：有/無

・非常用電源：有/無

・非常用電源の稼働時間：

・ラック数：XX

・使用可能な電源の容量：XX

・位相及び系統：XX

・許容する発熱量：XX

・耐荷重：XX
2 ○○施設 国以外の公的機関が保有する施設 ・・・
3 ○○データセンター 商用ＩＤＣ ・・・
クラウドサービスを利用する場合は、サービスに関する要件を記載します。クラウドサービスの要件については、要件定義書標準テンプレートを参照してください。オンプレミスで構築する場合は、ハードウェア構成、ソフトウェア構成、ネットワーク構成、施設・設備等の要件の定義に加えて、情報システムのハードウェア構成図も記載します。なお、記載に当たっては、仮想化による物理的な機器の削減についても考慮するとともに、将来的な拡張予定についても、その範囲を識別できるよう留意します。 レンタル/リース/買取の特徴を理解して、選択する 以前は高額なハードウェア製品が多く存在していましたが、昨今は製品価格が下落傾向にあるため、リースよりも買取の方が最終的には安価になることもあります。プロジェクトの特性に併せて、最適な方式を検討しましょう。 なお、事業者より見積りを取得する際には、「一式」ではなく、製品ごとの本体価格を提示するよう依頼し、機器単位で比較ができるよう留意してください。 - 表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 代表的なＯＳＳの比較
確認ポイント GPL
（※1）		 AGPL
（※2)		 LGPL
（※3）		 Apache
(※4)		 MIT
（※5）
ライセンスと著作権の表示要否 必要 必要 必要 必要 必要
変更した旨の表示要否 必要 必要

必要で

ない

 必要

必要で

ない
ソースコードの開示要否 必要 必要 必要

必要で

ない

必要で

ない
ソースコードの改変可否 可能 可能 可能 可能 可能
ソースコードの頒布可否 可能 可能 可能 可能 可能
派生物に対するライセンス条件の適用要否 必要 必要

必要で

ない

必要で

ない

必要で

ない
1. GPL（ライセンス条文 英文） 　 　 2. AGPL（ライセンス条文 英文） 　 3. LGPL（ライセンス条文 英文） 　 　 4. Apache（ライセンス条文 英文） 　 5. MIT（ライセンス条文 英文） 　 ### データマネジメントに関する事項 情報システムは管理するデータを登録、処理、記録するものであり、保有するデータの品質確保はサービス・業務を適切に運営するための生命線です。データ品質を保つためには、情報システムのライフサイクル全体を通してデータの管理状態を定期的に把握し、不具合が発見されれば直ちに原因を特定して対策を行うことが重要です。 また、広く国民に公開するデータに関しては、設計時点からデータの標準化（相互運用性）を意識し、利用しやすい形式（Web-APIやCSV形式など機械判読性の高い形式）にする等の工夫が必要です。 こうしたデータの重要性に着目し、データを情報資産として捉え、その利活用戦略からシステム実装に向けた設計や開発、さらに稼働後の運用、利用に至るまでのデータ品質の維持・向上をベースとした継続的、組織的な活動を「データマネジメント」と呼び、以下のような内容を検討・定義します。 - 表5-34 データマネジメントにおける定義内容 | № | 定義内容 | 具体的な内容 | |----|----|----| | 1 | データ管理体制の明確化 | データに関する責任の所在を明確化するため、データの種別毎に管理主体や役割の設定を行い、データ管理の体制を明確化すること。 | | 2 | データの標準化 | データの相互運用性を高めるため、マスターデータ、コード値などの標準化を推進し広範囲で利用できるようにすること。 | | 3 | データに関するドキュメントの一元的管理 | データに関する一元的管理ができるようにするため、データに関する各種設計書等のドキュメントを内容的に独立した構成とすること。 | | 4 | オープンデータ化を容易にする設計 | オープンデータ化の容易性を高めるため、データ取り出しの容易な仕組み設計や機械判読性の高いデータ設計などオープンデータ・バイ・デザインを推進すること。 | | 5 | データに関する運用情報の管理 | システム障害等が発生した際に迅速な原因分析が行えるように、データログ機能を充実させること。また、業務・サービスでの重要なデータやシステムで取得したデータを活用して、BPRや継続的な改善活動が行えるようにすること。 | | 6 | データの機密性定義に応じた設計 | データの機密性に応じたセキュリティを確保するため、データ配置やアクセス管理レベルの実装設計を実施すること。 | | 7 | データ品質の継続的改善 | ・データ品質に起因する障害を極力抑えるため、データ品質の定期的な棚卸と不備・不具合の改善を行うこと。 | - 参考5-13 データマネジメント活動が防ぐデータ関連のトラブル

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

近年、情報システムが管理するデータ量が飛躍的に増大するとともに、データ活用へのニーズも拡大しており、情報システムで行っている「処理」（機能）と「データ」（インプット/アウトプット）の重要性のバランスが変わりつつあります。これまでは処理部分に注目して開発・運用を行う傾向にありましたが、処理部分を精緻化するだけでは品質の良い開発、安定的な運用が困難であり、データを中心とした視点で品質確保と利活用推進を行うプロセスがますます重要になっています。

データマネジメントはこのような状況変化に対応するための重要なプロセスであり、情報システムのライフサイクルにしっかりと組み込むことが大切です。

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

データマネジメント活動を継続的、組織的に行っていくことにより、様々な潜在リスクを低減させることができます。

逆に、データマネジメント活動を実施していないとデータ関連でのトラブルが発生し、大きな社会問題となる可能性があります。過去の事例としても、統計システムでデータ抽出条件を変えたことの影響の考慮漏れで大規模な追加対応が必要となった事例、料金計算で複数のデータ項目間の紐づけミスが原因で多数の顧客に迷惑をかけた事例、データの入力ミスとエラーチェック漏れが重なり大規模な先進的プロジェクトが水泡に帰した事例など、その実例は様々です。

このような大きなトラブルを起こさないように、日常的な活動としてデータマネジメント活動を着実に実施していきましょう。
### テストに関する事項 情報システムのテストには、ソフトウェアの設計に基づいて事業者が行うテストと、発注者及び情報システムの利用者の視点で行うテストが存在します。 テストに関する要件には、実施するテストの内容や方法、環境等を示します。 上記の点に留意し、情報システムの設計・開発等におけるテストについて、テストの種類、目的、内容等を記載します。 - 表5-35 テストに関する要件
No. テスト工程 テストの目的、内容 テスト
環境		 テストデータ テスト
実施主体
1

単体

テスト

 アプリケーションを構成する最小の単位で実施するテストであり、主に機能単位で設計通りに動作するかを事業者（プログラマ）が確認する。 開発
環境		 テスト用に作成したデータ 事業者
（※1）
2

結合

テスト

 複数の機能を連携させて動作を確認するテストであり、主にユースケース単位で設計通りに動作するかをテスト担当者が確認する。 検証
環境		 テスト用に作成したデータ
3

総合

テスト

 システム全体が設計の通りに動作することを確認するテストであり、ユースケースを組み合わせた一連の業務が行えることを機能面や非機能面の観点からテスト担当者が確認する。 検証
環境		 テスト用に作成したデータ、又は本番データから作成した疑似データ
4

受入

テスト

 納品されるシステムが要件通りに動作することを確認するテストであり、発注者が主体となり、事業者と協力して確認する。 検証環境又は本番環境 本番データ、又は本番データから作成した疑似データ 発注者
1. 発注者もテスト計画を確認した上で、事業者に実施状況の報告を求め、報告書に記載されている実施結果に不足、誤り等が発生している場合は、課題等を整理し、指摘又は指導を行います。特に総合テストにおいては、発注者がテストシナリオやテスト評価方法の妥当性を確認し、過不足を指摘することで抜け漏れのないテストになるように関与します。 なお、それぞれのテスト工程の中でも、様々な観点からテストを行います。情報システムの特性により、テストの観点も大きく変わってきますので、それぞれの情報システムに見合ったテストを実施できるように要件を決めることが重要です。テストの観点のほか、各テスト工程におけるテストスケジュール、テスト環境、テストシナリオ等の情報は、事前にテスト計画書やテスト実施要領にまとめます。詳細については、実践ガイドブック「第７章Step.3-3 テストの計画を立てる」に記載しています。要件定義をする際には、ぜひ第７章の記載も読んでみてください。 テストに関する各作業を、誰が行うのか明確に記載する テストには、「テスト項目の作成」「テスト実施環境の準備」「テスト実施」「テスト結果の判定」等、様々な作業が存在します。それぞれの作業を誰がいつまでに行うのか明確にしてください。 - テストを行う上で必要な関係者との連絡調整やその実施者、また、テスト環境の準備や費用負担等、誰が行うのか明確に記載すること。 過剰な要求は避ける テストは、数多く実施すれば品質が上がるというわけではありません。当該テストの目的を踏まえて、必要十分なテスト内容・量を調整してください。 - 事業者に対してテスト環境の過剰な要求は避けること。 - 必要以上に厳密なテスト等の過剰な要求は避けること。 ### 移行に関する事項 移行には、データ移行、システム移行及び業務運用移行の３つの要素があります。大規模な情報システムにおいては、既存の情報システムから新しい情報システムにデータ移行とシステム移行（新情報システム稼働）を行い、一定期間並行稼働させた後に、業務運用移行を行う場合もあります。他方で、中小規模の情報システムにおいては、３要素全ての移行を休日に実施する場合もあります。 いずれの場合においても、業務の安定的な継続が最重要課題であるため、移行の各ステップにおいて状況を評価し、最悪の場合でも既存の情報システムへ切り戻せるような計画と、プロセスの準備を要求しておくことが必要です。 移行元である既存の情報システム、業務、運用について、対象を漏れなく抽出します。抽出に当たり、既存の運用・保守事業者の協力が不可欠となるため、事前に移行調査に必要となる既存事業者の要員確保について調整しておくことが重要です。移行対象の抽出後、移行に際する制限事項を整理します。例えば、月次の締め処理がある業務の場合、「月末の締め処理が完了するまでは移行不可」といった事項を明確にします。 ここでは、移行先への移行手段を詳細に記載する必要はありません。移行手段は設計・開発工程にて詳細化します。 - 表5-36 移行対象データ
No. 移行元 移行対象データ 件数 提供方法 補足
1 ○○申請システム ○○テーブル XX ＣＳＶ形式での提供
2 ○○申請ファイル XX ＣＳＶ形式での提供
3 ○○申請情報 XX ＣＳＶ形式での提供
- 表5-37 移行対象業務
No. 移行元 移行対象業務 件数 提供方法 補足
1 ○○申請システム ○○管理業務 XX 電子媒体
2 ○○登録業務 XX 電子媒体
3 ○○情報業務 XX 電子媒体
- 表5-38 移行対象システム
No. 移行元 移行対象システム 件数 提供方法 補足
1 ○○申請システム ○○管理システム XX 電子媒体
2 ○○登録システム XX 電子媒体
3 ○○情報システム XX 電子媒体
### 引継ぎに関する事項 情報システムの構築及びテストが完了し本番運用に移行する際、又は年度の節目等で事業者や要員が交代する場合、円滑な業務運営を維持するためには、あらかじめ引継ぎ項目を整理し、想定しておくことが重要です。 現在その作業を担当している事業者を「引継ぎ元」と定義し、その事業者が担当している作業を「引継ぎ内容」として明らかにします。基本的には事業者ごとに作業・成果物等を定義した契約が存在しているため、その内容を基に整理すると効率的です。 引継ぎ期間は 1 か月程度を設定するのが一般的ですが、十分ではないケースが多くみられます。引継ぎ期間が十分でない場合には、他の事業者が参入できなかったり、その後の業務運営に支障が生じたりするおそれがあるため、十分な期間を確保することが重要です。 また、事業者が情報システムを構成するソフトウェアのライセンスを保有している場合、事業者が交代する際にソフトウェアライセンスを引継ぎ先の事業者へ譲渡することが必要になります。ソフトウェアライセンスの契約条件によっては譲渡に制約が生じ、引継ぎ先の事業者による運用・保守作業に支障が生じる場合があります。そのため、譲渡可能なソフトウェアライセンスを調達する旨とソフトウェアライセンスの譲渡に関する制約がある場合はその情報を開示する旨を、要件定義書に記載しましょう。落札後 、ソフトウェアライセンスの契約条件を発注者・事業者間で合意した上で、ソフトウェアライセンスを調達しましょう。 事業者間の引継ぎにおける工夫は、「第7章 Step6-2 事例：異なる事業者間で引継ぎをスムーズに行う工夫」をご参照ください。 - 注記 引継ぎ計画書とは、情報システムの引継ぎに係る引継ぎ対象、引継ぎ体制、引継ぎ内容、引継ぎ方法、引継ぎスケジュール、理解度確認方法、完了条件等を記載した受託者が作成する資料のこと - 表5-39 引継ぎ事項
項番 引継ぎ
期間		 引継ぎ先

引継ぎ

内容

引継ぎ

手順

 補足
1

令和〇年

〇月〇日

～

令和〇年

〇日〇月

本システムの運用・保守事業者

（令和X年度後半に調達予定）

  • ソースコード
    (テスト・構成管理・環境構築等に利用するコード含む)開発環境に必要となる各種ツール

  • 各種設計書・ドキュメント類

  • 運用課題（管理簿）

  • 仕様課題（管理簿）

  • インシデント状況（管理簿）

  • 連携業務AP 対応状況
    （管理簿）

  • ヘルプデスク作業

  • 各種運用・保守作業

  • その他納品物一式
    (クラウドサービスの管理に必要なアカウントや鍵情報、またInfrastructure as Code に基づくシステム構築・管理等に係る構成管理ファイル等情報を漏れなく含む)

 受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。
2

令和〇年

〇月〇日

～

令和〇年

〇日〇月

 連携先システムである●●システムのアプリケーション保守事業者 必要となる知識等 受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。
### 教育に関する事項 「教育」とは、情報システムの利用者が、その情報システムの機能を理解し、効率的に運用していくために必要となる、利用者に対する操作研修等を指します。特に官公庁においては人事異動に備え、教育資料や年に数回程の操作研修を実施する等の対応が必要です。 業務要件定義で作成した業務フロー図等を参考に、教育対象者の範囲を定めます。基本的には業務フロー図に表現されている全てのアクター（役割）が、教育対象者の候補となりますが、対象者の役割、所属する組織、場所等を考慮し、教育効果や費用を考慮して教育内容や用いる教材等について要件として示します。 - 表5-40 教育対象者の範囲、教育の方法
No. 教育対象者の範囲

教育の

内容

教育の

実施時期

 教育の方法 教材

教育

対象者数

 補足
1 ○○入力担当者 窓口業務における操作 運営開始前準備時 集合研修：○○研修所 操作手順書 ○名程度
2 ○○決裁者 決裁における操作及び分析 着任時 オンライン研修：各職員が日常使用している端末ＰＣ システム管理者用操作手順書 ○名程度
3 ・・・ ・・・ ・・・ ・・・ ・・・ ・・・
以下の表では、教育に用いる教材等についての要件を示します。 - 表5-41 教材の作成
No. 教材 教材の概要 対象者 補足
1 操作手順書

  • 利用者区分ごとに操作手順書の内容を分割するなど、利用しやすいように工夫すること

  • 個々の業務に沿った画面の流れを中心に作成すること

 ○○入力担当者
2 システム管理者用操作手順書

  • 管理者権限のみが操作可能な機能に特化したシステム管理用操作手順書を作成すること

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

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

（従来のデータセンター利用等の案件の場合）

  • 重要データのバックアップは、週に○○回行い、△△世代保管すること。また、バックアップに用いる記憶媒体は受注者が負担すること。本情報システムのバックアップ用記憶媒体の種類は□□であり、一回のバックアップで約●●GB 必要とする。

（クラウドサービスを利用する場合）

  • 重要データのバックアップは、週に○○回行い、△△世代保管すること。なお、バックアップの取得については、クラウドサービス提供者から提供されるバックアップサービスを利用して差し支えない。ただし、適用するサービスの種類、同時被災しないことを前提としたバックアップサイトの場所、バックアップデータの取得時期及び保持期間（世代管理を含む。）、自動化の程度等については、対象とするデータの性質等に応じて、業務に影響を与えず、かつ費用対効果が高いものを適宜選定すること。
情報システムをリリースした後、実際に運用業務に必要となる作業は、標準ガイドライン解説書「第３編第９章２．解説（１）ア運用業務　表9-1」で示す事項になりますが、要件定義では、これら具体的な作業を設計するための方針を示します。 - **運転管理・監視等要件\** コンピュータで行う処理と運用管理者等で行う処理の切り分け、情報システムの運用を行う時間、内容、手法、連絡等について記載します。記載に当たっては、保守要件との責任分界を考慮し、作業の抜け漏れ、重複等がないように定義する必要があります。特に、情報システムの障害発生箇所の切り分け、発生原因の追究と解消について、アプリケーションプログラム、ソフトウェア製品、ハードウェアそれぞれの保守事業者と連携し、単体では発生しない障害についても監視、切り分け、復旧が可能となるよう留意してください。 また、障害発生を検知した際に、障害対策の原因究明を行うために十分な情報をログ等として確実に記録したり、情報システムを継続的に運用する中で性能劣化が起きないよう定期的な測定と改善活動を行ったりするように留意してください。 - **運用サポート業務\** 業務の実施に必要な体制以外に、情報システム利用者からの問合せ対応や操作研修等の運用サポート体制が必要となる場合は、その内容を記載します。 - **業務運用支援\** 情報システムの稼働に当たり、業務実施部門が行う業務の運用支援作業について記載します。 ### 保守に関する事項 「保守」と「改修」の違いが混同されてしまうケースがよくありますが、機能要件に変更を加えずにプログラム修正のみを行うことが「保守」、機能改善を目的としたプログラム修正作業が「改修」です。保守は「機能要件を変えずにプログラム修正する」という特徴があるため、現状の各種ドキュメントを正しく管理することが重要です。 アプリケーションやインフラの作業に着目しがちですが、ドキュメントの保守という観点を忘れないようにしてください。 保守作業には大別すると以下に示す４種類があります。 - 表5-42 保守作業の種類 | 種類 | 内容 | |----|----| | 是正保守 | ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正 | | 予防保守 | 引渡し後のソフトウェア製品の潜在的な障害を運用障害になる前に発見し、是正を行うための修正 | | 適応保守 | 引渡し後、変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正 | | 完全化保守 | 引渡し後のソフトウェア製品の性能又は保守性を改善するための修正 | なお、アプリケーションプログラム及びソフトウェア製品の保守要件については、表5－42を踏まえ、訂正に係る保守（是正保守、予防保守）と改良に係る保守（適応保守、完全化保守）を区別して検討します。 - **アプリケーションプログラムの保守要件\** 情報セキュリティに関する脆弱性の修正や不具合等の確認及び修正、小規模な改修等の対応範囲や条件を記載します。記載に当たっては、情報システムの機能改修に相当する作業を含まないように留意してください。 - **ハードウェアの保守要件\** 不具合の修理等の対応範囲や条件を記載します。 - **ソフトウェア製品の保守要件\** 情報セキュリティに関する脆弱性の修正や不具合への対応（パッチの提供）、小規模な改善等を目的とするリビジョンアップや大幅な改修を伴うバージョンアップ等の対応範囲や条件を記載します。 ソフトウェアの修正・不具合への対応や機能追加等のバージョンアップについては、業務や他の情報システムとの連携に影響を及ぼす場合もあるため、適用前に必ず影響を調査し、総合的に検討を行った上で実施の是非を判断する必要があります。例えば、脆弱性や不具合に対するパッチを適用する場合は、適用した場合の業務への影響や適用しなかった場合のリスク評価等を実施した上で、パッチ適用の是非を判断します。また、新たな機能の追加が行われる場合も、追加した場合と追加しなかった場合それぞれのメリット・デメリットを比較するなどした上で、追加の是非を判断する必要があります。 なお、クラウドサービスのバージョンアップの方法はサービスごとに異なり、自動で適用されるものもあれば、自動で適用されないものもあります。利用するクラウドサービスのバージョンアップの方法を確認した上で、バージョンアップの情報を漏れなく把握し、適用前には必ず影響調査等を実施するように留意してください。 - **データの保守要件\** 情報システムの設定データやマスタデータの更新作業等に関する要件を記載します。 - **保守実績の評価と改善\** 情報システムの安定的な運用の維持と継続的な改善のために必要となる保守実績の評価、改善活動について記載します。 ## システム方式を決定する 【標準ガイドライン関連箇所：第３編第５章第２節1)エ】 「1-B. システム方式に関する事項」で検討した内容を他の要件の内容と調整し、情報システムの実現案として決定します。機能要件と非機能要件を定義することで、情報システムの全体像が明らかになっていきますが、それを実現するためのハードウェア・ソフトウェアや機能等の構成は必ずしも１つではありません。クラウドサービスを活用した案や独自にハードウェアから用意する案、また、サーバと配置する機能の組合せ等、複数の構成案があります。これらの比較検討を行い、事業者からの提案・見積りを踏まえ、最適な方式を選択する必要があります。 このため、システム方式として選択可能な方式を、複数案取りまとめます。伝達のしやすさを考慮し、図表形式で取りまとめることも有効です。 また、システム方式によって、要件を実現するための難易度が異なることがあるため、要件の優先順位も併せて検討します。