PMBOK特集

第一部
デスマーチとPMBOK
 ーなぜ、いまプロジェクト管理か

　今や日本においても、プロジェクトを管理する手法として一般的な認知を受けているのは、PMBOK（ピンボック）である。PMBOKはProject Management Body Of Knowledgeのそれぞれ頭文字をとった略称で、日本語での名称を「プロジェクトマネジメント知識体系」という。PMBOKを提唱しているのは米国のプロジェクトマネジメント協会（Project Management Institute, PMI）で、同協会は『PMBOKガイド　第3版』を発行するとともに、それに基づく認定資格であるPMP（プロジェクトマネジメント・プロフェッショナル）試験を実施している。この特集では、第一部においてソフトウェア開発で見られる「デスマーチ」プロジェクトの分析を通してPMBOKの必要性を検討し、第二部では開発業務に適用する観点からみたPMBOKの特長について解説する。

デスマーチとは

「デスマーチ（死の行進）」－この穏やかならぬ言葉が、ソフトウェア開発に携わる人々の間で使われることがしばしばある。プロジェクトはさまざまな要因が絡み合ってデスマーチに陥ることがある。そうなると、プロジェクトは、死の行進のように、終わりの見えないなか、ひたすら前進しなければならなくなる。メンバーの深夜残業、徹夜、週末出勤が続き、それでも納期を守れそうもない。クライアントや上司からは理不尽な（あるいは理不尽と思える）要求や脅しを受ける。やっとの思いで、なんとかプロジェクトを終わらせても、身体的・精神的に体を壊すメンバーや退職を決意する者など、いわば「傷病者」や「戦死者」を生むことさえある。

「デスマーチ（death march）」という語は、もともと、第二次世界大戦末、敗色が濃くなったナチス・ドイツが、強制収容所からの撤退時に、収容者を歩かせて別の場所に強制移動させたという事件を指して使われる言葉である。たとえば、1945年1月、ナチスはソ連のポーランド侵攻を受けて、アウシュヴィッツにいた六万人を行進させて、50キロ以上離れた収容所に移動させた。その途上で約一万五千人が死んだ。それ以外のナチの強制収容所でも同様のことが起きた。またナチスだけでなく、日本軍も、第二次世界大戦中にフィリピンのバターンで戦争捕虜に死の行進をさせた。

忌まわしいデスマーチであるが、この言葉をソフトウェア開発の悲惨なプロジェクトに使ったのはエドワード・ヨードン（Edward Yourdon）である。ヨードンは「コード／ヨードン法」というオブジェクト指向分析／設計法を開発した人物として有名である。現在では、オブジェクト指向の分析といえば、UML（統一モデル記述言語）が一般的に使われるが、「コード／ヨードン法」はそれ以前の主要な分析／設計法の一つであった。

ヨードンが「デスマーチ」というタイトルの書籍を執筆したのは1997年である。多くの反響があり、2004年には「デスマーチ第2版」を書いている。第2版の日本語訳は、（第1版と同じ）松原・山浦訳で2006年に日経BP社から出版されている。

その本の中で、ヨードンはデスマーチ・プロジェクトを次のように定義している。
デスマーチ・プロジェクトとは、『プロジェクトのパラメータ』が正常値を50%以上超過したもの（「デスマーチ第2版」、p.2）
『プロジェクトのパラメータ』には、スケジュール、人員、予算、機能などがある。スケジュールや人員や予算が予想される規模の半分であったり、逆に機能が予想の倍以上であったりするなら、プロジェクトはデスマーチに陥るというのである。確かに無理には限度があり、納得できる話である。

もちろん、50%以上超過していなくてもデスマーチになるプロジェクトもある。したがって、ヨードンは次のような定義もしている。
公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析も含む）をした場合、失敗する確率が50%を超えるもの（同書、p.4）
この「失敗するリスクが50%を超える」プロジェクトという定義の方が包括的である。開発プロジェクトを成功させるには、スケジュールや人員や予算などの開発資源が十分そろっていなければならないが、根本的には開発資源の不足がデスマーチ・プロジェクトの原因である。

デスマーチに至る要因と結末

では、何が要因となって開発資源の不足に至り、デスマーチが始まるのだろうか。いくつかの段階で要因となるものを検討してみよう。

プロジェクト計画：当初から、無理な予算とスケジュールでプロジェクトが始まる場合がある。受託でソフトウェア開発を行っている場合、要件が固まらないまま概算見積りが先行し、いったん出た概算見積り額が一人歩きを始めると、無理な予算でプロジェクトが始まるかもしれない。また、スケジュールが上層部の「天の声」で決まったり、関連する予定の影響を考えるとスケジュールの延期が難しかったりすると、無謀と思いながらもプロジェクトが進むことがある。

要件定義：デスマーチに至る大きな要因の一つは、要件定義の段階でクライアントの仕様があいまいであったり、クライアントが要件を明確に決めようとしなかったりするなど、要件定義の甘さにある。仕様のずれは、後の工程での仕様変更につながる。特に、テスト段階で発生する仕様変更は、プロジェクトに破壊的な影響を及ぼすことがある。

設計：設計段階で問題となるのは、クライアントと開発側の「常識のずれ」である。クライアントは、当然ながら開発側にプロとしての常識を期待して、つまり言わなくてもそれくらいプロなら分かるだろうという先入観をもって発言してくる。設計レビューにクライアントが参加しない場合は特に、あとで設計の見直しが生じることがあるが、これもデスマーチの誘因となる。

製造（実装）・単体テスト：残業が常態化している職場では、スケジュールの遅れを取り戻すべく、製造・単体テストの段階で無理なスケジュールをこなす「精神」や「文化」がしみついているかもしれない。しかし、この段階でしっかりしたレビューによってプログラムの品質を確保しないと、テスト工程での後戻りがしばしば発生し、デスマーチに至ることがある。

結合テスト・総合テスト：テストは、納期の迫るなか、遅延が許されない状況で、それでも品質をしっかり担保するという使命のもとにある。テストの品質を確保するには、テスト計画とテスト仕様書をしっかりレビューしなければならない。すでに述べたように、テスト段階でデスマーチに陥る原因には、ここに至って仕様変更や仕様追加があったり、製造工程でのプログラムの品質が低くてバグが終息しなかったり、テスト計画不足でたいへんなテストのやり直しが続いたりすることなどがある。テスト要員もプログラムの修正要員も、テスト段階での最後のデスマーチで心身ともぼろぼろになる。プロジェクトへの最後の一撃となるのが、テストである。

ほかにも、事故やけがなどによる必須メンバーの脱落、あるいは人員追加のためにかえって時間が取られたり、技術レベルが低下したりするなど、様々なことが引き金になって、開発資源の不足が生じることがある。

では、開発資源の不足はどのようにデスマーチによって補完されようとするのだろうか。ヨードンは「デスマーチ」の中で、興味深いネーミングをした、4つのスタイルがあると論じている。（図1）

図1にある「満足度」はソフトウェアの開発中にメンバーが感じる満足度や充足度、「成功する可能性」は、デスマーチ・プロジェクトが成功する可能性の高さである。
「スパイ大作戦型プロジェクト」とは、デスマーチの中でも成功する確率の高いプロジェクトである。同名のテレビ番組や映画の主人公のように、不可能と思えるミッション（使命）でも、「卓抜した技術と勤勉さ」（同書、p.56）により、チームが結束して立ち向かい、その使命をやり遂げようとする。犠牲者が出るかもしれないが、成功を信じて前進するようなプロジェクトである。

「モーレツ型プロジェクト」とは、軍隊式のスパルタ・プロジェクトである。ヨードンは、この型のプロジェクトの特徴として、次の3つをあげている。「(a)プロジェクト・マネージャーはプロジェクトを成功させるつもりである。(b)プロジェクト・マネージャーは会社の中で生き残るつもりで、プロジェクトを成功させて利益を得ようとしている。(c)プロジェクト・マネージャーは、プロジェクトの成功のためならメンバーの健康や幸せを犠牲にする（実際には、そうしたいと考えている）。」（同書、p.57）デスマーチになったとき、こういうタイプのPMのもとで働くと、心身とも衰弱してしまうのはよく理解できる。しかも、この伝統は軍隊と同じように受け継がれるものである。

「自滅型プロジェクト」は、最悪のプロジェクトである。だれもが失敗すると思いながらも、プロジェクトから抜け出すこともできずに、みなが破局に向かう。この型のプロジェクトには加わりたくないものである。

「カミカゼ型プロジェクト」も失敗する点では、「自滅型プロジェクト」と同じであるが、メンバーのモチベーションやモラールが違う。メンバーはプロジェクトが失敗したとしても、プロジェクトに参加できたことを誇りに思い、何かをつかむことができたと感じている。そういうプロジェクトも確かにあるかもしれない。

プロジェクト管理の重要性

ヨードンの示唆に富む書物を読みながらデスマーチ・プロジェクトを考察してみると、「計画」と「管理」、PMの「交渉力（政治力）」の重要性が浮かび上がってくる。

デスマーチを避ける鍵は、まずプロジェクトの計画時にある。もちろん、計画段階で破綻が見えているプロジェクトを別にして、プロジェクトは、デスマーチを回避できる体制とスケジュールで始める必要がある。たとえ完璧な体制やスケジュールを組めなくても、少なくともリスクを認識し、リスクの解消に向けて継続的に対処していく姿勢が重要である。

プロジェクトの計画時に、「仕様」、「スケジュール」、「コスト」、「品質」、「体制」、「コミュニケーション方法」、「リスク」、「外注」などを、管理項目として明確にし、これらの項目を分析しておくなら、状況の変化を追跡して適切なアクションを迅速に取れるようになる。まさに「始めが肝心」である。

また「計画倒れ」という言葉もあるように、計画がいかに立派でも、その後の実施状況が芳しくないなら、当然のことながら、デスマーチに至ってしまう。計画の実施状況や進捗を「管理」し、新たなリスクを見極め、現実的なスケジュールになるよう継続的に改善を加えていく必要がある。しかもPMは、メンバーのモラールを高めながら、プロジェクトを管理していかなければならない。

さらにPMには、管理能力だけでなく、デスマーチを回避する「政治的」スキルつまり「交渉力」が求められる。PMは、利害関係者との折衝を通して、現実的な納期や人員や予算を確保していかなければならないが、そうした交渉を有利に進めるには、プロジェクトに関する客観的なデータで理論武装することが必要不可欠である。そのためにも、プロジェクトの管理が重要になってくる。

確かに、デスマーチに陥ったプロジェクトを見ていると、プロジェクト管理があまりなされていなかったり、あるいはプロジェクト管理どころではなくなって、混乱のなかプロジェクトが進行したりしていることがある。それでも、デスマーチを回避するか、あるいはデスマーチの程度を軽減するには、しっかりとした「プロジェクト管理」が必要というのはいくら強調してもしすぎることのない点である。それゆえに、PMBOKなのである。

PMBOK導入の目的

しかし、PMBOKを使った、あるいは参考にしたプロジェクト管理を行ううえで、忘れてならないのはPMBOKを導入する目的である。PMBOKの導入目的は、PMBOKを使うこと自体にあるのではない。むしろその目的は、PBMOKを使うことによって、デスマーチを回避し、納期・コスト・品質・顧客満足のすべての面でプロジェクトを「成功」させることにある。その点を忘れないようにして、導入目的からそれないなら、PMBOKを柔軟に生かすことができるだろう。