（0002）WBS：プロジェクト管理に於ける最も有用なツールの一つ 重要度★★★★★

「WBS/課題管理さえ行えば大概のプロジェクトは成功するだろう」

結論としてWBSは、
・ プロジェクト管理に於いて強力なツールであり、逆に言えば内容に問題があるとプロジェクトの進捗に影響を与えかねない。そのため実効性がある形式で作成 し、完成までには有識者の目を通すこと。
・ 進捗・工数・担当 等が管理出来る拡張版として作成する。WBSの目的、意味合いは、役割により異なり、担当者にとっては、自分の分担タスクとスケジュールを知るTODOとなり、プロマネにとっては、プロジェクト実行フェーズで進捗、コスト、要員の状況を把握し さらに言えばプロジェクト全体の進捗状況を俯瞰して適宜必用な対応を打つために利用することが出来る。
・ プロジェクトの実態に合わせて作成すること。例えば、「分解の粒度」については、プロジェクト内の作業内容によってすら変え、「EVM/PART」作成をについては、求められるコスト管理レベルや作業の複雑さ、期間の逼迫といった前提によって作成要否を決めることで負荷を減らしていくことが望ましい。要は必用な資料は作成しなくちゃいけないけど凝りすぎも良くないということ。 

そもそも、WBSって何？
WBSの意味は次の通り。要はタスクを分解して構造化した表のことです。

※ e-wordsより抜粋：
　プロジェクト全体を細かい作業に分割した構成図。
※ @IT情報マネジメント用語辞典より抜粋：
　プロジェクトの成果物あるいは仕事を詳細区分して階層構造化した図表

ただ、現場ではWBS単体の利用する場面は滅多にありません（というか見たことが無い）。通常のプロジェクトであれば、分解したタスク（ワークパッケージ）表に、マイルストーン、開始/終了予定日、実績、コスト、担当と言った管理項目を加え定期的（大体週次）で管理します。本文では一般的なWBS（詳細化されたワークパッケージ）に必要な管理項目を追記したものも含めてWBSと記載しております。 

WBSの目的は？
主目的は単純で「プロジェクト成果物（作業）をMECEに洗い出すこと」。そこから更に何のために利用するかが、会社によって組織によって異なってきます。一般的には、次の項目を管理するためにWBSを拡張します。
　　・進捗管理…開始/終了日、実績、状態（済/未済 等）、進捗率（係数、% 等）　　　
　　・コスト管理…見込み工数、実績工数
　　・作業分担…担当者、責任者 等
　　・追加情報…作業の前後関係、マイルストーン 等
WBSを使って進捗管理するのであれば、開始・終了日を書けば十分管理できます。しかし、関係組織の多い大規模なプロジェクトだったり、プログラムマネージャーに複数プロジェクトの進捗を報告するのであれば開始/終了日だけでは説明が難しいため、全体としての進捗率や作業項目数 等の係数も計上出来るようにしたほうが良いかもしれません。また、WBSで分解した作業がコスト管理、作業分担に最適なレベルであれば項目として追加しても良いでしょう。また、前後関係が厳密で複雑なポイントがあれば前後関係をつけたり、マイルストーンも記載して目標感を認識合わせ出来るようにすれば良いと思います。

しかし、「WBSは複雑になるほど管理負荷が増え実効性を失っていく」ことを意識して作成する必要があります。もうすこし言えば、WBS自体は開発の進捗に寄与するものではなくあくまでコミュニケーションツールです。つまり、WBSはよりシンプルであるべきで管理項目は必要最低限にすることが、生産性向上につながるのです。

WBSを作成のポイント
有用なWBSを作成するには、実務経験、業務遂行力、論理的思考が必要です。つまり、プロジェクトでどんな成果物や作業が発生するかを洗い出し、（効率的に）遂行するにはどのように各成果物や作業を進めれば良いかをイメージしてストーリーを作り、それらをプロジェクトメンバーが理解しやすい形で整理整頓出来るということです。という前提を置きましたが、そんな万能な人間が常にWBSを作成するわけじゃありません。有識者のレビューを通して完成度を上げていくことが大事ってことです。それを踏まえたうえで、私が思うWBS作成のポイントは以下です。

１． わかりやすい切り口で分解
システム開発プロジェクトであれば「要件定義・設計・テスト・移行」といった王道のフレームワークが幾つもあります。WBSを作成する際には100%ルールを守ることは大前提としてプロジェクトメンバーが理解しやすく、且つ、管理しやすい切り口で整理することが大切です。
　　　 
２． 適切な作業まで詳細化
「進捗状況、分担、コストが明確になるから、詳細化して管理項目を増やすにに越したことはない」という考え方はNGです。詳細化するほど管理負荷が増え実効性を失うことを
忘れてはいけません。ただし、成果物、作業分担や進捗レベルによって詳細化レベルは変わってきます。作業担当者によってすら変えてもよいです。例えば、実績が多い作業、ルーチンワークであれば詳細化レベルは低くて良いでしょう。プロジェクトメンバの能力が高く経験豊かであっても然りです。一方で、新規性が高い、または、難易度が高い作業については作業の進め方の認識を合わせる意味でもある程度詳細化した方が望ましいでしょう。
あと、テストやドキュメント作成は詳細化が必要ですが、項目数が多くなりすぎることが多いのでWBS上ではある程度の粒度で詳細化は止めておいて、別途管理表を作ったほうがWBSがシンプルになるでしょう。

３． 拡張は必要十分な管理項目に絞る
　　　上記の通りなので割愛します。

以上、本日はWBSについてでした。なお、WBS関連で私が参考になったなと思う本も紹介いたします。

システム開発のためのWBSの作り方/初田 賢司

￥2,625

Amazon.co.jp

（0001）はじめに。実効性のあるプロジェクト管理を考えていきます。

「生産性が最も高い働き方はプロジェクト管理なんかせずに少人数（出来れば一人で）プロジェクトの全てを仕上げてしまうことだ」

私の働く会社の情報システム部門は、日本企業の中でもプロジェクト管理の取り組みが進んでいる部類に入っていると思う。PMBOKやプロジェクト管理の教科書に書いてある大概のことは実行している。
官僚主義のためかマニュアル通りに、ルール通りに実施することは得意な組織だ。しかし、プロジェクト管理が進んでいると言っても完全に機能しているというわけではない。
どちらかというと逆で 、実態としては形式化してしまっているプロセスも多いし、プロジェクト管理に力を入れすぎる故に、システム開発に過剰に費用と時間が掛かっているように見えるからである。

プロジェクト管理はシステム開発をしている現場からするとオーバーヘッドになって煩わしいことが多い。 
「バグ曲線から品質の妥当性を説明 」 「プロジェクトの進捗係数を報告」「リスクを計上して対策を検討」 等、開発に貢献しない作業が多いからだ。私の場合も例外ではなく、プロジェクト管理系業務が開発の妨げにならないよう開発作業にプロジェクト管理係数を収集、整理する仕組みを織り込むような工夫をしていてさえ、一日の大半を プロジェクト管理資料作成に費やす時期もある。

じゃあ、プロジェクト管理が必要がないのか？もちろんNoだ。冒頭で書いたようなプロジェクトを少人数で開発だけに集中して予定通り完遂できるようなスーパーマンが常に揃うわけじゃない。であれば、ある程度能力に差異のある大人数がプロジェクトに参加することになる。その際、PMBOKをはじめとしたプロジェクト管理のナレッジには、プロジェクトを成功裡に収めるためのノウハウが集積されていて非常に有用だ。加えてプロジェクトマネジメントプロセスが標準化されているために、PMBOKプロトコルがあればグローバルにプロジェクト管理に対応出来る。グローバリゼーションが進む時代で組織でシステム開発（だけじゃないですが）に携わるビジネスマンには必須の知識である。問題は、そのナレッジを有効活用するためにどのように使うか？何を使うか？をプロジェクト、プロジェクト群の実態に併せて考えるということである。

上記の通り、プロジェクト管理自体はシステム開発の生産性向上に何ら寄与しないことが多い。技術者、担当者目線では、開発の生産性に寄与しない雑用に過ぎないかもしれない。そしてあくまでナレッジの集積であり、全てを実践しようとすると無駄な作業が増えプロジェクト管理系業務への現場のモチベーションが下がるし費用も嵩んでしまう。だから、プロジェクト管理費用とプロジェクト成功確率向上を最適を探るためには何をどのように適用すると有効なのかを経験を踏まえ考察していく。そのためには、資格試験の知識から若干外れたプロセスやツールのあるべき論や背景、目的といった抽象的な内容にも踏み込む必要があるだろう。更に言えば、思考系、コミュニケーション系をはじめとしたスキルにも触れることになるかもしれない。体系立てる努力はしますが、書く内容は順番を気にせず私の問題意識のトレンドや思いつきで書いていきます。

とはいえ、プロジェクト管理については経験が浅く、先輩からの口伝や本の読みかじり、KKD（勘、経験、度胸）で行なってきたため、正確な知識とは限りませんのでご容赦下さい。