僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編４）！！ H24/問３・設問3を振り返って・・・

さて、H24/問3の設問３の題意を考えてみようと思います。

◆といながら・・・例によってプロローグ

まず今回、前回書いたように設計の甘さが障害を招いたのですが、本当にこういう時いつも思うのが、

設計品質の悪いのは、設計した人（ITサービスマネージャ）だけではないという事です。

設計作成には、（通常は）レビューがあり、さらに運用系のテストであればお客側も混ざってくると思います。でも、にもかかわらず、テストデータが昔の考え方に沿って作られた。というのとかは、完全に人任せとしか言えないような状況だなぁと感じました。
まぁそういう事でもさせない限り問題にもならないんでしょうが。。。
もしかしたらそういう観点で文章を読めば、あぁこの考え方とかはきっと後で大変なことになるんだろうな的な”当たり”をつける事で役立つかもしれません。

いずれにしろ、この障害が起こったことの原因とヘルプデスクの障害対応遅延というところが次の焦点のようです。

◆設問３

ここでの問題は、以下の2つでした
①サービス利用量が最大になる時間帯に処理遅延

→負荷テストがNGデータ使用したからでは？という考えになるのは自明ですので、それを簡潔に書く。という事のようですね。

②障害時のサポート対応に時間を要する

→該当のチャプター部分の冒頭で、ヘルプデスクに移行計画の説明を最初はしたけど、早期リリース計画の話は部長との間だけの合意事項で他のものは誰一人としてそんな事実は知らないという状態をこの問題のために作ったようなストーリー展開だなぁと感じられるようになれば、もうこの問題は怖くないのかなぁと思いました。
で、題意としては、スケジュール変更などの情報共有はきちんと手を抜かずにやるべき当たり前の作業。と考えられているか、それくらい知っておいてね。的な感じでは？と思いました。

◆（１）

（１）処理遅延は結果的に起り、移行は成功したといっても元々の考えがNGだったのでまぁ仕方ないというか自業自得というか・・・ですが、ここではその問題点を問われています。

問題点はもちろん、移行データに問題があった事です。

ただこれらの意味を知っていても、解答する立場で問題と感じるのは書き方です。

恐らく問題文中で、現在のデータの様子は昔と違うぞ的な表現が書かれているはずで、そこの部分を考えるべきです。

つまり、この問題は、そもそもこのシステムをリニューアルする意味であったはずなのに、全くそれが反映されていないという事だと思いつけば、自ずと、このシステムのリニューアルする理由を書いている個所を文中からリードバックし、それはチャプタの『宿泊通知システムのリニューアル』で書かれてるはずだと”当たり”がつくようなフットワークを身に着ける必要もあるなと思いました。

この”当たり”をつけるフットワーク（俊敏な身のこなし）は課題となりそうです。
ただ、このフットワークはやはり問題を何回も解きながら、業界標準パターンを身体で覚える事かなと
思いました。そのためにどうすべきか・・・要工夫です。

（２）ヘルプデスクの処理遅延が起きたそもそもの原因（問題点）を問われています。

まぁこれも原因はITSMのスケジュール変更による関係各位への周知がやっていなかったためであるが、こういったのは、なぜ起こるのだろうと考える。

１つは、マネージャレベルになれば、全体への影響を必ず確認する必要があるという事を忘れると、

こういう事になりますよ。という題意なのかなと思われます。

今回の場合は、スケジュール変更に対する関係各位への周知徹底がされておらず、特にヘルプデスクへの変更連絡が怠った点が問題点だと気づくフットワークが必要と思われます。

という事で、H２４・問題３のテーマであるアプリケーションの受け入れという事の全体題意については、IPAの採点講評は、これこそまさに採点者の気持ちをズバリ書かれている題意そのものを知る方法なんだという事で、とても参考になると思います。

★平成24年度・秋期　ITサービスマネージャ　採点講評

という事で、次回は次の問題を振り返ると思いますが、その前に、喉元過ぎれば熱さを忘れないように、上記採点講評を参考（抜粋）にしながら記録する事にします。

題して、”ITSM　心得帖”　です！！

一杯集まったら、纏めて書籍化したいです（って、まぁ嘘ですが・・・）

今回はこれにて御免（にんにん　笑）