６月１日発売の拙著『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』からの引用です。
◇ ◇ ◇
スマホアプリが アップデートを繰り返す理由
「仕事のスピードを追求したら質が落ちてしまう。それじゃダメだ」
そう思われている方もいると思います。たしかに速さを求めると質は落ちます。大抵の仕事がそうであるように、スピードと質はトレードオフ（片方を取るともう一方は取れない）です。質の悪いものを出さないようにじっくり時間をかけて、ときには徹夜で頑張る人もいるでしょう。
けれども質を追求した結果、締め切りに間に合わないような仕事の仕方をしていては本末転倒です。締め切りに間に合うことが明らかな状況であれば、質を高めるために時間を使うのは間違っていません。問題なのは、まだ仕事が終わる見通しが立ってもいないのに、質を高めるためにあれこれ工夫を凝らそうとすることです。
みなさんが普段使っているスマートフォンのアプリを例に挙げて考えてみましょう。アプリは一度配信が開始されても、その後幾度もアップデートを繰り返します。新しいアップデートの通知が何件もたまっていく光景を誰でも一度は見たことがあるはずです。
あのアップデートはなぜ何回も繰り返し行われているのでしょうか？ 答えは、配信が開始された段階では100％の出来ではなかったからです。
「未完成品を売っているのか！」
そう思われたでしょうか？ しかし想像してみてください。最初から100％の出来のものを作るなんて、可能でしょうか？ 大抵の仕事は、終わったときは満足していたとしても、時間が経つと修正したくなるものではないでしょうか？
あなたの仕事だってそういうことがあったはずです。あのミーティングの日、話が終わった直後はなかなかいい仕事をしたと思った。でも翌日、ミーティングの内容を報告書にまとめている最中に「あれ、これで大丈夫かな......」と不安になってしまうのです。ほかにもあのプレゼンの前日、リハーサルが終わったときには「これでいける！」と思ったことでしょう。けれどもプレゼン当日、たくさんの人の前で発表している最中にどんどん不安になっていきます。
仕事とはそういうものです。どんなに頑張って100％のものを作っても、振り返ればそれは100％ではなく 90 ％や 80 ％のものに見えてしまうのです。言い換えれば、100％のものは、そんなに簡単に作れるものではないのです。だから世の中のアプリ開発者は、配信後も長い時間をかけてアップデートを繰り返し、少しでもいいものを提供できるように努力しているのです。
つまり最初から100％の仕事をしようとしても、ほぼ間違いなく徒労に終わるわけです。なぜなら後から再チェックすると、直すべき箇所が次々に見つかっていくからです。
もちろん、仕事のクオリティを上げるために時間を費やすのは間違ったことではありません。適当な仕事を繰り返していては上司からの評価も下がります。しかし時間を費やすあまり締め切りギリギリになったり、あるいは締め切りを破ってしまったりしては上司からの評価はもっと下がります。
クオリティが低くて怒られることよりも、締め切りを守れずに「時間を守れない人だ」という評価をされることを恐れてください。
3500個のバグがあっても、 世界は変わる
「兵は拙速（せっそく）を尊（たっと）ぶ」という言葉があります。これは兵法書『孫子』から派生した言葉だと言われています（ただ、それを否定する説もあり、何の書物が正統な起源なのかは詳しくわかっていません）。
この言葉は、一般には「拙（つたな）い戦法でも素早く進軍したほうが戦いに勝つ」という意味で浸透しています。転じて、「仕事は最初のうちに迅速に終わらせると良い」という意味にもなっています。
私はマイクロソフトでWindows95の開発をしていました。マイクロソフトでは仕事ごとに必ず締め切りがあり、なおかつ製品（ Windows95 ）の発売予定日も決定していたので、決められた仕事は必ず期限内に終わらせる必要がありました。当時どのような仕事の仕方をしていたのかは3章でお話ししますが、ここではとにかくスピードが求められていたということだけ覚えておいてください。
私はWindows95を予定どおりに発売するために、全力で仕事をしました。その結果、きちんと1995年8月 24 日にグローバル版が発売されました。
しかし発売当時、 Windows95には約3500個のバグが残っていました。私たちはそれを知っていましたが、そのまま発売することになりました。
もちろんバグは修正することができます。だから先ほど紹介したように、スマホアプリの開発者はいつもバグの修正に奮闘しているわけです。けれどもそのバグの数は、大規模なプロジェクトの場合、ある臨界点に達するともうそれ以上減らないということがプログラマーの世界では知られています。なぜなら、あるバグを直すとその副作用でほかのところでバグが発生する可能性があるからです。つまりソフトウェアのバグというのは、完全に0にするのがとても難しいのです。
それゆえプログラマーたちは、100点じゃなくてもいいので 90 点や 80 点のプログラム を必ず納期に提出することが求められています。「兵は拙速を尊ぶ」という言葉は仕事にもまさに当てはまるのです。
Windows95はそういう理由から、3500個のバグを残したまま製品化されました。といっても、深刻なバグはもちろんちゃんと修正してあります。たとえば保存したはずのファイルが勝手に消えるといったバグを残してしまっては、使い物になりません。だからそういったものはちゃんと検証して除去しています。
ただ、ユーザーが通常の使用をする中では発生しないような細かいバグは修正しませんでした。たとえば一般のユーザーが絶対に知らないような特殊なコマンドを入力すると画面が消えてしまうなどです。そういったものまで完璧に除去しようとすると、無限に時間がかかります。それでは発売予定に間に合いません。
それでもご存じのように、 Windows95は世界に大きなインパクトを与えました。恐らくWindows95は、細かいプログラムの知識を持っている専門家にとってはたいへんな手抜き作に見えたことでしょう。しかし大事なのは、一般のお客さんにとってどれだけいいものを素早く提供できるかです。バグの修正は発売後にもできますから、そこは許容範囲を見極め、割り切ってしまうべきです。
すべての仕事は、必ずやり直しになる
Windows95がどのようにして生まれたのかは、3章でもう少し詳しくお話ししますが、少し先取りして重要なキーワードをお伝えします。
このように多少のバグを無視して、とりあえず大枠を作ったものをプロトタイプ（試作品）といいます。これはプログラムの話に限らず一般的な仕事においても応用できる、より抽象的な概念であると理解してください。
会社の企画を任されたときにプロトタイプを作ると、全体のイメージが固まります。イメージが固まっていると上司もプロジェクトの進行を理解しやすいので、企画が通りやすくなります。また、何より自分自身がプロジェクトを進行するときに、仕事がやりやすくなります。
逆に、プロトタイプを作らないとこういうことになります。
以前職場で、別の部署の上司がプログラムを作っていました。といっても彼はプログラム自体を作っていたのではなく、詳細な設計図を作っていたのです。とても時間をかけて丁寧に作っていました。そしてそれをプログラマーに渡して、実際に作ってもらうのです。しかしプログラムというのは実際に作ってみてからが本番というところがあります。設計図上ではうまくいくはずなのに、実際に動かしてみるとうまくいかないということがしばしばあるのです。
結局プログラムはうまく動作しませんでした。しかしプログラムを作った人は、依頼主に文句を言うことはできません。「この設計ではできません」と申し出るのが難しいということは、みなさんもよくおわかりかと思います。そういうわけで、未完成な出来の悪いプログラムが納品されます。プログラマー自身も出来が悪いということを知っていながら納時間を品するしかないのです。完成品を受け取った依頼主の上司は「これじゃダメだ」ということで設計図を描き直します。そして再びプログラマーに依頼します。
こういうことを何回も繰り返す人がいるのです。私の見たところでは、上司が設計図を練っている時間にプログラムが3回は書けそうでした。しかも設計図の描き直しを何回も繰り返しているようでは、無駄の量は 10 倍 20 倍になっていきます。これでは仕事は進まないし終わりません。
これは覚えておいてほしいのですが、すべての仕事は必ずやり直しになります。最初の狙いどおりに行くほうがまれなのです。スマホのアプリもWindows95も、あなたの明日のプレゼン資料もそうです。どうせやり直しになるのだから細かいことはおいておき、まず全体像を描いてしまったほうがいいのです。これがつまりプロトタイプを作るということになります。
もし上司が、最初からプログラマーと密な連携を取ってプロトタイプを作っていたらどうなっていたでしょうか。きっと無駄なプロセスが省けて、もっと早く仕事が終わっていたはずです。