クロスイデアblog

ITコーディネータの吉田聖書（よしだみふみ）です。

前回の記事では、
大規模なプロジェクトのWBSを作成する際に
いきなり全体を書くと煩雑になり時間もかかるので
まずは工程とその成果物を洗い出してから
トップレベルのプロセスマッピングを
行う手順について書きました。

今回はその続きです。

Read the rest of this entry »

ITコーディネータの吉田聖書（よしだみふみ）です。

以前、プロセスマッピングを使ったWBSの作り方について書きました。
このテーマで実際に手を動かすワークショップも開催しました。

基本的な理屈はこれで充分なのですが、
比較的大規模なプロジェクトに
適用しようとすると項目が多くなるため
プロセスマップが描きにくくなりますし、
時間もかかってしまいます。
それを短時間で作成する方法をご紹介します。

Read the rest of this entry »

これまでWBSの必要性やたびたび議論される話題を取り上げましたが、今回は、前回述べた「プロセス・マッピング」を使ったWBSの作成方法をご紹介します。

私が初めての現場で最初にWBSを作成する場合には、全ての成果物あるいは作業を洗い出すためにプロセス・マップというものをまず作成します。プロセス・マップを作ることをプロセス・マッピングと呼びます。私がネットで調べた限りではプロセス・マップについて決まりきった型は無いように見えました。少なくとも業務プロセスを図示して見える化したものを指していると思ってもらえば良いです。

よく見かける業務フロー図もそのひとつです。定常業務の業務改善ではプロセス・マッピングにより現状の業務を全て書き出して問題点を見つけるというアプローチを取ります。しかし、プロジェクト業務の場合は（似たようなプロジェクトを繰り返し実施するというケースはあるでしょうが）基本的には初めてやることなのでゼロベースで作成することになります。

ゼロベースと言ってもプロジェクトのゴールは決まっているわけですから、ゴールをまず明記します。例えば何かのサービス開発だったら「カットオーバー（あるいはゴーライブ）」というのがそれに当たりますね。決まりきった型は無いと述べましたが、私が使うときには独自にルールを設定しています。ルールとはいえ記法というよりは考え方のルールです。より良い考え方があればどんどん改良して構いません。尚、記法についてはDFD（データフロー図）の記法を拝借しています。

1. まず、プロジェクトの開始（スタート）と終了（ゴール）を決める。実はゴールが明確であればスタートは何でも良い。「キックオフ」のようなものを書いても良いし、単に「スタート」でも構わない。外部のトリガーで始まるのであればそれを書く。
2. 作業を楕円、成果物を長方形で表し、作業と成果物を矢印で結んでいく。この時、ゴールから逆に辿って、成果物を生み出すために必要な作業、作業のために必要な成果物…という風に。
3. 作業には最低１つずつ入力になる成果物と出力になる成果物とが矢印で結ばれている必要がある。成果物を生まない作業は無いし、どの作業にも使われない成果物は無い。
4. プロジェクトチームの外部に依頼する作業、または外部から受取る成果物については、その外部の主体を長方形で表し、プロジェクトチームと外部主体との境界線を破線で引く。
5. 締切のある成果物にはその日付を長方形の外に書く。作業の担当者を楕円の外に書く。日数のかかる作業についてはその所要日数を楕円の外に書く。

プロセス・マップの例

このようにするとDFDとPERT図を組合わせたような図が出来上がると思います。参考までに過去に私が作成したプロセス・マップを説明用に改変したものを掲載します。これは私があるプロジェクトに途中から参画した時に、メンバーにヒアリングしながらホワイトボードに描いたものです。実際にはここに担当者や期日などが書き込まれたりしましたが、これによりプロジェクトメンバーの意識を合わせることができ、期日に間に合うか見えていなかった案件を無事に完成させることができました。

尚、この後このプロセス・マップを工程別あるいはマイルストーン別に区切って整理し、ガントチャートを作成します。本当に小規模なプロジェクトであれば（先ほどのサンプル・プロジェクトもそうでしたが）ガントチャートに書き換えずにこのまま進捗管理をしてしまうことも可能です。余談ですが、定常業務にこれを適用し、作図したものをさらに担当者別（あるいは部門別・会社別）にスイムレーン式に整理すると業務フロー図になります。

WBS作成の流儀は様々あるでしょうが、まだ作り方がよく分からないという方は是非参考にして、自分なりの作り方を確立していただければと思います。

前回に引き続き、WBSを作成する際に議論される問いについて考えます。

次に「項目は作業を分解したものか、あるいは成果物を分解したものか」という問いがあります。これは粒度に比べたらあまり話題に上がって来ない印象があって、私が作成するものも含め、いろんなWBSを見ていると同じレベルの項目の中に作業と成果物が混在しているものを見かけます。が、これはよくよく考えるとおかしな話です。そもそも作業は動詞であり、成果物は名詞だからです。これは単に文法的に語尾がどうなっているかというレベルの話ではなくて、作業は手段ないし過程であり、成果物は目的ないし結果です。だから基本的には作業と成果物が同列に並ぶということは無いのです。

プロジェクトというのはある目的の達成のために計画されるものです。従って、最終的に欲しいのは結果の方であって過程ではありません。とはいえ、成果物の名称だけ書かれていても、それを見た人が具体的な作業をイメージできなくて困るというケースもあるでしょう。だからつい作業を書いてしまったり、必要に迫られて作業を書くというのも止むを得ない話だと思います。そういう場合のひとつの方法として、「成果物を生み出す作業」を表記するやり方があります。

例えば、「調査」という項目があったとします。これは作業です。よって成果物が表現されていません。こういう時には「調査報告書の作成」という項目にしてしまいます。こうすることで成果物がイメージできるようになるし、調査報告書を作成するための「調査」の作業そのものもそこに包含されることになります。「調査」活動そのものが「調査報告書」という目的のための活動と明確に位置づけることができるわけです。

そうはいってもやはり成果物の作成という名目の作業だけで全ての項目を定義するのに違和感を覚えるという意見もあるかもしれません。そもそも成果物は作業の結果得られるものであって独立したものではありません。それにある作業の成果物（アウトプット）が別の作業のインプットになるものです。なので最初はWBSの形式に囚われずプロセス・マッピングを実施するようにしています。プロセス・マッピングとは一般的には業務プロセス定義の局面で用いられる手法のようですが、業務を構成するプロセスとプロセスの関連を業務を定義する目的で図示したものです。（そのバリエーションのひとつに業務フロー図があります。）通常は定常業務に対して適用するものですが、それをプロジェクト業務にも応用します。

プロセス・マッピングについての詳細は別の機会に譲りますが、このツールにより作業と成果物をネット状に繋げて全ての項目を洗い出すということをします。定義したプロセスに抜け漏れが無いことが担保できれば、WBS上に記載する項目が作業であろうと成果物であろうとあまり関係ありません。プロセス定義があればスケジュール表としては冗長な項目も慣れてくれば省略して記載しても構いません。要は「言われた通りに作るもの」ではなく「管理する人が管理しやすく、かつ抜け漏れがないもの」であれば良いのです。

5年前「炎上プロジェクトから学ぶセミナー」というタイトルのプロマネ向けの講習を友人の会社と共同で開催し、それからだいぶ経ちました。それ以来私は、参加者のアンケートなどを基に「より効果の出るテーマは何か」と考えてきました。その結論の一つが「WBSの作成」です。前回の記事で「なぜWBSを作成しなければならないか」について述べましたが、WBSは簡単そうに見えるためか、きちんと作り方を教わることも無いまま作らされることが多いように感じています。そこで、私なりのWBSの作り方を書き留めておきたいと思います。あくまでも私のやり方ですのでこれが正しいやり方というわけではありませんが、必要としている方にとって少しでも参考になればと思っております。

さて、WBSの書き方・作り方の前に、「誰がWBSを作るべきか」という問いがあります。「WBSを作れ」と言われてもその必要性を認識していなかったり、仮に必要性を認識していたとしても（以前お伝えしたように）「見える化」しないタイプの人は全く作らないか、なんとか誰かに作らせて少なくとも自分は作らないで済まそうとするのではないでしょうか。

しかし、今のところ私の考えでは、複数の会社が関わるならそれぞれの会社で、複数の部門が関わるならそれぞれの部門で作成すべきです。もっと分かりやすく言えば、全体で1つではなく、管理の単位（便宜的にチームと呼びます。きっと組織の文化によって呼称は異なるでしょう。）それぞれに1つずつのWBSがあるべきです。（もちろん社内の小さなプロジェクトなら1つあれば充分ですね。）そして、チームリーダーの責任でWBSを作るのが良いと考えます。何故ならWBSは、自分のチームが作らなければならない、あるいは実施しなければならないことをまさに網羅的に表現したものだからです。

だから、自分たちの作るべき成果物、やるべき項目を漏れなく列挙し、実作業の責任者としてそれをスケジュール化します。もちろん他のチームと連携しなければならない項目についてはマイルストーンの摺り合わせも必要ですが、基本的には他のチームの作業はそのチームが管理すべきことと考えます。だから他チームの作業そのものを項目化するのではなく、作業に係る他チームとのやり取りを項目化して、期日を両者で合意すると良いでしょう。

次に「どの粒度まで表現すべきか」という問いがあります。これは私も良く訊かれますし、他の人が訊かれているのを耳にしたこともあります。それだけ答えを探してもなかなか見つからない問いなのだと思います。中にはあらゆる作業、あらゆる成果物を細目に落とすべきといったアドバイスもネット上で見かけます。私もこれといった答えを持っているわけではないのですが、これだけは言えます。それは「管理する人が管理しやすい粒度で」ということです。項目が大まか過ぎて日々の状況把握に耐えられないようではいけないし、逆に細か過ぎて全体が俯瞰できなくなったりメンテナンスの負荷ばかり高くなっても本末転倒だからです。最初から完璧なWBSは作れなくても、慣れてくればその辺りのサジ加減は会得できると思います。

また、対象のプロジェクトや、そのプロジェクトを実施する組織によってその管理のやり方も異なってくるでしょうから、画一的な「正解」に凝り固まらない方が良いのではないでしょうか。WBSをきれいに作ることが目的ではないし、まして管理することが目的でもないのです。まったく初めての取組みであって勝手が分からないようなケースは本当に検討事項の一つ一つまで細かくしないと危ないかもしれないし、類似のプロジェクトを経験していればそこまで細かいと冗長さを感じることもあるでしょう。そこはWBSを利用する本来の目的に合わせて柔軟に粒度を調節できることが望ましいと考えています。

より具体的な作り方に関する問いについては次回に続きます。