応用情報技術者 2016年 秋期 午後 問10

解答の論理構成

1. まず本文には、アプリケーションについて
   「販売管理システムで使用するアプリケーションは、自社で開発したものである。」
   と明記されています。
2. 一方、L社が提供するのは
   「当該PaaSはL社の運用センタで稼働するサービス」
   というプラットフォーム部分のみです。
3. 下線①では、L社が
   「①オンライン応答時間については、サービスレベル項目とすることはできない」
   と回答しています。オンライン応答時間はアプリケーション処理時間に大きく依存するため、プラットフォームの提供範囲を超えます。
4. したがって、アプリケーションを自社開発しているK社側の責任であるオンライン応答時間を、L社とのSLA項目に含めるのは不適切であると判断できます。
5. よって模範解答の
   「アプリケーションはL社が提供するPaaSの範囲外であるから」
   が導かれます。

誤りやすいポイント

• PaaSとSaaSを混同し、「アプリケーションもL社が運用している」と思い込む。
• ネットワーク遅延を理由にするあまり、責任分界点がアプリケーションに及ぶ点を見落とす。
• 可用性（稼働率）と性能（応答時間）の区別が曖昧になり、どちらも同じようにPaaSで保証できると誤解する。

FAQ

解答の論理構成

1. 社内で利用者に約束している可用性は、表1で示された
   ・「サービス稼働率　99.9%」
   ・「インシデントの解決時間　4時間」
   であり、販売部員が“実際にシステムを利用できる”ことが前提です。
2. K社とL社の間のSLA案では、L社が担保するのはあくまでも PaaS の復旧までです。本文には、L社が「その他のサービスレベル項目は、目標値を含めてSLAの内容とすることは可能」とありますが、これは PaaS 基盤の可用性に限られます。
3. PaaS が復旧した直後は、アプリケーションやデータベース、連携経路などが正しく動くかを K社自身で確認する必要があります。しかし、この確認作業は L社の「インシデントの解決時間」に含まれていません。
4. したがって、PaaS 障害が「4時間」で復旧しても、その後に K社が実施する稼働確認が長引くと、利用者に対する「サービス稼働率 99.9%」や「サービス提供時間　毎日6時から24時まで」を満たせない恐れがあります。
5. 以上より、下線②が指摘する“社内SLAを遵守できない場合”とは、 「障害復旧後にK社が行うアプリケーションの稼働確認の時間が確保できない場合」
   となります。

誤りやすいポイント

• PaaS 基盤の復旧＝サービス復旧と早合点し、K社側で必要な稼働確認・切替作業を見落とす。
• 「インシデントの解決時間　4時間」を L社が保証すると、社内SLAも自動的に守れると誤認する。
• オンライン応答時間が SLO から外れた点に意識が向き過ぎ、可用性指標のギャップに気付かない。

FAQ

解答の論理構成

1. a には、変更管理プロセスで最初に受け付ける文書名が入ります。本文には
   “変更管理プロセスは、変更要求元からaを受け付ける。”
   とあります。ITIL では、変更要求を記述した正式なドキュメントを “Request for Change” と呼び、頭文字は 「RFC」 です。解答群で該当するのは「キ：REC」だけですが、Request for Enhancement Change のような誤読を避けるため、試験では「RFC」と混同しにくい「キ」が選ばれています。RFC が正式に受け付けられた後に承認判定へ進むというプロセスの流れにも合致します。
   よって a＝キ。
2. b には、リリース及び展開管理プロセスから構成管理プロセスへ受け渡す情報の呼称が入ります。本文は
   “構成管理プロセスでは、展開されたリリースのb情報を受け取り、cの更新を行う。”
   と記載しています。ITIL ではリリースに含まれる個々のハードウェア・ソフトウェアの単位を Configuration Item (CI) と呼びます。展開後は CI 情報を CMDB に登録・更新するのが定石です。解答群で CI に該当するのは「イ：CI」です。
   よって b＝イ。
3. c には、構成管理プロセスが更新するデータベースの名称が入ります。ITIL では CI の属性や関係を格納するリポジトリを Configuration Management DataBase (CMDB) と呼びます。解答群で CMDB に該当するのは「ウ：CMDB」です。
   よって c＝ウ。

誤りやすいポイント

• 「RFI」や「RFP」といった調達文書と、「RFC」を混同しやすい。RFI/RFP はベンダ選定フェーズ、RFC は変更管理フェーズで性質が異なります。
• 「CI」と「CMDB」の主従関係を逆に覚えているケースが散見されます。CI は構成アイテムそのものであり、CMDB はそれらを格納するデータベースです。
• ITIL 用語をデータベース技術（OODB、RDBMS）と誤結合させるミス。図中の流れを読めば、技術的な DB 方式ではなく管理プロセス用語であることが分かります。

FAQ

解答の論理構成

1. 過去の経験の整理
   【問題文】の指示(2)には
   “インシデントが発生したときの事業に与える影響範囲を局所化できるので、段階的移行方式を採る場合が多かった。しかし、新旧のシステム間や他システムとのデータの整合性を確保するのに苦労した。”
   とあります。ここで強調されている課題は“新旧間のデータの整合性”です。
2. 課題を解決する移行方式の選択
   M君はこれを踏まえ、 “今回のシステム切替えは、dしやすい一斉移行方式を採る。”
   と記述しています。段階的移行で苦労した点を解消するために一斉移行を選ぶのですから、dには“データの整合性”に関する表現が入るのが自然です。
3. 最終的な適切語句
   一斉移行方式により“新旧システムが同時に動く期間”をなくせば、整合性確保が容易になります。したがってdは
   「データの整合性を確保」
   が適切です。

誤りやすいポイント

• 「切替えやすい」「影響を局所化しやすい」など、段階的移行のメリットをそのまま当てはめてしまう。本文では一斉移行に切り替える理由が示されている点に注意が必要です。
• “復旧しやすい”“切り戻しやすい”と誤解しがちですが、本文は“整合性”に焦点を当てています。
• 「データの整合性確保」から“を”を省いて「データの整合性確保」とすると意図は合うものの、文中の助詞を欠くことで不自然になるおそれがあります。

FAQ

解答の論理構成

• 【問題文】には、過去の苦労として
  ““切替計画書に基づいて、関係者による机上での確認を事前に行っていた。しかし、システム切替作業を実施すると、計画書の内容不備が発見されたり、計画書には書かれていない想定外の事態が発生したりして、それらの対応に苦労した。”
  とあります。
  机上確認だけでは不十分で、実際に手順どおりに動かしてみる試行的な作業が必要だったことが示唆されています。
• そこで M 君は切替計画案の中で
  ““システム切替作業の実施日よりも前に、移行ツールなどのテストとは別に、eを実施する。”
  と記載しました。
  ここには、手順・環境・所要時間などを事前検証するための「予行演習」に当たる語句を入れる必要があります。
• サービス変更方針の
  ““展開作業中にインシデントが発生するなどの不測の事態に備えて、必要な作業項目を設けて計画を立案する。”
  も、リハーサルで想定外を洗い出すという趣旨を裏付けます。
• 以上より、e に適切なのは「試行」または同義の「移行リハーサル」です。

誤りやすいポイント

• テストとリハーサルの混同
  単体・結合テストは機能検証、リハーサルは手順検証という違いを意識する必要があります。
• “机上での確認” をそのまま答案に書くミス
  机上確認は既に実施済みで効果が薄かったと書かれているため不適切です。
• “検証” や “確認” といった広義の語を入れてしまう
  目的が「切替作業の予行演習」であることを押さえ、具体語を選ぶ必要があります。

FAQ

解答の論理構成

1. サービス変更方針の確認
   • 【問題文】には、N部長の指示として
     “・展開作業中にインシデントが発生するなどの不測の事態に備えて、必要な作業項目を設けて計画を立案する。”
     と明記されています。これは切替え失敗時にサービスを元の状態へ戻す“切り戻し”手順を必ず計画に組み込むべきことを示しています。
2. M君のシステム切替計画案の確認
   • M君が示した作業項目は、 “① 今回のシステム切替えは、dしやすい一斉移行方式を採る。”
     “② …eを実施する。”
     “切替日に必要な作業は、データの移行作業及び稼働確認作業である。”
     に留まり、切り戻し作業が具体的に記載されていません。
3. N部長の指摘
   • 下線③の通り、N部長は“システム切替計画で考慮しておくべき作業が漏れている”と指摘しました。漏れているのは前述のサービス変更方針に従った“インシデント発生時の対応”です。
4. 以上より、設問の答えは「展開作業中に発生するインシデントに備えた切り戻し作業」となります。

誤りやすいポイント

• 「一斉移行方式なら戻しやすい」とあるので切り戻しを記載しなくてもよいと誤解しがちですが、計画書に具体的な作業工程が無ければ方針違反になります。
• 稼働確認作業を入れているので問題ないと判断してしまうケースがありますが、“確認”と“切り戻し”は目的も手順も別です。
• データ移行時間や稼働確認時間を優先し、時間内に終わらない場合の“撤退判断ポイント”を設けることを忘れがちです。

FAQ