働き方改革によって、短すぎる納期や多すぎる仕事量など見直しが進んだ職場も多いと思いますが、不都合な真実が１つあります。
最初から無理のない納期であっても「納期通りに終わらない」仕事が結構あることです。
経験的に多いのは、着手の遅れと終盤でのトラブルですが、この２つは多くの職場で共通ではないでしょうか。
そんな課題を抱えていた私があるプロジェクトの前に読んで大変参考になった本がありました。
納期通りに終わらせるための納期意識とペース配分に関する考え方が役立ちました。
ワークスタイルイノベーションのヒントになれば幸いです。
参考図書
「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」（中島聡）
これはMicrosoft社でWindows95開発の中心的役割を果たした日本人プログラマー中島聡さんの仕事作法の話です。1990年代、難航していたMicrosoftの次世代OS戦略を大きく左右したのが日本から渡ったプログラマーだったことを知っている人は案外少ないかもしれません。
Appleにまつわる才能豊かな人物伝はいくつも本が出ていて花がある一方、Microsoftの方はビルゲイツ以外にあまり面白い話がない印象でしたが最近は出てくるようになり「Tools And Weapons」なども圧巻でした（別の機会に触れたいと思います）。
因みに、昔「闘うプログラマー」（WindowsNTを作った元DECの技術者デビッドカトラーの話）を読んで感銘を受けてそれは私が転職するときの背中を押したものの１つでした。
中嶋氏は期限通りにプログラムを完成させる、使えるものにする、ことを重視して達成してきました。
その実績があったから、ビルゲイツ氏は、開発遅延でいつ使いものになるかわからない状況に陥っていた次世代OSプロジェクトをキャンセルして中嶋氏率いるWindows95プロジェクトの商品化を優先する決断をしています。（この辺のエピソードもドラマティックでとても面白かったです。）
中島氏は計画した日程通りに完成させられない多くのプログラマーたちのできない理由、期限に完成する彼の仕事との違いを明快に指摘し、出来るようにする方法論を以下のように述べています。
ペース配分の考え方
納期通りに終わらせるポイントを一言でいえば
「最初の２割の期間で８割方の目処を付け、残り８割の期間は完成度を上げることに使え」
「前半の進め方が緩く、ラストスパートに頼る習慣」が諸悪の根源
ということです。
そう言われても相手もあることだし決して簡単ではないですが、お互いその相手を伺いながら予定調和で終盤にペースアップしていく習慣が定着してしまっているとも言えます。
パレートの法則を仕事の期間と内容に当てはめて、重要な終盤にリソースを多く割り当てようとすると、必然的に期間先頭の密度を上げるべきであることがわかります。
これをロケットスタートとスラックという言葉で表現されています。
ロケットスタートとスラックによって得られるメリットは
- リスクを測定できる
- 目に見える形のもの（プロトタイプ）を素早く作ることができる
- 誤差に対応できる
その逆を自分たちの状況に当てはめてみたら、まさにその通りで、胸が痛いところでした。
- リスクを測定できていない → 終盤にトラブルが起きる
- 目に見える形になっていない → 後で齟齬が発覚し手戻りする
- 誤差に対応できない → ブラッシュアップの時間が足りない
ポイント
・ロケットスタート
最初に最大の集中力を注いで着手する。2割の時間が過ぎた時点で8割方終わっていればスケジュール通り終わると考えて良いが、全力疾走で2割の期間を使ってその状態にならないのなら、かなりの確率で締め切りには間に合わない。（中島氏の経験則）
残りの時間で大事なのは全力で仕事を続けることではなく仕事の完成度を高めること。すなわち、時間に余裕があるときにこそ全力疾走で仕事し、締め切りが近づいたら流す。すると早い段階でリスクがわかり見える形のものができアクシデントに対応できる。
ロケットスタートでノリノリの時に徹夜するのはありだが、煮詰まったときの徹夜はしてはいけない。（スラック参照）・ラストスパート
仕事が終わらなくなる原因の9割は締め切り間際のラストスパートが原因である。 漫画の世界では主人公は追い込まれてピンチになり最大の力を出して逆転する。現実ではそのようなドラマチックな逆転劇は必要ない。 どんな仕事でもやってみないとわからない部分が必ずあり後半にアクシデントが発生する。 ラストスパート指向の一番の問題点は最後の最後までそのタスクの本当の難易度がわからないことだ。・スラック
アクシデントは後半に発生する。だから後半にスラック＝あそび（調整用の余裕）をもつことが非常に重要である。
締め切りが迫ると人は必ず焦り生産性が上がらない。そこにアクシデントが生じる。睡眠不足やスラックがない状態が慢性的に続くと人は生産効率が落ちていき、もっと効率的な仕事のやり方があったとしてもそれに気づかずがむしゃらに仕事にまい進するトンネリング状態（間違った方向であることも気づかず暗闇のトンネルを行進するかのような状態）になる。
トンネリングにはまると処理能力が落ちているうえに出口の光が見えていないので疲弊していく。期限に仕事は終わらない。・早く見通すこと
仕事が終わらない人は後半の応用問題を甘く見ている。前半の基本問題しか手を付けていない段階でこれなら簡単に終わると勘違いをしている。応用問題に取り掛からないうちは、まだ仕事がどのくらいで終わるか判断できない。
決まった期日内に終わらせることが重要な仕事の場合は、まず複雑な応用問題の見通しを付けなければいけない。・完璧主義の弊害
自分の中の100点をめざずあまりいつまでもループしている人は本来なら終わる仕事も終わらない。全ての仕事は必ずやり直しになる。最初の狙いどおりに行く方がまれ。
どうせやり直しになるのだから細かいことはさておき、まず全体像を描いてしまったほうがいい。粗削りでも早く全体像が見えるようにして細かいことは後から直す。プロトタイプを最速でつくるということ。・納期と生産性（日米でとくに違いが顕著な点）
納期の明確でない仕事は終わらない。
アメリカで「なるはや」という指示はありえないし部下もそういう受け取りはしない。納期を確認する。どんな仕事にも必ず締め切りが設けられ、部下は締め切りを守るために全力で仕事を終わらせる。締め切りがあるから効率化を考え、その結果生産性が上がる。
日本の職場にはそうした緊張感が欠けている。あいまいな仕事でモチベーションは上がらない。参考エピソード
ビルゲイツが部下にパーティーの花の用意を命じたが花屋のトラブルで届かなかったことがあった。この時ゲイツはその部下に激怒したという。
花さえ用意できれば裏で昼寝していてもよい。彼が命じられた任務はパーティーに花を用意することであり、花屋に注文をすることではない。必要なのは10時に待ち合わせたら10時前につく電車に乗ることではなくその時間に待ち合わせの場所に着くことだ。NECがPC98を出したのをみて中島氏は当時PCで使える初めてのCADソフトCANDYを作った。完成までに6か月かかったが実は最初の2週間でなんちゃってCANDYを作っていた。
ソフトの企画書を見せても理解してくれないがプロトタイプで早くフィードバックがもらえた。企画を形にする前に、そもそもどういうものか想像できない、予算はあるのか、商品になる保証はあるのか、などと言われて仕事を中断することになるのはもったいない話だ。
新製品のアイディアを思いつくことは、世の中を丁寧に見ている人には決して難しくない。難しいのは、そのアイディアを目に見えて触れることのできる、実際に動くものにしてしまう部分である。何かの実践のために知識が必要な場合は、知識はやりながら覚えていくのが一番。単なる備えで身に着けるのは難しい。明確な目的意識があればできるようになるもの。例えば英語なら、やるべきことは英語を勉強することではなく、英語を使って何かをすることだ。
「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」（中島聡）から抜粋し要約を作成しました。
実際やってみて
日程遅延を避けるためにマイルストーンを早めに設定する、増やす等の対策をしても、前倒しどころか、計画と実行のギャップが埋まらないことが多いのが実情でした。SaaSのようなアジャイルにできないメーカーのソフト開発で長年苦しんでいたところに、ペース配分を思い切って変える考え方が刺さり、次はこれで行こうと思いました。
折よく私がプレイングマネージャーを務める新規開発案件の立ち上げタイミングだったため、メンバーにこれを説き、自分の責任部分から「ロケットスタートとスラック」方式で進めました。
仕様資料は期日に揃えるのではなく、最初の２割の期間に８割バージョンを一度作ることにし、もうそんな時期でしたっけ？といぶかる設計担当者やデザイナーにも少々無理を言って協力してもらいました。
頑張ったのですがやってみるとなかなか厳しくて３割の時点で進捗７割の感じでした。
しかし案の定そこから隠れていた課題が出てき始めて失速し、６割の時点で進捗８割、9割の時点で進捗９割と追いつかれて少し焦りましたが、意外と守れることが少なかった最初のマイルストーンをクリアできました。ちょっとした爽快感でした。
次フェーズも同様に進め、途中で納期を前倒す必要が発生してしまったときも、苦しいならがスラックを切り崩すことで何とか対応できてしまいました。終盤のイレギュラーもそこそこありましたが、この本を読んでいなかったら間に合わなかっただろうと思われる製品リリースの達成でした。
（この時の案件が別投稿にある「RAW現像嫌いが開発したRAW現像ソフト」です。）
このやり方は継続的に繰り返せるかどうかが大事だと感じました。
実際問題として複数のプロジェクトに関わっている人は、１つがラストスパート状態になっているときに、もう一方でロケットスタートすることは困難です。また、前のプロジェクトが難航して終わらず、次のプロジェクトにオーバーラップしてしまうと、次のプロジェクトでロケットスタートが難しくなります。夜更かしと早起きが両立しない様に、周囲のプロジェクトも揃ってラストスパートサイクルからロケットスタートサイクルに変えて行かないと、すぐ引き戻す力が働いてしまいます。
中島氏は複数の仕事が重なっても日々の仕事に8:2をブレークダウンして実行できると書かれていますが、同じように出来る人は少ないのではないかと思います。
最初は一進一退でも成功体験を増やすことで定着していけると良いのではないでしょうか。
ちなみに、リスク要因のある技術要件を抜き出して製品開発日程よりも先行開発するフロントローディングがありますが、難しさの認識にはいろいろあって、メーカーではどうしても定量化できる性能要件への感度は高く、ユーザーインタフェースを適切に作り込む難しさのようなソフト面は（実は時間と手数がかかるにもかかわらず）鈍感な傾向があります。こうした背景にも適合できる手法に思いました。
昨今は様々な業種が情報サービス業としての機能をもちソフト開発に関わる人が増えていますし、一般的なオフィスワークの多くもこの考え方は活かせそうです。
ロケットスタートとスラック、ぜひ取り入れて働き方改革していきましょう。
以上
