世界一流エンジニアは何が違うのか
マイクロソフトの開発チームは、全員のベーシックな生産性が異様に高い。日本では、まず自分の力で試行錯誤することが、周りからも評価されるが、彼らはいきなり手を動かさない。まずは、事実（データ）を1つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。つまり、むやみやたらに試行錯誤するのではなく、まず自分の頭のメンタルモデルを使って仮説を立て証明する。この一連の手順が、手当たり次第に可能性を試すことによる時間のロスを排除し、圧倒的な効率を生んでいる。
どんなに頭がいい人でも理解には時間がかかる。頭のいい人が理解が早いように見えるのは、時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキストが載っているからだ。
理解が十分でないまま手を動かして努力しても、空回りになるだけで身に付かず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。「何かを早くできるように急ぐ努力」はかえって本質的な理解を遠ざけてしまう。
そもそも学習における「理解」とは次の3要素である。
- その構造をつかんで、人に説明できること
- いつでもどこでも即座に取り出して使えること
- 知見を踏まえて応用がきくこと
基本的な構造から把握した知識は、参考書を見たりググったりせずとも、いつでもどこでも即座に使えて、応用範囲が広い。基礎練習は誰でもできることだが、習得には時間がかかる。基礎的なことに時間をかけて理解する大切さは、プログラミングでも同じである。
マイクロソフトの同僚たちは驚くほど細かいところまで仕組みを把握し、記憶している。多くのことを把握するために、彼は「メンタルモデルをつくるとそれができるようになる」と教えてくれた。メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のことだ。つまり、頭の中で素早く情報処理をするために、何らかの脳内イメージを持っていることが有効だ。
自分の業種・業態に合った思考の枠組みを学んだり、経験したりして、自分なりの脳内イメージをつくり上げることができれば、頭の中で考えを整理したり、問題発見に至るプロセスが大幅に高速化する。
メンタルモデルを構築するにあたっては、わからないことをエキスパートに聞くのが最も速くて合理的だ。1つのことで2時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い。
仕事のパフォーマンスを上げるには、いかに「無駄なこと」をしないかに尽きる。エキスパートから情報がシェアされ、そのレベルから理解するフェーズに入れば、しっかりと肝心なことにフォーカスできる。
世界一流のエンジニアたちが身につけているマインドセット
①「Be Lazy」（怠惰であれ）
より少ない時間で価値を最大化するという考え方。できるだけ最小の労力で楽をする方法を探ろうというマインドセットだ。Be Lazyを達成するための習慣は次の通り。
- 望んでいる結果を達成するために、最低限の努力をする。
- 不必要なものや付加価値のない仕事をなくす。
- 簡潔さを目指す。
- 優先順位をつける。
- 時間や費やした努力より、アウトプットと生産性に重点を置く。
一流のエンジニアたちは「いかにやることを減らすか」に頭を使っている。重要なのは「減らすこと」自体に価値があると、マインドをリセットすることだ。
②リスクや間違いを快く受け入れる
リスクを受け入れるとは、次のことを意味する。
- 間違いを厳しく批判したり懲罰したりしない。
- 失敗から学ぶ態度。
- Fail Fast（早く失敗する）。
- 実験が推奨されている。
- 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される。
- 非難や恐怖感のない環境。
「リスクや失敗」を恐れる体質は、生産性の面で劇的な低下をもたらしてしまう。失敗したくないと、ともかく慎重になってしまうからだ。時間をかけたからといって失敗をゼロにできるわけではなく、時間をかけている間にライバルはどんどん次に進んでしまう。早く試して、失敗して、フィードバックを受けて素早く方向修正する。早く失敗することはそれ自体に価値がある。
③不確実性を受け入れる
失敗を快く受け入れるマインドは、業務全体の「不確実性を受け入れる」ことにもつながる。具体的には次の考え方である。
- マネジメントは詳細まで細かく練られた計画を期待しない。
- 予算と報告のプロセスは精密な結果の予測を要求しない。
- 内部プロセスは計画や優先順位の変更に柔軟である。
- 事前に全ての問題分析が完了せずとも新しいことに挑戦する姿勢を持つ。
- システムとプロセスは柔軟で、複数の頻繁な変更を受け入れられる。
- 学びに基づいて、変化を精力的に行う。
「計画通り」いかないことは決して「失敗」ではない。計画通りより、スピーディーに軌道修正をかけていける柔軟性の方がはるかに大切だ。
