さて、今回から、午後１試験のストーリーから、午後2試験で使えるようなモジュールの抜粋をやってみようかと。
＜2015.1.21追加＞
そう考えた理由は・・・例えば、あるストーリーに感情移入し、それなりに自分の頭の中で印象的な感情が芽生えた時、
その人は、そのストーリーを覚えていて、感動などしたらそのストーリーがいかに感動したかを、他の相手に伝えられるような、つまりそれだけそのストーリーが覚えてしまっているという事です。
つまり何が言いたいかというと、一般的な世間に出回ってる有名どころと言われる高度情報処理対策本に書かれていること、過去問を何度もやる。という対策方法の目的は、その問題に書かれている事を覚えるくらい問題をこなし、そして、覚えてしまう事は、その問題に出てくる登場人物ではなく、主人公であるプロジェクトマネージャは、様々な出来事に対してどんなことを考え、そしてどういう事を行ったかをあくまでもプロジェクトマネージャのお仕事としての見地で読み取る、いわゆる、それが出題者の題意というもの、題意を知れば、自ずとそれが解答という事なのかと思うのです。
資格も持っていない複数受験の経験者が各ブログなので説得力薄いかもしれませんが（苦笑）、問題を解ければよいのか？と自問自答してしまうのです。
どうせなら過去問を何回も繰り返し解く、のではなく、過去問を登場人物も意識させながらストーリ仕立てにして、さすがにその内容で感動巨編まで書くことはなかなか、というか恐らくよほどの筆致力が無い限り無理だとは思いますが、それでも、半ばむりやり？に、無茶苦茶な顧客の要求や、仲間の裏切り（笑）など、自分に降りかかる困難を振り払った主人公が、今回のプロジェクトマネージャに任命されて、新たな課題に取り組んでいく・・・っといったように勝手に思い込みながら、デフォルメ気味に、高々情報処理の過去問を壮大な感動巨編ストーリーであるかのように、読んでいくための読み物としたら、恐らく、その題意すら凌駕する過去問の読破を目指すのではないかと誇大妄想したからです（苦笑）
なので、これを少しでも興味を持って暇つぶし的に読んでみようと思った方にはぜひとも、その気持ちで、何度も繰り返し読んでみて頂けると、もしかしたら新たな視野が開けるかも？と淡い期待を抱いております。
そして次に巷に書かれている高度情報処理対策本には、
『午後２試験の例題は過去問を参考にすべし』
『午後2で問われる事例の題材をモジュール化して準備しておくべし』
である。
という事は、、この流れで過去問ストーリーを読んで感動（笑）までいかなくても、
なんとなく主人公が何をしたのかが印象に残り、その域まで達したならば、
その内容を基に午後2での出題観点となるモジュール抜粋ができるのではと考えたからです（笑）。
＜ここまで＞
生意気言うようですが、午後2の試験の経験者であればあるほど楽しめるかもしれないので、
大変申し訳ありませんが、午後2の必勝法を求めているのでしたら、ちょっとご期待には添えないかもです（ふっ）。
まぁそういう必勝法などはもっとすっごいのがあると思いますので、そちらで頑張った方が身のためです。さ～せん（苦笑）
でもです！午後１の過去問を午後2の問題風にしたらどうなるかを考えながらモジュール化できないか？と
いう試みが面白いと思った方が気に入ってくれるとうれしいかもです（笑）。
Sponsored Link
◆モジュール抜粋に際して
通常午後2のはじめてください！的な声とともに受験番号や氏名の後に必ず行わなければいけないのに、これも試験時間内に含まれるというもの、午後2の問題の最初の要と僕が勝手に思ってる、テンプレート、アンケート用紙である”質問書＊”の記述がまずありますが、午後１の試験問題にこれを当てはめるのもやっときます。
また、”特に記載なし”は、ご存知かとは思いますが、決して分からないと回答してはいけなく、一応、その選択肢もありますが、これは罠ですのでご注意を（笑）
という事で、適切な値の任意を選択するが、本問には特に重要でない項目という事になります。
＊（質問書って何なの？という方は、一応、こちらも参照ください）
また上記リンクに書かれてる質問書＝テンプレートについては、ITSMであって、PMではないのですが、
問われている事はまぁ大して変わりませんでしたので、ご参考まで。）
■質問書より
・プロジェクト名称・30字以内
⇒モニタリングシステム
・システムが対象とする企業・機関
１．建設業 ２．製造業 ３．電気・ガス・熱供給・水道業 ４．運輸・通信業 ５．卸売・小売業・飲食店 ６．金融・保険・不動産業 ７．サービス業 ８．情報サービス業 ９．調査業・広告業 １０．医療・福祉業 １１．農業・林業・漁業・鉱業 １２．教育（学校・研究機関） １３．官公庁・公益団体 １４．特定業種なし １５．その他（ ）
⇒４．運輸・通信業（通信事業）
・企業・機関などの規模
１．100人以上 ２．101-300人 ３．301-1000人 ４．1001-5000人 ５．5001人以上 ６．特定なし ７．分からない
⇒特に記載なし（７以外の任意で。）
・対象業務の領域
１．経営・企画 ２．会計・経理 ３．営業・販売 ４．生産 ５．物流 ６．人事 ７．管理一般 ８．研究・開発 ９．技術・制御 １０．その他（ ）
⇒１．経営・企画（経営管理部）
・システムの形態と規模
１．クライアントサーバシステム（ア。サーバ？台、クライアント？台） イ．分からない ２．Ｗｅｂシステム（ア。サーバ？台、クライアント？台） イ．分からない ３．メインフレームまたはオフコン（？台）及び端末 ４．組み込みシステム（ ） ５．その他（ ）
⇒本問では特にサーバ構成などの記載なし（イ以外の任意で。）
・ネットワークの範囲
１．他企業・他機関との間 ２．同一企業・同一機関などの複数事業所間 ３．単一事業所内 ４．単一部署内 ５．なし ６．その他（ ）
⇒２．同一企業・同一機関などの複数事業所間（各事業部と経営管理部がメイン）
・システムの利用者数
１．1-10人 ２．１１－３０人 ３．３１－１００人 ４．１０１－３００人 ５．３０１－１０００人 ６．１００１－３０００人 ７．３００１人以上 ８．分からない
・総工数
１．約？人月 ２．分からない
⇒開発メンバの数が不明であるが６か月の期間のため、Y人だと６Y人月と考えられますが、４月から2か月間はS課長が仕様確定のための上流工数が必要なので、６Y＋２人月でしょうか？
（２以外の任意で。）
・費用総額
１．約？百万円（ハードウェア費用を ア．含む イ。含まない ２．分からない
⇒特に記載なし（２以外の任意で。）
・期間
１．？年？月～？年？月 ２．分からない
１．？年？月～？年？月 ２．分からない
⇒２０１４年４月1日～２０１５年１月初め
（年度は記載なしなので任意ですが未来でない直近がいいかなと思います）
（年度は記載なしなので任意ですが未来でない直近がいいかなと思います）
・貴方が所属する企業・機関など
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒３．一般企業などのシステム部門
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒３．一般企業などのシステム部門
・あなたの担当したフェーズ
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
⇒１．システム企画・計画が本文に記載部分ですが、PMなので、１～５すべて担当ですね。
・あなたの役割
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
⇒１．プロジェクトの全体責任者
・貴方の管理対象人数
約？人～？人
約？人～？人
⇒特に記載なし（任意。）
・貴方の担当期間
？年４月～？年１２月
？年４月～？年１２月
⇒まぁプロジェクトマネージャなので、最後の年明けの1月まで面倒を見る事になると思われるので、現年４月１日～翌年１月初めまでで計画されているが、もしかしたら、担当期間は翌年の２月頃の様子を見る間しばらくは立ち合い期間として考慮すべきかもしれませんね（ってこれは前回も前々回も同様任意ですが（苦笑））
■設問ア用の『携わったシステム開発プロジェクトの特徴』モジュール
①題材：
⇒C社の経営状況モニタリングシステムのプロジェクト計画の策定
②体制：
C社 ？名（経営管理部のD部長、システム部、他・詳細人数は不明）
R社 ？名（開発メンバ）
③期間：
⇒現年４月1日～翌年１月初めが繁忙期のため稼働させる必要がある。
④規模：
⇒本問冒頭では様々な事業分野へ進出し事業規模が拡大とある。
⑤背景・目標：
（事実関係のみ記述）
◆背景
・経営管理部が策定した経営状況モニタリングシステム開発の計画書の内容について、PMであるS課長が関係各位にヒアリングをして事実関係の真偽を確認したところ、実際とは大幅に食い違うギャップ部分があり、計画の見直しが必要となった。
◆経営状況モニタリングシステム開発の計画書の内容のギャップ（GAP)とは？
目的
・各事業部の報告書から、経営管理部が手作業で集計している部分をシステム化する。
要件
・各事業部の既存の業務システムから必要なデータを抽出し経営会議資料に集約する
GAP：ところが実際は・・・
→類似のデータ項目がありデータ項目間の整合性は必ずしも取れていないため、
必要なデータ抽出を絞り込むのが困難。（事実手作業での集計もそのため手間取ってる模様）
・データ集計とレポート作成だけの機能で済む
GAP：ところが実際は・・・
→モニタリングシステム開発としてはそれだけの機能かもしれないが、その機能実現させるために、まずは開発前の全社の業務プロセスの整理と既存システム改修、つまりは、各事業部の業務システムのデータ項目間の整合性を取る事が先決であった。
・各事業部との調整は不要。
GAP：ところが実際は・・・
→不要どころか各事業部との調整なしでは、完全にプロジェクトは破綻、つまり納期に守れない、品質が悪いなどの状況が予想されると言える。
・開発期間は6か月と短期間。
GAP：ところが実際は・・・
→６か月が周知のとおり、データ集計とレポート作成にかかる期間だとわかれば、ここも当然見直しが必要なのは自明です。
経営会議メンバへのヒアリングより
（C社の社長からの所感と要望）
・経営会議資料のとりまとめ時間が遅い
・各事業部の状況を同一の指標で比較評価する必要性を感じている
・整合性のある正確な情報をモニタリングシステムから得られることを期待
⑥特徴：
今回の大きなポイントは、予めC社の経営管理部が策定した計画書の内容は、実際には大きくかけ離れたギャップがありすぎたために再度見直し作成をする事になったという点である。
プロジェクトマネージャは当然、こんなんじゃやれませんよ！的な事は思っても言うべきでない（笑）ので、リスク管理、対応という事でまず現在の計画書を正とした場合のギャップが有る事をリスクとして受け止めなければいけなく、しかも、実際に関係者から事情聴取を行い、刑事じゃないので関係者が嘘を言わないであろう（苦笑）から、彼らの話が真実であるなら、先に片付けておかなければいけないリスク回避として改善策を立て、計画が誤っている事を証明すべきである。
◆契約面：
今回はC社がR社に要件定義などの上流工程は委任レベルで開発工程からの全工程が請負のようにしたかったのだが、実際は要件定義も見直しが入ったためほぼ全工程を担当するような契約になったと思われるが詳細は書かれていなかったので、これはあくまでも推測です。。
◆事実関係：
関係者からの事情聴取により表面化されたギャップ面を考慮して、結果的に納期延長となったプロジェクト実行計画を策定した。事実関係は上記要件部分のGAPに記載。
◆リスク面
そもそもの当初策定された計画書内容に書かれた、要件および納期がリスク
＜補足＞
・今回はステークホルダであるC社社長の要望の実現がポイントかと。
つまり、要望をかなえようとしたら納期が守られず、納期を守れば要望がかなえられなくなります。
当然後者ではシステムを作る意味、目的がまったくないため、前者の要望の実現のために納期延長はやむを得なくなった。要するに、前半2か月はシステムの目的となる機能開発のためにはリスク回避を行う必要があるという事かと。
■設問における題意ポイント
午後1の題意を、IPAの採点講評や、解答例の出題趣旨を見て考えてみます。
あくまでも個人的な見解ですが、今回はリスクという用語の持つ意味とリスク回避するためにはどう対処すれば良いのかという点を意識して欲しいようです（笑）
またその手段には当たり前ですが、事前調査や一歩、いやもっと先を読む将棋のように読む予知スキルを必要とし、つまりは先にどんなリスク（脅威・危険）な事になるかをどれだけ正確に予想、推測、予言（笑）できるか、どれだけ漏れなくリスク抽出を行ったのか、そしてそれらリスクに対してどれだけの回避・予防・改善策を講じているかを意識する事がポイントかなと思いました。
ちなみに、ちょっと本題とそれますが、
僕が思うリスクマネージメントって、誰でも第三者的な立場で何かが起こった時に、何でも言える癖に（言葉荒くて失礼）、当事者として何かが起こる前に事前にそうならないように対策を講じる事を面倒だ、無駄だと感じて、適当な考えでいる人がなんと多い事かと残念に思う。
つまり何かが起こる前に予知、予見をするだけでなく、それらの回避策を講じ、それだけでもなく実践する能力が必要なんだと感じます。
もしかしたら、リスクは起こらず、無駄になる事もあるかもしれませんが、それでも本当にそのリスクが起きて何も回避策がなかったら、それは何もやってなかったと責められるのです。”備えあれば憂いなし”という事です。
リスク回避は抽出以上に気を遣うかもしれませんので、面倒がってやらない、やれないのかもと実感します。
はい、脱線でした（笑）
■設問の『携わったシステム開発プロジェクトの問題解決』モジュール
本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・リスクマネージメント
⇒C社のD部長から受け取ったであろうプロジェクト計画書の内容は、あまりにも現実のリスクを無視した内容であったのですが、僕はこの現状は結構現実の現場でも起こっている事だと感じました（苦笑）。
実は本題からそれるのですが、、、
僕が経験した似たような思い出は、あるシステムの改善といってもほとんど作り直しに近いシステムの計画書でした。
当時の僕はまだ疑う事もせず、その計画書に沿って開発を進めようとしましたが、途中の要件定義中盤からかなりGAPがあるなと思った事がありました。
それは当初は旧システム改善だったので、本題のように現システムの機能改善くらいにしか思ってなかったのですが、ステークホルダである業務窓口の要望が、現実のシステム機能を超越した改善というのは名ばかりで、まったく仕様も最新の内容ばかりであったという事実でした。
今ならその段階でまずは上司に報告し、納期調整を今回の本題のS課長のようにC社のD部長にお願いする事になるために見直しを行うべきだったのですが、それを行わず、ステークホルダである業務窓口の要件を追加して納期調整をあまり行わなかったという経験があります。
ただ奇跡的にもそれでもなんとか納期的に収まりそうに勢いだけで乗り切ったと安心したのも束の間、第二のステークホルダが途中から出現してきて、それは現システムと連携をしている他システムの担当窓口だったのですが、これが最悪で、最初の業務窓口と決めた仕様では連携に影響が出るため容認できないという、もはや要件定義終盤段階でひっくり返される羽目になり、結果的に僕のプロジェクトは納期遅れもおこし、今思うとかなり封印したい”苦いおもひで”ですね（苦笑）
で、御陰で得たスキルは、ステークホルダの判断を見誤るな。でした。
僕の場合、第二と思った他システムの業務担当者が実は重要なキーマンだったのです。
彼は最初から参画していたシステム的な内容に疎い業務担当者と違い、システム技術にはかなり詳しく、そのため彼の言動が基幹システムの仕様ですら少なからず影響を受けていたため、むしろ彼と要件定義を行った方が成功していたかもしれないと今しみじみと思うのです。
プロジェクトの特性上、いわゆるキーマンの要望は絶対であり、逆にキーマンの要望が満足されれば、おおざっぱでもプロジェクトとしては成功と言っても過言ではないという事です。
ただ、キーマンに限った事でもないかもしれませんが、プロジェクトに対する要望は、そう簡単に満足のいく結果とはいかないのが悲しい世の常だなと感じます。
キーマンの要望の実現と、それに対する納期遵守がバランスよく保てなくなった時に、リスクが生まれると思われます。
っと、本題に戻ります（苦笑）
②PMとして実施すべき点
ここで本問に出てくるプロジェクトマネージャとして行った事は何かといえば、、、
出題趣旨にも書かれていますが、以下の通りです。
1.リスクマネージメント
⇒初期の計画書のままでは要望を実現させるためには、納期遅れを起こしてしまうため、納期延長および開発要員の増員などの可能性について検討を行った。
2.コミュニケーション
⇒リスクマネージメントには定性、定量などの解析手法がありますが、リスクを抽出するためにはまずやはり有識者などの情報収集が一番確実であるわけですが、彼らの意見の信憑性の見極めも重要であるため、本題ではC社のD部長に納期遵守の可能性についてせっつかれながらも冷静に、まずは以下の人達にヒアリングを行い、リスクはどれくらいの影響を及ぼすかを検討した。
①R社のT課長にC社の業務システムの状況をヒアリング
→T課長は自社でもあり、今回浮上してきたリスクとなる重要な情報源でした。
②経営会議メンバ（といってもほとんどC社の社長が中心ですが（笑））へのヒアリング
→ここで得られた情報（要望）は計画から見直すべきだとS課長が確信できました。
③C社のシステム部（担当者）へのヒアリング
→①でT課長からW社のミドルウェアベースの移行計画があるため、開発関係者の人員増員が測れないことを聞いて、その事実確認を行い、増員できそうだという事実を知りました。
結果的に、①でリスク抽出をし、②③でその事実確認を行いました。
また、肝心の計画の見直しとは、スケジュール延長と人員の増員でしたが、
②でスケジュール延長、③で人員の増員が見込まれたと考えられます。
3.リスク対応計画の策定
⇒今回テーマ自体がリスク対応計画の策定＝計画の見直しにつながっているように思えました。
具体的な策定内容としては、以下と考えられます。
リスク１：スケジュールが短期
計画→C社の社長の要望実現のために解決しなければいけない課題について２か月延期した
リスク２：開発要員が少ない
計画→要員を調達できない原因がW社のミドルウェア導入のため自社からの要員が駆り出されてしまっているという点に目をつけ、幸いにもミドルウェア導入計画は、現状かなりリスキーという事で、採用は断念してもらい、こちらの開発に駆り出されている要員から補充するように調整した。
③汎用的に使える具体例・フレーズ
・今回のように当初策定したプロジェクト計画の見直しまでになるケースは、色々と難しいと思う。
一度会社内で決定した内容を変えるためにはそれ相応の材料が必要であるからです。
そのため、本題では基本とも言える、計画書についての現状・事実確認を行っったと思います。
つまり、ヒアリングにを行い、その聞いた内容の事実確認、で、そのまた事実確認・・・という風に、
この業界、聞いた。とか、思う。などというのでなく自分の目でしっかりと確かめるために、まず人を疑う（などというと性格悪くなりそうですが実際はそれくらいが良いと思うのです（苦笑））事から始めるべきだと思うのです。
間違っても、あの人がやったから、間違いない！などといって手抜きして事実確認をしないという事のないようにしないと、そこにリスクが潜んでるかもしれないなと思うのです。
まぁ実際は、ステークホルダのいう事は、社長であればもうこれは絶対であり、それを遵守するために費用対効果を見出さない限り、見直すなんて難しく、もしW社のミドルウェアが計画通り順調であるのが、現実かもしれないので開発要員不足で品質が問われる状況になりうるかもしれないなと思います。
S課長はラッキーとしか思えないです（笑）
以上となります。
最後に・・・今回のキーワード（用語）♪
・リスクマネージメント
・コミュニケーション
・ステークホルダ
本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・リスクマネージメント
⇒C社のD部長から受け取ったであろうプロジェクト計画書の内容は、あまりにも現実のリスクを無視した内容であったのですが、僕はこの現状は結構現実の現場でも起こっている事だと感じました（苦笑）。
実は本題からそれるのですが、、、
僕が経験した似たような思い出は、あるシステムの改善といってもほとんど作り直しに近いシステムの計画書でした。
当時の僕はまだ疑う事もせず、その計画書に沿って開発を進めようとしましたが、途中の要件定義中盤からかなりGAPがあるなと思った事がありました。
それは当初は旧システム改善だったので、本題のように現システムの機能改善くらいにしか思ってなかったのですが、ステークホルダである業務窓口の要望が、現実のシステム機能を超越した改善というのは名ばかりで、まったく仕様も最新の内容ばかりであったという事実でした。
今ならその段階でまずは上司に報告し、納期調整を今回の本題のS課長のようにC社のD部長にお願いする事になるために見直しを行うべきだったのですが、それを行わず、ステークホルダである業務窓口の要件を追加して納期調整をあまり行わなかったという経験があります。
ただ奇跡的にもそれでもなんとか納期的に収まりそうに勢いだけで乗り切ったと安心したのも束の間、第二のステークホルダが途中から出現してきて、それは現システムと連携をしている他システムの担当窓口だったのですが、これが最悪で、最初の業務窓口と決めた仕様では連携に影響が出るため容認できないという、もはや要件定義終盤段階でひっくり返される羽目になり、結果的に僕のプロジェクトは納期遅れもおこし、今思うとかなり封印したい”苦いおもひで”ですね（苦笑）
で、御陰で得たスキルは、ステークホルダの判断を見誤るな。でした。
僕の場合、第二と思った他システムの業務担当者が実は重要なキーマンだったのです。
彼は最初から参画していたシステム的な内容に疎い業務担当者と違い、システム技術にはかなり詳しく、そのため彼の言動が基幹システムの仕様ですら少なからず影響を受けていたため、むしろ彼と要件定義を行った方が成功していたかもしれないと今しみじみと思うのです。
プロジェクトの特性上、いわゆるキーマンの要望は絶対であり、逆にキーマンの要望が満足されれば、おおざっぱでもプロジェクトとしては成功と言っても過言ではないという事です。
ただ、キーマンに限った事でもないかもしれませんが、プロジェクトに対する要望は、そう簡単に満足のいく結果とはいかないのが悲しい世の常だなと感じます。
キーマンの要望の実現と、それに対する納期遵守がバランスよく保てなくなった時に、リスクが生まれると思われます。
っと、本題に戻ります（苦笑）
②PMとして実施すべき点
出題趣旨にも書かれていますが、以下の通りです。
1.リスクマネージメント
⇒初期の計画書のままでは要望を実現させるためには、納期遅れを起こしてしまうため、納期延長および開発要員の増員などの可能性について検討を行った。
2.コミュニケーション
⇒リスクマネージメントには定性、定量などの解析手法がありますが、リスクを抽出するためにはまずやはり有識者などの情報収集が一番確実であるわけですが、彼らの意見の信憑性の見極めも重要であるため、本題ではC社のD部長に納期遵守の可能性についてせっつかれながらも冷静に、まずは以下の人達にヒアリングを行い、リスクはどれくらいの影響を及ぼすかを検討した。
①R社のT課長にC社の業務システムの状況をヒアリング
→T課長は自社でもあり、今回浮上してきたリスクとなる重要な情報源でした。
②経営会議メンバ（といってもほとんどC社の社長が中心ですが（笑））へのヒアリング
→ここで得られた情報（要望）は計画から見直すべきだとS課長が確信できました。
③C社のシステム部（担当者）へのヒアリング
→①でT課長からW社のミドルウェアベースの移行計画があるため、開発関係者の人員増員が測れないことを聞いて、その事実確認を行い、増員できそうだという事実を知りました。
結果的に、①でリスク抽出をし、②③でその事実確認を行いました。
また、肝心の計画の見直しとは、スケジュール延長と人員の増員でしたが、
②でスケジュール延長、③で人員の増員が見込まれたと考えられます。
3.リスク対応計画の策定
⇒今回テーマ自体がリスク対応計画の策定＝計画の見直しにつながっているように思えました。
具体的な策定内容としては、以下と考えられます。
リスク１：スケジュールが短期
計画→C社の社長の要望実現のために解決しなければいけない課題について２か月延期した
リスク２：開発要員が少ない
計画→要員を調達できない原因がW社のミドルウェア導入のため自社からの要員が駆り出されてしまっているという点に目をつけ、幸いにもミドルウェア導入計画は、現状かなりリスキーという事で、採用は断念してもらい、こちらの開発に駆り出されている要員から補充するように調整した。
③汎用的に使える具体例・フレーズ
・今回のように当初策定したプロジェクト計画の見直しまでになるケースは、色々と難しいと思う。
一度会社内で決定した内容を変えるためにはそれ相応の材料が必要であるからです。
そのため、本題では基本とも言える、計画書についての現状・事実確認を行っったと思います。
つまり、ヒアリングにを行い、その聞いた内容の事実確認、で、そのまた事実確認・・・という風に、
この業界、聞いた。とか、思う。などというのでなく自分の目でしっかりと確かめるために、まず人を疑う（などというと性格悪くなりそうですが実際はそれくらいが良いと思うのです（苦笑））事から始めるべきだと思うのです。
間違っても、あの人がやったから、間違いない！などといって手抜きして事実確認をしないという事のないようにしないと、そこにリスクが潜んでるかもしれないなと思うのです。
まぁ実際は、ステークホルダのいう事は、社長であればもうこれは絶対であり、それを遵守するために費用対効果を見出さない限り、見直すなんて難しく、もしW社のミドルウェアが計画通り順調であるのが、現実かもしれないので開発要員不足で品質が問われる状況になりうるかもしれないなと思います。
S課長はラッキーとしか思えないです（笑）
以上となります。
最後に・・・今回のキーワード（用語）♪
・リスクマネージメント
・コミュニケーション
・ステークホルダ
さて、次回はどんな使えるモジュールがあるのでしょうか？
などと勝手に盛り上がってしまってますが、ご容赦を（苦笑）
あ、本ブログは、過去問ストーリーが終わってからの記述となります。
では乞うご期待（って誰が？（笑））
