「試行」の前に「思考」！
手を動かす前に仮説を立てるべし

　日本のビジネスパーソンには身に覚えのある人も多いだろうが、「時間をかけて結局全部やる」という考え方だと、優先順位の高いものに取り組んでいる時でも、他のタスクがどうしても気になる。その結果、焦りが生じて生産性が下がりがちだ。「2番目以降は割り切って捨てる」という、マイクロソフト流の思い切りの良さを見習うべきだろう。

　なお、上記の「（6）長時間労働しないことを推奨する」「（7）会議は決められた時間内で効率的かつ生産的に行う」とも関連しているが、米国には「時間を固定する」という考え方もあるそうだ。

「すべきこと」が終わるまで延々と作業を続けるのではなく、「何時から何時までこれをやる」と時間の枠を決める。そして、その枠の中で成果を最大化することを目指す。「限られた時間内で確実にできること」だけをピックアップし、集中するのだ。日本人が長時間だらだらと会議をしないためにも、有用な考え方だろう。

　さらに、「試行錯誤をしない」という考え方も本書で紹介されている。

　これに違和感を覚えた人もいるのではないだろうか。日本企業では「結果」だけでなく「プロセス」を評価しがちだ。トライアンドエラーを繰り返しながらじっくり検討を重ねた末に、最適解にたどり着くことが良しとされる。海外の一流企業では、それは重要ではないというのか――。

　その答えを示す、一つのエピソードがある。

　ある日、牛尾氏は自分のプログラムがうまく動かないときがあった。自力で直そうとすると、原因究明に途方もない時間がかかると考え、ポールという同僚のトップエンジニアに声をかけて「ペアプログラミング」を依頼した。ペアプログラミングとは、2人1組で1台のPCを共有し、一緒にプログラミングする手法だ。

　セッションが始まると、PCの画面には、牛尾氏のプログラムに問題があることを示すログ（プログラムが内部でどのように動いているかを示す記録）が表示された。

　するとポールは手を一切動かさず、最初の1つのログだけを見て、頭の中で「仮説」を立て始めた。ぶつぶつと独り言を言いながらしばらく考え、データベースを閲覧するソフトを起動。クエリ（システムへの命令文）を1つだけ書いて、「ここだろう」と一言。そのクエリの結果は、エラーの根本原因を正しく示すものだったという。

　牛尾氏のかつてのやり方は、「的確な仮説を導き出すべく『思考』を巡らせる」という過程を省き、ひたすら「試行」を繰り返すものだったのかもしれない。その手法では、どれだけ時間がかかるかわからない。