締め切りは絶対に守るもの→その為に巻きでやれ？？

えーと、昨日あたりからかな。ブックマークでホットなエントリとして下の記事があがってきた。
第2回「締め切りは絶対に守るもの」と考えると世界が変わる：Software is Beautiful｜gihyo.jp … 技術評論社
「締め切りは絶対に守るもの」。うん。その通り。

「そんなこと言ったって，ソフトウェアの開発過程において予想不可能な事態に陥ることはよくあることで，締め切りを絶対に守ることなんて無理」と思う人も多いだろうが，スケジュールの立て方・仕事の進め方の段階から締め切りを守ることの大切さをきちんと認識して働けば，「常に締め切りを守り続けて」仕事をすることは十分に可能である。

これもまた然り。で、記事ではそれを実現するための方法が示されるんだけど、それがどうもちょっと？？？な感じだったので日記を書いてみることにした。

最初にそもそもなぜ締め切りが守れないのか？原因はどこにあるのかこの人は説明している。曰く「ラストスパートが諸悪の根源」だ。この節ではダメな製品が生み出されるネガティブなスパイラルについて説明がされていて、うんうん、ハマるとこんな事になるよなと、そこはわかる。ひとつの実例としてリアリティがある話だった。

じゃあ、どうすれば事態は改善されるのかというと、次の３点を守ればいい、という。

* ①「ほぼ確実にできるタスク」だけを抽出して，まずはそれのスケジューリングをする。予測不能なものについては，正直に「現時点では見積りができない」と宣言し，必要ならば「見積りをするための調査期間」をもらう
* ② 各タスクはすべてスタートダッシュでこなし，与えられた時間の半分の時間で「ほぼ完成」まで持っていく
* ③ 万が一，半分の時間で「ほぼ完成」まで持っていけなかった場合，これを「危機的な状況」と認識してスケジュールの見直しを交渉する

１はいい。これは私もまったく同感。規模がブレる要素は分離して、未確定な部分を確定させてブレを小さくすることで、全体のスケジュール内に、自分の作業が収まるかどうかを早い段階で見切る。で、やばそうなら早く警報鳴らして期間の見直しなりなんなりに持っていけばいい。ここはちょっと３にもかかる。概ねな感じでは３もいい。細かい点ではちょっと納得がいかないけど。

で、どうも私が納得できないのは２だ。「スタートダッシュ」。言い換えると巻き。前倒し。この人は一口で言えば巻きでやれば締め切りは守れると言っているのだ。

この後、なぜこの考えなのかを補強する材料として、遅れる仕事というのはラストスパートに期待しているからだと説明する。そこに期待するから序盤に出遅れる。この序盤の出遅れを補正する為に、序盤から巻いていけと説いている。一見もっともらしい感じなんだけども、ちょっと雑な考えだと思う。遅れた人みんなが、こんな考えだったわけじゃないよね？　あまりに飛躍が過ぎるんじゃないかと思う。

締め切りが守れない。そんな事になる原因は、私の経験から言えば、計画がないからだ。締め切りを守るには、私ならこんな提案をする。

期日を目標としてどうやって完成まで組み上げていくかプロセスを考える。
それを最低でも週単位の作業計画に落として（個人の仕事だったら０．５週単位ぐらいがいいかも）、実績を毎週測定して実績とのかい離を評価する。
かい離が閾値（たとえば３％とか）を超えたら原因を分析して補正行動をとる。

評価の最小期間は、全体の期間を５０〜８０分割ぐらいしたものがいいかもね。個人的感覚だけども。

全体としてやってることに大差はないように見えるけど、背景にある考えは違う。件の記事は「最初に巻いておけば大丈夫！」と言っているんだけど、巻けばいいわけじゃない。巻きでやってもダメな場合があって、その為に３が安全装置としてあるわけだけど、粗すぎるわけです。やるべきことは盲目的な巻きじゃない。目標を達成する為の具体的な計画と、評価、必要に応じた補正です。

とか思いました！

ちょい追記。
元記事もところどころで目標をより明確にするんだ！という話も書いていて、納得のいく部分も多い。でも結論が巻きというのがどうも解せない。なんでこうなっちゃったんだろう？　「計画」っていう言葉で説明したくなかったんだろうか？