Structure)の作成である。成果物スコープとプロジェクト・スコープを、もれなく・重複なくカバーするタスク(アクティビティ)をすべて拾い上げる。それらを階層的に構成し、整理番号をつけたものがWBSだ。スケジューリングは、WBSを構成するアクティビティの所要期間を見積り、また、それらアクティビティ間の論理的な着手順序や依存関係を決定して、ロジック・ネットワークに落とし込む(ここは何らかのソフトウェア・ツールを利用することが多い)。その上で、クリティカル・パスを求めると、それがプロジェクト全体の工期となる、という訳である。通常はさらに、クリティカル・パス上の主要な達成点に、「マイルストーン」を設置する。これは後の進捗管理を分かりやすくするための工夫だ。ここまでは教科書的な常識の話で、誰もが知っていることだろう。問題は各アクティビティの所要期間の見積だ。これの精度がいい加減だと、プロジェクトの納期も信頼度が落ちるばかりか、コスト見積の精度もあやしくなる。したがって、過去に類似プロジェクトの経験があれば、当然そこから実績期間のデータを集めてきて、参考にすることになる。作業量の大小に違いはあるだろうから、作業量の基準となる値(BOQ)を比較する必要がある。BOQというのは、たとえば、テスト件数であるとか、コンクリート打設m3だとか、端末設置台数とか、業務プロセスのシナリオ数とか、そのアクティビティの仕事量を代表する指標である。プログラミングなら、ファンクション・ポイントを用いることも多いだろう。過去のアクティビティと現在計画しているアクティビティのBOQの比が2倍なら、所要期間も2倍になるだろう、と一応考える。これでは単純すぎるわけで、実際には投入要員数と生産性で補正して所要期間を計算するわけだ。ところが、この「過去のアクティビティ実績期間」というのがくせ者なのである。いうのも、実はアクティビティの着手時点と完了時点というのは、正確につかむのが案外むずかしいからだ。「90%シンドローム」という言葉を聞いたことがあると思う。「プロジェクトの期間の9割で進捗率は90%に達し、その後また同じ期間をかけてようやく100%に達する」(つまり当初計画の1.8倍の期間がかかる)という、ジョーク混じりの法則である。どんな仕事でも、最後の詰めの部分は効率がわるい。アクティビティの進捗率のグラフを描くと、「Sカーブ」になって最後はかなりなだらかな上昇になる。全体の90%まではすんなり到達するが、最後の10%にずっと時間がかかる理由は、二つある。一つは、「100%地点」が正確に見えていなかった、というケースだ。製品開発の基本設計とか、情報システムの要件定義などの“ソフトな”仕事では、よくある。お目にかかる理由は、仕事も9割を超えると、むしろ「残存問題箇所の修正モード」に入るからだろう。これはソフト的か、力仕事的かにかかわらず、起こりうる。Listとよぶ)を作成し、それをつぶすモードになる。この残件つぶしに、思ったより時間がかかるのだ。「実質的に終わり」の時点と、「公式に終わり」の時点にかなりの開きが出てしまう。期間がとらえにくいもう一つの問題点は、着手時点にある。プロジェクトの上流側の作業が遅れている場合、下流側の担当者は、しばしば「できるところから先に手をつけて」準備作業に入ることが多い。上流側が終わっていないので、下流側で手をつけられる箇所は当然限られている。手をつけては待ちになり、またちょっとやっては待ちになる。して生産性の上がらない期間が最初にできてしまう。TOC理論で言う「学生症候群」で、最初はサボっていて、タスクの締切近くにならないと真剣に作業しない、というケースだってあるだろう。このように、過去の実績期間データというのは、案外そのままは使えないものが多いのだ。それでは、どうするか?ここで使うテクニックが、「中点で測る」方法である。アクティビティのBOQの50%を達成した時点を、マイルストーンとして内部管理用に記録しておく。マイルストーン間の期間を比較の尺度としてつかうのである。期間の半分の時点を記録するのではなく、達成率50%になった時点を記録するのである(いわずもがなと思うが、念のため)。このようにすると、先行して着手したり、あるいは最後のダメ詰めで時間をとられたりした際の影響を受けにくい。Sカーブの傾斜の大きなときに測るわけであり、精度も比較的ぶれない。複数のプロジェクトを比較するときも、50%時点を中心に並べると見やすく、分かりやすい。このためには、作業量見積の基準となるBOQをうまくみつけておく必要がある。人間の標準作業や生産性評価が重要となるのは、このためなのである。23:32はじめまして。22:20退路を断つことです。17:48本当にその通りですね。メッセージを入力してください。