PM2考察編・問題分析の考察（設問ウ）３章とは

さて、それでは設問ウ、最後の章、起承転結の『結』にあたる、３章となります。
PM２に関しては、共通の必勝法を考察するのはなかなか表現も含めて難しいなと実感します。

それでも、一応まずは前回同様、H24問1の設問ウの例で考察しようと思います。

と、その前に設問イ、２章の心得とかどうだろう？と思って考えます。
２章に特化した場合、論文の起承転結の転（もしかしたら承と転かもしれませんが）という事かと。

あとは、結果的にアプローチの仕方は、最初の全体構想に沿って論じるので、設問ウも同じかと。
なので、PM２の全体の心得という事で、後で記録しようと思います。

という事で、設問ウです。

■設問ウについて　６００字以上１２００字以内

◆３　トラブルに対する作業統括　－－－＞ここは設問ウの文をタイトルっぽくなれば良い？

ここの出だしで以下の節に結びつけるために、”前振り”がないとどうもしまらない気がします。
つまり、この例で言うと、トラブルは連携ができなくなった。という事、原因は、連携サーバが起動
しているのにもかかわらず、連携元の基幹DBサーバを再起動してしまった事にあります。

それらの復旧は業後という事で方針は決定したが、業後の前後で何をすべきか、また現在の状況
はどういう状態か？などの進捗を知る必要があること、さらに、これらの進捗および業後に行う作業内容などの情報を関係各位に周知するため、報告窓口の1本化という事で、必ず私に一報する
必要がある。。というような前振りです。

問1の中の問題文に記載の指定の観点を論ずために、節タイトルにしてみました。
（もっと良い方法があれば教えてください（苦笑））

◆３．１　進捗状況確認
→まず現在の状況を再度確認。
・基幹DBサーバの原因であったDB枯渇は解消している事。
・基幹のAP,DBサーバは正常に再起動されている事。
・認証およびメールサーバは停止させている。
・ユーザ利用はできなくしているので現在サービスは停止している

次に実施すべき事の確認（目的）を論じる必要があると思われます。
この目的が設問ウの文中に指定されているからです。

ではどういう目的で作業統括すべきなのか考えます。
やはり、なんといってもサービス復旧が最大の目的なので、今回は業後でも良い連携の前に
基幹システム再開が最優先です。
恐らく、この、サービス再開が最優先目標というところは、共通の題意なのではと思われます。
ITILでいうインシデント管理にあるサービスの解決復旧の最優先というところです。

それでワークアラウンド（暫定対応）ですませたかのくだりはここではあまり重要ではないですが、
サービスが停止してしまったので、暫定処置として、注文はメールでなく電話とし、手書き対応に切り替える・・・とかまぁ今回の場合は色々と苦しい限りで省略ですが、つじつまが合ってれば結構現実味があって良い論文になりそうかもしれませんが題意から離れないようにするのをくれぐれもお忘れなきよう（って偉そうに言えませんが（苦笑））

まぁそんなわけで、サービス再開で後必要なのは、認証およびメールサーバの正常起動となります。これを実施する事で、基幹システムは正常に動作（連携以外）するからです。

◆３．２　情報の一元管理
→上記で得た現状及び業後に行う作業などの役割分担などが必要となります。
また今回のように連携サーバ起動時間延長情報が他業者しか知らないなどの情報周知不足などの無いように情報は一元化すべきと考え私含めた関係各位には必ず周知するように顧客交えて承認を得た。
また具体的な情報として、顧客、関連業者に対し以下の上布共有及びその方法に対する影響の有無の再確認を依頼。

・顧客：業後にDBサーバが一時中断するという利用者へのアナウンスが必要

・他業者：認証サーバ担当、メールサーバ担当へのサーバ再起動後の影響確認

・・・という感じでもう少し論文らしく書けばどうだろう？って思いました。

で、恒例？の文字制限ですが、今回は前回の８００字よりも少なめの６００字です。

２節に分けたので、１節平均で３００字ですね。

■総括

以上で、終わりです。

PM２のH24問1に限ってちょっと考察してみたのですが、なかなか２時間なんて

あっという間だろうなとあらためて実感です。

ただ、やはり、時間はあればあるほど有利という事は自信をもって思えますので、

次回は全体を振り返ってみようと思います。

それで、PM２の論文必勝法（非公認）の心得を僕流で纏めてみようかと（苦笑）。

でわ。

PM2考察編・問題分析の考察（設問イ）２章とは

さて、前回は熱くなってしまい、失礼しました（苦笑）
肝心な心得を記録するのを失念していましたので、以下、１．２章の心得です。

さて、それでは設問イ、章で言うと２章についての考察となります。

■設問イについて

流れ上、設問アの１．１が『起』、１．２が『承』なら、設問イは『転』のように思われます。
例によってH24（2012年度）の問１の場合だと、

◆２．重大なインシデント回復作業中のトラブル　８００字以上１６００字以内

◆２．１トラブル発生内容

”転”の章、つまり２．１章で、文章中で提示されている、基幹業務の障害から起こる、
全社認証基盤の停止、およびメールシステムの停止を起こすというものであるが、
それらの事前に用意した対策も”穴”があり、トラブルを引き起こし、それはどういう”穴”
なのかをここで論じるのだと思われる。
この内容は前の設問アで論じた前もって用意した対策の盲点が障害を引き起こすという事なので、僕が考えるに、例えば、よくある盲点として、自分は完璧だったときにおこる障害ですね。

え？作業は完璧だったら、障害とか起らないだろうって？
まぁ自分1人で最初から最後まで他に関係者が絡まないならば！です。

つまり、普通だったら数名のチームがいるばかりでなく、他の業者なども関係するとなれば、
色々な情報共有できなかった”穴”は少なからず存在してしまうわけです。
そうすると、事前に用意した対策に関して実は同じチームの中の人、もしくは他業者で影響した
かもしれない部分の周知がなかったら、間違いなく、なんらかの障害が出ると思われます。

そうですね。。。例えば同じチーム内であった場合は、
同じチームでも掛け持ってるやつがいて、そいつが途中で修正した他システムとの連携機能追加の周知が不完全な状態で周知されてしまったために、連携機能を忘れた状態でサーバ再起動を行い、連携機能障害を引き起こすとか・・・

または、連携先の他業者の場合、他業者側でも連携時間を変更してしまい、例えば夜８時までで連携を終わるのがその日はユーザからの要望で１０時まで連携時間を延長していたことが周知されなかったために、夜９時にサーバを再起動してしまい、連携停止で・・・とか。

まぁ複数の人が関わったために引き起こされる２次障害（トラブル）は盲点として格好のモジュールかなと思われます。（って実際に起こった場合を想定するとガチブルですが（苦笑））

◆２．２　トラブル発生時の関係者の協議

しかしながら、例によって対策を勝手気ままに論じるのではなく一定の流れに沿っての構成は
本文中で用意されており、2次障害（トラブル）に対する対策立案について、以下の指定があるので要注意です。

①その対策は安全で迅速である点に留意した内容で論じているか？

②その対策は、サービス再開としての検討方法は以下の検討観点で論じているか？

・サービスを全面的に再開する
→全面再開なので、もはや迅速性が懸念され、再開ポイント（個所）も増えて安全度も下がる？

・サービスを部分的に再開する
→部分的であるため全面よりも安全で迅速性は増すがその分、ユーザニーズに合ったサービス
であることが絶対の条件となるため、その見極めが大事と思われる。

・代替サービスの提供
→サービス自体の代替であるため、ユーザが違和感の無いサービス利用、ましてや使いずらいなどのクレーム等で利用頻度や信用を失うのは言語道断のため、代替えできるという絶対の自信と顧客と利用ユーザからの信頼実績があり、了承されている製品（サービス）が条件となるため、
日頃からそういった体制でいる以外はかなりリスキーな選択であると思われる。

といったような内容を対策に対する検討内容として論じる必要があるのですが、とにかく上記の架空障害の場合だと、基幹業務再開だけでなく連携データのリカバリも加わってしまってます。

今回のパターンで言うと、架空の１次障害も考えてませんでしたので考えてみます。
とにかく基幹障害のために、認証やメールなどが停止です。
停止したのか、停止させたかは書かれていないようですねぇ。
全社だったら、その影響でそうなった感じですが、後者はこれ以上影響を広めないための対応という風に分かれるのではと思います。
個人的にこの場合、特に触れられてませんから、どっちでもいいにしてほしいです（笑）

というのも、後者の場合でも良いなら、基幹が停まる影響で、認証を止めるのはつまりこれ以上使われると良くないという事、メールを止めるのも同じように自動でメール通知するような仕組みを止めるための臨時処置という風に考えれば良いかなと思ったからです。

前者のような連動で停止するのは、実際、基幹サーバ、認証サーバとメールサーバは別物ですから、同時にとまるのなんてサービス停止で連動するのは考えづらく、あるとしたら同一ネットワーク上に乗ってるであろうから、やはりネットワーク障害しかないと思われます。
そうなると、１次障害がネットワーク障害でそれから２次障害（トラブル）を起こさせるエピソードはなかなか思いつかないので、もし思い当たるエピソード有りましたら教えて頂きたいです。

いずれにしろ、基幹を停止させてこれ以上使われたら困るという状況はやはり容量的なものかなと。つまり例えば、基幹サーバ内のDBサーバのDB容量が枯渇してレスポンス遅延でAPサーバがフリーズしたとか、まぁそんな感じでまず基幹DBサーバがやばい状況となれば、ユーザがこれ以上システムでデータ更新されると困りますし、恐らくその画面もフリーズしてしまってますので、画面を使う前の認証画面で止めてしまえばよいので、認証サーバを止めて、DB情報を読み込んでメール送信する仕組みがダウンしてしまうので、メールサーバを止める必要も出てくるというのは、まぁ苦しいですが架空の障害ですので（苦笑）

で、この場合の予め予定されていた臨時対処が、認証、メールサーバも止めるであり、

その場合の対策が、DBの中身を整理・拡張、チューニングし、AP→DBサーバの順で再起動後に、基幹サービスの動作確認が問題なければ認証、メールサーバも起動させるという流れであったために上記に示す再起動時間の決定の盲点という感じで２次トラブル突入！というシナリオでどうでしょうか？

で、ここの問題の本題であるのはそんな想定外トラブルの立案をどうしたかとなります。

当然、サービス復旧が先決なわけで、なぜ連携が失敗したのかは後回しでしょう。
という事は、連携機能復活させるための連携データのリカバリを行い、データ同期をとる必要がありそうです。
ここで問われているのは関係者とどのような検討をしたかです。
まずは、データ同期の取り方と、その際の影響、そしてその作業の時間・他などを、基幹システム側関係者と連携側の担当を交え、お客様との間で至急、以下の観点で協議を行った。

今回の障害を基幹だけでなく連携機能も含めて全面的に再開させるか、その場合、
連携機能の再開は、リカバリとして基幹DB側の同期必須なので、基幹をそれまで止める必要がある。

連携機能は後回しで基幹のみ部分的に先行で再開させるか、その場合、
連携機能が停まった場合の連携側での機能が業務に影響しないかの確認が必要

もしくはサービス全体の再開を別のサービスで再開まで凌ぐ事が可能か、その場合、
別のサービスに詳しい担当者にも同席願って意見を聞く必要が出てくる。

さぁ、どうしましょう？というような感じで論じれそうです（笑）。

◆２．３　トラブルに対する対策立案

２．２で対策協議の結果、お客様から連携機能は、職員が業後に日計表を作成するためのDBサーバを兼任しているため、日中のリアルタイムな連携が滞ってもそれほど深刻でなく、業後で構わないと。
連携担当側の意見も、お客様の承認が取れれば、業後に基幹DBの利用止めて頂き基幹DBと連携側DBとの同期バッチを実行さえできればリカバリ復旧可能という事で合意できた。

既に前述の手順で基幹DBのデータは再起動され、基幹システムとしても復活しているが一応、認証およびメールシステムは止めたままである。

結果、日中は基幹システムの利用を先決とし、この後、まず認証サーバおよびメールサーバの起動で各システムの再開を行いそれとどうじに関係各位へのアナウンスを開始を行うという方針で関係各位全体で合意となった。

という事で、設問イはなんとか論じれそうかなぁって思われますが、ここで肝心な事がありました！！
そうです、字数制限です。
２章は、僕の場合、２．１～２．３の３節に分けましたので、８００字以上１６００字以上だと、
１節平均、最低２７０字くらいで収めればよいのかなと思います。

え？大変だって思いますか？でも、今、２．３の文だけで３３３文字ですのでもう越えてますので字数的にOKではないかと思いたいです（笑）

というわけで、次回は設問ウで、またH24の問1を例で考察してみます。
でわ。

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サービスマネージャとしてそういう場合にどうすべきかが問われているようです。

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

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

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

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

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

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

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

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

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

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

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

でまた次回。

PM2考察編・問題分析の考察（設問ア）１．１章

さて、午後2の問題の設問アについて考察してみます。
ほとんどの人が周知の事ですが、設問アの前半の問われ方は、
過去問すべての年で共通という事である。
つまり、この部分も当然前に書いたテンプレート同様、予め決めておくと
時間を稼げる部分ではないかと思われます。
で、その部分とは・・・過去５年で設問アの冒頭だけを書き出してみます。
一応、僕は過去問の午後1を印刷した紙を束ねて、それを開きながら書いております。

H25年度
問1　あなたが携わったITサービスの概要と兆候の管理の概要について、８００字以内・・・

問2　あなたが携わったITサービスの概要と外部委託業務の概要及び・・・８００字以内・・・

H24年度
問1　あなたが携わったITサービスの概要と重大なインシデント概要について、８００字以内・・・

問2　あなたが携わったITサービスの概要と不測の事態に備えて・・・８００字以内・・・

問3　あなたが携わったITサービスの概要とユーザとの接点に集まる声・・・８００字以内・・・

H23年度
問1　あなたが携わったITサービスの概要と顧客への基本的な報告事項、８００字以内・・・

問2　あなたが携わったITサービスの概要と監視作業を通じて発見・・・８００字以内・・・


問3　あなたが携わったITサービスの概要とITサービスの改善活動とした対象・・・８００字以内・・・

H22年度
問1　あなたが携わったITサービスの概要とCMDBの利用において発生した問題、８００字以内・・・

問2　あなたが携わったITサービスの概要とリリースの検証及び受入れの概要・・・８００字以内・・・

問3　あなたが携わったITサービスの概要とインシデント発生時に想定される問題・・・８００字以内・・・

H21年度
問1　あなたが携わったITサービスの概要と変更管理プロセスについて、８００字以内・・・

問2　あなたが携わったITサービスの概要とITサービスの改善計画について、８００字以内・・・

問3　あなたが携わったITサービスの概要と分析して判明したインシデント・・・８００字以内・・・

も、もういいですよ・・・ね？（笑） というわけで、見事に全く同じ書き出しである事は、まぎれもない事実であります。もうお腹一杯です（笑）
と、同時に、この出だしは最初から決めておくとかなり有利に時間を稼げるという事も
お分かりになるかと思います。

◆設問アの冒頭のアプローチについて

論文のプロットについてですが、いうまでもなく、この冒頭部分は第一章の一節、
つまり、１．１となるのは間違いないでしょう。
1章は、８００字以内であり、上記の場合で考えると大抵は１．２の２節分かなと思われます。
という事は、１節平均４００字以内であると考えられるのですが、
もう少し見てみると、上限８００字はあっても加減が無いという点です。
これは一体どういう事でしょうか？

僕が（あくまでも勝手に）思うに、題意に合いさえすれば、字数は少なくても良いのかも。
という考えです。
それなら、以下に示す、１．１で論じるのに必要なポイントさえ押さえればよいのかと思い
ます。

という事で第一章は、H25年度の問1を例にとれば、冒頭は以下のようになるはずです。

１、私が携わったITサービスの概要と兆候の管理の概要

１．１　私が携わったITサービスの概要

では、この１．１のITサービスの概要とはいったいどういう内容であるべきでしょうか？
恐らくここにも一定の基準となるキーワードがあって、それに当てはめて予め自分の
ITサービスをこれにしようって決めておけるんじゃないのかと思われます。

しかも前述の質問書（テンプレート）と若干かぶってる内容も含め乍ら、当然、ここの質問書に書かれたサービスの事を書く必要があります。当たり前ですが、質問書と別のサービスを１．１で書いてしまう事の無きよう注意願います（苦笑）

で、某対策本によれば、やはりそのキーワードはこれもまたテンプレート的にあるようで、
そのまま書くと著作権的に面倒かもしれないので、考え方を記録しておこうと思います。

まずITサービスの概要であって、詳細ではなく、しかもサービス（システム）の内容の詳細
を事細かく技術用語一杯並べて書くというのでもないのはお分かりかと思いますが、じゃあ
一体どういうの書けばよいの？となります。

◆ITサービスの概要
まず、あなたはITサービスマネージャである事を忘れないで念頭に置きます。
で、ITサービスマネージャ的な観点で、実際に携わった（かのように）サービス
の概要を冒頭で論じるのです。

つまり、結を先に論じて、後から尾ひれをつけていけばどうかなぁと。
具体的に書いてみます。
例といっても、具体的な解答はないので、過去の午後1の問題を見ながら、どう論じるのが良いのか、考察してみたのですが、意外に行けますねぇ（苦笑）。

１、顧客（サービス提供先）の業種と規模を紹介する。
→サービス提供している業者（顧客）の業種と規模を採点者がイメージできるように論述。
ここでの論述の主語は私ではなく、顧客、ｘ社という事です。
（もちろん既に質問書に書かれた内容と合致してる必要があります。）

■例
（問題抜粋）
・H24問1：
Z社は、消費者向けのスポーツ用品を製造する中堅企業で、商品は全国の小売店で販売。

・H24問3：
E社は、旅行代理店向けにサービスを提供する会社である。E社は、旅行代理店のシステムから宿泊予約が成立した旨の通知を受け、全国に１万軒あるホテル、旅館など（以下、宿泊施設という）に宿泊予約者の情報を送信するサービス（以下、宿泊通知サービス）を提供している。

・H24問4：
・C社は、健康食品の製造・販売会社である。インターネットを利用した販売を行うためのシステムとしてWebサーバ、データベースサーバ（以下、DBサーバという）、メールサーバなどで構成される販売管理システムを運用している。

と、まぁ切りが無いのですが、これほどまでに午後１問題での書き出しはもう凄いくらい
午後2の設問アの冒頭で使えるモノばっかりでした。

２、顧客先に提供した目的を達するためのサービス名を紹介する。
→ある理由のため、今回のシステムの提供が行われたという事がイメージできるよう論述。
（ここももちろん既に質問書に書かれた内容と合致してる必要があります。）

■例
（問題抜粋）
・H24問1：→（Ａ）とします。
Z社は、売り上げ拡大を図るために、消費者向けオンラインショッピングサイトのWeb注文受付システムを新規構築した。

・H24問3：→（Ｂ）とします。
E社は、サービス拡大のために、宿泊通知サービスのシステムリニューアルとして、旅行代理店が宿泊通知をリアルにタイムに把握できる機能を追加する事にした。

・H24問4：→（Ｃ）とします。
・C社は、インターネットを利用した同業他社の販売管理システムが不正アクセスを受け、顧客情報が漏えいしたという事件があったため、セキュリティ対策の有効性を確認するために脆弱性検査を行う必要があるという事になった。

と書いて思ったのが、上記に示した●●●のために・・・の●の部分が、問われている内容に
合う事が重要だと思いました。

つまり、上記、（Ａ）の場合、サービスは新規で、（Ｂ）の場合は既存サービスに機能追加、
そして、（Ｃ）の場合は、セキュリティの脆弱性に関する問題の時に使えるというものである。
ただセキュリティ分野の問題の場合は、他の例に合わせると異質な感じがする。
恐らくこのセキュリティ分野にとってはもしかしたらこれ専用のモジュールが必要かも。

まぁ当然色々な場面に遭遇するように、色々な問題パターンはあると思われますが、
それでも分野ごとに分類できればいいかもと思います。

またどうせ全ての分野が網羅できるわけもないと割り切れば、可能な限りの分野を抽出
して、類似の問題を探してあったらそれを選択するといった方法もありと思います。

３、そのサービス（システム）はどこ（誰）が担当しているのかを簡潔に説明する。
→１で紹介した顧客へのサービス提供先である会社の部門（部署）ですね。
システムの・・・は、・・・が担当という感じで書いているようです。

■例
（問題抜粋）
・H24問1：
Z社内システムの企画・運営は、営業管理部、システム構築は情報システム部が担当となった。

・H24問3：
E社内システムの運用は、システム部が担当し、旅行代理店及び宿泊施設からの問い合わせはシステム部が運営するサポートデスクが担当。

・H24問4：
C社で行う脆弱性検査は専門の会社であるＲ社と共同で情報システム部が担当

４、貴方の役割・所属・立場・責任範囲

■例
（問題抜粋）
・H24問1：
Ｚ社情報システム部のＭ部長からサービスとして提供するために必要なマネジメントをＩＴサービスマネージャとして指示を受けた。

・H24問3：
E社システム部のＦ部長からリニューアルシステムの受け入れテストの実施、およびリスクが最小限となるようなシステムの移行計画の作成指示をＩＴサービスマネージャとして受けた。

・H24問4：
C社情報システム部のＪ部長より脆弱性検査会社のＲ社と協力して検査指示をＩＴサービスマネージャとして受けた

という感じであれば、１．１ができてるのではと思われます。
試しに、H24問1の１～４をつなげてみます。

Z社は、消費者向けのスポーツ用品を製造する中堅企業で、商品は全国の小売店で販売。
Z社は、売り上げ拡大を図るために、消費者向けオンラインショッピングサイトのWeb注文受付システムを新規構築した。
Z社内システムの企画・運営は、営業管理部、システム構築は情報システム部が担当となった
Ｚ社情報システム部のＭ部長からサービスとして提供するために必要なマネジメントをＩＴサービスマネージャとして指示を受けた。

これで１９６文字ですが・・・どうでしょうか？
文章は論文調にもう少し手直しは必要かもしれませんが出だしとしていい感じだなと思いませんか？

という事で、設問アの１章の８００字のうちの出だし（つかみ）である、１．１ ＩＴサービスの概要の
考え方について考察してみました。
上記の考え方で自分が携わった、もしくは携わったかのようなＩＴサービスについて決定して
おく事が良いのではないかと思います。

で、今回は、まずはここまで。
次回は、１．２の論述方法を考えてみようと思います。
でわ。

PM2考察編・問題分析の考察（序盤）

前回、
過去５年間のPM１問題、合計２３問についてテンプレート作ってみようかと・・・
などと書いて、実際に問1からやろうと思いましたが、これ、なかなか大変という事に気づきました（苦笑）
まぁかなり言い訳にも近いというのもあるのですが、全２３問を実際にこのブログで記録していくと、
恐らく、試験が終わってるなぁと思ったのも理由ですね。

ただ、これってもう試験で絶対に費やす時間の一部なんで、自分なりのテンプレートは暗唱できるくらい
覚えておくと有利かもしれませんので、肝に銘じておいた方が良いかと思われます。

という事で、９月も早いものでもう3分の1が来ようとしています。
皆さんは準備万端でしょうか？（羨ましい限りです。え？全然って？・・・おぉおお同志よ（笑））

正直僕は、夏の暑さによる体調不良と、それになかなか時間が取れない所帯持ちの環境・・・
と、まぁ、そんなものはきっとただの言いわけなんだろうなぁって思いますが、
とにかく、これから試験までの残された期間で何をすべきか今一度振り返ろうと思ったわけです。

え？そんなことはいいから、PM２の問題分析して欲しいって？
ま、まぁそうなんですが、その前にやみくもにそれをブログに記録していてもこれはこれでまた
志半ばで試験日を迎えそうで、それはさすがに避けたいと思うのです。

という事で、問題分析の考察の前のプロローグと申しましょうか、
まずはスケジュール見直しとGOALまでのマイルストーンを決めておこうと思います。

まずGOALは、試験日で、今年は10/19(日)です。
これで思い出しましたが、毎年日曜日に、丸1日開催するので、終わった時には身も心も結構
ヨレヨレになって、しかもこの午後2の論文記述で出来如何にかかわらず、手が腱鞘炎になり
そうな脱力感で、明日は仕事かぁって思いながら帰途に就くのです。
（え？それって僕だけですか？（苦笑））

あ、脱線しました。

で、今日が9/10頃とした場合、試験まで日数で言うと、約４０日となります。
ブログで記録するのも毎日できるわけないので、まぁあとできても、５，６回かなぁと思われます。

という事は、あと５，６回でどういう風な内容をまとめるかという事を考える必要があるわけです。
今回、本ブログは”午後1問題の振り返り纏めブログ”と、”午後2の考察ブログ”がメインとなりそうで、
そうはいっても、まだまだ不十分である事は、残念でならない。

で、やはりまだやれていないのは午後2の各設問ア、イ、ウの３問のアプローチ方法の考察ですね。
午後1のように必殺技を編み出したいと思うわけです（苦笑）

もちろん、本当の勉強は、午後2だけでなく、午前1免除なら午前2の攻略も視野に入れながら、
まだ午後1の他の過去問にも手を出して、心得を作成する事ができたらもう完璧なんですけど、
それをGOALまでの期間で実現させるには、ほぼ毎日記録しても厳しいくらいと自覚しました。

という事で、ブログ記録は午後2の設問ア、イ、ウのアプローチ手法をなんとか過去問を例に
試験日までのGOALまでに記録しておけたらと思います。

なので、次回は、午後２の設問ア、イ、ウ纏めてのプロットを書く必要があるか、
もしかしたら以前書いたモジュールでつなぎ合わせてつじつまさえ合わせれば、
一見、別々のサービス（システム）における作業内容でも論じることはできないか？
などというのはいままで誰も考えた事はない、か、例えあっても公の場で公言など
しなかったであろう試みをやってみようと思います。といっても５回くらいですが・・・

でわ。