- IPA過去問リンク：平成20年度秋 -

  1. プロジェクトの概要

1.1 プロジェクトの概要

　これから、私が経験したプロジェクトについて述べる。そのプロジェクトは、Ａ市住民の予防接種記録を管理するシステムだ。

　Ａ市は人口約５万人程度の地方自治体である。

　我々は、関東の本社を置く従業員600人程度の会社である。主に地方自治体業務に特化したシステムの販売をしている。今回、ハードウェアのリースアップに伴うシステムの再構築プロジェクトを受託した。

　プロジェクト期間は約１年、ピーク時の要因は１０名で、総開発工数が１００人月。このプロジェクトに、私はプロジェクトマネージャとして参画した。

1.2 合意を得られたシステムの利用部門の作業

　今回のシステム再構築の目的は、単にハードウェアのリースアップに伴うシステム更改だけでなく、業務改善も含まれている。したがってシステムのＡ市利用部門（以下利用部門）に依頼しなければならない作業が多い。

　利用部門に依頼する作業の中でも、特に重要なのが、今回新たに追加する機能の仕様確定作業である。我々は、利用部門がまとめた業務仕様に基づいて要件定義書を作成する。その為、利用部門のその作業が予定通りに進まないと、プロジェクト全体にも支障が出てくるというわけだ。

　そこで、プロジェクトを立ち上げる前に作成しておいたプロジェクト計画書（概要版）を利用部門に提示し、本当にこの期間で作業が完了するかどうかを、くどいくらい確認した。そのたびに、利用部門の今回のプロジェクト責任者は「大丈夫、２ヶ月あれば十分まとめることができる。」と自信たっぷりの目で言っていたので信じることにし、プロジェクトを立ち上げた。

  1. 情報システム開発プロジェクトに置ける利用部門の参加について

2.1 利用部門の作業が計画通りに実行されなかったことによって発生した問題

　プロジェクトが立ち上がり、要件定義工程には３ヶ月をとっていた。そのうち前半２ヶ月で、我々は現行システムの移行について検討し、利用部門は新たに追加する機能を確定させる。その後、１ヶ月間で両方の作業を擦り合わせて最終要件にし、要件定義書を完成させるという段取りだ。

　しかし問題はすぐに発生した。プロジェクトが立ち上がり１ヶ月経過した頃、全範囲に置ける昨日追加の可否を含めた確定部分（判断完了部分）が３０％そこそこしかなかったのだ。時間的には５０％消化しているので、判断完了部分も５０％になっていなければならない。

2.2 その原因

　前述する通り、今回の利用部門の作業は、全範囲に対する判断完了の可否で進捗状況を確認している。そのルールはこうだ。

　・利用部門→各チームリーダ（日次の進捗報告） 　・各チームリーダ→私（ＰＭ）（日次の進捗報告） 　・リーダ会議（ＰＭ＋各チームリーダ）２週間に１回

　したがって、以前から遅れ気味なのは把握していたが、２回目のリーダ会議で状況を確認したところ、そろそろ対応を考えていかないと全体スケジュールに影響がでる可能性があるとのことだった。

　チームリーダに遅れの原因を確認したところ、一部の担当者が、他の業務に手がとられていてなかなか時間が取れないということだった。

2.3 私が取った対応策

　今回のように利用部門に任せていた作業に問題が発生して、全体スケジュールに影響がでると思われるケースでは、プロジェクトマネージャの利用部門に対する働きかけが重要だと考えている。そこで私は、リームリーダから聞いている問題とその原因を、ひとまず自分自身で確認することとした。

　まず、当初の利用部門との合意状況を改めて議事録で確認した。すると「専任は必要ないが、作業に進捗遅れが出ないように常に注意を払いながら、必要に応じて専念する」という記述がある。これが利用部門にあまり浸透していなかったようなので、改めて利用部門の責任者に個々の作業担当者に周知徹底してもらえるように頼んだ。それとともに、利用部門の責任者と対策案について話し合った。

　今回の原因は明確である。利用部門の一部の担当者が他の仕事に手を取られ、このプロジェクトに十分な時間を割けないことである。そこで私は、利用部門の責任者に次のような提案をした。

　・業務多忙な担当者に、具体的な時間を提示してその時間は、当該プロジェクトに専念するようにしてもらう。 　・利用部門側のPMに稼働確保できているかどうかの管理を強化してもらう。 　・業務多忙な担当者の代わりに、別の担当者をプロジェクトに加え、作業を分担する。 　・一部の仕事を弊社で受ける。

　業務多忙な担当者に依頼する作業は、大きく分けると２つある。業務改善の案を考えてそれを利用部門全員に意見を聞き固めていく作業と、その過程でドキュメントに残していく作業である。案外時間がかかるのは、後者の単純作業である。

　そこで、まずは業務多忙な担当者に、今後、このプロジェクトに具体的な時間を挙げてもらい、その稼働確保だけは絶対に守るように利用部門側のPMに管理強化を依頼した。

　しかし、絶対的に時間が足りない点は残ってしまう。そこで、追加の要因を投入して２人１組で作業するようにし、ドキュメント作成作業はその追加要因が実施することで、足りない作業時間を補うよう依頼した。ただ、予算の関係上、弊社側は参加できないので利用部門側で要因確保してもらうこととなった。

　最後に、この計画が納期や予算を守るために適切なものかどうかをチェックしなければならない。そこで私は、この１ヶ月の生産性と要員数の関係から計算してみた。幸いにも、進捗は計画値の３０％しか成果がでていないが、実質コストの消化率も３０％程度で、生産性そのものは計画通りである。やはり単に、要員の作業時間が足りなかっただけだ。そのため、この生産性で追加要員数と担当者の専任時間から計算し、最終予算と納期の予測値を計算し、問題がないことが確認できた。今後は、生産性と稼働時間を重点的にチェックしていけばいいと判断して、こうした対策をとった。

  1. 評価と改善点

3.1 私の評価

　その後１ヶ月で利用部門側の作業は予定の遅れを取り戻して完了した。要件定義フェーズもその後の１ヶ月で無事終了。全体の作業が見えたところで、再度計画の調整が入ったが、最終的には当初の予定していた納期・予算は確保できた。それもこれも、最初のところでつまずかなかったところが良かったのだと思う。

　最終的にプロジェクトそのものが成功したので、そのときの対策もよかったと考えているが、やはり、利用部門に発生している問題だからといって他人ごとにせず、私の持っている様々な対応策の中から、いろいろ組み合わせることができた点は評価が高い。中には、自分自身が経験したことではなく知識として学んだ対策案もある。そういう意味では、日ごろの学習が大いに役立ったと考えている。

3.2 今後の改善点

　ただ、手放しで喜んでもいられない。反省点は２つ。利用部門の人に依頼する作業とはいえ、最初から、生産性や週次での稼働時間を明確にしておき、それに基づいた管理をしておけば、もっと早く対処が出来ていただろうし、利用部門の担当者も時間をうまくやりくりしてくれていたと思う。それと、できれば専任を最初から約束してもらった方が良かった。プロジェクトを立ち上げる前に、そのあたりの話し合いにあまり時間をかけなかった点を反省しなければならない。