書籍：世界一流エンジニアの思考法
こんにちは。
3人娘を育てている、ベンチャー企業のCTOです。
書籍「世界一流エンジニアの思考法」
米国のマイクロソフト社で勤務されている牛尾剛さんが書かれた「世界一流エンジニアの思考法」を読みました。
書籍の大枠
ご本人はご自身の事を三流だと言い、身の回りの一流のエンジニアたちがどのような思考法をしているのかを整理した書籍です。
そして、牛尾さんは、その思考法を注意深く真似て実践することで、世界最高峰のドリームチームの中で活躍することができていると語ります。
個人としての思考法についても書いてあるのですが、それらの思考法が成立する組織の文化についても書かれています。
感想ざっくり
本書を読んで、「組織として、リーダーとして、こう在りたい！」と強く共感しました。
僭越ながら、「普段思っていたことがめちゃくちゃわかりやすく言語化されている！」とも思いました。
本書をチームで読み合ったら、そのチームは間違いなく強力なチームになるでしょう。
本書は、技術書ではなく、思考法に関する書籍です。
ソフトウェアエンジニアが使っている用語がしばしば登場しますが、用語にあまり囚われずに読む進めれば、技術者以外にとっても非常に有益だといえます。
口語的な書き方をされてますので、めちゃくちゃ読みやすいです。
今回、エンジニアではない方々にとっても、わかりやすく有益な部分をピックアップしてご紹介したいと思います。
頭がよくても「理解」には時間がかかる
どんなに頭がいい人でも理解には時間がかかるものなのだ。
頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
マイクロソフトでは社内で使われている小さなシステムごとに、理解のための動画を用意しているそうです。
マイクロソフトで働いている一流エンジニアは頭がいいから、その動画を見て一発で理解していると思いきや、誰もが何回も（10回くらい）見直しているそうです。
一流エンジニアは、そういった基礎を積み重ねているからこそ、結果的には非常に高い生産性を叩き出しています。
すぐに成果を求めようと、小手先だけで物事を進めようとすることは、最終的な生産性を下げることに繋がります。
根本を理解していないと、毎回同じことを調べることになるし、トラブルにも弱くなります。
理解が不十分なままこなそうとしても、空回りになるし、あやふやな試行錯誤は忘れやすくもあります。
基礎の理解は、非常に時間がかかるものです。
そして、どんなに頭がいい人でも、その基礎の理解には時間がかかります。
むしろ、基礎に時間をかけていることが、高いパフォーマンスにつながっていると考えた方がよさそうです。
いかにやることを減らすか？
Be Lazy の精神で「やることを減らす」のは大変素晴らしいことなのだ。
ところが日本人の感覚からすると、全部やらないのはなんとなく悪いことのように感じてしまい、現行の手続きやすでに決まっているタスクを「減らす」のがとても苦手だ。
しかし重要なのは、「減らすこと」自体に価値があると、マインドをリセットすること。
一流エンジニアたちは、いかにやることを減らすか、ということに頭を使っています。
そして、そこに使っていた時間や体力を、優先順位が高いことに使えるようになり、価値を最大化していきます。
日本人は、様々なところに過剰に工数をかけてしまうところがあります。
物事の完成度を高めること自体は良いことなのですが、重要ではない部分を完璧に仕上げても、価値は高まりません。
日本では、優先度をつけた後、「優先度が高い順に全部やる」となりがちです。
一方、マイクロソフトでは「優先度が最も高いことだけをやり、他はやらない」という捉え方をします。
リスクや間違いを快く受け入れる
奇妙なことに日本では、ネットでもお客さんが激怒し、炎上して中身も売れ行きもボロボロなのに、納期と予算を守ったという理由で「成功」したことになっているプロジェクトをいくつも見てきた。
組織で失敗すると、左遷されたり詰め腹を切らされたりして悲惨な目にあうので、失敗を認めづらいのだ。
だから、ビジネスにおけるあらゆる選択肢は、個人としても組織としてもつねに無難な方へと流れてゆく。
一方、アメリカでは、失敗や間違いで怒られることが皆無だ。
失敗に気づいた後に、本社に報告すると、「フィードバックをありがとう！」と大変感謝される。
もっと言うと、誰がやってもうまくいくようなことを無難に実施してミスがなくても、それは評価の対象にはならない。
生産性を加速させるために重要なマインドセットとして「リスクや間違いを快く受け入れる」があります。
VUCAの時代、やらないことが最大のリスクとなりえます。
挑戦と失敗を繰り返し、そこからフィードバックを得ながら修正していくというサイクルが早いほど、価値があると考えられています。
このとき、フィードバックを歓迎するムードを作ることが重要です。
何かの失敗が発生したり、それに対してフィードバックがあったときは、失敗する方法がわかったということなので、それを感謝しましょう。
アメリカでは、評価はKPIの達成で行われ、業務上の小さな成功や失敗は評価対象ではありません。
不確実性を受け入れよう
一生懸命未来を予見し、緻密な計画を建てることに時間を使ったあげく、商品やサービスが世の中の実態にそぐわなくとも、当初の「計画通り」に遂行しようとして、プロジェクトそのものが炎上してしまう場面はしょっちゅうある。
「計画通り」いかないことは決して「失敗」ではない。
そもそも未来を正確に予見できる人なんてこの世の中に存在しないし、なぜぜ「計画通り」でなければならないのだろうか？
むしろ、スピーディーに起動修正をかけていける柔軟性のほうがはるかに大切だ。
この不確実性の受け入れは、日本人がもっとも苦手としている分野かもしれないと著者は述べます。
その特徴は、特に「納期」の捉え方において顕著にあらわれています。
日本の場合、納期には、予定された機能がすべて搭載された製品が、予定された品質で納品されることが求められます。
そのために、無理をしすぎる傾向にあります。
一方、アメリカでは納期は柔軟です。
期日通りリリースしていても、中身は予定より少ないケースが多々あります。
納期を守るために徹夜をする人もいません。
品質、コスト、納期、スコープはトレードオフの関係にあります。
これらをすべて予定通り達成しようというのは、非常に困難な話です。
納期を達成するために、品質やスコープを下げるということは、当然のように起こります。
現実的な進め方としては、進捗の実績だけで状況を判断し、納期は固定し、スコープで調整するというのが一つの選択肢です。
「サーバントリーダーシップ」とは何か
ソフトウェアの世界では、2001年にアジャイル開発が登場して以降のパラダイムでは「サーバントリーダーシップ」と呼ばれるタイプのマネジメントが主流になっている。
従来型は「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示を出し、部下の状況を把握、確認し、管理していく。
日本の会社でも一般的な、いわゆる「マイクロマネジメント」だ。
一方、サーバントリーダーシップの場合、リーダーは＜ビジョンとKPI＞は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく。
マイクロソフトでは、エンジニアだけでなく、会社全体がサーバントリーダーシップスタイルで動いています。
ビジョン、戦略、KPIは明確ですが、誰も作業を指示することはありません。
現場のメンバーにかなりの権限が与えられ、どのように実行するかは各自が考えます。
日本の大企業では「これをやれ」「あれをやるな」といったスタイルで、主体的に考えて動くことが求められないケースもあるでしょう。
（そうではない企業も増えていますが）
「日本企業の社員は、なぜこんなにもモチベーションが低いのか？」という書籍では、マイクロマネジメントが横行していることが指摘されています。
コマンドアンドコントロールスタイルのマイクロマネジメントは、いわば、チームメンバーを子供扱いしているとも言えるでしょう。
一方、サーバントリーダーシップでは、チームメンバーを「ステークホルダー」として扱います。
そして、技術者を「専門家」として扱い、敬意を払い、重宝します。
「仕事を楽しんでいるか？」を確認する文化
日本のマネージャは進捗管理や課題管理をして、プログラマは開発者を指揮するイメージだが、サーヴァントリーダーシップ制のもとでマネージャが重視するのは、各メンバーのメンタル面だ。
「ツヨシ、仕事をエンジョイしているか？」
マネージャのダミアンが私と One on One （一対一の面談）をするときに必ず投げかけるのが、この言葉だった。
マイクロソフトでは、マネージャは、いかにメンバーたちが幸せに働けるかということに強い関心を持っています。
マネージャがメンバーに「エンジョイしているか？」と確認することは、「楽しんでなんぼ」というムード作りにもなっています。
仕事は楽しむものだというカルチャーがそこにはあります。
日本では、仕事は「我慢してなんぼ」という空気があります。
楽しみながら仕事ができる方が、パフォーマンスが上がることは明確でしょう。
ボスの役割はサポートすること
マネージャの主な仕事は「アンブロック」だ。
つまり開発者がどこかで詰まっている状態になると、ブロックされているものを取り除いてくれる。
サーバントリーダーシップスタイルでは、リーダーは具体的に細かく指示を出すことはしません。
仕事の進め方は、各メンバーに任されます。
リーダーは、その仕事を進める上でブロックしている要素があったら、それを取り除きます。
例えば、誰かに質問をしてもなかなか返答が無い場合、それがスムーズになるような働き方をします。
常に「仕事の遂行を助けてくれるサポーター」という姿勢を取ります。
そして、中長期的なキャリアアップについても、レールを敷くのではなく、各人が思い描く将来像にあわせたサポートをします。
以上、「世界一流エンジニアの思考法」からいくつかピックアップしてご紹介しました。
特に、日本企業のマネジメント手法とは異なるカルチャーを持っていることを感じました。
この思考法を実践するには、組織側のサポートも十分に必要だとかんじます。
本書でも、この思考法を実践するには、会社のトップ層やミドル層の理解が必要だという旨の記載もありました。
ただ、本書に記載されていることを少しでも実践できれば、組織はその分、強くなるという感覚を得ることができました。
私自身はまだまだですが、自分自身が理想と思っていた組織が本書にかかれているように感じました。
これを自社に少しずつでも適用していきたいと思っています。
この記事が気に入ったらサポートをしてみませんか？