プロジェクト管理の基本は、プロジェクトスタート時にきちんとしたプロジェクト 計画を立てることである。計画を立てる作業により、プロジェクトの成功イメージ と落とし穴(失敗リスク)を感じることができる。 プロジェクトの目的を明確にし して、メンバー全員が同じゴールを目指して作業を開始できるようにしよう。
プロジェクト失敗に慣れっこになってはいけない
現在、日本中で数限りない開発プロジェクトが実行されている。 しかし、 そのうち当初の計画どおりに成果を収める成功プロジェクトは、いったいど のくらいあるのだろう? 完成時期が遅れたり、当初の予算をオーバーする ということは日常茶飯事だ。 なんとか本番稼動にこぎつけても、思ったよう なメリットをユーザーに提供できないシステムも多い。また、バグやシステ ム的な障害が残ったまま、「だましだまし」運用しているケースや、なかな か公表されないが、プロジェクト自体が頓挫して、途中で自然消滅している ケースも少なからずある。
「決められた期間と予算内に、狙いどおりの効果をもたらす品質のよいシステムを構築する」ということは、「プロジェクト」という“生き物”を相 手にするので難しい側面があるのは確かだ。業界内にも、納期遅延や予算 オーバー、障害の発生などが、 「仕方のないこと」として暗黙的に認められ るような甘い風潮がある。 「もともとスケジュールがタイトだったから」「競 合があったため無理な予算で受注したから」 「優秀な要員を確保できなかっ たから」「新技術に慣れていなかったから」などなどプロジェクト失敗の原 因はいくらでもある。しかし、プロジェクトというものが難しくて失敗が多 いだけに、しっかりと体系立てて管理するというアプローチが必須だ。きち んとしたプロジェクト管理をやっていないのに、そういうことを失敗の原因 とするのは、単なる 「言い訳」 だと言われても仕方がない。
プロジェクトの目的
プロジェクトの大きな特徴は、「目的」 を持っていることだ。 つまり、 プ ロジェクト管理の第一歩は、プロジェクトの目的を明確にするということだ。 「な~んだ。 そんなこと当たり前だ」 と思うかもしれないが、メンバー全員 でプロジェクトの目的を共有するという当たり前のことがなされていない ケースは思いのほか多い。 プロジェクトに参加するメンバーの役割はそれぞ れ異なるが、プロジェクト全体の目標がはっきりしてさえいれば、各メン バーは自分の立場でゴールに向かって仕事をしてくれる。
プロジェクトの目的は、どうしても漠然とした内容になりがちだが、可能 な限り具体的な数値目標にして結果と対比できるようにする。 例えば「電子調達システム」を構築する場合、 「調達コストの削減」 「調達作業の合理化」 「調達データの全社一元管理」「電子認証の導入による管理徹底」「取引先と の関係強化」などさまざまな目的がある。 これを、 調達コストの削減」 な ら年間調達コストをいくらからいくらに削減するか、「調達作業の合理化」 なら紙ベースの調達作業の何割を電子調達に置き換えて、何時間分の時間を 削減できるか、というような数値目標にするのだ。
プロジェクトの目的の立て方は、状況に応じてフレキシブルだ。 例えば 「営業支援システム」では、 どのくらい営業効率がアップするかという目標 をうまく立てられればよいのだが、なかなか測定が難しいことも多いだろう。 そんな場合は、対象ユーザーが何名で、 そのうち何パーセント以上のユー ザーがどのくらいの頻度で利用するかという利用度合いを数値目標にするの も1つの方法だ。ユーザーが毎日利用するということは、それだけ営業に とって役に立つシステムであることの証明だし、ユーザーが使ってくれては じめてそのシステムは価値があるということになる。
- イメージを明確に持とう
プロジェクトリーダーの資質とは何だろう? 「あの人がリーダーだから大 丈夫のはずだ」と言われる人もいれば、 「あの人がリーダーじゃ、先が思い やられる」と不安がられる人もいる。 プロジェクトを成功に導くことのでき るリーダーは、「判断力」 「決断力」 「統率力」 「折衝力」 「技術力」 「粘り強さ」 ･･････などの能力に長けている場合が多く、これは簡単に真似をできるもので はないだろう。しかし、 「プロジェクト管理手法」を確立して実践するとい うアプローチは、そのような資質が“並”の人でもプロジェクトを成功に導くためのものだ。
プロジェクトを成功させるためには、 「経験がモノを言う」とよく言われ る。確かに、経験豊富なプロジェクトリーダーは、的確なイメージを持って プロジェクトを遂行できる。 プロジェクトが完成するまでのステップや何を なすべきかを的確にイメージでき、 同時に、プロジェクトの各段階における リスクの存在とそれを回避するための策についてもあらかじめきちんとイ メージできている。 また、プロジェクトの目的を明確化するということは、 完成後の成功イメージを明確に描くということでもある。
- プロジェクト管理の3要素
ITプロジェクト管理の3要素は、「スケジュール管理」「コスト管理」「 質管理」だろう。 個々には、要員管理や外注管理、 変更管理、バージョン 管理、ドキュメント管理、 セキュリティ管理、 リスク管理などさまざまな 管理要素がある。PMBOKでは8つの管理要素に分類しているが、3要素を きちんと管理するためには、周辺の管理要素も徹底する必要があるということだ 。
プロジェクト管理の3要素と周辺要素
「プロジェクト管理」の管理
一般にプロジェクト管理をどこまで厳密にやるかは、対象プロジェクトの 規模や性質によって異なる。 小さなプロジェクトに対してまで、厳密なプロ ジェクト管理を要求するのは無駄が大きい。 逆に大規模プロジェクトはプロ ジェクト管理を徹底しないと失敗する。 また、新規開発か既存改修か、上流 工程からか下流工程だけか、請けか二次請けか、などによっても管理のレ ベルが変わる。 そこで、プロジェクトのスタートにあたって、 どこまで管理 するかをPMとPLの間で取り決め、 それを 「プロジェクト管理票」に記すこ とにしている。 プロジェクト管理票には、このプロジェクトで作成すべき管 理ドキュメントがリスト化され、それらのドキュメントが作成された時点で 作成日に日付が入る。 PMは、 このプロジェクト管理票を使ってPLがプロ ジェクト管理をきちんと行なっているかを管理・ フォローするのである。
なお、プロジェクト管理票のドキュメントにはユーザー共有という欄があ る。 これは、そのドキュメントをユーザーに見せるかどうかの方針を示すも のだ。 できるだけユーザーと情報共有した方が良いのは分かりきっているこ とだが、ビジネスの関係上それが難しいケースもある。 そのあたりの微妙な 加減をPLとPMと協議して方針を決定しておくのだ。
2つのプロセスモデル
プロジェクトの進め方、すなわちプロセスモデルには、大きく分けて 「ウォーターフォールモデル」 と 「スパイラルモデル」 の2つがある。規模の 大きなシステム開発にはウォーターフォールモデルが適していると言われて いるが、最近ではウォーターフォールモデルを採用した場合でもプロトタイ ブを作成しながら進めるような混合型の開発が多くなってきている。
- ウォーターフォールモデル
ウォーターフォールモデルとは、プロジェクトをフェーズに区切り、段階 的に開発を進めるというものだ。プロジェクト全体を図2のように基本設計、 詳細設計、プログラム設計、プログラミング&単体テスト、結合テスト、総 合テストというような工程に分け、上流工程から順番に完成させていく方法 だ。このモデルの特徴は、水が高いところから落ちるように、プロセスが進 んでから前のプロセスに後戻りすることがないという考え方で、ウォーターフォールモデルと言われている由縁だ。 ウォーターフォールモデルは、プロジェクト全体のスケジュールが立てや すく、ユーザー側と開発側との役割 責任分担が明確であるという利点から、現在最も一般的に行なわれている手法である。 しかし、基本設計や詳細設 計など各工程でユーザーが100パーセント理解し、 それをドキュメントとい う形で作り上げるという、 あまり現実的でないことを前提としているので、 実際のプロジェクトでは、プログラミング段階に入ってから設計に戻ったり、 結合テストを開始したのにプログラミングに戻ったりすることがよくある。 仕様確定後は長期間ユーザーが介在しないので、 最終テスト段階に入ってか ら「こんなシステムを求めていたのではなかった」 という恐怖の言葉をユー ザーから浴びせられるリスクが高いのだ。
- スパイラルモデル
そこで最近では、プロトタイプを作成してユーザーとの確認作業を円滑に 行なうというプロトタイピングモデルをベースにしたスパイラルモデルもよ く使われる。特にWebを利用した開発ではプロトタイプを作りやすいのでこのモデルが多く採用されている。各ラウンド内の作業ステップはウォー ターフォールモデルと同じ流れだが、100パーセント完成してから次のス テップに進むのではなく、ある程度の完成度で次のステップに進む。 何ラウ ンドまでスパイラルするかはプロジェクトにより異なるが、スパイラルを り返すことによってプロトタイプの完成度を高め、最終的に開発を完了させ る。
成功するためのイメージ
優秀なプロジェクトリーダーは、プロジェクトのスタートにあたり、成功 のためのイメージを持つ。 プロジェクトを成功させるのに必要なことは、プ ロジェクトごとに異なるが、この章のページの「FAQ里恵コーナー」に出 てくるようなことが一例として挙げられる。 どんな場合でも、 その状況に合 わせた的確なイメージを持つことができるのが、優秀なプロジェクトリー ダーに共通する資質なのだろう。
テンプレートを持つ
プロジェクト計画を立てる上で大切なことは、 「早く書ぐ関する知識を9つ 「あれが決まっていない、これが詰まっていない」 などというLing)」に関 書の作成が後回しになってしまうケースをよく見かける。しかし、ツール け早くメンバー全員に目指すゴールを認識してもらうためには、プロジェ。 トスタート時に書けるところだけでも書いて、後は追加・修正するという姿 勢が大切なのだ。
プロジェクト計画に盛り込む内容は、会社やプロジェクトごとに異なるか もしれない。しかし、いちいち白紙から計画書を作成するのは大変だし、 れが生じる恐れがあるので、プロジェクト計画書のテンプレートを用意し、 それをベースに作成することにしよう。 表2は、プロジェクト全体を把握す るためのプロジェクト計画書のテンプレートだ。 PYRAMIDでは、 PMBOK の立ち上げプロセスのアウトプット「プロジェクト憲章」と「プロジェクト スコープ記述書暫定版」 を 「プロジェクト計画書」にまとめている。 開発体 制やスケジュール管理、品質管理、 コスト管理など、ほかの要素のテンプ レートもこの後の章で順次紹介する。
PMBOKをベースにしたプロジェクト計画
PMBOKでは、第3章の表のように、プロジェクト管理に関する知識を9つ のエリアに分類している。この中から各エリアの「計画 (Planning)」に関 するプロセスを抽出し、各プロセスの3つのブレイクダウン「入力」「ツール と実践技法」 「出力」の「出力」に関する項目を取り出したものが表3になる。 出力欄には、ドキュメントと作業行為が混在して記述されているが、 PMBOKをベースにしてプロジェクト計画書を作成する場合は、この中から 有効と思われる項目を自社に合った形式で具体化することになる。
具体化の取り組み方は各社各様だと思うが、最初から完全を目指さないと いうことが肝心である。 PMBOKに書かれているからと言って、それをすべ て取り入れたのではプロジェクトメンバーがついてきてくれないだろう。 ま ずは、絶対に必要と思われる項目のみを対象にして自社のスタッフが運用で きる程度に留めておこう。 そして使いながら不備、不足をブラッシュアップ して少しずつ改良していくというのが望ましいアプローチだと思う。
まとめ
成功のために
さて、本章で述べた鉄則をもう一度確認しよう。 大切なことは何よりも実異である。 現在、走っているプロジェクトの中できちんとプロジェクト管理 がされていないものがあれば、すぐに実践していただきたい。
- プロジェクト管理手法を確立して実践する
- プロジェクトの目的を明確化し、メンバーで共有する
- プロジェクトの成功と失敗のイメージを頭の中に持つ
- 複数の目的を目指す場合は、 具体的、段階的に目標を設定
- 「スケジュール」 「コスト」「品質」 の3要素をきっちり管理
- 果敢にスパイラルモデルにチャレンジする
- 「プロジェクト計画書」 は、 すぐに作成する
- 「プロジェクト計画書」のテンプレートを持つ
詳しくは NALまでお問い合わせ ください。