考える前に手を動かせ、質問する前に自分で考えろ…日本の社会人にとっての“あるある”は「世界最先端で働くエンジニアにとって真逆の考えだった」と、書籍『世界一流エンジニアの思考法』で紹介したのが、米国マイクロソフトのエンジニア・牛尾剛さんだ。

10月末に発売された著書は、各書店やAmazonの売れ筋ランキングで上位に入り、読者からは驚きや感嘆が交じったXが連日ポストされている。

「即レス」は非効率
「試行錯誤」は非効率
「後で文書化」は非効率
「ググれ、カス」は非効率
「早く失敗しない」は非効率
「納期を守りすぎる」は非効率
「会議の前に準備する」は非効率
「口頭だけでなく文書化」は非効率
何もかも覆された…でも超納得の一冊 pic.twitter.com/EmAQ3bSTfI

— もとやま📚著書『投資としての読書』 (@ysk_motoyama) November 7, 2023

しかし、一抹の不安もよぎる。

例えば、

書籍で語られたこれらの考え方は、特有の商文化やIT社会構造が根付く日本で実行できるのか。

米国マイクロソフトという、それこそ世界一流エンジニアが集まる環境だからこそ通用するのではないか？

そんなうがった見方を、ご本人にぶつけてみた。

「日本ではできない」なんて大間違い

SIerやSESなどのビジネスモデルにもあるように、元請け、二次請け……と多重下請け構造が根付く日本のIT業界で、こうしたメソッドは本当に実行に移せるのだろうか。そう問うと「なぜ実行できないと思うんです？」と牛尾さんは返す。

というのも、牛尾さんにはウォーターフォール一強だった約20年前、周囲の批判や反対を押しのけ、ある企業の営業管理システムをアジャイルで構築した経験がある。

「受託じゃできない。大企業相手には無理。日本じゃ不可能…。もう何百回とそんな言葉をかけられましたよ。それこそ、2002年当時私は大企業所属かつ受託の立場にいましたが、アジャイルでシステム構築することができました。周囲からは『おい牛尾、アジャイルって、あれ宗教やぞ』なんて言われながら（笑）」

上司や組織からのネガティブな反応の数々。それらは状況を「難しく」するかもしれないけれど「できない理由にはならない」と話す。そんな難しい場面を、牛尾さんはどのように突破したのか。

「一番最初にやったのは事例を作ることです。やりたいとだけ言っても誰も何もしてくれないので自分で営業しました。案件が取れたら今度は自分で実装して。

並行してアジャイルとは何か、どんなメリットがあるのかを広めるためにコミュニティーも立ち上げました。すると、社外の人もコミュニティーに来てくれたりするので毎月開催していた時期もあります」

そうした事例を一つでも作れば「やったことあります」と言えるのが最大のメリットだという。

「事例をひっさげて社外でたくさん講演をする。社内で相手にされなくても社外である程度有名になっていくと『アジャイルって面白そうだね』なんて言ってくれるお客さんが現れたりするわけです。

実際、興味を持ってくれたお客さまがいて、結果的に億単位を超える大規模なプロジェクトに発展したこともあります。社内からは案の定、無理だの、失敗するだのと猛反対されつつも無事完遂。その事例は日経コンピュータにも掲載されました」

「やると決めたら実現方法を考える」そのマインドが9割

牛尾さんいわく、日本であれ「やろうと思えばやり方なんて無限にある」のだ。

にもかかわらず、事態を難しくしているのは「マインドが原因」と指摘する。

「もし部長が反対するなら、心理学を勉強して部長を説得するトーク力を身につけることもできるだろうし、話が分かりそうな部長にアプローチするって手もありますよね。

あるいは政治的に手を回して理解のある別の上司を添えるのだって手かもしれない（笑）。もっと言えば、そんな会社なんて辞めて転職すればいいじゃないですか。それでも『できない』と言うのは、自分でそう決めているだけです」

エンジニアからコンサルタントへ転身した際も「できない理由を探す人」をたくさん見てきたという。

「ある人が『部長NGが出て困っている』と私に相談してきたとします。そこで私は『じゃあ部長を説得してきますね』といって部長を説得する。難なくOKがもらえて私が相談してきた人に『よかったですね、部長がOKしてくれましたよ』と報告しますよね。

すると今度は『でもチームの皆がなんて言うか……』と言うので、私がチームへ出向いて再度プレゼンします。こうすると生産性が高まりますよ、としっかり説明すれば大抵賛同してくれるんです。それでも『いやでも……』とまた別のできない理由を語り始める人は多い（笑）」

「はっきり言って、やりたくないならできるはずがないんです。それは日本がどうのという話ではない。やると決めたのなら、どうやったらできるか考えて、実行する。失敗したらそこからフィードバックを得て次の作戦を考える。そのマインドセットが9割だと思います」

牛尾さんはこうも続ける。

「ちなみに、”今の自分”は過去に自分が重ねてきた決断の結果です。まずは、その事実を自覚することが重要だし、第一歩かなと思います。

それがどんな理由であれやりたくないのであればそれはそれで良いと思うのですが、第三者や自分以外の何物かによって『できない』というのは存在しなくて、結局自分が『やらないことを選択』しているのだと私は考えています。それは、自分の判断や決断を誰かに委ねているようなもの。人に自分の人生が決められているってちっとも面白くないですよね」

なぜ「怠惰」がエンジニアを成長させるのか？

牛尾さんが「自覚が第一歩」を強調するのには理由がある。

「私は小さい頃から、運動も勉強も何をやらせてもできない子どもでした。厄介なのは、誰よりも努力しているにも関わらず、ですからね（笑）」

「とにかく性能が悪いので、諦めたらもう後がない。その状況に甘んじることになる。それだけは絶対に嫌だったんです」

そうした原体験が、のちの「ダメでも前に進み続ける」マインド形成に役立った。ただ、牛尾さんのように能動的になれない人は、一体どうすればいいだろう。

「私はただ、生涯を通じて良いエンジニアになりたいだけ。性能が悪すぎて、うかうかしていたら、あっという間に普通の人にすらついていけなくなるので」と謙遜しながらも、そんなときは「Be Lazy」を意識すればいいと教えてくれた。

直訳は「怠惰になれ」だ。なぜエンジニアが怠惰になるといいのか。牛尾さんはこの言葉の意味を過去の体験を挙げて話してくれる。

「米国に来た当初、私は日本人特有の“あれこれも”精神でいろいろな仕事に手を出しすぎてパツパツになっていました。そんな時、当時上司だったダミアンとの面談があり『最近どう？ ハッピーかい？』と聞いてくるわけです。いや、結構大変で……という話をしました。

するとダミアンが『剛にとって、今一番大事な仕事は何だ？』と聞いてくる。それで、私が当時担当していたDevOpsハッカソンだと答えると、『じゃあ、今からそれだけをやろう。それ以外は一切やらなくていいから』と言われました」

日本だとどうだろう。良い上司でも「俺も手伝ってやるから、土日も頑張ろうってなりますよね」と牛尾さんは笑う。

実際、DevOpsハッカソンだけをやった結果はというとー。

「自分の時間を全てハッカソンに注げるので、イベントのクオリティーをめちゃくちゃ高めることができたんです。NSATと呼ばれるMicrosoftの顧客満足度指標で、世界中の誰よりも高い数値をはじき出すことができ、お客様にも喜ばれました」

日本であれば、忙しくとも“あれもこれも”できる人の方が評価されることが往々にしてあるが「物量じゃなくて、バリューを出す」ことが大事だと痛感できたのは発見だった。

「米国では、エンジニアであれマネージャーであれ、自分がパツパツになると平気で予定を変えるし、なんなら仕事をドロップしてきます（笑）

私が『そろそろ次のプロジェクトにも取り掛からないといけないし、この仕事を早く終わらせないと』と焦っていると、『いや、時間をかけてもいいから、良いクオリティーで終わらせることに集中しよう』と言ってくるのが当たり前な世界。

ある時は、当時メンターだったクリスが『剛はAのプロジェクトとBのプロジェクト両方やるとチョイスしたよね。確かに両方できると思うけど、Bはやらない方がいい』とアドバイスされたことも。私自身『両方やる』と決めていましたし、実際にできる可能性は十分にあったにもかかわらずです」

クリスに理由を問うと「Aは明らかにインパクトがある。だけど、Bにも手を付けていたら君の工数が奪われるじゃないか」と返ってきた。

クリスが勧めたAのプロジェクトは、技術的には難易度が高いものではない。ただ、実行すればスループットが何十倍にもなり、それをマイクロソフトの上層部にデモンストレーションできるような類いの仕事。一方のBのプロジェクトは技術的に高難度だけど、エンジニアとしては楽しいものだった。

もちろん、両方やる道もある。しかし、Bにも手を出せばシンプルに「大変」なのだ。

「自分が楽できる方が、結果的にインパクトが出せる。それは先述のハッカソンで得た経験から分かっていたのでAのプロジェクトに全力を注ぐことを決めました」

こうした経験を通じて、牛尾さんは『Be Lazy』はわざわざ無理なことをするのではなく、「インパクトのある、より重要な仕事に集中せよ」と意訳できることにも気づいた。

文化がないなら、インストールすればいい

怠惰が奨励されるなんて「米国のカルチャーだからでしょ？」。そう思った読者は少なくないだろう。そこで、日本のIT業界で長年戦ってきた牛尾さん流「カルチャーが違った場合の対処法」も教えてくれた。

その答えはずばり「文化がないなら文化からインストールしてしまえ」だ。

「例えば、画期的なテクノロジーが登場すれば誰しも『早く導入したい』気持ちに駆られるのは当然です。ただ、その気持ちや行動を組織が阻害するようなら、まずは文化からインストールするのがいいでしょう」

文化インストールの方法として、牛尾さん自身が異文化の専門家であるロッシェルカップさんと共同で作成した「8Habit」（8つの習慣）を現場に伝えることを勧める。

「私がよく行なっているのは、新しいプロジェクトが始まる前に社長も含めた主要メンバーに、8つの習慣について話す時間を設けることです。この価値観をベースにプロジェクトを進めると、生産性が高まると伝えています。

会社全体に波及とはいかなくても大丈夫。少なくともチームやマネージャーにインストールすれば、その人たちには『いい価値観とはこういうものか』とか『こうすればみんなが楽になるんだ』という土壌ができ、物事を進めやすくなります」

他にも、日本のエンジニアチームを米国マイクロソフト本社に連れて行き、本社ツアー的な取り組みで文化インストールを促したこともある。

「『Be Lazy』を体現している米国本社の開発チームを目の当たりにし、日本の開発メンバーたちは『あぁ、Be Lazyって本当に実現できるんだ。価値あることなんだ』と身をもって実感することができました」

文化インストールの成功事例として、もう一つ別の事例も教えてくれた。

「例えば、アプリが生産的にアップデートされるのは誰だってうれしいですよね。にも関わらず、そのための改修作業にNOが出ていると仮定しましょう。

その場合、大抵はミドルマネジメント層がNOを出していたりします。なぜなら、さらに上の上層部からすれば生産性向上はむしろウエルカムですから。ところがミドルマネジメントの方にとっては、自分のKPIがあるはずなので慣れない方法をやることは恐怖しかないと思います。ですので、上層部を巻き込むことで、このプロジェクトを推進したミドルマネジメントは評価されるし、このプロジェクトに関してはKPIも気にしなくてよい等の『安心』を与えてもらえると変化を起こしやすくなります」

下記図は、牛尾さんが過去に支援した企業のケーススタディーだ。ソフトウェアがリリースされるまでにどんなプロセスがあり、時間と人が費やされているのかを可視化したものだ。

「上層部からミドルマネジメント、メンバーまで一堂に集め、承認までのフローを可視化。どの工程で、誰のどのくらいの時間が使われているのかを全員で洗い出す作業をしました。

関係者同士ひざを突き合わせて『この工程は要る、要らない』を話し合えたことで、リードタイムが8カ月だったところから1週間に縮めることに成功しました。こんなにリードタイムが短縮するのを歓迎しない経営層がいるでしょうか？」

こうした取り組みを地道に積み重ねることで、どんなに深く根差した文化も変えていけるのかもしれない。

「僕の好きな考え方でJames Clear提唱の『AtomicHabit』があります。詳しい内容はぜひ書籍で読んでほしいのですが、その中に出てくる一節で、ニューヨークからロサンゼルスへ向かう飛行機の話があって。飛行する前にたった三度だけ方向を南に変えると、到着地がメキシコのティファナになるという内容です。

つまり、少しの変化の積み重ねが、大きな変化につながるということ。文化であれ、今任されている仕事であれ、何かを一気に変えるのは難しい。そんな時こそ一度ずつでいい。行動することが大事です。

いろいろな状況が決断を難しくするかもしれませんが、できないことはありません。“万年のび太”だった私にできたんですから、みなさんにやれないことなんてありませんよ」

取材／伊藤健吾・玉城智子（編集部）
文・編集／玉城智子（編集部）

書籍紹介

『世界一流エンジニアの思考法』
著者：米国マイクロソフト シニアエンジニア　牛尾剛

「怠惰であれ!」「早く失敗せよ」――
米マイクロソフトの現役ソフトウェアエンジニアの著者が、超巨大クラウドの開発の最前線で学んだ思考法とは？
“三流プログラマ”でもできた〈生産性爆上がり〉の技術！

・試行錯誤は「悪」。“基礎の理解”に時間をかける
・より少ない時間で価値を最大化する考え方とは？
・「準備」と「持ち帰り」をやめて、その場で解決する
・マルチタスクは生産性が最低なのでやらない
・“脳の負荷を減らす”コミュニケーションの極意
・コントリビュート文化で「感謝」の好循環を生む……etc.

仕事と人生を「自分の手でコントロールする」最高のスキルがここに！

＞＞詳細はこちら