『世界一流エンジニアの思考法』を読んで実践していること
Amazonの「ソフトウェア開発・言語」のカテゴリで長らくベストセラーに輝いている『世界一流エンジニアの思考法』。私はエンジニアではなくプロダクトマネージャーですが、紹介記事などをみて内容が気になったので読んでみました。
本書では、マイクロソフトのクラウドサービスの開発チームにいる筆者が、チーム全体の生産性の高さに着目し、その秘訣について紹介しています。
読み進めていくと、ここで書かれていることは「プロダクトマネジメント」の基本的な進め方と内容が近いことに気づきました。本書の特徴的な点は、日本企業での勤務経験もある筆者の視点から、日本と海外の仕事の進め方の違いを明らかにしていることです。
私は「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」などの海外のプロダクトマネジメント本を愛読していますが、なぜこれが日本企業でうまく導入できないのか、ヤキモキしていました。
本書を読んで、そもそもの文化や思考法が大きく異なることに気づくことができました。ただ海外の事例を取り入れようとするのではなく、仕事への考え方を転換させた上で、実践していく必要があります。
そこでこの記事では、この本を読んで、私が日々のプロダクトマネジメントの仕事で実践していることをまとめたいと思います。
仮説を立ててから動き出す
「第1章 世界一流のエンジニアは何が違うのだろう」では、トップエンジニアたちの日々の仕事の進め方から、その生産性の高さの秘訣を明らかにしています。
その中でまず説明されているのが、「問題解決の際は仮説を立ててから行動する」ということです。
いきなり手を動かさない。まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。
これはプロダクト開発の基本的な進め方にも通じますね。単に思いつきで色々なパターンを試すだけでは、失敗からも何も得ることができません。
そこで私も、日々の仕事で問題解決に取り組むときは、まず事実を集めて仮説を立ててから行動することを改めて意識するようにしました。すると、問題解決につながる行動を起こせるようになり、もし失敗したとしても、仮説を修正して別の行動に移れるようになりました。
他の人が問題解決に取り組んでいるときも、どんな仮説のもとで行動しているのかをそれとなく聞いてみるようにしています。すると、仮説が間違っていることに気づいて、やり方を見直すことがよくあります。
何か行動を起こす際には、どんな小さなことでも仮説を立ててから行動する、ということを今後も徹底したいと思います。
理解に時間をかける
プロダクト開発における生産性を向上させるためには、さまざまな手法や技術を「理解」して、いつでも使えるようになっておく必要があります。「理解」とはどういうことか、筆者は以下のように説明しています。
・その構造をつかんで、人に説明できること。
・いつでもどこでも即座に取り出して使えること。
・知見を踏まえて応用がきくこと。
また、頭のいい人は短時間で理解ができるわけではなく「どんなに頭の良い人も理解には時間をかけている」と説明されています。
私はこれまで、新たなツールや技術が必要となったとき、「サマリ」を読んでざっと理解した（つもりになっている）ことが多かったように思います。それでは本当に理解したことになっていません。
そこで、同様のケースに直面した際は、じっくりと時間をかけて理解するようにしました。
例えば生成AIに触れる場合、ネットの記事を見ただけで満足せず、公式のドキュメントを読み込んでみたり、自分でツールを作って動かしてみたりします。そうすることによって、その技術でできることや現状の限界点などが理解でき、応用方法も思いつくことができます。
また、趣味のプログラミングの際も、利用するライブラリのドキュメントを読み込んでから使うようにしています。そうすることで、わからないことがあるたびにGoogle検索して解決策を見つけるよりも、早く解決策に辿り着くことができるようになりました。
このように、時間をかけて基礎を習得することで、結果的にその後の行動が早くなります。今後もあらゆる場面で理解に時間をかけることを意識したいと思います。
「検討」をやめて「検証」する
「第2章 アメリカで見つけたマインドセット」では、より少ない時間で価値を最大化するという考え方が紹介されています。これもプロダクトマネジメントの考え方に通じます。
価値を最大化するための方法の1つとして、失敗を受け入れて、失敗から学ぶ思考の習慣が説明されています。私がその中でも意識して実践しているのが、「検討」をやめて「検証」するということです。
日本の仕事の進め方について、以下のような事例が挙げられていました。
仮にあなたがベンダーに「提案」を依頼するとしよう。私が日本の大手SIerに勤務しているときは、何人もの人が数週間かけてせっせと提案書をつくっていた。しかし正直、大量に検討した資料をつくったところで精度は低いし、マニュアルに「できる」と書いてあっても、実際やってみるとできないことなんて頻繁に生じる。そしてその工数は、ベンダーからの請求書にきっちりのってあなたにはね返ってもくるだろう。LoseLoseの関係だ。
私は提案を依頼する側の人間なので、このような事例はよく目にします。もちろん、規模の大きな案件だったり、失敗した時の手戻りが大きい案件の場合はこのようなやり取りも必要かもしれません。
しかし、ソフトウェアの世界においては、クイックに実装して結果を検証することができます。時間をかけて検討を重ねるよりも、早く検証したほうが絶対に良いです。
そこで私は、何か新しいツールや技術を導入するかどうか迷ったときは、まず使ってみることにしています。現代のほどんどのツールはインターネット経由で入手して無料で試用することができるので、時間とお金をほとんどかけずに検証することができます。
一度使ってみることで、そのツールの特性や限界などをしっかりと見極めることができます。現代のプロダクト開発においてはスピードが非常に重要です。素早く検証できる方法をいつも探していたいです。
人に説明可能なレベルで記述する
「第3章 脳に余裕を生む情報整理・記憶術」では、記憶力の良さが仕事のスピード感につながることを指摘しています。ここでは、記憶を定着させるための手段として、以下のように説明されています。
つまり、人に説明可能なレベルで記述することが理解を深め、記憶を定着させるのに非常に有効な手段なのだ。私がよくnoteやブログに雑記を書いているのも、自分の気づきを脳内整理して記憶するためにやっている側面が強い。
私もnoteやzennに技術ブログを投稿しています。技術ブログでは、読者が理解しやすいように噛み砕いて説明したり、自分なりの気づきを整理して記載したりします。
これにより、書いた内容の理解度が一気に深まり、記憶にも定着します。もし忘れてしまったら自分で書いた記事を読み返せば良いので便利です。
今回の記事も、この実践例の1つです。今後も記憶に定着させたいことがあれば、積極的にブログに書き出していこうと思います。
相手が本当に欲しい情報を意識する
「第4章 コミュニケーションの極意」では、情報量を減らして伝えることで、相手に負荷をかけずにコミュニケーションを取るスタイルが紹介されています。
筆者のチームメンバーの1人は、自分が学んだこと、試したことを整理してOneNoteに登録し、他メンバーにシェアすることで、問い合わせに対していつも的確な対応をしているそうです。
このように、「みる人が欲しい情報は何か」という視点でメモをすることで、何かを聞かれた際の口数削減に直結します。
私が最近書いている技術ブログでは、「これは他の人も同じ箇所でつまずくかも」と思った内容も気軽に記事にしています。もし、同じケースで困っている人を見かけた場合、その記事のURLをシェアするだけで回答できます。
また、普段の仕事においても、チームメンバーが今どんな仕事をしているかを気にかけておきます。メンバーが必要としそうな情報があった場合、こまめにメモを残しています。これにより、問い合わせの際にすぐに回答できるケースが増えました。チームの生産性が上がるだけでなく、自分の作業時間を確保することにもつながります。
互いの知見を気軽に交換する
プロダクト開発においては綿密なコミュニケーションが重要ですが、リモートワークの普及によって、席を跨いだ気軽な会話は少しやりづらくなりました。そこで筆者が推奨しているのが、「クイックコール」です。1対1で通話をすることで、インタラクティブなやり取りができ、フィードバックも速く得ることができます。
そこで私も、わからないことがあれば気軽にクイックコールをお願いしてみたり、他の人からの依頼も喜んで受けるようにしています。ある程度の時間を割く必要はありますが、チャットで何度もやり取りするよりも、結果的には早く解決することが多いです。
なお、「気軽に聞く」ことを実践するためには、「気軽に断れる」ことがセットになっている必要があります。なので私もわからないことがあれば、「⚪︎⚪︎さんに聞いてみれば？」などと言ってサッと断ったりします。ちょっと冷たい感じもしますが、これくらいドライな方が、相手も気軽に聞きやすくなります。
本の中では、日本の事例として以下のようなものが紹介されていました。
これが日本だったら、一旦お客様から質問を受けたら自分がサポートに連絡して最後まで面倒を見たり、「後日回答します」と抱え込み、責任を持ったりするところだ。やくざ映画や寅さんとか観ても、「こうも頼まれちゃ断れねえな」と、いったん助けることを引き受けたらとことんやるのが日本人の性だ。
私もどちらかというと、最後までサポートすることを美徳としていたので、この気持ちはよくわかります。しかし、依頼する側の目線に立つと、質問のハードルが上がってしまいますよね。
このことからも、助けになれない場合はすぐに断ることを意識しています。これにより、メンバーが気軽に質問してくれる場面も増えてきたように思います。
ポジティブフィードバックする
「第7章 AI時代をどう生き残るか」では、日本特有の「批判文化」について、筆者の非常に鋭い指摘が書かれています。この章での提言だけでも、本書を読む価値があったと思います。
ここでは、日本とアメリカの文化の違いについて、以下のように比較しています。
この異常な完璧主義、先陣を切って何かにトライする人に対する嫉妬にも似た口さがない批判、冷笑、中傷が、新しいことへのチャレンジ精神を根本的に奪い続けてきた。
一方、アメリカには「コントリビュート」する文化がある。Contributeとは
「貢献する」という意味だが、人に何かを期待するのではなく、まず「自分がどういう貢献ができるか？」という公共性をベースに考える。だから、人がちょっとでも自分に何かしてくれたら「ありがとう」という気持ちが生まれ、感謝を表明する。
確かに私も、この批判文化に浸っていたと反省しています。新しいプロダクトに触れた時、機能不足やバグなど、至らない点ばかりが目についてしまいます。新しいサービスに関するネット記事のコメントを見ても、どちらかというと批判的な内容の方が目につきますよね。
しかしながら、批判からは何も生まれません。
筆者は、我々にもできる小さな貢献として、「素敵なアプリを見つけたら、作ってくれた人に対する感謝を発信してみる」ということを提案しています。
そこで私は、新しいプロダクトに触れた際は、それにどんな価値があるかを探し、感謝の気持ちを積極的に発信してみることを意識し始めました。SNSへの投稿ではなくても、製品のアンケートなど、フィードバックの機会はたくさんあります。
また、自社の他チームのプロダクトに対しても、良い点を積極的に見つけようとします。これにより、「自分がプロダクトにどう貢献できるか」という視点で新しいアイデアを考えられるようになりました。
プロダクトに対して批判ではなく感謝することで、そのプロダクトに対して自分も貢献したいという気持ちが生まれます。このマインドチェンジこそが、生産的なチームになるために最も重要な点であると感じています。
おわりに
今回は、『世界一流エンジニアの思考法』を読んで、自分なりに実践していることを7つ紹介しました。本書の仕事術は、何かを「やめる」ことを起点としているため、これらを実践した結果としては、仕事が楽になっています。
本書を読んで、日本では「頑張りズム」的な働き方がまだまだ根強いということを痛感しました。一人で黙々と努力し続けることももちろん重要です。しかし、ソフトウェアが主体となった現代のプロダクト開発においては、もっと楽しくて生産性の高い働き方があるはずです。
こうした働き方が組織内に浸透することを目指して、この本の仕事術を実践し、まずは自分自身の働き方から少しずつ変えていこうと思います。
参考資料
この記事が気に入ったらサポートをしてみませんか？