ITストラテジスト、システム監査、プロマネ講義ノート

2005年10月29日

2005年プロジェクトマネージャ試験　午後Ｉ　問４解答例

2005年 プロジェクトマネージャ試験　午後I　解答速報

問4

設問1

サブシステム間結合テストで使うミドルウェ アを提供し、結合テストの品質を確保する。

設問2

仕様の類似により、標準が保ちやすくコストも安くなる。

設問3

(1)改修完了が、総合テスト開始に間に合わない。

(2)改修の開始を即座に実施し、結合テスト開始日に間に合わせる。

(3)短期的な対応策を採択し、連携プログラム改 修後、サブシステム間結合テストを実施する。

(4)契約は結合テストまで請負契約だから。

投稿者 kato : 23:19 | トラックバック

2005年プロジェクトマネージャ試験午後Ｉ　問３解答例

2005年 プロジェクトマネージャ試験　午後I　解答速報

問3

(2)業務ソフトウェア規模を削減したオンライン性能目標で評価。

設問1

(1)稼動開始4年後のデータ量を与えた場合のオンライン処理時間。

設問2

(1)案１：開発日程に余裕があり、予算に余裕がない場合。

案２：開発日程に余裕がなく、予算に余裕がある場合。

(3)請負契約でありＢ社が責任を持って対処する。

設問3

(1)ソフトウェア改修による納期遅延。

(2)稼動開始年のデータ量への応答時間を満たし、稼動開始後対応する。

(3)データ量が稼動開始年の場合の応答性を満たしているから。

投稿者 kato : 22:46 | トラックバック

2005年プロジェクトマネージャ試験午後I　問２解答例

2005年 プロジェクトマネージャ試験　午後I　解答速報

問2

設問1

(1)①購買部が審査が委託先を選定せず、各部門が判断している。

②委託先選定の手順や判断基準が不明確である。

(2)客観的な判断基準に基づき委託先選定できる。

設問2

(1)T社：開発要員が不足して納期遅延

U社：工程管理能力が不足して納期遅延

T社：開発要員の動員力

U社：プロジェクト管理能力

(2)他のサブシステムが完成しているため負荷テストが可能だから。

設問3

(1)開発上のリスク：スキル不足で納期守れない。

検討した対策：スキル標準を設定し、R社の教育体制を監視する。

(2)①加えた方が良いもの：資本金

(2)②その理由：下請事業者の定義は資本金できまるから。

(3)購買部はチェックリストを使い委託先選定の判断基準とする。

投稿者 kato : 21:18 | トラックバック

２００５年プロジェクトマネージャ試験午後I　問１解答例

2005年 プロジェクトマネージャ試験　午後I　解答速報

問1

設問1

D社からの変更要求による納期遅延と予算超過防止の目的。

設問2

(1)担当者どおしの要件変更を防止し、両社で要件変更を共通認識する。

(2)変更要求が契約納期又は契約金額に影響を及ぼす場合。

(3)決算の早期化実現

設問3

(1)①E社

(1)②D社の不信感を買う共に追加コストを請求できない場合がある。

(2)CCBの結果、変更指示書を出し、変更指示書に基づき変更する。

投稿者 kato : 20:37 | トラックバック

2005年10月20日

2005年　プロジェクトマネージャ試験午後II　問２　小論文作成例

2005年午後II小論文 問2　解答速報

問1　稼動開始時期を満足させるためのスケジュールの作成について

1 プロジェクトの概要と開始時期が決定された背景

1.1 プロジェクトの概要

A社は光関係の研究開発を行い、研究成果に基づく製品を提供するベンチャー型の製造業である。 A社は新製品Bを開発し、この販路としてWebシステムを使って販売することを決定した。 そこで広告ツールとしてのWebシステムを開発するとともに、新たに製品Bの販売組織を 構築し、その組織内のLAN及びグループウェアの導入することになった。加えて、 製品BをOEM製品として開発するため、協力会社のS社との電子発注システムの構築を 行いことになった。

　本プロジェクトは、顧客の要求を受けて10ヶ月の短期で開発を完了する。プロジェクト 組織のうち弊社はプロジェクト管理者の私、LANチーム３名、WANチーム５名、Webサーバ及び アプリケーション開発チーム２名の11であった。また、顧客の業務分析チームが２名いた。
　契約の形態は請負契約で、LAN、Web及びWANシステムを順次段階的に納品することになっており、 WANシステムの納品をもって契約の完了とした。

1.2 開始時期が決定された背景とプロジェクト計画

1.2.1 納期が決定する背景

　A社の製品Bは、業界で画期的な技術であった。しかし、技術公開したくないA社は特許を取得することを リスクと考えて、特許を取得しないまま直接製品Bを市場に投入する計画であった。このため、B社販売を 支援する情報システムの納期は必須といえた。製品Bを早期に市場に投入販路を獲得し、研究開発に要した 資本を短期間に回収する計画であった。

1.2.2 プロジェクト計画

　当初、A社の要望は、営業チームを組織的に活性化する目標で、LANとグループウェアを構築し、その後に Webシステムを開発し販売体制を確立した後、協力会社S社と間の電子発注システムの構築を構築する ことであった。

　そこで、私はA社の要望を満たすべく、プロジェクト計画書を作成する過程の中で、サブシステムの 開発スケジューリングの開発優先順位を上記のとおりとした。また、要員の投入も上記の計画通りを示し、 顧客の承認を得た。また、開発スケジューリングを立案する手法としてWBS(Work Break Down Structure) 法を採用し、アクティビティ単位まで作業を分割し、担当者と着手日、完了予定日を計画した。また、 進捗管理の集計を2週間単位として、アーンドバリュー分析法で進捗管理することにした。

2 開発期間短縮要求とスケジュール調整活動

2.1 開発期間短縮要求

　顧客から次のような事由による開発スケジュール短縮を要望された。

　以上の現状をかんがみ、Webシステムの開発優先にスケジュールを組みかえる計画の立案 を検討する必要性がでた。

2.2 スケジュール調整の必要性

2.2.1 他の開発事例の参照

　なお、プロジェクト計画書変更に当たり、上記サブシステムごとに過去の開発プロジェクト報告書をレビューした。 そのうえでWANの接続仕様決定に大きなリスクがあることを認知していた。WANの場合、ビジネスプロトコル 、通信プロトコルなどのIT以外の要件仕様の確定及び接続テストに時間を要する。
また、Webシステムの場合、技術的に比較的容易であることがわかった。同様に、LAN開発についても 弊社は豊富な経験と人材をプロジェクトに蓄積していることを確認した。従って、予測している5ヶ月よりも 短納期で納品できる可能性が高いことがわかった。

2.2.2 スケジュールの組み換え

顧客の要望と、過去のプロジェクト報告書を比較検討した結果、スケジュールを以下のように 組み替える計画を立て、顧客の承認と上司のを得た。その上で、アサインしているメンバの招集 手順を組み替えることを検討した。特に重複したプロジェクトに参加しているメンバーがいる場合 は、他プロジェクト管理者との調整を行った。

　以上の作業の組み換えが、LAN、WAN及びWebシステム開発上、相互連携に矛盾を発生させないかを 弊社技術チームに検討依頼し、問題のないことを確認した上で、顧客と調整して上記のスケジュール案を 実施することにした。

2.3 スケジュール調整工夫

2.3.1 他のプロジェクト管理者との調整

　WANシステムの予定を組み替えたため、WANのネットワーク開発技術者のアサインが不足した。そこで 私は、WANのネットワーク仕様確定と、概要設計を優先する計画を立案して、ネットワークの仕様確定と 概要設計のスペシャリスト2名をまず優先赴任させてもらうことを他のプロジェクト管理者に交渉し、 既に他プロジェクトの概要設計を終えたメンバから順次、優先提供する確約をうけた。また、その旨を 上司に報告した。

2.3.2 サブシステムの相互依存性の確認

Webによる受注システムとA社S社間の受発注システムとは、相互に連携を持たない。また、別仕様の システムである。このため、相互の作業を並行させることに問題ないこと顧客と私の参加して構成する スコープ委員会にて確認、承認した。

2.3.2 余剰と成ったLAN設計者の措置

　既にアサインしているLAN設計者を放置する待ち工数が発生する。このため、LAN設計者を 有効活用するために、顧客が要求しているLANについて、導入予定の機器、機器数とネットワーク構成 について技術検討を実施させた。また、予想されるトラフィック数を想定してテストデータを 作成させておいた。これによって、テスト工程でのストレステストの準備を短縮化することにより LANの開発開始に遅れが出た場合でも、後半のテスト工程を削減できるように工夫した。

3 評価と課題

3.1 評価

3.1.1 スケジュール変更の手続きの妥当性

　私の実施手順は、顧客との契約を満たしている。また、スケジュール計画の変更 について スコープ管理委員会実施、技術検討、上司の承認を得ていることで管理手続きの妥当性は 確保されている。また、半期に一度の開発状況の監査もクリアした。

3.1.2 スケジュール変更の結果

　上記のタスクの並行化によって、納期よりも１週間前にシステムを完成させることが できた。また、余裕期間を総合テストに充当した結果、十分な運用環境の安定性を確保する ことができた。

3.2 課題

　今回は、サブシステム間に相互に依存性の少ないシステム開発プロジェクトであった。 このため、サブタスクの並行作業が容易であった。しかし、今回のように運よく相互依存性の 少ない情報システムばかりとは限らない。そこで、全社的に、開発報告書の体系的な整備を 行い、事例を豊富に持ち多様な顧客の要求に柔軟に対応する必要がある。このためにも、 標準化の徹底は重要といえる。

以上

投稿者 kato : 22:48 | トラックバック

2005年10月19日

2005年　プロジェクトマネージャ試験　午後II　解答速報　目次

2005（平成17）年度プロジェクトマネージャ試験午後Ⅱ解答速報

※留意事項

この解答速報は、プロジェクトマネージャ小論文試験等の 「合格のためのガイドラインを予測するもの」 です。完全性を保障するものではなく、また、 利用される皆さんの合格を保証するものではありません。その点を十分、 ご留意いただいたうえでご利用ください。

■合格のためのガイドラインと正答率

　合格と足切りのガイドラインは以下の通りであると予想します。

表1.平成16年度AN試験の合格のガイドライン

試験	足切りの得点率	足切り割合	備考
午前	68％程度	①＝受験者×50％程度	IRT方式の採点。経営科学、システム開発と法規などが出来ないと苦しい。 50門中34問以上取れないと、恐らく合格出来ない。
午後Ｉ	70％程度	②＝①×40％程度	本コンテンツで再三触れていたICタグが出題された。的中！午後Iは受験者の負担を考慮して、A4*3枚/問が定着してきた。
午後II	60％程度	③＝②×40％程度	午後Ｉの生き残りだけが採点されます。正答率が55％程度まで合格の可能性があるかもしれません。

※これは試験センター発表の正式情報ではありません。弊社の推測値です

■IRTと足きり

午前の足きりライン

　午前の通過は、スコア値600点です。全体の受験者の約50％が足きりになります。

午後Iの足きりライン

　午後Iの通過は、スコア値600点です。午後Iに採点が回った受験者の約60％が足きりになります。 従って、午後IIの小論文を採点してもらえる受験生は全体の約20%です。

■総評と論文の解答速報

●総評

●問題

投稿者 kato : 23:50 | トラックバック

2005年10月19日　プロジェクトマネージャ午後II　解答速報　総評

2005年PM午後II小論文の総評

■総評

■小論文を書く上での留意事項

それぞれの小論文を書く上で次の点に注意が必要である。

■難易度

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

[結論]

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

■問題別、小論文戦略

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

問題	問題の必須条件	合格のための工夫
問1	プロジェクト特性と重要なステークホルダとの関係のしっかりと手意義付けること	重要と考えた人物の納得できるコミュニケーション方法と内容を、その相手の職能別に論述する
問2	タスクに対する問題発生の内容が合理性のあるものか。	開発標準の参照、類似事例の参照、タスクの組み換えの実例、その具体的な手法を合理的に示せるか
問3	プロジェクト再編の手続きから確認、評価まで合理的に実施したことを論理的に示せるか	問題の分析、チーム再編の計画、再検討（納期、品質、予算の見通し）、スタッフへの説明ができるか

解答速報 目次に戻る

投稿者 kato : 23:00 | トラックバック