努力報われサクラ咲く！成績照会は次の通り。感無量。
-----------------------------------------------------
受験番号 PM*** - **** の方は，合格です。
午前試験のスコアは，715 点です。
午後I試験のスコアは，610 点です。
午後II試験の評価ランクは，A です。
-----------------------------------------------------
けさ起きたとき思った。今回もまたダメかもしれない、
そう簡単に受かるはずがないと。
だから、自分の番号を見たときは、半信半疑だった。
成績照会を見てようやく、あー合格したんだと実感した。
午後１、危なかったが、結果オーライ。
近日中に、合格体験記をアップしよう。
今夜は喜びの余韻を味わいつつ・・
JITEC（試験センター）から午後の解答例が公表された。
午後１は、もう自分の書いた解答の内容をはっきり覚えていないところも多く、はっきり言って採点のしようがなかった。ただ印象として、ITECやTACの出している解答例と比べ、微妙に異なっている箇所もあったような気がした。こうなると、スコアがどの程度になるのか全く予想がつかなくなってくる。部分点がもらえれば・・運がよければ・・という極めて混沌とした状況にあるのかもしれない。
午後２は、例によって解答例ではなく出題趣旨という「要約文」が掲載されている。これだけ読むと多くの人は「そんなことわかってるよ」と思うだろう。強いて気がついた点を挙げるとすれば、３問とも「プロジェクトマネージャとしての・・」という文言を含んでいること。PM試験だから当たり前のことなのだが、その当たり前が意外に難しい。私が選んだ問１の場合、重要な関係者とのコミュニケーションがテーマであるが、エンジニアではなくマネージャとしてのコミュニケーションでなければならない。そういうことを四苦八苦しながら考え、無我夢中で書いた記憶はあるが、もはや採点云々や合否の行方など全く判断できない。
あと15日。ただ祈るのみ。
半年前の記事（参考）:
解答例についての雑感
読書の秋もそろそろ終わり、木枯らしの季節がくる。10月までは仕事や勉強に忙しかったし、12月になると年末のゴタゴタでまた忙しくなる。だから11月というのは、落ち着いて本を読んだりするにはちょうどいい時期なのだ。ずっと積んだままにしていた小説を、私はいま読みふけっている。
さて、今年も残すところあと１ヵ月余りとなった。今年読んだ本の中で印象に残り、かつ、おすすめの本を紹介しておく。
書籍名：曖昧性とのたたかい 体験的プロジェクトマネジメント論
出版社：翔泳社 たしか購入したのは７月頃だったと思う。
Amazonのレビューを見ておもしろそうだと感じたこと、プロマネの勉強を本格的にやる前の参考にしようと思ったことが購入の動機だった。
実際に読んでみると、プロジェクト管理の一般的な知識がただ整理されているだけでなく、著者の実体験によって裏付けされた理論や主張がわかりやすく説明されている。「なるほど、言われてみれば確かにそうだ」とか「これは今まで気が付かなかった」などと考えながら、あっという間に読み終えてしまった。目からウロコとはこのことだ。プロジェクト管理に興味のある方はもちろん、多くの技術者にとって「システム屋のバイブル」になりうる本だと私は確信する。
開放感を味わえるはずの時期なのに、そういう気持ちになれない。
今までであれば、やっと終わった、しばらくのんびり過ごそうなどと思い、好きな本を読んだりしていた。試験のことなどあっというまに頭から消えていったものだが、今回は違った。頭にずっと残っているのだ。いったいどうしてだろう。
プレッシャーが無かったと言えばウソになる。難関のプロマネ試験とはいえ、これだけ受け続けているのだからそろそろ受からねばという重圧はあった。そして重圧に耐えながらもどうにか最後まで戦い抜いたはよかったが、あとになって、次から次へと論文の内容が頭に浮かんできたのである。あそこの記述はまずかった、ああいうことを書くべきでなかったとか、本当はこういうことを書けばよかったとか・・。
仕事が忙しければ、こんなふうに思い煩うこともないかもしれないが、皮肉にもこういう時にかぎって忙しくないのである。こうなったら、来年の春試験のことでも考えるしかないのか。ということで、ここ数日は前向きな気持ちに少しはなってきた。
第１候補 システム監査技術者
第２候補 テクニカルエンジニア（情報セキュリティ）
つづきはまた次回
今回受験したプロジェクトマネージャ試験について、振り返ってみたい。いま手元に問題がないので、私の記憶だけを頼りにまとめておく。
午前について 本音を言うと少し意表をつかれた問題もあったが、全体的には無難な問題が多かったと思う。今年から100分55問に増え、セキュリティ分野の問題が増えることも予想したが、さほど目立って出題された感じはなかった。過去の問題をまともにやっていれば大丈夫、という印象は変わらないが、時代の流れと共に少しずつ新しい傾向の問題に移行していることも確かである。（私の結果：ITEC解答速報で46/55。足切りはクリアできそう。）
午後１について じつはミスに気がついて少し意気消沈している。冷静に考えれば難しくない設問に対し、何を思ったか取り違えをしてしまった。減点は避けられないが、今更悔やんでも仕方がない。出題内容としては、特に目新しいものもなく、いかにも教科書的というか国家試験らしい、整然とした問題であったと思う。ミスは誰しも多かれ少なかれあるものと割り切って考えたい。（私の結果：問1,3,4を選択。出来は70％とみていたが少し評価を下げて65％程度か。）
午後２について 問１「重要な関係者とのコミュニケーション」を選択した。今年はセキュリティ関係がまた出題されるかとも思っていたが、やはりプロマネの本職といえば、進捗、品質、コスト、組織要員といった管理分野が基本になることを改めて感じた。ちなみに問２は進捗関係、問３はチーム編成がテーマだった。
問２は問題文がやや長いうえ難しそうに感じたので、問１と問３を比べたが、事前に考えていたネタを使えそうと判断したのは問１だった（じつは春のシス管も問１選択という縁起を意識した!!）。
コミュニケーションというテーマが過去にあったかどうか定かでないが、身近なテーマだけに選ぶ人は多かったのではないかと思う。ただし注意深く読んでいくと「直接の管理下にあるメンバ以外の関係者」というような前提条件がある。つまり、プロジェクトメンバ以外のキーパーソンを登場させる必要がある。論文は物語ではないが、登場人物にかかわる状況をよく説明し、わかりやすく描写しないと読み手に伝わらないという意味で、ある種のストーリー展開が求められるかもしれない。
肝心の出来のほうは、ここ毎回同じことを思うのだが、やはり不満足であった。何とか論文らしい構成になったものの、どうしても具体性に欠けてしまう。それでも、今までの経験から判断すると、そう悪い評価にはならないだろうと感じている。（私の結果：ア：800字、イ＋ウ：2000字。量はちょうど良かった。）
これからしばらくの間は、終わったあとの開放感に浸ろう。
いくつかミスもあったがご愛嬌。時間がたてば忘れてしまうだろう。
早くも合格発表の日時が試験センターから発表されていたのには驚いた。
とりあえず、試験を終えての感触だけ報告しておく。
午前 ：８割程度。
午後１：７割程度。
午後２：６割程度。合否は極めて微妙なところか。
論文は、重点的に対策を実施していたものの、やはり本番になると簡単に書けるものではない。春の試験のときと同様に、あとになってから次々とネタが浮かんできたり、文章の構成を考えたりと、後味がよくない。
きょうは疲れたので、またあとで詳しく振り返ってみようと思う。
<平成14年 問３>
１．プロジェクト概要及び参画時の状況
１−１．問題発生プロジェクトの概要
首都圏に約１００店舗を有する金融機関（以下ユーザと呼ぶ）では、汎用機による顧客情報システムが老朽化したため、Ｗｅｂベースへ再構築することになった。ユーザ本店のサーバに構築する顧客情報データベースの検索・更新を各店鋪から行うものである。予定工数は２５０人月、私が勤務するＳＩ企業Ｊ社が受託し、機能分割した４つのサブシステム毎にチーム編成されていた。
当プロジェクトは、稼働開始まであと３ヶ月という時期であり、マスタスケジュールによると本来はシステムテスト工程のはずであった。しかし、進捗は約１ヶ月遅れ、前工程の結合テストがまだ予定の半分しか進んでいなかった。こうした状況に加えて、プロジェクトマネージャのＡ氏が病気のため長期療養となったので、急遽、私が代役を務めることになった。
１−２．参画した時点でのプロジェクトの状況
開発現場にはテスト項目表や証跡資料などが山積みされ、整理されていない様子であった。そこで私は、Ａ氏から引き継いだ成果物一覧表に基づいて点検したところ、成果物レビューが行われた形跡（検印など）の無いものが散見される、必要な資料が不足しているなどの不備が判明した。
また、ユーザに対しては、週１回の会議で進捗状況や品質に関する報告を行う。私は今までの報告資料からテスト項目の消化数およびバグ摘出件数の推移を確認したところ、進捗遅延だけでなく、品質不良の問題もあることを認識した。２つのサブシステムで、結合テストの途中にもかかわらず、バグ件数が既に品質評価の基準値を超えそうな気配であったからである。一部のサブシステムの品質不良は、次工程のシステムテストに悪影響を及ぼすと推定されるため、早急に手を打つ必要がある。
２．問題発生プロジェクトの管理について（設問イ）
２−１．問題点の調査及び原因分析
上記のような状況では、得てしてバグの早期撲滅など対処的解決を急ぎがちになる。しかし、そうした目先の問題だけに焦点を当てず、なぜこのような状況になったのか、根本的な問題は何かという分析や検証から行わないと、真の解決には至らないと考える。そこで私は、以下の手順で問題点の調査と原因分析に当たった。
（１）問題点の調査方法
まず私は、各チームの現状を正確に把握するため、Ｊ社内部で緊急会議を開催した。そして、各チームリーダに結合テストの未解決バグ数、工程完了時期の見込みなどを報告させた。また、品質管理の実施状況を把握するため、今までに起票したバグ対応票をすべて提出させ、記述内容の精度や妥当性を自ら検証した。
一方、ユーザ側の責任者であるＹ氏にヒアリングを実施した。その際に、Ｊ社とのコミュニケーション、すなわち報告や連絡の仕方についての実態を聞き出し、率直な意見を求めた。ユーザの観点から、プロジェクトの運営方法に問題がなかったかを探るためである。
（２）原因分析の方法
進捗の遅れについては様々な原因が考えられたので、特性要因図を利用して分析した。具体的には、各チームリーダや主要メンバーにインタビューし、個人の問題、チームの問題、プロジェクト全体の問題とその原因を挙げてもらい、模造紙上に図示することによって因果関係を明らかにした。そして、これまでのプロジェクト管理に欠落及び不足している事項を加筆し、チームリーダに提示することで、全体の共通認識として確認した。
２−２．明確になった原因
調査・分析の結果、次の点が明らかになった。
（１）成果物レビューの実施方法が不明確である
テスト結果資料のレビュー方法が曖昧なため、チーム毎にばらつきが見られた。例えば、リーダ自ら成果物の内容をチェックするチームがある一方で、各メンバーのセルフチェックをもって完了とするチームがあった。このままでは成果物の品質が保証できないと私は考えた。
（２）バグ対応管理が適切に行われていない
本来は、各リーダが管理しＡ氏が最終確認する運営方法であった。しかし、リーダ自身も設計や実装に関するバグの調査などに追われ、管理が行き届かなかった。このため、未解決のバグが放置されたり、他のサブシステムに影響する事象の周知や調整が遅れたりしており、それが品質不良を引き起こす要因になっていた。
（３）ユーザへの報告・連絡が遅い
発見したバグのうち外部設計に関わるものは、早期にユーザへ報告し設計変更などの対応方法を決める必要がある。しかし調査の結果、報告のタイミングが遅く、対応が後手に回っていたことが判明した。これはＹ氏からの情報でも裏付けられた事実である。このため、再テストの実施など作業の手戻りが多く発生していた。
２−３．実施した対策
以上の問題点、並びに稼動開始まで３ヶ月しかないことを考慮し、私は以下に述べる対策を実施した。
（１）役割分担の明確化
チームリーダは、担当するサブシステムの品質を確保する役割を担うと考える。そこで私は、各リーダに対し、個々のバグ対応よりも、チーム全体の成果物レビューや他のチームとの調整を優先させるよう、役割分担を明確にした。そして、ＴＲＭに不足していたレビュー項目を追加し周知する、チーム間の調整会議を定例化するなどの改善策を実行した。
（２）ユーザ対応の迅速化と確認
特に外部設計に関わる改修作業は多くの工数を要することから、私から逐次ユーザへ報告し迅速に対応する方針を、全メンバーに提示した。また、会議の席上で修正点を再確認し、認識ずれの発生を防止した。
（３）段階リリースの検討及びユーザへの折衝
残作業の工数を見積もった結果、残り３ヶ月で結合テストとシステムテストの完了は不可能であると判断した。そのため私は、最も進捗が遅れている１サブシステムは、やむを得ず稼動開始を遅らせたい旨をＹ氏へ伝えた。折衝の末、予定時期の１ヶ月後の納期厳守を条件とし段階リリースとすることで承認された。
３．評価及び改善点（設問ウ）
３−１．実施活動の評価
３サブシステムは計画通りの稼働開始、１サブシステムはその１ヶ月後の稼働開始を遂げた。プロジェクト管理上の問題点を中心に調査と原因分析、改善策を精力的に実行したことで、軌道修正ができたと評価する。
特に、チームリーダの役割を明確化したことにより、成果物レビューの実施方法が確立し、成果物の機能不備や品質不良が改善できている。最終的なバグ件数は基準値の上限を上回ったものの、収束傾向を示しており、品質は確保できたと判断している。また、ユーザへのヒアリングによりプロジェクト運営上の問題を把握しただけでなく、こうした積極性がユーザとの信頼関係を保つことにつながったと感じている。
３−２．今後の改善点
危機的な状況を乗り切ったことで貴重な経験であったと思う反面、このようなプロジェクトは二度とあってはならないと考える。のちに復帰したＡ氏と共に振り返る機会があり、今後の改善点について次のような見解で一致した。
・進捗や品質の状況は、メンバーからの報告を鵜呑みにせず、成果物を提出させるなどしてプロジェクトマネージャ自身の目でも確認する必要がある。
・標準的な管理手法を確立し、メンバー全員に理解させたうえで、適切に実行されているか否かの監視や追跡を続けることが肝要である。
<修正ポイント・考察など> 問題文の中にくり返し出てくる文言は、その問題のキーワードと捉えるべきだろう。今回の問題でいえば「成果物の機能不備や品質不良」という文言が、設問もあわせて３回も出てくることに気がつく。３回も出てくるキーワードを無視するわけにはいくまい。そのことに注意し、気合いを込めて修正してみた。
論文は前半が特に大切ということがわかる。後半は手を抜いてもいい、という意味ではない。前半、つまり設問アの後半400字から設問イの初めの400字あたりの書き方がうまくいけば、そのあとも自然な流れで書けるということだ。今回の場合は、設問アの１−２でキーワードをしっかりと入れ、設問イにつなげたことにより、全体として筋の通った論旨の展開ができたと思う。
<スキル基準> 論文作成において参考になった以下の基準について、復習しておこう。
プロジェクト追跡と実行管理 3-3 問題管理 プロジェクト追跡と実行管理 3-6 進捗管理 プロジェクト終結 5-1 プロジェクト終了状況の確認あとがき：
論文対策は、約40日間の厳しい修行のようであった。ときには仕事で疲れきった日もあり、何度か挫折しそうになったが、ここで気持ちを切りたくないという思いで勉強を続けられたことに、悔いはないと感じている。試験日まで残り６日。最終確認をして本番に備えよう。
下書き論文の改善メモ
１−１
設問は「問題発生プロジェクトの概要」なので、ここで問題点について言及しておく必要がある。
１−２
設問は「成果物の機能不備や品質不良などの状況」なので、それをきちんと書かなければいけない。
２−１
詳しく書いたつもりだったが、論文というより単なる報告書を読んでいるような気がする。もう少し自分の主張とか考えを入れたほうがいいだろう。
２−２
ここだけ読めば特に問題なさそうだが、これらの原因によって引き起こされた問題点、つまり「機能不備や品質不良」がきちんと表現されていなかったため、あれ？と感じる。
２−３
（１）は抽象的すぎる。
役割分担を明確にするために何をしたのか。もう一声！
３．
品質向上できたと言える客観的根拠がほしい。
項番は上記に合わせ３−１、３−２に修正しておく。
最後の論文対策は、意外に改善すべき点の多い検証結果となった。前回は「徐々に筆がなめらかになってきた」などと評していたが、それは裏を返せば、出題の要求事項から逸脱する恐れもある、ということになる。特に今回の問題は、実際の開発現場でありがちな生々しい状況設定を書きたくなるが、そこだけに注力すると大切なポイントを忘れてしまう。書きやすいと思うテーマほど、じつは落とし穴にはまりやすいことがわかった。注意しよう。
<平成14年 問３>
１．プロジェクト概要及び参画時の状況
１−１．問題発生プロジェクトの概要
首都圏に約１００店舗を有する金融機関（以下ユーザと呼ぶ）では、汎用機による顧客情報システムが老朽化したため、新たにＷｅｂベースの新システムを再構築することになった。ユーザ本店の顧客台帳サーバと各店鋪の支店サーバ及びパソコンとの連携により、ユーザと取引のある顧客情報を一元管理するデータベースの検索などを行うものである。開発は、私が勤務するＳＩ企業Ｊ社が受託し、予定工数は２５０人月、機能分割した４つのサブシステム毎にチーム編成されていた。
当プロジェクトは１０ヶ月前に立ち上がり、稼動開始まであと３ヶ月という時期であった。ところが、プロジェクトマネージャのＡ氏が病気により長期療養となったために、急遽、私が代役を務めることになった。
１−２．参画した時点でのプロジェクトの状況
私が参画した時期は、マスタスケジュールによると、本来ならばシステムテスト工程のはずであった。しかし、進捗は約１ヶ月遅れており、前工程の結合テストがまだ予定の半分しか進んでいなかった。開発現場にはテスト項目表や証跡資料、バグ対応票などが山積みされていたが、整理されていない様子であり、私は品質に対する不安を抱いた。何人かのメンバーの話によると、プロジェクト開始当初は、Ａ氏を中心に各メンバーが積極的な姿勢で作業に取り組んでいたようであった。ところが、テスト工程にはいった頃から徐々に進捗のペースが落ちていった。現在は、週１回の進捗会議で、品質面についても確認しているが、サブシステム毎にテスト項目の消化数やバグ対応件数の報告を形式的に行うだけで、より踏み込んだ議論には至らないという。
以上の状況から私は、プロジェクトが抱える問題を解明し、早急に手を打つ必要があると認識した。
２．問題発生プロジェクトの管理について（設問イ）
２−１．問題点の調査及び原因分析
（１）調査の方法
まず私は、Ｊ社内部で各チームリーダを召集し、緊急会議を開催した。そして、各チームの現状を正確に把握するため、結合テストの残項目数、未解決バグ数、工程完了時期の見込みなどを至急報告するよう指示を出した。また、品質を詳細に分析するため、今までに起票したバグ対応票をすべて提出させ、バグ事象や原因、対処の状況、記述の仕方などに注意して自ら確認した。
一方、ユーザ側の責任者であるＹ氏にヒアリングを実施した。その際に、進捗や品質の問題だけでなく、Ｊ社の開発メンバーとのコミュニケーション、すなわち報告や連絡の仕方についての実態を聞き出し、率直な意見を求めた。ユーザの観点から、プロジェクトの運営方法に問題がなかったかを探るためである。
（２）原因分析の方法
進捗の遅れについては様々な原因が考えられたので、特性要因図を利用して分析した。具体的には、各チームリーダや主要メンバーにインタビューし、個人の問題、チームの問題、プロジェクト全体の問題とその原因を挙げてもらい、箇条書きで図示することによって因果関係を洗い出した。そして結果を模造紙へ記入し、チームリーダに提示することで再分析し、全体の共通認識として確認しあった。
２−２．明確になった原因
（１）成果物レビューの実施方法が不明確である
テスト実施後のレビューはスケジュール化されているものの、その実施方法が曖昧なためチーム毎にばらつきが見られた。例えば、リーダ自ら成果物の内容をチェックするチームがある一方で、各メンバーのセルフチェックをもって完了とするチームがあった。このままでは成果物の品質が保証できないと私は考えた。
（２）バグ対応管理が適切に行われていない
各リーダが管理し、Ａ氏が総括する運営方法であった。しかし、リーダ自身もバグ対応、すなわち設計や実装に関する不具合の調査などに追われ、管理が行き届かなかった。このため、未解決のバグが放置されたり、他のサブシステムに影響する事象の周知や調整が遅れたりして、テストの進行を妨げる要因になっていた。
（３）ユーザへの報告・連絡が遅い
発見したバグのうち業務仕様に関わるものは、早期にユーザへ報告し仕様変更などの対応方法を決める必要がある。しかし調査の結果、報告のタイミングが遅く、対応が後手に回っていたことが判明した。これはＹ氏からの情報でも裏付けられた事実である。このため、再テストの実施など作業の手戻りが多く発生していた。
２−３．問題解決策
以上の問題点、並びに稼動開始まで３ヶ月しかないことを考慮し、私は以下に述べる対策を実施した。
（１）役割分担の明確化
チームリーダは、担当するサブシステムの品質を確保する役割を担うと考える。そこで私は、各リーダに対し、個々のバグ対応よりも、チーム全体の成果物レビューや他のチームとの調整を優先させるよう、役割分担を明確にした。
（２）ユーザ対応の迅速化
仕様に関わる作業は多くの工数を要することから、私から逐次ユーザへ報告し迅速に対応する方針を、各リーダはじめ全メンバーへ周知した。
（３）段階リリースの検討及びユーザへの折衝
想定される残作業の工数を見積もった結果、残り３ヶ月で結合テストとシステムテストの完了は不可能であると判断した。そのため私は、最も進捗が遅れている１サブシステムのみ稼動開始を遅らせたい旨をＹ氏へ伝えた。折衝の末、予定時期の１ヶ月後の納期厳守を条件とし段階リリースとすることで承認された。
３．評価及び改善点（設問ウ）
（１）実施活動の評価
３サブシステムは計画通りの稼動開始、１サブシステムはその１ヶ月後の稼動開始を遂げた。プロジェクトは非常に厳しい状況であったが、管理上の問題点を中心に的確な調査と原因分析、解決策を精力的に実行したことで、うまく軌道修正ができたと評価している。特に、チームリーダの役割を明確に打ち出したことにより、各リーダの自覚を促し、プロジェクト全体の品質を均一に向上できたと考えている。また、ユーザへのヒアリングによりプロジェクト運営上の問題を把握しただけでなく、こうした姿勢がむしろユーザとの信頼関係を保つことにつながったと感じている。
（２）今後の改善点
危機的な状況を乗り切ったことで貴重な経験であったと思う反面、このようなプロジェクトは二度とあってはならないと考える。のちに復帰したＡ氏と共に振り返る機会があり、今後の改善点について次のような見解で一致した。
・計画時、体制と役割は念入りに検討すべきである。
・進捗や品質の管理はチームリーダに任せた場合でも、必ずプロジェクトマネージャが別な角度から検証する。
・標準的な管理手法を確立し、メンバー全員に理解させることが肝要である。
問題発生プロジェクトへの新たな参画について <平成14年 問３>
成果物の機能不備や品質不良などによって進捗が遅れているプロジェクトに、プロジェクトマネージャとして新たに参画し、問題を早期に解決する使命を与えられる場合がある。このようなプロジェクトでは、進捗管理や成果物レビューが不十分であったり、要員の士気が低下していたり、顧客との信頼関係が悪化していたりするなどのプロジェクト管理上の問題点が見られることが多い。
新たに参画したプロジェクトマネージャは、そのプロジェクトの過去の管理方法などにとらわれることなく、新たな観点で問題点の調査や原因の分析などを行うことが重要である。まず、プロジェクトや構築する情報システムの特徴を理解した上で、プロジェクト管理上の問題点を調査する。そのためには、例えば、次のような項目を自ら検証する。
・プロジェクトの進捗管理や成果物の品質管理などの実施方法・実施状況
・成果物の作成状況やレビュー結果の反映状況
・プロジェクト体制や要員配置の状況
次に、調査結果を基に、プロジェクト管理上の問題点の原因を分析する。この分析は、これまでのプロジェクトの管理に欠落及び不足していると思われる事項を重点的に行う。そして、対策を検討して実施する。例えば、レビューの管理や実施体制に原因があれば、管理帳票や記録帳票などを改訂したり、実施体制を変更したりする。このようにして、これまでの問題点を是正し、成果物の機能不備や品質不良などを早期に解決することが重要である。
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
設問ア
あなたが新たに参画した問題発生プロジェクトの概要と、参画した時点での成果物の機能不備や品質不良などの状況を、800字以内で述べよ。
設問イ
あなたは、プロジェクト管理上の問題点をどのように調査し、その原因をどのように分析したか。また、その結果、明確になった原因と実施した対策は何か。それぞれ具体的に述べよ。
設問ウ
設問イで述べた活動をどのように評価しているか。また、今後どのような改善を考えているか。それぞれ簡潔に述べよ。
<平成15年 問３>
１．プロジェクト概要及び立上げ時の問題
１−１．プロジェクト概要
関東中心に約２００店舗を有する金融機関（以下ユーザと呼ぶ）では、経営基盤の強化と基幹業務のコスト削減を目的とし、財務会計システムを開発することとなった。当システムは、インターネットを利用し、ユーザ本店の基幹サーバと各店鋪の支店サーバ及びパソコンとの連携により、財務情報を一元管理するデータベースの検索・更新や帳票出力等の事務処理を行うものである。
私が勤務する情報処理サービス会社Ｊ社は、ユーザの既存システム開発・運用を長年にわたり受託してきた。こうした経緯から、今回の新システム開発も要件定義以降をＪ社が一括して受託し、私はプロジェクトマネージャとして全体を統括し、指揮することになった。
１−２．プロジェクト立上げ時の問題
開発体制を整える段階で、私は問題を抱えていた。２名の要員が、他のプロジェクト（以下、現業と呼ぶ）の期間延長により、すぐに参加できなくなったのである。この２名はユーザ本店で常駐ＳＥの経験があり、金融業の知識が豊富であったため、私は要件定義からシステムテストまでを通して任せるつもりでいた。要件定義は４名で行う計画のため、そのうち２名が参画できないのは致命的であった。この２名に代わる要員も候補として挙げて検討したが、業務知識の面でスキル不足は否めず、私は結局、この２名を現業との兼任という形で、当プロジェクトを立ち上げることにした。
現業とは、店鋪統合に関わるシステム開発である。私は、上記の２名が兼任であるため、現業の責任者（プロジェクトマネージャ）とプロジェクト間の作業スケジュール調整を入念に行うべきと考えた。また、兼任となる期間はおよそ２ヵ月であり、要件定義の期間と重なるため、何らかのリスク対策が必要である。
２．プロジェクト全体に波及する問題について（設問イ）
２−１．全体に波及すると想定した問題
一部の要員が兼任でスタートするというリスクによりどのような問題が想定されるのか、以下に述べる。
（１）進捗の遅れ
一般に要件定義では、調査や分析といった非定型的な作業が中心となるため生産性の見積もりが難しく、綿密なスケジュールを作成しにくい。今回のプロジェクトもその傾向があり、まず曖昧なユーザ要件をいかに明確化するかがポイントになる。こうした状況において兼任で作業する場合、仮に現業でトラブルが発生したとすると、こちらの作業よりもトラブル対応が優先されてしまうのは明らかである。このため、要件定義がなかなか完了せず、そのしわ寄せが後工程に及び、進捗の遅れが顕在化するといった問題が想定された。
（２）費用超過
進捗が遅れると、遅れを取り戻すために残業時間が増えると予測できる。つまり、プロジェクトにかかる労務費が増加し、これが続くと予算オーバー即ち赤字となってしまうことも考えられる。
（３）品質の低下
私は、兼任となる２名の力量は十分と見ており、豊富な業務知識に基づく品質の確保を期待した。しかし、現業に多くの時間を費やすと、当プロジェクトの作業に集中できない、成果物の検証やレビューが不十分になるといったことが想定される。さらに、要件定義や基本設計の品質に問題があると、後工程で問題を解消するための多大な工数が必要となる。
２−２．問題発生の兆候の早期発見策
上記の問題が発生する兆候を早期に発見するため、私は次の各項目について分析した。
（１）兼任している要員の作業負荷
要件定義の２ヵ月間は、２名の要員が兼任となるため、現業及び当プロジェクトそれぞれの作業負荷を監視する必要がある。現業はシステムテスト中であり、テスト項目数を管理対象としていた。しかし、要員の作業負荷を分析するには、テスト消化状況のほかに作業時間を考慮する必要がある。そこで私は、兼任の２名に作業スケジュール並びに勤務報告書の提出を指示した。現業が過度の負担になっていないか、今後の作業への懸念材料はないか等を分析するためである。具体的には、週単位の労働時間のうち現業に費やす時間が全体の５０％を超えた時は危険信号とみなし、作業の調整を行った。一方、要件定義のほうは、定期的に成果物を提出させて進捗状況を確認した。
（２）設計レビューの指摘件数
要件定義が予定通り完了しても、次の設計工程で品質不良などの問題が顕在化することもあり得る。このため、設計レビューを重視し、レビューでの指摘件数が標準値の範囲から外れていないか分析した。その際、設計書が完成した後では修正作業による手戻りが大きくなるため、設計工程の途中に１〜２回の中間レビューを行う計画とした。
中間レビューでの指摘件数が基準に照らして多すぎる場合は、品質低下の兆候として捉えた。逆に指摘件数が少なすぎる場合は、適切なレビュアーが参加していないため問題が見つけられない、難易度の低い設計部分しか完了していない等の可能性がある。こうした分析により、品質上の問題が拡大する前に適切な処置を施すようにした。
３．評価及び改善点（設問ウ）
３−１．実施活動の評価
プロジェクト全体に関わる大きな問題もなく、財務会計システムは無事に稼動した。兼任とした２名に関し、現業のテスト結果の検証作業がピークとなり、プロジェクト全体の進捗に影響しそうな時期もあった。しかし、現業の責任者と共に、検証作業を他のメンバーに振り分けるなど作業負荷の平準化とスケジュール調整を行い、当プロジェクトの進捗遅延や費用超過を未然に防止できた。また、設計レビューの指摘件数を工程途中で分析したことにより、品質低下を避けることができた。
以上の通り、問題発生の兆候を早期に発見できていることから、私の実施した活動は、プロジェクトに対して有効に機能したと評価する。
３−２．今後の改善点
プロジェクトの初期段階で様々な観点からリスクを識別し、リスク管理を計画的に実行することの大切さを感じた。Ｊ社はこのような取り組みが遅れているため、組織的な改善が必要と思われる。したがって、今回のプロジェクトの実績・評価を参考とし、問題管理の方法を標準化及び詳細化し、今後の開発プロジェクトに適用していきたい。
<修正ポイント・考察など> 問題文にはリスクという言葉は出てこない。しかし、リスク管理を適切に行うプロセスについて述べれば、ほぼ題意に沿った論文になる。リスクそのものを軽減する対策とか、問題が発生した後の解決策などを中心に書いてしまうと、まちがいなくアウトだと思われる。そうではなく、どのようにリスクを分析し、リスクが大きな問題に広がる前に、どのように問題発生の予兆を発見したか、あるいは発見する仕組みを考えたかといった点が問われている。
そういうところに注意し、何とか書き上げたつもりである。説明が不足している箇所は肉付けし、無駄な部分は削るという、いつものやり方である。
しかし、あらためて初めから読んでみると、もっと興味深い内容を盛り込めないものかと思う。出題テーマにもよるのだろうが、書いても書いても内容がありきたりなものにしかならないような気がする。もう少し頑張ってみよう。
<スキル基準> 論文作成において参考になった以下の基準について、復習しておこう。
プロジェクト計画策定 2-A リスク管理計画 プロジェクト追跡と実行管理 3-C リスク管理
下書き論文の改善メモ
１−１
過去２回と異なるプロジェクトを題材にしてみた。様々なネタで書けるようにしておきたいので、これはこれでいいと思う。
１−２
兼任メンバー２名をどうしても必要とする理由として、業務に精通している事だけでは、やや弱い気がする。もう少し深みを出したい。
２−１
ＱＣＤを意識して忠実に書いてみた。流れとしてはいいが、やや抽象的で説明不足か。もう少し具体的に書きたいところ（特に品質）。
２−２
「作業負荷」は、あと一息。どのように分析したのかもう一声！
「レビュー指摘件数」は、ほぼＯＫ。
３−１
評価もおおむね書けているが、早期に問題を発見できたというニュアンスが欲しい。
論文対策も３回目で、徐々に筆がなめらかになってきた気がする。本番では２時間で書き切らなければならないので、途中で筆が止まらないよう一気に書く訓練をしておきたい。あとは、プロジェクトマネージャとして専門性を感じさせるキーワードを盛り込む、なるべく定量的な表現をする、といったことに留意すればいいだろう。
<平成15年 問３>
１．プロジェクト概要及び立上げ時の問題
１−１．プロジェクト概要
関東中心に約２００店舗を有する金融機関（以下ユーザと呼ぶ）では、経営基盤の強化と基幹業務のコスト削減を目的とし、財務会計システムを開発することとなった。当システムは、インターネットを利用し、ユーザ本店の基幹サーバと各店鋪の支店サーバ及びパソコンとの連携により、財務情報を一元管理するデータベースの検索・更新や帳票出力を行うものである。
私が勤務する情報処理サービス会社Ｊ社は、ユーザの既存システム開発・運用を長年にわたり受託してきた。こうした経緯から、今回の新システム開発もＪ社が一括して受託し、私はプロジェクトマネージャとして全体を統括し、指揮することになった。
１−２．プロジェクト立上げ時の問題
開発体制を整える段階で、私は問題を抱えていた。プロジェクトメンバーとして確保していた一部の要員２名が、他のプロジェクト（以下、現業と呼ぶ）の期間延長により、すぐに参加できなくなったのである。この２名はユーザ業務に精通していたため、要件定義からシステムテストまでを通して任せるつもりでいた。要件定義は４名で行う計画のため、そのうち２名が参画できないのは致命的であった。この２名に代わる要員も候補として挙げて検討したが、業務知識の面でスキル不足は否めず、私は結局、この２名を現業との兼任という形で、当プロジェクトを立ち上げることにした。
現業とは、店鋪統合に関わるシステム開発である。私は、上記の２名が兼任であるため、現業の責任者（プロジェクトマネージャ）とプロジェクト間の作業スケジュール調整を入念に行うべきと考えた。また、兼任となる期間はおよそ２ヵ月であり、要件定義の期間と重なるため、特別な対策が必要である。
２．プロジェクト全体に波及する問題について（設問イ）
２−１．全体に波及すると想定した問題
一部の要員が兼任でスタートするというリスクによりどのような問題が想定されるのか、以下に述べる。
（１）進捗の遅れ
一般に要件定義では、調査や分析といった非定型的な作業が中心となるため生産性の見積もりが難しく、綿密なスケジュールを作成しにくい。今回のプロジェクトもその傾向があり、各メンバーは漠然と、定められた期限までに要件定義を完了させればいいと考える。したがって兼任で作業する場合、仮に現業でトラブルが発生したとすると、こちらの作業よりもトラブル対応が優先されてしまうのは明らかである。このため、要件定義がなかなか完了せず、そのしわ寄せが後工程に及び、進捗の遅れが顕在化するといった問題が想定された。
（２）費用超過
進捗が遅れると、遅れを取り戻すために残業時間が増えると予測できる。つまり、プロジェクトにかかる労務費が増加し、これが続くと予算オーバー即ち赤字となってしまうことも考えられる。
（３）品質の低下
私は、兼任となる２名の力量は十分と見ている。しかしながら、現業に時間を取られて当プロジェクトの作業に集中して取り掛かれない場合、期待した品質が得られないことも想定される。特に要件定義あるいは基本設計での品質に問題があると、後工程で問題を解消するために多大な労力が必要となる。
２−２．問題発生の兆候の早期発見策
上記の問題が発生する兆候を早期に発見するため、私は次の各項目について分析した。
（１）兼任している要員の作業負荷
要件定義の２ヵ月間は、２名の要員が兼任となるため、現業及び当プロジェクトそれぞれの作業負荷を監視する必要がある。現業はシステムテスト中であり、テスト項目の消化件数により進捗状況を管理していた。しかし、今回のように複数プロジェクトを兼務する要員の作業負荷を分析するには、作業時間も考慮しなければならない。そこで私は、現業の責任者に、２名の作業スケジュール並びに勤務報告書の提出を依頼した。これにより、当プロジェクトの要件定義を進めるうえで、現業が過度の負担になっていないか、あるいは今後の作業への懸念材料はないか等を分析した。
（２）設計レビューの指摘件数
要件定義が予定通り完了しても、次の設計工程で品質不良などの問題が顕在化することもあり得る。このため、設計レビューを重視し、レビューでの指摘件数が標準レベルから外れていないか分析した。その際、設計書がすべて完成した後に問題が発覚すると手戻りが大きくなるため、設計工程の途中に１〜２回の中間レビューを行う計画とした。
中間レビューでの指摘件数が基準に照らして多すぎる場合は、品質低下の兆候として捉え、私は担当者に設計書の見直しを行わせた。逆に指摘件数が少なすぎる場合は、適切なレビュアーが参加していないため問題が見つけられない、難易度の低い設計部分しか完了していない等の可能性がある。こうした分析により、品質上の問題発生の兆候を早期に発見し、問題が拡大する前に適切な処置を施すようにした。
３．評価及び改善点（設問ウ）
３−１．実施活動の評価
プロジェクト全体に関わる大きな問題もなく、財務会計システムは無事に稼動した。兼任とした２名に関し、現業のテスト結果の検証作業がピークとなり、プロジェクト全体の進捗に影響しそうな時期もあった。しかし、現業の責任者と共に、検証作業を他のメンバーに振り分けるなど作業負荷の平準化とスケジュール調整を行い、当プロジェクトの進捗遅延や費用超過を未然に防ぐことができた。また、設計レビューの指摘件数を工程途中で分析したことにより、品質低下を避けることができた。以上により、私の実施した活動は有効であったと評価する。
３−２．今後の改善点
プロジェクトの初期段階で様々な観点からリスクを識別し、リスク管理を計画的に実行することの大切さを感じた。Ｊ社はこのような取り組みが遅れているため、組織的な改善が必要と思われる。したがって、今回のプロジェクトの実績・評価を参考とし、問題管理の方法を標準化及び詳細化し、今後の開発プロジェクトに適用していきたい。
プロジェクト全体に波及する問題の早期発見について <平成15年 問３>
情報システム開発のプロジェクトでは、顧客側の業務担当者の参加が約束されていなかったり、一部の要員の力量が不足していたり、一部の要員がほかのプロジェクトを兼任しスケジュール調整が難しかったりするなど、部分的に問題を抱えたままプロジェクトマネージャの判断でプロジェクトを立ち上げる場合がある。
プロジェクトの遂行時には、これらの問題の解決が遅れたり、不十分であったりすることがある。その結果、例えば、要件定義が確定しなかったり、設計品質が低下したり、進捗が遅れたりするなどのプロジェクト全体に波及する問題になることがある。
プロジェクトマネージャは、プロジェクトの立上げ時に抱えていた問題から波及するおそれがあるプロジェクト全体の問題を事前に想定し、その兆候を早期に発見することが必要である。そのためには、プロジェクトの立上げ時に抱えていた問題に応じて、例えば、次のような項目の傾向を分析することが重要である。
・要件に対する質問への回答の遅れ日数
・要件定義の変更回数
・設計レビューの指摘件数
・兼任している要員の作業負荷
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
設問ア
あなたが携わったプロジェクトの概要と、プロジェクトの立上げ時に抱えていた問題について、800字以内で述べよ。
設問イ
設問アで述べた問題が解決できない状況において、プロジェクト全体に波及するどのような問題が発生すると想定したかを述べよ。また、どのようにしてその発生の兆候を早期に発見したか、分析した項目とともに、具体的に述べよ。
設問ウ
設問イで述べた活動をどのように評価しているか。また、今後どのような改善を考えているか。それぞれ簡潔に述べよ。
<平成14年 問２>
１．プロジェクト概要及び業務仕様の変更可能性
１−１．プロジェクト概要
関東中心に約２００店舗を有するＡ金融機関（以下Ａ行と呼ぶ）は、個人住宅ローンを主力商品の一つとしている。Ａ行では、業務の効率化、顧客サービス向上を目的とし、老朽化した住宅情報システムを再構築することになった。情報処理サービス会社Ｂ社の汎用機とＡ行の各店鋪にある端末を公衆回線で接続する方式から、インターネットを利用したＷｅｂベースへと刷新するものである。Ｂ社に勤務する私は、プロジェクトマネージャとして全体を統括し、指揮する立場であった。
再構築に伴い、業務仕様が大幅に変更されることとなった。その理由は、ローン承認までの時間が長いとの苦情に対してＡ行が審査方法を見直し、中枢機能である審査チェックを改変する必要が生じたためである。
１−２．業務仕様の変更可能性
審査チェック機能は、業務仕様上４つのグループに分かれており、顧客情報、日付情報、資金情報、物件情報の各グループで構成される。私はこのうち資金情報については、開発途中での仕様変更がかなり多くなると予測した。その理由は、約２５０種類のチェックのうち、半数近くを資金情報が占めているうえ、現行システム開発時にも度々変更した経緯があったからである。
また、画面や帳票をＷｅｂ用に作り変える必要がある点について、Ａ行責任者（以下Ｙ氏）に確認したところ、デザインや操作性を重視したいとの意向であった。こうした要求は、システム利用者個人の好みや操作習熟度に左右されるため、仕様として固まりにくいと考えられる。このことから、画面や帳票のレイアウトについても全体的に変更が多くなると予測できた。
以上のことから、当プロジェクトは変更の発生を前提として取り組まなければならないと私は認識した。
２．業務仕様の変更についての検討及び対応（設問イ）
２−１．業務仕様の変更に対する検討
プロジェクト立上げに際して、私は以下に述べる内容について検討した。
（１）ユーザへのプロジェクト参画の要請
今回のプロジェクトでは、仕様の凍結時期を決めることが難しく、私は開発作業を進めながら仕様を確定していく構想を描いていた。つまり、開発の途中であってもユーザの要求を聞き取りやすくするため、ユーザを巻き込んで開発を進めることが容易な体制を作っておく必要がある。このため、Ｙ氏に対し、仕様変更に関する私の構想を伝えたうえで、プロジェクトへの積極的な参画と協力を要請した。その結果、Ｙ氏から承認が得られ、共同体制による開発がスタートした。
（２）仕様変更ルールの策定
А行の参画を前提として、仕様変更を行う際の手続きなど、ルールを決める必要がある。予想以上に変更が多くなることも想定し、混乱を回避するためである。そこで私は、Ｙ氏との協力により、いつ、どの機能にどの程度の変更が発生するか可能な限り予測して、仕様変更ルールを策定した。具体的には、週１回の仕様連絡会で、Ａ行から新たな仕様変更依頼書の提示を、開発側Ｂ社から前週の案件に対する変更方針の回答を行うルールとした。また、管理・運営のための作業フローや手順書を準備し、関係メンバー全員に配布した。
（３）変更の採否判定基準及び判定方法
ユーザからの要求を無条件で受け入れるのではなく、変更を実施するか否かの判断が必要になる。そこで私は、業務上の重要度、緊急度、変更しない場合の影響、変更作業工数など、幾つかの判定基準に基づいて評価するためのチェックシートを用いて、Ｙ氏をはじめ各関係者と協議しながら進める方針とした。採否の決定は前述の仕様連絡会で行い、必要に応じて専門的な知識や技術を有するメンバーも参加させ、多角的な視点から判定することにした。
２−２．業務仕様の変更要求への実際の対応
設計工程にはいると、当初予測したとおり、仕様変更が頻繁に発生した。その対応について以下に述べる。
（１）仕様変更ルールの見直し及び改善
当初は週１回、２時間の予定で連絡会の開催を計画していたが、時間内に報告しきれないため、設計工程に限り週２回に変更した。また、仕様変更依頼書については、会議の当日でなく依頼発生の都度、Ｙ氏から私に受け渡すルールに変更した。事前にどのような変更があるのか質・量を把握し、タイムリーに影響調査を行うためである。さらに、事前に把握することで、会議では報告の時間を最小限に抑え、双方が意見を調整する時間を長く取れるように工夫した。こうした見直しと改善により、遅滞なく変更要求に対応することができた。
（２）変更案件の優先順位づけ
限られた期間や費用ですべての変更案件を実施することは不可能であった。また、前述のチェックシートでは評価しにくい例外的な案件もあった。そこでＹ氏と検討した結果、変更案件に優先順位をつけ、優先度の高いものに絞って実施することで合意した。例えば、審査チェックのうちで顧客情報と資金情報の連携機能など、業務上重要な案件については変更を実施し、業務への影響が小さい案件は、変更の延期または中止とすることを決めた。
（３）変更案件の滞留防止
私は、案件管理簿により変更要求の実施、一部実施、保留、延期、中止という状態を管理していた。しかし徐々に「保留」や「延期」が増えてきたことを危惧した。一般に開発の後工程になるほど、変更による作業負荷が高くなるからである。このため、保留または延期の場合は必ず決定期限を決め、変更案件の滞留を防止するよう関係者に周知のうえ厳密に管理した。
３．評価・改善点（設問ウ）
３−１．実施活動の評価
開発中の変更要求は１００件を超えたが、プロジェクトは予定していた期間内で完了した。プロジェクトの初期段階からユーザの参加を働きかけたことで、業務仕様の変更に柔軟に対応できたと考える。ユーザとの調整に苦慮する場面もあったが、後日Ｙ氏から「共同体制が成功の要因」との評価を得た。また、当初の予測通り、審査チェック・資金情報への変更は全体の６０％と多かったが、仕様変更ルールを確立し、判定基準による客観的な判断を行ったことで、プロジェクトを適切に運営できたと思う。以上のことから、私の実施した活動は効果的であったと評価する。
３−２．今後の改善点
開発中の仕様変更については、変更による修正範囲の調査をできるだけ詳細に行う必要があると考える。なぜなら、調査の結果、実現が難しい、現機能への影響が大きい、テスト工数が膨張するなど、様々な問題が判明する可能性があるからである。そういった調査の掘り下げや、変更によるリスク分析がやや甘かったと認識している。この点は、今回使った判定基準のチェックシートにリスク項目を追加するなどの改善を加え、今後のプロジェクトで有効に活用していきたい。
<修正ポイント・考察など> 設問アの前半はプロジェクト概要を素直に書けばいいが、そうは言っても、出題テーマを意識した文言を少しでも含めておくと、あとが書きやすくなるようだ。そして設問アの後半であるが、ここは重要な部分である。
下書きでは、設問イのはじめのほうで「利用者の好みや習熟度による」という言葉を使っていた。しかしこれは、仕様変更がたびたび発生する源となるキーワードになるので、設問アではっきりと書いておくべきと考えた。
さらに、単にユーザ担当者でなくＹ氏という人物を登場させることによって、論文全体にリアリティーというか生々しさを感じさせるように修正してみた。人物描写が多すぎるとよくないが、協力してプロジェクトを運営したというニュアンスを表現するには効果的である。
全体的には、読み手になるほどと思わせる内容にまとめたつもりだが、何となくまだ物足りないと感じている。もっと深く追求していこう。もっと様々な視点から書いてみよう。
<スキル基準> 論文作成において参考になった以下の基準について、復習しておこう。
変更管理 4-1 変更要求の把握 4-2 変更内容の分析と評価 4-3 変更の承認 4-4 変更の実施
| ホーム | 次のページ
