「プロジェクトマネジメントシミュレーター」でプロマネ業務のツボをつかめ！

プロマネデビュー前に疑似体験できる

　開発プロジェクトを何年か経験すると、プロマネの役割を担うエンジニアもいる。開発プロジェクト経験はプロマネに必須とはいえ、マネジメント業務は開発業務とはかなり異なるものとなる。身近でプロマネ業務を見ていても、実際にやってみるとなかなか思うようにできないものだ。

　富士通ラーニングメディアでは集合研修とeラーニングで「プロジェクトマネジメント疑似体験ワークショップ」を提供している。対象者はシステム開発プロジェクトを7～8年ほど経験したエンジニア。プロマネが何をするかは知っているものの未経験で、これから本格的にプロマネ業務を担当する人を想定している。いわばプロマネデビュー前の疑似体験だ。なおこの講習はプロジェクトマネジメントの知識体系ガイドとなるPMBOK（Project Management Body of Knowledge）をベースに構成されている。

　今回市古編集長が体験したのはプロマネ業務のシミュレーション。目玉は、プロジェクトマネジメント疑似体験ワークショップなどで使用されるプロジェクトマネジメントシミュレータだ。指南役の同社ナレッジサービス事業本部 第一ラーニングサービス部 城尚志氏は「プロジェクトを成功に導いてくださいね」と笑顔で言う。

開発要員の性格まで設定されたリアルさ

　シミュレーションのおおまかな流れとしては、まず状況（設定）を把握し、次にプロジェクトメンバーに仕事をアサインし、加えて自分のプロマネ業務となるリーダータスクも一通り設定し、プロジェクトを仮想的に進めていく。リーダータスクの中にある「進捗チェック」を設定して「実行」ボタンを押すとシミュレーションが始まり、その日時まで時間が進む。途中で発生した問題に対処するようにアサインやタスク設定を繰り返し、最終的には開発が完了すればシミュレーションは終了する。終了時点で期限や費用が目標内に収まれば成功というわけだ。

　今度は詳しく見ていこう。シミュレーションはメンバーを5～10名の範囲で設定できるが、今回は8名とする。設定としてはシステム構造設計まで終了しており、体験者はプログラム構造設計から結合テストまでを請け負うことになっている。期間（約5ヶ月間）と費用（受注額）はあらかじめ定められている。

　開発するプログラムは見積もりステップ数のほか、上下関係も定められておりテストする順番に関係する。開発要員は経験、スキル、性格までも設定済みだ。こうした設定から適した要員に適した仕事をアサインして進めていく。なお、開発要員はSE（システムエンジニア）とPG（プログラマ）と分かれ、平日単価（時給）や生産性（月に開発できるステップ数）が設定されている。残業や休日出勤になれば時給が変わる。

　前準備として与えられた納期と予算、開発すべきプログラムを把握する。これはおかれた状況の理解となる。次から実際のシミュレーションが始まる。まずはメンバーに仕事をアサインする。最初に各要員を何月から何月までプロジェクトに参加するか登録する。これで大まかな工数と費用が算出される。

　次に各メンバーに作業を割り当てていく。どのプログラムを誰が開発するかを指示していく。例えば「安部さんはプログラムA11を開発する」など。メンバーごとにスキルや生産性が異なる。性格も多様だ。「明朗快活で闘志あり」や「休みがちで情緒不安定」など。この性格がどのように影響していくかはシミュレーションを体験してのお楽しみである。

進捗チェックでは「納期を守れそうにない」といった報告を受ける

　シミュレーションはメンバーのアサインだけではない。プロジェクト管理に必要なタスクも設定していく。例えばプロジェクト全体会議、利用者（クライアント）への報告、上司への報告などをカレンダーに設定する。リーダーがすべき仕事項目の多さに「意外と多いんですね……」と市古編集長は腰が引けている様子だ。会議や上司への報告は資格Zineにだってあるでしょうに、運営は大丈夫かと心配になる。

　例えば、進捗チェックの設定を見てみよう。各メンバーの進捗状況が報告される。プロジェクト計画の予定と実績を把握するのによさそうだ。

　市古編集長は城氏の指南を受けながらメンバーのアサインとリーダータスクを一通り設定し、いざ「実行」をクリック。

　すると、画面に進捗チェックで設定した日までに起きたことが表示される。最初なので「○○がプロジェクトに参加します」「これからも定期的に報告してください」などと事務連絡的なものが並ぶ。しかしよく見ると、のっけから気になるメッセージもある。

　メンバーからの報告で「我々は利用者から（プログラム名）に関するシステム構造設計の仕様を受け取っていません。すぐに仕様をもらわないと納期を守れそうにありません」と出た。リーダーはこれに対応してなくてはならない。対応は面倒かもしれないが、知らないまま過ごしていると後で致命的なことになりかねない。こうした指摘を素早く把握するためにも、メンバーとのコミュニケーションは密に行う必要がある。

請求金額の交渉に胃が痛くなりそう

　シミュレーションでは、他にも途中でいろんなイベントが発生する。例えば、仕様追加や機能縮小だ。仕様追加が発生すると、利用者と費用請求交渉をしなくてはならない。予想ステップ数や難易度が定められており、SEとPGの工数から費用を見積もり請求する。余裕を持って多めに請求すればいいように思うが、希望通りに通るとは限らない。利用者から「高すぎます」と拒否されることもあるのだ。再見積もりと再交渉が繰り返されると、時間はずるずると延びていく。交渉が折り合うような価格で請求する必要がある。

　ややトリッキーなのはメンバーからの進言だ。納期が近づいてくると「プログラムレビューなんて非効率です」とレビューを軽視する意見が出てきたりする。メンバーから多様な意見が出つつも、リーダーは的確な判断をしていかなくてはならない。

　城氏によると「リーダーがいつどのような事態を把握するかにより、プロジェクトの結果が変わってきます」とのこと。リーダーの采配でプロジェクトがいつ、どのくらいの費用ですむかが変わってくるというわけだ。

　集合研修では数人でチームを組み、アサインやタスク割り当てを合議しながら設定していく。受講者の中には慎重に進めようとする人がいれば、強引に進めようとする人もいる。集合研修でいろんな意見を聞くのも勉強になりそうだ。eラーニングだと当然ながら完全に自分一人で判断していく。

　アサインと進捗チェックを繰り返し、全ての開発が完成するとゴールとなる。すごろくなら「あがり」である。そのときに品質や予算、納期がどれだけ守られているかはリーダーの采配次第だ。

本番では高リスクで試せないマネジメント方法にトライできる

　シミュレーションが終了すると、全体を通じて様々な結果が数値で示される。例えば、8月20日が予定納期だったのに、最終的には9月5日になれば納期が守れなかったことになる。予算も同様に目標の範囲で納められたか表示される。残業や休日出勤が増えればコストはかさむ。

　メンバーのリーダーに対する評価も体制や残業といった観点で表示される。品質や納期、費用とはまた別の観点でプロジェクトを振り返ることになるだろう。他にも「利用者満足点」や「上司満足点」なども表示される。最終的にはスコアから総合ランキングが表示される。

　それぞれに好みのアプローチやポリシーがあるかもしれない。優先度もまちまちだろう。例えば「私は絶対に残業はさせない」「ぼくは利用者満足度を何よりも優先する」というのも考え方としてはありだろう。その結果としてどうなるか、シミュレーションで結果が出る。初心者だとまずはプロジェクトを目標通りに達成するのが精いっぱいかもしれないが、自分のポリシーがどういう展開を生むのか確認できる。

　城氏は「本番ではさすがに失敗できませんが、シミュレーションなら安心して失敗できます」と話す。例えばレビューを怠れば品質低下が生じ、結果的に工数が増えてしまうことがある。自分の決断がどのような結果となり自分に跳ね返ってくるのかが分かる。ここで積極的に失敗しておくのもいいだろう。

　「知識があったとしても、実際に経験してみるとQCDのバランスを取る難しさに戸惑います。ここで経験を積んで知識を実践スキルに変換してみてください」（城氏）

　昨今ではアジャイル開発も流行だ。そうした新しい潮流に対応しているかと市古編集長が質問すると、城氏は「プロジェクトマネジメントで計画するポイントは、開発プロセスにあまり依存しません。押さえておくべきポイントがあります」と話す。この講習ではプロマネがすべきことを把握するきっかけとできそうだ。

城 尚志（じょう たかし）

株式会社富士通ラーニングメディア
ナレッジサービス事業本部 第一ラーニングサービス部

2000年に株式会社富士通ラーニングメディアに入社し、Javaやオブジェクト指向設計などアプリケーション開発技術の教育を講師として担当。その後、富士通グループの開発現場に出向し、電子申請システムといったWebシステム構築プロジェクトやパッケージ開発プロジェクトを経験。現在は、富士通ラーニングメディアに復職し、現場で感じたプロジェクトマネジメントの重要性を伝えるため、プロジェクトマネージャの人材育成に携わっている。

［主な取得資格］Sun認定Webコンポーネントデベロッパ、PMP