ブログ

プロジェクト管理:WBSとは~計画立案の進め方とポイント~

  • このエントリーをはてなブックマークに追加

見える化+WBS+リーン開発スタイルでプロジェクト管理の計画力をアップ!

プロジェクト管理では、基本的に初めてのことに取り組む事がほとんどです。
ですから、先が見えません。経験がなければ、どのような作業があるのか、どのような問題が発生するのか、まったくわかりません。類似のプロジェクト経験があれば、そこからある程度は、作業内容やリスクは予測がつきますが、まったく同じというものではありません。
プロジェクト管理では、計画段階で、先が見えないということが、大きな悩み、課題のひとつです。
計画如何によってプロジェクトの成功、失敗は決まると言っても過言ではありません。
見える化+WBS+リーン開発スタイルによってこの課題を解決する方法をご紹介します。

 ・計画の悩みを解決するには
 ・WBS:作業展開計画とは
 ・実際のWBS:作業展開計画は
 ・アウトプット+課題・リスクから作業展開
 ・作業を先行させてリスクを早く見つけ解決する
 ・プロセス順の開発スタイルの問題点
 ・機能別開発スタイルで問題・リスクと先出し

計画の悩みを解決するには

計画段階の悩みは、先が見えないと言うことです。
しかし、初めてのことに取り組むのですから、見えないのが当たり前です。
先に進まなければ見えてこないこともたくさんあります。
それを最初からすべて見えるようにしようとすることに無理があります。
重要なのは、見えている事と見えていない事を明確にすること。
つまり、見えていない事を見える化することです。
今はまだ、見えていないとわかっていれば、それを前提として仕事を進められます。
見えてきた時に対応できる準備ができるのです。
そして、見える時期を1秒でも早くなるようにすることです。
考えて、計算すれば見えるものでは、ありません。
相応の環境や実際の経験があって、初めて見えてくることもたくさんあります。
そのような環境や経験を一秒でも早くすることが、見える時期を早めることにつながります。
見えてないことを見えるようにする、見える時期を早めるということに有効な手法のひとつが見える化による作業展開計画です。
体系立てて、プロジェクトの作業を整理し、展開する手法です。

WBS:作業展開計画とは

プロジェクトを開始するにあたり、皆さんは、作業をどのように洗い出しますか?
過去の経験ですか?開発ルールに従ってですか?
作業展開計画(ワークブレークダウンストラクチャー:Work Breakdown Structure)は、プロジェクトの成果物であるアウトプットを生み出すための作業を体系的に洗い出す手法です。
作業一つ一つのつながりを明確にしながら、必要な作業をあぶり出していくものです。
作業は、相互に関連し合って、アウトプットを生み出すことにつながっていなければなりません。
アウトプットにつながっていない作業は、必要の無い作業です。
皆さんは、作業を洗い出すとき、工程や時間の始まりから終わりに向かって、どのような作業が必要か考えていませんか?
作業展開計画では、逆に、後ろから考えます。
まず、最初に、そのプロジェクトの目的を明確にします。
次に、その目的を実現するために、プロジェクトの成果物であるアウトプットを明確にします。
目的に即したアウトプットでなければなりません。
そして、アウトプットを生み出すために必要な作業を仕事の流れとは逆に、遡るようにして洗い出します。
このような洗い出し方法をアップストリーム型と言います。
仕事の始まりから作業を洗い出すと、その作業の必要性がわかりません。
取りこぼしている作業にも気がつきません。
そして、何よりも自分たちの知っている作業しか洗い出すことができないのです。
アップストリーム型では、まず、目的に必要なアウトプットを洗い出します。
目的に不可欠のものが何であるか考えます。
目的を達成するために、どのようなアウトプットにすればいいかわからない事も見えるようになります。
見えない事が見えるのです。
次にアウトプットに必要な作業を順番に洗い出します。
このときも、アウトプットを生み出すために、足りない作業、どのようにすればいいかわからない作業が明確になります。
見えない事、わからない事は、それを見えるようにするために何をすればいいのか考えて計画します。

実際のWBS:作業展開計画は

実際の作業展開計画(ワークブレークダウンストラクチャー:Work Breakdown Structure)は、最初からすべてのアウトプットと作業を洗い出す事はできません。
プロジェクトをフェーズに分けて、フェーズ毎に作業展開計画を行います。
プロジェクトの段階毎に作業展開計画を立てていきます。
しかし、それでは、フェーズが進まないと先が見えない事になります。
そこで、設計フェーズによって最初にすべてのアウトプットを洗い出します。
設計フェーズの目的は、すべてのアウトプットを明確に定義する事です。
そして、明確になったそれぞれのアウトプットをもとに、作業の展開計画を行います。
このように作業展開計画は、設計フェーズの設計活動と密接に絡み合わせて行います。
どうしても、設計フェーズが終わるまで待てない場合は、企画段階で、アウトプットをきっちりと定義するか、概要設計だけを先行して行い、アウトプットを明確にする事で、作業展開計画を行うことができます。その場合でも、設計フェーズが終わったときに、アウトプットの見直しと作業展開計画の再計画を行うようにしてください。

アウトプット+課題・リスクから作業展開

目的を明らかにし、アウトプットを定義すれば、作業を洗い出す事はできます。
しかし、それでも、まだ、作業を見えなくする原因が潜んでいます。
それは、アウトプットを実現する上での課題やリスクです。
この課題やリスクが何であるのか明確になっていなければ、単純に作業を洗い出しても、
その作業が後からも間違っているものであったり、足りなかったり、ムダであったりすることになります。
例えば、データがそのままでは会計システムと連携できないという課題がわかれば、作業の中に会計データへの変換機能のつくりこみの作業を最初から組み込む事ができます。
また、クラウド接続の経験が無く不安があれば、接続テストを先行して行う事を計画できます。
このように、アウトプットの実現上の課題やリスクを明確にする事で、足りない作業や見えない作業を明確にする事ができるようになります。

作業を先行させてリスクを早く見つけ解決する

しかし、課題やリスクそのものを最初から洗い出す事もなかなか難しいものです。
経験の無い事であれば、どんな課題やリスクがあるのか想像もつきません。
中途半端に経験がある場合は、大丈夫、いける、と思ってしまい、実際に後で大きな問題が発生したということもよくあります。
このように、課題やリスクはなかなか洗い出す事は困難です。
そのようなときは、作業を先行させて、早めに着手して、トライしてみて、課題やリスクを洗い出す方法も必要となります。
経験の無い事や、後で影響の大きい部分については、その作業の一部を先行着手し、評価してみて、課題やリスクをあぶり出します。
あぶり出された課題やリスクを前提として、作業展開計画を立てていきます。
作業を先行させるには、設計の仕方を変えてみる方法もあります。
実際の試作品をつくって、試してみて、その後、設計資料を、作成する方法です。
例えば、システム開発であれば、先にコア部分のプログラムを作って動かしてみて設計書を、後から作成する。
営業所の開設なら、レンタルオフィスを借りて1ヶ月間テスト運用してみて、ロケーションや顧客の反応を見て、営業所の規模や開設場所を決めるというものです。

プロセス順の開発スタイルの問題点

プロジェクト型の業務の多くは、プロセス順に開発などを進めるスタイルです。
このスタイルは、プロセスが進むに従い、企画や設計された事が具体化され、実行される段階へと進んでいくスタイルです。
それ故、後半に行くほどに設計段階ではわからない、実際にやってみてわかる、様々な問題が噴出してくることがよく見受けられます。
導入、運用段階で、問題だらけで、本格運用の延期や中止になったなどという話はよく聞きます。
経験の無いこと、乏しい事を行うのがプロジェクト業務ですから、実際に経験してみてわかる事がたくさんあるのは当然です。
しかし、後からわかった問題を解決するためには、膨大な時間やお金がかかる事になります。
少しでも、それを未然に察知して、つぶしておく事ができるようになりたいものです。
作業展開計画での課題やリスクの洗い出しでは限界があります。
FMEAやQFDといった課題やリスクを洗い出す手法も有効ですが、ここでは、プロジェクトの開発スタイルを変え、作業展開計画を組み合わせて解決する方法をご紹介します。

機能別開発スタイルで問題・リスクと先出し

プロセス順の開発スタイルを、機能別開発スタイルに変える事で、問題の先出しを行う事ができます。
これは、源流管理スタイル、リーン開発スタイルと言われるものです。
機能毎に、設計、開発、テスト、導入という一連のプロセスの開発を行います。
設計から具体化、実行までを一気に行い、やってみてわかる問題を早い段階に洗い出してしまいます。
その洗い出された問題には、プロジェクト特有の問題や、その機能だけではなく、他の機能に関連する事なども含まれています。
洗い出された問題や実際の経験を踏まえて、残りの機能の課題やリスクを明確にした上で、作業展開計画を立てます。
先の機能の経験から次の機能の問題発生を抑える事ができ、プロジェクトが進行していくごとに問題発生件数が減っていくというのが機能別開発スタイルの特徴です。
このような機能別開発スタイル(リーン開発スタイル)は、プロジェクト型業務の理想型ではありますが、機能毎に開発をするためには、企画段階で機能別にプロジェクトを進める全体設計ができていなければならず、最初から意図して取り組まなければ実現できない方法で、ハードルの高い手法です。
プロセス順の開発と機能別開発を組み合わせたハイブリッド型という方法もあり、もっと簡単に取り入れる事ができます。

  • このエントリーをはてなブックマークに追加

関連記事

ページ上部へ戻る