前回の記事「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ で、世間ではそもそも「WBS」とか「Activity」という概念のレベルで、誤解や混乱があると書いた。 たとえば、WBS=「ガントチャートの線表に引いた線の集合」だ、と理解している人達を、よく見かける。ためしにネットで、「WBS スケジュール」の2キーワードで検索をかけてみると、よくわかる。上位の検索結果に、こういう説明が出てきたりする: 「WBSとはプロジェクトのスケジュール管理に使われるツールの1つ。作業工程を分解して示したものと、それをスケジュールにしたものを合わせてWBSと呼ぶことが多い」 この説明など、残念ながら逆立ちしている。WBSはスケジュール管理用のツールでもないし、もちろんガントチャートの線も含まない。WBS(Work Breakdown Structure)とは、プロジェクトのスコープを階層的に分解したものを指す。スコープを単位作業の集合として構成し管理番号を付番したもので、つまりスコープ管理用のツールなのだ。まずWBS作成が先にあって、最後にガントチャートや予算表ができる訳なのだから、逆立ちなのである。(なお、たまたまGoogle検索で上位にヒットしたので、上記サイトをやり玉にあげさせていただいたが、全体としては平易で良い記事が多いと思う。だからこそ、こうした誤解が残念なのだ) ついでにいうと、タスクとアクティビティという用語も、しばしば混乱して使われているようだ。プロジェクトのWBSを構成する要素作業は、「タスク」とよぶのか、「アクティビティ」とよぶべきなのか? 世界で最も広く普及しているPM分野の標準書「PMBOK Guide」では、一貫して、プロジェクトの要素作業を”Activity"とよんでいる。これが、世界的な共通語である。ただ、わたしの知る限り、日本のIT業界では、プロジェクトの下位要素を「タスク」とよぶ人が非常に多い。まあ、一種の業界慣習(?)なのだろうか。むろん習慣に従うのは自由だが、外の人と話すときには、自分たちが方言を使っていることを意識しておいた方が良い。 ちなみにPMBOK Guideでは、タスクという用語は、"Daily task”の形で出てくる。日々の細かな宿題、課業である。すなわちTaskとは、To Doリストとか課題管理表で追いかけるべき、細かな作業を指す。 しかし、Activityは違う。これはプロジェクトを構成する単位作業で、ある意味、プロジェクトの縮小版であり似姿だ。Activityは、通常、完了条件を持つ。つまり、アウトプットとしての成果物がある。あるいは、ある状態になったら完了していい、との条件がある。 たとえば、要件定義というActivityは、『要件定義書』という成果物を生み出したら完了する。あるいは、テストだったら、試験完了の状態になれば終わる(まあ普通はテスト報告書も作成するけれど)。つまりActivityというのは、プロジェクトと同じく一過性の仕事なのである。じゃあ、週次ミーティングは何なのか? WBSには入れないのか? との疑問が浮かぶかもしれない。それはDaily taskです、というのが答えだ。 Activityには、必要なインプットがある。インプットは、部品・材料といったモノの場合もあるし、情報の場合もある。さらにActivityには、それを遂行するためのリソース(経営資源)も割り当てなければならない。つまり担当者であり、機械やツールであり、作業場所である。こうしたものは作業中は占有するが、終われば開放されて、別の仕事に使える。リソースは、Activityで消費されてしまうインプットとは性質が異なる。 そして、各Activityはその内容・種類に応じて、作業量(BoQ=Bill of Quantity)を推算しなければならない。これがコストやスケジュールのベースとなるからだ。 プロジェクトのWBSを構成する全Activityについて、そのインプット、アウトプット(完了条件)、リソース、そして作業量(BoQ)をまとめた表を、Activitlyリストとか、WBS Dictionaryとよぶ。たとえていうならば、WBSとは、日本全国を50都道府県に分解し、さらに各県を市町村に分割し、マネジメントしやすい自治体の単位に表示した、お仕事の地図のようなものである。この地図帳には、WBS Dictionaryという統計表がついている。これが、プロジェクト・マネジメント計画の土台なのだ。単なるスケジュール管理用のツールではないことが、お分かりいただけたと思う。 さて、「ダイレクト・ガントチャート方式」の問題点に話を戻そう。いうまでもなく、ガントチャートは、チームメンバーや顧客・外部協力会社とのコミュニケーション上、必須の道具である。PERT/CPMの計算に使うActivity Network線図など、誰も見たくないだろうし、見てもよく分かるまい。わたしの勤務先でも、PERT/CPMの計算の後、必ずガントチャートを作成して、プロジェクト・チームに配布する。それを元に、キーパーソン同士による「総合工程会議」を開いてレビュー・議論し、完成するやり方をとっている。 だが、頭の中にWBSもActivityリストもないまま、いきなりガントチャートの線表を書き始める「ダイレクト・ガントチャート」方式は、全然別物だ。アウトプットとしての線表は共通だが、背後にきちんとしたスケジューリングのロジックがないため、これをスケジュール管理用に使うのは、けっこう危険である。まあ「ロジック・ガントチャート」方式と「ダイレクト・ガントチャート」方式は、アウトプットの線表だけ見ると似ているので、両者の違いを知らない人が多いのかもしれない。 では、プロジェクトのロジックとは何か? 狭義には、Activity間の依存関係やスケジュール上の制約条件を示したものを指す。たとえば、あるActivityのアウトプットが、他のActivityのインプットやリソースになる場合、両者の間に先行→後続という、依存関係が生じる(Finish to Startの略でFS関係とよぶ)。あるいは、ペンキ塗装のように、あるActivityが開始してから一定日数後に、別のActivityを開始できることがある。これをStart to Startの依存関係とよぶ(略してSS)。 こうしたロジックは、Activity Networkを組むベースとなるだけではない。あるActivityが予定から変化(遅れた・早く完了した)場合に、他のActivityにどう影響するかの予測を、可能にする。 なお、スケジュール・ロジックは広い意味では、Activityの所要期間の推定根拠(何で決まるか)も含む。つまり、作業量(BoQ)と、投入リソース量と、生産性である。所要期間は、以下の式で計算する。 所要期間=作業量÷(生産性×投入リソース量) リソースが人間の場合は、所要期間=作業量÷(生産性×人数) になる。作業量は、ソフトウェア開発の場合なら、たとえばFunction Point(FP)だとか画面帳票数だとかLOC(コード行数)などのパラメータで測ることが多い。 かくして、WBSを構成する各Activityについて、作業量(BoQ)と投入リソース量と生産性から、所要期間が決まる。もっとも中には外部調達機器の納期のように、外から与えられる所要期間も無論ある。 そして、ロジックを元にActivity Networkを組んで、はじめてクリティカル・パスがわかり、プロジェクト全体工期が計算できるのである。全体工期がわかって、はじめてプロマネの工数を積むことができる。だから、計画立案は必ず、スコープ→WBS作成→スケジュール計画→コスト見積の順番になる。 ところが、ダイレクト・ガントチャート方式は、途中を中抜きして、いきなりスコープからガントチャートを作ってしまう。家を建てるのに、土台や柱の骨組み抜きで、壁を立て屋根を乗せているようなものだ。途中で倒れなかったら、まあ幸運である。 ダイレクト・ガントチャート方式をとる人には、しばしばもう一つの問題がつきまとう。それは、ガントチャート上に、フロートを表示しないことである。フロートとは、そのアクティビティがどれだけ遅れると、プロジェクト全体の納期に影響を与え始めるかを表す数値だ。無論、クリティカル・パス上のアクティビティのフロート日数はゼロである。 たとえば4月開始で、実質の所要期間は3ヶ月のActivityがあるとしよう。ただし、並行する別の作業があるために、8月末までに完成すればいい。このとき、本来ならば3ヶ月間の実線と、2ヶ月分の余裕日数(フロート)を表す点線を、横に並べて引くべきだ。 だが4月から8月末まで、5ヶ月分、バーの実線を引いてしまうケースが多いのである。ロジックをよく理解していない人は、フロートの概念があいまいだからだ。こうすると、そのActivityの正味の所要期間が見えなくなってしまう。 こういう線をあちこち引いたガントチャートを見て、さて、プロジェクトの最長の経路(見かけ上の最長経路)をクリティカル・パスだと判断したら、当然おかしなことになる。クリティカル・パスとは、フロートを差し引いた正味の経路長が最大のものを指す。プロジェクトの全体工期を制約する最長の経路である。プロマネは、納期を守るために、クリティカル・パスが遅れないよう、注意を集中すべきだ。だが、フロートが見えないと、間違ったAcitivityに注意を向けたりしかねない。 ちなみに、プロジェクト・マネジメントという特殊なActivityについても、注意を向けておきたい。これをWBSにいれていない大企業を、見かけたことがある。思わず、「プロジェクト・マネジメントはしないんですか」、と口走ってしまった(苦笑)。もちろん、プロジェクト・マネジメントには確実に工数がかかるので、見積に必要である。プロマネだけでなく、書類事務などが多い場合は、アシスタントもつける必要もある。だからWBSに無いのはおかしい。 ただしプロジェクト・マネジメントというActivityは、固有の成果物と、固有の所要時間を持たない点が特殊だ。その期間は、プロジェクトのクリティカル・パスの長さに依存する。 だからガントチャートでは、省略されることも多い。うっかり線を引くと、それがクリティカル・パスみたいに見えてしまう。だが、WBSの一部である。このように、WBSとガントチャートは、一致しない点がある。 以上、ダイレクト・ガントチャート方式を批判してきたが、じつはわたし自身、直接ガントチャートを引くことがある。それは、身近で数人が関わる程度で、期間も数週間程度のごく小規模なプロジェクト的業務の場合である。役割分担を決め、やる事とタイミングを決めたら、あとは走りながら考える。必要に応じて、微調整していく。その程度で十分な仕事が、確かにある。え? 線表は何で引くかって? もちろんExcelでだ(笑) 無論、きちんとWBSを作りプロジェクト計画を立てるべき仕事もある。当たり前だが、規模によって、マネジメントのやり方は変えなければならない。3人のお客様を呼ぶパーティーと、300人のお客様を呼ぶパーティーでは、段取りから何から全て違うのだ。あるいは、先ほどの家を建てるアナロジーでいうと、犬小屋なら地面にすぐ壁を立て屋根を乗せても大丈夫だ。だが普通の木造家屋では、そうはいかない。そして10階建てのビルなったら、そもそも材料も構造も変える必要がある。 つまり、規模とマネジメント手法の相関が大事なのである。少しでも複雑化した仕事、規模の大きなプロジェクトでは、それに見合うやり方を選ばなければならない。なぜなら、小さなスケールの仕事で「分かっている」と思ったやり方が、通用しなくなるからだ。本格的なやり方を知った上で、小さな場合には適時省略する、のは構わない。だが、本式のやり方を知らないのでは危うい。 現在のPMBOK GuideやPMP試験の問題点は、ここにある。プロジェクトの規模や複雑性によって、適切なマネジメントのやり方を選ぶべきだ、という事をハイライトしていない。たとえ規模は変わらなくても、海外プロジェクトは、パートナーやステークホルダーと契約関係が、複雑性を増大させる。なのに国内と同じ簡略化した進め方が通用すると思ってはいけない。規模が大きくなったり、プロジェクト構造が複雑化したら、より精度の高いプロジェクト計画が必要なのだ。 ちなみに、上に挙げた図の中で、点線で囲まれた部分は、わたしの主催するプロジェクト&プログラム・アナリシス研究部会が開発中の、初級者向け研修コースのカバー範囲である。わたし達の研修プログラムの最大の特徴、他との違いは、PMにおける「システムズ・アプローチ」の涵養にある。受講者には最初に手を動かして、ロジック・ネットワークを作成してもらう。それを通じて、「プロジェクトとはActivityからなるシステムであり、そこには独特のロジックと動力学がある」という感覚を得てもらうことがポイントだ。ここが身につかないと、どこを簡略化すべきか、分からない。 Excelで工程表を書くべきではない、というのは、こうしたロジックが磨かれないからだ。それは、本当はツールの問題ではない。MS ProjectでもPrimaveraでも、やろうと思えば「ダイレクト・ガントチャート方式」は可能だ。まずいのは、ツールではない。ツールを使う条件、使える範囲を知らずに、いつでも使うことだ。 知らないことは、別に恥ではない。知ろうとしないことが、恥なのである。 <関連エントリ> →「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ (2017-12-02) →「仕事の最小単位ーーアクティビティの構造を学ぶ」 http://brevis.exblog.jp/13992804/ (2011-01-16)
by Tomoichi_Sato
| 2017-12-10 06:21
| プロジェクト・マネジメント
|
Comments(4)
Commented
by
あえて言う
at 2017-12-10 23:46
x
あえて言う。それで景気が良くなるのかね?管理して、仕事がはかどって、そしたら楽になるのかね?他人には勝てるだろうさ。それが喜びにはなるだろうさ。仕事がうまくいくことは楽しいさ。管理して、誰が喜ぶのさ?上司を喜ばせたいのかい?褒められるとうれしいからか?管理がうまくいって何になる?
あなた程、理路整然と物が書けて頭の良い者が、世の中を良くするもっと他の方法は思いつかないのかい?勝ってどうする?仕事なんて際限はない。ところで管理の仕事はさせてもらえるのかね?管理されるだけじゃないのかね?管理って、誰得だよ。管理だけして、部下を責めるだけで僕ちゃん管理してますってふんぞり返るだけ。WBSうまくやれて、カッコは良いよね、快感だよね。それが喜びなんだよな。楽しいか?
0
Commented
by
ふじた
at 2017-12-12 11:05
x
Commented
by
通りすがり
at 2017-12-15 10:41
x
Commented
by
アレックス ロゴ
at 2018-02-14 15:29
x
あえて言うさんは悪い管理にしか当たったことがないんでしょうね。管理といえば下の者を締めつけて上にはいいことしか言わないような管理方法しかできないマネージャーがやっぱり多いんですかね?だからあえて言うさんは管理=悪と思いこんで批判しているのでしょう。でもどんな物事もそうであるようにいい管理と悪い管理があるとおもうんですよ。そもそも大規模プロジェクトで管理というものをしなかったらうまくいくいかない以前にプロジェクト崩壊ですよ。
私は管理というものは部下に働きやすい環境を作ってやってパフォーマンスを向上させてあげることだと思っています。 例えば高速道路であっちこっちで工事をやってて車線規制してたら車は本来の巡航速度で走れませんよね。渋滞しだしたら巡航どころか走ることさえままなりませんよね。管理とは上司やマネージャーがこういう障害を極力調整して環境を整えてやったら後は進捗を確認してあげればいいだけだと私は理解しています。(どうやって調整するのか?例えば「その工事は本当にやらなければならない工事か?」「交通量が多い時間帯を避けて工事できるか?」「バイパスを作れないか?」等々)そして進捗が遅れているのを感知したらまたその原因を特定して調整してやると。 まあ現実の職場では部下のマルチタスクにさえ無頓着な上司が多々いることも事実ですが。
|
検索
カテゴリ
全体 時間管理術 サプライチェーン プロジェクト・マネジメント 工場計画論 リスク・マネジメント ビジネス 考えるヒント ITって、何? 書評 映画評・音楽評 English articles 思考とモデリング 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書」 「時間管理術 」(日経文庫) 「BOM/部品表入門 (図解でわかる生産の実務)」 「リスク確率に基づくプロジェクト・マネジメントの研究」 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||