■ プロジェクトは、確からしい計画を立てることができたら、8割は終わったも同然です！
業務改革プロジェクト、システム導入プロジェクトと、その内容は違えども、いくつものプロジェクトにて、プロジェクト・マネージャーをさせて頂いてきた経験から言えるのですが、「プロジェクトは、万全な計画が立案できた時点で、ほぼ成功は見えている」というのが筆者の持論なのであります。この「万全な」という形容詞の意味の解釈が大事で、「絶対動くことのない予定調和的なスケジュール」のことを指すわけでは決してありません。
スコープチェンジ、要求仕様変更、要員のスキル・工数不足、度重なる納期変更、こういったプロジェクト進行と成功を邪魔する要因を全て掌握し、潜在的なリスクを全て洗い出して対応策も心得ておき、それらのリスクがいざ顕在化して課題として表出したら、涼しい顔でひとつひとつ片付けていく。もしかすると、その過程で、予定納期が過ぎてしまうかもしれません。
しかし、プロジェクトのQCDはいずれもトレードオフの関係。プロジェクト・オーナーや、ステアリング・コミッティーに諮り、納期遵守を取るか、品質向上を取るか、プロコンを明らかにし、プロジェクト・マネージャーの私見も大いに主張して、意思決定者に何を優先するか決めてもらう。そうすれば、スケジュール遅延も単なる×（バツ）ではなくなり、リスケジュールも含めて、プロジェクト目的を達成すれば、全てが成功なのです。結果よければすべてよし！？
注１）QCD：品質（Quality）、コスト（Cost）、納期（Delivery）
注２）プロコン：Pros and Cons（賛否両論）、複数案のメリット、デメリットの評価
そういう意味では、筆者は、当初の予定通りにプロジェクトを終えた経験は皆無です。しかし、プロジェクト・マネージャーになってから、失敗プロジェクトとして途上で中止になったプロジェクトは一つもありませんし、いまだに現役のコンサルタントとして首にならずに、プロジェクト案件をやらせてもらっています。全ては、WBSを中心とした、プロジェクトマネジメントスキルをクライアントにご評価いただいていることに尽きるのです。
そこで、シンプルなのですが、特に、業務改革やシステム導入の上流工程のプロジェクトにマッチするであろうと思われる「WBS」の作成方法についての「TIPS（秘訣）」をここに紹介したいと思います。
■ そもそもWBSでの管理を必須とする「プロジェクト」とは何者ぞ！？
本稿で説明したい「WBS」とは、「Work Breakdown Structure（作業分解構成図）」の略語になります。では、「WBS」というツールを使って効果的に仕事を進めることができる舞台としての、「プロジェクト」とは何者なんでしょうか？
プロジェクトとは、筆者のこれまでの現場感覚では、次の３条件の内、少なくとも２つを備える性質の仕事の進め方、またはその仕事そのものを意味します。
（１）個別性：ミッションに基づく明確なゴールがある
（２）有期性：期限（納期）が定められている
（３）不確実性：不確実な事象が潜在している
プロジェクトには非常に強力な達成目標や、解決すべき課題が必ず存在します。目標達成や課題解決がゴールです。このゴールに向かって、粛々と仕事を進めるのがプロジェクト的な仕事に対する姿勢です。そのため、プロジェクト内で実施される仕事は全て、ゴールに到達するために必要十分なタスクでのみ構成されていなければなりません。ゴール達成のためにやらねばならぬ仕事をひとつひとつ定義したものがWBSに記述されるのです。
プロジェクトには必ず納期が設定されます。いつまでにゴールに到達すべきか、ビジネスをやるうえで、有限でかつ重要な経営資源である「時間」を最大限有効活用するために、常に時間との勝負を促すツールとしてWBSに乗っている仕事にはすべて納期が設定されます。仕事のひとつひとつの締め切りを守るようにプロジェクト参画メンバの仕事のタイムコントロールを行うのです。
そりゃ、メンバからは一時的には嫌われますよ。だって、締め切りに追われる漫画家や作家が、現行の締め切りを迫ってくる編集者を嫌うのと同レベルに。でもね、漫画家さんや作家さんが、同時に担当編集者を頼りにしている場面もありますよね。プロジェクト・マネージャーも同じ。締め切りだけを迫るのではなく、課題が起きれば一緒に解決策の案出に知恵を絞るし、メンバの仕事が早く進むなら、喜んで買い出しに出かけて、おにぎりのひとつでも買ってくるものです。
プロジェクトには、常にその成功を邪魔する悪魔が裏に潜んでいます。毎日、プロジェクト・マネージャーが呆然と立ちすくむ様子を見てほくそ笑みます。プロジェクト・マネージャーは、プロジェクトのQCDの全要素が詰まっているWBSとにらめっこしながら、毎日、自分に挑戦してくる悪魔と戦い続けます。将棋や囲碁のように、何手も先を読みながら。そのために、プロジェクト・マネージャーが意思決定の「よすが」として頼るのが「WBS」なのです。筆者は、常に「WBS」を修正・加筆・実績記入しながら、プロジェクト進行にあたるのです。
■ そもそもWBSには何が記載されていればいいんだろう？
前章の最後で触れた通り、「WBS」には、プロジェクトマネジメントに必要な全要素が詰まっています。もし、「WBS」に記述が無いものがプロジェクトの進行を妨げるのなら、それはプロジェクト・マネージャーの見落とし、瑕疵に違いありません。全てを見通して、プロジェクト管理に必要なことは全て、一枚の「WBS」を見れば分かるようにします。ただし、何でもかんでも管理すべき要素を「WBS」に書き込んでいたら、「WBS」が複雑極まりなく、ビジーで見づらいものになるかもしれません。その場合は、本来は「WBS」に記述されていなければならないものを、
・課題管理表
・リスク管理表
・To-Do一覧表
などに、分記する方法もあります。それら、「WBS」以外のプロジェクトマネジメントツールのお話はまた別の機会に。
では、改めて、WBSに記載されているべき構成要素を下記にご紹介します。
「WBS」は、プロジェクトゴール達成のために、必ず成し遂げられなければならない仕事を、「WP（Work Package）」として記述していきます。上記のポンチ絵では、分かりやすいように、システム導入プロジェクトなどの上流工程、「基本構想」「要件定義」といったフェーズで必ず手を付けなければならない「分析（現状調査・ヒアリング）」「案出（あるべき姿、課題解決策の洗い出し）」「決定（アプローチや解決策の選択）」というようなタスク（作業・WP）を、時系列とか、因果関係、粒度・階層の別にしたがって、並べていきます。
そして、ゴール達成に必要な作業は、必ず、誰かがいつまでにやるべき仕事なのか、「担当者」と「納期（締め切り）」を貼り付けます。誰の仕事か分からない仕事は放置されるのが落ちです。それは、プロジェクトに限らず、ルーチンワークでも同じです。必ず、プロジェクトワークは、誰の仕事か、言い換えると、誰の責任で終わらせなければならないかを明確にしておきましょう。自分の仕事は何か、を職場やプロジェクト、同僚の全員に周知されていれば、通常の神経の持ち主なら、「これは自分の仕事だ、必ず自分の責任でやり遂げないと！」と動機付けることができるはずです。例外的に、「これは○○さんの仕事ね！」と渡したにもかかわらず、一向にその仕事をやってくれない人もいるかもしれません。それは、プロジェクトとか、「WBS」以前のその職場固有の問題、その担当者固有の問題。プロジェクトとしては、速やかに、上位の管理者、例えば職制の上司や、ステアリング・コミッティーに課題として、遠慮なくエスカレーションしていきましょう！
最後に、設定の難易度が一番高いと思われる「成果物」を作業に貼り付けます。というより、仕事のアウトプットが「成果物」です。それゆえ、「WBS」上で「作業（仕事）」と「成果物」を結びつける、という言い方にちょっと違和感を持たれる方がいらっしゃいます。でもどうでしょう。「現状調査報告書」を、①ドラフト版を作成する、②校正をかけて正式版を作成する、③上席者にレビューをしてもらう、④レビュー時の指摘事項を反映した修正事項を加筆する、⑤関係部署に配布する、というひとつひとつの作業（仕事）のアウトプットだとしたら。細かく定義すると、それぞれ、「現状調査報告書（ドラフト版）」、「現状調査報告書（校正第2版）」、「現状調査報告書（レビュー後第3版）」と名称が微妙にずれていきますが、同じ版を使った作業が必ずかぶります。そう、「作業（仕事）」と「成果物」は必ず「1対1」関係とは限らないのです。それゆえ、「WBS」上で、「作業（仕事）」と「成果物」の組み合わせを必ず意識する必要があるのです。また、前工程のアウトプットが、次工程へのインプットとなります。そのアウトプットとインプットの重なりが前工程と次工程をつなぐ「成果物」なのです。
次回は、具体的に、経営管理領域のいわゆる上流工程といわれるフェーズのプロジェクト事例を引いて、「WBS」を実際に描いていきます。
⇒「プロジェクトマネジメントの王道 WBSを作成する（2）上流プロジェクトの事例で実際にWBSを書いてみる！」
コメント