日本人の器用さがプロジェクトを失敗させるプロジェクトはなぜ失敗するのか(7)

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。

» 2008年05月13日 00時00分 公開
[落合和雄@IT]

WBS作成がプロジェクトマネジメント高度化の第一歩

 WBS(Work Breakdown Structure)を明確にすることは、プロジェクトマネジメントを高度化する第一歩である。PMBOKでは、スケジュールの作成、予算の作成など重要な計画はすべてWBSをベースに作成する。また、多くのシステム開発やソフトウェア開発も、WBSの定義を行うことを前提としている。

 WBSとは、プロジェクトで実施する作業を細分化し、階層構造で示したものである。これがないと、本来であればシステム開発はできないはずだが、器用な日本人は詳細なWBSがなくても、何とかシステムを作り上げてしまう。しかし、これが実はプロジェクトマネジメント高度化の大きなネックとなっている。

ほかの業界では詳細なWBSの作成は当然

 ソフトウェア開発と建設では作業上の類似点が多いが、建築業界で詳細なWBSが作成されないということは考えられない。大きな理由の1つは外注作業が多いことである。建設業界は、多重の下請け構造の中で仕事が行われているため、各下請業者に対し、作業の指示をきちんと行わないといけない。そのためにはWBSの明確化が必要である。

 もう1つの大きな理由は、高額な資材を多く使う点である。資材の手配を間違えると大きな損失につながるので、詳細なWBSを作成し、そこで使用する資材を明確にすることが必須だ。

ソフトウェア開発に存在する甘え

 ところがソフトウェア開発は、外注を使うことが多いが、そのかなりの部分は気心が知れた外注先や、常駐している外注先への発注だったりするので、あいまいな指示でも何とか作業ができてしまう。また、高価な資材を使用するわけではないので、多少指示があいまいでも大きな損失は出にくい。そのため、仕様があいまいなままプロジェクトを開始してしまうことが多い。

 ユーザーも、ソフトウェア開発の場合には、後から多少仕様を変更したり、追加しても何とかなるだろうという甘えがあり、それが仕様の詳細な決定の先送りにつながっている。

WBSの詳細化が必要となってきた環境の変化

 ところが最近になって、WBSの詳細化が避けて通れない大きな環境変化が2つ発生してきている。1つは、オフショア開発の増加である。あいまいな仕様でも仕事をしてくれるのは世界中でも日本のSEぐらいである。中国やインドのSEは指示書や設計書に記載されていない作業は一切行わない。これが国際標準なのである。日本のSEのように「行間を読んで」ソフトウェアを作成してくれることはない。これが日本でオフショア開発がうまくいかない大きな要因になっている。この結果を見て、「オフショア開発は使えない」などと安易なことをいう人もいるが、コスト面、技術面を見た場合、オフショア開発は避けて通れない道であり、それに対応することが求められてくる。このときまず必要となるのがWBSの明確化だ。

 もう1つの環境変化は、進行基準の採用である。従来、多くの会社が検収基準を採用しており、顧客が検収した時点でソフトウェア開発の売り上げを計上していた。だが、2009年4月以降の会計年度では、原則としてプロジェクトの進行度合いに応じて売り上げを計上しなくてはいけなくなった。これを工事進行基準という。このため、収益総額、原価総額、決算日における工事進ちょく度の3つの要素について、信頼性をもって見積もることが求められる。こうなると、従来のようにあいまいなWBSで作業を行うことは不可能になる。

80時間ルール

 では、一体どこまでWBSを詳細化すればよいのだろうか。これに関して、米国のPMI(Project Management Institute)では、80時間ルールを推奨している。WBSの最下層では、その作業時間が80時間以内になるよう作業の分割を行うというルールである。

 なぜ80時間かというと、これ以内の作業であれば、人間は頭の中でコントロールができるだろうという考えに基づいている。逆にいうと、これ以上の作業は人間の頭の中だけで作業を行うのは無理があるということだ。WBSを作成する際、この基準を参考にしてブレークダウンを進める必要がある。

 ここで注意が必要なことは、大規模なプロジェクトでは、最初からすべての工程を80時間のレベルまでブレークダウンすることが不可能な場合もあるということだ。この場合、段階的詳細化の考え方を採用して、直近の工程についてはWBSを80時間のレベルまで詳細に作成しておくが、まだ先の工程については上位レベルでとどめて、1つのWBSをもっと粗いレベルで作成しておくことができる。

的確なWBSを作成するコツ

 詳細なWBSを作成するのは非常に難しい。特にこれまで経験がない作業で漏れがないWBSを作成することは、なかなかできることではない。これに対する一番の対策は、テンプレートを用意しておくことである。ソフトウェア開発は、個々のプロジェクトごとに独自性があり、それがWBS作成を難しくしているのであるが、そうはいってもかなりの部分で類似性があるはずである。WBSのテンプレートを使えるところは使う。それが効率よく的確なWBSを作成するコツである。従って、ソフトウェア開発をいくつかのパターンに分けること、さらにWBSのテンプレートをそのパターンごとにぜひ用意しておくことが望ましい。

 それでは、過去にあまり経験がなくテンプレートが使えないプロジェクトはどうしたらよいのだろうか。このようなプロジェクトで、経験のないプロジェクトマネージャが的確なWBSを作成することは無理である。この場合、社内のノウハウを集めてWBSを作成しなければならない。関連する各分野の専門家を集め、どのような作業が必要かを検討し、その結果に基づいてWBSを作成するような仕組みが必要である。

著者プロフィール

落合和雄

1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム(現新日鉄ソリューションズ)などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』(翔泳社)、『実践ナビゲーション経営』(同友館)、『情報処理教科書システム監査技術者』(翔泳社)などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。