「締め切りを守ること」の大切さ

今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力（ばりき）のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「⁠常に締め切りを守れるように仕事をすること」である。

チームで仕事をする場合、どうしてもお互いが担当するタスク（＝作業）の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタスクは「必ず期日以内に仕上げる」という強い意志を持って仕事に取り組む必要がある。

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

ラストスパートが諸悪の根源

大半のエンジニアが、スケジューリング（開発工数の見積り）の段階から大きな勘違いをしてプロジェクトに取りかかっている。締め切りという言葉への典型的な誤った考え方は次のようなものだ。

• ① 見積りはあくまで見積りでしかなく、予定通りに開発が進むとは限らない
• ② 締め切り目前に徹夜でも何でもしてがんばることが大切
• ③ それでもどうしても締め切りに間に合わなかった場合は、その段階でスケジュールを変更してもらうしかない

たとえばあるソフトウェアを作ることをこのような意識のエンジニアに依頼したとする。するとそのエンジニアは、今までの経験から「3ヵ月ぐらいでできると思います」と言う（漠然とした見積り⁠）⁠。

多くの場合、その手のエンジニアはプロジェクトを甘く見て、最初の2ヵ月ぐらいはのんびりと過ごす。残り1ヵ月ぐらいになって「お尻に火がついた」状態になって頑張るのだが、あわてて作るためにスパゲッティコードになってしまう。残り2週間でそこそこ動き始めるが、まだまだ機能は不十分だし、バグもたくさんある。最後の1週間でバグの修正に取りかかるが、最後の最後になってアーキテクチャ上の欠陥が見つかる。しかし、いまさら後戻りはできないので、バグを回避するためのその場しのぎのコードを埋め込むが、そんなことをしているとますますコードが汚くなっていく。

最後は徹夜もするが、寝不足でミスが続き、結局バグが取れずに締め切りの日になって「申しわけありません、できませんでした」と言ってくる。「⁠じゃあどのくらいで完成するの」と聞くと、「⁠あと2週間あれば大丈夫だと思います」と言う（根拠はない⁠）⁠。しかし、2週間ではアーキテクチャの変更もままならず、パッチにパッチを当てて、目も当てられないようなコードになっていく。結局2週間努力しても問題は解決せず、「⁠根本的な問題の解決のためにアーキテクチャの変更をするので、2ヵ月ください」と言う。しかたがないのでスケジュールの変更を認めると、時間に余裕があるので、最初の1ヵ月はのんびりと流してしまう。最後の1ヵ月でラストスパートをかけようとするが、再び同じような状況に陥り、最後は徹夜の連続。再び寝不足のためにコードが汚くなり、バグが多発。結局、新しく設定した締め切りも逃してしまう…。

これでは「プロの仕事」とは言えない。その根底には「締め切り＝努力目標」とう考えがあり、「⁠目標に向けて精一杯努力をすることが大切」という体育会的な姿勢がある。そして最もいけないのが、「⁠最初はのんびりしていても最後に頑張ればなんとかなる⁠」⁠、という「楽観的なラストパート思考」である。

「ラストスパート」なもの作りの一番の欠点は、最後の最後まで、そのタスクの本当の難易度がわからないという点にある。どんなタスクでも、「⁠やってみないとわからない」部分はどうしてもある。個々のタスクに「本気で取り組む」タイミングを遅らせれば遅らせるほど、「⁠予想外に時間がかかってしまってほかの人に迷惑をかける」可能性が高くなる。

まずは「締め切りは絶対に守るもの」と考える

大切なことは、スケジューリングの段階から「締め切りは絶対に守るもの」という前提で臨むことである。すると、スケジューリングの段階からずっと真剣にならざるを得なくなる。

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

まず①だが、「⁠締め切りは絶対に守るもの」ということを常に念頭に置いておけば、「⁠3ヵ月でリリース可能なところまで持っていく」みたいなあいまいなものではなく、「⁠この機能の実装には1週間」「⁠このUIの追加には3日」という、より明確に定義された細分化されたタスクリストになる。

当然だが、プロジェクトの最初の段階では見積りすら不可能なタスクもあるものだが、その手のものを「今までの経験をもとにざっくりと」見積もるのはとても危険である。そういう場合は、まずは3日とか1週間の「調査期間」をスケジュールしてもらい、その期間に実際にプロトタイプを作りながら「タスクの難易度」を測定するのだ。その間に「これなら作れる」という感覚が得られたのなら見積りを出すし、それでも無理ならば「相当難しいタスク」と覚悟したほうがよい。

その場合、この手の「難易度の予想が難しい」タスクをほかのタスクより先にやることがとても大切である。それが「相当難しいタスク」であるかどうかを見極め、全体のスケジュールを見直したり、機能変更をするのは早ければ早いほど良い。

スタートダッシュで一気に作り上げる

次に大切なのは、②のすべてのタスクを「スタートダッシュ」で行うこと。「⁠締め切りに迫られていないと頑張れない」のは多くの人々に共通する弱さだが、先に述べたように、ソフトウェアのプロジェクトがうまくいかなくなる原因の9割は、締め切り間際の「ラストスパート」が原因だ。大切なことは、2週間でやるべきタスクだったらその半分の時間の1週間で終わらせるつもりで、プロジェクトの当初からスタートダッシュをかけることだ。

とにかくこの時期に集中して仕事をして、可能な限りのリスクを排除する。アーキテクチャの変更が必要ならこの時期にする。書きはじめたコードが汚くなってしまったら、もう一度ゼロから書き直す。健康だけには気をつけながら、全力疾走で仕事をする。

そして、実際に半分の時間が過ぎた段階で、タスクがどのくらい完了しているかをできるだけ客観的に判断する。8割がた終わっていればスケジュール通りに進んでいると考えてよい。6割ぐらいしか終わっていなかったらかなりの危機感を持つべき。半分の時間が過ぎた段階で、万が一完成度が6割未満だった場合は、「⁠締め切りまでに完成できない可能性がある」とその段階で判断し、プロジェクトマネージャに状況を説明して、スケジュールの見直しをしてもらう（③⁠）⁠。締め切り直前ではなく、締め切りよりもはるか前に締め切りに間に合わせられるかどうかを見極めることがものすごく大切だ。この段階で「まだ半分しか時間を使っていないから大丈夫」と思うのは大間違い。全力疾走で半分の期間を使って、まだ「ほぼ完成」の状態に持っていけていなかったら、かなりの確率で締め切りには間に合わないと判断すべきである。

そして予定通りに進んでいれば（つまり半分の時間に8割がた完成していれば⁠）⁠、あとはコードを見直したり、テストプログラムを書いたり、次のタスクの準備をしながら余裕を持って仕事をする。この段階での自分の仕事は、「⁠バリバリコードを書くこと」ではなく「書いたコードの完成度を高めること」にあることを強く意識して仕事をする。

時間に余裕があるときにこそ全力疾走する、という働き方

ここに私が書いた仕事術は、ひとことで言えば「時間に余裕があるときにこそ全力疾走で仕事し、締め切りが近づいたら流す」という働き方である。仕事に対する姿勢を根本的に変えなければならないので簡単な話ではないが、確実に効果があることは保証するのでぜひとも試みていただきたい。特に学生の人たちには勉強にもこのやり方を応用すること強くお勧めする。授業の前の予習に8割の時間を割き、残りの2割の時間を授業直後の復習に使う。そして、試験前は一夜漬けなどけっしてせずに、体を十分に休めてフレッシュな頭で試験に臨む。そんなやり方で勉強すれば、必ず成績は向上する。