2010年04月22日
2010年プロジェクトマネージャ試験 午後ＩＩ 論文 解凍速報目次
2010（平成22年度)プロジェクトマネージャ試験午後Ⅱ解答速報
※留意事項
この解答速報は、システム監査小論文試験等の
「合格のためのガイドラインを予測するもの」
です。完全性を保障するものではなく、また、
利用される皆さんの合格を保証するものではありません。その点を十分、
ご留意いただいたうえでご利用ください。
新版ＣＤ「ITストラテジスト小論文突破講座（ver2.0）」は
2010年4月16 リリース！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
■合格のためのガイドラインと正答率
合格と足切りのガイドラインは正答率60％であると予想します。
■総評と解答速報
●総評
●午後Ⅱ
2010年04月21日
2010年プロジェクトマネージャ試験 午後ＩＩ 解答速報概況
2010年プロジェクトマネージャ試験 午後II 小論文の総評
■総評
- 非常にオーソドックスで平易で良問が多かった
- 問題文に指定が明確に指定されているから、指定にしたがって解けば容易に論文がかけるる。
■難易度
[難易度]★が多いほど難しい
- 問1 ★★★★☆
- 問2 ★★★★☆
- 問3 ★★★★☆
上記の難易度を決めた理由は次の通りである。
- 問1：プロジェクト目的を明確に述べておくことが重要である。リスク分析も合理的な手法を述べる必要がある
- 問2：チームリーダへの権限の委譲、良い意味での管理がポイントである
- 問3：進捗管理上のリスク予防措置と課題発生の把握と対処を的確にかけるか
■問題別、小論文戦略
合格できるか、否かについての基準を示そう。
| 問題 | 問題の必須条件 | 合格のための工夫 |
| 問1 | プロジェクトの特徴とリスクを合理的に結び付ける | 設問アで潜在的なリスクを述べておいて、対処の具体的対策を述べられるか |
| 問2 | チームリーダをいかに管理するかが課題 | 権限の範囲を限定して、権限を委譲しつつ、コントロールすることが要点 |
| 問3 | 進捗管理に品質確保がからめて出題されていることがポイント | 予防対策と対処を設問イとウに切り分けて書く |
■総評と解答速報
●総評
●午後Ⅱ
■2010プロジェクトマネージャ試験 解答速報目次に戻る
■プロジェクトマネージャ試験小論文合格講座
平成22年(2010年)度、プロジェクトマネージャ試験 午後ＩＩ 問3解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問3 解答例
１．プロジェクト概要と重点管理項目
１．１ プロジェクト概要
私が参画したプロジェクトはＣ社の原価計算システムの開発プロジェクトである。Ｃ社は製造業であり、独自の標準原価計算に基づいた原価計算方式、積算方式を採用している。従来は原価計算のパッケージソフトを採用していたが現実との業務との乖離が発生して課題となっている。そこでリニューアルし、既存の会計パッケージと連携する必要がある。
本プロジェクト規模はおおよそ50人月。開発組織は顧客の会計担当者と顧客プロジェクト管理者。当社は管理者としての私。会計に詳しいＳＥ、プログラマ2名、データベース管理者1名である。Ｃ社は新年度4月からのカットオーバーであり、テスト期間を含めると余裕期間がない状態であった。
1.2 重点管理したアクティビティ
開発工程をWBS(Work Breakdown Structure)として細分化して、アクティビティかする。これらの工程をスケジュール上に並べてパート図化すると次の工程が課題となっていることがわかる。(1)原価計算の仕様の要件定義
通常の原価計算と、Ｃ社方式との原価差異を明確化して開発用件として定義しておく必要がある。特に、勘定科目体系や原価差異などの取り扱いについて、企業会計原則や商法及び法人税法上の取り扱いでコンプライアンス上の問題点がないか十分な精査が必要であると共に、顧客との意見調整も必要と予想された。
(2)会計パッケージとのインターフェース部分の設計
原価差異分析がかわると勘定科目体系に影響が出る。現在使用中の会計パッケージの勘定科目体系との調整が必要になる。現行の財務諸表に影響が出ないような対策が必要と予測された。
２．完了日を守るための対策について
２．１ 対策の基本戦略
上記のアクティビティとクリティカルパスが進捗管理上の課題と予想されたため、その対策として以下の考えを文書化して、上司の承認を得た上でプロジェクト組織に周知徹底、及び顧客に伝達した
(1)(1) 財務諸表アウトプットの品質確認のため最終1.5ヶ月はテスト期間とすること
(2)(2) 勘定科目の作りこみや、その影響調査を含めて顧客の協力を要請すること。そのために要件定義に1.5ヶ月の期間を確保すること
(3)会計に関連する専門用語、アクティビティ名を徹底して標準化して、紛らわしい用語、類似用語を使わないようにすること
(4)ユーザと開発部隊の認識を共有化するために、用語や認識のあいまいさを徹底的に排除して疑問点があれば即座に質問、回答、報告、共有するための掲示板をネット上に構築すること
(5)(4)の仕組みを使って、プロジェクトの進捗の可視化をユーザ側と共有すること
2.2 分担のルールと周知徹底の工夫
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 重点アクティビティへの配慮
原価差異分析アクティビティが原価管理システムの品質と、会計システムへの影響が大きいと判断した。この仕組みが混乱するとプロジェクトの納期に大きな遅延が予想されるので次のような配慮を計画した。
(1)会計に詳しいＳＥのユーザ会議、プロジェクト会議への参画。
(2)(2)要件定義段階で、会計システムのコンプライアンスを確保するために当社顧問税理士への相談の実施。
(3)原価差異分析の勘定科目変更による、会計システムへの影響を波及分析を、シミュレータ実施。その結果のユーザ共有・プロジェクト内共有
(4)重点アクティビティについての週単位での進捗管理の実施。予想される進捗遅れに関する顧客への連絡体制の整備
３ 進捗遅れの原因と影響分析および対策
3.1 進捗遅れとその原因
(1)コンプライアンス上の問題
当初、ユーザの説明では一部、出力される勘定科目が変更されても問題ない。そのままシステム開発を継続してほしいという意見であった。しかし、要件定義段階で税理士から「企業会計原則の継続性の原則から問題がある」という指摘をうけて見直し作業を実施したため、要件定義作業が2週間の遅れが発生した。
(2)単体テスト結果のユーザ確認遅れ
ユーザとの進捗管理情報、製品情報の共有化を実施していた。しかし、原価加工費の差異分析用データベース詳細設計の結果にユーザー担当者のＯＫがでて、次の作業に取り掛かったタイミングで担当者上司から、原価分析データ用の識別符号をぜひ付加して欲しいという意見がでた。これは、ユーザ担当者が上司の意見を我われに伝達忘れしたことが原因である。また、上司も他の会議に時間を割かれていて、共有されている仕様に対するチェックが甘くなったのが原因と予想された
3.2 追加対策
(1)変更管理ついて
変更管理についてはユーザを交えた、スコープ管理委員会を臨時に開催して、優先順位、他のシステムへの影響度を考慮して判断。上記2案は重要なので採択。進捗スケジュールを見直した。
(2)スケジュール対応
今回のスケジュール対応についてのポリシとして「専門性の高いプロジェクトであるから、追加要員投入は混乱の原因である」と判断。実施しなかった。
従って、スケジュールの組み換えで対処した。勘定科目対応の必要性のないアクティビティ開発を優先させて、会計に強いＳＥとデータベース技術者を集中的にユーザ変更要求に対応させた。他のメンバーは別作業を並列化した。
(3)レビューの強化
会計システムでは間違いが許されないので、設計変更のタイミング、作りこみ後のタイミングでユーザを交えたレビューを実施して、設計書上のあいまいさや、作りこんだ製品のアウトプットの正しさを検証した。
平成22年(2010年度）プロジェクトマネージャ試験 午後II 問2解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問2 解答例
１．プロジェクトの特徴とプロジェクト編成
１．１ プロジェクトの概要
私が開発に関与したプロジェクトはB社のwebシステムの開発システムである。B社は趣味商品の小売業であり、Webサイトで年間数千万円の売上をあげており商品点数も8,000件ある。B社の現行Webシステムは、使い勝手も悪く、Web検索にも弱いシステムであったためB社経営者であるC氏はWebサイトのリニューアルを企画したシステム開発規模は30人月と見積もられた。契約の形態は概要設計までが準委任契約、内部設計から結合テストまでが請負契約であった。
1.2 プロジェクトの特徴
開発に当たってユーザと協議したことは①ユーザにとって更新しやすいシステムであること。②8000件あるデータの移行、エントリ変更が円滑にできること。このため、開発ツールとして、データベースとWebを連度させるCMS(Contrents Management System)ツールを利用することになった。当社にとってCMSツールの使用は初めてであり、CMS開発に強い企業との連携が必要であった。１．３ プロジェクトの組織編制について
プロジェクト編成は、顧客側がB社C社長、D氏、E氏である。当社側がプロジェクト管理者の私、SE兼リーダのT氏、SEのU氏である。また、当社には不慣れなCMS開発であったため、社外パートナーとしてCMSにつよいP社に外注依頼した。外注先の選定基準は当社規則にしたがった。P社にはSEであるQ氏、WebデザイナーであるR氏がいた。
私は本来、本プロジェクトに専任でありたかったが、上司から招請を受けて別プロジェクトと兼任体制であった。このため、プロジェクトマネージャの代理としてT氏を指名していた。
２．プロジェクトリーダへの権限委譲
２．１ 権限委譲させた業務とその理
(1)権限委譲させた業務
私がプロジェクトリーダT氏に権限委譲した業務は①進捗管理業務、②パートナー企業との交渉権限である
(2)権限委譲したその理由
①プロジェクトマネージャ兼任であること
管理者である私が兼任であるため、業務過多になる可能性が高かった。この結果、事務処理量を軽減する必要があった。
②パートナー企業のコントロール
本プロジェクトの成否は、工数の60%を占めるパートナー企業P社のコントロールであった。この進捗を把握し、かつ、成果物の品質を十分管理するためには部下に権限委譲したほうが水準の高い管理が実現できると考えた。
③部下の人間的特性と力量
部下のT氏の人間的特性・力量として、SEとしての力量よりも正確な事務処理能力、理論的な交渉力に期待するところが多かった
2.2 分担のルールと周知徹底の工夫
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 リスク分析
(1)分担のルール
部下に権限の以上に当たっては、プロジェクト計画書に組織図を明記したうえで、権限分掌範囲を明記した。また、T氏に面接を行い、なぜ、権限委譲を行う理由についても丁寧に説明して合意を得た。
(2)周知徹底の手段について
①プロジェクト記録の共有
パートナ企業との交渉記録、決定事項、懸案事項についてイントラネットで共有した。私は外部に出張している際は毎日、VPN回線からアクセスし記録の確認を行った。
②日報での報告
Tからプロジェクトの進捗や課題、及び労働時間とその作業との関連を電子メールで日報として報告させた。そして、疑問がある場合は、電子メールで質問した。
③週一回の面談
共有ファイルだけでは、プロジェクトのディテールが不明なケースも多い。そこで週一回の面会のチャンスを得て。現状の課題とその原因、Tがもっている解決策とその評価を行った。
３ 評価と課題
3.1 評価
(1)進捗管理
進捗管理について、パートナー企業とは順調だったが、ユーザ企業B社の作業が遅れ気味であった。これはB社がプロジェクトよりも現状業務を優先させたためである。このため当社やパートナー企業に待ち工数が発生した。
(2)パートナーとの交渉力
パートナー企業へ当社の要望や意見を正しく伝える能力、パートナー企業の成果物をテストで吟味してゆき、その記録を残す能力において、T氏は期待した能力どおりの力を発揮した。
3.2 課題と改善点
(1)課題
T氏の場合、理論的である反面、理が勝ちすぎる点がある。したがって、当社に理があって、顧客企業に否があっても、顧客が協力を渋ることがあった。
T氏はそれを「勝手だ」と断定する点があった。
(2)改善点
Tのいうことはもっともな点はあるが、Webは顧客の協力なくしてプロジェクト目的を達成させることはでき
ない。このため、T氏についてはOJT的に①仕事の薦め方、②顧客を褒めて動かす方法などを指導する必要があると実感した
2010年04月20日
平成22年(2010年度)プロジェクトマネージャ試験 午後II 解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問1 解答例
１．プロジェクトの特徴とプロジェクト目標
１．１ プロジェクトの概要
私が開発に関与したプロジェクトはＡ社の生産販売管理システムの開発システムである。A社は製造業であり、得意先から引き合いをすると、技術的に対応可能か検討した上で、原価計算、見積り、受注、購買、生産する。情報システムの規模はおおよそ200人月であり、プロジェクトメンバーは常時10人である。
1.2 プロジェクトの特徴
契約の形態はA社が当社得意先との関係も深いため、詳細設計から結合テストまでが請負契約となっている。また、A社は原価管理システムに独自の計算方法を持っていて、A社担当者の協力なくして開発は困難である。また、受注電文のフォーマットが取引先によって異なっているため、どの電文を標準化するかが未確定要素であった。私は開発以前からA社担当者B課長と打ち合わせをしていて上記二点について開発着手前の解決を依頼していたが、達成されないまま開発プロジェクトが開始された。また、A社からの依頼事項として、クラウドの開発を懇願されていたが、当社にとっては始めての開発であり不安要素であった。
1.3 プロジェクトの目標について
プロジェクト本来の目標は、A社の要求する納期、品質で、情報システムを依頼されたコスト内で納めることである。しかし、今回は契約面において不利な交渉であったこと、内部設計工程からが請負契約である条件であること、未確定要素の多い開発プロジェクトであるため、次のような目標を立てた。- リスクを最大に見積もった規模見積りで対処する
- プロジェクトを黒字プロジェクトで完了させる
- 品質標準を保ったシステム開発の完了
２．プロジェクトリスクとリスク分析
２．１ プロジェクトリスク
(1)赤字プロジェクトの恐れ
未確定の機能開発を正確に見積もることができないため、開発工程が最悪1.5倍程度になる可能性がある。このケースは25％程度の赤字プロジェクトになる
(2)品質標準が保てないこと
未確定仕様について、顧客の仕様変更がプロジェクト中に頻発すると、品質標準が保ちにくくなり、顧客の利益が損なわれること。
(3)納期遅延
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 リスク分析
(1)規模見積りについての分析
上記、リスクのうち、最大のものが(1)味覚提要その影響による赤字プロジェクトである。これを定量的に分析する手法として iCOST法を使った。
iCOST法はFP法で概算の規模見積りを一端、行い、その後、COCOMO法を用いて再見積りを行う。そのなかで、リスク要因となる①未確定要素、②はじめての技術基盤（クラウド開発）をパラメタとして計算式にいれ他結果、最悪のケースは開発段階で1.5倍の規模となるという結果が出た。
(2)品質標準と維持について
ここで品質とは、①バグなどの不具合、②ユーザの求める機能の作りこみ、③ユーザの求める性能、④テストが不十分なことによるキャリーオーバーなバグの存在、⑤ドキュメント品質、⑥移植性などを総合的にさしていう。
バグなどはゴンベルツ曲線などによるバグの摘出数で定量的に見積もることができる。また、ユーザの求める機能や品質はユーザからのクレーム数などで測定できる。ドキュメント品質はドキュメントのページ数/kstepの定量的側面と、曖昧さの排除のような定性的側面で評価する。
３ リスク対応計画と評価
3.1 リスク対応計画
(1)(1)規模見積りリスク
規模見積り対策として以下の対策を講じた。
①COCOMOで最終算出した予算規模に当社標準の待ち工数を加算して、概要設計後の段階で顧客に提出した。この段階で未解決な仕様は残っていた。
②顧客の意思決定責任者と相談して、未解決のキャリーオーバは顧客のメリットにならないことを説明して、顧客サイドの協力を得て仕様確定を加速した。当社側も、上司の承認を得て、製造業の仕様確定の専門家を招請して顧客のニーズを引き出してゆき、内部設計中盤には仕様を確定していった。
(2)品質管理対策
仕様変更が品質に与える影響をA社責任者に説明し、スコープ委員会を設置してもらった。仕様変更依頼が発生するつどにスコープ委員会で決済し、採択、優先順位付けを行い仕様変更を仕分けした。
(3)納期遅延対
納期遅延対策は独立して開発できる機能を選定して、仕様確定待ちしているメンバーをシフトして先攻開発していった。
3.2 評価
(1)顧客との利害の共有
顧客と利害を共有し、交渉を進めることにより、円滑に顧客の協力を引き出すことができた.
(2)意志決定者へのアプローチ
顧客窓口の立場を守ることも重要であるが、重要な決定事項がある場合は、先方の責任者に可能な限り同席してもらった。
(3)定性的見積りの導入
顧客に規模と人月、コストの関係を可視化することによって、顧客のコスト意識を引き出すことに成功した。また、開発サイドでもリスクとコストの関係が明確になって先手を打って顧客にアプローチできた。また、リスクと思える技術基盤を開発前に技術習得させることにしたことも有効だった。
(4)スコープ委員会
ユーザと委員会で合意を得ながらプロジェクトをすすめたことによって、仕様変更を予想以上に最小化できた。
2009年04月20日
平成21年 2009年 プロジェクトマネージャ試験 小論文 問3の解答速報です
平成21年 プロジェクトマネージャ試験 午後Ⅱ 問3 解答例
１ プロジェクトの特徴とパッケージの利用目的
1.1 プロジェクトの特徴
私が勤務するA社は、ソフトウェア開発ベンダである。今般は独自工業技術を提供する
製造業X社の受注、原価計算、日程計画、購買、生産管理システム開発プロジェクトにプロジェクト管理者として
参画した。
本プロジェクトの目標特徴は以下のとおりである。
- A社の方針として、経営資本利益率を高めるため、できるだけ情報化投資をせずにERPパッケージを用いて開発を行う
- ERPパッケージを導入するため業務改革が必要である
- 業務改革を行うため、ユーザの代表として総務課長や他部署のメンバーが業務改革委員として プロジェクトに参画する
- 業務改革を成功させるため、経営者から「全体的最適化」の方針に沿ってまとめるようにとの訓示があった
業務改革チーム:A社の各部署を代表したメンバーが
A社業務の現状を調査し、A社のあるべき姿（業務フロー）をDFDなどで定義してゆく。
要件定義チーム:業務改革の結果に基づいて。業務定義を行い、ERPの実態に即した外部設計書を
アウトプットする3人。
ERPカスタムチーム:ERPパッケージを導入しカスタメードする。
インフラチーム:ネットワーク、データベース、サーバ及び機器設定の専門家集団。3人
プログラム開発チーム:要件定義書に基づいてERPに存在しない機能を作りこんでゆくメンバー
8人
このほか、管理者としての私とプロジェクト文書担当者1名である。
1.2 業務パッケージの採用目的
A社では営業管理システム、会計・給与システム、顧客管理システム、生産管理システムなどが個別に稼動していた。 このため、営業担当者は顧客から見積もり依頼を受けると会計セクションに原価の問い合わせをして見積書を作成していた。また、生産日程計画を立案する場合でも購買セクションや生産セクションとの情報交換や調整に 多大な時間を要していた。このため、①部署間での情報共有、②情報共有による業務生産性の向上。 ③業務生産性の改善によるQR(Quick Response)、④計画作成における属人性の排除を目的として 業務パッケージソフトの導入を計画した。
2 外付けプログラムの開発
2.1 外付けプログラムが必要となった理由
A社が選定したパッケージソフトウェアは、標準原価計算と総合原価計算が標準機能として
実装されている。しかし、A社は大規模な受注を特徴としており、工事完成基準に基づく原価計算を希望していた。
あえて、異なる原価計算基準のパッケージを導入した理由は、他のパッケージに比べて希望する機能を標準的に
実装していたこと。経営者が最も重視していた日程計画作成機能がA社の業務に適合していたことなどからである。
本来ならば、業務パッケージに業務を適合させてゆくことが慣用であるが、標準原価計算と工事完成基準とでは
原価の集計の仕方や生産途中えられる集計結果が従来とまったく異なるため。原価計算部分だけ外付けのプログラム
開発が必要になった。。
2.2 外付けプログラムの概要
標準原価計算では、まずかつてのコスト事例に基づいて、材料費、加工費ごとに標準原価が設定される。 それに予定時間数を乗じて原価予測を立てて、実際の原価と比較を行う。
これに対して工事完成基準は、加工進捗度に基づいて原価の集計が行われる。このため、実際の作業時間による 原価測定と加工進捗度にもとづく原価測定では生産中途において集計される原価額が異なる。
2.3 利用部門との協議と経緯
利用部門との協議を行うに際して留意したことは次のことである。- スコープ管理委員会をA社担当者、当社担当社で開催すること
- スコープ委員会で、原価計算法を変更した場合の、品質的影響、影響の及ぼす範囲の確定を行うこと
- 外付け開発する場合の予算規模を算定し、ユーザ承認してもらうこと
- それ以外の外付けプログラムの開発は優先順位をつけて、それぞれの案件ごとにスコープ委員会で 開発承認を行うこと。
この結果、①外付けプログラムは原価計算プログラムと、その改定の影響を受けるプログラムのみと すること、②今後、外付けプログラムの開発依頼が出た場合には、スコープ委員会で 予算的側面、保守性の側面、品質的側面で検討を行い可否決定することが決定した。。
3 工夫と結果と改善点
3.1 工夫
A社メンバーの説得。ユーザはシステムに改定を加えたリスクが予想できない。そこで、シミュレータソフトを
使い原価計算ソフトに変更を加えた場合、どこまで影響があるのかを可視的に確認してもらった。
それをスコープ委員会で、各委員立会いのもと実施して、改定に必要な費用の概算見積もり案を提示しながら
説明した。
3.2 成果と改善点
プロジェクト期間中に強化したことは次のとおりである。
- ビジュアルとコストに訴求する説得は効果があった。
- その結果、ユーザからの外付けプログラム変更開発要望は抑止された
- 今回はユーザが協力的にスコープ管理に参加してくれたので効果があった。非協力的な場合も想定されるの 対処法を検討しておく必要がある。
平成21年（2009年度）プロジェクトマネージャ試験 小論文 問1 解答例
平成21年 プロジェクトマネージャ試験 午後Ⅱ 問1 解答例
１ プロジェクトの目標と特徴、メンバ構成
1.1 プロジェクトの目標と特徴
私が勤務するA社は、ソフトウェア開発ベンダである。今般は独自工業技術を提供する
製造業X社の受注、、原価計算、日程計画、購買、生産管理システム開発プロジェクトにプロジェクト管理者として
参画した。
本プロジェクトの目標特徴は以下のとおりである。
- A社の方針として、経営資本利益率を高めるため、できるだけ情報化投資をせずにERPパッケージを用いて開発を行う
- ERPパッケージを導入するため業務改革が必要である
- 現行マシンのリース期限が残り12ヶ月で切れるため、そのリース期限切れに間に合わせる必要がある
- 業務改革を行うため、ユーザの代表として総務課長や他部署のメンバーが業務改革委員として プロジェクトに参画する
- 業務改革を成功させるため、経営者から「全体的最適化」の方針に沿ってまとめるようにとの訓示があった
1.2 メンバー構成について
本プロジェクトのメンバーと役割について述べる。
業務改革チーム:基本的にA社の業務改革委員会の集まりである。各部署を代表したメンバーが
A社業務の現状を調査し、A社のあるべき姿（業務フロー）をDFDなどで定義してゆく。
ERP導入コンサルタント:ERP導入ベンダーから紹介を受けた技術コンサルタントY氏。
ERP導入に当たっての技術的課題を解決する。
要件定義チーム:業務改革の結果に基づいて。業務定義を行い、ERPの実態に即した外部設計書を
アウトプットする3人。このメンバーはどちらかというと業務に精通し年齢も高い。
ERPカスタムチーム:業務改革の結果、Y氏の指導結果に基づいて。ERPパッケージを導入しカスタメードする。
インフラチーム:ネットワーク、データベース、サーバ及び機器設定の専門家集団。3人
プログラム開発チーム:要件定義書に基づいてERPに存在しない機能を作りこんでゆくメンバー
8人
このほか、管理者としての私とプロジェクト文書担当者1名である。
2 動機付けの内容と方法について
2.1 動機付けの内容
本プロジェクトのメンバーと動機付けと手法について述べる。
(1)業務改革チーム:ユーザ企業の担当者であることから、礼儀を尽くし、また、
このプロジェクトがユーザ企業の利益に資するためのシステムであることを十分理解していることを
伝えたうえで、ユーザに依頼したいこと「①業務要件定義、②その期限、③標準化」について文書を配布して説明した。
そのうえで経営者の発言を引用し、「業務の最適化」を優先してお願いしたい旨を伝えた。
この際に、事前に総務部長に面会し、キックオフプロジェクトで経営層の意見を述べていただきたいことをお伝えして
快諾をえておいた。
(2)要件定義チーム:通常のプロジェクトであるならば、業務のあるべき姿を定義すれば
よいが、今回のプロジェクトはERPの活用であるため、ERP標準を準拠する旨を伝えておくことにした。
年齢が高く、経験も豊富であることから、プロジェクトの成功と情報システムの品質は要件定義チームの
作成する要件定義書の品質に依存することを伝達したうえで、標準化作業への協力を要請した。
また、要件定義書作成機関中は要件定義チームとのコミュニケーションが重要と考えたため、
両者の都合の付く限り、ランチを同席するなどして、進捗の様子やモチベーション、標準化への理解度に変更がないかを
確認しつつ相互の理解をえることにした。
(3)ERPカスタムチームとプログラム開発チーム:両チームとも、WBS(Work Break Down Structure)
法でアクティビティ単位まで作業を分割してそれぞれのメンバーの責任範囲と進捗計画を明らかにした。そのうえで、
各チームリーダに依頼して、メンバーに面接を実施してもらい、①メンバーの不安事項、②リーダの面接所見、
③作業環境の不満、④作業意欲を採取した。そして、即座に改善できることがあれば、改善計画を立てて、
作業環境の工夫をしたり、メンバーの不安要因を除くための説明をしたりした。
また、これらの作業チームは、単純労働的な思考に陥りがちであるため、それぞれの作業品質や進捗が全体にどのような影響を与えるかを
面接の過程で説明してもらった。
(4)インフラチーム:インフラチームは人数も少ないことからそれぞれのメンバーに面接を行い
期待される技量や行動形式、品質などについて希望を述べ、本人のプロジェクトへの参加意欲を確認した。
そのうえで、ERPチーム、プログラマチーム、インフラチームなどの一体感を醸成するために以下の工夫をした。
- 作業場所、集合場所を基本的に同一オフィス内とすること
- 1ヶ月に1回全体ミーティングを開催すること
- 朝礼を実施して、プロジェクトの目的と社是、品質目標を唱和すること
- 目的を目標、標語、進捗状況、バグの状況を可視化して意図的に部屋の中に張り出すこと
- 朝礼のやミーティングの司会者をそれぞれのグループから持ち回りに出すこと
- 朝の挨拶を徹底させること
2.2 反応
本プロジェクトのメンバーと動機付けと手法について述べる。
(1)業務改革チーム:当方のA社の利益を優先する方針と総務部長が述べた経営層の発言により
比較的容易に協力を引き出せた。
(2)要件定義チーム:要件定義チームは基本的に裁量労働的な態度で仕事を進めてもらい、
納期と品質について厳しくチェックしたところ。それぞれの品質要件やシステム特性を把握しつつ標準化
に対する協力が得られた
(3)ERPカスタムチームとプログラム開発チーム:朝礼と作業場の共通化が功を奏して
全体的な一体感が得られた。
(4)インフラチーム:責任を持って作業を依頼したところ達成感を求めて。短時間で高品質な
インフラが完了した。
3 プロジェクト進行中の維持強化
3.1 基本的な考え方
モチベーション維持のための基本的な考え方は次のとおりである。
①ユーザがやるべき作業と当社がやるべき作業を明確に分けてる。責任を持って分担する
②ユーザと当社はプロジェクト期間中は一体であるという信念を持ち、言動に勤める
③プロジェクト末端のメンバーほど責任範囲についての権限委譲を行い達成感をあじわってもらう
④しかし、まかせきりにせず、1週間おきに進捗と品質の状況をプロジェクトリーダを介して検証する。
3.2 強化したこと
プロジェクト期間中に強化したことは次のとおりである。
- ユーザ企業からともすると、当社に作業を押し付けたり、仕様変更を安易に命令しようとする傾向があった。 この問題を解決するためにスコープ委員会を通じて、仕様変更等の優先順位をつけて安易な変更命令の発生を抑止した。
- 作業遅れが発生したり、不安に陥りモチベーションの低下したメンバーについては、リーダが 名節を行い、軽度の遅れであれば技術的助言を与えたり、負担の少ないメンバーに助言させたりした。
- プロジェクト進行とともに当初の目的が薄れる傾向にあるので、 プロジェクトの意義などの必要性を朝礼で話すなどした。
2009年04月19日
平成21年(2009年度)プロジェクトマネージャ試験 小論文、解答速報
2009（平成21年度) プロジェクトマネージャ試験午後Ⅱ解答速報
※留意事項
この解答速報は、システム監査小論文試験等の
「合格のためのガイドラインを予測するもの」
です。完全性を保障するものではなく、また、
利用される皆さんの合格を保証するものではありません。その点を十分、
ご留意いただいたうえでご利用ください。
新版ＣＤ「ITストラテジスト小論文突破講座（初版）」は
2008年5月 中旬 リリース開始！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
「提案型システムコンサルタント養成講座」セット販売もあり！
■合格のためのガイドラインと正答率
合格と足切りのガイドラインは正答率60%です。
■総評と解答速報
●総評
●午後Ⅱ
2008年10月22日
プロジェクトマネージャ試験 2008年 午後II 問1
平成20年 プロジェクトマネージャ試験 午後Ⅱ 問1 解答例
１ 業務革新の概要と経営目標、背景
1.1 プロジェクト概要
私が関与したプロジェクトは、食品原料加工業A社の調達物流システム開発である。同システムは
調達部門、生産管理部門、倉庫部門、検査部門が利用する。現在、A社は海外から原料を仕入れ加工して、
大手食品製造業に食品原料を提供している。
現在の経営課題は、大手食品製造業から、厳格な品質保証を迫られていること。
このため、A社企画室では調達製品の検収の厳格化、保管の安全管理、荷役の正確化などの盛り込んだ
開発計画をまとめた。A社は世界標準に準拠した品質保証マニュアルを有している。
本プロジェクトには、A社企画室B氏、当該利用部門がオブザーバとして加わる。 当社は管理者としての私、ネットワーク開発者1名、データベース開発者1名、 プログラマー3名によって構成される。開発に当たりパッケージソフトをA者向けに カスタマイズする必要がある。
1.2 合意された利用部門の作業
A社側は、基本的に保管システムなどの機能については自らの業務を改め、パッケージに
合わせる予定でいる。しかし、受け入れ検収作業と出荷検査作業などは顧客から
作業の厳格化を求められているため、パッケージの改定が必要になる。
A社側が約束した協力作業内容は以下のとおりである。
- 要件定義開始から1ヶ月以内に、検収・検査手続き改定の仕様をまとめる
- 当社が取りまとめた要件定義をレビューして、1週間以内に承認を行う。
- 総合テストに参加して、仕様の実現化状況を検証する
2 利用部門の課題と対策
2.1 利用部門の課題
要件定義が開始されてから1ヶ月がたった約束の日に利用部門から変更要件に関する 仕様確定の返事が無かった。その後も1週間待っても返事が無く、検収・検査手続きの概要設計作業が 待ち状態に陥り納期遅延の恐れが発生した。
2.2 利用部門の返答遅延の理由
利用部門からの返答遅延の理由は次の通りである- 食品原料偽装問題が発生し、流通経路が混乱していた。
- この問題に対処するために利用部門の人員が割かれ情報システム変更仕様確定が手付かずになっていた
- この混乱の収拾には後1月くらいかかる見通しとA社からの返答があった
2.3 対処
このままでは予備日程を食いつぶし、納期遅延が大幅に拡大する可能性もある。 また、他の業務に遅延が拡大する可能性があった。このため、次のような対策を私は講じた。
- 現状を放置した場合の、A社の損害、システム開発の遅延の発生などの被害状況を報告書に取りまとめ A社担当B氏に提出し説明した。
- 仕様確定のノウハウを持つ専門技術コンサルタントX氏の招請を上司に提案し承認された
- A社担当B氏に、①X氏への協力の要請、②X氏の応対担当のメンバーの確保を依頼し承認された
- B氏の担当C氏にも事前に当社幹部から根回しを進めておいた
- そのうえでX氏をA社に送り込み、要件仕様を確定させた。
2.4 対処の理由
2.4.1 根回しを行った理由A社の混乱状況は危機管理対策状態であり、B氏のような課長クラスの人間でも、 情報システム開発の仕事に専念し難いような環境と判断された。このためトップダウン的 門外解決が必要とされた。
2.4.2 X氏の投入業務分析やヒアリングには経験とスキルが必要とされる。また、A社には品質保証体系図などの文書 が存在するから、その内容を理解することのできるメンバーを集中的に投入すれば、A社にヒアリング等に 多大な負担をかけることなくA社業務や仕様を洗い出せるものと判断した。
3 評価と改善
3.1 評価
(1)納期目標の達成度
要件定義工程は1ヶ月余分にかかった。しかしX氏の正確な要件定義よって、
外部設計以降の工程で挽回が可能となった。また、予備日程を1ヶ月保有していたことも
大きかった。
(2)手続きの妥当性
今回は顧客が非常事態であった。その環境下では柔軟な対応が求められる。このため、
組織ルールを護り上司に相談しつつ、X氏の投入を決めた。
また、顧客に対しても十分な説明責任を果たした。
3.2 改善点
基本的に開発プロジェクトは余裕日数をもって望むことが理想だ。 しかし、今回のように予期せぬトラブルが顧客側に発生することもあり、 そのような場合の対処は全社的に確立しておく必要がある。
- 危機管理発生時の対処事例集、マニュアルの整備
- X氏のような専門的問題解決能力を持った人材の確保とデータベース登録
- 対処に関する意思決定を迅速化するための手続きの確立と全社的合意
このほか、3PL組織を毎年、評価し格付けの変更を行うとともに、顧客からの要望を 取り入れて改善を要望してゆく必要がある。
2007年08月28日
プロジェクトマネージャ試験小論文作成の留意事項（続き）
プロジェクトマネージャ試験小論文の題意の把握と執筆にあたり留意すべき事柄
ある読者の方からご質問をいただきました。
現在、添削内容を基に論文を修正しているのですが、やはり書くべき内容がまったく浮かびません。
先ほど、やっとの思いで修正が終わりましたが、時間にすると８時間ほどかかってしまいました。
知識不足が原因だと思っていますが、どのような対策が良いのでしょうか？
現在は、論文集を読んだり、自分なりに書いたりしていますが、試験対策本以外のＰＭ本も読んだ方が良いでしょうか？
論文に書くべき内容
プロジェクトマネージャ試験において、論文設問イとして書くべき内容は次のとおりです。なお、 論文のテーマは「進捗管理」とします。
- 設問イ前半部：理想的な管理状態を想定し,PMBOKで記載されている理論的施策をそのまま事例に当てはめて 書けばよい。
- 設問イ後半部：理想的な管理状態を維持したいと考えていたが、顧客の要求などによって理想が崩れた場合の 実務的対処を書く
- ※：世界標準に準拠しつつ、実務的問題解決能力があることが示せればこの試験は合格できるのです。
良く見られる「ドタバタ物語」「スーパーSE物語」を書こうとするから苦しいのです。 設問イ前半のPMBOKは理論的内容なので、そのまま、冷たく書けばよいです。問題は設問イ後半部は 実務的問題解決が問われます。
実務的問題解決とは
実務的な問題解決とは「オヤヂ的問題解決法」ではなく冷静な対処法が求められます。
- 契約書にもとづく法的解釈の徹底による問題解決
- 事前打ち合わせ記録の参照に基づく問題解決
- やむを得ず工程を見直す場合、計画を変更する場合は、スコープ委員会などの手順にのっとった 正規の手続きよる問題解決
- 単純な増員などの安直な問題解決を選択しないこと（禁止事項）
重要であるとかかれている内容は必須であり、必要である大切であるとある項目は80％程度 その他の内容は60％程度盛り込んでおく必要があります。すべてを盛り込みたいところですが 試験の制限時間と字数制限もありますので現実的には妥協は必要でしょう。
実務的問題解決の記載内容
よって問題解決法では次のようなことをします
- 契約書を顧客と読み合わせをして、現状問題解決の責任関係を明確にすること
- 詳細事項や見解の相違事項は過去の打ち合わせ記録に基づいて相互協議しつつ問題解決すること
- 計画は独断解決せず、周囲への報告連絡相談、周知徹底を行うこと
- ※よって、重要な点は①業務手続の遵守、②組織ルールの遵守、③顧客との協議の徹底、④ 打ち合わせ文書の利用、④同僚、上司への相談、協力の要請です
プロジェクトマネージャとしての知識不足について
プロジェクトマネージャの知識が不足していると自覚される方は、安直な勉強法を選択せず 次の点に着目しておくと良いでしょう。
- プロジェクト計画書、開発標準書などの文書をレビューすること
- プロジェクト管理に必要は派遣法、労働基準法、民法の契約関連の知識、著作権法などの法規の 分野の知識を習得します
- 自分の上司が、日常、どのような行動様式で組織内で行動しているのかを観察すること
法律にかかわる知識は、法律家になるわけではないので必要な部分だけかいつまんで 勉強しておくと良いと思います。
当面すぐに役立つ知識
- PMBOKは精査、精読しておくこと。暗記するくらいがよい
- QC(Quality Control)は一読しておくよい
- プロジェクト管理上発行される文書にどのようなものがあるか、どのようなものが書かれているかについて 調べておくと良い
- 文書体系を整理しておくと、プロジェクトマネージャの業務フローがよくわかる
要はプロジェクトマネージャは工場長のようなものですから、工程管理技術、品質管理技術が あることを示せればよいのです。そのヒントがPMBOK,QC なのです。
投稿者 muramatsu : 09:34 | トラックバック
2007年08月27日
プロジェクトマネージャ試験小論文作成の留意事項
プロジェクトマネージャ試験小論文の題意の把握と執筆にあたり留意すべき事柄
ある読者の方からご質問をいただきました。
論文を作成するに当たり、一番苦労したのが、論文に書くべき内容がまったく浮かんでこない事でした。
今回は延べ１０時間ほどかかり、とても２時間で書き上げる自信がありません。
さらに、添削して頂いた内容を見ると、自分の論文が題意から大きく逸れていることがわかりました。
添削に出す前は、（作成に時間かけた事もあり）それなりに自信もありました。
題意の把握について
論文添削を行っていて題意の把握が十分でない方が多いのに驚かされます。無論、私どもの CD教材の生徒さんは結構、いいところまでいっているのですが、総論として次の点に留意されて 論文の題意の把握に勤められればよろしいと思います。
- 論文問題文のなかで指摘されている項目が十分記載されているか
- 論文の主題および副題が十分記載されているか
- 論文で要求されてたこと意外の項目が記載されていないか（禁止事項）
論文で指摘されていることを盛り込むために
論文で指摘されていることを盛り込むためには次の事柄に留意すべきと存じます。
- 問題文のなかの「重要である」と書いてある事柄
- 問題文のなかの「必要である」「大切である」と書いてある事柄
- その他英語で言うと「shall be」に該当する内容
重要であると書かれている内容は必須であり、必要である大切であるとある項目は80％程度 その他の内容は60％程度盛り込んでおく必要があります。すべてを盛り込みたいところですが 試験の制限時間と字数制限もありますので現実的には妥協は必要でしょう。
主題および副題の把握について
主題は当然ですが、副題はしっかり把握しておかないと ピントの外れた論文を書くことになってしまいます。
- 主題が「プロジェクトの進捗管理について」とあったとします。
- その問題文のなかで、「プロジェクトの進捗管理に当たってはクリティカルパスの管理が重要である」と 書いてあったとします
- さらに深く読み進めたときに、「進捗管理に影響を兆候の把握が必要」とあったとします
このような場合、進捗管理だけをテーマに書いては不適合な論文といえます。
そこで自分の場合は次の点に留意した論理のを用意します。
- 主題が「プロジェクトの進捗管理について」以外のことは書かないように心がけます。
- その問題文のなかで、「クリティカルパスの管理が重要」な工程ラインが何か考えます
- さらに「進捗管理に影響を兆候」として何があったのか考えます。
具体的に考えると「顧客管理システム開発の進捗管理」において、
「顧客管理ワークフローの構築」する工程がクリティカルパスだとします
このクリティカルパスを管理するためにスコープ委員会に提出される「要望仕様変更書」や「各
ワーキンググループの報告書」の内容や多寡が予兆となるわけです。
最低限、このようなことを頭で整理したうえで論文を書くのです。
投稿者 matsunaga : 16:27 | トラックバック
2006年11月08日
プロジェクトマネージャ2006 午後Ⅰ問4
問4
| 設問1 |
| (1)通信設備の影響で性能目標が達成できない。 |
| (2)ピーク時間帯の最大受付件数。 |
| (3)シミュレータを導入しアルゴリズム別の性能を評価する。 |
| 設問2 |
| (1)性能目標達成の観点で機能を評価する。 |
| (2)1.メリット：進捗管理を帳票画面数で評価できる |
| 2.デメリット：各工程間の依存関係で進捗管理できない |
| 設問3 |
| P社からの仕様変更依頼を一端保留し、その内容をL課長に報告する。 |
| 設問4 |
| (1)追加開発依頼を実現した場合、納期遅延が発生する可能性がある。 |
| (2)追加開発はＰ社経営会議の承認を得ているか。 |
■2006年 プロジェクトマネージャ試験解答速報目次に戻る
■プロジェクトマネージャ試験小論文講座
2006年11月07日
プロジェクトマネージャ2006 午後Ⅰ問3
問3
| 設問1 |
| (1) 製造・単体テスト：追加メンバを開発経験者が指導できるから。 |
| (2) 開発未経験者の参加による生産性の低下。指導工数の発生。 |
| (3) 追加開発による工数増加と手戻りの発生。 |
| 設問2 |
| (1) 1 レビュー参加者に内部設計書を事前にレビューさせる。 |
| 2 レビューの指摘漏れを防止することができる。 |
| (2) レビューでの指摘事項の一覧を対応完了を確認するためのチェックリストとする。 |
| (3) 指摘事項反映確認の捺印欄 |
| 設問3 |
| (1) 内部設計書の構成要素別に品質の良し悪しを識別している。 |
| (2) 内部設計書に記述漏れや、検討の深さが足りないことが予想される。 |
| (3) プロジェクトチーム |
■2006年 プロジェクトマネージャ試験解答速報目次に戻る
■プロジェクトマネージャ試験小論文講座
2006年11月06日
プロジェクトマネージャ2006 午後Ⅰ問2
問2
| 設問1 |
| (1)現行システムの改修内容が新システムとして必要かどうかの検討。 |
| (2)内部設計以降に発生した改修作業コストは再見積りを行う。 |
| (3)システム改修内容の新システム反映への期限の設定。 |
| (4)コスト |
| 設問2 |
| 1.内部設計、製造・単体テストで使った要員が手すきになり、再活用できる。 |
| 2.結合テストで十分検証した上で第二次開発するのでプログラム品質を確保できる。 |
| 設問3 |
| (1)1次開発、2次開発間のプログラム検証 |
| (2)2次開発での修正の影響が1次開発チームに反映されない |
■2006年 プロジェクトマネージャ試験解答速報目次に戻る
■プロジェクトマネージャ試験小論文講座
プロジェクトマネージャ2006 午後Ⅰ問1
問1
| 設問1 |
| 各部で使用する帳票や画面が異なっていて、これを標準化しなければならないため。 |
| 設問2 | |
| (1)帳票・画面ごとに設計着手から完了承認まで一貫して管理できる。 | |
| (2)タスクの完了基準が明確に記述されていない。 | |
| 設問3(1) |
| 1.DBチーム |
| 2.入出力チーム |
| 3.プロセスチーム |
| 設問3(2) |
| 1ヶ月目でCVがすでに-3,300だから。 |
| 設問4(1) |
| 1.設計完了後、利用者承認がないと出来高比率は20％となるから。 |
| 2.設計の完了時 |
| 設問4(2) |
| 利用者の要求によって手戻りが発生する。 |
| 設問4(3) | |
| d | 高くなる |
| e | 高くなる |
| f | 変わらない |
| g | 高くなる |
■2006年 プロジェクトマネージャ試験解答速報目次に戻る
■プロジェクトマネージャ試験小論文講座
2006年10月21日
プロジェクトマネージャ試験2006年解答速報 目次
2006（平成18）年度プロジェクトマネージャ試験午後Ⅱ解答速報
※留意事項
この解答速報は、プロジェクトマネージャ小論文試験等の 「合格のためのガイドラインを予測するもの」 です。完全性を保障するものではなく、また、 利用される皆さんの合格を保証するものではありません。その点を十分、 ご留意いただいたうえでご利用ください。
新版ＣＤ「システム監査技術者試験合格講座」は
2006年12月中旬 リリース予定！
Coming soon！
新版ＣＤ「プロジェクトマネージャ小論文突破講座（第3版）」は
2007年中旬 リリース開始！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
■合格のためのガイドラインと正答率
合格と足切りのガイドラインは以下の通りであると予想します。
表1.平成18年度PM試験の合格のガイドライン
試験 |
足切りの得点率 |
足切り割合 |
備考 |
| 午前 | 68％程度 | ①＝受験者×50％程度 | IRT方式の採点。経営科学、標準化と法規などが出来ないと苦しい。 |
| 午後Ｉ | 70％程度 | ②＝①×40％程度 | 全体的に業務改革ものが多く出題された。なかでも問2のKJ法が象徴的だ。 |
| 午後II | 60％程度 | ③＝②×40％程度 | 午後Ｉの生き残りだけが採点されます。正答率が55％程度まで合格の可能性があるかもしれません。 |
※これは試験センター発表の正式情報ではありません。弊社の推測値です
■IRTと足きり
午前の足きりライン
午前の通過は、スコア値600点です。全体の受験者の約50％が足きりになります。
午後Iの足きりライン
午後Iの通過は、スコア値600点です。午後Iに採点が回った受験者の約60％が足きりになります。 従って、午後IIの小論文を採点してもらえる受験生は全体の約20%です。
■総評と解答速報
●総評と解答速報
●午後Ⅰ
●午後Ⅱ
- 問１：情報システム開発におけるプロジェクト内の連帯意識について
- 問２：情報システム開発におけるプロジェクト予算の超過の防止について
- 問３：業務の開始日を変更できないプロジェクトでの変更要求への対応について