Not a passenger in life

スポンサーサイト

2011.06.26 Sunday
-
-

この広告は60日以上更新がないブログに表示されております。
新しい記事を書くことで広告を消すことができます。

試験当日障害発生

2011.06.26 Sunday
資格全般
21:54
comments(0)

本日、情報処理技術者試験当日の朝に私が保守しているシステムのミドルウェアでエラーが発生し、急遽出社対応が必要になりました。

同じシステムを保守している同僚達は受験の予定があったので、もともと受験の予定が無かった私が出社しリカバリさせました。ひどいタイミングでの障害でしたが、私に受験の予定が無くて本当に良かったです。

同僚達が良い結果であることを願います。

Check

プロジェクトマネージャ試験の論文を添削します

現在、残り1名の添削希望を受け付けています。
既に添削させていただいた方々からは、丁寧な添削で大変参考になったとの評価をいただいています。

先着31名まで、プロジェクトマネージャ試験の論文を無料で添削します。

ボランティアですのでお金はいっさいいただきません。

あなたが書いた論文を下記メールアドレスまで送信ください。

不明な点や質問についてもお気軽にメールでお問い合せください。

ymhr1121 atmark gmail.com（atmarkを@に変えてください）

私は専業の講師ではなく現役のプロジェクトマネージャーですが、論文作成のツボは心得ており、適切な添削ができるかと思います。

Check

プロジェクトマネージャ試験関連リンク集

受験の申込、出題範囲の確認
・情報処理推進機構：情報処理技術者試験

勉強のモチベーション維持、向上
・資格取得でNoリスク・Highリターン　（ASCII.jp －キャリア：ITエンジニアのためのスキルアップ研究より）

参考書・問題集
・情報処理教科書　プロジェクトマネージャ
　※amazon.co.jpより「情報処理教科書プロジェクトマネージャ三好康之」で検索

勉強法全般
・資格取得のための効率的な勉強法　（情報処理技術者試験☆合格への道より）
・プロジェクトマネージャ試験 | 勉強方法　（snapshotより）
・プロジェクトマネージャ試験に合格するまでにやったことの全て　（brittの日記より）

午後Ｉ対策
・情報処理技術者試験の勉強：午後Iの試験対策（その一、その二）　（高度情報処理技術者より）
・プロジェクトマネージャ試験午後Iの勉強法　（Not a passenger in lifeより）

午後ＩＩ対策
・論文特別講座　（情報処理技術者試験☆合格への道より）
・プロジェクトマネージャ合格のまとめ　（The sky is the limit!より）
・プロジェクトマネージャ合格のまとめの補足　（The sky is the limit!より）
・情報処理技術者試験ＰＭ午後IIの試験対策（その一　～　その九）　（高度情報処理技術者より）
・プロジェクトマネージャ試験午後IIの勉強法　（Not a passenger in lifeより）

午後ＩＩ　論文例
・平成８年度　問２　システム開発における仕様変更の管理について
　問題および論文　（Not a passenger in lifeより）

・平成１３年度　問２　要員交代について
　問題および論文　（Not a passenger in lifeより）

・平成１３年度　問３　テスト段階における品質管理について
　問題　論文　（情報処理技術者試験☆合格への道より）

・平成１４年度　問２　業務仕様の変更を考慮したプロジェクトの運営方法について
　問題　論文　（情報処理技術者試験☆合格への道より）

・平成１４年度　問３　問題発生プロジェクトへの新たな参画について
　問題　論文　（情報処理技術者試験☆合格への道より）
　問題および論文　（Not a passenger in lifeより）

・平成１５年度　問３　プロジェクト全体に波及する問題の早期発見について
　問題　論文　（情報処理技術者試験☆合格への道より）
　問題および論文　（Not a passenger in lifeより）

・平成１７年度　問１　プロジェクトにおける重要な関係者とのコミュニケーションについて
　問題および論文　　（情報処理技術者試験☆合格への道より）

・平成２０年度　問１　情報システム開発プロジェクトにおける利用部門の参加について
　問題および論文　（Not a passenger in lifeより）

Check

資格図鑑の取材を受けました

2009.12.13 Sunday
資格全般
08:44
comments(0)

資格図鑑の制作に関わっている方からIT系資格に関して取材を受けました。

資格図鑑は以下のようなコンセプトの資格ガイドです。
（ダイヤモンド社のサイトより抜粋）

人気資格４４のやりがいと収入、その仕事の現実をホンネで語る資格のバイブル！　世の中には国家資格をはじめとして任意団体が管理しているものまで約１５００種の資格があります。その中のどの資格なら独立が可能なのか等、ほとんどの人たちがよく理解していません。多くの場合は、大学や専門学校、資格学校などの宣伝を鵜呑みして、惑わされてしまいます。本書は、人生をムダにしないためのホンネの資格ガイドです。

今回の取材では、情報処理技術者試験や各種ベンダー系の資格に関して
・資格を持っていることで得られたメリット
・一般にありそうだと思われているメリットだが実際にはそうでもないもの
などを私の体験の中からお話させていただきました。

資格図鑑は現在2010年度版まで刊行されているのですが、
2011年度版にはそうした話のいくつかが反映されるかもしれません。

Check

システム監査技術者試験関連リンク集

受験の申込、出題範囲の確認
・情報処理推進機構：情報処理技術者試験

勉強のモチベーション維持、向上
・資格取得でNoリスク・Highリターン　（ASCII.jp －キャリア：ITエンジニアのためのスキルアップ研究より）

参考書・問題集
・情報処理教科書　システム監査技術者
　※amazon.co.jpより「情報処理教科書システム監査技術者」で検索

監査、IT統制関連書籍
・図解一番はじめに読む内部監査の本
・図解 IT統制入門

基準・指針・ガイドライン等
・新「システム監査基準」、「システム管理基準」　（経済産業省より）
・システム管理基準追補版(財務報告に係るIT統制ガイダンス）　（経済産業省より）

勉強法全般
・システム監査技術者試験勉強法　（人知らずしてより）
・合格体験記（システム監査技術者）　（情報処理技術者試験☆合格への道より）
・資格取得のための効率的な勉強法　（情報処理技術者試験☆合格への道より）
・システム監査技術者試験対策　（システム監査技術者試験に合格する。使いこなす。より）

午後Ｉ対策
・午後1の勉強方法　（システム監査技術者試験に合格する。使いこなす。より）

午後ＩＩ対策
・論文特別講座　（情報処理技術者試験☆合格への道より）
・システム監査技術者合格のまとめ　（The sky is the limit!より）
・「失敗」から学ぶ合格の秘訣　IT資格不合格体験記　（日経BP社より）

午後ＩＩ　論文例
・平成１４年度　問１　システム監査における監査調書の作成と整備について
　問題　論文　（情報処理技術者試験☆合格への道より）

・平成１７年度　問１　システム監査の品質確保について
　問題　論文　（情報処理技術者試験☆合格への道より）

・平成１９年度　問１　システム監査におけるＩＴの利用について
　問題および論文　　（情報処理技術者試験☆合格への道より）

・平成２０年度　問２　内部統制報告制度におけるシステム監査について
　問題および論文　（Not a passenger in lifeより）

午後ＩＩ　論文ネタ探し
・内部統制.jp ： ITpro　（日経BP社より）

Check

プロジェクトマネージャ試験午後IIの勉強法

プロジェクトマネージャ試験午後IIの論文対策ですが、これに関しては非常に参考になる参考書やサイトが存在しますのでぜひそちらを読んでみてください。

・翔泳社の情報処理教科書プロジェクトマネージャ
・ブログ「情報処理技術者試験☆合格への道」の論文特別講座カテゴリの記事

ただ、一点だけ私からアドバイスするとしたら、もしも論文を手書きで書くことがまだ不慣れなのにもかかわらず、以下の様な勉強方法をとっている方がいたら絶対に止めたほうが良いです。

１．特に時間制限を設けずに
２．ネット上や市販の論文集でネタを探しながら
３．テキストエディタで論文を作成する

私がソフトウェア開発技術者に合格し、その後しばらく論文試験のあるアプリケーションエンジニアに挑戦していた頃の話になるのですが、当時の私には「２時間という時間枠の中で問題文以外のものを何も見ずに手書きで論文を仕上げる」ということは、とんでもない苦行のように思えていました。

また、敢えてそんな苦労をしたところで、論文に不慣れな最初のうちは大した論文は書けやしないと思い、私は上記「１～３」のような方法で論文を作ることにしました。これで何本かそれなりの論文を作ることができたら、その後に本番試験同様に時間を計って手書きで論文を書く練習をするつもりでいました。

しかし、いくら時間をかけても１本も論文は完成しませんでした。

まず、時間制限が無いので、ちょっとした文章表現でも気に入らなければいくらでも直せてしまいます。さらに、手書きであればせっかく書いた文章を消しゴムで消す作業が伴いますので多少なりとも面倒くさく躊躇するものですが、テキストエディタを使っているので気軽に簡単にきれいさっぱり消すことができます。

また、ネット上や市販の論文集でネタを探しながら、というのもマズイです。本番の試験では試験開始後、大体１０～１５分のうちに、経験したプロジェクトあるいは直接経験はしてなくても自分が見聞きした周りのプロジェクト、といった限られた範囲の手持ちのネタを使用してなんとか書けそうと思える問題を選び、さらに論文の大筋のシナリオを決めるということをするかと思います。１５分以内くらいにそこまで決めて書き始めないと、時間内に規程の文字数をクリアできないからです。しかし、ネット上や市販の論文集でネタを探しながらですと、いつまでも踏ん切りがつかず、延々とネタ探しをしてしまいます。

今思うと「１～３」のような勉強方法は時間ばかり浪費してしまい、非常に非効率でした。それよりも、時間を計って手書きで論文を書くことをお勧めします。

たとえ時間内に完成させることができなくても、自分がどこに時間をかけすぎてしまったのか（例えば設問アの後半にやたら懲りすぎてしまった等）や、各設問のどの部分が書けずに詰まってしまったのか（＝自分に何の知識や経験が足りないのか）がよくわかります。

また、なんとか時間内に論文を書き上げることができたとしても、読み直してみると修正したり加筆したりしたほうが良いと思える箇所が見つかるはずです。

こうした点をもとに自分に足りない知識を補いつつ、論文を手早く書くコツのようなものを体得していったことが、私にとっては有効な論文対策になりました。参考にしていただければと思います。

※いちおう参考までにプロジェクトマネージャの勉強を始めた平成１８年度からの論文試験の成績を書いておきます。最初の２年は本番ではＢ評価で不合格でしたが、模試ではＡ評価でしたので、上で紹介した私のアドバイスは一定の効果はあるかな、と思います。

・平成１８年度ＴＡＣ模試　評価Ａ（１００点中６２点）
・平成１８年度の本番　　　評価Ｂ
・平成１９年度ＴＡＣ模試　評価Ａ（１００点中６１点）
・平成１９年度の本番　　　評価Ｂ
・平成２０年度の本番　　　評価Ａ

Check

合格時の再現論文（プロジェクトマネージャ）

平成２０年度　プロジェクトマネージャ試験　午後Ⅱ問１
問１　情報システム開発プロジェクトにおける利用部門の参加について

　プロジェクトマネージャは、情報システム開発のプロジェクト立ち上げ時に、業務仕様の確定、総合テストの準備などに関して、システムの利用部門の作業を明確にし、利用部門の合意を得る。
　プロジェクト遂行中には、利用部門の作業が計画通りに実行されないことによって、問題が発生することもある。このような場合、プロジェクトマネージャは問題の原因を分析し、分析結果に基づいて、問題を解決するための対策を検討しなければならない。例えば、次のような問題、原因及び対策が考えられる。
　・業務仕様の確定が遅れるという問題が発生し、その原因が利用部門の要員の業務
　　多忙にあれば、利用部門に対して、その要員を業務使用の確定のための作業に専
　　念させるように要求する。
　・総合テストの進捗が遅れるという問題が発生し、その原因がテストデータの不備に
　　あれば、利用部門にテストの目的と方法を再度説明した上で、協力してテスト
　　データの不備を改善する。
　プロジェクトマネージャは、複数の対策を検討し、その中から幾つかを選択したり、組み合わせたりして、プロジェクトの納期や予算などを守るために適切な対策を実施し、問題を解決しなければならない。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア
あなたが携わったシステム開発プロジェクトの概要と、合意を得られたシステムの利用部門の作業について、800字以内で述べよ。
設問イ
設問アで述べた利用部門の作業が計画どおりに実行されなかったことによって発生した問題とその原因、及び実施した対策は何か。その対策がプロジェクトの納期や予算などを守るために適切な対策であると考えた理由とともに、具体的に述べよ。
設問ウ
設問イで述べた対策について、あなたはどのように評価しているか、今後改善したい点とともに簡潔に述べよ。

※以下の回答例は、情報処理技術者試験の論文用紙と同様に、全角２５文字で改行しています。また、８００字詰めの用紙一枚が終わる箇所に罫線を入れています。

１．私が携わったプロジェクトの概要
１．１　プロジェクトの概要　
　私の勤務する企業は、生命保険会社から独立した情報
システム子会社である。私は、生命保険会社での各種事
務に係わるシステムを開発する部署に所属しており、プ
ロジェクト管理を主要な業務としている。
　今回、私が担当したのは宛先不明通知再送事務システ
ムの再構築プロジェクトである。生命保険会社では顧客
に向けて各種の通知を発送するが、顧客の転居などに伴
い会社が把握する住所が既に古いものとなっていること
があり、宛先不明で返送される通知が日々大量に発生す
る。本システムは、こうした顧客の現在の住所を調査し
通知を再送するまでの事務をサポートするものとなる。
　本プロジェクトの総開発工数は２０人月、開発期間は
６か月で、私はプロジェクト管理を担当した。
１．２　合意を得られたシステムの利用部門の作業
　本システムに関わる利用部門の体制としては、企画お
よび立案は生命保険会社の事務企画部が担当し、実際に
システムを利用して事務を行う担当は事務サービス部と
なる。
　本プロジェクトを進めるにあたり、プロジェクト発足
時に合意を得た利用部門の作業は以下の二点である。
　まず、一点目は要件定義である。週に一度、事務企画
部の課長１名と入社２年目の若手社員１名が出席する打
ち合わせにて要件のヒアリングおよび詳細化を行う。た
だし、要件定義が遅れた場合のことを考慮し、必要に応
じて週一回以外にも臨時で会議の場を設けることで合意
した。要件定義工程の期間は４週間で計画した。
　二点目は総合テストである。総合テストでのテストケ
ースは事務企画部主導で計画し、テストの実作業はエン
ドユーザである事務サービス部が行う。総合テスト工程
の期間は３週間で計画した。

２．利用部門の作業での問題、原因およびその対策
２．１　発生した問題
　要件定義工程に入って３週間目で問題が発生した。３
度目となる打ち合わせに事務企画部の課長が欠席となり、
翌日に臨時で開催した打ち合わせについても続けて欠席
となってしまったのである。その為、これらの打ち合わ
せの場では事務企画部の若手社員のみと要件定義作業を
行ったが、まだ事務に対する知識が浅く、質問を行って
も、事務企画部の課長かあるいは事務サービス部の社員
に聞かないとわからないので保留にして欲しい、という
回答が目立った。また、比較的簡単な要件に関する事項
でも若手社員には決定権が無く、最終的に課長の了承を
得ないと要件を確定できなかった。
　その結果、要件定義工程３週間が経過した時点で、要
件定義工程での未解決課題は１機能あたり約１．８件と
なった。本システムで定義する機能は１０機能あり、残
課題の総数は１８件となる。利用部門の協力が充分に得
られない現在の状況で、残り１週間のうちにこれら全て
の残課題を解決させることは難しいと考えられた。
２．２　問題の原因
　前述の要件定義工程の遅れという問題に対処するため、
私はその原因を整理した。
　まず一点目としては、本システム再構築の企画者であ
る事務企画部の課長が直近２回の打ち合わせに欠席して
いることである。その為、この課長でなくては判断でき
ないような課題が未解決のまま残ってしまい、進捗の遅
れを招いている。若手社員によると、この課長は別の業
務で発生したトラブル対応で多忙であり、打ち合わせに
参加できない状態となってしまっているとのことであっ
た。
　二点目は要件定義で発生した課題の半数は、打ち合わ
せの場では解決せず、その後に事務企画部が事務サービ

ス部の担当者へヒアリングを行った結果、解決に至って
いるということであった。これにより、打ち合わせ開催
後から課題解決に至るまで余分に時間がかかり、要件定
義工程全体の遅れに影響していた。
２．３　問題への対策
　前述の問題点に対処するため、私は以下の施策をとっ
た。
　まず、要件定義を進めるには課長に打ち合わせへ参加
してもらうことが必要であるため、自社のＰＭＯ経由で
事務企画部の部長に申し入れを行った。課長の業務多忙
状態を解消させ、打ち合わせに参加してもらうには、そ
の上司である部長に業務割り振りの見直しなどの対応を
取ってもらう必要があると考えたからである。
　調整の結果、課長が抱える別業務のトラブルは別の社
員と分担してもらうこととなり、要件定義工程の残り一
週間は毎日打ち合わせを開き、課長には必ず出席しても
らうことを約束した。
　また、それとは別の対策として、要件定義の打ち合わ
せの場に事務サービス部の主任クラスの社員を参加させ
てもらうよう課長に依頼した。前述の通り、要件定義で
発生した課題は、事務企画部が打ち合わせ後に事務サー
ビス部へヒアリングを行った結果、解決に至ったものが
約半数あり、事務サービス部の社員が打ち合わせに直接
参加すれば課題解決を効率的に進めることができると考
えたからである。
　しかし、事務企画部ではシステムの要件定義において
は自らの部門が窓口となり、他の部門を開発側と直接や
り取りさせない、という流れが従来からあるため、難色
を示された。これに対し、私は以下の点を説明し、最終
的に合意を得た。
・前提として、事務サービス部と開発側の間だけで勝手
に要件を決定するようなことはしないこと。

・課長の参画および打ち合わせの回数を増やすことにつ
いて約束できたものの、現時点で要件定義の進捗が遅れ
ていることに変わりはなく、当初の予定期間内に要件定
義を完了させるにはより速やかに課題を解決させていく
必要があること。それには事務サービス部の社員が打ち
合わせに直接参加することが効果的であること。
・事務サービス部は総合テストへの参画が予定されてい
るため、要件定義段階から参画することは本システムへ
の理解が深まり、総合テストの効率化および期間短縮が
期待でき、今後進捗遅れが発生した際のリスクヘッジと
なること。またテスト精度の向上も期待できること。
３．評価と改善点
３．１　評価
　以上の施策の結果、要件定義工程を予定通りに完了さ
せることができた。また、総合テストも予定期間内に完
了させ、納期を遵守することができた。
　成功の大きな要因はプロジェクト発足当初に利用部門
のかかわる作業を明確にし、合意を得ていたことにある
と考える。作業を明確にしたことで、予定と実態との乖
離が発生した際に速やかに対策の検討に入ることができ
た。また、利用部門と予め合意を得ていたことで、作業
への協力を充分に得られない状況に陥っても、その事前
の合意を根拠に交渉を行い、最終的に協力を得る事がで
きた。
３．２　改善点
　発生した問題点に対し、より多くの対策を挙げ、それ
らを比較検討し、納期や費用を守る上でより適切な対策
を選択することができればなお良かったと思われる。　
　次回以降のプロジェクトで同様に対策を検討すること
があった際には、そうした点にも留意するようにしたい。
（以上）
（設問ア：約800字、設問イ・ウ：約2,350字）

Check

論文例（平成８年度　プロジェクトマネージャ試験　問２　システム開発における仕様変更の管理について）

平成８年度　プロジェクトマネージャ試験　午後Ⅱ問２
問２　システム開発における仕様変更の管理について

※重要な箇所（論文で論述すべきと思われる箇所）に下線を引いています

　システム開発においては、業務要件や運用条件の変更などによって、仕様の変更が発生する場合が多い。仕様変更が統制なく行われると、プロジェクトの進捗やシステムの品質に重大な影響を与えるため、プロジェクトマネージャには仕様変更を適切に管理することが要求される。
　仕様変更の実施の可否を判断するに当たっては、変更の必要性の度合いと変更によるスケジュールや予算などへの影響を的確に把握することが重要である。この際、エンドユーザとの十分な調整が必要である。また、システム開発のどの段階であるかも十分に配慮しなければならない。例えば、基本設計の段階では容易に取り込める変更であっても、総合テストの段階では取込みが困難なことがある
　仕様変更の実施においては、変更したことによるシステムの整合性を確保するためのレビュー方法、変更が正しく行われ他に影響のないことを確認するためのテスト方法、及び変更作業の進捗管理に十分な考慮が必要である。更に、ドキュメントやプログラムなどに矛盾が生じないような配慮も必要である。
　あなたの経験に基づいて、設問ア～ウに従って論述せよ。

設問ア
あなたが携わったシステム開発プロジェクトの概要と特徴、及び仕様変更の発生状況を、800字以内で述べよ。
設問イ
設問アで述べたプロジェクトにおいて、仕様変更を適切に管理するためにどのような仕組みを作り、どのように運用したか。また特に工夫した点は何か。具体的に述べよ。
設問ウ
設問イで述べた仕組みと運用についての評価と改善すべき点について、簡潔に述べよ。

※以下の回答例は、情報処理技術者試験の論文用紙と同様に、全角２５文字で改行しています。また、８００字詰めの用紙一枚が終わる箇所に罫線を入れています。

１．私が携わったプロジェクトの概要
１．１　プロジェクトの概要　
　私は、生命保険会社の情報システム部門において、生
命保険契約の保険金支払いに関するシステムを開発する
担当に所属しており、プロジェクト管理を主要な業務と
している。
　今回、私が担当したのは保険金支払事務の進捗状況管
理システムの新規開発プロジェクトである。これは、全
国の支社、支部における保険金支払事務が遅滞無く行わ
れているかの管理を強化するためのシステムで、顧客へ
のサービス向上を図る狙いがある。
　本プロジェクトの総開発工数は８０人月、開発期間は
１０か月で、私はプロジェクト管理を担当した。開発体
制は、事務進捗データを作成するホストバッチ処理を開
発するバッチチームと、それを表示するＷｅｂベースの
画面を開発する画面チームの、２チーム体制とした。
１．２　仕様変更の発生状況
　２ヶ月間を予定しているプログラムコーディング工程
に入って１ヶ月（プロジェクト発足後６ヶ月）を経過し
た時点でユーザから要件の変更を行いたいという申し入
れがあった。本プロジェクトで開発する進捗状況管理シ
ステムの対象に保全事務を加えたいとのことであった。
保全事務とは契約内容（保障内容や名義、顧客情報など）
の変更に伴う事務を指す。
　事務進捗データは日時の夜間バッチ処理で作成する設
計だが、処理量の増加は翌朝のユーザ利用開始時間まで
に処理が完了しないことが懸念された。また、画面につ
いては保険金支払事務向けに設計を進めており、保全事
務向け画面を新たに開発する必要も考えられた。私はこ
の要件変更がシステムの品質やプロジェクトの工数、納
期に大きな影響を与えると予想した。

２．仕様変更管理の仕組みとその運用
２．１　仕様変更管理の仕組み
　私はプロジェクト計画段階でユーザと調整し、本プロ
ジェクトでの仕様変更管理に関して以下の施策を採った。
（１）変更管理委員会の設置
　ユーザから変更要求を文書にて受け付けた後、開発側
でスケジュールや予算への影響を調査した上で、週次で
開催する変更管理委員会にて採否の検討を行うこととし
た。この会議には、プロジェクトマネージャである私、
各チームリーダ、ユーザの担当者が出席する。また、影
響調査の結果、プロジェクトの予算や納期に影響を与え
る可能性がある変更要求に関して検討を行う際は、予算
と納期の決裁権を持つユーザ側の責任者に出席してもら
うこととした。
　この会議でプロジェクトの重要関係者による検討を行
うことで、変更の必要性とプロジェクトの予算やスケジュ
ールに与える影響を踏まえ、総合的な観点から採否を決
定できるようにした。
（２）仕様変更受け入れ可能期間の設定
　同じ仕様変更であっても、その発生が後半の工程にな
ればなるほど、手戻りによるプロジェクトへの影響は大
きくなる。そこで、仕様変更の受け入れ可能期間を設け
ることとした。当社としては外部設計の完了までで受け
入れを締め切ることとしたかったが、ユーザとの調整は
難航した。結果、プログラムコーディング工程完了まで
を受け入れ可能期間とすることで合意した。
（３）仕様変更発生を踏まえた契約条件の締結
　変更要求が予算や納期に影響を及ぼす場合はその都度
再見積りを行い、契約を締結しなおすことを契約の条件
として盛り込むことで合意した。
２．２　仕様変更管理の実施
（１）ユーザとの調整

　前述の変更要求については、ユーザからは再見積りし
た追加費用の請求に応じる代わりに納期については当初
の計画通り１月稼動とすることを強く要求された。追加
費用で要員を増員し、納期に間に合わせよ、ということ
である。
　しかし、一般に新規確保した要員は引継ぎなどで立ち
上がりに予想以上に時間がかかるというリスクも伴う。
そこで、私は追加費用の請求額を抑える代わりに以下の
案をユーザに提示し、合意した。
　まず、事務進捗データの項目数を三割削減すれば、処
理量の増加に耐えられる見通しが立ったため、ユーザ側
に見直しを依頼し、重要度の低い項目を削減することと
した。また、保全事務用の画面については新規開発せず、
当初から要件に含まれていた保険金支払事務用の画面を
簡略化し、保全事務でも使用できるような汎用的な画面
とすることで、必要工数を抑えることとした。
　これにより、いったん設計の手戻りは発生するが、使
用は簡略化されるため、次工程である単体テスト工程以
降の必要工数を当初より削減することができ、納期を遵
守できると判断した。
（２）変更の実施
　変更の実施に関しては、プロジェクト途中で急遽発生
する作業であるため、対応を急ぐあまり進捗やレビュー
実施状況の管理が疎かになりがちである。私は、変更管
理票に作業の予定開始日・完了日、実施担当者、レビュ
ー完了欄を設けることで、これを確実に管理することと
した。なお、必要な作業は全てＷＢＳに反映させること
で進捗状況の管理を行った。また、変更された設計書や
プログラムのバージョン管理については、当社の開発標
準であるリポジトリツールにて管理を行うことで矛盾が
生じないよう配慮した。
３．評価と改善点
３．１　評価
　以上の施策の結果、変更要求を受け入れた上で最終的
にプロジェクトの納期を遵守することができた。
　成功の大きな要因は、プロジェクト計画時に仕様変更
発生を踏まえた仕組みの整備やユーザとの取り決めを行
うとともに、ユーザとの調整を充分に実施したことであ
ると考えている。
　また、変更作業の実施においては進捗やレビュー状況
の管理を変更管理台帳にて行っていたため、作業実施状
況が不明確になったり、成果物の不整合が生じたりする
ことも無かった。
３．２　改善点
　仕様変更受け入れ期間については当社において明確な
基準が無く、プロジェクト発足のたびにユーザと調整す
るか、あるいは明確な取り決めの無いままプロジェクト
が開始されている。この点について基準を設けるよう当
社内に働きかけを行っていきたい。
（以上）
（設問ア：約800字、設問イ・ウ：約2,000字

Check

論文の事前準備と題意に合わせたアレンジについて

練習として以下３本の論文を書いてみました。

平成１３年度　問２　要員交代について
平成１４年度　問３　問題発生プロジェクトへの新たな参画について
平成１５年度　問３　プロジェクト全体に波及する問題の早期発見について

３本ありますが、実はどの論文例も取り扱っているプロジェクトは同じで、問題に合わせて多少状況設定を変えているだけです。

特に「平成１３年度　問２」と「平成１５年度　問３」は「成果物の品質不良」という問題がプロジェクトの途中で実際に起こったか、最初から起こると予想していたかの違いぐらいしかありません。

各論文例の状況設定は以下の表にまとめましたので見比べてみてください。

プロジェクトマネージャの論文問題は過去問題と似たテーマが再度出題されることがありますので、事前に論文を準備しておくというのは有効な対策だと思います。

ただし、例えテーマ（費用管理とか要員交代とか）は同じでも、いくらかは過去問とは違う内容を論述するよう要求してくるようですので、事前準備した論文をそのまま使うのではなく、題意をよく読みとってうまくアレンジして書き上げることが重要だと思われます。

逆に言うと、本番の試験で出題されたテーマがたまたま事前準備した論文と同じものだった場合、ラッキー！と思って、事前準備した論文を題意に合わせてアレンジすることなくそのまま使ってしまうと痛い目に遭います・・・。気をつけたいところです。

Check

論文例（平成１５年度　プロジェクトマネージャ試験　問３　プロジェクト全体に波及する問題の早期発見について）

平成１５年度　プロジェクトマネージャ試験　午後Ⅱ問３
プロジェクト全体に波及する問題の早期発見について

※重要な箇所（論文で論述すべきと思われる箇所）に下線を引いています

　情報システム開発のプロジェクトでは，顧客側の業務担当者の参加が約束されていなかったり，一部の要員の力量が不足していたり，一部の要員がほかのプロジェクトを兼任しスケジュール調整が難しかったりするなど，部分的に問題を抱えたままプロジェクトマネージャの判断でプロジェクトを立上げる場合がある。
　プロジェクトの遂行時には，これらの問題の解決が遅れたり，不十分であったりすることがある。その結果，例えば，要件定義が確定しなかったり，設計品質が低下したり，進捗が遅れたりするなどのプロジェクト全体に波及する問題になることがある。
　プロジェクトマネージャは，プロジェクトの立上げ時に抱えていた問題から波及するおそれがあるプロジェクト全体の問題を事前に想定し，その兆候を早期に発見することが重要である。そのためには，プロジェクトの立上げ時に抱えていた問題に応じて，例えば次のような項目の傾向を分析することが重要である。
・要件に対する質問への回答の遅れ日数
・要件定義の変更回数
・設計レビューの指摘件数
・兼任している要員の作業負荷
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア
あなたが携わったプロジェクトの概要と、プロジェクトの立上げ時に抱えていた問題について、800字以内で述べよ。

設問イ
設問アで述べた問題が解決できない状況において，プロジェクト全体に波及するどのような問題が発生すると想定したかを述べよ。また，どのようにしてその発生の兆候を早期に発見したか，分析した項目とともに，具体的に述べよ。

設問ウ
設問イで述べた活動をどのように評価しているか。また、今後どのような改善を考えているか。それぞれ簡潔に述べよ。

※以下の回答例は、情報処理技術者試験の論文用紙と同様に、全角２５文字で改行しています。また、８００字詰めの用紙一枚が終わる箇所に罫線を入れています。

１．私が携わったプロジェクトの概要
１．１　プロジェクトの概要　
　私は、生命保険会社の情報システム部門において、生
命保険契約の保険金支払いに関するシステムを開発する
担当に所属しており、プロジェクト管理を主要な業務と
している。
　今回、私が担当したのは保険金支払事務の進捗状況管
理システムの新規開発プロジェクトである。これは、全
国の支社、支部における保険金支払事務が遅滞無く行わ
れているかの管理を強化するためのシステムで、顧客へ
のサービス向上を図る狙いがある。
　本プロジェクトの総開発工数は８０人月、開発期間は
１０か月で、私はプロジェクト管理を担当した。開発体
制は、事務進捗データを作成するホストバッチ処理を開
発するバッチチームと、それを表示するＷｅｂベースの
画面を開発する画面チームの、２チーム体制とした。
１．２　立ち上げ時に抱えていた問題点
　私が所属する部署はホスト系の開発経験を持った要員
は多いものの、Ｗｅｂを初めとするオープン系の開発経
験者が少なく、本プロジェクトの様に画面開発を伴う場
合、社内の他部門から要員をアサインする。
　本プロジェクトの画面チームメンバもそうした他部門
の所属であったが、チームリーダのＡ氏以下全員が営業
支援系システムの開発経験者で、保険金支払事務に関す
るシステムの開発は今回が初めてであった。Ａ氏は、画
面開発の経験が豊富で、画面チームの要件定義、外部設
計を進める上で欠かせない人物であるが、業務知識不足
であることはリスクとなりえた。
　また、その対策として保険金支払事務に詳しいバッチ
チームリーダのＫ氏を画面チームの上流工程のサポート
役に充てることとしたが、バッチチームとの兼務となる
為、これについても留意する必要があると考えた。

２．プロジェクト全体に波及する問題
２．１　想定した問題

　私は前述のリスクから、以下の問題が発生する可能性
があると想定した。
（１）画面チームの品質不良
　本プロジェクトで開発する画面については、事務の進
捗状況に合わせて、画面のレイアウトや見出しを適宜変
化させて見栄えを良くしたいという要件があった。こう
した要件をまとめ上げ、業務の特性と矛盾することなく、
正しく設計に反映させるには保険金支払事務に関する一
定の業務知識が要求される。しかし、上流工程の実作業
者であるＡ氏には業務知識の面で不安があるため、要件
を正しく把握できず、外部設計の品質不良を招く恐れが
あると私は考えた。
　画面チームの外部設計における品質不良は、外部設計
工程そのものの進捗遅れとなり、後工程へしわ寄せが及
ぶ。また、後工程で外部設計の品質不良が発覚すれば、
大きな手戻りが発生する。私は、これらの問題がプロジ
ェクト全体の進捗遅れへと繋がると想定した。
（２）バッチチームの進捗遅れ
　画面チームでの品質不良を未然に防ぐ為、業務に詳し
いバッチチームリーダのＫ氏に、画面チームで実施する
ユーザヒアリングへの参画と、画面チームの外部設計書
の中間レビューを実施させることとした。これらの作業
はバッチチームとの兼務での実施となるが、私は以下の
問題が発生する可能性があると考えた。
　まず、兼務により、画面チームの作業に時間を割かれ、
本来の担当であるバッチチームの作業に専念できず、バ
ッチチームの進捗遅れへと繋がる恐れがある。また、兼
務による負荷の集中によりＫ氏が体調を崩すという最悪
の結果になることも想定しておく必要があると考えた。
もし、そうなれば画面チーム、バッチチーム両方に影響

が及び、プロジェクトとして致命的な痛手となる。
２．２　問題の早期発見
私は、これらの問題の兆候を早期に発見することができ
るよう、以下の項目の傾向を重点管理することとした。
（１）画面チームの外部設計レビュー指摘件数
　外部設計工程は２ヶ月間を予定している。私は、１ヶ
月経過時点で作成途中の外部設計書を対象にＫ氏による
中間レビューを実施させるとともに、指摘件数が当社の
品質管理基準範囲内であるかをチェックすることで、品
質不良の兆候を早期に察知できるようにした。なお、指
摘件数が基準値を下回った場合には、Ｋ氏によるレビュ
ーが期待する効果を出せていないということになるので、
これについても併せて注意を払うこととした。
　中間レビューを実施したところ、基準値を２割程度上
回る不備が検出された。Ｋ氏によると、死亡保険金と生
存保険金とで、事務の流れが異なることを考慮していな
いため生じた設計ミスが多いとのことであった。私は、
この点に関してＫ氏からＡ氏に対して指導させるととも
に、２週間後にも中間レビューを実施させ、再度品質の
状況を確認することとした。
（２）Ｋ氏の残業時間と作業時間割合
　私はＫ氏の日々の残業時間と、画面チームとバッチチ
ームそれぞれの作業時間を確認することで、兼務によっ
て発生する問題の兆候を把握できるようにした。残業時
間は、今年度Ｋ氏が残業可能な総時間（当社労働規定に
基づく）から換算し、毎日２時間を限度とした。また、
作業時間の割合はＷＢＳから画面２割、バッチ８割を基
準として見積り、プラスマイナス１０％を超えることが
無いか、週単位で監視した。
　外部設計工程の後半１ヶ月に入ると残業の増加傾向が
見られた為、バッチチームの担当作業のうち、比較的容
易なものを下位のメンバに割り振るなどさせ、負荷を分

散させた。
３．評価と改善点
３．１　評価
　以上の施策の結果、外部設計を予定された２ヶ月間で
完了させ、最終的にプロジェクト全体の納期を遵守する
ことができた。画面に関するユーザ要件も業務に詳しい
Ｋ氏の参画により漏れなく正確に取り込めるができ、ユ
ーザからの評価も高い。
成功の大きな要因は、プロジェクト立上げ時に抱えるリ
スクから生じる問題を事前に想定し、その予兆を把握で
きるようにすることで、必要な対策を早期に打てたこと
だと考えている。
３．２　改善点
Ｋ氏の残業時間の増加などにより、計画値以内ではある
が、費用の増加が発生した。私の部署では、Ｗｅｂベー
スの画面開発を伴うプロジェクトが今後も控えているが、
当社の組織体制の都合上、当面は業務知識の不足する他
部門に依頼しなければならない為、同種のプロジェクト
では計画時から予算の見積りや要員面で余裕を持たせる
ようにしたい。
（以上）
（設問ア：約800字、設問イ・ウ：約2,100字

Check