その仕事は、本当に間に合うのか？
１章では「あなたの仕事はなぜ終わらないのか」ということで、仕事が終わらない人の特徴を挙げて原因を分析しました。その結果、
①安請け合いしてしまう
②ギリギリまでやらない
③計画の見積もりをしない
という問題が見えてきました。この問題意識を引き継ぎつつ、本章では正しい時間の使い方をマスターすることの利点についてお話しします。
まず、時間の使い方をマスターすると、仕事のリスクが見えるようになります。リスクとはなんとも大げさな言葉のようですが、ここでは「できそうかどうか」という程度の意味だと思ってください。
たとえば２週間後が締め切りの仕事を任されたとします。この仕事が２週間で終わるかどうかはわかりません。上司もプロジェクトの進行上２週間後と設定しているだけであり、ちゃんと２週間で終わることを計算して言っているわけではありません。
だからこの仕事のリスクは、まず自分で計るしかないのです。自分で計った結果、２週間では終わらないということがわかったら、すぐに上司に言えばいいのです。
ここでリスクを計らずに愚直に仕事を進め、締め切り間際になって「終わりそうにありません……」と報告されるのが会社にとっては最悪です。締め切り間際にスケジュールの再調整に追われる上司がどれだけ大変か考えてみてください。
どの仕事でもそうですが、全体のプロジェクトのうちどこか一つでも締め切りに間に合わないと、プロジェクト自体が滞ってしまいます。ＡとＢという仕事が完成して初めてＣという仕事を始めることができる、という状況はみなさんも直面したことがあるでしょう。
仕事が締め切りまでに終わらないのは仕方がないことです。そういった場合、できるだけ早く上司に相談することで、のちの混乱を避けることができます。
だから仕事のリスクを計ることは大事なのです。
スマホアプリがアップデートを繰り返す理由
「仕事のスピードを追求したら質が落ちてしまう。それじゃダメだ」
そう思われている方もいると思います。たしかに速さを求めると質は落ちます。大抵の仕事がそうであるように、スピードと質はトレードオフ（片方を取るともう一方は取れない）です。質の悪いものを出さないようにじっくり時間をかけて、ときには徹夜で頑張る人もいるでしょう。
けれども質を追求した結果、締め切りに間に合わないような仕事の仕方をしていては本末転倒です。締め切りに間に合うことが明らかな状況であれば、質を高めるために時間を使うのは間違っていません。問題なのは、まだ仕事が終わる見通しが立ってもいないのに、質を高めるためにあれこれ工夫を凝らそうとすることです。
みなさんが普段使っているスマートフォンのアプリを例に挙げて考えてみましょう。
アプリは一度配信が開始されても、その後幾度もアップデートを繰り返します。新しいアップデートの通知が何件もたまっていく光景を誰でも一度は見たことがあるはずです。
あのアップデートはなぜ何回も繰り返し行われているのでしょうか？
答えは、配信が開始された段階では１００％の出来ではなかったからです。
「未完成品を売っているのか！」
そう思われたでしょうか？ しかし想像してみてください。最初から１００％の出来のものを作るなんて、可能でしょうか？ 大抵の仕事は、終わったときは満足していたとしても、時間が経つと修正したくなるものではないでしょうか？
あなたの仕事だってそういうことがあったはずです。あのミーティングの日、話が終わった直後はなかなかいい仕事をしたと思った。でも翌日、ミーティングの内容を報告書にまとめている最中に「あれ、これで大丈夫かな……」と不安になってしまうのです。ほかにもあのプレゼンの前日、リハーサルが終わったときには「これでいける！」と思ったことでしょう。けれどもプレゼン当日、たくさんの人の前で発表している最中にどんどん不安になっていきます。
仕事とはそういうものです。どんなに頑張って１００％のものを作っても、振り返ればそれは１００％ではなく90％や80％のものに見えてしまうのです。言い換えれば、１００％のものは、そんなに簡単に作れるものではないのです。
だから世の中のアプリ開発者は、配信後も長い時間をかけてアップデートを繰り返し、少しでもいいものを提供できるように努力しているのです。
つまり最初から１００％の仕事をしようとしても、ほぼ間違いなく徒労に終わるわけです。なぜなら後から再チェックすると、直すべき箇所が次々に見つかっていくからです。
もちろん、仕事のクオリティを上げるために時間を費やすのは間違ったことではありません。適当な仕事を繰り返していては上司からの評価も下がります。
しかし時間を費やすあまり締め切りギリギリになったり、あるいは締め切りを破ってしまったりしては上司からの評価はもっと下がります。
クオリティが低くて怒られることよりも、締め切りを守れずに「時間を守れない人だ」という評価をされることを恐れてください。
３５００個のバグがあっても、世界は変わる
「兵は
この言葉は、一般には「
私はマイクロソフトでWindows95の開発をしていました。マイクロソフトでは仕事ごとに必ず締め切りがあり、なおかつ製品（Windows95）の発売予定日も決定していたので、決められた仕事は必ず期限内に終わらせる必要がありました。当時どのような仕事の仕方をしていたのかは３章でお話ししますが、ここではとにかくスピードが求められていたということだけ覚えておいてください。
私はWindows95を予定どおりに発売するために、全力で仕事をしました。その結果、きちんと１９９５年８月24日にグローバル版が発売されました。
しかし発売当時、Windows95には約３５００個のバグが残っていました。私たちはそれを知っていましたが、そのまま発売することになりました。
もちろんバグは修正することができます。だから先ほど紹介したように、スマホアプリの開発者はいつもバグの修正に奮闘しているわけです。
けれどもそのバグの数は、大規模なプロジェクトの場合、ある臨界点に達するともうそれ以上減らないということがプログラマーの世界では知られています。なぜなら、あるバグを直すとその副作用でほかのところでバグが発生する可能性があるからです。つまりソフトウェアのバグというのは、完全に０にするのがとても難しいのです。
それゆえプログラマーたちは、１００点じゃなくてもいいので90点や80点のプログラムを必ず納期に提出することが求められています。「兵は拙速を尊ぶ」という言葉は仕事にもまさに当てはまるのです。
Windows95はそういう理由から、３５００個のバグを残したまま製品化されました。といっても、深刻なバグはもちろんちゃんと修正してあります。たとえば保存したはずのファイルが勝手に消えるといったバグを残してしまっては、使い物になりません。だからそういったものはちゃんと検証して除去しています。
ただ、ユーザーが通常の使用をする中では発生しないような細かいバグは修正しませんでした。たとえば一般のユーザーが絶対に知らないような特殊なコマンドを入力すると画面が消えてしまうなどです。そういったものまで完璧に除去しようとすると、無限に時間がかかります。それでは発売予定に間に合いません。
それでもご存じのように、Windows95は世界に大きなインパクトを与えました。恐らくWindows95は、細かいプログラムの知識を持っている専門家にとってはたいへんな手抜き作に見えたことでしょう。しかし大事なのは、一般のお客さんにとってどれだけいいものを素早く提供できるかです。バグの修正は発売後にもできますから、そこは許容範囲を見極め、割り切ってしまうべきです。
すべての仕事は、必ずやり直しになる
Windows95がどのようにして生まれたのかは、３章でもう少し詳しくお話ししますが、少し先取りして重要なキーワードをお伝えします。
このように多少のバグを無視して、とりあえず大枠を作ったものをプロトタイプ（試作品）といいます。これはプログラムの話に限らず一般的な仕事においても応用できる、より抽象的な概念であると理解してください。
会社の企画を任されたときにプロトタイプを作ると、全体のイメージが固まります。イメージが固まっていると上司もプロジェクトの進行を理解しやすいので、企画が通りやすくなります。また、何より自分自身がプロジェクトを進行するときに、仕事がやりやすくなります。
逆に、プロトタイプを作らないとこういうことになります。
以前職場で、別の部署の上司がプログラムを作っていました。といっても彼はプログラム自体を作っていたのではなく、詳細な設計図を作っていたのです。とても時間をかけて丁寧に作っていました。そしてそれをプログラマーに渡して、実際に作ってもらうのです。しかしプログラムというのは実際に作ってみてからが本番というところがあります。設計図上ではうまくいくはずなのに、実際に動かしてみるとうまくいかないということがしばしばあるのです。
結局プログラムはうまく動作しませんでした。しかしプログラムを作った人は、依頼主に文句を言うことはできません。「この設計ではできません」と申し出るのが難しいということは、みなさんもよくおわかりかと思います。そういうわけで、未完成な出来の悪いプログラムが納品されます。プログラマー自身も出来が悪いということを知っていながら納品するしかないのです。完成品を受け取った依頼主の上司は「これじゃダメだ」ということで設計図を描き直します。そして再びプログラマーに依頼します。
こういうことを何回も繰り返す人がいるのです。私の見たところでは、上司が設計図を練っている時間にプログラムが３回は書けそうでした。しかも設計図の描き直しを何回も繰り返しているようでは、無駄の量は10倍20倍になっていきます。これでは仕事は進まないし終わりません。
これは覚えておいてほしいのですが、すべての仕事は必ずやり直しになります。最初の狙いどおりに行くほうがまれなのです。スマホのアプリもWindows95も、あなたの明日のプレゼン資料もそうです。どうせやり直しになるのだから細かいことはおいておき、まず全体像を描いてしまったほうがいいのです。これがつまりプロトタイプを作るということになります。
もし上司が、最初からプログラマーと密な連携を取ってプロトタイプを作っていたらどうなっていたでしょうか。きっと無駄なプロセスが省けて、もっと早く仕事が終わっていたはずです。
石膏像を彫るとき、「眉毛」から始める人はいない
プログラムに限らず、大抵の仕事の全体図は実際にやってみないと描けません。企画書という紙の上だけで考えても大体思ったとおりになることはないのです。みなさんもそういう経験がおありだと思います。
ですからプロトタイプの作成に速やかに入り、ある程度まで作ったうえで、どのくらいの難易度かを考えつつ仕事を進めていくのが賢いやり方です。
プロトタイプを作らず愚直に細部を突き詰めていった場合、締め切り間際になって「ここは設計から作り直さなければならない」という事実に気づくことがあります。そうなると危険です。締め切り間際では、大枠の設計を変更する時間もないので、完成品はろくでもないものになります。
一方プロトタイプを作っていると、「ここは作り直さなければならない」という事実を早期に発見できます。そうしたら設計図を作り直せばいいのです。プロトタイプを作っている段階ならば、いくらでも直しが効きます。
よくこういった話を、石膏の彫刻の例を出して説明することがあります。石膏を削って胸像を作るとき、いきなり眉毛の一本一本にこだわって細い彫刻刀を使う人はいません。そんなことをしても、後になって全体のバランスがおかしくなって失敗するだけです。普通はまず大きく輪郭を粗削りするところから始めます。つまりプロトタイプを作るとは、そういうことなのです。
仕事が遅くて終わらない人が陥る心理として、「評価されるのが怖い」というものがあります。自分の仕事がどう評価されるのかが怖くて、できるだけ自分の中の１００点に近づけようとしてブラッシュアップを繰り返します。しかしブラッシュアップすればするほど、もっと遠くに１００点があるような気がして、いつまでたってもこのままじゃ提出できないという気持ちになります。そして、そうして時間をかければかけるほど、上司からはクオリティを期待されているような気がして、恐怖に拍車がかかります。
このループに陥る人の状態を「評価恐怖症」といいます。１章の「なるはや病」と同じく、日本の一部で蔓延している病です。評価恐怖症にかかった人は、自分の中での１００点満点を目指すあまり、本来なら終わる仕事も終わらなくなります。
たしかにそうして仕事が遅れてしまう心理はよくわかります。粘り強くいいものを作ろうとする気持ちも決して失ってはいけないと思います。そして、そうした気持ちこそが優れた製品やサービスを作るのだとも思っています。
しかし、すべての仕事は必ずやり直しになる、くらいの覚悟が必要です。荒削りでもいいから早く全体像を見えるようにして、細かいことは後で直せばいいのです。そうした気持ちでいれば、評価恐怖症でいることも、あまり大したことではないとわかるはずです。あなたはプロトタイプを最速で作るべきなのであって、細かいところは後から詰めて考えればいいのです。
待ち合わせ30分前に、スタバでコーヒーを飲め
仕事は締め切り前に終わらせる。これは大前提です。そのため、１章で紹介したように、徹夜で仕事を終わらせようとする人が出てきます。
徹夜の危険性についてはすでに１章でお話ししたとおりですが、もう一つお話ししておきたいことがあります。それは誤差への対応です。
締め切り当日がゴールだと思ってラストスパートをかける人は、大抵最後の最後になって不足していた部分に気づき、慌てることになります。「全力でプレゼン資料を作ることに集中していたため資料のコピーを取ることを忘れていた」などが典型でしょう。
そうした思わぬ追加の仕事のことを私は誤差と呼んでいます。誤差のせいで完成していたはずの仕事が完成しなかった経験はみなさんあると思います。
こうした誤差による失敗はすべて、締め切り当日がゴールだと思っていることに起因しています。
10時に友人と渋谷のハチ公前で待ち合わせするときのことを想像してみてください。
５分前行動主義者のあなたは、９時55分に渋谷に着く電車に乗ります。しかし電車は遅れることがあります。運悪く電車が遅れてしまったあなたは、10時10分に渋谷に着くことになります。そして待ち合わせの相手に謝罪のメールを送ることになるわけです。
私はこういうとき、９時半にはハチ公広場から横断歩道を渡ったところにあるＴＳＵＴＡＹＡのスターバックスで優雅にコーヒーを飲んでいます。そうして９時50分にはスターバックスを出ます。10時に待ち合わせだったら、９時半に近くのスターバックスでコーヒーを飲むというのが私のスタイルです。
ここで大事なのは、待ち合わせ時刻の30分前に近くのスターバックスにいるということです。つまり私にとって10時にハチ公前で待ち合わせをするということは、すなわち９時半にＴＳＵＴＡＹＡのスターバックスにいるということと同義なのです。
10時にハチ公前に間に合うようにする方法ではなく、９時半にスターバックスにいる方法を考えるというわけです。そうすれば自然と電車に乗る時刻も早くなりますし、電車が遅延したとしてもほとんどの場合間に合います。
この渋谷の待ち合わせの話が示唆することは、締め切りの前に締め切りがあると考えなければならないということです。逆説的なようですが、締め切りに間に合わせようと考えていても、締め切りには間に合いません。しかし、締め切り前に締め切りがあると考えると間に合います。締め切りを狙ってはいけないのです。
花さえ用意できれば、裏で昼寝してもいい
友人との待ち合わせならともかく、仕事の締め切りに遅れてしまうのは絶対に避けたいものです。私はマイクロソフトにいたころ社長のビル・ゲイツと仕事をしていました。そのため彼の考えはよく知っているのですが、彼は待ち合わせや締め切りに遅れた人がする言い訳をこの世で一番嫌っていました。とくに論理的に言い訳する人を嫌うのです。どういうことかお話ししましょう。
たとえばあるパーティーがあるときに、ビル・ゲイツがあなたに花を用意してほしいと頼んだとします。あなたは花屋に電話をし、パーティー会場に花束を届けるように注文します。しかしパーティー当日、花屋から、雪のせいで配達が遅れるという電話が来ます。あなたは花が遅れるという旨をビル・ゲイツに伝えます。
こういうとき、彼は尋常じゃないほど怒ります。その怒りは、人が変わったのではないかと思うほどです。それだけ締め切りまでに仕事を終えることを重視しているのです。
あなたが命じられた任務はパーティーに花を用意することであり、花屋に注文をすることではありません。注文をするだけなら誰にでもできます。あなたは花を用意するために雇われているのです。であれば、いかなる理由があっても花を用意することができなかったのは１００％あなたの怠慢であり、責任を負うべきだというのです。
ですから、もし花屋が雪の影響で配達が遅れるというならば、あなたはなんとしてでも花をパーティー会場に用意するための手段を考えなければいけません。車で近くの花屋まで行くとか、ほかの花屋に至急注文をするとか、そういった第二第三の案をただちに遂行しなければなりません。
あなたの任務は花を用意することです。花さえ用意できれば、パーティー会場の裏で昼寝をしていてもいいのです。だからこそ花は絶対に用意しなければならない。花屋に注文をすることは任務の一部でしかありません。言い訳をする人はそこを勘違いしています。
先ほどの待ち合わせの例でいえば、大抵の人は10時前に到着する電車に乗ることだと思っています。しかし本当の任務は、10時に待ち合わせ場所に着くことです。
このように自分の中で任務を再定義することが仕事においても重要です。私はビル・ゲイツほど厳しい人間にはなれませんが、自分の中で絶対にやらなければならないものとは何かを真剣に考えることは大事なことだと思っています。
ルーがなくてもカレーは作れる
ビル・ゲイツが仕事において重要視していることをあと２つ紹介します。
彼は複雑な問題をいくつかの独立した問題に分けるのがとても上手な人です。「困難は分割せよ」とはフランスの哲学者・デカルトの言葉ですが、分割術を最も実践的に行っているのはビル・ゲイツでしょう。
たとえば、こんな例で考えてみましょう。
ある日、ビル・ゲイツがカレーライスを作ろうとしたとき、なんとカレールーとニンジンがありませんでした。これではいつものカレーライスが作れません。しかしよく考えてみてください。ルーがないと絶対にカレーライスは作れないでしょうか？ ニンジンがないとカレーライスは作れないでしょうか？ そんなことはありません。ルーは市販のカレー粉で代用できるし、ニンジンはなくても一応カレーライスにはなります。つまり、ルーがないという問題と、ニンジンがないという問題は独立しています。だからここは慌てず、「ルーをどうするか」「ニンジンをどうするか」という分割された課題に、別々に当たればいいわけです。
ビル・ゲイツはその後、カレー粉とじゃがいもを使ってカレーライスを作っておいしくいただきました。
やや抽象的な話だったので、現実にあった事件を例に挙げます。
マイクロソフトがパソコンメーカーにソフトを依頼されたとき、ある技術的な問題により、パソコンメーカーから苦情が来たことがありました。クライアントがたいそう怒っているということで、社内は混乱していました。とにかく、原因の技術的問題を解消しなければこの問題は収まらない。マイクロソフトの社員はみんなそう思い込んでいました。
そんなとき、ビル・ゲイツは困難を分割しました。
技術的問題はクライアントの怒りからは独立した問題だと。どうやらクライアントが怒っているのは技術的問題よりも、担当者との性格の不一致に原因があったようです。そうして担当者は替えられ、クライアントをとにかくなだめる任務に就くことになりました。他方で技術的問題はエンジニアたちが全力で解決に向かってまい進していました。
こうしてクライアントとマイクロソフトの関係は、なんとか立ち直ったのです。技術問題と外務問題を切り分けることで、この事件は終息を迎えました。ビル・ゲイツが「その問題とこの問題は独立している」とよく言っていたことを覚えています。こうした課題の分割は、複雑な問題を効率的に解決するうえで重要なことだと思っています。
「出勤前の服選び」で疲れてどうする
話が脱線しますが、効率化といえば、「世界の偉人はいつも同じ服を着ている」ということが一部で知られています。たとえばフェイスブックのマーク・ザッカーバーグはいつもグレーのＴシャツにジーンズをはいています。アップルのスティーブ・ジョブズは黒のタートルネックにジーンズをはいていました。オバマ大統領はグレーかブルーのスーツを着ています。
彼らはなぜそういうことをしているのでしょうか。それは彼らが日常のささいな決断の数を減らそうとしているからだそうです。日々たくさんの人と会い、様々な意思決定を行う彼らは、普段から大きな決断を迫られています。そのため会社の経営や政治に関わる重大な決断をするときに脳が疲れないよう、無駄な決断をしないようにしているのだそうです。無駄な決断とは、ここでは服選びのことを指します。
心理学では、決断や意思決定をする際に減少する気力のようなものを「認知資源」という名前で呼んでいます。この言葉を使うと、つまり世界の偉人は、認知資源を経営や政治のために温存しているということになります。服選びなどのつまらない決断で疲れるのを避けようというわけです。
私は認知資源という言葉は最近まで知らなかったのですが、「決断疲れ」を避けようとする偉人たちの気持ちはとてもよくわかりました。
私は毎日服を着る際、いつも
服選びならともかく、もっと時間を取るものがあります。それは表敬訪問です。とくに用事はないけれども、ご挨拶という触れ込みで訪ねる不思議な文化です。あれは無礼の表明になりこそすれ、敬意の表明にはなりません。
ビル・ゲイツは私よりももっと先鋭化させた考えを持っています。最初に私が驚いたのは、彼が何らかの説明を社員から聞くときに、直接その社員からは話を聞かないことです。彼は情報をかみくだき、彼にわかりやすく説明してくれる専門の社員を雇っていたのです。
私たち社員は、ビル・ゲイツに何か説明をするとき、その専門の社員に説明をします。するとその専門の社員がビル・ゲイツにわかりやすく説明をするのです。
一般のスタッフの中には、説明がうまい人もいれば下手な人もいます。そんな中でビル・ゲイツがいちいち顔を合わせて聞いていたら、膨大な時間がかかります。だから彼は、コストをかけてでも、説明を聞く時間を効率化するために専門のスタッフを雇っていたのです。当時ビルは、常時二人の説明専門家を雇っていました。
さらに、彼が参加するプレゼン会議では、発表者が発表をする時間は設けられません。彼のいうプレゼン会議とは、発表者との質疑応答の時間のことを指します。したがってスライドを動かしながら説明をするといったことはしません。資料は前もって送り、当日、質問を受けるだけです。これは究極の効率化です。
そこまで効率化を図りつつも、しっかりと会議をする目的は果たします。会議室に入っていきなり「３ページ目の開発は、ほかのグループがやってるけど、君は知らないのか」など鋭い突っ込みが入ります。そして会議は最長で30分という時間が決められています。ですのでちゃんと受け答えの準備ができていないと、うなだれて帰るのがオチになります。
ビル・ゲイツはとにかく仕事の効率化を図っている人です。私も彼ほどまでに厳しくはできませんが、ビル・ゲイツが世界一の大金持ちになった理由の一端は、彼の時間の使い方にあったのだと確信しています。
ビル・ゲイツの意思決定は光速
もう一つビル・ゲイツが仕事で重要視していたのは、
光速
と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。
あれは忘れもしない１９９５年１月、シアトルの冬らしい小雨の降る昼下がりのことでした。
米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。カイロというグループとシカゴというグループの対立です。
もともとカイロが、前作のWindows 3.1に続く次世代ＯＳを開発する予定だったのですが、カイロは進捗が悪く、そのあいだを埋めるためにシカゴというグループが結成されました。
シカゴはハッカーを寄せ集めた職人集団というイメージで、スタンフォード大学の博士号を取ったような人たちばかりのカイロとはまったく毛色が違いました。
私はもともとカイロに所属していたのですが、退屈なミーティングが多くて嫌だったので、上司と喧嘩したのをきっかけにシカゴに移りました。シカゴならカイロよりも風通しがよく、自分のアイデアもすぐ仕事に反映できると思ったからです。
シカゴに移った私は、カイロにいたころに取り組んでいたプログラムを一部持ち込んできました。一言でいえばアイデアを盗んできたということになりますが、同じ社内だし、そもそもそのプログラムをカイロで設計したのは私だったので、犯罪でも何でもなかったのです。
しかしその後、カイロの人たちに、アイデアをシカゴに持っていったことがばれ、怒られました。スパイだとも言われました。カイロの人たちは社長であるビル・ゲイツに直談判して社内裁判を開きました。
シカゴでの私の上司は、「今度ビル・ゲイツの前でプレゼンすることになったから、全部君に任せるね」とあっさり私に告げました。それにもびっくりしたのですが、それ以上に、カイロから送られてきた資料にも驚きました。約４００ページの資料には、私がシカゴに移って組み上げたプログラムが、いかに張りぼてで手抜きかということが延々と書かれていたからです。
たしかにその指摘は間違っていませんでした。前述したように、私は「兵は拙速を尊ぶこそ仕事の要諦」と考えています。
早く仕事に着手することを起点にして、70点でも80点でもいいから速攻で仕事全体をまず終わらせてみることこそ重要という主義です。そういう風ですから、細かいバグが膨大にあったことは認めます。
しかしそれにしても、カイロの頭でっかちのサイエンティストたちは机上の空論ばかり振りかざしているように見えました。こんな細かい指摘ばかりしていては、いつまで経っても仕事は終わりません。この４００ページの資料も全部読もうとしても眠くなってしまうので、数ページめくってからそっと閉じ、社内裁判に出席することに決めました。
プレゼンの日は刻々と近づいていましたが、プレゼン資料を用意する気にもなりませんでした。技術的に細かなことで闘うのではなく、これはマイクロソフトのカルチャーに関わる問題だということを明らかにしたほうが良いと思ったのです。カイロのような仕事の仕方では決してものは出せないことをビル・ゲイツに納得してもらうのです。
裁判当日、私は取締役会議用の会議室に通されました。そこには、マイクロソフトのトップ５のうち、営業の長であるスティーブ・バルマーを除いた全員が出席していました。副社長のブラッド・シルバーバーグとジム・オールチン、オフィス開発グループリーダーのブライアン・マクドナルド、上級副社長のポール・マリッツ、そしてビル・ゲイツ。このそうそうたる顔ぶれを見て、私はとんでもなく重大なミーティングに参加しているということに気づかされました。
こうなると緊張どころか、逆にワクワク感が募ってきます。
これだけのメンツがそろっている前で、自分の仕事の重要性を主張する機会は滅多にありません。机上の空論ばかりを繰り返しているカイロに負けるわけにはいかない。アドレナリンが血中に放出されるのを感じました。
裁判が始まりました。まずカイロ側が例の４００ページの資料を出して、シカゴの仕事がいかに適当でダメダメかということを話しました。そのとき、私は４００ページの資料を読んでいなかったことを後悔はしませんでした。私なりの戦い方の準備をしていたからです。
私の発言の機会が回ってきました。何も資料は作っていませんでしたが、一つだけ用意してきたものがありました。あるデータが入ったＣＤ－ＲＯＭです。その中身を披露しながら、私はビル・ゲイツの目を見据えてこう言いました。
「カイロチームの主張にも一理あるけれど、完璧なアーキテクチャ（基本設計）を追い求めていては、永遠にものは出せません。Windows95のリリースはあと６か月に迫っています。いつになったらリリースできるかわからないカイロにマイクロソフトの将来を任せるというのは、どう考えても間違っています」
次世代ＯＳをめぐるカイロとシカゴの戦いは、どちらの時間の使い方が正しいかをかけた戦いでもあるのです。
ビル・ゲイツはこのあいだずっと両手を体の前に合わせ、少し前屈みで、体をゆっくりと前後に揺らしながら聞いていました。考えながら真剣に人の話を聞いているときの彼のスタイルです。
一通りの意見を聞き終えると、ビルの体の揺れが止まりました。「何か重要な発言をするのか」と私は身構えました。
しかし、ビルは単にポール・マリッツのほうを向き、目配せをしただけでした。するとポールが「ここでこのまま待つように」と言って立ち上がり、ビルと一緒に部屋から退出しました。恐らくビルの頭の中では結論が出たのでしょう。それをポールと再確認したうえで、最終決定として伝えるつもりなのです。
ビルとポールが退出していた時間はわずか３分ほどでした。けれども部屋には妙な沈黙が流れていて、私にはそれが１時間くらいに感じられました。部屋にいる全員が、次に彼らが部屋に戻ってきたときには、裁定が下され、それには誰も口をはさめないことを知っていました。
シカゴとカイロという莫大な開発費をかけた２つのプロジェクトの命運が、今日この場で決まるのです。
ドアを開いて、ポールを先頭に二人が部屋に戻ってきました。運命の瞬間です。
「カイロプロジェクトはキャンセルする」
開口一番、ビルはそう言いました。
カイロプロジェクトキャンセル。それはすなわち、４年にわたってカイロが開発していたＯＳをなかったものにするという意味です。その一瞬で、４００人を超える大所帯のカイロを解散することを決めたのです。逆に言えば、シカゴで開発していたＯＳを、マイクロソフトの次世代ＯＳとしてリリースする方針に決定したということでもあります。
その次世代ＯＳとは何でしょうか？
それは、私が証言していたときに実際に動かしていたＣＤ－ＲＯＭにすでに格納されていました。その中身は、シカゴに移った後に完成させていたベータ版のWindows95だったのです。
この裁判はまさに、私の提出した仕事が会社のトップに認められた瞬間でした。
そしてこの重要すぎる決断は、たったの３分で下されたのです。
現在の「右クリック」の概念は、こうして生まれた
ビル・ゲイツの話が続いたので、余談になりますが、私が米マイクロソフト勤務時代にカイロからシカゴに持ち込んだというアイデアについて少しお話しします。
それまでのＯＳでは、あらゆる操作をキーボードでのコマンド入力（コマンドと呼ばれる文字例をキーボードから入力し、コンピューターに命令すること）で実行していました。マウスは存在していましたが、まだ今ほど便利で優れたツールではありませんでした。では、Windows95で何が起きたのでしょうか？ それはみなさんおなじみの右クリックとダブルクリック、そしてドラッグ＆ドロップの現在の形への進化です。この概念を私は、ビル・ゲイツの前での公開裁判の中で披露した、ベータ版の中にすでに組み込んでいました。
みなさんご存じのとおり、Macintoshのマウスにはボタンが１つしかありません。これは昔からそうです。一方、Windowsにはボタンが２つあります。とはいえ当時は左ボタンを使うことがメインで、右のボタンは今ほど使うことはありませんでした。
しかしWindows95になってから、右クリックの使い勝手は飛躍的に向上しました。デスクトップ画面の何もないところで右クリックすることで、画面のプロパティやアイコンの整列などの操作をするメニューが開きます。テキストファイルの上で右クリックすると同様にメニューが開きます。
また、ドラッグ＆ドロップも大きな変化の一つです。たとえば、要らない文書ファイルのアイコンをクリックしたまま「ごみ箱」のアイコンの上に持っていけば、文書ファイルを削除することができます。Windows95はユーザーがパソコンに詳しくなくても簡単に操作できるように、グラフィカルな設計がなされたのです。今の感覚からするとずいぶん当たり前なことですが、当時としては画期的なことでした。
グラフィカルな設計といえば、ダブルクリックもそうです。文書ファイルのアイコンをダブルクリックすると自動的にワープロソフトの編集画面が立ち現われ、音楽ファイルのアイコンをダブルクリックすると自動的にプレーヤーが立ち現われて再生が始まります。
ファイルをシングルクリックした場合、その後ユーザーが選択するコマンドは「ファイルの編集」「コピー」「転送」「再生」など、様々な種類が考えられます。しかしダブルクリックは、文書ファイルなら文書ファイル、音楽ファイルなら音楽ファイルといった対象を選択したうえで、ダブルクリックという操作をするだけで、自動的に「編集する」「再生する」といったコマンドが選択されるのです。
このように、何らかの対象（オブジェクト）を先に選択したうえで動作を指定することをオブジェクト指向といいます。
オブジェクト指向のわかりやすい例として、私たちがいつも使っている日本語が挙げられます。
あなたがテーブルの上の塩を取ってほしいとき、あなたは「すみません、塩を……」まで言葉にしたところで一呼吸置くと思います。それはなぜなら、「塩」という対象を指定した時点で、あなたが相手にしてほしいことは決まり切っているからです。相手もそれをわかっているので、「塩をどうしろっていうんですか？」なんて野暮なことは聞きません。
エレベーターに乗り合わせた人に「すみません、12階を……」と言うのも同じことです。これも12階という対象を指定した時点で、12階のボタンを押してほしいということは決まり切っています。
これはWindowsにおけるダブルクリックと非常によく似ていると思いませんか？ このようなグラフィカルでオブジェクト指向な機能を思いつくことができたのは、もしかしたら私が当時マイクロソフトで唯一の日本語話者だったからかもしれません。日本人的な会話の作法を取り入れた結果、Windows95が世界を席巻したと考えると、感慨深く思います。
先日も、深夜に口もききたくないくらい疲れ切ってタクシーに乗ったときに、この「オブジェクト指向」言語である日本語を理解する運転手（平たく言えば普通の運転手）に助けられました。そこでは次のような会話が展開されました。
「すみません、経堂まで……」
「はい、経堂までですね。道はどうしましょう？」
「あ、環七経由で……」
「はい、環七から赤堤通りですね」
（しばらくして）
「その信号を左に……」
「はい、ここを左ですね」
「それで、そこの行き止まりの所で……」
「はい、かしこまりました」
時間を制する者は、世界を制す
本章の最後に、結局時間を制するとどんなメリットがあるのかをおさらいしておきましょう。それは次の３点に集約されます。
①リスクを測定できる
②目に見える形のもの（プロトタイプ）を素早く作ることができる
③誤差に対応できる
まず、冒頭でリスクを測定できるというお話をしました。その仕事が締め切りまでに終わるかそうでないかを早期に判断することが、会社にとって非常に大事なのです。終わりそうにない、ということ自体は仕方のないことです。一番避けたいのは、締め切り間際になって「終わりそうにないです……」と言ってくることです。上司としては、早めに報告してくれればいくらでもリカバリーできるのに、ギリギリに報告されるのは正直困ります。でも前倒しで仕事の大半を終わらせるようにすれば、迷惑をかけることはありません。
次に、プロトタイプを作ることができるというお話をしました。プロトタイプとは、簡単に言えば70点でも80点でもいいので、仕事全体をいったん終わらせたもの（試作品）のことです。Windows95はバグが３５００個あったという話を思い出してください。細かいところは後から直せます。ですから細部は後に回して、まず大枠を作って全体を俯瞰できるようにすることが大事です。
バグの数は絶対に０にはできません。ですから、許容範囲を見極めて早めに形にしてしまうほうがいいのです。バグを消そうとして頑張っていては、いつまで経ってもゴールにたどり着きません。
「評価恐怖症」のところでお話ししたように、１００点の出来を追求しすぎると、自分の中でどんどん勝手にハードルが上がっていき、上司や顧客からの期待に応えられないのではないかという不安が増幅していきます。これではいつまで経っても仕事は終わりません。
すべての仕事は必ずやり直しになります。ですから、70点でも80点でもいいから、まずは形にしてしまうことから始めましょう。スマホアプリが延々とアップデートを繰り返している理由を考えてみてください。１００点の仕事など存在しないのです。それよりも最速でいったん形にしてしまってから、余った時間でゆっくりと１００点を目指して改良を続けるのが正しいのではないでしょうか。
最後に誤差に対応できるというお話をしました。これは渋谷に10時に待ち合わせをするという比喩がわかりやすかったと思います。９時55分に渋谷に到着する計画では、遅れてしまう可能性が十分あります。そうではなく、30分前に近くのスターバックスにいることも含めて待ち合わせだと考えてください。私にとって、10時に渋谷で待ち合わせというのは、すなわち９時半にＴＳＵＴＡＹＡのスターバックスにいることと同義なのです。
また、ビル・ゲイツがあなたに花を用意させる話もしました。花を用意するという任務を与えられた以上、あなたは花屋がいかなる理由で花を届けることができなくても、責任を持って花を準備しなくてはなりません。あなたの任務は花屋に花を注文することではなく、花を用意することなのです。待ち合わせの例でいえば、待ち合わせというのは10時前に到着する電車に乗ることではなく、10時に絶対に待ち合わせ場所に着くことなのです。
このように自分の中で何を守るべきなのか、何が任務なのかを再定義することが仕事でも重要です。責任感を持つことで自分のやるべき使命がはっきりします。
以上の３点を本章前半で紹介していきました。また、後半では私のマイクロソフト時代の話やビル・ゲイツの話をしていました。
「時間術の本なのになぜこんなにエピソードが多いんだ」と思われる読者の方もいることでしょう。
まずビル・ゲイツの話は、時間術を極めれば世界一の大金持ちにすらなれる可能性を示唆させていただいたものです。またマイクロソフト時代の話は私にとって、そして私の仕事のやり方をみなさんに知ってもらうにあたって、非常に重要なのです。
なぜなら私がみなさんにお話しする仕事の仕方は、次の３章でお話しする、プログラミングの仕事をしてきた半生の中で生まれてきたからです。
そこで、続く４章では、引き続き「時間術を極めるとどんないいことがあるのか？」の話と並行して、「ロケットスタート時間術はいかにして生まれたか？」についてお伝えしていきたいと思います。
私は時間術の本を書くほどですから、子どものころからかなり効率について意識しながら生きてきました。ですから、私がいろいろな場面で何をどう考え生きてきたかをお話しすることは、ストレートに「効率的に生きている人間は常々何を考えているのか？ 時間術をどう日々の生活の中に落とし込んでいるのか？」をみなさんにお伝えするいい方法だと考えました。
ロケットスタート時間術が、仕事の中だけでなく、学生時代の生活、勉強しているときなどのあらゆる生活の場面に、存分に生かすことのできるものなんだということを想像していただきながら読んでもらえればと思います。