WBSが案件炎上の予防線になる!?

今回はWBS(ワークブレイクダウンストラクチャ)のお話です!



 

WBSはプロジェクトマネージメントの基本としてよく使われている手法です。

 

実はこの手法って、案件を炎上させないための方法として、とても有効な手段だったりします!


過去の記事では、案件が炎上した経験を色々語りました。

 

でも、どうすればいいの?・・についてはあまり触れてなかった気がするので、今回はこちらをテーマにさせていただきました!

 

WBSの考え方を知ると、リスクの早期発見に役立ちますので、ぜひ読んでみてください!


 

何故プロジェクトは炎上しやすい?

 

WBSの前にプロジェクトが炎上とか手詰まりになるケースを考えてみましょう。

 

失敗事例としてよくあがっているのは「イマイチ解らないけど、とりあえず手探りで進めるか」・・みたいなパターンです。

 

このノリで進めてしまうと、こんな事が起きやすかったりします

 


これが起きる原因って、要はただの情報不足なんですが、ここは別な表現で解説します。

 

例えば、我々が乗り物に乗って、一度も行った事ない場所でも、ちゃんと目的地に付けるのは何故でしょう?

 

それは・・

 

地図や案内版があるから!


進む道が示され、自分が今どこにいるかが解ると不安も減るし、誰もが同じ場所に到達出来ますよね。

 

プロジェクトマネージメントでこの「地図」にあたるのが・・

 

WBSなんです!


 

WBSとは?

 

WBSは「Work Breakdown Structure」これを訳すと「作業分解図」という意味になります。

 

要はタスクを構造化して、関係者全員が視覚的に解りやすくするための資料です。

 

この説明だけじゃ解らないと思いますので、ストーリー化して解説します。


 

WBS作成のロープレしてみます。

 

この記事は、非エンジニアの方も読んでますので、開発計画とかではなく、ITに関係ない作業を例にします。

 

あなたは、炒飯を作るのが得意な料理人で、知人からあなたのチャーハンを食べてみたいというリクエストをたくさん受けています。

 

そこであなたは、知人を呼んで炒飯パーティーをしたいと考えました。

 


この案件を計画的にプロジェクト化するにはどうすればよいでしょうか?

 

まず私なりのWBSを作ってみます!


 

まずは大項目を洗い出そう!

 

最初に、こんな感じで大項目を洗い出します。

 

  • 要求
  • 場所
  • 設計(レシピ)
  • 調達
  • 料理
  • 配膳
  • 撤収


 

更に細分化して構造にしよう!

 

次は大項目を実現するために必要な作業を、関係者各位と徹底的に確認を行い、洗い出します。

 

そして洗い出した情報をこんな感じでツリー構造にしていくんです。


こうすると「炒飯のパーティー」を実現するには、どんな作業が必要か?視覚的に構造で解りますよね。

 

次はこの構造を表にして、洗い出した作業は、どんなスキルを持った人に頼めば良いのか?どれくらいの工数で出来るか?を1つずつ確認していきます。


実はここがとても重要なポイントで、ここで「作業不可」の項目があった場合、プロジェクトはそのフェーズに来たらストップします。

 

なので、すべての項目で「作業可能」と確認が取れるまでは、プロジェクトをスタートしてはいけません。

 

また、「誰がやれる」の部分にやれそうな人を、ただ適当に当てはめていくのもダメです。


担当を決めたら、本当にやれるか?を必ずアサインした人に確認しましょう。

 

よくある失敗例は、ここで勝手に担当を決め無茶振りをして、責任だけを押し付ける事。

 

可否の確認をせず、とにかくやらせるという行為は、結果的に「問題の先送り」と同じ意味となります。


プロジェクトはこのように、都合の良い言い訳を重ねれば重ねるほど、リスクが増大します。

 

無茶振りは、立場が上の人ほど、ついやってしまう傾向があるので注意しましょう。


 

ここまでがWBS!

 

やるべきこと・可否の確認はプロジェクト開始前に必ず確認する、とにかくこれが一番大事。

 

プロジェクトがかなり進んだ段階で抜けがあったり、出来ない作業項目が発生すると、そのまま炎上に繋がります。

 

プロジェクトにどんな作業が必要か?これを視覚化するのが、WBS(ワークブレイクダウンストラクチャー)で・・

 

これがプロジェクトすべての骨組みになるんです。


難しいと感じる事でも、何が難しくて、何ができないのかを、プロジェクトが始まる前にちゃんと具体化・視覚化できていれば、関係者から協力を得る事ができます。

 

また、この情報を拡張して進捗管理表を作ったり、開発計画の場合はロードマップの骨子にも利用できます。


 

課題管理と組み合わせると最強

 

このWBSに基づいた進捗管理表を作り、何が終わっていないか?関係者各位で共通認識を持ちつつ、問題が発生したら、課題管理で議論して一つずつ潰していくと、冒頭で話したリスクを大幅に回避できます。

 

※冒頭で話したリスク


 

課題管理の大事なポイントは、問題を共有して、対応がちゃんと進んでいるかを全員が把握できるようにして、いらぬ不安を持たれないようにすること。

 

また、課題の完了宣言をする事で「これ以上この件では議論しません」という事をやんわり共有するのも実はすごく大事なんです!

 

※WBSをもとにした進捗管理表の例


 

※課題管理表の例


 

最後に

 

チームで仕事をする人であれば、プロジェクトマネージメントの考え方は必ずどこかで役立ちます。

 

大事なのは、こういった技法をそのまま実行する事ではなく、考え方を知り応用してチームの成果を出す事!

 

あまり固く考えず、先人の知恵として、自分なりのやり方でうまく活用していきましょう!


 

今回のお話で、プロジェクトマネージメントに興味が出た方は、以下のように簡単に解説している本が結構出てるので、まずこういうのから読んでみると良いかもしれません!

 


フォロー待ってます!
シェア大歓迎!

コメントを残す

メールアドレスが公開されることはありません。