締め切りは絶対に守るもの
「スケジューリング」についてすばらしい記事があったので、感想をまとめてみる。
締め切りが守れないのは、スケジュールの立て方・仕事の進め方が間違っているから
大半のエンジニアが，スケジューリング（開発工数の見積り）の段階から大きな勘違いをしてプロジェクトに取りかかっている。締め切りという言葉への典型的な誤った考え方は次のようなものだ。
① 見積りはあくまで見積りでしかなく，予定通りに開発が進むとは限らない
② 締め切り目前に徹夜でも何でもしてがんばることが大切
③ それでもどうしても締め切りに間に合わなかった場合は，その段階でスケジュールを変更してもらうしかない
耳が痛いです。
まずスケジュールの立て方では①の考え方が間違い。そうですね「見積りはあくまで見積りでしかない」思ってます。だいたい超過します。そしてプロジェクトの反省会でPMが「なぜ見積もりの精度があがらないのか」とぼやくことになります。
そして仕事の進め方では②の「ラストスパート」が諸悪の根源だそうです。（もうラストスパートできないくらい疲弊しているデスマも多いですが...）
スケジューリングの段階からずっと真剣に
それではどうすればいいのか。
①「ほぼ確実にできるタスク」だけを抽出して，まずはそれのスケジューリングをする。予測不能なものについては，正直に「現時点では見積りができない」と宣言し，必要ならば「見積りをするための調査期間」をもらう
② 各タスクはすべてスタートダッシュでこなし，与えられた時間の半分の時間で「ほぼ完成」まで持っていく
③ 万が一，半分の時間で「ほぼ完成」まで持っていけなかった場合，これを「危機的な状況」と認識してスケジュールの見直しを交渉する
①が工数見積もりの精度をあげる答えそのものでした。なぜこれまで見積もり工数より時間がかかっていたかというと、「ほぼ確実にできるタスク」と「予測不能なもの」、それぞれが抽出されてない。つまりタスクが分解しきれてなかった...。
当然だが，プロジェクトの最初の段階では見積りすら不可能なタスクもあるものだが，その手のものを「今までの経験をもとにざっくりと」見積もるのはとても危険である。そういう場合は，まずは3日とか1週間の「調査期間」をスケジュールしてもらい，その期間に実際にプロトタイプを作りながら「タスクの難易度」を測定するのだ。その間に「これなら作れる」という感覚が得られたのなら見積りを出すし，それでも無理ならば「相当難しいタスク」と覚悟したほうがよい。
その場合，この手の「難易度の予想が難しい」タスクをほかのタスクより先にやることがとても大切である。それが「相当難しいタスク」であるかどうかを見極め，全体のスケジュールを見直したり，機能変更をするのは早ければ早いほど良い。
チームで実装する場合は、プロジェクト全体の技術調査というのは必ずするものだし、まあ時間もとってもらえてプロトタイプは作るので大丈夫なのですが、自分だけのときは見切り発車になりがちですね...他のことで手一杯であとで調べようと思ってたり...最悪もれてて実装するときに発狂するとか...。
時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す
ここに私が書いた仕事術は，ひとことで言えば「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方である。仕事に対する姿勢を根本的に変えなければならないので簡単な話ではないが，確実に効果があることは保証するのでぜひとも試みていただきたい。
「ラストスパート型」と「スタートダッシュ型」の図がすばらしいです。「ラストスパート型」は締め切り間際にならないとリスクが見えません。「スタートダッシュ型」はダッシュ後の早い段階でリスクが見えてきます。
リスクが見えれば対処はできるんですよ！これからはスタートダッシュ型で仕事しようと思います。
