t_wの輪郭

線表による「やべぇ」はプロジェクト要員が少数なら感覚的あるいは定性的で良いのだが、人数が多かったり定量的な説得が必要になるなら、やり方を変える必要がある。

三点見積もりを行い、ベータ分布に基づいて「いつ」「どれだけの確率で」プロジェクトが達成されるかを求めることができる。

このあたりになってくると線表ではなくPERTに属するものになってくる。しかし、フリーのソフトウェアにてPERTを行えるものを寡聞にて知らない。有償ならなにがしかあるだろうが、金が出せないならExcelでなんとかするしか無い。しかしExcelには「数式の汚損がしばしば発生する」「PERT図の自動作図が困難」「図から直接入力できない」といった問題がある。

今日は「そのタスクは後続タスクが無いので急ぎません」という発言が己から出てきて、「線表が効いとるな」となった。

結局アレ（後続タスクがそのタスクの期限を規定する）なのだ。

転居線表2023年を人に見せたら「これ売れるじゃん」って面白がってた。実際、わたしによる線表の作成と管理（とその他諸々の雑用）に対して、お客様から安くない稼働費が支払われていた。C社に対して。本当は線表の作成管理はプロパーがやったほうがいいと思う。

あと、「退去バッファ」のウケが良い。大真面目にバッファを設けてるので、ネタではない。

退去バッファがあることで、以下の利点がある

• 重要であることが自明な退去工程をクリティカルパスとしてGanttProjectが計算してくれる（しょうもない後続作業をクリティカルパスから除外できる）
• バッファ残量で「ヤバさ」がわかる
• 退去期限を超えるとリキダメが発生するので、リキダメ抑止に役立つ

線表による「やべぇ」の自覚は、線表をこねこねすることで生まれるというところもある。線表をこねる間にプロジェクトの計画に関する情報が脳に染み渡り身体化される。

線表を引く良さはやはりこの「やべぇ」を自覚できるところだな。しかもどこが「やべぇ」のかがクリティカルパスでわかる。危機感から作業の密度が上がり、創意工夫が生まれる。「このタスクは本当に必要か？」「タスクの前後関係は妥当か？」を一つ一つ丹念に何度も問うていく。作業量を時系列方向に平準化する。推測を排してバッファを差っ引く。リソースを増やすべく作業を並列化する。プログラムの処理速度を向上させる作業にも似ているかもしれない。

引っ越しの準備もろもろの掌握のために、GanttProjectで線表を引いとくか