現在Microsoftのシニアソフトウェアエンジニアとして、Azure Functionsプロダクトチームで活躍する牛尾剛氏。日々最前線の技術に触れながら、その知見を日本のエンジニアにも共有しています。著書『世界一流エンジニアの思考法』は、多くのエンジニアにとってバイブル的な存在となっており、現在までに9万部以上売れています。
本記事では、そんな牛尾氏が『Developer eXperience Day 2024』（主催：日本CTO協会）で講演した「米国巨大IT企業で働いて分かったソフトウェア開発文化とマインドセットの違い」の模様をご紹介します。
スピーカー紹介
牛尾 剛
Microsoft
Senior Software Engineer
米MicrosoftAzure Functionsプロダクトチーム シニアソフトウェアエンジニア。
シアトル在住。PM・コンサルタント・経営者を経て、2019年より米国本社でAzure Functionsの開発に従事する。
著作に『世界一流エンジニアの思考法』など。ソフトウェア開発の最前線での学びを伝えるnoteが人気を博す。
目次
牛尾氏のエンジニアとしての歩み
牛尾氏は、幼少期からコンピュータに強い興味を持ち、日本の大手SIerに就職しました。入社面接では「UNIXのコマンドを担当したい」と強く願い、プログラマとしての道を目指していたといいます。しかしながら、初めの配属先は営業部門で、希望とは異なるスタートとなりました。
営業の仕事にやる気を見出せなかった牛尾氏ですが、よい上司に恵まれ、5年目にようやくシステムエンジニアに転身することができました。システムエンジニアとしてのキャリアをスタートさせたものの、最初はなかなか成果を出せず、自分の技術力の不足を痛感したそうです。
その後、2002年ごろにアジャイルのコミュニティに参加し、そこでの活動を通じて自身とコミュニティの仲間たちとの違いを認識したといいます。また、このころからコミュニティで自分の事例を作ったり、発表したりするようになり、会社の中でも風向きが変わってきたと感じたそうです。
「システムエンジニアだし、やっとコードが書けると思ったら。まるで役に立たなかったですね。やっぱり人事の人はよく見ていました。エバンジェリストやコンサルみたいなことをやるのは得意なんですけど、実際にやってみると通用しなかった。だから僕は昔からどうやったら、できるような人になれるか、っていうのをとても知りたかった。
アジャイルとかやってた仲間と比べると、いったい僕は何があかんのやろうって、ふわっと思ってたんですね。そう思っていたときに、ふと気がついたのはアジャイルって2つの要素があって、いわゆるヒューマン系であるとか、組織をどう回すかみたいな話と。あともうひとつは、技術系の話なんですよ。
コミュニティで出会った僕のお友達っていうのは、みんなそれぞれそもそもエンジニアとして成功してアジャイルコーチになってるんです。僕はエンジニアじゃなかったです。やはりこの技術の要素っていうのが自分に不足しているから、だから自分は薄っぺらなんだなと思ったんですよね」
アメリカでのキャリア転換
日本でのキャリアに壁を感じていた彼は、英語力を活かしてMicrosoftのエバンジェリストとしての道を切り開きました。エバンジェリストの仕事は、技術力よりもプレゼンテーションやコミュニケーション能力が求められます。そのため、牛尾氏にとっては非常に適した役割だったそうです。
「エバンジェリストは、ちゃんと人に説明できるとか、プレゼン力があるとか、そういうのが活かせる役割でした。実際に自分でデモをしたりコードを書いたりしますので、多少の技術力は必要ですが、これまでやっていたコンサルよりは、ちょっとプログラマ寄りでもあり、自分にとっては非常によいステップでした。
日本では通用しなかったんですけど、どうやって今のAzure Functionsのチームのメンバーに、しかもプログラマになれたかっていうのは僕のブログに全部書いてあるので、もし興味があれば読んでみてください。
Microsoftアメリカ本社での活動を通じて、日本とアメリカの開発文化の違いを強く感じるようになりました。とくに、アメリカでは技術力だけでなく、個々のエンジニアの自主性や創造性が非常に重視されている点に驚きました。これが、アメリカのIT企業が常に最先端を走る理由の一つといえるでしょう」
＜参考記事＞牛尾氏のブログ
https://simplearchitect.hatenablog.com/
Microsoftの開発文化
Microsoftでは、標準プロセスやルールが存在せず、各チームが独自に決めるスタイルが主流だといいます。ウォーターフォールは一切使われず、アジャイル以降の手法が主流となっており、この柔軟な環境がエンジニアの創造力を最大限に引き出す要因となっています。
「さすがに2024年になると、ウォーターフォールは今のテクノロジーとあんまりあってない気がするんですよね。2024年の開発スタイルで、もっと楽なことをしたらいいんじゃないかなと思いますね。こういうふうにするといいかも、という自分なりの意見をブログに書いてみましたので、もし興味があれば読んでください」
＜参考記事＞ウォータフォールはやめて2024年の開発をやろう！https://note.com/simplearchitect/n/nfd147540e3db
牛尾氏のチームでは、各エンジニアが自分のフィーチャーに責任を持ち、設計、開発、テスト、リリース、運用までを一貫して行います。これにより、個々のエンジニアが全体の流れを把握し、自分の仕事に対する責任感を強く持つことができます。また、チームのメンバー同士が頭脳を借り合う文化が根付いており、わからないことがあればすぐに他のメンバーに相談し、知識を共有することが奨励されています。
「チームといっても個人商店の集まりです。ICってIndividual contributorっていうんですけど、マネージャーが一人いて、でかいチームなんていうものは存在しないですね。だからちっさいチームの集まりです。ちいさいチームの集まりで、中身のシステムめちゃくちゃ複雑ですけど、結局意外とみんな思ってるよりたぶん少ない人数でやってますね。
それぞれの人が自分の責任を持ってやっていきます。ICは、他のチームとコラボして、自分からアクションを起こして、情報を得ながら自分のタスクを遂行するという進め方になってます。もちろん、この進め方はあくまで一例として聞いていただければいいかなと思ってます」
エンジニアの評価と昇進が明確化されている
アメリカのIT企業では、ジョブディスクリプションが明確に定義されており、その達成度に応じて昇進が決まります。年齢や経験に関係なく、実力に基づいた評価が行われるため、競争意識が低く、純粋に自分の仕事に集中できる環境が整っています。
牛尾氏は、ジョブディスクリプションに基づいた評価制度が非常に快適であると感じているそうです。日本では他の人が昇進することで自分が昇進できないという競争が常にあり、他方、アメリカではそうしたストレスがなく、自分の仕事に集中できる環境が整っています。とくに、若いエンジニアでも実力があれば早期に昇進できるため、モチベーションを高く保つことができます。
「若い人でもそれができていたらめっちゃ早くプロモートされるし。歳をとっていても別にそれは誰も気にしないというか。本当にジョブディスクリプションと自分の戦いっていう感じになるので、誰もあいつが先に昇進したから俺が昇進できなかったみたいなという争いは全然なくて、めっちゃ気持ちいいですね」
マネージャーの役割は「UNBLOCK」
アメリカのマネージャーは指示を出す人ではなく、エンジニアの成功をサポートする存在です。主な仕事は「UNBLOCK」、つまりエンジニアが作業中に遭遇する障害を取り除くことです。これにより、エンジニアが技術に集中できる環境を作り出しています。
マネージャーは、エンジニアの現場の状況を把握し、必要なリソースを提供する役割を担っています。たとえば、技術的な問題に直面した際に、適切な専門家を紹介してくれるなど、エンジニアがスムーズに仕事を進められるようサポートします。また、マネージャー自身も高い技術力を持っていることが多く、エンジニアからの信頼も厚いと語ります。
「こういう環境でマネージャーの技術力どないやねん、という話ですが、これもすごく違っていて。たとえば僕の上のマネージャー、この人はAzure FunctionsのJavaのランタイムを1から書いた人。その上のマネージャーも、Azure Automationの開発をされてて、どんな技術の話題でも深く理解してすごいアイデアを出したりするパートナーです。その上のフェローは、Azure AppServiceっていう、Azureのフラグシップのサービスを1から書いた人ですね。
僕の上のマネージャーは、すべての僕よりプログラミングが明らかにできるんです。彼らがやったほうが絶対早いって思いますよ（笑）。
そんな環境なので、たとえば何か新しい技術とかやろうとしたときにも、技術のことがわかっているので日本にいたときのような説得のフローがいらない。組織としてめちゃくちゃ楽ですね。開発に集中できますし、技術の高さがちゃんと評価されます。ここは本当にすばらしいなと思いますね」
基本的に納期がない
牛尾氏は、納期に関するアメリカのアプローチについても語りました。
「僕らは信じてもらってるんですよ。そんなこといわんでも、君らみんなプロフェッショナルだからさ、自分のベストでやるやろうって。実際にみんなそうですよね。誰も自らサボるようなやつおらへんし、自分で考えるベストってそれぞれの人間がやるんだから、彼らをトラストするという姿勢ですよね。
何よりも、ソフトウェアと納期って向いてない気がしていて。ソフトウェアは予見しにくいですし、無理やり完成させたら品質が落ちるだけなんですよね。そしたら誰も使ってくれないじゃないですか？そっちのほうが大ダメージですよね」
理解に時間をかけることの重要性
牛尾氏が強調したのは、「理解に時間をかけること」の重要性です。アメリカのエンジニアは、難解なタスクに対して何度も見返して理解を深めることを厭わないという文化があります。
たとえば、牛尾氏の同僚であるトニーは、1時間半ある開発者向けの技術紹介映像を10回も見返して理解を深めるというエピソードを紹介しました。
「トニーだけではなく、横にいたクーパーも『すげぇ難しいから、見ては巻き戻して何度も見てますわ』といってて。僕はけっこうそれがすごい衝撃だった。
賢い人って、あんなのすぐ見てわかって、賢いな。羨ましいなと思ってたんです。でも実際はそうじゃなくて、理解に時間かけてるだけなんですよね。賢いトニーが10回見てるのに、僕が一回見てわかるはずないです。だから、理解に時間かけるのってすごく重要だということを強く思いました。
また、会議中に理解できない点があれば、その場で質問して理解するまで説明を求める姿勢が一般的です。僕が最も賢いと感じる同僚が、会議中にわからない点をしつこく質問し、その後に素晴らしいアイデアを提案する光景を目の当たりにしています。このような姿勢が、質の高い仕事ができる要因になっていると考えます。
それから僕が「実装遅くてゴメンな」とかいってたら「そんなことは気にしなくていい」「君のスピードで君が納得するまでちゃんとした品質のものを出そう」といつもいわれますね。ソフトウェア開発に関しては、理解に時間をかけることによって、実は早くなるということを、すごく実感しています」
徹底的な自動化と品質管理
Microsoftでは、開発プロセスの多くが自動化されており、とくにカナリアリリースやフィーチャーフラグの活用が重要です。徹底的な自動化によって、人為的なミスを減らし、効率的に高品質なソフトウェアを提供することが可能です。
たとえば、カナリアリリースでは、新しい機能を段階的にリリースし、問題が発生した場合にはすぐに元のバージョンに戻すことができます。また、フィーチャーフラグを使用することで、新しい機能を簡単にオンオフできるため、リリースのリスクを最小限に抑えることができます。レビューやデザインレビュー、Bug Bashなどの手法も駆使して品質管理しています。
「自動化しないと世界中のサービスなんかとてもとても回せません。でもとても普通のことしかやってません。本当にうちが特殊とかじゃなくて、どれも当たり前のDevOpsテクニックですね。
Bug Bashはいろんな立場の人が、それぞれの立場でシステムを使ってみてバグ出しをする手法です。決まったテストケースが定義されているわけではないため「こんないい加減でいいの？」と思われるかもしれませんが、各関係者によって多面的にテストされるため意外と有効な手法です」
失敗の歓迎がイノベーションにつながる
イノベーションの鍵は、地道な技術の積み重ねと失敗の歓迎です。新しいプラットフォームの開発やビジョンの共有が重要であり、経営層の明確なビジョンがエンジニアを鼓舞する要因となっています。 たとえば、牛尾氏が関わったFlex Consumptionの開発では、最初の試みが失敗に終わりました。しかし、その経験を活かして新しいプラットフォームを開発し、最終的にはスループットを40倍に向上させることができました。
「当時のプラットフォームで実現できなかったとき、僕はけっこうしょんぼりしましたよ。だって俺がやってたのは、何の意味もなかったのか。あんなに時間かけたのになって。ただポールってやつは、逆にぜんぜん違う反応だったんです。『あー、こうやったらできない。ということがわかった』『よかったよかった』みたいなこといってたんですよ。
その後、新しいプラットフォームを開発して僕らがやってたことが今度は使えるぞと。失敗をいろいろ重ねて、どうやったらいいかというのがわかっているので、フィーチャーを一瞬で実装してやったら、大幅なスループット改善ができたんですよね。
だから失敗って別になんてことはなくて、プログレスなんですよね。失敗したらこういうのはできないってわかった。じゃあ次はこうしてみよう。日本では何もアウトカムがないって思われるかもしれないけど、こっちでいうと「あ、それでやってくれてありがとう。」ってなる感じです。失敗を恐れず、地道な積み重ねを続けることで、大きな成果を生み出すことができるんです」
明確なビジョンを持つ経営者の存在
経営層が明確なビジョンを持ち、それを共有することも重要です。牛尾氏は、Microsoftの経営層が常に数年先を見据えたビジョンを持ち、その実現に向けてエンジニアたちが努力する姿を目の当たりにしています。
「最初のビジョンを聞いたときに「え、そんなんできんの？」って正直思ったことがあります。僕はそう思ったんですけど、そういうのみんな頑張って実装しちゃうんですよね。経営層が思っているビジョンをほんまに実装して、その経営ビジョンも、さすがですよね。みんなが熱狂するようなことを考えているわけですよ。すごい前から。だからそういうビルディングも素晴らしいなと思ったし。これが、イノベーションを生み出す原動力にもなっているんだなと」
There is no magic
牛尾氏は、自分の経験を通じて、日本のエンジニアたちにも同じような成功を収めてほしいと願っています。
「今日はいろいろお話ししてきましたけど、ここまで僕がお話ししてきた内容って、たぶん、日本人だからとか、日本だとできないってことは何一つないと思うんですよ。だってDNAが違うとかじゃないですよね。
僕がこういう情報発信をしているのは、やっぱり日本がよくなってほしいなと思っているからです。僕はたまたまラッキーで、今アメリカで昔夢見ていたようなチームで働いていて、自分自身いろいろびっくりしています。そういう経験が一つ日本のためになったらいいなと思って、学んだことをいろいろシェアしているという感じです。
僕のマネージャーが『There is no magic』といってましたけど、もう一度、日本が技術の国になるには地道なことをしないといけないと思います。でもそうやっていけば、僕らが負ける道理には何もないと思うので、ぜひ日本でも技術を楽しくやっていけるようになればいいなと思いまして、このような話をさせていただきました」
取材後記：米国ITエンジニアのマインドセット
牛尾氏の講演から、日本と米Microsoftにおける開発文化とマインドセットの違いを知ることができました。個人的にも、ITエンジニアとしてのスタンスを改める要素がちりばめられており、大変有益な内容でした。
とくに、理解に時間をかけることの重要性や、失敗を恐れず挑戦し続けるマインドは、大切にしていこうと思いました。これらの要素は、米国巨大IT企業の成長要因のひとつであるといえるでしょう。日本でも同様の開発文化を取り入れることで、技術力を向上させる可能性は大いにあると感じました。
（文：星影）
