【社内教育】プロジェクト管理入門：PMBOK と CMMを理解しよう(2/12)

PMBOKはあくまでも知識体系集でしかなく、これを勉強しただけでプロジェク管理力が強化されるわけではない。 PMBOKやCMMなどの役割を理解し、その上でプロジェクト管理力を養うために何が重要かを考えてみよう。

なぜ、失敗が繰り返されるのか

汎用機 オフコンから、クライアント/サーバー、 Webアプリケーション の時代へと移り変わるにつれ、システム開発の難しさが一段と増してきてい る。その要因の1つは、プログラム作成だけでなく、ネットワークやミドル ウェア、セキュリティ、バックアップ、ハードウェア、 開発言語といった異 なるベンダ製品を組み合わせてシステムを構築するための幅広い知識と経験 が必要とされるからだ。 そして、もう1つの要因は、 開発期間やシステムの 使いやすさ、デザイン性などのユーザー要求が従来とは比較にならないくら い厳しくなっていることだ。 期日通りに完成させるだけではなく、 そのシス テムがどれだけ活用されてユーザーにメリットをもたらすかがより重要視さ れてきているのだ。 アプリケーション開発に注力して、 プログラムステップ 数を人数で単純に割っていた時代に比べ、現在のプロジェクトでは、メン バーの役割分担や求められる技術が高度で複雑になっていると言える。

このようにシステム開発の難易度が大幅に高くなっているにもかかわら ず、現状は、従来と同じスタイルで開発プロジェクトを遂行しているケース が非常に目立つ。その結果、スケジュールのオーバーランや品質低下、予算 オーバーなどの失敗が増えているのだが、 その原因をメンバー個人の力量不 足だけに求めてしまうため、プロジェクトの失敗が繰り返されてしまう。今日の開発プロジェクトでは、 従来のようなメンバーの技量に依存する属人的 なやり方ではうまくいかず、体系的なプロジェクト管理手法も積極的に取り 入れなければならないのだ。

 

PMBOKって何だろう?

プロジェクト管理に関する国際標準として、 PMBOK (Project Management Body Of Knowledge) という規格がある。 これは、米国プロジェクトマネジメ ント協会 (PMI Project Management Institute) が1987年に発行したプロ ジェクト管理に関する知識体系 (Body of Knowledge) のガイドであり、 プロ ジェクト活動を管理するための基本的な考え方、手法をまとめたものだ。 PMBOKは1996年に改定された時点で世界的に広く認知され、 現在は PMBOK1996を一部改定したPMBOK2000を経て、2004年にPMBOKガイド第3 版 (日本語版は2005年2月発行) に改編されている。 IEEE1490-1998や米国標準 規格ANSI/PMI99-001-1999として認定されるほか、品質管理の国際標準規格で あるISO 10006にも影響を与えている。

日本ではこれまで一部の企業しかPMBOKを導入していなかったが、 PMBOK自体の認知度はかなり高くなっている。 多くの企業が開発プロジェ クト失敗の繰り返しを反省し、プロジェクト管理の重要性を再認識しはじめ ている。その際、 企業独自の手法ではなく国際標準になりつつあるPMBOK に目を向けようという気運が高まってきたのは、世界に遅れを取っている日 本のIT業界にとっては非常に良いことだと思う。

 

 

PMBOKの知識管理体系

PMBOKの知識管理体系を理解しておこう。 図1はPMBOK における知識管 理体系を立体的に表わしたものだ。 PMBOKは、プロジェクト管理体系に関 する知識を分類し、書類棚を並べたような引き出しに整理している。 この書 棚は図1のように、9段、横5段、奥行き3段の構造で、それぞれのボックス の中にプロジェクト管理に関する項目が入っている。

PMBOKでは、プロジェクト管理に関する知識 (Knowledge)を縦9つのエ リアに分類して整理している。 日本の製造業で従来から使われてきたQCD管 理(Q:「品質管理」、C: 「コスト管理」、 D : 「納期管理」) は3つだが、 PMBOKはこれに 「スコープ管理」 「組織・要員管理」 「コミュニケーション 管理」 「リスク管理」 「調達管理」 という5つの分類を加え、それらをトータ ルに管理する 「総合管理」 を含めた9つの知識エリアで構成されている。 例 えば 「スコープ管理」では、プロジェクトの請負範囲や成果物が何であるか をきちんと定義・計画する。 また、 「スケジュール管理」では、作業タスク の定義やスケジュールの作成、 進捗管理に関するノウハウが管理されている。

各エリアごとに、 「立ち上げ」 「計画」 「実行」 「監視・管理」「終結」 とい う5つのプロセスの流れが横軸である。 どのプロセスで何を作成管理すべ きかは、9つの知識エリアごとに定義されている。 例えばスコープ管理の場 合、計画プロセスでスコープの計画や定義を決定し、監視・管理プロセスで 成果物の検収やスコープの変更の管理を行なう。 また、スケジュール管理の 場合は、計画プロセスで作業の定義や所要時間の見積もり、スケジュールの作成を行ない、監視・管理プロセスでスケジュールの進捗管理を行なう。 知識エリアとプロセスの交わる引き出しには奥行きがあり、そこに入出力 がパートで定義されていて、 「入力 (インプット)」「ツールと実践技法」 「出 力 (アウトプット)」という3つのパートで表わされる。

パートの構成は具体的な例で説明しよう。図2は 「タイムマネジメント」 エリアの「所用時間の見積もり」プロセスにおけるパート別の内容を表わし たものだ。各パートは図1におけるキューブの1つ1つに相当し、その箱を引 き出しとして知識が整理されている。 箱の中身を見ると、「所用時間の見積 もり」プロセスでは「作業内容」 や 「リソース状況」をインプット(入力) として、「作業に必要な資源」 や 「作業内容 (更新) 」 「RBS (リソースプ レークダウンストラクチャ)」などをアウトプット (出力)としていること が分かる。

なお、これから9つの知識エリアを順に説明していくが、その中に (11) や (S2)などが出てくる。 これらは第1章の表2のレベルチェック表にある 「No.」と対応しているので、レベルチェック表で明らかになった問題点に対 応する説明は、特に注意して読んでほしい。

 

知識エリア [スケジュール管理]

総合管理 (Integration Management)

一番上の 「Integration Management」 は、 「Scope Management」 以下の8つのエリアを統合したもので、これを含 めて全部で9つの知識エリアに整理している。 本書では総合管理と訳してい あるが、直訳通り統合管理とも呼ばれている。

プロジェクトの立ち上げ時に行なうことは「プロジェクト憲章作成」だ。 プロジェクトには目的や目標があるので、 それをきちんとプロジェクト憲章 (プロジェクト計画) に盛り込む必要がある (11) プロジェクトのスタート にあたってきちんとした計画書を作成すること (12) は、 プロジェクト管理 の基本となる。 「プロジェクト計画書なんか作ったことがない」 プロジェク ト計画書のテンプレートが組織にない」 ということであれば、それは改善す べき状況にあると言える。

プロジェクト計画書を書かない理由

「プロジェクト計画」 をきちんと立てる ことは、聞けば誰もが重要と答える。 しか し、現実にはなかなかプロジェクト計画書 を書かないリーダーがたくさんいる。 理由 は大きく2パターンあるようだ。

1つ目は「何を書いたらいいのか分から ないので…」というタイプだ。 きちんと したリーダー教育がされていなかったり、 「プロジェクト計画書」のテンプレートが なかったりというケースに多いパターンだ。 もう1つは、 「まだ、 あれが決まってい 「ないので…」 などと言いながらずるずる と先延ばしにしているケースだ。書くこと によって何が決まっていないかが整理され るし、メンバー全員に目標や方針が伝わる のに･････と歯がゆくて仕方がない。プロジェクトリーダーに任命されたら、 不完全でもいいから「プロジェクト計画書」 を作成するという作業からスタートする習 慣を持とう。

スコープ管理 (Scope Management)

スコープ管理とは、プロジェクトにおける自社の役割やカバーする範囲を 決めることだ。 日本人はこの部分がちょっと苦手かもしれない。

まず大切なのは、プロジェクトの目的を達成するために必要な作業 (タス ク)を漏れなく洗い出すことだ (S1)。 多くのプロジェクトでは、このタス クの洗い出しが不十分なため、途中で追加作業が発生する。 システム環境の 構築やデータ移行などの作業がすっぽり予定から抜けていた、などというこ とのないように気をつけたい。

プロジェクトに必要なタスクはこれらの作業だけとは限らない。 ユーザー との役割分担をきちんと決めておく必要がある (S2)。 サーバー構築と RDBMSのインストールはこちらでやるけれども、ネットワーク構築はユー ザー側の責任範囲ということもあるだろう。 データ移行作業ならば、 既存シ ステムからの移行対象データはどれとどれにするか、 それ以外のデータはど うするか、既存マシンからデータを取り出すまでの処理はどちらが行なうか、 データ変換プログラムはどちら側が作成するかなどを細かく決めておく必要 がある。 システムテストの確認方法やユーザー教育の実施方法、 役割分担も よく揉めるところだ。

また、提出ドキュメントをきちんと決めていないと、これもトラブルのも とになる。 「基本設計書」 とか 「詳細設計書」 などと漠然と書いてある だけでは、ユーザーが欲しいドキュメントが含まれているかどうかがはっき りしない。 後々のメンテナンスのためにER図やUMLなどを要望するユー ザーもいれば、テスト仕様書の提示を求めるユーザーもいる。 マニュアル作 成にしても、 操作マニュアルだけでなく運用マニュアルやヘルプも要求され る場合もある。

スケジュール管理 (Time Management)

さすがにスケジュール表を作成していないプロジェクトは少ないと思う が、おおまかなスケジュール表が1回こっきり作成されてそのままとなって いるという、 だらしないプロジェクトを見かける。 スケジュール表を作成す る作業は、プロジェクト全体の作業予定を把握するのに有効なだけでなく、 作業タスクを洗い出すのにも役立つ。 プロジェクトがスタートしたらすぐに 作成してほしい (T1)。 スケジュール表は、作業タスクの漏れを防止するタ スクの一覧表でもあるからだ。

小規模なプロジェクトでは 「総合スケジュール表」 だけでも構わないが、 ある程度の規模では 「総合スケジュール表」 1枚と、それをブレークダウン した 「詳細スケジュール表」 をサブシステム単位で作成する。 肝心なのは、 スケジュール表とは別に 「進捗管理表」 を作成することだ (T3)。 これは機 能単位に担当者を明記して、 メンバーの作業予定と実績をフォローするため のもので、 個人単位の作業割り当てを機能単位に行なう必要がある。

スケジュール管理のプロセスは、 計画 (Planning) と監視・管理 (Controlling 。 スケジュール表や進捗管理表を作成する作業が「計画」 プロセスで、 進捗報告やフォロー作業が 「監視・管理」 プロセスとなる。 忙 しくなると進捗確認作業がおろそかになりがちなので、「毎週水曜日の朝」 と決めるなどして進捗ミーティングは定期的に開催するようにしたい。 忙し いことを理由にリーダーがこのミーティングを勝手に延期しているプロジェクトもよく見かけるが、リーダー自らがルールを守らないようでは計画遵守 のムードは高まらない (T4)。 進捗確認では、できるだけ「報告ベース」ではなく数値/現物で確認する ようにする (75)。「ちょっと遅れているけど大丈夫です」などという報告を 「じゃあ、がんばれ!」と励ますだけでは “管理” とは言えない。予定より何日分遅れているか?その原因は何か? 遅れを取り戻すために具体的にどうするのか?ということをきちんと確認するべきだ。

途中で発生した遅れをカバーするのは簡単ではない。ましてや精神論だけ では片付けられない。「作業分担を見直す」 「生産性を上げられるように作業 内容を見てあげる」「リスケジュールする」など、原因に応じた具体的な対 策が必要になる。

失敗の原因とオーバーの原因

プロジェクトの途中で仕様が膨れ上が り、スケジュールやコストが予定よりオー バーするケースはよくあることだ。 ブロ ジェクトリーダーに聞くと、客先の 「仕様 「変更」 が多かったという報告を受けるが、 実際はプロジェクトスタート時の範囲設定 が甘かっただけということがままある。営業担当の「見積もりが高かったから失 「注した」 と、 開発担当の 「ユーザーの仕様 変更が多かった」という決まり文句は聞い ていてあまり印象の良いものではない。 プ ロならば、そうならないように事前に手を 打つべきだと思うのだが……

コスト管理 (Cost Management)

通天閣の上から紙飛行機を飛ばしたらどこに着陸するだろうか。そんなこ とは誰にも分からない。 しかし、 毎日100機ずつ投げ続けたら、次第に「こ こんな風の日はあのあたり」 というように、 少しずつ勘が働いてくるだろう。紙飛行機の構造や、その日の風の 流れなどの情報をもとにスーパーコンピュータで計算するよりも、案外、 こ うした経験則のほうが当てになったりする。

システム開発のコスト見積もりも似たようなところがある。 FP (ファン クションポイント) 法 【注1】 や COCOMOII 【注2】などのように、 なんらかの指 針があるほうが正確だと思いがちだが、実際はそうとも限らない。 経験豊か なプロジェクトマネージャがKKD法 (勘と経験と度胸) で見積もったほう が、より信頼できるというケースも少なくない。

しかし、 KKD法に頼り切っていては進歩がないし、時に大ケガをすること になる。 ファンクションポイント法でも標準値法でも構わないので、機能に 応じた開発工数の標準値を「見積もり算出基準」として用意しよう。 用意したら、その基準値を使ってシステム開発工数を見積もる。 さらにプロ ジェクト終了時には、 実際にかかった開発工数との差異をフィードバックし て算出基準を修正する。 この作業を各プロジェクトで繰り返すことにより、 「見積もり算出基準」 の精度は少しずつ高まっていく。

しかし、それでも難しいのが見積もりというものだ。 見積もりの精度を高 めるために、複数の見積もり方法を併用して妥当性を確認してほしい。 KKD法をベースにする場合でも、 スケジュール表のタスクに工数を割り当 てる方法と機能別の工数を積み上げ計算する方法の2通りで見積もりを行な い、トータル工数に大きな違いがないことを確認する。 また、複数の人の意 見を聞いてみることも大切だろう。 人の意見を聞けば、 「確かにそうだなぁ ･･････」と納得することが多いのも事実だ(C3)。 コスト管理もスケジュール管理と同じく 「計画」 と 「監視・管理」 の2つのプロセスからなっている。 計画プロセスでは、コストを見積もってプロ ジェクト予算を作成する。 一方、監視・管理プロセスの基本作業は「トラッ 「キング」と「コントロール」だ。 現在いくらコストを使ったかをタイムリー に把握(トラッキング)し、対策を講じなければならない 。

プロジェクトマネージャだけが予算を把握して “やりくり” しているケー スも多く見受けられるが、できればプロジェクトメンバーにも予算と現状を リアルタイムに伝えるようにしたい 。 スタート時に立てたプロジェク ト予算は「予測」ではなく「目標」となる。これをメンバーにきちんと伝え れば、各人がコスト意識を持ってプロジェクトを遂行するのに役立つはずだ。

見積もり作業の投資対効果

見積もりの精度を上げるには、 「十分な 情報量」 と 「見積もり作業にかかる工数」 が必要になる。しかし、プロジェクトス タート前に内部テーブル数や画面上の項目 数などの十分な機能数を算出できることは ごくまれだ。 また、 Slerが行なうシステム 開発の見積もりは営業経費 (つまりタダ) となるのが普通なため、 先生すれば無駄骨 になってしまう。

そんな状況の中で、 Slerが武器として身 に付けなければならない見積もり法は、 「少ない情報量でも短時間でそこそこの精 度で見積もれる」というものだろう。 自社 独自の「見積もり算出基準」 を作成する場 合は、 あれもこれもと情報を入れなければ ならないものではなく、 大雑把であっても 大外れしない方法を複数用意したい。

品質管理　(Quality Management)

日本の製造業が世界に通用するようになったのは、徹底した品質管理が良 い製品を生み出したからに他ならない。 それを考えると、日本のITが世界に 立ち向かうための秘密兵器は案外、品質管理ではないかと思う。 製造業の品 質管理では、 「後工程に不良を流さない」ということが徹底されている。 後 工程になってから不良を取り除く作業のほうがはるかに大変だということ を、長年の経験で嫌というほどわかっているからだ。 我々IT業界も、痛い目 に合っている数は負けないはずだが、その教訓がなかなか生かされずに同じ ような失敗を繰り返している。 ここらで本気になって「後工程に不良(バグ) を流さない」 ということを真剣に考えてみたい。

品質管理で最初に考えなければならないのは「品質基準」だ。品質の良し 悪しは相対的なものなので、目標とする品質を「品質基準書」 にはっきりと 記述してからプロジェクトをスタートする (Q1)。 品質は数値目標の設定が 難しいことが多く、 基準書に何を書くか迷うかもしれない。 しかし、 「想定 しているデータ量ではどのくらいのパフォーマンスとなるか」といったパフォーマンスに関する目標などは書けるはずだ。 品質というと、プログラムのバグをイメージする方が多いと思うが、現実にはプログラムよりも設計のバグのほうがプロジェクトに大きな影響を及ぼ す。設計工程のバグを少なくするには、 設計書のレビューをきちんと行なう ことが基本だ (Q2)。 基本設計、詳細設計それぞれでレビューを真剣に行な えば、後工程になってからの手戻りや仕様変更をかなり抑制できるはずだ。

製造工程に入ったら、開発メンバーの1本目のプログラムソースを誰かが で“変な処理コード をきちんと正してあげることが肝心となる。 また、エ チェックしてあげよう (Q3)。 開発者の技量はまちまちなので、最初の段階 ンジニアには人それぞれのやり方がある。 「開発標準書」を用意してでき るだけ標準化するのはもちろんのことそこに書いていない共通的な処理を 拾い出して標準化を促進する作業も重要になる。

「単体テスト」 や 「結合テスト」]は、きちんとテスト仕様書を作 成し、それをベースに行なうようにしよう (C4、C5)。 テスト仕様書を書く 行為そのものが、開発時には気づかなかった矛盾を見つけるきっかけになる しまた、テストの際のチェック漏れを防ぐことにもつながる。システム導入後に行なう 「総合テスト」プログラムで正常な仕様書どおりの) 動作をすることを確認するテスト。

では、ユーザーの役割が明確 になっているかどうかがポイントとなる。 テストデータの準備、マスタの整 備、確認作業、ユーザー教育などの作業はユーザー側にもお願いしたい部分 があるため、遠慮せずに頼んでみよう (Q6)。 品質管理ではユーザー側の協 力も重要だ。ユーザーをコントロールすることも、プロジェクトマネージャ の役割の1つと言える。

 

各工程における品質管理のポイント

組織管理 (Human Resource Management)

uman Resource Managementを直訳すると「要員管理」 となるが、プロジェクト体制を意識して 「組織管理」 とも呼ばれている。 組織管理は、プロジェクト体制の構築と開発メンバーの確保、そしてメンバーの育成という3つが主な仕事になる。

プロジェクト計画の際には、プロジェクト体制図を作成する。 単にPM、 SE、PGなどと書くのではなく、協力会社のメンバーも含め、個人名も記載 して各人の役割分担を明確に記すことが重要だ (H1)。 プロジェクトスター ト時にまだ要員が十分確保できていない場合でも、 名前欄を匿名にしてそ こに誰かをアサインしなければならない状況を図示しておいたほうが良い。プロジェクトは、ユーザーと開発チームの共同作業であり、両者の良いコ ミュニケーションがあってはじめて成功する。 ユーザー側のプロジェクト体 制図も作成してもらうようにしたい。

システム構築プロジェクトは、スタートすると要員が集められ、終了する と解散する。このため、プロジェクトスタート時には、協力会社も含めて要 貝を確保するのに四苦八苦する。 ただ数だけを集めるのではなく、 “できる” メンバーを集めなければ意味がない。優秀なメンバー集めに成功したら、も うそれだけで成功の半分はゲットしたようなものだ。 そのためには、常日ご ろから周囲に気を配っておく必要がある。

優秀な開発メンバーはそのへんに転がっているわけではないので、日ごろ から育てる努力も必要だろう。 「下を育てれば、それだけ自分が楽になる」 という図式はどの業界でも同じなため、たいていの会社ではきちんと実践し ているようだ。 ただし、落とし穴がある。 それは、プロジェクトリーダーに 対する教育指導だ。 ある程度の経験を積んだスタッフが、 「そろそろプロ ジェクトを任せてもいいかな」 ということでプロジェクトリーダーに抜擢さ れるわけだが、その際に「リーダー教育」をきちんと行なうことが結構おろ そかにされている。

リーダー教育は日本社会の苦手マターの1つかもしれない。 開発メンバー としてのスキルとPMとして必要なスキルは異なるため、きちんとリーダー 教育を行なう制度を確立しよう

コミュニケーション管理 (Communication Management)

ユーザーとのコミュニケーションでは、「きちんと記録する」ことがポイ ントとなる。 打合せを行なったのにきちんと 「打合せ議事録」 を書いていな いプロジェクトがあるが、これではビジネスのプロとして甘いと言わざるを 得ない (M1) 打合せ議事録を作成する際のコツは、 「迅速に」 「ポイントを 「絞って」 書くことだ。 だらだらと書くのではなく、方針を決定する重要な部 分に的を絞って、 打合せ翌日には提出したい。 また、打合せ議事録は、単に 決まったことの備忘録というだけではなく、両者の宿題 (ペンディング事項 を書き留めて相互にフォローするためにも活用する。 そのため、担当者や期 も明記すべきだろう。以前は、電話と打合せだけがコミュニケーション手段だったが、最近は メールに 「質問票」を添付したり 「Q&A専用掲示板」でやり取りを行なう ことが多くなった。 ユーザーとのQ&Aなどの管理は、手段を決めて一元化 するようにしたい。プロジェクトの規模が大きくなると、 開発メンバー間のコミュニケーショ ンも非常に重要になる。 「RDBMSのスキーマ定義を変えた」 「開発標準に新 しい処理を追加した」 など他の開発メンバーに連絡しなければならないこと は、「開発掲示板を見る」 「連絡票を回す」 などのルールを決め、 効率的に伝 わるようにしたい。

リスク管理 (Risk Management)

リスク管理のプロセスも「計画」と「監視・管理」から構成される。計画 プロセスは、プロジェクト開始時に 「リスク一覧」 を洗い出し、その対策を 考えておくという「備えあれば憂いなし」 作戦だ。 「メンバーが新しい技術 に疎い」「ユーザー側の仕様決定プロセスが不明確」といったリスクは、「生 産性が低い」「仕様変更が多そう」 というような問題を生む。「リスクは分かっているけど、しかたがないものばかりだ」 などと言わず、 とにかく一度書き出してほしい (R1)。 解決につながる何かをきっとつかめ るはずだ。「監視・管理」 プロセスではトラッキングとコントロールが主体 となる。 発生した問題点は 「問題点一覧」に書き留め、ミーティングを通じ て対策を講じてフォローする。 人間は嫌なことは忘れたいという本能がある ので、問題点をそのまま放置しないように必ずリストに記載するようにしよ う。

システム開発プロジェクトでおろそかになりやすいのは、開発途中のド キュメントやプログラムのバックアップだ。 何かあってからでは遅すぎるた め、必ずプロジェクトで保全ルールを決め、その遵守をチェックしてほしい (R3)。 また、近年は顧客情報や機密情報の漏洩も社会問題となっているの で、こちらも対策をきちんと立てて実行するようにしたい。

調達管理 (Procurement Management)

調達管理は、 「外注管理」 とか 「協力会社管理」とも呼ばれるものだ。 こ こでおろそかにされがちなのは、最初にRFP (Request For Proposal : 提案 依頼書) や 「発注仕様書」でプロジェクトの要件や目的をきちんと伝えるという作業だ。また、 プロジェクトがはじまった後も、 状況や問題点な ども支障のない限り伝えるのが良いだろう。 人間はマシンではないので、気 持ち次第で仕事の出来不出来が変わる。 できるだけ全容をつかんでもらい、 プロジェクト成功に向けて一緒にがんばってもらえるよう努力したい。

と言いながらも、 人が悪そうなことを言うようだが、調達管理のポイント は 「協力するけど信じない」 ことだ。 たとえ信頼できる協力会社であっても、 「すべておまかせ」 では管理したことにはならない。 必要な情報をきちんと伝 える代わりに、プロジェクトの進捗をトラッキングできる根拠をタイムリー に提出してもらうビジネスライクな態度が、最終的には相互のためになる。 一括請負でお願いするならば、 協力会社側のプロジェクト管理体制をチェックすることも怠ってはいけない (P2)。 不安があれば、こちら側のプ

ロジェクト管理手法を使ってもらうようにお願いしても嫌とは言わないはずだ。 また、 「開発体制図」 や 「スキルシート」 をきちんと提出してもらうことも忘れてはならない。 実際に委託先に出向いて、 メンバー1人1人と会う手間を惜しまないことも大切だろう。

PMBOKだけじゃ意味がない

PMBOKは、あくまでも一般のプロジェクトを管理するのに必要な知識レ ベルを体系化した「ガイド」に過ぎず、それをシステム開発プロジェクト向 にして活用するのはあくまでも自分達なのだ。 たとえばプロジェクト の立ち上げプロセスのアウトプットは、 「プロジェクト」と「プロジェク トスコープ記述書暫定版」の作成となっている。 しかし、このような馴染み の薄い文書でなく、「プロジェクト計画書」というものに目的や概要、スコー ブを一緒に記してもよい。

大切なのは、 PMBOK を参考にしたうえで、自分たちなりのプロジェクト 管理手法を作成し、それを実践することである。 そこで作り出されるプロ ジェクト管理手法は、社内的には標準化されたものであることが望ましいの だが、 他社と横並びである必要性はまったくない。 プロジェクト管理手法は、 インターフェイスやハードウェアの標準化とは性格が違うので、優れたプロ ジェクト管理手法を独自に工夫して定着させることが企業の競争力をアップ させると考えてもよいのだ。 国際標準であるPMBOKを導入するということ は、その記述内容を忠実にトレースするという姿勢ではなく、PMBOKの中 から有効と思われるところを参考にし自社に合った管理手法として具体化 することだと私は考えている。

 

CMMも知っておこう

第1章でプロジェクト管理力を自己チェックし、 「おみそれ」 から 「ふはは 「は」などのランク付けをした。 実はもっとまじめで国際的な指標として CMM (Capability Maturity Model) がある。 CMMはプロジェクト管理力を 客観的な数値レベルで表わすもので、最近ではPMBOKと並んで注目されて いる。 PMBOKが個々のプロジェクトごとに管理の徹底を図るのに対し、 CMMは企業単位の開発プロセス改善を目指すものである。 その点では、 EPMと同じような位置付けとも言えるだろう。CMMを導入する目的は、「開発委託先選定のための評価基準」 と 「自社の 「プロセス改善」の2つである。 日本のe-Japan計画でも、一定金額以上の政府 調達の際にこのCMMを導入しようという検討が進められているとされた。 これでCMMが一躍脚光を浴びたのだが、 以来ずっと検討段階という状態が 続いており、掛け声倒れになるかもしれない。 CMMは、調達先選定のため にランク付けされるという負のイメージもあるが、これを契機にして企業単位で改善を推し進めようという前向きなマインドを持つほうが、結果的に ことになるのではないかと思う。Japan 構想が忘れ去られ ていく中でも、いろいろな企業がCMMのランク取得を行なっている。

位で改善を推し進めようという前向きなマインドを持つほうが、結果的に ことになるのではないかと思う。Japan 構想が忘れ去られ ていく中でも、いろいろな企業がCMMのランク取得を行なっている。位で改善を推し進めようという前向きなマインドを持つほうが、結果的に ことになるのではないかと思う。Japan 構想が忘れ去られ ていく中でも、いろいろな企業がCMMのランク取得を行なっている。CMMは、もともとは米国政府のソフトウェア調達などに利用されてきた ものだが、最近では国際的なソフトウェア開発の委託先選定などのため、 世 界各国で積極的に導入されてきている。 Maturityとは 「成熟」を意味する言 葉で、成熟度を表1のような5段階のレベルにモデル化し、科学的な尺度でIT 企業の開発力を表わすものだ。 つまり成熟度レベルは、IT企業にとっての ミシュランの5つ星” のようなものと言うことができる。

PDCAサイクルとPMBOKプロセス

PDCAサイクル

日本の製造業を中心に昔から定着している管理技術として 「PDCAサイク ル」 がある。 これは、図4のように 「Plan (計画)」 「Do (実行)」 「Check 評価)」「改善 (Action)」 という4つのプロセスを一連のサイクルとして、

定常的に(つまりスパイラルに)サイクルをまわる管理手法だ。 PMBOKの プロセスが 「立ち上げ」 から 「終結」まで直線的に進むのに対し、日本が得 意とするPDCAサイクルはループ状のプロセスになる。「PDCAは古い これからはPMBOKだ」 などと言う人もいる。この2つを 同列に比較するのもどうかと思うが、PDCAの 「Continual Improvement (絶え間ない改善)」 という努力により、 全体のレベルを向上させようという アプローチは正しいし、日本人の気質にマッチしているように思う。

                                                                                  PDCA管理サイクル

PMBOKは ｢一撃必殺」

PDCAの基本的な考え方は、継続的改善 (Continual Improvement) であ る。絶え間ない改善の努力を通して全体のレベルを向上させていこうという アプローチは、日本人の特性にマッチしていたため、 日本国内で広く普及し たモデルとなっている。 一方、 PMBOKの場合はサイクリックではなく、 “一撃必殺”である。先日 「ミッション・インポッシブルIII」 という映画を 観たが、あるミッションのためにプロジェクトが発足し、 ミッション終了に より解散するというプロフェッショナルな考え方がPMBOKの基本となる。

PMBOKにおける5つのプロセス群の流れを表わしたものである。 プロジェクトの 「立ち上げ (Initiating)」 → 「計画 (Planning)」 → 「実行 (Executing)」 → 「終結 (Closing)」というようにプロセスが縦に流れ、 そ れらと並列して 「監視・管理 (Controlling)」 プロセスが位置付けられてい る。「監視・管理」 プロセスは 「実行」 プロセスと特に密接な関係を持つが、 同時にほかのプロセスの管理も行なうものである。PDCAサイクルにおける 「改善」というプロセスは存 在しない。 その代わりに、 PDCAにはない 「管理」 というプロセスが独立し て重要な役割を担っているのが特徴である。 PDCAの継続的という考え方が、 ともすると「マンネリ」 に陥る恐れがあるのに対し、 PMBOKは体系的に「コントロール」という機能を強化して、目の前のプロジェクトを成功させ ようという性格が強くなっている。 PDCAが 「長期的展開」に重きを置く日 本型経営に受け入れられてきたのに対し、PMBOKは 「ミッション明確化」、 CMMは 「数値指標化」 という米国的な性格が強い管理手法であるとも言え るだろう。

                                                                                   PMBOKの5つのプロセス群   

プロジェクト管理を強化するアプローチ

プロジェクト管理を強化し、 CMMの 「評価5: 最適化段階」に相当する実 力を付けるためには、第1章で説明した7ステップのアプローチを繰り返し実 行する必要がある。

●STEP1･･･ 【問題点認識】現状のやり方で何ができていないかを認識する

●STEP2 ･･･【改善計画】問題を解決するために何をすべきかを整理する

●STEP3･･･ 【ツール作成】 その方針を実現するための具体的なツールを作る

●STEP4･･･ 【普及策決定】 それを社内に普及させるためのルールを決める

●STEP5 ･･･【リーダ育成】 それを実践できるプロジェクトリーダーを育成 する

●STEP6･･･ 【実行】 メンバーに徹底させ、ルールどおりに実行する

●STEP7･･･ 【評価・レビュー】 その結果を評価して改良する

PMBOKを学んだだけではまだスタート地点に立っただけだ。 その知識を 活用して自社のプロジェクト管理手法として具体化するという、 STEP2、 STEP3の作業がうまく機能しなければ意味がない。 ここで重要なのは、「ド 「キュメントベース」ということだ。 すなわち、 手法自体を明文化すること もさることながら、PMBOK プロセスの「出力」に相当する成果物を具体 的なテンプレートとして用意することである。 本書ではこのポイントを重 要視し、プロジェクト管理を実践するためのテンプレート作成を中心テーマとしている。ここ数年、ITの資格取得熱が高まっている。 IT資格を持っていたからと いって仕事ができる人とは限らないが、 資格取得に向けた努力と取得できた という結果はその人にとって有益だからだろう。 企業にとってのCMM認定 の取得は、個人にとっての資格取得と同じような意義となる。 政府などのソ フトウェアの調達に参加する際に有利になるという「ニンジン」 でもあるが、 自社のプロジェクト管理体制の強化に役立つという考えは、決して間違って いないはずである。

まとめ

以上、PMBOKとCMMについてご説明しました。この立体的な体系とそこに記されている基礎知識を理 解することは、プロジェクト管理を理解するうえで役立つはずであります。

プロジェクト管理を実践す るためには、“グラマー” だけでは不十分だということを心しておきましょう。

引き続き,プロジェクト管理入門に関する知識をまた共有していきます。

詳しくは、NALまでお問い合わせください。