なぜWBSを作成しなければならないか

プロジェクトに携わると必ずと言って良いほど「WBSを出して下さい」と言ったり言われたりします。WBSとはWork Breakdown Structureの頭文字をとった頭字語で、プロジェクトを計画する際によく使われるツールですが、多くの人はWBSを作る立場になる前に少なくとも1つ以上のWBSを見たことがあるのではないでしょうか。

ところが、自分がWBSを作る立場になると、WBSの作成は簡単そうに見えて意外と難しいということに気づくケースが多いように思います。少なくとも私はそうでした。

以前にも書いたように、たまたま参画したプロジェクトのPM(プロジェクトマネージャ、プロマネ)が「見える化」をしないタイプだとしたら、おそらくWBSは存在していない(作られていない)でしょう。そういうプロジェクトは概して無計画で、出たとこ勝負であり、ノリ重視であったりします。人生は出たとこ勝負で良いかもしれませんが、プロジェクトとなれば(当人がプロジェクトのオーナーで無い限りは)そういうわけにもいきません。そういう現場が好きな人以外は、そのようなプロジェクトに間違って参画してしまうとそれなりに苦しい時間を過ごすことになります。

「プロジェクトは計画通りにいかない」という人がいます。もちろんそのとおりだと思います。プロジェクトには大なり小なり想定外のイベントは付物で、事故と言ってもいいでしょう。しかし、だからといって計画を立てなくて良いということにはなりません。それは何故でしょうか。

WBSはプロジェクトの完了に必要な要素を全て洗い出したものです。多くの場合、洗い出した項目とガントチャートを組合せてスケジュール表として作成します。(以降、WBSといえばスケジュール表を兼ねているものを指す)だから、WBSがあれば、

  • そもそも何をしなければならないか(全体の規模感)が分かるため、心構えができる。
  • 何をいつから始めれば良いかが分かるため、気付いたら時間切れという事態を避けられる。
  • 各作業の全体の中の位置付けが分かるため、次の作業を意識して取組むことができる。
  • 先々の予定を把握することで、余裕を持って作業に取組むことができる。
  • 結果的に、生み出す成果物の品質が高くなり、プロジェクトの成功確率が高まる。

…と、このようなメリットが期待できるのです。逆にWBSが無ければどうなるでしょうか。

  • 何をしなければならないか「分かったつもり」になっているため、必要な項目が漏れる。
  • 何をいつから始めれば良いか分からないため、項目を思いついた時点で既に時間切れの場合がある。
  • 全体の中の位置付けが分からないため、1つの作業に没頭してしまい、目的と期限を見失う。
  • 先々の予定が分からないので、差し迫ってない項目は放置し、差し迫ってから着手する。
  • そのため、突貫工事で低品質の成果物を生み出し、高稼働でコスト増またはスケジュール遅延となる。

…と、このようなデメリットが想定されるのではないでしょうか。ここでは私の思いつく限りを列挙しましたが、きっと皆さんはそれぞれの状況下でそれぞれのメリット・デメリットを挙げることができるでしょう。突き詰めていくとWBSの有無がプロジェクトの成否だけでなくプロジェクトに関わる人たちに影響をもたらすと言えます。


「見える化」というプロマネの仕事

「プロジェクトマネージャ(PM)の目的は何か」という問いには人によって表現は微妙に異なると思いますが、およそ「成功裏にプロジェクトを完了させること」ということになるでしょう。では「その目的の為にPMが行う作業(=手段)は何か」という問いにはどのように答えるでしょうか。もちろん、これも人によって、特に業種・業態やプロジェクトの特性によって表現は異なると思いますが、私が一言で答えを問われた場合には「見える化(=可視化)」と答えます。

もちろん、PMの仕事というのは究極的には「成功裏にプロジェクトを完了させるために、あらゆる手を尽くす」ということになるのですが、「あらゆる手」に共通するポイントというのが「見える化」なのではないかと考えています。とはいえ「見える化」して終わりという意味ではなく、「見える化」するところから始まるという意味です。念のため。

プロジェクト管理手法というのは数多あるのですが、どれもが管理すべき対象を見えるようにして状況を把握し、様々な手を打つための判断の手助けをしてくれるものだと私は理解しています。例えば、計画の見える化、タスクの見える化、スコープの見える化、スケジュールの見える化、コストの見える化、品質の見える化、リソースの見える化、リスクの見える化、コミュニケーションの見える化…などです。

なので、プロジェクトをマネジメントする立場に就いた場合には、いかなる形式であろうと、これらを「見える化」する、つまり具体的なドキュメントに落とし込むかツールに入力・表示するというところから始める必要があるということです。こういった作業は面倒くさいものですが、「見える化」する作業を省略していったい何をマネジメントするというのでしょうか。

よく、頭の中にはあるから(アウトプットしなくても)大丈夫だということを主張する人も見かけますが、実際にアウトプットしてみると意外と出来ないということが分かると思います。脳内に記憶できる情報量も限られているそうですので、全てを同時に、かつ瞬時に把握し合理的な判断を下すというのはどう考えても無理があります。まして、プロジェクトでは日々想定外の問題が発生し、常に合理的な判断を求められるのです。そのためにいちいち思い出しながら進めるというのは効率が悪すぎます。それにもしそのうちのいくつかを思い出さなかったとしたら、それはどういう結果を招くでしょうか。

ここまでプロジェクトマネジメントのイメージで書いてきたつもりですが、改めて考えてみると一般的な組織のマネジメントにも当てはまるのではないかと思っています。もちろん経営者は判断するのが仕事ですが、瞬時に的確な判断を行うために「見える化」が必要なんだと理解しています。


限られたリソースで最大の効果をもたらすトリアージ

もう随分前になりますが、このブログの中で「デスマーチ」そして「パーフェクトソフトウェア」という2つの著作をご紹介したことがあります。両者に共通するポイントはリソースは有限であるため全てのバグを取り除くことができないという点と、その有限のリソースの中でバグをどのように分類し優先順位を付けて対応するかという点であろうと思います。いずれもソフトウェア開発に関する著作ですので「バグ」が対象にはなっているのですが、もっと広くプロジェクトマネジメントという観点に引き上げてみると、バグだけではなくバグ対応を含めたToDoの捌き方のアドバイスということになります。

前者の「デスマーチ」ではトリアージという戦争時における負傷者救護の優先順位づけのアイデア(これは今の災害時の救急医療現場でも活用されているようです!)を紹介していますが、後者の「パーフェクトソフトウェア」ではトリアージを実践するための具体的なバグの分類方法を提案しています。当時のブログ記事の中でも私なりにアレンジした分類方法をご紹介しましたが、今回はより進んだ分類方法をご紹介します。

システム開発では、開発中のシステムに対する仕様の変更や追加の要求が出されることが良くあります。要求を出す方としては当然のことながらすべてに対応してもらいたいと思うものですが、要求を受ける方としても当然のことながらプロジェクトとして実施している場合は納期も予算もありますので(これがリソースが有限であるということの意味ですが)出された要求の全てに応えることができないという状況に陥ることがあります。

そんな時、要求を一覧化して対応するかしないかを選別しても良いのですが、もっと明確な基準があると判断にも迷わないですし、なされた判断も客観的で納得感が出てくると思いませんか。例えば、次のような分類を考えてみましょう。

レベル0:そもそも技術的に不可能であり、対応できない要求
レベル1:対応できなければリリース延期またはプロジェクトを中止する要求
レベル2:リリース時に無くても良いが、対応しないと業務に支障のある要求
レベル3:可能なら対応したいが、対応しなくても止むを得ない要求

これらの分類をするだけでも客観的な評価となり得ますが、次のような設問フローを作るとより客観的で論理的な判断を下すことが可能になり説得力が増します。

トリアージの判定フロー

(1) 要求が技術的に不可能であるか。
[Yes⇒レベル0/No⇒(2)へ]
(2) 対応されなければリリース延期するか。
[Yes⇒レベル1/No⇒(3)へ]
(3) 対応されなければ業務に支障があるか。
[Yes⇒レベル2/No⇒レベル3]

判断をするときには設問に答えていくだけで客観的な優先付けを行うことができ、レベル0は除外して優先度の高いものから残されたリソースの範囲で対応できるものを決定していくことになります。これも救急医療現場で使われるABCDEアプローチのようなもので、判断を急ぐときにはシンプルで強力なツールとなります。分類の数が多くなっても設問を増やすだけで良く、状況に応じてアレンジもしやすいです。


東京都福祉保健局によるトリアージの説明

CCPM勉強会に参加してきました

東京タワーが近くに見える会場でした

本日8日、毎月開催されている私的なIT勉強会に久しぶりに参加してきました。今回のテーマはCCPM。今年に入ってから改めて興味を持つようになり、弊社としても求められるクライアントに対してはサポートできるように日々勉強しております。3月にはグローバル・オプティマム社の主催するCCPMセミナーにも参加いたしました。

今回の進行役はY2研究所の吉田裕美子さん。吉田さんもこの2年くらいCCPMを勉強しておられるとのことで、「最短で達成する 全体最適のプロジェクトマネジメント」という書籍をテキストにして発表されました。私も事前に一読して参加しましたが、当たり前のことを当たり前にやるのがCCPMの極意。でもそれがすごく難しい。本書に限らずCCPMやTOCに関する書籍は何冊か読んでいるのですが、いつも読んで納得するもののなかなか実践するには至らないというのが正直なところです。実は今回の参加者の間でも質疑や議論が盛んに行われましたが、どうやって導入するかというところが一番の関心事であるように感じました。

もちろん、まずはCCPMの考え方を理解して、導入するチームや組織にも理解をしていただく必要があるのですが、大上段に構えてしまうと自分がチームのメンバーだったら引いてしまいますよね。なのでできるだけCCPMと言わずに、そのエッセンスを取り入れることができないかというのが私のテーマであります。

実はこっそり既に試しているものもあり、例えば進捗度の指標としてパーセンテージを使うのではなく残日数で行うというものは、周囲の方々には少しずつお話しして納得していただいているところです。進捗何パーセントっていかにも管理してますって聞こえますけど、例えば昨日50%で今日60%という報告を聞いて、その差の10%分が1日の進捗度合いとして妥当なものかを判断するのはとても困難だと思うのです。ところが、残日数での報告にすると昨日から今日にかけての差というのは1日でなければおかしい。誤魔化し様がないのです。こういったことから少しずつ始められたらいいなと思っています。


PMBOKとは、そしてPMPとは何なのか

前日に引き続きJSDGの研修会に参加です。今日は大阪に移動し、午後から関西ミニ研修会が開催されました。会場は此花区民ホール会議室。案内が来たときは此花区ってどこだ?と思って調べたら意外に梅田に近い。JSDGの大阪在住メンバーでも此花区へ訪れることはめったにないとのことでした。

さて、講演の内容ですが、『プロジェクトマネジメント~PMBOK、PMPって何者~』というテーマでお話がありました。一時期流行ったPMBOKとPMP。今でもまだやってるの?という素朴な疑問を持っていましたが、講演者ならびにPMP保持者によれば、かつては大規模プロジェクトに参画するにはPMPが必要だったこともあるようです。それに数年で改訂されて、今は第4版。今回はその第4版をベースに面白おかしく具体例を交えながら全体を一通り説明してくださいました。

PMBOKはプロジェクトマネジメントの手法だという誤解もありますが、平たく言うとPMBOKというのは手法も含めたプロジェクトマネジメントの工程ならびに成果物に関する知識を整理したもの、ということができるでしょう。そしてPMPとはPMBOKについての知識を問う試験を合格した人に与えられる資格です。PMBOKが手法だという誤解というのは、PMBOKが守るべき規準として取り扱われる間違いが起こっているということです。そうではなくて知識を整理したものに過ぎないということなんですね。

じゃあ意味ないじゃないかというとそうでもない。今回の講演を通して、PMPを取得するかは別として、PMBOKは一通り理解をしておくべきだなと感じました。小規模なプロジェクトまでにこれを適用できるかというとそれはやり方次第になるのでしょうが、それでも知っているのと知らないのとではプロジェクトの質が変わってくるだろうと思います。もちろん知っていればうまく行くということでもありません。ただ、完全な自己流よりは良いだろうなという感じです。その辺のさじ加減は難しいですね。

講演後、近くの居酒屋で懇親会。お店は講演者チョイスとのことで、見るからに大丈夫なのか?と思わせる外観。…講演者はそういうツッコミを期待していたそうなのですが、私を含めて皆さん普通に中に入って行きました。名古屋の某店に比べたら…。でもお店のおばちゃんの仕切り様はさすがといったところ。お魚もお酒もおいしく頂きました。