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