WBSはどこまで細分化すればいいのか【WBSの記事第二弾】

先日、WBSの意味と目的について記事を書きました。（WBSを制するものはプロジェクトを制す！WBSの意味とその目的を参照）

 

そちらの記事で、WBSは「工数算出・スケジュールを作る」「タスクの内容を理解する」ことを目的として実施する旨を紹介しました。

 

この記事を読んだ方から、

 

WBSってどこまで細分化すればいいんですかね？

 

という質問をいただきました。

 

そう言われてみると、僕が作ったWBSもフェーズやタスクによって粒度がマチマチだったりします。

 

「なんでだろう？」と自分の作ったWBSを振り返ってみると、その理由がわかりました。

 

「この理由ってけっこう重要かも」と思ったので、本日はこの点について触れてみたいと思います。

 

WBSはどこまで細分化できるのか

「WBSはどこまで細分化すればいいのか」について、考えるためにも、お悩みポイントである「WBSがいくらでも細分化できる」点について見ていきます。

 

これは説明するより例を挙げたほうがわかりやすいので、一般的な日本のビジネスマンを対象に「セブンイレブンのドーナッツを買う」というタスクを分解してみますと、

• セブンイレブンに行く
• ドーナッツを選ぶ
• ドーナッツを注文する
• ドーナッツを購入する
• ドーナッツを受け取る

 

となりますが、これらもさらに細分化することもできます。

 

「ドーナッツを選ぶ」までの流れを細分化すると、

• セブンイレブンに行く
• セブンイレブンの入り口に立つ
• 自動ドアが開くのを待つ
• セブンイレブンに入る
• レジ横のドーナッツの売り場に行く
• ドーナッツを選ぶ

 

のようになり、これらもさらに細かくすることもできます。

 

このように例を挙げるとわかりますが、どこまで細分化すべきか、は確かに悩むポイントかと思います。

 

どこまでWBSはを細分化すればいいのか

ここからが本題になります。

 

WBSを制するものはプロジェクトを制す！WBSの意味とその目的で触れたとおり、WBSを徹底することは「想定外タスクを減らす」というリスクヘッジにつながるのでプロジェクトの成功確率を高める、という旨を説明しました。

 

ところが、先ほど例に挙げた「セブンイレブンのドーナッツを買う」タスクの分解したとおり、わかりきったタスクまで書き出すと、スケジュール化（いつ初めて、いつ終わらせるか。その次にどのタスクを実施するか）した際に、管理作業も比例して増えてしまうので、タスク分解は適度な粒度でとどめておくべきです。

 

ここで、適度な粒度を図る基準が必要なわけですが、僕はこれを

 

自分が理解できる粒度まで分解する

 

と定めています。

 

この基準を元に、先程の「セブンイレブンのドーナッツを買う」のタスクを細分化すると

 

• セブンイレブンのドーナッツを買う

 

のみとなります。

スケジュール化した際でも、例えば今日の3時のおやつにドーナッツを食べるということであれば、

• タスク：セブンイレブンのドーナッツを買う
• 開始日時：今から
• 終了日時：本日15時00分

 

となります。

 

この例は簡単すぎますが、ビジネスの場でプロジェクト化されるものはもっと複雑です。

例を挙げて説明してみたいと思います。

 

WBSの細分化の例

ここでは、開発系プロジェクトのWBSとして、「コーポレートサイトの問い合わせフォームを作る」というプロジェクトを例に上げて説明していきます。

 

クライアントの要求は以下の通り。

• 企業への問い合わせを受けるフォームとする（採用、自社サービスなどの問い合わせは別とする）
• レスポンシブデザインで対応して欲しい
• 必須項目は非同期でエラー表示をさせたい
• 問い合わせ後はサンキューメールを自動送信したい
• 問い合わせ内容はデータベースに格納したい

 

この要求からは、エンドユーザに見える画面の制作があるので、デザイン面でのレギュレーションの確認が必要です。また、プログラミングが必要なので、サーバ環境の確認や、技術的に問題がないかの実現可否確認も必要になることがわかります。

 

さらに、予算が決められているハズなので、見積もりを作成し、予算を超えた場合は要件の変更・見積もり変更が発生します。

 

これらの内容から、自分が理解できるところまで分解すること以下のようになります。

• 要件定義
  • デザインなど各種ガイドラインの確認
    • デザインガイドラインの確認
    • コーディングガイドラインの確認
  • サーバ環境の確認
    • インストール済みのミドルウェアの確認（バージョン含む）
    • パラメータシートの確認
  • 実現可否確認
    • 実現が難しい課題がある場合、解決案を考えて提案
  • 機能一覧の作成
  • 見積もり作成
  • （必要に応じて）要件変更・見積もり変更
• 設計（設計、及びそれ以降は、要件定義の内容から再度WBSを実施）
• 開発・開発
• テスト

 

僕自身、開発の経験があるため、一般的な問い合わせフォーム構築の要件定義としては、この程度の粒度でブレイクダウンされていれば問題ありませし、分解したタスクをすべて自分で対処することも可能です。

 

ただ、開発に関する知見がない場合は、「設計フェーズに進めるために、要件定義で何を決めて置く必要があるのか」がわからないので、コチラで述べた通り、自分でWBSを完成させるためには知見のある人とタスクを細分化していくことになります。

 

さらに、クライアントに確認・提案する際には、誰とどんな内容を確認すればいいのか、必要に応じて社内ですり合わせを行ったりもします。

 

このように、意思決定が必要なタスクは、マイルストンとしてプロットしておくことも重要です。

（僕はタスクの見直しも兼ねて、いつもスケジュールにプロットしています。）

 

WBSが完成することはない！？

プロジェクトそのものに言えますが、常に変更が発生するので、完成することはありません。

 

先に挙げた「コーポレートサイトの問い合わせフォームを作る」においても、実装可否確認の結果、解決案を考えて提案する必要があることをタスクとして計画していますが、具体的な内容は実装可否確認を実施しないことには見えません。

 

このように、予めタスクを予見することはできますが、具体的なタスクが分からないものの他に、突発的に発生するタスクがあります。これら突発タスクは、単純に実施すればいいものもあれば、解消しないと後続のタスクを着手することができないクリティカルパスになるものがあります。

 

このあたりは、リスクマネジメントの考えの通り（リスクマネジメントで一番難しいことの記事を参照）、予見できないものは都度対処していくしかありません。

 

余談：進行管理上の問題

WBS後、スケジュールを作成しプロジェクトの進行をするわけですが、過去に僕が経験した体制上の問題について触れたいと思います。（この記事からは趣旨がズレるので、お急ぎの方は読み飛ばしてください）

 

大規模・中規模のプロジェクトになると、1人でWBSを作り上げるのは難しいので、必然的にタスクを理解できるリソースと一緒に検討していくことになります。

 

その際、デザインフェーズだったらアートディレクター、制作フェーズだったら制作ディレクター（シニアエンジニア、など）とタスクの細分化をしていきます。

 

当然、プロジェクトの体制を考える時は、アートディレクターの下に必要名のデザイナーが、また制作ディレクターの下に必要名のエンジニアがぶら下がるようにアサインします。

 

ところが、プロジェクト開始後、マネジメントを期待しているアートディレクター、制作ディレクターに進捗を確認すると、

 

あ、それは現場（作業者）に確認してください

 

と言われ、直接作業者へ状況を確認することがよくあります。

それも「自分は進捗とか見ませんから」と言わんばかりの涼しい感じで言われるので、こちらもそれ以上は期待しないのですが、僕はいつも「それってちょっと違いませんか」と思います。

 

プロジェクトは限られた時間の中で成果物をコミットするため、品質に限らずスケジュール感も含めて、タスクを任せているアートディレクター・制作ディレクターが責任を負うものです。

 

スケジュール管理は、プロジェクトマネジャー（プロマネの機能を担ったディレクター）がするもの、として管理業務に関しては自分の管轄外として、勝手に自分の作業範囲を決めている方が多いように感じます。

 

僕はそういうリソースが割り当てられてしまった時は、品質管理も含めてタスクを巻取り、そいつに仕事をさせないようにしています。

（心なしかアートディレクターに限って、「このデザインはレビューしてない！」とかブツブツ言ってくるように思います。その場合は、コーディングのフェーズでデザインの修正が発生しても別のデザイナーにお願いして処理したりしちゃいます）

 

大きなプロジェクトを手がけようとしているディレクター・プロジェクトマネジャーの方は、WBSに注意を払うだけではなく、他にも気にしなければならないポイントはたくさんありますので、自分なりに見つけてもらえればと思います。

 

最後に

WBSはプロジェクト計画の要素であるスケジュールを作成するための中間成果物にすぎませんが、タスクが見えているかどうかで、プロジェクトの成功度は大きく変わってきます。

 

見えないタスクがあればあるほどプロジェクト進行中に想定外タスクが発生し、急な対応を余儀なくされます。そのため、予め想定されるタスクを洗い出し、誰が・いつ・どのタイミングで実施するのかをスケジュール化しておくことがどれほど重要か、理解いただけると思います。

 

さらにプロジェクトが成功し、自身のプロジェクトマネジメントのスキルが評価されれば、やりたい案件へ参画するチャンスも広がります。

 

実際、僕もディレクター初心者だった頃は、制作・開発のスキルセットを活かした制作ディレクションが中心でしたが、徐々に設計やデザインなどの工程も任されるようになり、今では販売戦略や新規サービス立ち上げ時のサービスデザインなども請け負うことができるようになりました。

 

デザインや設計のフェーズでは、ビジュアルデザインやワイヤーフレームなど成果物がわかりやすいので、僕の理解もそれなりに早かったのですが、マーケティングやコミュニケーションデザインの領域は、正直に言うとタスク分解してもとタスクの理解が追いつかず、とても苦しんだ経験があります。

 

ちょうど今お世話になっている会社で、プロモーション戦略とサービスデザインを担当させてもらっているので、僕の記憶が新しいうちに、このあたりのWBSについて紹介したいと思います。

（今日はたくさん書いたので、またの機会に！）