概要

米マイクロソフト・シニアエンジニアの牛尾さんが2023年10月に出版された「世界一流エンジニアの思考法」という本が大変素晴らしく色々と思考が整理された感覚があったので、自分なりの解釈と感想を書いておきます。

本書の概要

著者の牛尾さんは、大学卒業後に日本の大手SIerでITエンジニアとなり、その後独立され、アジャイル、DevOpsのコンサルタントとして数多くのコンサルティングや講演を手掛けられ、その後マイクロソフトに入社され、エヴァンジェリストとしての活躍を経て、現在はシニアエンジニアとして活躍されています。

その牛尾さんが、世界トップレベルのエンジニアのような高い生産性を発揮するために、彼らの「思考法」をまとめられたものです。

エンジニアの理想的な働き方の理解という意味ではエンジニアよりもむしろIT企業で働く他の職種やマネージャーの方々にこそ読んでいただきたい話にも感じました。

書評

書評の要約

「個人」「チーム・会社」「日本」という三つの単位でそれぞれ生産性を上げるためにできることとして印象に残ったことをまとめます。

個人の生産性を上げる

理解には4段階ある

理解には以下の4段階があり、

• 1: 何もググらずに即実装できる
• 2: ググれば解決できる
• 3: スパイクソリューションがあれば(課題把握のための大まかなプログラムをしたら)何とかなる
• 4: 自分では無理

脳のメモリから直ぐに引き出せるもの、つまり1が多ければ多いほど生産性が上がる、といったことが書いてありました。

私はググれば(Chat GPTに聞けば)分かるのであればそれで必要十分だと思っていた節があったので、これはなるほどなと思わされました。2を1にすることを今後はより意識していきたいと思います。

生産性を上げるためには学習が必要

• 仕事ばかりしていては短期的なアウトプットは上がったように見えても、根本的な生産性が上がらない。
• キリのいいところまでやろうと考えずに、時間を決めて切り上げる。仕事を定時で切り上げて勉強する時間を確保する。

著者も以前は「終わるまでやる」といったマインドでたくさん残業されていたそうです。私もこの「終わるまでやる」マインドでやってしまうから始業時間も就業時間もランチ時間もバラバラで、酷い時は日付が変わる時間まで仕事してしまうこともあったりするので、ちょっとタイプが似ている(恐らく「達成欲」が強い)のかなと思いました。

やっぱり、自分や家族の生活が金銭面で私の「仕事」に依存していると考えるとどうしても自分の勉強や個人開発よりも優先度が高くなり、仕事が忙しくなると時間が取れなくなって中々習慣化できずに悩んでいたのですが、なるほど、「中長期的な生産性を上げるために残業をしない」という発想はありませんでした。

確かに、目の前の短期的なアウトプットを上げるような働き方をして成長できる(根本的な生産性を上げられる)段階はとっくに過ぎてしまったと思います。仕事が途中だろうが時間で切る、ということをなるべく意識していきたいです。

アウトカム至上主義に陥らない

• 結果を急がない。「理解には時間がかかる」ことを認めてじっくり理解する。
• アウトカムに集中すると、一時的には良くても、中長期の「生産性」は上がらない。
• 技術は地味な積み重ねにこそ真価が宿る。何かを身につけるのは決して即席ではできない。
• 王道を愚直に実行し、ゆっくりと基礎を理解する。
• 細かい技術の積み重ねで勝負する必要がある。アメリカでは専門性を高めるという蓄積に価値が置かれ、スピードは思ったより重視されない。結局は時間をかけて小さな努力を積み重ねる方が圧倒的に良いものが作れる。

正に私はアウトカム(結果)こそ全てだ、と考えている節があり、これはむしろ欧米的な価値観に近いのかなと思っていましたが、日本こそアウトカム至上主義だとは知りませんでした。会社やチームについての話は後述しますが、個人としても、とにかく速く結果を出すことに拘っていました。

ただ、ここで指摘されている通りその態度が中長期的な生産性やユーザーにとっての価値に繋がるかというと、確かにそうではないなと思いました。

改めて考えてみると、腰を据えてじっくりゆっくり時間をかけて何かを理解する、という時間はあまりとれていないので、もっと意識していこうと思いました。

脳の酷使をやめる

• 瞑想をする
• ディスプレイから意識的に離れる
• しっかり睡眠時間をとる

これは以下で書評を書いたメンタルマネジメント大全でも非常に重要だと述べられていました。

【書評】一番大切なのに誰も教えてくれない メンタルマネジメント大全

特に、気がついたらスマホやテレビを見てしまうのは私含め現代人が抱える大きな課題だと思うので、何か手段を考えたいと思います。

チーム・会社の生産性を上げる

個人的には、個人の話よりもチーム、会社といったより広い範囲についての話がより興味深かったです。

不確実性を受け入れる

• できない人を何とか管理するという発想をやめて、できる人たちにのびのびとパフォーマンスを発揮して欲しかったら、何よりもチームメンバーが「仕事を楽しめる」環境を作ることだ。
• できない人を何とか管理するという発想は捨て、大人扱いして「できる人」にする方がずっと効率がいい。特にソフトウェア開発の場合、「できない人」に焦点を合わせて管理すると、できる人も増えなければ、突出した上位層も十全にパフォーマンスを発揮しようとしなくなるため、会社全体の生産性が上がらない。
• できる人たちにのびのびとパフォーマンスを発揮して欲しかったら、何よりもチームメンバーが「仕事を楽しめる」環境を作ることだ。
• 納期がなく、マネージャも急かさない。できた時にプロジェクトは終了する。
• これは「不確実性を受け入れる」こととそのまま繋がる。たとえば1週間でできると思ったことが技術的な問題が発覚して2ヶ月くらいかかってしまうこともざらだ。予想外のことが頻繁に起こる。
• マネージャは絶対に急かさない。私は一度も「早くしてください」と言われたことがなく、「何だか遅くてごめんな」と言うと、「いやそんな気にすんなよ」「よくあることだよ」と励ましてくれる。

本書でも触れられていましたが、ソフトウェア開発はかなり不確実性が高く、1週間で終わると思ったものに1ヶ月かかったり、当初想定していなかったイレギュラーが発生したりすることが日常茶飯事です。私は今まで、そういった不確実性を、一言で言えば「気合い」で解決してきました。

不確実性が高い、でも納期は絶対に守らなければならない、という状況の時にできることは、「とにかく序盤に爆速で仕事を進めて不確実な部分をどんどん明らかにしていく」です。なので、プロジェクトの開始時期はいつも残業が多くなっていました。酷い時はそれが数ヶ月〜半年も続き、半分燃え尽きたこともありました。

これができない人が担当している場合、単純に納期が遅れるか、遅れそうになって炎上し、マイクロマネジメントが発生し、新たに人が投入されるかになります。

そもそも、この不確実性が高いソフトウェア開発の特性上、期初に「プロダクトAをX月にリリースする」といった目標を定めること自体かなり無理のあることで、あくまで目安としてロードマップを敷くことはあっても、その達成度合いによって評価しようとすると、前述の「アウトプット至上主義」に陥りやすく、個々人のWell-beingや中長期的な生産性の向上、引いては企業の発展のためにはマイナスになってしまうのではないかなと思いました。

結果を出すからバリューを出すへ

• 日本式の「結果を出さないといけない」プレッシャーと、インターナショナルチームで「バリューを出す」ことを求められることとは、似ているようでまるで違う。
• 日本だと、一度目標が決まったら、途中で未知の問題が発覚しても、「プロなのだから、一度決めた納期はしっかり守り通そう」と徹夜などして必死に達成しようとする
• 予測が誤っていても、必ずやりきらないといけない対象になるので、全員に相当なプレッシャーがかかる。
• 後者は、目標へ向かう途中で問題が発生したら、「どうやったら達成できるか？」を常に考え、工夫するが、目標設定に無理があると判明した場合は、最も優先順位の高い最初の1ステップのみを目指すようにすぐ方向転換する。
• 定時以降の仕事や、休日出勤でカバーしようという流れになることはない。できないものはできないとクールに判断する。簡単に納期を延ばしてしまう。
• KPIは定時で無理なく楽に達成できる程度のものであるべきだという大前提がある。
• 日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、海外ではそうした火急の依頼は「マネジメント能力の欠如」とみなされる。
• 計画は単に「見通しを立てて、仕事を進めやすくするため」のものでしかない。
• アメリカでは納期が近くなっても、「無理して機能を完成させなくていいから、品質の良いものを作るようにしようよ」とマネージャから言われる
• さほど問題になりもしない納期とリリース機能を守るために、プログラマの生活や健康を犠牲にしてまで取り組むことは、中長期的には疲弊して生産性が低下してしまうことになるので、マネジメント的に効率が悪い。
• 納期がないなら何があるのだ？と日本の人たちによく驚かれるが、バックログ(今後やるべきことリスト)と、大きな予定だけはある。戦略とカスタマーフィードバックに基づいて今期はこれとこれをやろうという計画があって、とても粗い粒度の要素を整理して、開発者たちにアサインする。
• 予定は今期に達成されないと言うことも頻繁に生じる。想像よりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、不測の事態は見通せないので仕方ない。オーガナイズはされているが、できなかったときはできないと認める。それで現場が責められることはない。
• 日本での仕事を振り返ってみても、本当に納期がそんなに重要な場面ってあるのだろうか？日々の業務で、ある機能の実装が1週間、2週間遅れたからといってどんな重大な影響があるのだろう？
• マネージャは一度仕事をプログラマに割り振ったら、あとはもう信頼するしかない。その選択が最適だったと、その人を信頼し切る。当人が一生懸命やって時間がかかったなら、それが現時点でできるベストだったのだ。
• ただし、あまり成長がなかったりむいてなかったりすると、違う仕事にアサインされたりはする。だから皆、やりたい仕事は頑張って成果を出そうと思って取り組む。
• 精神論ではっぱをかけ、納期厳守で徹夜でやらせるような管理は、グローバル基準で言ったらプロのマネジメントではない。

確かに、仮にプロダクトAをX月にリリースできたとて、それがユーザーにとって価値あるものでなければ「成功」とは呼べないはずです。そもそも、決められた機能を期限通りにリリースしたら、たとえそれがユーザーに全く売れなくてもプロジェクトとしては成功でA評価、みたいなのは本質的ではないと思います。出せる時に出す、出した後にユーザーからの評価を見聞きし、さらに改善を重ねる。これができれば良いのだと思います。

世界トップレベルの企業が結果的に「納期を持たない」ようになっているのは非常に示唆的で、中長期的にはこのスタンスこそが合理的なのだと思います。ただし、この方針でも成果を上げ続けるためには、人材のレベル、というか仕事に対するモチベーションやスタンダードが高く、また雇用の流動性も高い状態を保つ必要があるのではないかなと思いました。

日本の生産性を上げる

会社組織の中心を「実際に手を動かす人」へシフトする

• 1990年代、大企業の優秀なエンジニアたちは、できないエンジニアを育てるのではなく、そういう人でもプログラムが組める方向を目指した。
• 日本の平均レベルで言うと、アメリカだけでなくヨーロッパと比べても低い。特に大手の低迷感が否めない。その大きな理由は「自分でやらないから」
• プログラミングを低レベルの人がやることとみなして外注し始めたことが、日本の大手SIer衰退の分岐点となってしまった。
• 実際作るのは手を動かす技術者だ。ノウハウの蓄積も最新の知見も前線のエンジニアたちの頭脳に集まる。
• 海外のテック大手のCEOがみんな技術畑出身なのは、そういう現場的な鼻が利くことが意思決定に有効に働くことが増えているからに他ならない。
• 安く下請け企業に丸投げする中抜きビジネスの旨みを知ってから、日本の大手企業の技術力は坂を転がるように衰退していった。ITに限らず、多くの産業で同様の構造が見受けられる。
• AIが日進月歩で進化を遂げる時代、今日本が早急にやるべきは、「自らの手で一流のソフトウェアを開発する力」をつけること。そして、失敗しながらでも「世界の市場に挑戦する」こと。
• その第一歩となるのが、技術軽視の風潮を改め、ソフトウェアの技術者を専門家として大切に扱い、彼らが働きやすい職場環境へと刷新していくことだろう。
• 現代的なイノベーションは素人が何人集まっても生まれない。そこには技術による裏打ちやクリエイティブジャンプが絶対に必要で、それなくして、革新的なサービス、製品は生まれようがない。だから会社組織の中心が、政治的な人から、実際に手を動かす人へシフトするのが、この先日本企業が再生していく上で喫緊の課題ではないだろうか。

日本はITに限らずとにかく手を動かさずに横流しする仕事が多い印象があります。日本国内で言えばかなり風通しが良い方であるIT企業でも、手を動かさない人がトップダウンで物事を決めることが多いです。

私は本当に新卒の頃から仕事は手を動かしてなんぼだと思い続けてきましたが、同じ思いが言語化されていて本当に嬉しかったです。

最後に

• 会社のルールで決まっているからできないなら、会社のルールを変えるように動けばいいだけの話。どうしても嫌なら会社を辞めればいい。今の会社で活路を見出せないなら、起業したっていいし、海外の会社に行ったっていい。

本当に自分が考える理想的な組織を作ろうと思ったら起業するしかないんだろうなとも思いますが、こちらもそう簡単にはいきません。

中々大きい会社なので会社のルールを変えるというのはそう簡単にはいかないと思いますが、まずは今できることを、特に不確実性や納期の話、手を動かす人を中心に据えていく話については提案していきたいと思います。

個人レベルでできる、「仕事を定時で切り上げて、生産性を上げるために学習する時間を確保する」「アウトカム至上主義に陥らない」といった点はすぐに実践していきます。

本記事に書いたこと以外にもたくさん良いことが書かれていましたので、是非手にとって読んでみていただきたいです。エンジニア以外の方にもきっと収穫があると思います。

本当に良い本に出会えてよかったなと思います。ありがとうございました。