平成26年度秋期・午後1 問１設問4

さて、設問4も問われている章「応答性能確保に向けた方策の検討」内で主語述語抜粋です。

「設定では余裕があり」　「来店客数が想定通り」　「応答性能を（が）実現できる」
「CPU使用率が上昇」　「実施が決定」　「業務量が増加」　「CPU使用率が基準値超え」
「応答性能が悪化」　「H氏は増強することにした」　「増強には掛かる」
「H氏は（暫定対策を）策定した」　「H氏が実施」　

となり、今度は、H氏は応答性能対策案を実施したようです。
しかもCPU使用率を監視の判断基準にしているような感じまではこれだけでもわかります。

さて問題ですが、サービス運用段階でモニタリンできる監視項目とありますね。
その前に、これもサービスレベル目標で販売支援サービスの応答関連の明記に着目です。

表1サービスレベル目標にはこう書かれています。
応答性能時間：５秒以内

つまり５秒以上かかってしまうと”問題”となるようです。
ただ、応答が５秒以上かかってるかをモニタリングするというのはなかなか大変です。
しかも、問われている回答内容は、サービス運用段階の監視項目と書かれているため、
レスポンス時間というのではなく、もっと具体的なレスポンスを測る項目だとイメージする
必要があるようです。
すなわち、文章にはCPU使用率が上昇したら悪化の兆候とみなすようなのですが、
どのサーバのCPUの事かという事で、APサーバ②と書かれています。

そんなわけで「APサーバ②のCPU使用率」を監視項目にすべきです。
回答は監視項目を求められているので、使用率の上昇とか、余計なものを書かぬよう注意です。

で、次に問われているのは、”暫定対策実施の判断方法”と”しきい値”ですが、
まず、対策を実施すべきと判断する方法は何かという事です。

当然、しきい値を超えたときに対策は発動されるのですが、着目すべき可視化イメージは、
例えば、基準値を策定した通りの監視を行い、それが超えた時に間に合えばよいのですが、
書いているように、セールス時期はそうはいかないと予想されます。
セールスにもかかわらず通常の基準値のままであった場合、超えたと判断してから
対応が間に合わない事態をひきおこすのではと危惧している状態をイメージです。

つまり、基準値とは別に新たにしきい値を設定するというのはこの事ではないかと予想されます。
要するに２段階の警告ラインをしきい値として設定しておくのです。
最初は一段階で対策の準備もしくは対策にとりかかるわけです。

また問われているのは、”暫定対策実施の判断方法”なので、基準値超えの前に対応ができる余裕があるもう一つの別のしきい値を設け、特にセール開催時にそのしきい値が超えたかの有無を
判断する。

という事です。
以上で、問１の全設問の可視化を実施してみました。

平成26年度秋期・午後1 問１設問3

さて、問3も前回同様、主語と述語だけで問われている章内で抜粋してみる。

問3の問われている章は、『バックアップ方式の検討』である。

「H氏は着手した」　「ストレージ機が故障した」　「復旧に（は）40分」　「回復作業に（は）20分」
「販売情報集計レコードが格納され」　「変動はある」　「データ量は一定」
「H氏は策定した」　

となり、ストレージ機器が故障した時の障害対策としてバックアップを考えた模様です。
で、問題にもなる、２案のバックアップ方式おどちらを採用するか？となるようです。

２案とはバックアップ方式の異なる内容のようです。
何が違うのかを表からイメージする必要がありますがこの場合主語述語では不明なので、
やはりバックアップの違いとなるサイクルなどを読み解く必要がありますが、そもそも、
採用する決め手は何かという事を知らないと意味を理解しても無意味なのは当然です（苦笑）

なので、
どうだったら採用されるかを可視化イメージできないか考えてみます。
バックアップ方式はフルバックと、増分（差分）バックの２種類のようです。

そｍそもフルは時間がかかるイメージがあるので、最初にフルバックしたら、あとは差分
バックアップで変わった部分だけを取得すればバックアップ時間は短いという事ですが、
表からそのあたりの違いを実際の時間から算出しておく事が必要のようですが、
やはり最初のなにが採用基準か？の要件を探す必要があるのです。

はい、お客の要件を示すものといえばなんでしょうか？
やはりお客との信頼を得るための規約、SLAを浮かべる必要があると思うのです。
それを記載しているものが、示されている章よりも最初の表にあるサービスレベル目標
となるわけです。

なので、問題のアプローチというと、今回は可視化の視点が、バックアップ案を採用される
ためにはどうであれば良いのかを知る必要があり、それがサービスレベル目標にあるのだ
とできるだけ早くイメージする必要がある用です。

視点でいうと、
「問3の表４　情報検索DB群のバックアップ方式案」⇒「表１　サービスレベル目標」
となるのではと思います。

可視化イメージは、H氏がバックアップ方式案を２案考えて、どれを採用すべきかと
思いながら、そういえば、サービスレベル目標があったはずだから、営業に聞いて
資料もらうか！！などという場面が僕の職場だったら、そんな感じですね（苦笑）

で、そのサービスレベル目標の中の情報検索サービスのバックアップに関する要件は、
う～ん、、、そういうキーワードは特にないのです。
ただ、お客から考えればバックアップするのは何のためかという視点で考えれば、
もちろん障害時に元の状態（この場合障害が起きる直前が望ましいですが）に戻る、
つまりリストア、復元などのキーワードでどうあるべきか書かれている箇所あります。

それは・・・以下です。
サービス回復時間：２時間以内（障害発生検知からサービス回復まで）　

そうなると、表4の関係するのはバックアップというよりもリストアだとなります。
リストア時間が２時間以内で、どちらかの一番早いほうが採用だと予想されます。
その観点で表4の箇所を見ます。
案１は、最新（1時の最終段階）のフルバックからリストアして４０分。
案2は、最新（といっても日曜時点）のフルバックからリストア４０分かけて、その後増分に1回５分。


そうなると、どう考えても案1の方が早くリカバリできるというわけです。
しかも案2の場合は、障害がおこった日が日曜～土曜でリカバリ時間が増分分で余分にかかるという欠点があり、案1はいつであろうと時間は変わりません。ゆえに完璧に案2不採用です。

という事で、案1を採用した理由が次に問われていますので、案1視点でいえばサービスレベル目標に書かれている時間内で最も早く一定時間でリストア（回復）できるというのが理由で、案2視点では、案1に比べてサービスレベル目標の時間内に回復できたとしても、障害が起きた曜日で不安定に変わるという点が宜しくないというわけです。

という事で、本問はこの辺で。

平成26年度秋期・午後1 問１設問2

さて、設問１からずいぶんな日数を費やしてしまっているのは勘弁願うとして（っていいながら遅れた原因をスルーして傷に触れないようにしてるのですが（苦笑））、まぁ、と、とにかく、設問2です。

設問2もそうなのですが、情報処理の午後の問題は、必ず長文の中のどの章（chapter）のことを問いにしてるかと親切？にも明示している点は見逃してはいけないと思います。
え？そんなのわかってるって？　　　へ、へぇ～すごいねぇ（苦笑）

・・・と、いうわけで（え？どういうわけ？）、とにかく章だけをまず可視化してみようと思うのです。

で、考えたのですが、そそも可視化とは、頭にその光景が浮かんでくるようになるのが最終目的、
そう、Goalだと思うのですが、そうなるためのステップはなんだろうと考えてみました。

頭に浮かんでくる光景というのは、文章からその様子がビジュアル化させるという事ではと思うわけです。
さぁでは早速（という程早くもないですが（苦笑））試してみようと思います。

という事で、設問2の章は、「サービスの可溶性を考慮した構成検討」とあります。
問題はともかくまずは、問題を読んで光景を浮かべるわけです。

そこでさらに思うのですが、光景を思い浮かべるためにはどうすればよいか？です。
ちょっと先に書いた章を読んでみると、気になる点がありました。
それは、主語と述語、つまり、なになに（誰々）は（が）、どうした（どうなった）。という箇所です。

余計な修飾や形容を省いて主語と述語だけ抜粋してみます。

『保守員が常駐』　『（保守員が）復旧』　『部品は常備』　『H氏は、検討を行った』
『機器は切り替え』　『サービスを継続』　『故障が発生しない』　『H氏は、まとめた』
『ルータ及びSWは、サービス回復となる』　『WebサービスおよびAPサーバは15分必要』
『（お得意様割引）機能は、割引を適用』　『H氏は見直す』

どうでしたか？・・・え？それがどうしたって？
・・・・はい、では僕なりに考えたことを発表しますと、（って大袈裟ですが（苦笑））

主語は文章に出てくる登場人物で、術後はその人たちが行ったアクションですけど、それだけで詳細はようわからんがなんかやってるくらいのイメージがつかめるんじゃないのかなと思うわけです。

例えば、最初の『保守員が常駐』というのは、文字通り、保守員がどこかの場所に常駐しているというのはわかるわけです。
で、何の部品かわからんけど常備されていて、H氏が何かを検討し、その結果、機器を切り替えてサービス継続できる。という事で故障が発生しないという検討結果をH氏はまとめた。
という章の前半となり、これはよくわからないが、保守員が常駐して復旧している様子と、その現状をH氏は検討して検討結果を表にまとめたという事くらいは何となく予想がつくかなと思います。

その様子が頭に浮かべばこの章の問題の前半の可視化はできたのではと勝手に思うわけです。

ところが！！
肝心の問題ですが、そのH氏がまとめた表の空欄になった部分を埋めるというもの。
どう埋めればよいかというのは、冗長化の有無で決めると書かれているんですが・・・
この回答は無情にも、乱暴な事を書くとしたら、問題とは全く関係ない観点で正答できるという、
人によってはサービス問題でもあり、ある人にとっては意地悪な問題なんです。

つまり、この回答は、機器の冗長化が必要な原因は何かを一般論で考えれば自明です。
まぁいわば、冗長化しなければいけない状態は通常はデータもしくは２台で冗長化（クラスタ？）
しようとした場合、救う必要があるデータ状態が変わっている場合かと思います。

はい、つまり更新系と参照系のデータのどっちのサービスか？がわかればよいわけです。
参照系はデータが変わるわけでないので、むしろ冗長化不要で×、
更新系はその逆でデータが変わってしまうため、冗長化は必要で○です。
で、その問題では、販売支援がaで、情報検索はbというわけですが、どちらのAPサーバで
どのデータかを調べると、aは更新系でbが参照系であると判明するわけです。

そこまでわかれば、aは○、bは×となるわけです。

という感じで可視化は本門とは無関係でしたがこうやってイメージトレーニング、
略してイメトレ（笑）していければよいかもと思うわけで、まずはここまで。
では、また。

平成26年度秋期・午後1 問１設問１

プロローグをいいペースで書いたにもかかわらず、なんだかいつの間にかそろそろ8月になってしまうなんて、時は無情にも過ぎ去ると感じてしまったので、タイトル通り、H26年度の午後1の問1について、しかも可視化をイメージできるような問題文の読み取り方というものが果たしてできるのか？できるとしたら、どういった読み方をすべきなのかを考えてみようと思います。

とはいっても、そもそも可視化を目指したアプローチなんて偉そうなこと言って、本当にうまくいくのか?などと大半の人は思っているに違いない！いやその通りなのですが（苦笑）、実際にそう思ったとしてもそこから可視化イメージ手法の考察しようとしないのはなんか僕にとっては、違反な行為なんじゃないのかと思うわけです。

え？能書きは良いから早く可視化手法を教えろって？
そ、そうですよね？え、え～と、、、、ではゆる～りと参りますかねぇ。

■H26年度の午後1の可視化の考察
さて、この問題だけとは限らないのですが、可視化をするのには、

Information Technology Infrastructure Library通称、ITILの流れの理解が必要であるというような事をプロローグで書いたと思いますが、問題がこの流れのどの部分かをイメージする事ができるかを知る必要があるのです。

ITILの流れとは、どういうものでしょうか？

これは以前記録のブログイメージである、2015年7月現在、ITIL2011かなと思われます。
この時も下手な絵を描きながら問題文を理解しようとしていましたが、ここまででなくても
問題文の読みをこのようなイメージで頭の中を可視化出来たら良いのになと思うのです。

まず可視化のポイントは何だろうかと考えてみます。
確かにITILの流れですが、それだけでは全体しかイメージがつかめないと思うのです。
そこで、一端、ITサービスマネージャ（以下ITSM)の根本的な事を考えます。
一体、ITSMとは何をするのかという事です。
当然、必要不可欠な役割を担っているに違いないのですが、そもそも何をするかを理解しないと、問題文中では、ITSMとしてこのような場合はどう対処すべきか?といった問いかけがあるからです。
つまり、問題の主人公は当然ITSM（あなた？、え？僕か（苦笑））であり、問題が解決したとされる事は、お客様のサービス（システム）を安心に使う、使えるようになった事という表面上はそうかもしれませんが、究極はお客様が納得して満足している状態を持続し続けるという事です。

といっても、間違ってはいけないのは、現状のサービス（システム）に納得しないお客様のことではなく、現状のシステム機能の範囲内で合意された内容で稼働して使える状態であるという事です。

ITSMはそのような状態になるため、ならない場合の調整役であり、うまく機能させる原因があり、それを見つけて解決させる役割であると考えます。
そしてITILはそのサービス（システム）をだけでなく、顧客満足度も併せて持続させるためのドキュメントライブラリであり、これらを活用させるノウハウを習得していると有利なのです。
当然、これら各ITILのプロセス中には人の動き、やり取りが必要不可欠であるため、可視化には、
流れの中で人の動きがイメージされるべきと考えるのです。

お、なんかちょっとイメージが湧いたかも（苦笑）
・・・という事で、問1の可視化をやって見ようかと思います。

恐らく最初は、到底このテンポでは2問90分での１問あたりの試験時間40分～45分などはイメージ化してるうちに、あっ！・・・という間に過ぎ去るであろうと思われますので、慣れるための訓練や、速度アップのためのさらなる工夫は必要かもしれません。

可視化には、問題で話題になってる点はなんなのか？その話題でITSMはどう関わるのか?
サービスの目的、問題での中心となる機能はなんなのかを読み取る事かもしれません。
さぁて、どぅなることやら（苦笑）

■問題１・設問1を可視化してみる。
まず、問題冒頭には、ITサービスの設計に関する・・・と書かれています。
どんなサービスかというと、家電量販店の販売サービス（システム）の拡大によるサービス再構築。
IT設計の目的とは、サービス拡大に伴う新規ITサービス設計を行う事がミッションの模様です。

ミッションが判明したら、問題文を先に読んでみます。
設問1：サーバ構成設計が障害時によろしくない理由を求められています。

可視化では、今回考えたサーバ構成において、店舗でインシデント発生した時に動く人を可視化すればよいのかなと考えます。
そのために登場人物はだれかという事ですが、まずはすでにインシデントが起きた後での人物の動きであるため、まずは作業状態としては、やはり店舗内でシステム障害が発生したという知らせを受けたX社の情報システム部が復旧しようと情報システム部サーバルーム内の確認端末を使おうとしている。といった場面でしょうか?

どうです？頭に浮かびましたか?
可視化はもしかしたら、絵よりもドラマ仕立ての方がいいかもしれません。という事で実際にやってみます。

例えば・・・今電話が鳴ったとします。
・・・ぷるるるるるるる・・・

情シス部員：『・・・はい、情報システム部です。』
A支店店員：『あ、もしもし！情報部ですか?こちらA支店ですが、、、』
情シス部員：『はい、、、どうされました？』
A支店店員：『え～、うちの販売システムが停まったみたいで画面が固まりました。助けてください』
情シス部員：『かしこまりました。一応お伺いしますが、固まった後でPC再起動等行いましたか？』
A支店店員：『はい、それやったんですが、今度はシステム起動しなくなったようです。』
情シス部員：『かしこまりました。ではこちらで調査し分かり次第至急折り返し連絡します』

A支店店員：『はい、よろしくお願いします。』

って感じで、一見進行的にはいい感じで進んで、この後、情シス部AさんとBさんが部内のサーバルームに移動して上司のAさんがBさんに調査の依頼をしますが、Bさんの様子が変です。

情シス部員B：『Aさん、ちょっとすいません。』

情シス部員A：『ん？どうしました？』
情シス部員B：『こちらからは問題なく接続できているのですが？』

情シス部員A：『え？そうなの？・・・・それじゃあ現象が再現しないって事?』

情シス部員B：『はい、そ、そうなります・・・ねぇ、ど、どうしましょう』

情シス部員A：『サーバルーム内で検証するんじゃなく直接A支店に行くしかないな（溜息）』

という風になって、まぁこの困った状態が結局解答となるわけですね（苦笑）

でも、もしかしたら事象はA支店だけでなくB支店も同様だとしたら、これだけでも解決しません。

つまり、設問とは無関係ですがどうだったら良い構成と言えるのでしょうか?

今回のポイントは障害時と同じ現象の再現のでる端末で検証できるか？だと思います。

したがって、理想は、サーバと同じNW内だけでなくNW外の各店舗内にも検証端末、または

それに相当する検証端末が存在し、リモートで情シス内のサーバルームから乗り入れて、

検証できるような状態であれば、Aさんは現象の再現を確認できるだけでなく他の店舗でも同じ現象が出ていないか？などの障害切り分けが可能となるのではないかと思うのです。

という事で、設問1の、店舗でインシデントが発生したとき。という部分を少しドラマ?小説？風にしてみたのですが、ドラマで事件イメージが頭に浮かんで可視化されませんでしたか？（苦笑）

以上、まずは設問1の可視化という事で、記録です。
次回は設問2の可視化に続く・・・

プロローグ・可視化へのアプローチ構想

■プロローグ
さぁて、今回からゆるぅりと、始まる事になりました、この企画（なのか？（笑））
まずは、今回のポイントとなる、”可視化”というキーワードにこだわった理由ですが、
実は恥ずかしながら、結構な回数の受験経験だけはこなしている（って全く自慢でないですが）
僕が最近思ったのは、高度情報試験の午後１の長文読解について、僕はいまだに苦手です。
というか、年を追う毎に読みながら頭に入れていく動作が億劫になってきてしまっている始末。

まぁなんというか、それって老化というのも否定できない深刻な事態が蝕んでいるのかもしれない。
しかしです！といっても、ここで起死回生の一発のような奇想天外のアイデアなどは出ない（苦笑）
ですが（なんや出ぇへんのかいな（笑））、文章読んで頭に入れて問題に答えてゆく・・・という、
一見当たり前でしょ的な動作と思ったのが、実際はもうそんな事やってる場合じゃなくて、
クラシック、古風、古臭い（笑）時代錯誤的な方法だとしたら（などといってもこれはただの妄想、
もとい構想という事なんですが（苦笑））面白いかなと思いながら、どうせなら今までの過去問で
そのような発想ができないかって考えたところから始まったという訳です（はぁ～あ）

で、その考え、つまり、読んで記憶に格納じゃなくて、読んだものを視覚として脳にインプットする
といった感じになるためのアプローチ手法というものを考えればいいなぁって思いました。
で、それが、ITSMの視覚化、可視化となるわけなんです。

さて、本当にそんな事が出来るのでしょうか?・・・そうなんですよねぇ（苦笑）

■アプローチのための可視化について
一口に過去問を可視化と言っても、問題とそぐあわなければ、やっても無駄って思いますよね?
それは確かに僕もそう思います。
なので、問題とそこに関連した文章をペアとして、そのペアを視覚化してみたら？と思いました。
え？何を言ってんじゃい！この妄想野郎！！って？・・・さ～せん（苦笑）

■可視化のペアリング
先述した通り、ペアが問題文と関連個所について、これだけだと回答、解答がねぇんじゃん！！
などと今更ながらのクレーマというのを避けるため、当然、解答交えた３つ巴で可視化を目指そう
かなと思うわけです。
え？いっこもわからへんぞ（ってなぜ関西弁？）って？
はいっ！！そう思うのは当然なのですが、それではイメージを考えてみようかと思います。
つまり、僕が考えるのは、やはり、ITサービスマネージャの仕事を語るためには、ITILなしでは
無理なんだろうなと思うのです。

ちなみに、ITILと一口に言っても微妙にITIL はV2からV3、2011 Editionへと進化したりしてます。

で、そのITILには、サービスデスク、インシデント管理、問題管理、変更管理、そして、リリース管理といった流れ作業のような各セクションがあり、そのセクションにおいて、守るべきもの、
たとえば、サービスレベル、可用性、キャパシティ、財務管理、そして継続性管理などです。

つまり、これらの各セクションの守るべきもののどれかが問題になり、解答を求められているのではと思うのです。
つまり、過去問のこの部分は、このセクションでのこの守るべきものを重視しているんだと、本能的に、脳の中で可視化イメージが湧いたら凄いんじゃないかなと思ったわけです。

そのためには、今のITIL2011Editionにおける各セクションの守るべきものを可視化すべきです。
僕が前回（といっても1年前）記録のブログで書いたイメージでも良いのですが、どうせなら
もちょっと、ビジュアルを意識して絵心の無い僕ではありますが頑張ってみようかと（苦笑）。

とまぁそんなわけで次回から唐突に過去の問題別の可視化によるアプローチやって見ます。
え？いつの過去問かって？
そうですねぇ～、前回とかぶらない年の、最終年度といえば、、、はい！そ、そうなんです（笑）
『H２６年度秋期試験』からやってみますかねぇ。

という事で、プロローグなんで、一応ここまで。
次回はもちっと、問題を可視化、いわゆるビジュアル化できないかの考察をしようかと。
でわ。