「締め切りは絶対に守るもの」と考えると世界が変わる
『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社）
「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。
「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「仕事への姿勢」そのものから決まるのだということが本書を読めば理解していただけると思います。
以下に、本書の一部を公開します。
◇ ◇ ◇
100人に1人もできない「あること」とは？
今まで、たくさんの日米のエンジニアと仕事をしてきました。その中には私よりも明らかに賢いエンジニアもいましたし、ものすごい生産性でプログラムを作ってくれる馬力のあるエンジニアもいました。
しかしそんな中でも、私が仕事をするうえで最も大切だと考えている「あること」をきちんとこなせる人は100人に1人もいませんでした。その「あること」とは、「常に締め切りを守ること」です。正確に言い換えれば、「常に締め切りを守れるような仕事の仕方をすること」です。
2章のビル・ゲイツの例で話したとおり、あなたの仕事は、パーティーに花が間に合うよう花屋さんに予約をすることではなく、パーティーに花を間に合わせることです。期日に間に合うよう予約しても間に合うとは限りません。予期しないアクシデントが起こることを前提としなければならないのです。
チームで仕事をする場合、どうしてもお互いが担当するタスクの間に依存関係が生じます。そんなときに、どれか一つのタスク完了の遅れがほかのタスクの完了に波及し、全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られます。これはほかの一般的な職場でも頻繁に起こっていることでしょう。上司からすると、安請け合いして締め切りを守らない部下ほど、残念な気持ちにさせられるものはないのです。
そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が自分に割り当てられたタスクは「必ず期日以内に仕上げる」という強い意志を持って仕事にのぞむことが必要です。そもそも部下にとっては、上司に約束した納期に仕事を間に合わせることが仕事の第一の鉄則なのです。
「そんなこと言ったって、仕事の過程において予想不可能な事態に陥ることはよくあることで、締め切りを絶対に守ることなんて無理」と思う人もいるでしょう。たしかにそのとおりです。みなさんは怠慢が原因で締め切りを破ることなんてないはずですから、きっと締め切りを破るとしたら予測不可能な事態が原因だろうと思います。
しかしスケジュールの立て方・仕事の進め方の段階から、締め切りを守ることの大切さをきちんと認識すれば、何があっても常に締め切りを守り続けることは十分に可能なのです。
「ラストスパート志向」が諸悪の根源
大半の人が、スケジューリングの段階から大きな勘違いをして仕事に取り掛かっています。締め切りという言葉への典型的な誤った考え方は、次のようなものでしょう。・見積もりはあくまで見積もりでしかなく、予定どおりに仕事が進むとは限らない
・締め切り目前に、徹夜でも何でもして頑張ることが大切
・それでもどうしても締め切りに間に合わなかった場合は、その段階でスケジュールを変更してもらうしかない
たとえば、このような意識を持っているエンジニアに、私があるソフトウェアの作成を依頼したとしましょう。するとそのエンジニアは、今までの経験から「3か月くらいでできると思います」と軽い気持ち（漠然とした見積もり）で答えます。
多くの場合、この手のエンジニアはプロジェクトを甘く見て、最初の2か月くらいはのんびりとすごします。残り1か月くらいの「お尻に火がついた」状態になって頑張るのですが、あわてて作るためにスパゲッティコード（スパゲッティのように複雑に絡み合ってしまったプログラム）になってしまいます。
残り2週間目くらいでソフトウェアはそこそこ動き始めますが、まだまだ機能は不十分だし、バグもたくさんあります。最後の1週間でバグの修正に取り掛かりますが、最後の最後になって基本設計上の欠陥が見つかります。しかし、いまさら後戻りはできないので、バグを回避するための、その場しのぎのパッチ（修正プログラム）を当てますが、そんなことをしているとますますプログラムが汚くなっていきます。
最後は徹夜もしますが、寝不足でミスが続き、結局バグが取れずに締め切りの日になってしまいました。私には「申し訳ありません、できませんでした」と言うしかありません。「じゃあどのくらいで完成するの」と聞くと、「あと2週間あれば大丈夫だと思います（根拠なし）」と答えます。しかし、2週間では根本的な変更などできるはずもなく、パッチにパッチを当て、目も当てられないようなプログラムになっていきます。
結局2週間努力しても問題は解決せず、「根本的な問題の解決のためにあと2か月ください」と言い出します。しかたがないのでスケジュールの変更を認めると、時間に余裕があるので、また最初の1か月はのんびりしてしまいます。
そうして最後の1か月でラストスパートをかけようとしますが、再び同じような状況に陥り、最後は徹夜の連続。再び寝不足のためにプログラムが汚くなり、バグが多発。結局、新しく設定した締め切りも逃してしまいました……。
こんなことでは、プロの仕事とは言えません。この仕事の根底には「締め切り＝努力目標」という考えがあり、「目標に向けて精一杯努力をすることが大切」という体育会的な姿勢があります。そして最も良くないのが「ラストスパート志向」です。多くの人が、「最初はのんびりしていても、最後に頑張ればなんとかなる」という根本的な誤ちを改めるところから始めないといけません。
ラストスパート志向の一番の欠点は、最後の最後までそのタスクの本当の難易度がわからないという点にあります。どんな仕事でも、やってみないとわからない部分が必ずあるのです。
だからラストスパート志向で仕事に取り組むと、仕事の後半に予想外のアクシデントが発生して、完了までの時間が延び、ほかの人に迷惑をかけてしまう可能性が出てくることを忘れてはいけません。これは1章でも2章でも何度もお話しした大事なことです。
まずは「締め切りは絶対に守るもの」と考える
ではたとえば上司から「これ10日でやっといて」という仕事が降ってきたとき、どうすればいいでしょうか？大切なことは、スケジューリングの段階から「締め切りは絶対に守るもの」という前提でのぞむことです。すると予定を立てる段階から、次のような真剣なやり方をとらざるを得なくなるはずです。
①「まずはどのくらいかかるかやってみるので、スケジュールの割り出しのために2日ください」と答えて仕事に取り掛かる（見積もりをするための調査期間をもらう）
②その2日をロケットスタート期間として使い、2日で「ほぼ完成」まで持っていく
③万が一、その2日で「ほぼ完成」まで持っていけなかった場合、これを「危機的な状況」と認識してスケジュールの見直しを交渉する
まず①ですが、「締め切りは絶対に守るもの」ということを常に念頭に置いておけば、何も考えずに「だいたい 10 日くらいでできると思います」のようなあいまいな回答はできないはずです。
当然ですが、仕事の最初の段階では見積もりすら不可能なタスクも多々あります。しかし、その手のものを、今までの経験をもとにざっくりと見積もるのはとても危険な行為です。そういう場合は、まずは上司から指定された期間の2割（この場合は2日間）を見積もりのための調査期間としてもらい、その期間、猛烈に仕事に取り掛かります。仕事の真の難易度を測定するためです。
その間に「8割方できた」という感覚が得られたなら上司に「10日でやります」と伝えます。そこまで至らなかったら、相当難しい仕事と覚悟したほうがいいでしょう。上司に納期の延長を申し出るのは、早ければ早いほどいいわけですから、8割方できなかった場合は期日の延長を申し出ましょう。
スタートダッシュで一気に作る
大切なのは、②で全力のスタートダッシュを行うことです。『マリオカート』をやったことはあるでしょうか。『リッジレーサー』でも『グランツーリスモ』でもそうですが、あらゆるレーシングゲームにはスタートダッシュ（ロケットスタート）というテクニックがあります。スタート前の「3→2→1」のカウントダウンのあいだに、適切なタイミングでボタン操作をすることで、スタートと同時に圧倒的に加速でき、ほかを引き離すことができるテクニックです。これをイメージしてください。「締め切りに迫られていないと頑張れない」のは多くの人々に共通する弱さですが、先に
述べたように、仕事が終わらなくなる原因の9割は、締め切り間際の「ラストスパート」が原因です。
ですから、 10 日でやるべきタスクだったら、その2割の2日間で8割終わらせるつもりで、プロジェクトの当初からロケットスタートをかけなければなりません。初期段階でのミスならば簡単に取り戻せますし、リカバリーの期間を十分に持つことができます。
とにかくこの時期に集中して仕事をして、可能な限りのリスクを排除します。考えてから手を動かすのではなく、手を動かしながら考えてください。崖から飛び降りながら飛行機を組み立てるのです。
作業を進めていって根本的な方向転換が必要だったら、この時期に行います。たとえばソフトウェアの開発ならアーキテクチャ（基本設計）の変更などです。何だか全然ダメなものができてしまったらもう一度ゼロからやり直します。健康だけには気をつけながら、全力疾走で仕事と向き合います。
そうして、実際に指定の2割の時間がすぎた段階で、仕事がどのくらい完了しているかをできるだけ客観的に判断します。8割方終わっていればスケジュールどおりに進んでいると考えていいでしょう。6割くらいしか終わっていなかったらかなりの危機感を持つべきです。その段階で万が一、完成度が6割未満だった場合は、③のとおり、「締め切りまでに完成できない可能性がある」と判断し、上司に状況を説明してスケジュールの見直しをしてもらいましょう。
締め切り直前ではなく、締め切りよりもはるか前に、期日に間に合わせられるかどうかを見極めることが大事なのです。この段階で「まだ2割しか時間を使っていないから大丈夫」と思うのは大間違いです。全力疾走で2割の期間を使って、まだ「ほぼ完成（8割方完成）」の状態に持っていけてないのだったら、かなりの確率で締め切りには間に合わないと判断すべきです。
逆にその時点で8割がた完成していれば、上司に「 10 日のスケジュールで大丈夫です」と伝え、残りの2割の「完成にまで持っていく仕事」を残りの8日間をかけてゆったりと行っていきます。余裕があればその期間に、次の仕事の準備を進めたりもします。
この段階で大切なのは、「全力で仕事と向き合う」ではなく「仕事の完成度を高める」であることを強く意識して向き合うことです。8割の時間を使って2割の仕事をこなすわけですから「仕事が終わらないわけがない」という余裕が生まれます。心地いいほど完璧なスラックの獲得です。
ここまでが、私が実践している仕事との向き合い方の全貌です。一言で言えば「時間に余裕があるときにこそ全力疾走で仕事し、締め切りが近づいたら流す」という働き方です。仕事に対する姿勢を根本的に変えなければならないので簡単な話ではありませんが、確実に効果があることを保証するので、なるべく多くの方におすすめしたいと思っています。
人は誰しも無意識のうちに不安を抱えながら仕事をしています。締め切りに間に合うかどうかを恐れているからです。ですから、取り掛かる時期が早ければ早いほど不安は小さくなります。取り掛かりを前倒しし、華麗なロケットスタートを切れば、仕事のほとんどが期限の2割程度の時間で終わります。
その瞬間を体験したとき、あなたの目から見えている景色は180度変わっていることでしょう。ぜひその快感を体感してみてください。
32歳でビル・ゲイツに直接プレゼンした話～「こんなきつい仕事いつまでも続けられない」と思っている全ての人へ
『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社）の「まえがき」を公開します。◇ ◇ ◇
今日も残業だ
仕事が終わらない
また先送りしてしまった
やりたいことが全然できない
もっと効率的な方法があるんじゃないか
そんなことで、日々悩んでいるみなさんに朗報です。
この本は、「好きなことに思いっきり向き合う」ための時間術の本です。もし今、時間に縛られて、人生を楽しめていない、と感じている方はぜひ、この本を最後まで読んでみてください。明日の朝起きたら、今までのあなたとはまったく違う新しい人生が始まります。
みなさんはじめまして。この本の著者、中島聡と申します。私はプログラマーとして、米マイクロソフト本社でWindows95の開発に携わりました。パソコンに詳しくない方のためにわかりやすくお伝えしますと、「ドラッグ＆ドロップ」を世界に普及させ、「右クリック」「ダブルクリック」の概念を現在の形にしたのが私です。
これを読んで「自分とは違う、遠い世界の話だ」と思われる方もいるかもしれません。しかし、こういった「世界を変える発明」は、時間を制することで誰でも生み出せる、と言っても過言ではないのです。
その理由をお話ししたいと思います。私が29歳で、マイクロソフトの日本法人から、本社勤務になった日のことです。私は、これまでにない脅威を感じました。なぜなら、アメリカのプログラマーたちが、絵に描いたように優秀そのものだったからです。朝早くからバリバリ仕事をこなし、夕方には颯爽と帰路につく。私よりはるかに腕のいいプログラマーがごろごろいて、到底太刀打ちできるようには思えなかったのです。おまけに私は、英語も全然しゃべれませんでした。
だから私は「時間との付き合い方」と徹底的に向き合うことにしました。まず、天から与えられている時間は皆平等である。ここに気がつきました。人の能力がいきなり向上するようなことはありません。ならば時間の使い方を徹底的に突き詰めるしかない。すなわち、時間を制する者が世界を制している。私はこれが、世界で成果を上げ続けている人たちの真実の姿だと思っています。私が身近に接した、元マイクロソフト社社長のビル・ゲイツこそ正にその中の一人でした。
その結果、32歳のときにビル・ゲイツの前でプレゼンをし、自分の提出した仕事が認められることになりました。それがWindows95です。
それらの実績が出せたこともあり、私は40歳のときに起業を決意しました。マイクロソフトを辞めると言うと、当時CEOだったスティーブ・バルマーは、私が退社する日の朝7時に、直接訪ねて引き留めてくれました。アメリカのベンチャー・キャピタル（投資家）は、起業の経験もない私に150万ドル（現在のレートで約1億7千万円）もの資金を出してくれました。どれも、身に余るほどありがたいことで、感謝してもしきれません。
もちろん、やりたいことがすべてできたわけではありませんし、関わったプロジェクトの成功率は3割くらいです。寝る間を惜しんでプログラムを書き続けなければいけないことはしばしばあるし、なかなかとれないバグ（不具合）で苦しむこともあります。新しい言語や開発環境を短期間で習得しなければならないときなど、肉体的にも精神的にも自分を酷使しなければいけません。
自分に鞭打って、眠い目をこすりながらパソコンに立ち向かわなければならないこともよくあります。つらいときがまったくないかと言えば嘘になります。
しかし、時間を自分の手の中に取り戻し、時間を最大限にまで効率的に運用し続ければ、もしかしたら2倍以上の能力差のある優秀な人たちをも出し抜けるのではないか、と思っていました。恐れるべきは失敗することではなく、自分の「やりたい」という思いに不誠実になることだったからです。
すると結果として、幸せな人生を手に入れることができたのです。
「やりたいこと」を実践するよう努力し続けていたら、結果を出すことができた、というわけです。
その結果を出すための自分のやり方を、今回私は「ロケットスタート時間術」と名付けました。本書では、みなさんにこの方法を最速で身に付け、一生定着させていけるように、次のような流れでお伝えしていきます。
「なぜあなたの仕事が終わらないのか？」を解き明かし、あなたのこれまでについて振り返っていただきます。敵を知り己を知れば百戦危うからず、だからです。
2章 「ロケットスタート時間術」を手に入れると、あなたにどんないいことがあるかを説明することで、時間を効率的に使うことの楽しさを実感していただきます。
3章 「ロケットスタート時間術」がいかにして生み出されてきたかをお伝えします。小・中学校時代、高校・大学時代、社会人になってから起業するまで、どう時間に向き合ってきたかの話が出てきます。
4章以降メインとなるノウハウのすべてを公開していきます。
本書は時間術の本です。ですが単純に、ノウハウをみなさんに教えるためだけに紙幅のすべてを割くことはしません。方法論の公開と同時に、たくさんの例とたくさんの比喩、たくさんの概念を織り交ぜて時間そのものの核心に迫っていきます。
そんな風なので、ノウハウの説明に至る以前の3章までをまどろっこしく感じる方もいるかもしれません。しかし全体を読み通していただいた後に、3章までの真の価値をきっとご理解いただけるはずです。なぜなら、ノウハウをあなたに伝えることは、私の本書での仕事のほんの一部にすぎないからです。
ドイツの文豪ゲーテは、「知ることだけでは十分ではない、それを使わないといけない。やる気だけでは十分ではない、実行しないといけない」と言いました。本書全体を通して私は、あなたにロケットスタート時間術を実践していただけるよう、丁寧に働きかけていくつもりです。
そのことをお伝えするために、これからあなたと一緒に私も、まるまる一冊をかけて「時間を探す旅」へと漕ぎ出していきたいと思います。時間そのものに対してそんな見方をしているのだ、こんな時間の使い方があるのだ、ということを発見しながら読んでいただければと思います。
一度立ち止まって、時間の使い方に徹底的に向き合う。
あなたが本当に効率的な仕事の仕方を身に付け、忙しさから解放されたいのであれば、一度立ち止まる勇気を「今」ここで持たなければなりません。
この本の「ロケットスタート時間術」は、あなたの苦しみを、今度こそ根本から治癒するために生まれたものです。あなたが「時間の手綱を自分の手に取り戻し」、自分の人生と世界を制する一助となれば、これほどうれしいことはありません。
世界を変えたのは「締め切りを守る男」だった
【世界を一変させたWindows95の設計思想を生み出した元マイクロソフト伝説のプログラマーが教える人生を制するスピード仕事術】
徹夜ナシ、残業ナシで、能力の高い人に勝てる。こんな一生ものの仕事術を、ぜひ身につけてみませんか?
まじめに働いているのに仕事が終わらない人の特徴
６月１日に発売した『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』から、書籍の内容を一部公開。
頑張っている割には仕事を期日内に終わらせることができない人の仕事に対する姿勢を若干誇張して書いています。
私はこれまで大勢のエンジニアと仕事をして来ましたが、大半の人が「追い詰められないと頑張れない」という「ラストスパート型」のエンジニアです。彼らは「いつ頑張るか」の違いでしかないと思っていますが、それは大きな勘違いです。ラストスパート型で仕事をすると、余裕がないために、痛みを伴う変更ができず、抜本的な問題を先送りして、その場しのぎだけをすることになり、結果的に良い仕事が出来ないのです。
良い仕事をしたければ、スタートダッシュ型で働き、余裕のあるうちに難しい問題、根本的な問題から先に解決して行くしかないのです。
◇ ◇ ◇
金曜日
「これ、1週間でよろしく」あなたはたった今、上司から新たな仕事を任されました。今日は金曜日。締め切りは1週間後の来週金曜日です。7日あればその仕事は確実に終わるでしょう。
しかしあなたは、ほかにも来週の月曜日締め切りの仕事を抱えています。優先順位を考えれば、3日後が締め切りの仕事を先にやらなければいけません。あなたは頑張って、3日後が締め切りの仕事を今日中に終わらせました。お疲れ様でした。週末2日間、ゆっくり休んでください。
月曜日
さて、月曜日がやってきました。先週の金曜日に頼まれた新規の仕事に取り掛かります。締め切りまで5日あるわけですから、たぶん終わるでしょう。「まあ、でもほかにも仕事はあるしな」
あなたは新規の仕事はいったん脇に置き、メールの返信や長期で抱えているほかのプロジェクトを進めていきました。もちろんそのあいだに、新規の仕事をどう終わらせるかというスケジュールも考えていました。
水曜日
期限まであと2日……。「これじゃ終わらないかもしれない……」
スケジュールを考えていたとはいえ、頭の中でやるのと実際にやるのとは違います。なんとなく終わらなそう、と予感したあなたは、ほかの仕事を放棄して、あと2日しかない仕事に本格的に取り組むことにしました。
木曜日
締め切り前日、木曜日の夜のことです。メールの返信やほかの緊急の打合せなどで時間を取られたあなたは、ついに徹夜で仕事をしなくてはならなくなりました。締め切りまであと数時間。あなたは必死に仕事を進めていきます。金曜日
「例の件、終わった？」翌日の金曜日、あなたは上司から仕事について尋ねられました。背筋に寒気が走り、冷や汗が額を伝います。あなたは徹夜で赤くなった目を瞬きしながらこう言いました。
「すみません、ほかの仕事もありまして、徹夜もしたのですが……もう1日いただけないでしょうか……」
その後の顛末はみなさんの想像にお任せします。
じつはこの話、実際にいた私の部下であるＡくんが、知り合った当初にやったことでした。Ａくんは従順な部下に見えました。仕事を頼むと、彼はいつも「はい！ やります！」「かしこまりました！」「承知しました！」と言います。いつも文句を言わずに仕事を引き受けてくれます。上司としてこんなにありがたい部下はいません。
けれどもＡくんは、仕事にどのくらい時間がかかるのかという見積もりを甘く見ていました。いつも仕事を与えられた際に、ぺろっと仕様書を見ただけで、理想の完成日時を予告してしまうのです。
Ａくんの仕事は、上司である私の側から見るとこう見えています。
締め切りが1週間後の仕事をお願いした後、Ａくんは毎日まじめに仕事をしていました。途中、ほかのこまごまとした仕事を任されることもありましたが、頼んだ仕事もちゃんとやっているようでした。土日も体を休め、余裕を持って仕事をしているようでした。このような姿を見ると上司としても安心です。
ところがある日のこと。会社に行くと、Ａくんがオフィスで一人寝ていました。どうしたのかと聞くと、どうやら徹夜で仕事をしていたようです。「大丈夫？ ちゃんと終わる？」と私が聞くと、「大丈夫です！ 頑張ります」と答えました。締め切り前日の木曜日のことです。
私は不安になってきました。とはいえ、大丈夫と言われたからには手出しはできません。Ａくんはまじめな部下です。仕事で手を抜いたり、適当な完成度で放り投げたりはしません。だからきっと、任せた仕事はほとんどもう終わっていて、クオリティを上げるために時間を費やしているのだろうと思っていました。そして締め切りの金曜日、Ａくんは私にこう言いました。
「すみません、ほかの仕事もありまして、徹夜もしたのですが……もう1日いただけない
でしょうか……」
Ａくんは毎回毎回適当に仕事をしているわけではありませんでした。もちろん規定どおりの仕事を、ちゃんと納期ぴったりに出してくることもありました。しかし、ほかの案件や、メールの返信などのこまごました仕事にも意外と時間がかかることを織り込んでいないため、仕事を終わらせることができなくなるのです。
その後もＡくんは毎回締め切りギリギリになって「すみません、終わりませんでした」と謝ってきました。それも、眉を下げ、本当に申し訳なさそうに言うのです。Ａくんは毎度徹夜で仕事を頑張るので、目を赤くして私のところに来ます。
「徹夜したのですが……」
それが何回も何回も続いたのです。
3か月ほど経ったころ、これはさすがに注意しないといけない、ということで私はＡくんを厳しく叱りました。仕事が遅いからちゃんとやってくれと。反省しているのかと。遅れるなら仕方がないけど、間に合わないと思った段階で早く報告してくれと。
私のほうでも、Ａくんがしっかり仕事できるように様々な工夫を試みました。たとえば、その会社では基本的に2週間単位の仕事を割り振っていたのですが、彼には3日単位の小さな仕事を割り振ってみたりしました。あるいは単に仕事の量を半分にしたりもしました。しかし結果は変わらず、Ａくんはいつも最後には「終わりませんでした」と言ってきました。
Ａくんは、仕事自体はデキるのです。そこそこ優秀なプログラマーだったといえるでしょう。けれども彼は時間を使うのがとても苦手でした。仕事の量をいくら減らしても終わらないというのは、そういうことなのでしょう。
Ａくんはその後、会社から幾度も勧告を受けたにもかかわらず、まったく改善が見られないため、残念ながら、1年後に私のチームにいてもらえなくなってしまいました。私も上司として力不足でした。
Ａくんのように、締め切り間際にラストスパートで仕事を終わらせようとする人の態度を「ラストスパート志向」といいます。のちにお話ししていきますが、ラストスパート志向は、仕事をするうえで最も避けるべきことです。
テストを解き終えられない人と仕事が終わらない人の共通点
『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』からの引用ですが、ここだけ読むと誤解されそうなので解説しておきます。
試験の場合は「とりあえず簡単な問題から解いておいて可能な限りの点を稼いでおく」という戦略も成り立ちますが、仕事の場合には「基本的に全ての仕事を期日内に終えるべき。万が一終えられない可能性がある場合には、早めに知らせるべき」という制約があります。
そのため、仕事の場合には、難しい問題（試験であれば最後の応用問題）から取り掛かり、早めにめどをつけるなり、「期間内には終わりそうもない」という警告を出すかすべきだ、という話です。
◇ ◇ ◇
いつまでも仕事が終わらない人は、その仕事にどのくらい時間がかかるのか、という見積もりを甘く見ていることが多くあります。そこで、仕事にかかる時間の見積もりについて、数学のテストを例にして考えてみましょう。
一般的に数学のテストは、前半に単純な計算問題があり、後半に難易度の高い文章問題が配置されています。前半に基本問題、後半に応用問題があるわけです。前半の基本問題はいわゆるサービス問題です。ちゃんと授業を聞いて、式の解法を知っていれば、地道にやるだけで確実に解けます。どんなに数学が苦手でも、時間を使えば必ず解けるはずです。
一方後半の応用問題は、ただ解法を知っているだけでは解けないことが多いです。解法を知ったうえで、特殊なテクニックや論理性が問われます。こちらの問題は基本問題のように時間さえあれば解けるわけではありません。瞬時に答えまでの道筋がひらめくこともあれば、定理の本質を理解していないせいでドツボにはまってしまうこともあります。
応用問題の難しいところは、問題を解くのにどれくらいの時間がかかるのかが未知数であるという点にあります。基本問題はただの計算ですので、一問解くのにどれくらいかかるかがなんとなくわかります。けれども応用問題は、先ほど述べたように一瞬でわかることもあれば、果てしなく時間がかかることもあります。そこが難しいところです。
みなさんもお気づきのように、数学のテストは仕事と似たところがあります。手を動かすだけで終わる単純作業もあれば、一見しただけではどのくらいかかるかわからない頭を使う仕事もあります。
仕事が終わらない人は、得てして後半の応用問題を甘く見ています。前半の基本問題をとんとん拍子に解いていくなかで、「こんなの簡単に終わるじゃないか」と錯覚するのです。
しかしそれは根本的な勘違いです。応用問題がどのくらいで終わるかは、取り掛かってみないと絶対にわかりません。そして応用問題が終わらなければ仕事は終わりません。
ですから応用問題に取り掛からないうちは、まだ仕事がどのくらいで終わるか判断できないのです。つまり、決まった期日内に終わらせることが重要な仕事の場合、まず取り掛かるべきは複雑な応用問題のほうなのです。
多くの人が仕事を与えられた際、簡単に仕様書を見ただけで「できます！」と判断していました。数学のテストの例でいうと、愚直に前半の基本問題から解いていき、最後に応用問題に直面したところで「これは終わりそうにない……」と気づく、という人です。
石膏像を彫るとき、 「眉毛」から始める人はいない
６月１日発売の「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」。瞬間風速に終わらないように、一部を公開します。
◇ ◇ ◇
石膏像を彫るとき、 「眉毛」から始める人はいない
多少のバグを無視して、とりあえず大枠を作ったものをプロトタイプ（試作品）といいます。これはプログラムの話に限らず一般的な仕事においても応用できる、より抽象的な概念であると理解してください。
会社の企画を任されたときにプロトタイプを作ると、全体のイメージが固まります。イメージが固まっていると上司もプロジェクトの進行を理解しやすいので、企画が通りやすくなります。また、何より自分自身がプロジェクトを進行するときに、仕事がやりやすくなります。
プログラムに限らず、大抵の仕事の全体図は実際にやってみないと描けません。企画書という紙の上だけで考えても大体思ったとおりになることはないのです。みなさんもそういう経験がおありだと思います。
ですからプロトタイプの作成に速やかに入り、ある程度まで作ったうえで、どのくらいの難易度かを考えつつ仕事を進めていくのが賢いやり方です。
プロトタイプを作らず愚直に細部を突き詰めていった場合、締め切り間際になって「ここは設計から作り直さなければならない」という事実に気づくことがあります。そうなると危険です。締め切り間際では、大枠の設計を変更する時間もないので、完成品はろくでもないものになります。
一方プロトタイプを作っていると、「ここは作り直さなければならない」という事実を早期に発見できます。そうしたら設計図を作り直せばいいのです。プロトタイプを作っている段階ならば、いくらでも直しが効きます。
よくこういった話を、石膏の彫刻の例を出して説明することがあります。石膏を削って胸像を作るとき、いきなり眉毛の一本一本にこだわって細い彫刻刀を使う人はいません。そんなことをしても、後になって全体のバランスがおかしくなって失敗するだけです。普通はまず大きく輪郭を粗削りするところから始めます。つまりプロトタイプを作るとは、そういうことなのです。
仕事が遅くて終わらない人が陥る心理として、「評価されるのが怖い」というものがあります。自分の仕事がどう評価されるのかが怖くて、できるだけ自分の中の100点に近づけようとしてブラッシュアップを繰り返します。
しかしブラッシュアップすればするほど、もっと遠くに100点があるような気がして、いつまでたってもこのままじゃ提出できないという気持ちになります。そして、そうして時間をかければかけるほど、上司からはクオリティを期待されているような気がして、恐怖に拍車がかかります。
このループに陥る人の状態を「評価恐怖症」といいます。1章の「なるはや病」と同じく、日本の一部で蔓延している病です。評価恐怖症にかかった人は、自分の中での100点満点を目指すあまり、本来なら終わる仕事も終わらなくなります。
たしかにそうして仕事が遅れてしまう心理はよくわかります。粘り強くいいものを作ろうとする気持ちも決して失ってはいけないと思います。そして、そうした気持ちこそが優れた製品やサービスを作るのだとも思っています。
しかし、すべての仕事は必ずやり直しになる、くらいの覚悟が必要です。荒削りでもいいから早く全体像を見えるようにして、細かいことは後で直せばいいのです。そうした気持ちでいれば、評価恐怖症でいることも、あまり大したことではないとわかるはずです。あなたはプロトタイプを最速で作るべきなのであって、細かいところは後から詰めて考えればいいのです。
ビルゲイツ向けのプレゼン会議は常に「質疑応答」しか無かった
６月１日に発売した『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』より書籍の内容を少しづつ紹介。
以下抜粋です。
◇ ◇ ◇
「出勤前の服選び」で疲れてどうする
効率化といえば、「世界の偉人はいつも同じ服を着ている」ということが一部で知られています。
たとえばフェイスブックのマーク・ザッカーバーグはい つもグレーのＴシャツにジーンズをはいています。アップルのスティーブ・ジョブズは黒のタートルネックにジーンズをはいていました。オバマ大統領はグレー かブルーのスーツを着ています。
彼らはなぜそういうことをしているのでしょうか。それは彼らが日常のささいな決断の数を減らそうとしているからだそうです。
日々たくさんの人と会い、様々な意思決定を行う彼らは、普段から大きな決断を迫られています。そのため会社の経営や政治に関わる重大な決断をするときに脳が疲れないよう、無駄な決断をしないようにしているのだそうです。無駄な決断とは、ここでは服選びのことを指します。
心理学では、決断や意思決定をする際に減少する気力のようなものを「認知資源」という名前で呼んでいます。この言葉を使うと、つまり世界の偉人は、認知資源を経営や政治のために温存しているということになります。服選びなどのつまらない決断で疲れるのを避けようというわけです。
私は認知資源という言葉は最近まで知らなかったのですが、「決断疲れ」を避けようとする偉人たちの気持ちはとてもよくわかりました。私は毎日服を着る際、いつも箪笥（たんす）を3センチだけ開けて、一番手前にある服を着ることにしています。服で何か仕事に影響があるとは思っていないからです。服装が仕事のパフォーマンスに影響するならともかく、そうでないことがはっきりしているのに、服にいちいち気を遣う必要はあまりないのではないでしょうか。
服選びならともかく、もっと時間を取るものがあります。それは表敬訪問です。とくに用事はないけれども、ご挨拶という触れ込みで訪ねる不思議な文化です。あれは無礼の表明になりこそすれ、敬意の表明にはなりません。
ビル・ゲイツは私よりももっと先鋭化させた考えを持っています。最初に私が驚いたのは、彼が何らかの説明を社員から聞くときに、直接その社員からは話を聞かないことです。彼は情報をかみくだき、彼にわかりやすく説明してくれる専門の社員を雇っていたのです。私たち社員は、ビル・ゲイツに何か説明をするとき、その専門の社員に説明をします。するとその専門の社員がビル・ゲイツにわかりやすく説明をするのです。
一般のスタッフの中には、説明がうまい人もいれば下手な人もいます。そんな中でビル・ゲイツがいちいち顔を合わせて聞いていたら、膨大な時間がかかります。だから彼は、コストをかけてでも、説明を聞く時間を効率化するために専門のスタッフを雇っていたのです。
当時ビルは、常時二人の説明専門家を雇っ ていました。
さらに、彼が参加するプレゼン会議では、発表者が発表をする時間は設けられません。彼のいうプレゼン会議とは、発表者との質疑応答の時間のことを指します。したがってスライドを動かしながら説明をするといったことはしません。資料は前もって送り、当日、質問を受けるだけです。これは究極の効率化です。
そこまで効率化を図りつつも、しっかりと会議をする目的は果たします。会議室に入っていきなり「3ページ目の開発は、ほかのグループがやってるけど、君は知らないのか」など鋭い突っ込みが入ります。そして会議は最長で 30 分という時間が決められています。ですのでちゃんと受け答えの準備ができていないと、うなだれて帰るのがオチになります。
ビル・ゲイツはとにかく仕事の効率化を図っている人です。私も彼ほどまでに厳しくはできませんが、ビル・ゲイツが世界一の大金持ちになった理由の一端は、彼の時間の使い方にあったのだと確信しています。
米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。
◇ ◇ ◇
あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはOSの開発に関する派閥争いがありました（OSとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。
＂カイロ＂というグループと＂シカゴ＂というグループの対立です。
もともとカイロが、前作のWindows 3.1に続く次世代ＯＳを開発する予定だったのですが、カイロは進捗が悪く、そのあいだを埋めるためにシカゴというグループが結成されました。
シカゴはハッカーを寄せ集めた職人集団というイメージで、スタンフォード大学の博士号を取ったような人たちばかりのカイロとはまったく毛色が違いました。
私はもともとカイロに所属していたのですが、退屈なミーティングが多くて嫌だったので、上司と喧嘩したのをきっかけにシカゴに移りました。シカゴならカイロよりも風通しがよく、自分のアイデアもすぐ仕事に反映できると思ったからです。
シカゴに移った私は、カイロにいたころに取り組んでいたプログラムを一部持ち込んできました。一言でいえばアイデアを盗んできたということになりますが、同じ社内だし、そもそもそのプログラムをカイロで設計したのは私だったので、犯罪でも何でもなかったのです。
しかしその後、カイロの人たちに、アイデアをシカゴに持っていったことがばれ、怒られました。スパイだとも言われました。カイロの人たちは社長であるビル・ゲイツに直談判して社内裁判を開きました。
シカゴでの私の上司は、「今度ビル・ゲイツの前でプレゼンすることになったから、全部君に任せるね」とあっさり私に告げました。それにもびっくりしたのですが、それ以上に、カイロから送られてきた資料にも驚きました。約400ページの資料には、私がシカゴに移って組み上げたプログラムが、いかに張りぼてで手抜きかということが延々と書かれていたからです。
たしかにその指摘は間違っていませんでした。前述したように、私は「兵は拙速を尊ぶこそ仕事の要諦」と考えています。早く仕事に着手することを起点にして、 70 点でも 80 点でもいいから速攻で仕事全体をまず終わらせてみることこそ重要という主義です。そういう風ですから、細かいバグが膨大にあったことは認めます。
しかしそれにしても、カイロの頭でっかちのサイエンティストたちは机上の空論ばかり振りかざしているように見えました。こんな細かい指摘ばかりしていては、いつまで経っても仕事は終わりません。この400ページの資料も全部読もうとしても眠くなってしまうので、数ページめくってからそっと閉じ、社内裁判に出席することに決めました。
プレゼンの日は刻々と近づいていましたが、プレゼン資料を用意する気にもなりませんでした。技術的に細かなことで闘うのではなく、これはマイクロソフトのカルチャーに関わる問題だということを明らかにしたほうが良いと思ったのです。カイロのような仕事の仕方では決してものは出せないことをビル・ゲイツに納得してもらうのです。
裁判当日、私は取締役会議用の会議室に通されました。そこには、マイクロソフトのトップ5のうち、営業の長であるスティーブ・バルマーを除いた全員が出席していました。副社長のブラッド・シルバーバーグとジム・オールチン、オフィス開発グループリーダーのブライアン・マクドナルド、上級副社長のポール・マリッツ、そしてビル・ゲイツ。
このそうそうたる顔ぶれを見て、私はとんでもなく重大なミーティングに参加しているということに気づかされました。
こうなると緊張どころか、逆にワクワク感が募ってきます。これだけのメンツがそろっている前で、自分の仕事の重要性を主張する機会は滅多にありません。机上の空論ばかりを繰り返しているカイロに負けるわけにはいかない。アドレナリンが血中に放出されるのを感じました。
裁判が始まりました。まずカイロ側が例の400ページの資料を出して、シカゴの仕事がいかに適当でダメダメかということを話しました。そのとき、私は400ページの資料を読んでいなかったことを後悔はしませんでした。私なりの戦い方の準備をしていたからです。
私の発言の機会が回ってきました。何も資料は作っていませんでしたが、一つだけ用意してきたものがありました。あるデータが入ったＣＤ-ＲＯＭです。その中身を披露しながら、私はビル・ゲイツの目を見据えてこう言いました。
「カイロチームの主張にも一理あるけれど、完璧なアーキテクチャ（基本設計）を追い求めていては、永遠にものは出せません。Windows95のリリースはあと6か月に迫っています。いつになったらリリースできるかわからないカイロにマイクロソフトの将来を任せるというのは、どう考えても間違っています」
次世代ＯＳをめぐるカイロとシカゴの戦いは、どちらの時間の使い方が正しいかをかけた戦いでもあるのです。
ビル・ゲイツはこのあいだずっと両手を体の前に合わせ、少し前屈みで、体をゆっくりと前後に揺らしながら聞いていました。考えながら真剣に人の話を聞いているときの彼のスタイルです。
一通りの意見を聞き終えると、ビルの体の揺れが止まりました。「何か重要な発言をするのか」と私は身構えました。しかし、ビルは単にポール・マリッツのほうを向き、目配せをしただけでした。するとポールが「ここでこのまま待つように」と言って立ち上がり、ビルと一緒に部屋から退出しました。恐らくビルの頭の中では結論が出たのでしょう。それをポールと再確認したうえで、最終決定として伝えるつもりなのです。
ビルとポールが退出していた時間はわずか3分ほどでした。けれども部屋には妙な沈黙が流れていて、私にはそれが1時間くらいに感じられました。部屋にいる全員が、次に彼らが部屋に戻ってきたときには、裁定が下され、それには誰も口をはさめないことを知っていました。シカゴとカイロという莫大な開発費をかけた2つのプロジェクトの命運が、今日この場で決まるのです。
ドアを開いて、ポールを先頭に二人が部屋に戻ってきました。運命の瞬間です。
「カイロプロジェクトはキャンセルする」
開口一番、ビルはそう言いました。カイロプロジェクトキャンセル。それはすなわち、4年にわたってカイロが開発していたＯＳをなかったものにするという意味です。その一瞬で、400人を超える大所帯のカイロを解散することを決めたのです。逆に言えば、シカゴで開発していたＯＳを、マイクロソフトの次世代ＯＳとしてリリースする方針に決定したということでもあります。
その次世代ＯＳとは何でしょうか？ それは、私が証言していたときに実際に動かしていたＣＤ-ＲＯＭにすでに格納されていました。その中身は、シカゴに移った後に完成させていたベータ版のWindows95だったのです。
この裁判はまさに、私の提出した仕事が会社のトップに認められた瞬間でした。そしてこの重要すぎる決断は、たったの3分で下されたのです。
６月１日に発売した『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』より
今回、引用するのはビル・ゲイツから学んだ「仕事」や「責任」に関する教訓です。
◇ ◇ ◇
たとえばあるパーティーがあるときに、ビル・ゲイツがあなたに花を用意してほしいと頼んだとします。あなたは花屋に電話をし、パーティー会場に花束を届けるように注文します。しかしパーティー当日、花屋から、雪のせいで配達が遅れるという電話が来ます。
あなたは花が遅れるという旨をビル・ゲイツに伝えます。こういうとき、彼は尋常じゃないほど怒ります。その怒りは、人が変わったのではないかと思うほどです。それだけ締め切りまでに仕事を終えることを重視しているのです。
あなたが命じられた任務はパーティーに花を用意することであり、花屋に注文をすることではありません。注文をするだけなら誰にでもできます。あなたは花を用意するために雇われているのです。であれば、いかなる理由があっても花を用意することができなかったのは100％あなたの怠慢であり、責任を負うべきだというのです。
ですから、もし花屋が雪の影響で配達が遅れるというならば、あなたはなんとしてでも花をパーティー会場に用意するための手段を考えなければいけません。車で近くの花屋まで行くとか、ほかの花屋に至急注文をするとか、そういった第二第三の案をただちに遂行しなければなりません。
あなたの任務は花を用意することです。花さえ用意できれば、パーティー会場の裏で昼寝をしていてもいいのです。だからこそ花は絶対に用意しなければならない。花屋に注文をすることは任務の一部でしかありません。言い訳をする人はそこを勘違いしています。
待ち合わせの例でいえば、大抵の人は 10 時前に到着する電車に乗ることだと思っています。しかし本当の任務は、 10 時に待ち合わせ場所に着くことです。
このように自分の中で任務を再定義することが仕事においても重要です。私はビル・ゲイツほど厳しい人間にはなれませんが、自分の中で絶対にやらなければならないものとは何かを真剣に考えることは大事なことだと思っています。
たとえば、こんな例で考えてみましょう。ある日、ビル・ゲイツがカレーライスを作ろうとしたとき、なんとカレールーとニンジンがありませんでした。これではいつものカレーライスが作れません。しかしよく考えてみてください。ルーがないと絶対にカレーライスは作れないでしょうか？ ニンジンがないとカ レーライスは作れないでしょうか？
そんなことはありません。ルーは市販のカレー粉で代用できるし、ニンジンはなくても一応カレーライスにはなります。つまり、ルーがないという問題と、ニンジンがないという問題は独立しています。だからここは慌てず、「ルーをどうするか」「ニンジンをどうするか」という分割された課題に、別々に当たればいいわけです。
ビル・ゲイツはその後、カレー粉とじゃがいもを使ってカレーライスを作っておいしくいただきました。
やや抽象的な話だったので、現実にあった事件を例に挙げます。マイクロソフトがパソコンメーカーにソフトを依頼されたとき、ある技術的な問題により、パソコンメーカーから苦情が来たことがありました。クライアントがたいそう怒っているということで、社内は混乱していました。とにかく、原因の技術的問題を解消しなければこの問題は収まらない。マイクロソフトの社員はみんなそう思い込んでいました。
そんなとき、ビル・ゲイツは困難を分割しました。技術的問題はクライアントの怒りからは独立した問題だと。どうやらクライアントが怒っているのは技術的問題よりも、担当者との性格の不一致に原因があったようです。そうして担当者は替えられ、クライアントをとにかくなだめる任務に就くことになりました。他方で技術的問題はエンジニアたちが全力で解決に向かってまい進していました。
こうしてクライアントとマイクロソフトの関係は、なんとか立ち直ったのです。技術問題と外務問題を切り分けることで、この事件は終息を迎えました。ビル・ゲイツが「その問題とこの問題は独立している」とよく言っていたことを覚えています。こうした課題の分割は、複雑な問題を効率的に解決するうえで重要なことだと思っています。
それまでのＯＳでは、あらゆる操作をキーボードでのコマンド入力（コマンドと呼ばれる文字例をキーボードから入力し、コンピューターに命令すること）で実行していました。マウスは存在していましたが、まだ今ほど便利で優れたツールではありませんでした。では、Windows95で何が起きたのでしょうか？
それはみなさんおなじみの右クリックとダブルクリック、そしてドラッグ＆ドロップの現在の形への進化です。この概念を私は、ビル・ゲイツの前での公開裁判の中で披露した、ベータ版の中にすでに組み込んでいました。
みなさんご存じのとおり、 Macintoshのマウスにはボタンが1つしかありません。これは昔からそうです。一方、 Windowsにはボタンが2つあります。とはいえ当時は左ボタンを使うことがメインで、右のボタンは今ほど使うことはありませんでした。
しかしWindows95になってから、右クリックの使い勝手は飛躍的に向上しました。デスクトップ画面の何もないところで右クリックすることで、画面のプロパティやアイコンの整列などの操作をするメニューが開きます。テキストファイルの上で右クリックすると同様にメニューが開きます。
また、ドラッグ＆ドロップも大きな変化の一つです。たとえば、要らない文書ファイルのアイコンをクリックしたまま「ごみ箱」のアイコンの上に持っていけば、文書ファイルを削除することができます。 Windows95はユーザーがパソコンに詳しくなくても簡単に操作できるように、グラフィカルな設計がなされたのです。今の感覚からするとずいぶん当た り前なことですが、当時としては画期的なことでした。
グラフィカルな設計といえば、ダブルクリックもそうです。文書ファイルのアイコンをダブルクリックすると自動的にワープロソフトの編集画面が立ち現われ、音楽ファイルのアイコンをダブルクリックすると自動的にプレーヤーが立ち現われて再生が始まります。
ファイルをシングルクリックした場合、その後ユーザーが選択するコマンドは「ファイルの編集」「コピー」「転送」「再生」など、様々な種類が考えられます。しかしダブルクリックは、文書ファイルなら文書ファイル、音楽ファイルなら音楽ファイルといった対象を選択したうえで、ダブルクリックという操作をするだけで、自動的に「編集する」「再生する」といったコマンドが選択されるのです。
このように、何らかの対象（オブジェクト）を先に選択したうえで動作を指定することをオブジェクト指向といいます。
オブジェクト指向のわかりやすい例として、私たちがいつも使っている日本語が挙げら
れます。
あなたがテーブルの上の塩を取ってほしいとき、あなたは「すみません、塩を……」まで言葉にしたところで一呼吸置くと思います。それはなぜなら、「塩」という対象を指定した時点で、あなたが相手にしてほしいことは決まり切っているからです。相手もそれをわかっているので、「塩をどうしろっていうんですか？」なんて野暮なことは聞きません。
エレベーターに乗り合わせた人に「すみません、12階を……」と言うのも同じことです。これも 12 階という対象を指定した時点で、12階のボタンを押してほしいということは決まり切っています。これはWindowsにおけるダブルクリックと非常によく似ていると思いませんか？
このようなグラフィカルでオブジェクト指向な機能を思いつくことができたのは、もしかしたら私が当時マイクロソフトで唯一の日本語話者だったからかもしれません。
日本人的な会話の作法を取り入れた結果、 Windows95が世界を席巻したと考えると、感慨深く思います。
先日も、深夜に口もききたくないくらい疲れ切ってタクシーに乗ったときに、この「オブジェクト指向」言語である日本語を理解する運転手（平たく言えば普通の運転手）に助けられました。そこでは次のような会話が展開されました。
「すみません、経堂まで……」
「はい、経堂までですね。道はどうしましょう？」
「あ、環七経由で……」
「はい、環七から赤堤通りですね」
（しばらくして）
「その信号を左に……」
「はい、ここを左ですね」
「それで、そこの行き止まりの所で……」
「はい、かしこまりました」
中島聡
Ex-Microsoft (software architect, Windows95 and IE3/4)
◇ ◇ ◇
ビル・ゲイツの意思決定は光速
ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはOSの開発に関する派閥争いがありました（OSとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。
＂カイロ＂というグループと＂シカゴ＂というグループの対立です。
もともとカイロが、前作のWindows 3.1に続く次世代ＯＳを開発する予定だったのですが、カイロは進捗が悪く、そのあいだを埋めるためにシカゴというグループが結成されました。
シカゴはハッカーを寄せ集めた職人集団というイメージで、スタンフォード大学の博士号を取ったような人たちばかりのカイロとはまったく毛色が違いました。
私はもともとカイロに所属していたのですが、退屈なミーティングが多くて嫌だったので、上司と喧嘩したのをきっかけにシカゴに移りました。シカゴならカイロよりも風通しがよく、自分のアイデアもすぐ仕事に反映できると思ったからです。
シカゴに移った私は、カイロにいたころに取り組んでいたプログラムを一部持ち込んできました。一言でいえばアイデアを盗んできたということになりますが、同じ社内だし、そもそもそのプログラムをカイロで設計したのは私だったので、犯罪でも何でもなかったのです。
しかしその後、カイロの人たちに、アイデアをシカゴに持っていったことがばれ、怒られました。スパイだとも言われました。カイロの人たちは社長であるビル・ゲイツに直談判して社内裁判を開きました。
シカゴでの私の上司は、「今度ビル・ゲイツの前でプレゼンすることになったから、全部君に任せるね」とあっさり私に告げました。それにもびっくりしたのですが、それ以上に、カイロから送られてきた資料にも驚きました。約400ページの資料には、私がシカゴに移って組み上げたプログラムが、いかに張りぼてで手抜きかということが延々と書かれていたからです。
たしかにその指摘は間違っていませんでした。前述したように、私は「兵は拙速を尊ぶこそ仕事の要諦」と考えています。早く仕事に着手することを起点にして、 70 点でも 80 点でもいいから速攻で仕事全体をまず終わらせてみることこそ重要という主義です。そういう風ですから、細かいバグが膨大にあったことは認めます。
しかしそれにしても、カイロの頭でっかちのサイエンティストたちは机上の空論ばかり振りかざしているように見えました。こんな細かい指摘ばかりしていては、いつまで経っても仕事は終わりません。この400ページの資料も全部読もうとしても眠くなってしまうので、数ページめくってからそっと閉じ、社内裁判に出席することに決めました。
プレゼンの日は刻々と近づいていましたが、プレゼン資料を用意する気にもなりませんでした。技術的に細かなことで闘うのではなく、これはマイクロソフトのカルチャーに関わる問題だということを明らかにしたほうが良いと思ったのです。カイロのような仕事の仕方では決してものは出せないことをビル・ゲイツに納得してもらうのです。
裁判当日、私は取締役会議用の会議室に通されました。そこには、マイクロソフトのトップ5のうち、営業の長であるスティーブ・バルマーを除いた全員が出席していました。副社長のブラッド・シルバーバーグとジム・オールチン、オフィス開発グループリーダーのブライアン・マクドナルド、上級副社長のポール・マリッツ、そしてビル・ゲイツ。
このそうそうたる顔ぶれを見て、私はとんでもなく重大なミーティングに参加しているということに気づかされました。
こうなると緊張どころか、逆にワクワク感が募ってきます。これだけのメンツがそろっている前で、自分の仕事の重要性を主張する機会は滅多にありません。机上の空論ばかりを繰り返しているカイロに負けるわけにはいかない。アドレナリンが血中に放出されるのを感じました。
裁判が始まりました。まずカイロ側が例の400ページの資料を出して、シカゴの仕事がいかに適当でダメダメかということを話しました。そのとき、私は400ページの資料を読んでいなかったことを後悔はしませんでした。私なりの戦い方の準備をしていたからです。
私の発言の機会が回ってきました。何も資料は作っていませんでしたが、一つだけ用意してきたものがありました。あるデータが入ったＣＤ-ＲＯＭです。その中身を披露しながら、私はビル・ゲイツの目を見据えてこう言いました。
「カイロチームの主張にも一理あるけれど、完璧なアーキテクチャ（基本設計）を追い求めていては、永遠にものは出せません。Windows95のリリースはあと6か月に迫っています。いつになったらリリースできるかわからないカイロにマイクロソフトの将来を任せるというのは、どう考えても間違っています」
次世代ＯＳをめぐるカイロとシカゴの戦いは、どちらの時間の使い方が正しいかをかけた戦いでもあるのです。
ビル・ゲイツはこのあいだずっと両手を体の前に合わせ、少し前屈みで、体をゆっくりと前後に揺らしながら聞いていました。考えながら真剣に人の話を聞いているときの彼のスタイルです。
一通りの意見を聞き終えると、ビルの体の揺れが止まりました。「何か重要な発言をするのか」と私は身構えました。しかし、ビルは単にポール・マリッツのほうを向き、目配せをしただけでした。するとポールが「ここでこのまま待つように」と言って立ち上がり、ビルと一緒に部屋から退出しました。恐らくビルの頭の中では結論が出たのでしょう。それをポールと再確認したうえで、最終決定として伝えるつもりなのです。
ビルとポールが退出していた時間はわずか3分ほどでした。けれども部屋には妙な沈黙が流れていて、私にはそれが1時間くらいに感じられました。部屋にいる全員が、次に彼らが部屋に戻ってきたときには、裁定が下され、それには誰も口をはさめないことを知っていました。シカゴとカイロという莫大な開発費をかけた2つのプロジェクトの命運が、今日この場で決まるのです。
ドアを開いて、ポールを先頭に二人が部屋に戻ってきました。運命の瞬間です。
「カイロプロジェクトはキャンセルする」
開口一番、ビルはそう言いました。カイロプロジェクトキャンセル。それはすなわち、4年にわたってカイロが開発していたＯＳをなかったものにするという意味です。その一瞬で、400人を超える大所帯のカイロを解散することを決めたのです。逆に言えば、シカゴで開発していたＯＳを、マイクロソフトの次世代ＯＳとしてリリースする方針に決定したということでもあります。
その次世代ＯＳとは何でしょうか？ それは、私が証言していたときに実際に動かしていたＣＤ-ＲＯＭにすでに格納されていました。その中身は、シカゴに移った後に完成させていたベータ版のWindows95だったのです。
この裁判はまさに、私の提出した仕事が会社のトップに認められた瞬間でした。そしてこの重要すぎる決断は、たったの3分で下されたのです。
デカルトは「困難を分割せよ」と言い、ビル・ゲイツは「問題を切り分けろ」と言った
６月１日に発売した『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』より
今回、引用するのはビル・ゲイツから学んだ「仕事」や「責任」に関する教訓です。
◇ ◇ ◇
花さえ用意できれば、 裏で昼寝していてもいい
友人との待ち合わせならともかく、仕事の締め切りに遅れてしまうのは絶対に避けたいものです。私はマイクロソフトにいたころ社長のビル・ゲイツと仕事をしていました。そのため彼の考えはよく知っているのですが、彼は待ち合わせや締め切りに遅れた人がする言い訳をこの世で一番嫌っていました。とくに論理的に言い訳する人を嫌うのです。どういうことかお話ししましょう。たとえばあるパーティーがあるときに、ビル・ゲイツがあなたに花を用意してほしいと頼んだとします。あなたは花屋に電話をし、パーティー会場に花束を届けるように注文します。しかしパーティー当日、花屋から、雪のせいで配達が遅れるという電話が来ます。
あなたは花が遅れるという旨をビル・ゲイツに伝えます。こういうとき、彼は尋常じゃないほど怒ります。その怒りは、人が変わったのではないかと思うほどです。それだけ締め切りまでに仕事を終えることを重視しているのです。
あなたが命じられた任務はパーティーに花を用意することであり、花屋に注文をすることではありません。注文をするだけなら誰にでもできます。あなたは花を用意するために雇われているのです。であれば、いかなる理由があっても花を用意することができなかったのは100％あなたの怠慢であり、責任を負うべきだというのです。
ですから、もし花屋が雪の影響で配達が遅れるというならば、あなたはなんとしてでも花をパーティー会場に用意するための手段を考えなければいけません。車で近くの花屋まで行くとか、ほかの花屋に至急注文をするとか、そういった第二第三の案をただちに遂行しなければなりません。
あなたの任務は花を用意することです。花さえ用意できれば、パーティー会場の裏で昼寝をしていてもいいのです。だからこそ花は絶対に用意しなければならない。花屋に注文をすることは任務の一部でしかありません。言い訳をする人はそこを勘違いしています。
待ち合わせの例でいえば、大抵の人は 10 時前に到着する電車に乗ることだと思っています。しかし本当の任務は、 10 時に待ち合わせ場所に着くことです。
このように自分の中で任務を再定義することが仕事においても重要です。私はビル・ゲイツほど厳しい人間にはなれませんが、自分の中で絶対にやらなければならないものとは何かを真剣に考えることは大事なことだと思っています。
ルーがなくてもカレーは作れる
ビル・ゲイツは複雑な問題をいくつかの独立した問題に分けるのがとても上手な人です。「困難は分割せよ」とはフランスの哲学者・デカルトの言葉ですが、分割術を最も実践的に行っているのはビル・ゲイツでしょう。たとえば、こんな例で考えてみましょう。ある日、ビル・ゲイツがカレーライスを作ろうとしたとき、なんとカレールーとニンジンがありませんでした。これではいつものカレーライスが作れません。しかしよく考えてみてください。ルーがないと絶対にカレーライスは作れないでしょうか？ ニンジンがないとカ レーライスは作れないでしょうか？
そんなことはありません。ルーは市販のカレー粉で代用できるし、ニンジンはなくても一応カレーライスにはなります。つまり、ルーがないという問題と、ニンジンがないという問題は独立しています。だからここは慌てず、「ルーをどうするか」「ニンジンをどうするか」という分割された課題に、別々に当たればいいわけです。
ビル・ゲイツはその後、カレー粉とじゃがいもを使ってカレーライスを作っておいしくいただきました。
やや抽象的な話だったので、現実にあった事件を例に挙げます。マイクロソフトがパソコンメーカーにソフトを依頼されたとき、ある技術的な問題により、パソコンメーカーから苦情が来たことがありました。クライアントがたいそう怒っているということで、社内は混乱していました。とにかく、原因の技術的問題を解消しなければこの問題は収まらない。マイクロソフトの社員はみんなそう思い込んでいました。
そんなとき、ビル・ゲイツは困難を分割しました。技術的問題はクライアントの怒りからは独立した問題だと。どうやらクライアントが怒っているのは技術的問題よりも、担当者との性格の不一致に原因があったようです。そうして担当者は替えられ、クライアントをとにかくなだめる任務に就くことになりました。他方で技術的問題はエンジニアたちが全力で解決に向かってまい進していました。
こうしてクライアントとマイクロソフトの関係は、なんとか立ち直ったのです。技術問題と外務問題を切り分けることで、この事件は終息を迎えました。ビル・ゲイツが「その問題とこの問題は独立している」とよく言っていたことを覚えています。こうした課題の分割は、複雑な問題を効率的に解決するうえで重要なことだと思っています。
日本語とオブジェクト指向
『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』ですが、おかげさまで２度目の重版が決まったそうです。とてもありがたいことです。
以下も、この本からの引用です。
◇ ◇ ◇
現在の「右クリック」の概念は、こうして生まれた
ビル・ゲイツの話が続いたので、余談になりますが、私が米マイクロソフト勤務時代にカイロからシカゴに持ち込んだというアイデアについて少しお話しします。
それまでのＯＳでは、あらゆる操作をキーボードでのコマンド入力（コマンドと呼ばれる文字例をキーボードから入力し、コンピューターに命令すること）で実行していました。マウスは存在していましたが、まだ今ほど便利で優れたツールではありませんでした。では、Windows95で何が起きたのでしょうか？
それはみなさんおなじみの右クリックとダブルクリック、そしてドラッグ＆ドロップの現在の形への進化です。この概念を私は、ビル・ゲイツの前での公開裁判の中で披露した、ベータ版の中にすでに組み込んでいました。
みなさんご存じのとおり、 Macintoshのマウスにはボタンが1つしかありません。これは昔からそうです。一方、 Windowsにはボタンが2つあります。とはいえ当時は左ボタンを使うことがメインで、右のボタンは今ほど使うことはありませんでした。
しかしWindows95になってから、右クリックの使い勝手は飛躍的に向上しました。デスクトップ画面の何もないところで右クリックすることで、画面のプロパティやアイコンの整列などの操作をするメニューが開きます。テキストファイルの上で右クリックすると同様にメニューが開きます。
また、ドラッグ＆ドロップも大きな変化の一つです。たとえば、要らない文書ファイルのアイコンをクリックしたまま「ごみ箱」のアイコンの上に持っていけば、文書ファイルを削除することができます。 Windows95はユーザーがパソコンに詳しくなくても簡単に操作できるように、グラフィカルな設計がなされたのです。今の感覚からするとずいぶん当た り前なことですが、当時としては画期的なことでした。
グラフィカルな設計といえば、ダブルクリックもそうです。文書ファイルのアイコンをダブルクリックすると自動的にワープロソフトの編集画面が立ち現われ、音楽ファイルのアイコンをダブルクリックすると自動的にプレーヤーが立ち現われて再生が始まります。
ファイルをシングルクリックした場合、その後ユーザーが選択するコマンドは「ファイルの編集」「コピー」「転送」「再生」など、様々な種類が考えられます。しかしダブルクリックは、文書ファイルなら文書ファイル、音楽ファイルなら音楽ファイルといった対象を選択したうえで、ダブルクリックという操作をするだけで、自動的に「編集する」「再生する」といったコマンドが選択されるのです。
このように、何らかの対象（オブジェクト）を先に選択したうえで動作を指定することをオブジェクト指向といいます。
オブジェクト指向のわかりやすい例として、私たちがいつも使っている日本語が挙げら
れます。
あなたがテーブルの上の塩を取ってほしいとき、あなたは「すみません、塩を……」まで言葉にしたところで一呼吸置くと思います。それはなぜなら、「塩」という対象を指定した時点で、あなたが相手にしてほしいことは決まり切っているからです。相手もそれをわかっているので、「塩をどうしろっていうんですか？」なんて野暮なことは聞きません。
エレベーターに乗り合わせた人に「すみません、12階を……」と言うのも同じことです。これも 12 階という対象を指定した時点で、12階のボタンを押してほしいということは決まり切っています。これはWindowsにおけるダブルクリックと非常によく似ていると思いませんか？
このようなグラフィカルでオブジェクト指向な機能を思いつくことができたのは、もしかしたら私が当時マイクロソフトで唯一の日本語話者だったからかもしれません。
日本人的な会話の作法を取り入れた結果、 Windows95が世界を席巻したと考えると、感慨深く思います。
先日も、深夜に口もききたくないくらい疲れ切ってタクシーに乗ったときに、この「オブジェクト指向」言語である日本語を理解する運転手（平たく言えば普通の運転手）に助けられました。そこでは次のような会話が展開されました。
「すみません、経堂まで……」
「はい、経堂までですね。道はどうしましょう？」
「あ、環七経由で……」
「はい、環七から赤堤通りですね」
（しばらくして）
「その信号を左に……」
「はい、ここを左ですね」
「それで、そこの行き止まりの所で……」
「はい、かしこまりました」
中島聡
Ex-Microsoft (software architect, Windows95 and IE3/4)
Microsoft Store
