さて、午後１試験のストーリーから、午後2試験で使えるようなモジュールの抜粋をやってみようかと。
そう考えた理由は・・・例えば、あるストーリーに感情移入し、それなりに自分の頭の中で印象的な感情が芽生えた時、
その人は、そのストーリーを覚えていて、感動などしたらそのストーリーがいかに感動したかを、他の相手に伝えられるような、つまりそれだけそのストーリーが覚えてしまっているという事です。
つまり何が言いたいかというと、一般的な世間に出回ってる有名どころと言われる高度情報処理対策本に書かれていること、過去問を何度もやる。という対策方法の目的は、その問題に書かれている事を覚えるくらい問題をこなし、そして、覚えてしまう事は、その問題に出てくる登場人物ではなく、主人公であるプロジェクトマネージャは、様々な出来事に対してどんなことを考え、そしてどういう事を行ったかをあくまでもプロジェクトマネージャのお仕事としての見地で読み取る、いわゆる、それが出題者の題意というもの、題意を知れば、自ずとそれが解答という事なのかと思うのです。
資格も持っていない複数受験の経験者が各ブログなので説得力薄いかもしれませんが（苦笑）、問題を解ければよいのか？と自問自答してしまうのです。
どうせなら過去問を何回も繰り返し解く、のではなく、過去問を登場人物も意識させながらストーリ仕立てにして、さすがにその内容で感動巨編まで書くことはなかなか、というか恐らくよほどの筆致力が無い限り無理だとは思いますが、それでも、半ばむりやり？に、無茶苦茶な顧客の要求や、仲間の裏切り（笑）など、自分に降りかかる困難を振り払った主人公が、今回のプロジェクトマネージャに任命されて、新たな課題に取り組んでいく・・・っといったように勝手に思い込みながら、デフォルメ気味に、高々情報処理の過去問を壮大な感動巨編ストーリーであるかのように、読んでいくための読み物としたら、恐らく、その題意すら凌駕する過去問の読破を目指すのではないかと誇大妄想したからです（苦笑）
なので、これを少しでも興味を持って暇つぶし的に読んでみようと思った方にはぜひとも、その気持ちで、何度も繰り返し読んでみて頂けると、もしかしたら新たな視野が開けるかも？と淡い期待を抱いております。
そして次に巷に書かれている高度情報処理対策本には、
『午後２試験の例題は過去問を参考にすべし』
『午後2で問われる事例の題材をモジュール化して準備しておくべし』
である。
という事は、、この流れで過去問ストーリーを読んで感動（笑）までいかなくても、
なんとなく主人公が何をしたのかが印象に残り、その域まで達したならば、
その内容を基に午後2での出題観点となるモジュール抜粋ができるのではと考えたからです（笑）。
＜ここまで＞
生意気言うようですが、午後2の試験の経験者であればあるほど楽しめるかもしれないので、
大変申し訳ありませんが、午後2の必勝法を求めているのでしたら、ちょっとご期待には添えないかもです（ふっ）。
まぁそういう必勝法などはもっとすっごいのがあると思いますので、そちらで頑張った方が身のためです。さ～せん（苦笑）
でもです！午後１の過去問を午後2の問題風にしたらどうなるかを考えながらモジュール化できないか？と
いう試みが面白いと思った方が気に入ってくれるとうれしいかもです（笑）。
Sponsored Link
◆モジュール抜粋に際して
通常午後2のはじめてください！的な声とともに受験番号や氏名の後に必ず行わなければいけないのに、これも試験時間内に含まれるというもの、午後2の問題の最初の要と僕が勝手に思ってる、テンプレート、アンケート用紙である”質問書＊”の記述がまずありますが、午後１の試験問題にこれを当てはめるのもやっときます。
また、”特に記載なし”は、ご存知かとは思いますが、決して分からないと回答してはいけなく、一応、その選択肢もありますが、これは罠ですのでご注意を（笑）
という事で、適切な値の任意を選択するが、本問には特に重要でない項目という事になります。
＊（質問書って何なの？という方は、一応、こちらも参照ください）
また上記リンクに書かれてる質問書＝テンプレートについては、ITSMであって、PMではないのですが、
問われている事はまぁ大して変わりませんでしたので、ご参考まで。）
■質問書より
・プロジェクト名称・30字以内
⇒スマートフォン向けアプリケーションソフト開発プロジェクト
→モバイルアプリ開発プロジェクト
・システムが対象とする企業・機関
１．建設業 ２．製造業 ３．電気・ガス・熱供給・水道業 ４．運輸・通信業 ５．卸売・小売業・飲食店 ６．金融・保険・不動産業 ７．サービス業 ８．情報サービス業 ９．調査業・広告業 １０．医療・福祉業 １１．農業・林業・漁業・鉱業 １２．教育（学校・研究機関） １３．官公庁・公益団体 １４．特定業種なし １５．その他（ ）
⇒７．（SNS）サービス業
・企業・機関などの規模
１．100人以上 ２．101-300人 ３．301-1000人 ４．1001-5000人 ５．5001人以上 ６．特定なし ７．分からない
⇒特に記載なし（７以外の任意で。）
・対象業務の領域
１．経営・企画 ２．会計・経理 ３．営業・販売 ４．生産 ５．物流 ６．人事 ７．管理一般 ８．研究・開発 ９．技術・制御 １０．その他（ ）
⇒１０．その他（一般のスマホユーザ全般）
・システムの形態と規模
１．クライアントサーバシステム（ア。サーバ？台、クライアント？台） イ．分からない ２．Ｗｅｂシステム（ア。サーバ？台、クライアント？台） イ．分からない ３．メインフレームまたはオフコン（？台）及び端末 ４．組み込みシステム（ ） ５．その他（ ）
⇒本問では特にサーバ構成などの記載なし（イ以外の任意で。）
・ネットワークの範囲
１．他企業・他機関との間 ２．同一企業・同一機関などの複数事業所間 ３．単一事業所内 ４．単一部署内 ５．なし ６．その他（ ）
⇒６．法人向けだけなどでなくインターネットを用いた広範囲のユーザ全体
・システムの利用者数
１．1-10人 ２．１１－３０人 ３．３１－１００人 ４．１０１－３００人 ５．３０１－１０００人 ６．１００１－３０００人 ７．３００１人以上 ８．分からない
・総工数
１．約？人月 ２．分からない
⇒開発メンバの数が不明であり、本問の場合は工数を知る事が大して重要ではなく、むしろ基本設計工程で委任契約を結んでいた初の契約企業が次工程の詳細設計から請負契約して大丈夫かが重要となるため、まぁ、ここは任意ですかねぇ。
といっても、やはり、ここはともかく、２以外の任意でしょうね！！
・費用総額
１．約？百万円（ハードウェア費用を ア．含む イ。含まない ２．分からない
⇒特に記載なし（２以外の任意で。）
・期間
１．？年？月～？年？月 ２．分からない
１．？年？月～？年？月 ２．分からない
⇒２０１４年４月1日～２０１５年６月初め
（今回前述のとおり記載なしなので任意ですが未来でない無理のない妥当な期間かなと思います）
（今回前述のとおり記載なしなので任意ですが未来でない無理のない妥当な期間かなと思います）
・貴方が所属する企業・機関など
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒３．一般企業などのシステム部門（実際は情報システム部）
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒３．一般企業などのシステム部門（実際は情報システム部）
・あなたの担当したフェーズ
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
⇒１．システム企画・計画が本文ではここが記載ですが、PMなので、１～５すべて担当ですね。
・あなたの役割
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
⇒１．プロジェクトの全体責任者（まぁこれは何も考えず、常に固定でしょうね）
・貴方の管理対象人数
約？人～？人
約？人～？人
⇒特に記載なし（任意。）ですが、一応、U社の基本設計時のメンバとなり、詳細設計は請負なので、U社側のPMかと。
・貴方の担当期間
？年？月～？年？月
？年？月～？年？月
⇒ってこれは前回も前々回も同様任意ですね（苦笑）
まったくもって本問題に関しては、日程、時間、納期などの情報が記載されていないため、あくまでも本問題の中に限っては重要じゃあないんでしょうなぁ（苦笑）。
まったくもって本問題に関しては、日程、時間、納期などの情報が記載されていないため、あくまでも本問題の中に限っては重要じゃあないんでしょうなぁ（苦笑）。
■設問ア用の『携わったシステム開発プロジェクトの特徴』モジュール
①題材：
⇒モバイルアプリ開発プロジェクト
②体制：
P社側 ？名（モバイル開発課のQ課長・他はステークホルダの企画部ですが人数は不明）
U社側 ？名（U社・？名）
③期間：
⇒・・・書いてませんので任意。
④規模：
⇒本問では規模的な記載は特にない。これはあくまでも推測ですが、雰囲気的に割と古参のSNS企業で、結構有名でトップの位置で君臨していたけれども、アプリが陳腐化されてくるまでは特に新たな開発もせずに現状のままでなんとかやれてきたが、さすがに競合他社のおかげで規模縮小、もしくは会社の危機的状況になってきたため、ここは心機一転一攫千金（笑）を狙って一山当てて一気に業界のトップに返り咲こうと社長含めた幹部連中が画策しているのかなぁなどと勝手に思ってしまいました（笑）
⑤背景・目標：
（事実関係のみ記述）
◆背景
・本問のポイントは、大きく２点のキーワードが重要ではないかと思われます。
つまり、一点目は、
ステークホルダが企画部という点です。
⇒彼らは最も会社組織のトップから信頼され、しかもユーザとの位置関係が近いため、開発者の都合、開発者が効率よくやれるなどといった考えなどは全く耳を貸さない、そのお蔭で、品質不良と納期遅延を起こしたという黒歴史も有る（笑）という相手であるので、開発者にとって敵に回せば相当厄介であるが、味方にすればこれほど強力なキーマンはいないので、当然味方にすべき相手であるのです。PMとしてステークホルダを味方にするために行った事がポイントという訳です。
さて、二点目としまして、
リスキーな請負契約に対する対策を行った点です。
あ、もちろん、請負契約がすべてリスキーという訳ではないので誤解なきよう（苦笑）
つまり、リスキーなのは、契約すべき相手が信頼できるか否かという点です。
仮に、一見頼りにできそうと思われたのに実は全く信頼できなかったとしたらどういう恐ろしい事になるかという事が、リスク（脅威）となるわけですが、今回で言うリスクはまさに初めて契約するため、詳細設計で請負契約になった場合は、まったく都度の状況確認などは不可能となるわけなのです。え？これって、
初めて子供を厳格な全寮制の小学校に入れたのは良いが、親は学校内や寮内には入れない状態というのに、ちょっと似てるなぁと思ったのは僕だけ？（苦笑）
あ、もちろんここでいう子供はPJ(プロジェクト）、親はPMで、そして小学校は請負先という訳です。
PM：『あのぅ、うちのPJ、元気でやってますでしょうか？』
請負先:『はい！大丈夫ですから、卒業までは何も心配しないで面会もなしにしてください。』
などと言われて、卒業してきた我が子がグレてしまってたら・・・・というわけですね（笑）。
さ、さて、妄想的なたとえ話はともかく！請負先が主導で動き始める、つまり基本設計を完了させて詳細設計に入ってしまわないうちに、色々と確認し、そして危ないと思った部分にはそれ相応の制約条件、場合によっては誓約書（なども必要？）をかわしておくくらい用意周到な準備を行わないと何かあってからでは取り返しがつかないのではと思うわけです。
そして何よりも今まで契約すらしていなかったパートナー企業と、基本設計工程は委任で、移行の詳細設計からの契約は請負契約という内容で進めて本当に大丈夫か？大丈夫でなかったら何がリスキーなのか？じゃあそのリスキーな部分を対策しておく場合はどんな事に気を付ければよいのか？という点。
これら上記の２つの観点についてのPMとしてどうすべきかを背景として以下の観点でとらえておくと良いのかなと思いました。
目的
①プロジェクトの目的という訳ですが、これは冒頭で開発部長から申し渡されました。
まず期限内までに確実に、新しいモバイルアプリを市場に提供する事。
⇒本文においては納期的な数値は特に記載がないのですが、企画部の黒歴史を繰り返さないために企画部と開発規模・開発期間の制約条件に関して意識を一致させるようにする事は期限重視のためのPMとしての目的達成のための活動ではないかと思われます。
ただ、要望としては、仕様確定後の変更だってあるわけで、それはできないと言ってしまうと、目的の顧客満足度が達成されないため、ここはなんとしてでも開発完了後になるべく対応しておく必要があると考えた点がPMの行った点であり、出題者の意図でもあったという訳です。
②社内の関係者の知恵を集めて、魅力あるUI（ユーザインタフェース）のモバイルアプリを開発し、顧客満足度を向上させること。
⇒PMとして顧客満足度を向上させるためには顧客の要望に最も近いステークホルダである企画部の満足度を満たす事なのですが、直接の記述はないのですが、基本設計時点でU社の成果物を見せた（もしかしたらそれなりにユーザレビューしたかも）事で高評価を受けているという点で、PMの活動が推定されます。
③今後想定される新規端末の発売、OSの更新といった変化、及びユーザからの改善要望に対して速やかに対応できるように、十分な保守性を確保する事。
⇒この点は、U社に対して詳細設計時の請負契約条件の提案内容の中の品質管理内で歌われています。さすがです（笑）
要件
大きな要件は、対お客様の具体的な要件は特に記載がないので、要件＝プロジェクトの目標と考えると良いかもと思いました。
⑥特徴：
顧客の事を思うあまり、品質不良や納期遅延を起こしたステークホルダである企画部への調整を怠らないようにする事と、初めての請負契約を行う際のリスク対応を詳細設計が始まる前で準備しておくべき必要があるという２点がプロジェクトの特徴かなと思いました。
◆契約面：
今回は開発上の契約については対U社とで、基本設計と総合テストが委任契約で、詳細設計から結合テストまでを請負契約にて交わす。
◆リスク面
本問に対して、リスクを抽出しながら対策を施しているため、実際のリスク対策を施すための詳細設計開始がまだのため、何も起こっていないのではと思いました。
そのため、以下の観点で変更します。
◆リスク対策
・ステークホルダ対策
①リスク：基本設計計画スケジュールが企画部のおかげで守れずに黒歴史（笑）
対策⇒企画部と開発規模・開発期間の制約条件に関しての事前の意識合わせ
②リスク：仕様確定後の変更要望を受け付けなかったために、顧客満足度が得られない。
対策⇒顧客満足度を向上させるための企画部の重要な要求を開発完了後でも対応を行うようにする
・初めての委任および請負契約先（U社）対策
①リスク：基本設計に対して企画部がU社のデザインや技術力に満足しないため手戻り。
対策⇒企画部にU社がデザインした基本設計のレビューを事前に行っておく。
②リスク：詳細設計に対して請負契約で任せたためにプロジェクトの品質および納期遅延が発生。
目的：U社のプロジェクトマネジメントの実力を確認するため。
・対策１⇒U社がどのように進捗管理・品質管理を行うのかを把握する
・対策2⇒請負契約締結条件をベースにした今回の案件へのU社からの提案を求める
・U社から提示された提案内容についての対策
①リスク：進捗管理に関する提案内容について、詳細設計と製造について作成した成果物の量が報告されているだけなので品質を確保するために必要な活動の進捗状況が評価できない。
対策：⇒定期的にレビュー済の成果物の量を報告してもらうように依頼。
②リスク：品質分析評価報告書に関する提案内容について、工程の中間及び完了時に、評価対象工程について機能別・担当者別の定量的な分析を行うだけでは、評価対象工程での数値の差異だけで品質の良否を判断する事になりかねない。
対策：⇒評価対象工程だけでなく前の工程も含めた欠陥混入の原因分析を行うように依頼。
③リスク：保守の観点でコードレビューだけしかしないと、問題検知のタイミングが遅れてしまう
対策：⇒詳細設計に対する保守性のレビューを追加するように依頼。
その他、PMの依頼事項。
①ソースコードについては性的ツールを活用して指摘された潜在的な問題に対応する。
②算出されるコードメトリクスを評価して数値が適当な範囲に収まるように対応する。
◆今後の保守期間・回収機関を通じて、安定した品質を常に保てるプロセスとしたい。
PMとして、リポジトリに変更を加えた場合・・・以下のプロセスを検討するようにU社に依頼。
①単体テストの自動再実行
②静的解析ツールの自動実行
■設問における題意ポイント
午後1の題意を、IPAの採点講評や、解答例の出題趣旨を見て考えてみます。
あくまでも個人的な見解ですが、前回に引き続き今回もリスクという用語の持つ意味とリスク回避するためにはどう対処すれば良いのか、またその理由は？という点を意識して欲しいようです（笑）
が、そのためにステークホルダを特定し、早急にリスクにならないように対策を講じる事、初めて契約者に対する能力確認を行い、契約の有効性について確認をする事がリスク回避対策となると思われ、出題者のそのような意図が感じられます。
■設問の『携わったシステム開発プロジェクトの問題解決』モジュール
本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・リスクマネージメント（前回同様です）
⇒前回同様のキーワードではありますが、リスクを生む要因のパターンが、ひとつは顧客中心でプロジェクト全体にとってはいささかリスクとなるステークホルダに対する意識合わせや、事前の調整事項を優先にすべき状況かと思われます。
・ステークホルダ
⇒ポイントは、顧客の要望、つまり満足度優先であったために過去に納期遅延や品質不良を発生させた経緯があるなど、開発メンバにとってはかなり手強いとおもいがちな存在であり、敵に回すとプロジェクト自体の目的までもが達成できなくなってしまうという点を常に意識すべきかもしれません。
②PMとして実施すべき点
出題趣旨にも書かれていますが、前回同様以下の通りです。
1.リスクマネージメント
⇒上記、⑥特徴の各リスク対策にて記述のためここでは割愛。
2.リスク対応計画の策定
⇒こちらも⑥特徴の要件を参照ください。
③汎用的に使える具体例・フレーズ
・ステークホルダが曲者（笑）の場合、プロジェクトの達成度の難易度が上がります。
なにが曲者かは、色々と状況によってありますが、今回の場合は、ただ顧客の要件
最優先にするだけの存在ではなく、経営陣の信頼が厚く、そして社内での発言力が
強いという所はかなり曲者ですね（笑）。
で、結果的にステークホルダに対しては、たとえば納期に対する事前のケアと顧客
満足度に対する仕様決定後のケアを施す事にして挽回をする。
次のフレーズは初めて契約するという未知の能力に他する脅威（リスク）までもが
重なって、プロジェクトの達成を脅かそうとするケースなのかなと。
で、初めての契約先に対しては、プロジェクトマネジメント能力を詳細設計で請負
契約しても大丈夫かを見極めるために前工程である基本設計段階で、それらの
能力を先に見極めようとする点、事前に請負契約における条件に対する提案力
とその方針が正しく任せても良いものなのかどうかを確認する事で、伏線を張る
事で、挽回をする。
そのような感じではないかと思われますね。
そういえば、ステークホルダは身に染みて、超重要ですね。
え？私は結構苦手かも・・・・って言う人、はい！それでしたらそのPJは８割方失敗
の方向に傾いてるかもしれません。
もちろん、僕も苦手だったので、最悪、避けたり、ないがしろにしたりしたため、その
人は反撃という事で、最終のレビューなどで手戻り連発だったりして、泣きました（苦笑）
僕が体験した妖怪、じゃなかった、人のタイプで大きく分けるとしたら、、、
Type1：IT知識が一応あるため、技術的な内容に対していちいち口を出してうるさい。
最終的にはセキュリティ系の盲点をついて手戻りにする妖怪、じゃなく、ステークホルダ
対策例⇒このタイプは他では技術得意人という位置づけでプライド高し。そのためプライドを傷つけられると反撃に出るので、常に優位に立たせながらもまず始めにこちらの理解者と
いう存在に持って行くように頑張るしかなかった（苦笑）。
Type2：一見、お任せにして我感知せずという風なので、しばらく順調そうに見えるが、
実はイメージが湧いていない、つまりよくわかっていないので、後になるほど理解が
進んで後半になるほどようやく意と違うと騒ぎ出し手戻りさせようとする妖怪、じゃなく
ステークホルダ。
対策例⇒この手もプライドが高く、最初はわからないのでお任せにしているため、
本当にこの段階で理解してるかを早急に感知すべきであるが、聞くわけにもいかず、
聞いても忙しいとか言ってしかとされるのがおち。
そのためプロトタイプを準備して早い段階から自分のPCで密かに使用して理解して
頂くようにしたり、定期的な説明会や質疑応答・課題改善など掲示板など設けて、
直接FaceToFaceでなくても良いようにケアが必要である（あった（笑））
Type3：プロジェクト全体はどうでもよく、自分のテリトリ内で不都合や不便を感じた際に
いきなり反撃に出るかなり厄介者。しかも新しいものに敏感で今まで慣れたものが変更
する事に大変敵意むき出しで襲い掛かってくる（笑）ため、上位管理者レベルの権力を
使うのが、この手の人はもっとも有効か（だった）と思います。
試験問題にあった、社長から言ってもらうというのはもはや社命でもあり、最終奥義と
いっても過言ではないでしょうね（苦笑）
という事で、ついに本年度の勉強記録は以上となります。
個人的に試験よりもこういう勉強を工夫して楽しむのが好きだなと思いました。
試験を受かる事だけがこの勉強ではないと思いたいです。
でないと落ちたらもうやらないとか悲しすぎるなと思うのです。
途中でリタイアして受けないとか、勿体ないんですけどねぇ～
PMやITSM,もしかしたら他の高度情報処理の問題は、結構実践でも役に立てるスキル
じゃあないのかなって思うのあったりしますので、個人的にはとっても役立ってます。
皆さんもちょっと他と違うけど自分にとっては楽しくて頭に入る？という勉強法を
考えてみられたらいかがでしょうか？
もしいい方法あれば教えて欲しいですけど（苦笑）
次年度もまた何かいいねたありましたら記録再開すると思います（たぶん）
最後に・・・今回のキーワード（用語）♪
・リスクマネージメント
・ステークホルダ
・委任契約
・請負契約
・進捗管理
・品質管理
・情報セキュリティ
・リバースエンジニアリング
・レビュー
・定性と定量
・欠陥混入分析
では乞うご期待（って、もし期待して頂いてる人がいたら！ですが（笑））
