PM2考察編・問題分析の考察＊とりあえず全体総括。

さぁいよいよ１０月になり、もうカウントダウンって感じですよねぇ。
ゆるい感じで色々と考察を行ってますので、まだまだまったくもって物足らないのです。
なので、恐らく再開はすると思いますが、試験日は無情にも迫ってきますので、
一応、PM2の僕なりの攻略法というか、特訓法？のようなものを考えようと思います。

■とにかく時間は2時間しかない

くれぐれもお断りしておきますが、２時間も、ではなく！２時間しかないのです。
なので、基本的な考えとしてやはり時間を少しでも稼げるための工夫をする事
が先決だと思うわけです。
対策本には、採点者の読みやすいようにとかいうのももちろん書かれてますが、
それもこれも時間の余裕がないと読みやすいとかいうよりも読んでもらえるような
文章が記述できているかのレベルになりかねないなら意味がないからです。

という事で、

■まずは試験時間を稼ぐ工夫。
です。
最初に書いた、試験官が”はい始めてください”というまでの時間も少なからず
待たされる感じです。
しかもその時間は裏返しになった答案用紙を透視できないかなどと馬鹿な事を
考えたくなるようなちょっとした静寂の時間なのですが、人（僕も？）によっては
この時間はあまり好きではない、プチ拘束時間です。

で、このプチ拘束時間に透視を考えるよりも、もっと有意義な時間にできないか
と思うわけです。
まぁ静寂と言っても全くの静。という訳でもないですが、いわば、無の境地になれる
かもしれないのです。

無・・・そうです。この時間は目をつぶり試験官の合図とともに何をすべきかなどを
整理する時間と考えればどうでしょうか？

という事で、このプチ時間で考えるべきことは何かです。

■始めで、試験時間にすべきこと。

まぁ試験なのですから、問題を解けばよいのですけど、なんせ論文ですので、
勝手が違うわけです。

まず、答案用紙と、問題と、それに以前書いた質問書（テンプレート）があるわけです。

そうなると、やはり最初に書くのは、名前・・・は確かに重要でかつ間違えてはいけない
最初の回答かもしれません。

まぁその次は受験番号・・・も同様です。

で、次に来るのはやはり質問書（テンプレート）です。
例年毎回同じだと思われますし、今回も間違いなく同じであろうと思いますので、
ヤマかけというほどでもない確率で毎違いないでしょう。

ならばもう始めの合図と同時に名前と受験番号の記述が終わったら、
迷うことなく、しかも考えることなく書き写すような感じで記憶通りに、
この質問書を記述できたとしたら、大体１５の質問で、１問当たり１０秒未満だったら、
質問書は見直しても３分ほどで記述できるのではと思います。

ではここまで纏めると。

開始前（だけど教科書閉まって的なプチ拘束時間）
１、試験開始までは瞑想（笑）し、開始して何をすべきかの手順の確認を頭でしておく

開始の合図後
２、答案用紙に名前と受験番号を間違えずに書く

３、質問書に記述。記述の内容は考えずに予め覚えてきた通りの内容で考えず書く

特訓：質問書を何回も手書きして暗記するくらいまでになるべし！

４、２つの問題の選択をして、選んだ問題はどれかを問題用紙に記述。

特訓：どの問題が自分にとって論文が書きやすいかの見極めの訓練すべし！

ポイント：対策本に書かれている事を参考にしましたが、なかなかさすがに鋭いです。
①問題は2問で、１つの大きなキーワードで別れていますので、そのキーワードで
取り掛かれるかの判断をできるようになるべき。

②①が難しい人は、全２問の設問ア、イ、ウの問題文中に書かれているキーワードの区切りを下線で引きその線の左横（始点）に①から数字を機械的に書き込んでいく方法。
で、問1、問2の設問ア、イ、ウの下線の合計が多い方を選ぶのだそうです。
え？少ない方が良いんじゃないのかって？はい、僕もそう思ったのですが、
実は文中のキーワードが多いという事はかえってキーワードを多くなることで詳細になる題意や
ヒントなどが増えるという事なのだそうです。

で、この下線を引いた数字につきましては、後ほど例題とかで活用してみます。

③②でもピンとこない、もしくは万一同じ数だったとかだったら・・・こちらの方法です。
といっても今回の方法は、設問ア、設問イ、の後で設問ウの問われ方に着目するのだそうです。
例えば、H24年の問１だと、設問イで述べた・・・・と書かれており、
H23年の問２の場合は、設問アで述べた・・・と書かれていますが、この場合は、H23年の問2の
論文を選択すべき。と、対策本には書かれてました。

その理由は、設問ウを論じる際、設問アについて言及されるのと、設問イについて言及されるのでは、論文の幅が違うという事。つまりこれから設問アの範囲で論じるのと、設問アの題意を含んだ設問イについて論じるのとでは、論じる内容をどこまで絞るかで、断然！前者という事らしいです。

５、時間間隔に慣れる。
　２時間の内訳は、対策本に書かれているのは以下の通りでした。
　・問題文選択　5分
　・論文の構成の組立　１５分
　・設問ア　８００字以内　３０分と言っても基本は１章の２節分の時間が掛かる。
　　１．１　体験したサービス内容など
　　１．２　問題のキーワード
　・設問イ　９００字くらい　３５分といっても節の数分の時間が掛かる
　　しかも字数も１節平均全体の節の数で割った文字と考えると、
　　３節だと、３００字くらいなので結構纏めて絞って書かないとダメと考えられます。

　　設問ウ　７００字くらい　２５分

　　ここまでで設問ウについては設問イよるも字数が少ないため想定の制限時間

　　はかなり少ないと感じると予想される。

　訓練方法を考えてみました。
　やはりこれはもう身体でなじむしかないと思います。

え？いきなり論文なんてかけないのにそこまで至らないって思いますか？

はい！そうなんです（笑）
やはり対策本などの購入は否めないと思いますが、どうやって書いたらいいのか不明、
とか、合格したやつら（失礼）の論文とはどんなものか知りたい。

というような人は僕のように対策本を買えば、載ってます。

え？それは人の論文だから訓練にならないのでは？って思いますか？
最初は僕もそう思ったんですけど、PMとか含めて３回PM2受験してみて
あらためて感じる事は、２時間、論文を手で書き続ける事は結構大変でした。
といっても最初などは、設問ウまで至らず、以前に書いたように、構成や、
質問書で時間を取られて、敢え無くアウトでしたが、それでも諦めずに書き
続けたらどうなったと思いますか？（苦笑）

はい！手が途中から動かなくなって、ちょっと焦りました。
え？んなばかなぁ、大袈裟ですって？

ま、まぁ動かないはいいすぎかもしれませんが、手がだるくて最後の10分くらい
になったら手の感覚がなくなってきたのは事実でした。

さすがに２回目の記述の時は、少し楽にはなってきましたが、時間配分は相変
わらず最悪で、設問ウを書き始めた時には、時間が２０分を切ってました。

もうこうなった僕は、完全にクールな状態でいられなくなり、記述を早めようと
するのですが、ペースが乱れたランナーの状態で、やはり最悪でした。

そういう状況になったことが無い人は凄いと思いますが、少なからずそういう
思いをした。しそうになるかな？などと思った人は、ぜひとも、たとえ人の合格
論文であってもそれを自分の手で書き写してみようと思った次第です。

もちろん！書き写しているだけで、前述の　・問題文選択　5分、論文の構成の
組立　１５分の２０分は関係ないので、後の見直し５分入れた実質２５分を除い
た１２０－２５＝９５分よりかかってはいけないという事になります。

既に構成ができている文章を書き写してみるのですが、手の疲れ度合いは、
どうでしょうか？可能なら同じでしょうが、ひたすら字数に慣れるという意味で
その論文を書いてみる。もしくは他の年度の別の人の合格論文を書き写す事
もやってみようと思います。

え？そんなことばかりしか効果はないんじゃないのって思いますか？

ぼくはそうは思わず、中身の構成ができているわけですから、どういうような
書き方で問題に対する論述をしているかの観点でも読みながら書き写して
みれば少しはためになるんじゃないのかなぁって思います。

前述のように色々なテーマの年度別の色々な人の合格論文を書き写すだけ
でも結構特訓になりそうな、そんな気がしませんか？

で、これはちょっとすげぇええって思ったんですが、猛者、いや漢なのかもしれ
ませんが、どうしても自分の体験したサービスが問題にそぐわないと思った、
その人は、なんと！！過去の自分が写した他人の合格論文の事象をそのまま
引用してA判定合格したのだそうです。

このやり方は当然お勧めしませんが、過去の合格論文内容まで覚えてるわけ
ないので、まぁひとつの最終兵器という事で使えるかもと思いました。

という事で、

■過去問の色々なキーワードを他人の合格論文で模写すべし！
可能なら、暗記するほど繰り返すべし。

これで、字数感覚と、合格できる構成の組み立て方を学ぶ。

いよいよカウントダウンですが、このブログの最大の目的である必勝法の研究序説
という事で、ITSMにかぎらず、僕の次の目標であるPM試験で記録しようと思ってます。

以下のサイトにて開始・・・

H26用PM試験・僕流勉強～午後1研究序説！

H26用PM試験・僕流勉強～午後2研究序説！

取り急ぎ、皆さんの検討を祈ります。
あ、もちろん、僕もゆる～りと頑張ります（苦笑）

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までに記録しておけたらと思います。

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

でわ。

PM2考察編・テンプレート化構想

前回の考察を受けての試みという事で、今回はPM１の過去問の内容を使って、
まずは、質問書と言われるテンプレート作成できるかやってみようと思います。

と、その前に、過去問の午後1と午後2のそれぞれの問題傾向（カテゴリ的なもの）を見てみようと
思います。
というのも、こういった対策本などに書かれているのは、午後2対策で論じるために必要なプロット
をその場で考えるのではなく、あらかじめいくつかの（多ければ多いほど良い）カテゴリに合った
サービス例をサンプルとして暗記するくらいで保持しておくと良いのだそうです。
また、これらサービス例は、モジュールと呼び、このモジュールをパーツとして分解して、題意に合う
パーツを差し替えるだけでその内容を後は論じるというか、予め想定されているサンプル例を論文
として記述すればよいのである。というものです。

”え？それって実際の自分の体験でなく、しかも過去問題の内容をパクッてるから、NGでは？”
って思われる真面目な（笑）人もいるかもしれませんが、実は僕も最近までそう思ってました。
しかしながら、本当に出題者がそんなところまで採点の対象にしてるかというと多分、Noでは
ないかと思われます。

色々と出題者のコメントなどを見る限り、そういうところはどうでもよく、如何に題意に沿って、
簡潔に論じているか？に尽きるように思われるからです。

そうだとしたら、究極は、全くの未経験者でも、その役になりきる事さえできれば、午後2も論じる
事ができる、つまり合格する可能性が十分にあると思われます。

ただ、注意すべきは、この考え方は、あくまでも、今の高度情報試験精度の中で通用する考え方で、
有名なPMP試験などはご存知かもしれませんが、少なからずともPM経験をしているだけでなく、その
携わった関係者（ステークホルダー）にも承認してもらえるような状況でないと受験ができないという
過酷な条件であれば、こういう”なり切り”だけでは、正体がばれて、結果、受験すらできない事にも
なりかねませんのでご注意を。

さて、話が結構脱線してきましたので修正。。。
え、と。そんなわけで、過去問のカテゴリ傾向を列挙。して、モジュール作成をしようかと思うのです（苦笑）
ちなみに、こういう考え方はあっても実際にモジュールの作り方とか書かれているようなのは、
みあたりませんでした。
先人の合格した人の体験記（を読むのは個人的に好きではないのですが向学のため仕方なくです）を見る
限り、このモジュールを駆使して自分の経験したサービスなどと合わせてるように見受けられましたが、
どういうモジュールを用意していたなどというのは概要程度はあっても、詳細なものはないように思え
ましたので、このブログで独学研究も含め、書き留めようと思います。

◆過去問における午後1と午後2の問題比較
ここで、とりあえず、過去5年間の午後1と午後2問題についての問題の出だしである、『××××　について・・・』
という　『ｘｘｘｘ』部分をまずは以下、表にまとめてみました。

表を作りながら、結構広範囲なキーワードだと感じましたが、
左の表で僕がやりたい事は、PM1でモジュールを作成するという事、
それと、PM2でのそれぞれの題意と、PM1で作成したモジュールが
当てはめること、もしくはまったくそのまま流用できるとは思えない
ので、モジュールを流用して組み合わせることができないか？など
の考察を行えればと思います。

と書いて、あぁなるほど、と理解できないかもしれませんが、
まずは、モジュールを作成するところから始められたらと。

また、モジュールには、当然先に記した、テンプレートにも
流用しないとおかしなことになるかもしれませんので併せて
テンプレートもセットで作成しようと思います。


◆過去問モジュール作成をするため　
まずテンプレートづくりとなりますね。

ちょっと、H21の午後1（PM1)問題の問1：キャパシティ管理からやってみようと思います。



H21/PM1-1のテンプレートを（注：あくまでも個人的に）作成してみました。

あ、これはどこでも書かれている事ですが、解答の選択肢の中には、分からない的なのもありますが、
かりそめにもあなたはITサービスマネージャであるなら、分からないのは問題と自覚する必要ありです。
つまり、これは出題者のトラップであり、この選択肢『分からない』は無視すべきです。

問題文中
・中堅の日用雑貨販売会社
・インターネット上で個人消費者向けに個人カタログを公開
・売り上げを伸ばすための宣伝チャネル強化のためにWebサイトシステム更新
より、

①サービスの名称（３０字以内）
→日用雑貨販売会社の個人カタログ公開Webサイトシステム（２７文字）

サービスが対象とする企業・機関
②企業・機関などの種類・業種（選択）
→情報サービス業

③企業・機関などの規模（選択）
（＊大規模経験のない人は見栄？を張ると整合性のバランスでバレてしまいそうです。
自分の体験位何と台数規模で書こうと思います）
→１０１～３００人

④対象業務の領域（選択）
→営業・販売

システムの構成
⑤システムの形態と規模（選択＆記入）
（＊問題内のシステム構成図より）
→Webシステム（サーバ約４台*1、クライアント約３００台*2）
*1：４台とは、DBサーバ、統合監視サーバ、APサーバ、APサーバ予備機
*2：３００台とは、③の回答に合わせるため、MAX数としただけ。

⑥ネットワークの範囲（選択）

→他企業・他機関との間

ITサービスの規模・形態
⑦ITサービスの利用者
文中：インターネット上で個人利用消費者向けに・・・
より
→個人

⑧ITサービスの利用者数
（＊まぁ普通これって⑤でのクライアント台数と合わせないとねぇ）
→約３００人

⑨ITサービス提供に携わる要員数
（＊まぁ普通これって⑤の規模と運用保守体制を想定した整合性を考慮すべきかと思われます。）
→約２人（が妥当かなぁと）

ITサービスマネジメントにおけるあなたの立場
⑩あなたが所属する企業・機関など（選択）
（＊個人的に他の選択肢は不適切な気がしますのでこれは固定でいいのではと思います。）
→ソフトウェア業・情報処理・提供サービス業など

⑪あなたの担当業務
（＊個人的に他の選択肢はITSMとして不適切な気がしますのでこれは固定でいいのではと思います。）

→運用・保守

⑫あなたが所属する部門またはチームの名称

文中よりこれ↓でいいんじゃないかと。

→Webサイト運用サービス（チーム）

⑬あなたの役割（選択）

（＊この場合、これ↓以下はマネージャより下なのでやはりもう固定でこれしかないと思います）

→部門マネージャ

⑭部門またはチームの構成人数＊

え～これには但し書きもあって、⑬の役割は部門の構成人数を記述するとの事

（＊まぁさすがに２人っていうのも寂しいですが（笑）、２人だと問題になるとも思えないので・・・）

→約２人（笑）

⑮あなたの担当機関

（＊この問題は２００９年なので、初めはそれくらいからにして、期間ですが・・・）

文中より

Webサイトシステムの稼働状況を２４時間365日体制で監視し、・・・・

とあるので、まぁ最初の契約は１年間で良いかなぁと・・・てきとうですいません（苦笑）

→2009年10月～2010年9月

以上。

という事で、どうでしょうか？テンプレート作成してみましたが、この記述がPM2の試験開始とともに

行わなければいけなく、これが既に制限時間の２時間のうちの時間内に含まれているのが要チェックです。

と、書いてるといつの間にか結構長くなったので、今回はこの辺で。

次回は、この感じで、過去５年間のPM１問題、合計２３問についてテンプレート作ってみようかと思います。

でわ。