2010年04月21日

2010年プロジェクトマネージャ試験 午後II 解答速報概況

2010年プロジェクトマネージャ試験 午後II 小論文の総評

■総評
  1. 非常にオーソドックスで平易で良問が多かった
  2. 問題文に指定が明確に指定されているから、指定にしたがって解けば容易に論文がかけるる。
■難易度

[難易度]★が多いほど難しい

 上記の難易度を決めた理由は次の通りである。

■問題別、小論文戦略

 合格できるか、否かについての基準を示そう。

問題 問題の必須条件 合格のための工夫
問1 プロジェクトの特徴とリスクを合理的に結び付ける 設問アで潜在的なリスクを述べておいて、対処の具体的対策を述べられるか
問2 チームリーダをいかに管理するかが課題 権限の範囲を限定して、権限を委譲しつつ、コントロールすることが要点
問3 進捗管理に品質確保がからめて出題されていることがポイント 予防対策と対処を設問イとウに切り分けて書く
■総評と解答速報
総評
●午後Ⅱ
■2010プロジェクトマネージャ試験 解答速報目次に戻る
■プロジェクトマネージャ試験小論文合格講座



投稿者 kato : 11:07 | コメント (0) | トラックバック

平成22年(2010年)度、プロジェクトマネージャ試験 午後II 問3解答例

平成22年 プロジェクトマネージャ試験 午後Ⅱ 問3 解答例 

1.プロジェクト概要と重点管理項目
1.1 プロジェクト概要

 私が参画したプロジェクトはC社の原価計算システムの開発プロジェクトである。C社は製造業であり、独自の標準原価計算に基づいた原価計算方式、積算方式を採用している。従来は原価計算のパッケージソフトを採用していたが現実との業務との乖離が発生して課題となっている。そこでリニューアルし、既存の会計パッケージと連携する必要がある。

 本プロジェクト規模はおおよそ50人月。開発組織は顧客の会計担当者と顧客プロジェクト管理者。当社は管理者としての私。会計に詳しいSE、プログラマ2名、データベース管理者1名である。C社は新年度4月からのカットオーバーであり、テスト期間を含めると余裕期間がない状態であった。

1.2 重点管理したアクティビティ
 開発工程をWBS(Work Breakdown Structure)として細分化して、アクティビティかする。これらの工程をスケジュール上に並べてパート図化すると次の工程が課題となっていることがわかる。
(1)原価計算の仕様の要件定義
通常の原価計算と、C社方式との原価差異を明確化して開発用件として定義しておく必要がある。特に、勘定科目体系や原価差異などの取り扱いについて、企業会計原則や商法及び法人税法上の取り扱いでコンプライアンス上の問題点がないか十分な精査が必要であると共に、顧客との意見調整も必要と予想された。
(2)会計パッケージとのインターフェース部分の設計
原価差異分析がかわると勘定科目体系に影響が出る。現在使用中の会計パッケージの勘定科目体系との調整が必要になる。現行の財務諸表に影響が出ないような対策が必要と予測された。
2.完了日を守るための対策について
2.1 対策の基本戦略
 上記のアクティビティとクリティカルパスが進捗管理上の課題と予想されたため、その対策として以下の考えを文書化して、上司の承認を得た上でプロジェクト組織に周知徹底、及び顧客に伝達した

(1)(1) 財務諸表アウトプットの品質確認のため最終1.5ヶ月はテスト期間とすること
(2)(2) 勘定科目の作りこみや、その影響調査を含めて顧客の協力を要請すること。そのために要件定義に1.5ヶ月の期間を確保すること
(3)会計に関連する専門用語、アクティビティ名を徹底して標準化して、紛らわしい用語、類似用語を使わないようにすること
(4)ユーザと開発部隊の認識を共有化するために、用語や認識のあいまいさを徹底的に排除して疑問点があれば即座に質問、回答、報告、共有するための掲示板をネット上に構築すること
(5)(4)の仕組みを使って、プロジェクトの進捗の可視化をユーザ側と共有すること
2.2 分担のルールと周知徹底の工夫
 顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。 2.2 重点アクティビティへの配慮
原価差異分析アクティビティが原価管理システムの品質と、会計システムへの影響が大きいと判断した。この仕組みが混乱するとプロジェクトの納期に大きな遅延が予想されるので次のような配慮を計画した。
(1)会計に詳しいSEのユーザ会議、プロジェクト会議への参画。
(2)(2)要件定義段階で、会計システムのコンプライアンスを確保するために当社顧問税理士への相談の実施。
(3)原価差異分析の勘定科目変更による、会計システムへの影響を波及分析を、シミュレータ実施。その結果のユーザ共有・プロジェクト内共有
(4)重点アクティビティについての週単位での進捗管理の実施。予想される進捗遅れに関する顧客への連絡体制の整備

3 進捗遅れの原因と影響分析および対策
3.1 進捗遅れとその原因

(1)コンプライアンス上の問題
 当初、ユーザの説明では一部、出力される勘定科目が変更されても問題ない。そのままシステム開発を継続してほしいという意見であった。しかし、要件定義段階で税理士から「企業会計原則の継続性の原則から問題がある」という指摘をうけて見直し作業を実施したため、要件定義作業が2週間の遅れが発生した。

(2)単体テスト結果のユーザ確認遅れ
 ユーザとの進捗管理情報、製品情報の共有化を実施していた。しかし、原価加工費の差異分析用データベース詳細設計の結果にユーザー担当者のOKがでて、次の作業に取り掛かったタイミングで担当者上司から、原価分析データ用の識別符号をぜひ付加して欲しいという意見がでた。これは、ユーザ担当者が上司の意見を我われに伝達忘れしたことが原因である。また、上司も他の会議に時間を割かれていて、共有されている仕様に対するチェックが甘くなったのが原因と予想された

3.2 追加対策

(1)変更管理ついて
変更管理についてはユーザを交えた、スコープ管理委員会を臨時に開催して、優先順位、他のシステムへの影響度を考慮して判断。上記2案は重要なので採択。進捗スケジュールを見直した。
(2)スケジュール対応
 今回のスケジュール対応についてのポリシとして「専門性の高いプロジェクトであるから、追加要員投入は混乱の原因である」と判断。実施しなかった。
 従って、スケジュールの組み換えで対処した。勘定科目対応の必要性のないアクティビティ開発を優先させて、会計に強いSEとデータベース技術者を集中的にユーザ変更要求に対応させた。他のメンバーは別作業を並列化した。
(3)レビューの強化
 会計システムでは間違いが許されないので、設計変更のタイミング、作りこみ後のタイミングでユーザを交えたレビューを実施して、設計書上のあいまいさや、作りこんだ製品のアウトプットの正しさを検証した。

プロジェクトマネージャ試験、小論文対策講座(有)アイ・リンク・コンサルタント



投稿者 kato : 10:48 | コメント (0) | トラックバック

平成22年(2010年度)プロジェクトマネージャ試験 午後II 問2解答例

平成22年 プロジェクトマネージャ試験 午後Ⅱ 問2 解答例 

1.プロジェクトの特徴とプロジェクト編成
1.1 プロジェクトの概要

 私が開発に関与したプロジェクトはB社のwebシステムの開発システムである。B社は趣味商品の小売業であり、Webサイトで年間数千万円の売上をあげており商品点数も8,000件ある。B社の現行Webシステムは、使い勝手も悪く、Web検索にも弱いシステムであったためB社経営者であるC氏はWebサイトのリニューアルを企画したシステム開発規模は30人月と見積もられた。契約の形態は概要設計までが準委任契約、内部設計から結合テストまでが請負契約であった。

1.2 プロジェクトの特徴
 開発に当たってユーザと協議したことは①ユーザにとって更新しやすいシステムであること。②8000件あるデータの移行、エントリ変更が円滑にできること。このため、開発ツールとして、データベースとWebを連度させるCMS(Contrents Management System)ツールを利用することになった。当社にとってCMSツールの使用は初めてであり、CMS開発に強い企業との連携が必要であった。
1.3 プロジェクトの組織編制について
 プロジェクト編成は、顧客側がB社C社長、D氏、E氏である。当社側がプロジェクト管理者の私、SE兼リーダのT氏、SEのU氏である。
 また、当社には不慣れなCMS開発であったため、社外パートナーとしてCMSにつよいP社に外注依頼した。外注先の選定基準は当社規則にしたがった。P社にはSEであるQ氏、WebデザイナーであるR氏がいた。
私は本来、本プロジェクトに専任でありたかったが、上司から招請を受けて別プロジェクトと兼任体制であった。このため、プロジェクトマネージャの代理としてT氏を指名していた。
2.プロジェクトリーダへの権限委譲
2.1 権限委譲させた業務とその理

(1)権限委譲させた業務
私がプロジェクトリーダT氏に権限委譲した業務は①進捗管理業務、②パートナー企業との交渉権限である (2)権限委譲したその理由
①プロジェクトマネージャ兼任であること
 管理者である私が兼任であるため、業務過多になる可能性が高かった。この結果、事務処理量を軽減する必要があった。
②パートナー企業のコントロール
 本プロジェクトの成否は、工数の60%を占めるパートナー企業P社のコントロールであった。この進捗を把握し、かつ、成果物の品質を十分管理するためには部下に権限委譲したほうが水準の高い管理が実現できると考えた。
③部下の人間的特性と力量
 部下のT氏の人間的特性・力量として、SEとしての力量よりも正確な事務処理能力、理論的な交渉力に期待するところが多かった
2.2 分担のルールと周知徹底の工夫
 顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。 2.2 リスク分析
(1)分担のルール
 部下に権限の以上に当たっては、プロジェクト計画書に組織図を明記したうえで、権限分掌範囲を明記した。また、T氏に面接を行い、なぜ、権限委譲を行う理由についても丁寧に説明して合意を得た。 (2)周知徹底の手段について
①プロジェクト記録の共有
 パートナ企業との交渉記録、決定事項、懸案事項についてイントラネットで共有した。私は外部に出張している際は毎日、VPN回線からアクセスし記録の確認を行った。
②日報での報告
 Tからプロジェクトの進捗や課題、及び労働時間とその作業との関連を電子メールで日報として報告させた。そして、疑問がある場合は、電子メールで質問した。
③週一回の面談
 共有ファイルだけでは、プロジェクトのディテールが不明なケースも多い。そこで週一回の面会のチャンスを得て。現状の課題とその原因、Tがもっている解決策とその評価を行った。

3 評価と課題
3.1 評価

(1)進捗管理
 進捗管理について、パートナー企業とは順調だったが、ユーザ企業B社の作業が遅れ気味であった。これはB社がプロジェクトよりも現状業務を優先させたためである。このため当社やパートナー企業に待ち工数が発生した。

(2)パートナーとの交渉力
 パートナー企業へ当社の要望や意見を正しく伝える能力、パートナー企業の成果物をテストで吟味してゆき、その記録を残す能力において、T氏は期待した能力どおりの力を発揮した。

3.2 課題と改善点

(1)課題
 T氏の場合、理論的である反面、理が勝ちすぎる点がある。したがって、当社に理があって、顧客企業に否があっても、顧客が協力を渋ることがあった。  T氏はそれを「勝手だ」と断定する点があった。
(2)改善点
 Tのいうことはもっともな点はあるが、Webは顧客の協力なくしてプロジェクト目的を達成させることはでき ない。このため、T氏についてはOJT的に①仕事の薦め方、②顧客を褒めて動かす方法などを指導する必要があると実感した

プロジェクトマネージャ試験、小論文対策講座(有)アイ・リンク・コンサルタント



投稿者 admin : 03:38 | コメント (0) | トラックバック

2010年04月20日

平成22年(2010年度)プロジェクトマネージャ試験 午後II 解答例

平成22年 プロジェクトマネージャ試験 午後Ⅱ 問1 解答例 

1.プロジェクトの特徴とプロジェクト目標
1.1 プロジェクトの概要

私が開発に関与したプロジェクトはA社の生産販売管理システムの開発システムである。A社は製造業であり、得意先から引き合いをすると、技術的に対応可能か検討した上で、原価計算、見積り、受注、購買、生産する。情報システムの規模はおおよそ200人月であり、プロジェクトメンバーは常時10人である。

1.2 プロジェクトの特徴
 契約の形態はA社が当社得意先との関係も深いため、詳細設計から結合テストまでが請負契約となっている。また、A社は原価管理システムに独自の計算方法を持っていて、A社担当者の協力なくして開発は困難である。また、受注電文のフォーマットが取引先によって異なっているため、どの電文を標準化するかが未確定要素であった。
 私は開発以前からA社担当者B課長と打ち合わせをしていて上記二点について開発着手前の解決を依頼していたが、達成されないまま開発プロジェクトが開始された。また、A社からの依頼事項として、クラウドの開発を懇願されていたが、当社にとっては始めての開発であり不安要素であった。
1.3 プロジェクトの目標について
 プロジェクト本来の目標は、A社の要求する納期、品質で、情報システムを依頼されたコスト内で納めることである。しかし、今回は契約面において不利な交渉であったこと、内部設計工程からが請負契約である条件であること、未確定要素の多い開発プロジェクトであるため、次のような目標を立てた。
  1. リスクを最大に見積もった規模見積りで対処する
  2. プロジェクトを黒字プロジェクトで完了させる
  3. 品質標準を保ったシステム開発の完了
2.プロジェクトリスクとリスク分析
2.1 プロジェクトリスク

(1)赤字プロジェクトの恐れ
未確定の機能開発を正確に見積もることができないため、開発工程が最悪1.5倍程度になる可能性がある。このケースは25%程度の赤字プロジェクトになる (2)品質標準が保てないこと
 未確定仕様について、顧客の仕様変更がプロジェクト中に頻発すると、品質標準が保ちにくくなり、顧客の利益が損なわれること。 (3)納期遅延
 顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。 2.2 リスク分析
(1)規模見積りについての分析
 上記、リスクのうち、最大のものが(1)味覚提要その影響による赤字プロジェクトである。これを定量的に分析する手法として iCOST法を使った。  iCOST法はFP法で概算の規模見積りを一端、行い、その後、COCOMO法を用いて再見積りを行う。そのなかで、リスク要因となる①未確定要素、②はじめての技術基盤(クラウド開発)をパラメタとして計算式にいれ他結果、最悪のケースは開発段階で1.5倍の規模となるという結果が出た。 (2)品質標準と維持について
 ここで品質とは、①バグなどの不具合、②ユーザの求める機能の作りこみ、③ユーザの求める性能、④テストが不十分なことによるキャリーオーバーなバグの存在、⑤ドキュメント品質、⑥移植性などを総合的にさしていう。
 バグなどはゴンベルツ曲線などによるバグの摘出数で定量的に見積もることができる。また、ユーザの求める機能や品質はユーザからのクレーム数などで測定できる。ドキュメント品質はドキュメントのページ数/kstepの定量的側面と、曖昧さの排除のような定性的側面で評価する。

3 リスク対応計画と評価
3.1 リスク対応計画

(1)(1)規模見積りリスク
 規模見積り対策として以下の対策を講じた。 ①COCOMOで最終算出した予算規模に当社標準の待ち工数を加算して、概要設計後の段階で顧客に提出した。この段階で未解決な仕様は残っていた。 ②顧客の意思決定責任者と相談して、未解決のキャリーオーバは顧客のメリットにならないことを説明して、顧客サイドの協力を得て仕様確定を加速した。当社側も、上司の承認を得て、製造業の仕様確定の専門家を招請して顧客のニーズを引き出してゆき、内部設計中盤には仕様を確定していった。

(2)品質管理対策
 仕様変更が品質に与える影響をA社責任者に説明し、スコープ委員会を設置してもらった。仕様変更依頼が発生するつどにスコープ委員会で決済し、採択、優先順位付けを行い仕様変更を仕分けした。

(3)納期遅延対
 納期遅延対策は独立して開発できる機能を選定して、仕様確定待ちしているメンバーをシフトして先攻開発していった。

3.2 評価

(1)顧客との利害の共有
 顧客と利害を共有し、交渉を進めることにより、円滑に顧客の協力を引き出すことができた.
(2)意志決定者へのアプローチ
 顧客窓口の立場を守ることも重要であるが、重要な決定事項がある場合は、先方の責任者に可能な限り同席してもらった。
(3)定性的見積りの導入
 顧客に規模と人月、コストの関係を可視化することによって、顧客のコスト意識を引き出すことに成功した。また、開発サイドでもリスクとコストの関係が明確になって先手を打って顧客にアプローチできた。また、リスクと思える技術基盤を開発前に技術習得させることにしたことも有効だった。
(4)スコープ委員会
 ユーザと委員会で合意を得ながらプロジェクトをすすめたことによって、仕様変更を予想以上に最小化できた。

プロジェクトマネージャ試験、小論文対策講座(有)アイ・リンク・コンサルタント



投稿者 admin : 21:50 | コメント (0) | トラックバック