プロジェクト・スケジューリング立案作業の第一歩は、いうまでもなくWBS(Work Breakdown Structure)の作成である。成果物スコープとプロジェクト・スコープを、もれなく・重複なくカバーするタスク(アクティビティ)をすべて拾い上げる。それらを階層的に構成し、整理番号をつけたものがWBSだ。スケジューリングは、WBSを構成するアクティビティの所要期間を見積り、また、それらアクティビティ間の論理的な着手順序や依存関係を決定して、ロジック・ネットワークに落とし込む(ここは何らかのソフトウェア・ツールを利用することが多い)。その上で、クリティカル・パスを求めると、それがプロジェクト全体の工期となる、という訳である。
通常はさらに、クリティカル・パス上の主要な達成点に、「マイルストーン」を設置する。これは後の進捗管理を分かりやすくするための工夫だ。ここまでは教科書的な常識の話で、誰もが知っていることだろう。 さて、問題は各アクティビティの所要期間の見積だ。これの精度がいい加減だと、プロジェクトの納期も信頼度が落ちるばかりか、コスト見積の精度もあやしくなる。したがって、過去に類似プロジェクトの経験があれば、当然そこから実績期間のデータを集めてきて、参考にすることになる。むろん作業量の大小に違いはあるだろうから、作業量の基準となる値(BOQ)を比較する必要がある。BOQというのは、たとえば、テスト件数であるとか、コンクリート打設m3だとか、端末設置台数とか、業務プロセスのシナリオ数とか、そのアクティビティの仕事量を代表する指標である。プログラミングなら、ファンクション・ポイントを用いることも多いだろう。 過去のアクティビティと現在計画しているアクティビティのBOQの比が2倍なら、所要期間も2倍になるだろう、と一応考える。ただし、これでは単純すぎるわけで、実際には投入要員数と生産性で補正して所要期間を計算するわけだ。 ところが、この「過去のアクティビティ実績期間」というのがくせ者なのである。というのも、実はアクティビティの着手時点と完了時点というのは、正確につかむのが案外むずかしいからだ。たとえば、「90%シンドローム」という言葉を聞いたことがあると思う。「プロジェクトの期間の9割で進捗率は90%に達し、その後また同じ期間をかけてようやく100%に達する」(つまり当初計画の1.8倍の期間がかかる)という、ジョーク混じりの法則である。どんな仕事でも、最後の詰めの部分は効率がわるい。だから、アクティビティの進捗率のグラフを描くと、「Sカーブ」になって最後はかなりなだらかな上昇になる。 全体の90%まではすんなり到達するが、最後の10%にずっと時間がかかる理由は、二つある。一つは、「100%地点」が正確に見えていなかった、というケースだ。製品開発の基本設計とか、情報システムの要件定義などの“ソフトな”仕事では、よくある。しかし、もっとしばしばお目にかかる理由は、仕事も9割を超えると、むしろ「残存問題箇所の修正モード」に入るからだろう。これはソフト的か、力仕事的かにかかわらず、起こりうる。ほぼ終わりが見えた時点で、ふつうは残件リスト(英語ではPunch Listとよぶ)を作成し、それをつぶすモードになる。この残件つぶしに、思ったより時間がかかるのだ。だから、「実質的に終わり」の時点と、「公式に終わり」の時点にかなりの開きが出てしまう。 期間がとらえにくいもう一つの問題点は、着手時点にある。プロジェクトの上流側の作業が遅れている場合、下流側の担当者は、しばしば「できるところから先に手をつけて」準備作業に入ることが多い。上流側が終わっていないので、下流側で手をつけられる箇所は当然限られている。だから、チョロッと手をつけては待ちになり、またちょっとやっては待ちになる。こうして生産性の上がらない期間が最初にできてしまう。あるいは、TOC理論で言う「学生症候群」で、最初はサボっていて、タスクの締切近くにならないと真剣に作業しない、というケースだってあるだろう。 このように、過去の実績期間データというのは、案外そのままは使えないものが多いのだ。それでは、どうするか? ここで使うテクニックが、「中点で測る」方法である。アクティビティのBOQの50%を達成した時点を、マイルストーンとして内部管理用に記録しておく。そして、マイルストーン間の期間を比較の尺度としてつかうのである。むろん、期間の半分の時点を記録するのではなく、達成率50%になった時点を記録するのである(いわずもがなと思うが、念のため)。 このようにすると、先行して着手したり、あるいは最後のダメ詰めで時間をとられたりした際の影響を受けにくい。いわばSカーブの傾斜の大きなときに測るわけであり、精度も比較的ぶれない。複数のプロジェクトを比較するときも、50%時点を中心に並べると見やすく、分かりやすい。 無論、このためには、作業量見積の基準となるBOQをうまくみつけておく必要がある。人間の標準作業や生産性評価が重要となるのは、このためなのである。
by Tomoichi_Sato
| 2009-02-06 23:29
| B3 プロジェクト・スケジューリング
|
Comments(0)
|
検索
カテゴリ
全体 A 生産マネジメントとSCM A1 生産マネジメント全般 A2 生産計画と生産スケジューリング A3 在庫・調達計画 A4 コスト・品質・安全 A5 BOM(部品表) A6 サプライチェーン B プロジェクト・マネジメント(PM) B1 プロジェクト・マネジメント全般 B2 スコープ・WBS・プロジェクト組織 B3 プロジェクト・スケジューリング B4 プロジェクト・コストと見積 B5 プロジェクトの価値とリスク B6 プログラム・PMO・ガバナンス C システムとしての工場 C1 工場計画論 C2 スマート工場論 D 情報システムのマネジメント D1 製造業のITシステム D2 ITアーキテクチャ・データ活用技術 D3 ITって、何? E ビジネス・マネジメントと管理技術 E1 マネジメントの技術論 E2 設計のマネジメント E3 組織・経営・戦略論 E4 ビジネスのソフト・スキル E5 時間管理術 E6 メンタルと働き方のマネジメント F 考えるヒント F1 思考とモデリングの技法 F2 社会・言語・文化 G 書評 H English articles 未分類 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書 「時間管理術 「BOM/部品表入門 (図解でわかる生産の実務) 「リスク確率に基づくプロジェクト・マネジメントの研究 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
2026年 04月 2026年 03月 2026年 02月 2026年 01月 2025年 12月 2025年 11月 2025年 10月 2025年 09月 2025年 08月 2025年 07月 more... ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||