失敗を避けるために知っておくこと

IT業界においてよく聞く言葉の1つとして「プロジェクト炎上」というものがあります。
最近ではよく使われるようになった炎上ですが、ここにおいては要するにプロセスに狂いが生じてしまい、スケジュール通りに進まなくなったり、そもそも完成させることが難しくなってしまうなどの大問題が発生することを指しています。
プロジェクトの炎上が起こればそのプロジェクトが大きく失敗してしまう可能性が高まるだけではなく、同時に部署や会社全体の評判を低下することにも繋がる大問題となります。
出来ることならばプロジェクトの炎上は避けたいわけですが、どのようにするとこれが可能なのでしょうか？

プロジェクトの炎上を避けるためには、WBSというものについて知っておく必要があります。
WBSというのはWork Breakdown Structureの略称で、つまりは作業を細かく分割して構築する、スケジューリングの手法の1つを指しています。
では、通常のスケジューリングと比べてどのような点が優れており、どういった点に注意する必要があるのでしょうか？

WBSのポイント

WBSのポイントの1つ目としては「表計算ソフトを使わない」ということが挙げられています。
今やどんな職場においても利用されているこのソフトを利用しないことによってどのようなメリットがあるのか、ということがまず疑問として浮かぶでしょう。
これはもちろん業務全体に置いて利用しないということではなく、あくまでもスケジューリングのためのツールとして利用しない、ということです。
小さなプロジェクトであればプロセスの数も少なく表計算ソフトでも十分管理することができますが、タスク数が大きくなるほど管理に適さないものとなり、段々とわけが分からなくなってしまう、というわけです。

次のポイントは「ともかくタスクを細分化しすべて書き出す」ということです。
これがブレークダウンという過程であり、通常ならば大雑把にしか書かれないような部分についてもともかく細かく、一つ一つの作業を書き込むつもりで作っていくことが重要です。
そうすることによっていざという時の小回りがきくようになり、失敗を避けることができる、というわけです。
目標は100タスクの書き出しです。

ただ、いきなり100タスクを書き出せと言われてもなかなか難しいでしょう。
そういった時に重要になるのがストラクチャーの項目、「作るものを目安にして構造化していく」ということです。
完成形が見えていなければ細分化するのは難しく、逆に完成形さえ見えていればガイドラインを作るのも簡単である、という理屈です。

次に「クライアントの希望は一度忘れ、あるべきものを考える」ということです。
受注生産をするプロジェクトにおいてあるまじきことのように思えますが、まずは実際にこういったものにはどんなものが必要なのか、ということを考え、それをベースにして考えていくようにしましょう。
例えば納期についても「1ヶ月以内」とクライアントから指示されていたとしても、しっかりとした作成をするのであれば「2ヶ月」必要である場合、2ヶ月をベースにしてストラクチャーを考えていく、ということです。
できないことはできない、できる事を出来る範囲内で考えて調節していくことがWBSの基本です。

そして更に重要なことの1つとして「それぞれの担当者を明確にする」ことです。
タスク一つ一つを並列して進めていくことになるため、ここを適当にしていると後々整合がとれなくなります。
一つ一つの責任者と担当者をはっきりさせて、最終的な構築を目指せるようにしなければなりません。