PM2考察編・問題分析の考察（設問ア）１．２章からの全体構成

さて、前回は午後2問題の設問アの決まりきった１．１章の論述部分となる、
私が携わったITサービスの概要　でした。

少しだけ１．１の４ポイントおさらいです。

■１．２の考察
で、１．２章というのは、問題によって異なる部分でもあり、論文の主旨ともいえる
大切なキーワードという事ですが、１章は８００字以内というところで、前回１．１章で
２００文字ほど使いましたので、残り６００字と思ったりしてませんか？
以前書いたかもしれませんが、注意すべきは、８００字以内であって、ｘｘｘ字以上という
下限の文字数の考慮が無用というところがポイントだと思います。

つまり、気を付けるべきは、６００字以内必須、キーワードに沿ったエピソード（モジュール）
組み込みとなるわけです。

で、その１．２に相当するキーワードの考察となるわけです。
前回の前半で記述した中の１．２部分のキーワードをピックしてみます。

H25年度
問1■兆候の管理の概要について、６００字以内・・・
問2■外部委託業務の概要及び・・・６００字以内・・・
H24年度
問1■重大なインシデント概要について、６００字以内・・・－－－＞☆今回例です
問2■不測の事態に備えて・・・６００字以内・・・
問3■ユーザとの接点に集まる声・・・６００字以内・・・
H23年度
問1■顧客への基本的な報告事項、６００字以内・・・
問2■監視作業を通じて発見・・・６００字以内・・・
問3■ITサービスの改善活動とした対象・・・６００字以内・・・
H22年度
問1■CMDBの利用において発生した問題、６００字以内・・・
問2■リリースの検証及び受入れの概要・・・６００字以内・・・
問3■インシデント発生時に想定される問題・・・６００字以内・・・
H21年度
問1■変更管理プロセスについて、６００字以内・・・
問2■ITサービスの改善計画について、６００字以内・・・
問3■分析して判明したインシデント・・・６００字以内・・・

う～ん、なかなか多種多彩のキーワードですね。
強いて言えば、インシデント、ＩＴサービス改善という言葉しか繰り返しは
ないようですね。

例年の傾向をつかもうと思ったのですが、まぁ当たりはずれで仮に当たって
も僕は嬉しくないです（笑）
では、傾向から考えるという考えは没にして方針変更です（きっぱり（笑））

変更方針として、まずこのキーワード一つの題意について考えてみます。
例でＨ２４年度の問1の場合・・・

１．２　重大なインシデント概要

となるわけですが、一体何を書けば（論じれば）良いのでしょうか？
ここで、重要な事ですが、問題に書かれている内容以外のエピソードを論じるような事
決して行ってはいけないという事です。
つまり、今回の問題では、以下のように問題文に（指定で）書かれているのである。
重大なインシデントとして、
・基幹業務のシステムの障害
・全社認証基盤の停止
・メールシステムの停止
の３つのインシデント内容を使って論じなさいという事は、既に固定で決められているのです。
言い換えれば、上記の3つのキーワードをモジュールとして、担当サービス内で起こったインシデント
として論述する必要があるという事です。

そしてそれらキーワードについての（あくまでも）序章、プロローグ、ほんのさわり的な紹介程度に
抑えて論述する必要があるようです。

さて、それではどう論述するか？です。

まず、今回のキーワード例の場合は、３つのインシデントについての概要を論じるという事です。
もう少し具体的に言うと、消費者向けオンラインショッピングサイトのWeb注文受付システムを新規構築した際に、
基幹業務のシステムの障害、および全社認証基盤停止し、メールシステムも停止したという
エピソード（プロット）を作成する事になってしまいます。

う～ん、今回の場合やはり新規構築時に、これほどまでのインシデントを招くのには無理が
あるかもしれません。
ただ、前持って考えていた１．１の内容がこれしかないのでしたら、潔くこのモジュールで辻褄を
合わせることに専念するしかないでしょう。
恐らくこの段階で別の問題に変える事は、”無謀”な選択としか言いようがないと思われますので。

■プロット（というか）つじつま合わせの考察
まず、プロットという意味で、今回のインシデントに対する論文構成を考えるわけですが、
もうこの辺りは、後で出てくるわけですが、他の設問イ、設問ウをチラ見してみます。

ざっとですが・・・
設問イ：設問アのトラブル回復中にまたトラブルが出たがどういうものか？
設問ウ：設問イのトラブル対策を実施するための目的と、どういう風に統轄したか？
って感じですね。

つまり設問アで述べた３つのインシデントは、設問イで回復中に、手順想定外でトラぶった際の
検討策を関係者と協議する際の観点を既に列挙されているサービス回復手法の選択とその理由を述べ、
設問ウで書かれている作業統括方法について述べる事のようです。

さぁ、そんな感じなので、つじつま合わせといえど、設問イ、設問ウを想定した構成にする必要があり
です。
よって、、、

設問イではそのための対策で回復中にトラブルであるため、
設問イに問われる前の、回復策（といっても不完全で、これが設問イのトラブルの伏線）
までは論じておくか、設問イの冒頭で論じ始めないと辻褄が合わなくなる

設問ウはその設問イでおきた２次災害となるトラブルをどのように統轄して収めたかを
問われているため、構成（プロット）としては、以下のような流れが考えられます。

以下、朱筆部分は、構成のつじつまを合わせるために考察が必要な個所。

■全体構成の考察箇所の整理
新規構築開始・設問ア
↓
＜1次障害勃発＞→どんな障害？考察①・設問ア
↓
基幹業務のシステム障害→＜具体的にどのような障害？＞→考察②・設問ア
↓
全社認証基盤の停止→＜なぜ起こった？＞→考察③・設問ア
↓
メールシステムの停止→＜なぜ起こった？＞→考察④・設問ア
↓
事前に用意済の対策実施→＜どんな対策？＞→考察⑤・設問ア
↓
↓ここ↑までで８００字以内となり、ここまでが設問アで問われている範囲と思われます。
以下は設問イからですが、全体の流れとして一応記録です。

↓
インシデント回復中＜2次障害勃発＞→＜どんなトラブル？＞→考察⑥＊・設問イ
＊設問イで問われているのはココですが、以下の観点を含めないとNGです。
a：２次トラブル発生時に関係者と検討した観点
b：２次トラブル発生時に立案した対策

で、上記の2点の観点を含めるのは題意を読む必要ありと思われます。
統轄とは、ばらばらのものを一つにまとめること。「各人の意見を―する」という意味だそうです、
そうすると、色々な作業を一つに纏める、色々な作業って？という辺りの記述はポイントでしょうか？
まぁこの辺りは、考察・設問イでやる事にします。
↓

作業を統括するために行った事→考察⑦・設問ウ＊
＊設問ウも単なる統括しましたでは当然なく、題意を含んでるように思われます。
これも考察・設問イでやる事にします。

というわけで、１．２章から全体構成までは関連づいていないとダメなんだなと感じます。

■総括
上記の例では予め想定内の障害と、想定外の障害が勃発し、
結果的にITサービスマネージャとしてそういう場合にどうすべきかが問われているようです。

想定内の障害は事前に準備していた対策でカバーできると思ったら、そうでなかったという盲点ですよね。
しかしながら役者で言う台本通りでないアドリブが効かないと、一皮むけないのかもしれません（笑）。

このようなテストレベルでさえもこういった資質が問われてる位、実際の作業ではそれ以上に、アドリブを
効かすことができないと、最悪は収集不可能で大参事を冒し、役交替となりかねないのです。

しかしながら、そうはいっても盲点は残念ながらあり、その時の想定外の焦りと驚きが相まって、一瞬でも
パニクってしまうのが人間だと思うわけです。

みなさんはそんなパニクッった時にどうしますか？
僕は独りでかんがえたくないので即エスカレーションです（笑）

エスカレーション先は大抵上司含む関係各位ですので、今回の作業内容は周知されております。
もちろん１次障害時にも用意されている対策内容も認可、承認されていたはずです。
にもかかわらず！です！！！２次障害が起こるとはだれも想定できなかったはずです。

だから、それ以降の作業は単独の判断で動いてはいけないのです。
場合によっては、最小限に悔いとどめる方法をお客様と協議して、対会社としての判断を仰ぐ
必要があるはずだと思うからです。

つまり、関係各位が知っている想定内の作業以外の道の想定内の事象が発生した場合、
例えそれが大丈夫であろうと、勝手な判断でそれ以上進めてはいけないと思います。

恐らく、論文の題意としてそういった判断力を求めてるのかなとも思ったりします。

いずれにしろ、お客様に本日の作業内容と、それで起こった障害対策の準備もお客様との合意
がされているはずなので、ここまでの障害でしかも対応がきちんと取れていさえすればクレーム
になりそうでも、お客様承認の予定通りの作業内容のため、会社が責められる事はあっても作業にかかわった人たちの人はなりません。

しかしながらお客様どころか関係各位誰一人として単独の判断で実施させて起こしてしまった障害の場合は、相当な覚悟で会社としての信用問題まで発展しかねないと思います。

とりあえず話が熱くなってきたのでクールダウンです（苦笑）

でまた次回。