線表を引く良さはやはりこの「やべぇ」を自覚できるところだな。しかもどこが「やべぇ」のかがクリティカルパスでわかる。危機感から作業の密度が上がり、創意工夫が生まれる。「このタスクは本当に必要か？」「タスクの前後関係は妥当か？」を一つ一つ丹念に何度も問うていく。作業量を時系列方向に平準化する。推測を排してバッファを差っ引く。リソースを増やすべく作業を並列化する。プログラムの処理速度を向上させる作業にも似ているかもしれない。
引っ越し線表2023年9月9日その２
2023/9/9 21:17:00
引っ越し線表2023年9月10日
2023/9/10 12:58:00
あれ
2023/9/10 11:54:00
あれ
2023/9/9 22:38:00
あれ
2023/9/9 22:19:00
平日は日中に仕事あるし、アクティビティの多重度高いし、これ回らんでしょ。
いや、「待ち」が多いからまだ行けるか……？
あれ
2023/9/9 21:36:00
あれ
2023/9/9 21:33:00
無限に負荷を受容できるという前提で計画建てるとアクティビティの多重度がマシマシになって死ぬんだけど、「リソースの負荷を勘案してスケジューリングしたい」とかいいだすと生産スケジューラーとかが必要になりそう
あれ
2023/9/9 21:20:00
全体に対してバッファが50%無いのがだるい。
できればバッファを2/3程度まで取りたい。