午後2で使えるモジュール⇒H25・午後１_問3。

◆はじめに・・・
さて、今回から、午後１試験のストーリーから、午後2試験で使えるようなモジュールの抜粋をやってみようかと。

そう考えた理由は・・・例えば、あるストーリーに感情移入し、それなりに自分の頭の中で印象的な感情が芽生えた時、
その人は、そのストーリーを覚えていて、感動などしたらそのストーリーがいかに感動したかを、他の相手に伝えられるような、つまりそれだけそのストーリーが覚えてしまっているという事です。
つまり何が言いたいかというと、一般的な世間に出回ってる有名どころと言われる高度情報処理対策本に書かれていること、過去問を何度もやる。という対策方法の目的は、その問題に書かれている事を覚えるくらい問題をこなし、そして、覚えてしまう事は、その問題に出てくる登場人物ではなく、主人公であるプロジェクトマネージャは、様々な出来事に対してどんなことを考え、そしてどういう事を行ったかをあくまでもプロジェクトマネージャのお仕事としての見地で読み取る、いわゆる、それが出題者の題意というもの、題意を知れば、自ずとそれが解答という事なのかと思うのです。
資格も持っていない複数受験の経験者が各ブログなので説得力薄いかもしれませんが（苦笑）、問題を解ければよいのか？と自問自答してしまうのです。

どうせなら過去問を何回も繰り返し解く、のではなく、過去問を登場人物も意識させながらストーリ仕立てにして、さすがにその内容で感動巨編まで書くことはなかなか、というか恐らくよほどの筆致力が無い限り無理だとは思いますが、それでも、半ばむりやり？に、無茶苦茶な顧客の要求や、仲間の裏切り（笑）など、自分に降りかかる困難を振り払った主人公が、今回のプロジェクトマネージャに任命されて、新たな課題に取り組んでいく・・・っといったように勝手に思い込みながら、デフォルメ気味に、高々情報処理の過去問を壮大な感動巨編ストーリーであるかのように、読んでいくための読み物としたら、恐らく、その題意すら凌駕する過去問の読破を目指すのではないかと誇大妄想したからです（苦笑）

なので、これを少しでも興味を持って暇つぶし的に読んでみようと思った方にはぜひとも、その気持ちで、何度も繰り返し読んでみて頂けると、もしかしたら新たな視野が開けるかも？と淡い期待を抱いております。

そして次に巷に書かれている高度情報処理対策本には、
『午後２試験の例題は過去問を参考にすべし』
『午後2で問われる事例の題材をモジュール化して準備しておくべし』
である。

という事は、、この流れで過去問ストーリーを読んで感動（笑）までいかなくても、
なんとなく主人公が何をしたのかが印象に残り、その域まで達したならば、
その内容を基に午後2での出題観点となるモジュール抜粋ができるのではと考えたからです（笑）。

＜ここまで＞

生意気言うようですが、午後2の試験の経験者であればあるほど楽しめるかもしれないので、

大変申し訳ありませんが、午後2の必勝法を求めているのでしたら、ちょっとご期待には添えないかもです（ふっ）。
まぁそういう必勝法などはもっとすっごいのがあると思いますので、そちらで頑張った方が身のためです。さ～せん（苦笑）

でもです！午後１の過去問を午後2の問題風にしたらどうなるかを考えながらモジュール化できないか？と
いう試みが面白いと思った方が気に入ってくれるとうれしいかもです（笑）。

Sponsored Link

◆モジュール抜粋に際して
通常午後2のはじめてください！的な声とともに受験番号や氏名の後に必ず行わなければいけないのに、これも試験時間内に含まれるというもの、午後2の問題の最初の要と僕が勝手に思ってる、テンプレート、アンケート用紙である”質問書＊”の記述がまずありますが、午後１の試験問題にこれを当てはめるのもやっときます。
また、”特に記載なし”は、ご存知かとは思いますが、決して分からないと回答してはいけなく、一応、その選択肢もありますが、これは罠ですのでご注意を（笑）
という事で、適切な値の任意を選択するが、本問には特に重要でない項目という事になります。

＊（質問書って何なの？という方は、一応、こちらも参照ください）
また上記リンクに書かれてる質問書＝テンプレートについては、ITSMであって、PMではないのですが、
問われている事はまぁ大して変わりませんでしたので、ご参考まで。）

問3：システム開発プロジェクトの企業合併に伴う計画変更について

■質問書より

・プロジェクト名称・30字以内
⇒アパレル業務システムを更改する開発プロジェクト→A社プロジェクト→新プロジェクト

・システムが対象とする企業・機関
１．建設業　２．製造業　３．電気・ガス・熱供給・水道業　４．運輸・通信業　５．卸売・小売業・飲食店　６．金融・保険・不動産業　７．サービス業　８．情報サービス業　９．調査業・広告業　１０．医療・福祉業　１１．農業・林業・漁業・鉱業　１２．教育（学校・研究機関）　１３．官公庁・公益団体　１４．特定業種なし　１５．その他（　　　）
⇒15．アパレル業

・企業・機関などの規模
１．100人以上　２．101-300人　３．301-1000人　４．1001-5000人　５．5001人以上　６．特定なし　７．分からない
⇒特に記載なし（７以外の任意で。）

・対象業務の領域
１．経営・企画　２．会計・経理　３．営業・販売　４．生産　５．物流　６．人事　７．管理一般　８．研究・開発　９．技術・制御　１０．その他（　　）
⇒１．経営・企画（経営管理部）

・システムの形態と規模
１．クライアントサーバシステム（ア。サーバ？台、クライアント？台）　イ．分からない　２．Ｗｅｂシステム（ア。サーバ？台、クライアント？台）　イ．分からない　３．メインフレームまたはオフコン（？台）及び端末　４．組み込みシステム（　　）　５．その他（　　　）
⇒本問では特にサーバ構成などの記載なし（イ以外の任意で。）

・ネットワークの範囲
１．他企業・他機関との間　２．同一企業・同一機関などの複数事業所間　３．単一事業所内　４．単一部署内　５．なし　６．その他（　　）
⇒２．同一企業グループの全事業所（全社プロジェクトであり合併対象のM社も含む）

・システムの利用者数
１．1-10人　２．１１－３０人　３．３１－１００人　４．１０１－３００人　５．３０１－１０００人　６．１００１－３０００人　７．３００１人以上　８．分からない

⇒特に記載なし（８以外の任意で。）

・総工数
１．約？人月　２．分からない
⇒開発メンバの数が不明であるが、結果的に合併前の２か月でB部長１人で作成した要件定義をそのまま流用してからの計１０か月の各工程でしかもM社に関する工程も併せると以下のように考えられるかなと。
①要件定義：2人月
②A社設計：X人として、３X人月
③A社製造：Y人として、３Y人月
④A社結合・総合テスト：Z人として、３Z人月
⑤A社とM社の合同・移行方式設計：α人として、３ヶ月くらいを想定し、３α人月
⑥A社移行ツール開発：W人として２W人月
⑦A社とM社の運用テスト：β人として、３β人月
⑧M社の移行ツール開発：γ人として、２γ人月
とまぁ、だいたいこんな感じで、計①～⑧の合計人月となりますかねぇ。

まぁそれはともかく、２以外の任意で！！

・費用総額
１．約？百万円（ハードウェア費用を　ア．含む　イ。含まない　２．分からない
⇒特に記載なし（２以外の任意で。）

・期間
１．？年？月～？年？月　２．分からない

⇒２０１４年４月1日～２０１５年６月初め
（年度は記載なしなので任意ですが未来でない直近がいいかなと思います）

・貴方が所属する企業・機関など
１．ソフトウェア業・情報処理・提供サービス業など　２．コンピュータ製造・販売業など　３．一般企業などのシステム部門　４．一般企業などのその他の部門　５．その他（　　）
⇒３．一般企業などのシステム部門（実際は情報システム部）

・あなたの担当したフェーズ
１．システム企画・計画　２．システム設計　３．プログラム開発　４．システムテスト　５．移行・運用　６．その他（　　）

⇒１．システム企画・計画が本文ではここが記載ですが、PMなので、１～５すべて担当ですね。

・あなたの役割
１．プロジェクトの全体責任者　２．プロジェクト管理スタッフ　３．チームリーダ　４．チームサブリーダ　５．その他（　　　）

⇒１．プロジェクトの全体責任者（まぁこれは固定でしょうね）

・貴方の管理対象人数
約？人～？人

⇒特に記載なし（任意。）ですが、一応、M社のN課長にM社の業務部門をお任せするとした場合、B部長の管理対象は、後は自社（A社）内の何名か不明の業務部門となるかと

・貴方の担当期間
？年４月～？年６月

⇒まぁ、全社規模での重要プロジェクトのPMなので、全体を面倒を見る事になると思われるので、現年４月１日～翌年６月初めまでで計画されているが、もしかしたら、担当期間は翌年の２月頃の様子を見る間しばらくは立ち合い期間として考慮すべきかもしれませんね（ってこれは前回も前々回も同様任意ですが（苦笑））

■設問ア用の『携わったシステム開発プロジェクトの特徴』モジュール

①題材：
⇒業務プロセス一新のためのA社の基幹（ERPパッケージ）システムの更改プロジェクト

②体制：
A社側　？名（情報システム部のB部長、業務部門？名、他・詳細人数は不明）

M社側　？名（管理課・N課長と業務部門？名）

③期間：
⇒現年４月1日～当初４月初めであったがM社合併で翌年６月初めに稼働時期を延期。

④規模：
⇒本問冒頭でA社は東京中心の東日本を商圏とした中堅企業とあり、合併企業であるM社は大阪中心の関西地方に顧客基盤を持っていて、合併後は全国規模企業と記載。

⑤背景・目標：
（事実関係のみ記述）
◆背景
・本問のポイントは、業務プロセスを一新したシステムとなった事で、社内の業務部門からの抵抗などがあり、デモ環境などで社内評価を高め、ようやく要件定義も終了した時に、M社との合併話が持ち上がり、PMである情報システム部のB部長は、今までの要件定義が無駄にならない事を確認したうえで、次工程からはM社のN課長を味方につけるためにN課長への要件定義の理解を重視し、その後移行方式設計などはA社とM社共同で行う、M社に対して抵抗感を示さないように両者の社長からの要請依頼も行う事で、リスク対策を講じた点かなぁと。

◆A社システム　→　A社・新システムへ変更

目的
・業務プロセスを一新して業務効率を飛躍的に改善する事

要件
●当初（M社合併前）
・V社のERPパッケージ導入　
⇒リスク：現行の業務プロセス変更に対する業務部門の抵抗による要件定義の遅れ
　　対策：V社のデモ環境を使用して検討を繰り返す

●現在（M社合併時）
⇒リスク１：M社から既に完了した要件定義の内容変更要求があり、手戻りが発生する。
　　実情：M社の業務プロセスをA社の新システムの業務プロセスに統一するため、特に対策を講じる必要もなくM社にとっては開発スコープに影響がないため要件定義は従来の内容で大きな変更の必要は不要となった。

⇒リスク２：M社の業務プロセスの理解が無知なため移行方式設計が短期間で終わらない
　　対策１：移行方式設計はA社とM社合同で実施。
　　対策２：前回同様、V社のデモ環境使用を先行でN課長、続いて業務部門で実施

⇒リスク３：６月と12月に行われるM社の基幹システムの定期改修で、データ仕様が変わってしまう場合、定期改修後の移行方式設計の着手時期に影響が出る

　　対策１：６月の定期改修が済めば、9月の移行方式設計までにデータの仕様の凍結を行う

　　対策２：12月の定期改修は中止

⇒リスク４：M社の業務部門が業務プロセスを迅速に理解できないため、当初予定の1か月の基幹では運用テストが完了できない

　　対策１：M社合併という事で、３か月に延長し運用テストで発生する問題に対応する時間の余裕を確保した。

⑥特徴：
今回の大きなポイントは、最初にA社システムとして要件定義まで終わらせたプロジェクトがM社の合併によりプロジェクトを見直さなければいけない事になったのだが、幸いにもM社基幹システムを捨てて完全にA社基幹システムに乗り換える事になった事で、要件定義の内容に対する変更が不要となり、以降の工程での納期遵守のため、M社合併の影響によるリスク対応を実施した点であると思われます。

今回のプロジェクトマネージャは、リスク管理、対応という事でM社が合併するという事によるプロジェクトに対してどの辺が影響となるかを把握し、その観点をリスクとして受け止めなければいけなく、実際に合併側のM社内の人間の窓口をN課長として、M社でのステークホルダでもあるM社の業務部門への取り纏めは、N課長にお任せするという風にして、自信の負荷も、リスクとなる事を肝に銘じて、リスク対応という事で除去すべきであると思われます。

◆契約面：
今回は開発上の契約については特に無関係で対象外となります。

◆事実関係：
M社合併により影響が出ると想定された点を考慮して、納期延長としたプロジェクト実行計画を再度策定した。

◆リスク面
上記、⑤背景・目標の要件に記載の通りです。
＜補足＞
・今回はステークホルダであるM社のA社の新業務プロセスの理解度合がポイントかなぁと。

一応色々と対策は練られているのですが、やはりまだまだ不安な点があるなぁと。
つまり、A社と共同で実施して理解してもらおうとしたが、A社要員ももしかしたら同時期に行われるV社ERP導入の製造時期と重なってしまって、十分にケアできなかった場合、やはり理解度が不完全なままでM者側の品質の落ちる移行方式設計が出来てしまうかもしれません。そのため、特に問題文中には書かれてませんでしたが、やはりここはA社の業務部門にも一役買って頂き、最終的にできた移行方式設計の品質チェックにも可能な限り参画願いたいところだなと思いました。
そういう意味でも移行方式設計要員は、情シスの開発メンバ＋A社業務部門かなぁと。

■設問における題意ポイント
午後1の題意を、IPAの採点講評や、解答例の出題趣旨を見て考えてみます。
あくまでも個人的な見解ですが、前回に引き続き今回もリスクという用語の持つ意味とリスク回避するためにはどう対処すれば良いのか、またその理由は？という点を意識して欲しいようです（笑）
またその手段には当たり前ですが、事前調査や一歩、いやもっと先を読む将棋のように読む予知スキルを必要とし、つまりは先にどんなリスク（脅威・危険）な事になるかをどれだけ正確に予想、推測、予言（笑）できるか、どれだけ漏れなくリスク抽出を行ったのか、そしてそれらリスクに対してどれだけの回避・予防・改善策を講じているかを意識する事がポイントかなぁ・・と、前と同じ内容になってしまいました（苦笑）

■設問の『携わったシステム開発プロジェクトの問題解決』モジュール

本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・リスクマネージメント（前回同様です）
⇒M社のN課長を味方につけるための対策と、その奥に潜む、M社業務部門に対する業務プロセスの理解の度合いを迅速に終わらせる事は、上記でも触れたように少しまだリスクを感じた内容ではあったのですが、今回のように要件定義に影響がなかったですが、恐らく結構現実の現場では要件定義にも影響が出て、手戻り状態になっているのでは？と感じました（苦笑）。

実は本題からそれるのですが、、、僕もそのような経験があります。といっても合併で要件定義が手戻りになったのではなく、完全に要件定義に誤りがあったという世にも恐ろしい事態です（苦笑）。
その話に触れる前にこの、世にも恐ろしいPJを仮にEプロと呼びましょう。
で、このEプロは、２次受けの契約で、１次受け企業で要件定義が完成し、これを受けて詳細設計を現地常駐して３人月で終わらせて後は社内に持ち帰って更に３人月で終わらせる・・・という、話を聞いたときは、結構楽なプロジェクトだなと思っていたのです。

で、我々は出来上がった要件書を正と信じるしかできないので、その内容でせっせせっせと結構順調に製造工程まで進んで、いくつかのフェーズに分かれていたので、まずフェーズ１の顧客レビューで、悪夢が始まりました。
というのも、データベースの設計（正規化の考え方）が要件段階で１か所謝ってたという事実が発覚したのです。
当然、要件定義を信じるしかなかった我々にはそこでレビューは中断となってもなすすべがなく、結果的に要件定義まで手戻りとなったEプロは今思うと泣きそうです（苦笑）

だって、顧客（といっても私たちからすれば１次受けが直接受けていた顧客なのですが）がいつの間にか直接私たちの所にエビデンスが信頼できないので単体テストのケース数を増やして精度を上げて持ってくるような要求をする事になってしまい、明日の朝にそのエビデンスの検証会議するので、よろしく！的な無理難題を何度か言われ、当然何回か徹夜して、最初数十ケースほどが、約２００ケースに膨れ上がったエビデンスづくりで身も心もボロボロになったという、あのTheナイトメア・Eプロ（笑）を思い出しましたからです（苦笑）
でも、御陰で、この業界、与えられたものでも鵜呑みして信用してはいけないという、とっても良い教訓を得ました（苦笑）

っと、本題に戻ります（苦笑）

②PMとして実施すべき点

ここで本問に出てくるプロジェクトマネージャとして行った事は何かといえば、、、
出題趣旨にも書かれていますが、前回同様以下の通りです。
1.リスクマネージメント
⇒M社合併によって、既に完成した要件定義の影響の有無、およびM社に対する業務プロセスの理解を迅速にさせるための対策を行った。

2.コミュニケーション
⇒これも前回同様リスクマネージメントには定性、定量などの解析手法がありますが、リスクを抽出するためにはまずやはり有識者などの情報収集が一番確実であるわけですが、本問では合併先のM社側代表という事で、N課長の意見のヒアリングを行い、リスクはどれくらいの影響を及ぼすかを検討した。

3.エスカレーション
⇒M社のN課長に業務部門の説得や説明を頼むだけではやはり荷が重すぎると考え、B部長は、A社とM社の両社長にも、今回導入する期間システムに対しての抵抗感を持たずに前向きな意見として評価するように強く要請して頂くようにした点であります。
やはり、社長が言えば、従わないわけにもいかないので、この点は素晴らしい行動ですねぇ。

4.リスク対応計画の策定
⇒こちらも⑤背景・目標の要件を参照ください。

③汎用的に使える具体例・フレーズ

・合併というイベントで要件定義まで進んでいた工程が再見直しで、幸いにも要件定義への影響がなかったが、それ以降の工程で色々と工夫が必要となったという点かな？と思われます。
しかもスケジュールの見直しが入った各工程には、リスクが潜んでいるわけで、PMはそれを見抜いて、対策を講じながら線引きする必要があるわけです。
今回の場合は、M社が絡む工程は、M社がA社の業務プロセスなど全く知らないため、M社データをA社側にデータ移行する事の品質が問われます。
品質を高めるために有識者、つまり、ここではA社の移行方式設計要員と共同でやりましょうという点ですが、先にも書きましたが有識者であり、さらに最初は抵抗を示していたのに評価するほどに考え方が１８０度も変わった理由・観点を体験とともに知り尽くしているA社の業務部門に、理想は移行方式設計の品質チェック、もしくはA社合同の大目で期間を設けた運用テストで参画してもらいながら、精度を高めていければ良いのかなぁと思いました。

以上となります。

最後に・・・今回のキーワード（用語）♪
う～ん、前回とさほど変わらんですかねぇ（苦笑）

・リスクマネージメント
・コミュニケーション
・エスカレーション
・ステークホルダ
・企業合併
・データ（もしくは仕様）凍結
・業務プロセス

・データ移行
・キックオフミーティング
・デモ環境

さて、次回はどんな使えるモジュールがあるのでしょうか？
などと勝手に盛り上がってしまってますが、ご容赦を（苦笑）
あ、本ブログは、過去問ストーリーが終わってからの記述となります。

では乞うご期待（って、もしいたら！ですが（笑））