先週末から暑い日が続いています。TVではまだ暑さに慣れていないこの時期、熱中症になりやすいと盛んに注意を促しています。他人事とは思わず気を付けたいものです。
さて、WBSについて考えています。前回は成果物基準のWBSに触れました。これは成果物、つまり「なんらかの形のある結果」を作り出すためにどのような行動（タスク）が必要かを考えるということです。
成果物には、製品やソフトウェア、ドキュメントなど直接目的に結び付く具体的な”モノ”と、システム（仕組み）やサービス（ビジネスモデル）などの概念を具体化するためのツールがあります。例えば、マニュアルやルール作りですね。それともう一つ”承認を得る”という合意形成の成果物があります。
”承認”という行為ではなく結果としての成果物は多少異質ですが、WBS上はとても重要な成果物となるので、注意が必要となります。
「概念を具体化するためのツール」についてもう少し考えてみましょう。
例えばFacebookは世界中からユーザを集め、SNSという無料のサービスを提供し、そうすることで広告収入を得るというビジネスを行っています。つまりこのビジネスの基本は、メディアとしての価値を上げるために、いかに多くのユーザを集めるかにかかっているわけです。
そのためこのビジネスを始めるときの成果物は、SNSシステムということになります。決してSNSシステムを作ることが目的ではなく、目的は”儲ける”ことだということにご留意ください。成果物はあくまでも目的を達成するための手段だということになります。
前回のブログで「成果物はプロジェクトの目標」であると述べました。キットPMの定義では、プロジェクトの目的は、１つもしくは複数のプロジェクト目標の集まりによって達成することになります。
そのため、成果物基準のWBSを考えるときは、各成果物がプロジェクトに対してどのような”価値”を提供するのか、またそれぞれの成果物はどのような関係を持つのかを定義することが必要となります。つまり目標（成果物）の構造化です。
成果物基準の場合、結果である「目的達成」からスタートへ向かって、成果物単をBreakdownしていくことになります。ツリー構造をイメージいただくと分かりやすいのではないでしょうか。
一番上に目的が存在し、その下に目的を達成するために必要な成果物を配置していきます。
●
＿＿＿｜＿＿＿
〇 ◎
＿＿｜＿＿
△ ■
こんな感じです。
このとき、「●を行うためには何が必要か？」という問いかけをします。できれば声にだしてください。
上記の例は問いかけに対して「〇と◎が必要」という結果になっています。さらに「〇を作るには何が必要か？」という問いかけに対して、「△と■が必要」という結果となります。
このように、終了時点から遡って成果物を分解していくことで、比較的抜けや漏れを少なくして成果物を構造化することができます。
このテーマ次回もまだまだ続きます。