プロジェクト炎上を防ぐ10の法則 - WBS作成の極意
※インテリジェントネットではWBSを引いたり、WBSに沿って一緒にものづくりをする仲間を募集しています。詳しくは【インテリジェントネット採用情報】をご覧ください。
先日、当社インテリジェントネットにてフリーランスとしてご活躍されているd-threeの大崎さんをお招きして社内勉強会「WBS講座」を開催しました。
ほぼ全員参加だったため、全くWBSやスケジュールをひいたことのない初心者もいれば、日頃から中～大規模サイト構築案件のディレクターとしてWBSをひいてプロジェクトマネジメントをしている中級者（どこまでが中級者でどこからが上級者かわかりませんが）まで幅広いメンバーが参加しました。初心者向けのレポートは新人ディレクターがアップしますので、このエントリでは中級者向けのレポートをアップしたいと思います。
そもそもWBSとは？
「Work Breakdown Structure」です。ここまではわかっていたのですが、「スケジュールとの違いは？」と聞かれてお恥ずかしながら「・・・？！」となってしまいました。意味としては明確に違う物で、WBSは「Work＝お仕事（作業）」を「Breakdown＝細かく分類、分解」して「Structure＝構造化」することを指すものだそうです。つまり、プロジェクトのスコープを管理するためにタスクを細かく分解したものであり、この段階ではまだ日付けや期間は入っていないのですね。ということは「WBSを使ってスケジュールを作成する」が正しい表現なのかもしれません。
でもそんなことは細かく考えなくていいそうです（でも僕が書きたかった）
さて、では本題に入ります。 とかく炎上しがちなWebサイト構築プロジェクト。どのようにWBSをつくり活用すれば炎上のリスクを減らすことができるのか？という視点で10項目に分けてみました。炎上こわい！炎上こわいです！
１．Excelは使わない
しょっぱなから「まじか！」っていう方も多いんじゃないでしょうか。かくいう僕も以前はExcelを使ってました。だからエクセラー（？）の気持ちもよくわかります。今までそれ使っててそれが当たり前であればなかなか変える気にはなれないものです。でも変えましょう。大崎さんも「Excelがプロジェクト管理ツールより優れている点は初めのとっつきやすさだけ」と、ばっさり切り捨てていました。
実際、タスクが100以上にもなると、何かのタスクの前提が変わったりしてスケジュールが変わったり、それに合わせて前後すべてのスケジュールを変更しなければならなくて、スケジュールを調整してるのかExcelと戦ってるのかわからなくなってきます。専用のツールなら前後のタスクも自動でずらしてくれますし、工数を入力すればこれまた自動でガントチャートの線も変更してくれます。これができるだけでExcelとの戦いから解放され、だいぶ時間に余裕ができます。プロジェクトの炎上を防ぐ最も単純な方法はディレクターが時間的余裕を持つことじゃないでしょうか。
２．タスクはとにかくすべて書き出す。100個書き出すつもりで！
とにかく出す！気にせず出す！だそうです。まずプロジェクトのゴールにたどり着くためにどんな作業があるのか、それを明確にし、全員が共有しなければいけません。「デザイン」とか「コーディング」だとか、そのレベルのものはさすがに誰でも入れていると思います。それらに加えて「技術要件定義」などを入れることもあるかもしれません。でも、これではダメだそうです。例えば技術系の要件定義ならユーザー環境の定義もあればHTMLやJavaScriptなど実装技術に関するものもあります。例えば「サポートブラウザー定義」という書類の項目レベルまでタスクとして分解すべきとのこと。確かに、「技術要件定義いついつまで」と決めても、その中の要素を明らかにしていないといったい何割進んでいるのかがわからなくなりますね。なるほど。
３．つくる物を目安に構造化する
100個書き出すつもりで！と言っても、いきなり完成型が見えて上から順に書いていけるわけではないと思います。やはりそういう場合は（こういうものは何でもそうだと思いますが）大枠、大きなカテゴリから考えていって、その次にそれに紐づく詳細なタスクを書き出すと良いと思います。
そのとき
「要素成果物（つくるもの）を目安に構造化すると良い」
とのこと。結局最終的にドキュメントかＨＴＭＬか何かを出すわけですから、それを大きなカテゴリとしてタスクを分解すると良いのですね。
４．まずはあるべき論でひく。発注者の希望はど忘れする
これ重要だと思いました。僕らディレクターは発注者と直接やり取りすることが多いがために相手の要望に耳を傾け過ぎてしまうことがあります。「○月○日までに公開！なにがなんでも！」と言われるとそこを基点に考えてしまいがちですが、それで炎上して結局遅れたり瑕疵が多発するようでは元も子もありません。スケジュールを短縮するにしても、どのタスクが肝で、どこならチャレンジができるのかを把握するためにはまずきちんとタスクを構造化する必要がありますよね。
５．依存関係を強く意識する
すべてのタスクには「これが終わらないとそれは始められない」や「これが始まらないとそれも始められない」という依存関係があるはずです。プロジェクトマネジメントを料理の段取りに例えたりすることは多いのですが、大崎さんはポテトサラダの作り方を例にしていました。例えば、お芋を潰す作業が必ず発生しますが、それはまず茹でてからでないとできません。洗い物の完了は調理の完了時間に左右されます。このように、タスクには依存関係があり、これをちゃんと意識してWBSをつくらないと前後関係に無理が出てプロジェクトが炎上します。僕はマヨネーズが大嫌いなのでポテトサラダも嫌いなのですがそれが気にならないぐらいわかりやすかったです。
６．必ず担当者を明確に
「みんなでやろうは誰もやらない」僕がよく使う言葉です。WBSをどんなに細かく作成しても、最終的にそれを誰がやるのかがわからなければ、誰も手を付けなくてスケジュールが遅延します。必ず、何を、誰が、いつまでにやるのかを明確にしておくべきです。
「複数の担当者がいる場合には、必ず主担当者と副担当者を明らかにすること」
だそうです。なるほど。ちなみに大崎さんは会社名だけでなく、発注側も含め担当者の名前まで入れるそうです。
７．わからないところは必殺"フェーズ分け"
「基本的にプロジェクトには"やったことがないこと"が含まれている」
PMBOKにあるプロジェクト定義を持ち出してこうおっしゃってました。全く同じプロジェクトというのは世界に二つとなく、必ず"わからないこと"があるとのこと。だから、わかるところから詳細化して、わからないことはわかる人かGoogle大先生に聞くわけですが、それでもすぐに答えが出てこないことがあります。要件を詳細に洗い出さないとわからない部分もあり、それは仕方ないといえば仕方ないんですが、しかしそれではプロジェクトのゴールが見えなくて稟議や提案が通りません。そういう時は、計画と実行や開発などフェーズを分けて、手前のフェーズを詳細に計画を立てて、それを進めながら次のフェーズの計画を詳細に立てていくことが大事だそうです。そうしないと、わからないことに対して詳細な計画を立ててしまうとその通りに進まないのでプロジェクトが炎上しますね。これは確かに、当社もそのように進めているので納得でした。
８．調整は"あるべきWBS"ができてから！
タスクを分解して、きちんとそれぞれに必要工数を入力すれば、おのずとスケジュールも出てくると思います。
「だいたい発注者の希望日には間に合わない。間に合っていたら何かやるべきタスクが抜けてると思うぐらいでちょうどいい」
とのこと。確かに・・・。でも、これはこれで良いのですね。この段階ではそれが正解。これまでにちゃんとタスクを洗い出して、依存関係をきちんと繋げていれば、その作業が何でどんなものなのかが明確になっているはずで、だからこそ「調整」ができるんですね。大量なタスクの"勘所"がわかるからこそ、リスクを踏まえた調整ができるのだと思います。期日だけ意識して「えいやっ！でWBSをつくっちゃう」っていうのは絶対にやってはいけないことです。
９．クリティカルパスを意識する
「クリティカルパス＝所要時間が最長の経路」
これは、一つのタスクの話ではありません。前後のタスクの連なりの話です。WBSで依存関係を意識してタスクをつなげば、いくつかのタスクが連なった"経路のグループ"ができると思います。その中で最長の経路がクリティカルパス。おのずとこれは、プロジェクトの開始から終了までをつなぐ経路になると思います（それ以上のものが無いので）。この経路に入っているどこかのタスクが遅れればプロジェクト全体も遅れることになります。逆に、クリティカルパスではないタスクを短縮してもプロジェクト全体の短縮にはなりませんよね。もともと影響しない部分なのですから、そこを短縮しても担当者が優雅にコーヒーを飲む時間ができるだけです（それも大事ですが）。
１０．進捗の把握は"期間"ではなく"成果物"の進捗度合で
WBSを使ってスケジュールをひいたとしても、WBSそのものはただのデータ、もしくは資料の一つでしかありません。その通りにプロジェクトを進めなければいけないですし、遅れているのか、進んでいるのか、常に状況を把握し、メンバー全員で共有していなければ意味がありません。
- 「頻度は状況によって臨機応変に使い分ける」
- 「タイトな場合は毎朝10分のMTGとかも効果あり（ただし形骸化する恐れも）」
- 「とにかく、全員が同じ状況意識を持つことが大事」
だそうです。この辺、悩みどころですね。ただ、このとき注意しなければならないのは
「状況の把握に大雑把なパーセンテージや純粋な期間だけを使ってはいけない」
とのこと。たとえば「いま70％できています」と報告を受けても、それは具体的に何がどういう状態なのかがわかりませんし、10日のうち現在7日目だから70％と把握しても、実際の成果物が進んでなければ意味がありません。ここは、例えば10ページの資料なら
「7ページ終わってるから70％とすべき」
とのこと。
おまけ１．WBSは１人でつくらない
「三人寄らば文殊の知恵」
「７．わからないところは必殺"フェーズ分け"」でも書いた通り、プロジェクトには「わからないところ」はつきものです。だからこそ、一人で考えすぎてはいけないと強くおっしゃってました。わからないことはわかる人に聞けば良いですし、その方が精度が高くなりますね。もとい、わかる人が責任をもって定義しないとあやふやなものができてしまって、実際にそのように進まず炎上へまっしぐらです。
また
「スタッフみんなで考えれば気づきも多い」
とのこと。確かに・・・！。
おまけ２．クライアントにもわかりやすいWBS
「WBSってちゃんとつくればつくるほど細かくなっちゃって、クライアントには何が何だかさっぱりなんですよね(´・ω・｀)」という事前質問を出していました。
↓↓↓返答↓↓↓。
「『WBS』としてはないかも...(^_^;)」
つまり「そんなものはない！」ということですね（そこまで言い切ってはいない）。
僕も薄々感じていたことだったのですが、はっきり言い切られていて助かりました。１人で悩んでいたものが「その方向に答えはたぶんない」とわかるだけでもぜんぜん違います。クライアントは結局のところ「よきにはからえ」でサイトができちゃえばそれが一番良いわけで、開発メンバーと同じように状況を把握する必要はないんですよね。
WBSが状況の詳細な把握と共有のためにあるとすれば、その対象にクライアントは入らないわけですね。クライアントが知りたいのは全体の大まかな流れと重要な部分の期日（マイルストン）や、そのなかで自分たちが何をする必要があるのかだけなので、そこだけに焦点を当てて資料をつくり、理解してもらえば良いのかと思います。例えばそれは前者がロードマップであり、後者がチェックリストやチェック内容をまとめた資料になるのだろうと思います。
まとめ
- Excelは使わない
- タスクはとにかくすべて書き出す。100個書き出すつもりで！
- つくる物を目安に構造化する
- まずはあるべき論でひく。発注者の希望はど忘れする
- 依存関係を強く意識する
- 必ず担当者を明確に
- わからないところは必殺"フェーズ分け"
- 調整は"あるべきWBS"ができてから！
- クリティカルパスを意識する
- 進捗の把握は"期間"ではなく"成果物"の進捗度合で
おまけ１．WBSは１人でつくらない
おまけ２．クライアントにもわかりやすいWBS（は、たぶん無い）
並べてみると、割と基礎的なことばかりな気もします。
ただ、各々はなんとなくはわかっていても、ちゃんと言葉にして強く意識しているかというとあやしい部分もあったり、手法に落ちていなかったりします。僕自身、新たな発見もありながら、改めて肝に銘じる、のような部分もありましたが、総じて大変勉強になりました。
これをご覧の皆さんも、いま一度自分のWBSやスケジュールを見返してみてはいかがでしょうか。
インテリジェントネットではWBSを引いたり、WBSに沿って一緒にものづくりをする仲間を募集しています。
詳しくはインテリジェントネット採用情報をご覧ください。