超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（2） Regional Scrum Gathering Tokyo 2022
本記事は「超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1）」の続きです。
日本のエンジニア層と米国のエンジニア層の違い
次はエンジニアのレベルっていう話です。
これはもう僕のイメージなんですけど、日本のエンジンニアは、もちろん技術力の高い人がたくさんいます。
たくさんいるんですけど、ある一定以上のレベルになると人数がすごい減るっていうイメージがあります。
アメリカの場合は、別にエンジニアがすべて優れているとは思っていませんが、基本的に一定のレベルが担保されてる感があって、みんな普通にオブジェクト指向とか、関数型とかDIであるとかデザインパターンとか、そういうのはもうみんな普通に使える、というのは当然になってますね。
日本でもそういう技術力の高い人はいますけど、人数が圧倒的にアメリカより少ない感があります。
この違いを考察してみると、まずはやっぱりコンピュータサイエンスですね。
アメリカの場合はコンピュータサイエンス出身の人じゃないとエンジニアになれないのが基本なんです。
コンピュータサイエンスをやっているから、新人だからプログラミングができないなんてないです。やっぱり学問ってすごい重要だなと思います。
何で日本は優秀なエンジニアの人数が先細りしているのかというと、これは2つの原因があるんじゃないかと思っています。
1つは経験できるシステムです。例えばシアトルのエリアに住んでたら、僕が優秀か否かっていうのに関わらずマイクロソフトに就職できるし、Amazon.comに就職できるし、Facebookにも就職できるわけです。Googleもそうやし。
シアトル住んでいれば普通の話なんです。世界でみんなに使われるようなクラウドの開発に携わったりとか、みんなが世界で見たことのないようなプロダクトに携わったりすることができるわけですよね。
だから、頭の差とかじゃなくて経験できるんです。そしたら経験値も上がりますよね。そういうオポチュニティがあるのが1つ目の差なんじゃないかなっていうのをすごい思います。
そしてPh.D.ですね。
日本の場合は、Ph.D.っていうか院まで行ってドクターになっても就職先がないとか言いますけど、アメリカでPh.Dって言うともうかっこいい、大体はすごいエンジニアです。
すごいエンジニアで、マイクロソフトで言うとMSR（Microsoft Research：同社の研究部門）の人なんかはだいたいそうなんすけど、もうものすごい戦闘力ですわ。
やっぱり専門で何年も研究した人はモノが違いますね。すごいプロダクトを作ったりとかもしてくれてるんで、だからそういうふうなところの差が出てるんじゃないかと僕は個人的には思っています。
イノベーションは地道な技術の積み重ねと研究
最後にイノベーションのコーナーに行きたいと思うんですけど、イノベーションとかデジタルトランスフォーメーションとか言われますけど、イノベーションってどんなイメージがありますかね。
去年のMicrosoft Buildという大きなイベントのキーノートで発表された「Azure application services」というサービスがあります。
どんなサービスかというと、Azure FunctionsやAzure App ServiceといったAzureのサービスを、AWSでもGoogle Cloudでもオンプレミスでも、どこでも動くようにする、というものです。
だから発表されたときにすごい話題になりました。
僕は作ったわけではないのですが、関わってはいました。
それで、こういったイノベーションを中の人から見たらどんな感じなんかっていうと、僕から見たらこんな感じでした。
すごい地道な技術的な積み重ねと研究と、過去のプロダクトですね。
例えば、スケールコントローラーの部分は、僕らが長年オープンソースやってたKEDAっていうやつがあって、そのKEDAにちょっとだけ機能拡張して使ってます。
中の部分はGo Langで書いてあって、機能を実装するときもKubernetesで動くようにしたり、他のAzureのプラットフォームで培ったデザインパターンみたいなのを適用して作っていたりとか。
何年も前からちょっとずつ開発をして、積み重ねていった結果ですね。
他にはMicrosoft Researchという研究部門が人を派遣してくれて一緒にやって新しいプロダクトできたっていう例もあります。
だからやっぱり投資もしてるし時間もかけてるし、小さな技術の積み重ねなんです。
ビジネスサイドのビジョンが明確だった
その中でも面白いのは、ビジョンが明確だったな、と。ビジネスサイドの人が明確なビジョンを示してくれてたんですね。
ビジョンというのは、Azure Functionsっていう僕らのサービスをGoogleでも、AWSでもオンプレミスでも、どこでもAzureで動かしてるのと全く同じレベルで動作させる、というもの。
そんなの技術的に不可能かもしれないけど、それでも最初からこのビジョンを一貫して言ってくれた。
僕らも、技術的に完全なものは不可能と分かっていても、それに近づけるようにするにはどうしたらいいかっていうのをみんなすごい考えて頑張ったんですよね。
あとはやっぱりコンピュータサイエンス、技術力
あとはやっぱり技術力です。なんかコピペしかできへんような人やったら無理ですよね。日本ではイノベーションが起こらない、なんでか？ とよく言われますけど、単純に技術とか経験の差なんじゃないかなと僕は思います。
やっぱりコンピュータサイエンスへのリスペクトとか、ソフトウェアエンジニアリングには少なくともその基礎知識が必要であると。そのベースがあるから僕らは余分なことに工数を使わなくていいわけです。
分からない人にレクチャーする必要もないし、開発手法の標準化みたいなものもいらないですよね。ちゃんとしたエンジニアならいらないんじゃないですかね、そういうのって。
開発者の個々人がちゃんとした人であれば問題ないはずで、そういう人材をアメリカの企業は求めているし、少なくともジョブインタビューではそれが前提条件だとしてそういうのを求められる。
すると就職する学生さんもコンピュータサイエンスを出ておこう、と思うわけじゃないですか。そこでマスターとか出た方がより給料は高くなるよねとか、Ph.D.はもっと給料が高くなるんだったら、みんな院に進みますよね。
本当に競争力を持ちたかったら世の中にないものを作らないといけないじゃないですか。となると、やっぱり本当に重要なのは基礎知識、コンピュータサイエンスですよ。
だから実は僕も勉強したんですよ、ジョブインタビューのときに。アルゴリズムとデータ構造とか。
僕はコンピュータサイエンス出てないし。そういう基礎があるとやっぱりレベルが上がるので。ある程度そういうことが力になると思います。
納期がなくても遅ければネガティブに評価されるか？
ここからは会場とインタラクティブにQ＆Aをやっていきたいと思います。どんなことを聞いてもらってもかまいません。
司会）すごいインパクトがあったのが、さっきの納期がない話。納期がないんだったら、例えば毎回やろうと思ったことが達成されないとネガティブ評価になるんじゃないかとか、納期がないとするならば、そのマネージャのレスポンシビリティは何になるんでしょうかと、そのマネージャは何で評価されるんでしょうかっていう質問が出てますね。
何でしょう、納期って予定じゃないですか。これぐらいにできて欲しいなっていう希望ですよね。それが正解であるってどうやったらわかるんですかね。多分神様でないと分かりませんよね、正直な話。
やってみたらめっちゃ難しかった、みたいなのは普通にあるわけじゃないですか。もしかするとうまくいって早くできるかもしれないし。
開発者の人は、さぼってない限りはその人のベストを出しているわけじゃないですか。そうしたら、それが最速なんじゃないですかね。
そのプロダクトというかフィーチャーが完成するのは、その人にアサインしたらその人がレスポンシビリティを持っているんだから、それが最速なんじゃないかと思います。
他の人にアサインしたら、もしかしたらその方が早かったかもしれませんが、その他の人とは生産性が違うし、その他の人は違う仕事をしてる。
それが最速だったと従業員を信頼する
その状態である人にアサインしたら、そこはもうトラストしかないんです。エンプロイ（従業員）をトラストすることしかないんです。
ちゃんといい人を選んで採用しているのであれば、その人を信頼してやってもらって、その人が頑張って一生懸命やってそれでもすごい長い時間かかったんだったら、それはそれが最速なんですよね。
僕はマネージャから「遅かった」って言われたことは1回もないけど、僕の方から「遅かったと思うけど、どうやったらもうちょっと早くなったと思う？」みたいなことを自分から聞くとはあります。
でもマネージャからは基本的に言われなくて。
知らないコードベースでの開発は誰だって遅いと思うんですよ。だからジョブをアサインにしたら最初はすごい遅いかもしれないけど、そのジョブが終わって次が来たら、その人がそのエリアではもっと早くできる。
そしたら、マネージャからすると、こいつができるエリアが増えて、チームとしては生産性上がる。だから結果で考えるしかないんじゃないすかね。
開発者をどう評価するか？ マネージャをどう評価するか？
それから評価。マネージャも同じようなのですけれど、ICの場合はどう評価するかというと、3つあるんです。個人のインパクト度、他の人をいかに助けるか、既存の資産に対していかに貢献するか。
特にマネージャは他の人に対する部分が大きい。いかにチームの人が幸せに働けるかとか、そういうことに彼らは注力してる感じです。
ちょっと最初の方で言いましたけど、いかにICが快適で、マイクロソフトで働き続けていたくなる。彼らのキャリアを伸ばす。ICが将来こうなりたいっていうのを実現できるように、彼らは助けてくれるんです。
それがたとえ違うチームへの転職であってもそうなんです。それが彼らの仕事なんですよね。
そういうのがうまくできる人で、ICが「あのマネージャいいね」って言ってる人は多分評価が高いんだと思います。
司会）マネージャが牛尾さんより技術力があるというのはかなりそれを成立させてる感じがしますね。
そうだと思います。僕も余計な説明をしなくていいし、僕より知ってるんで。
なので、彼らがそのプロダクトを早くリリースしたいときはアイディアを出してくれるんですよ。難しそうだねと、だったらこのプルリクエストを2つに分けて、こっちの前半だけマージしておくのはどうか、とか。
で、こっちの方はちょっと時間かかりそうだから、みんなでディスカッションしてから実装しようかと。そういうのはあります。
「お前とりあえず土日で頑張れ」みたいなことはないです。
部下が出来なかったらマネージャが代わりにやることはあるのか？
司会）例えば自分の部下できなかったところを、最悪マネージャが自分がやるからいいやって思ってるかどうか、という質問です。
プルリクエストのレビューはしてくれるけど、彼らがやることはないですね。一度誰かにアサインした仕事をマネージャが奪うようなことは多分しないです。
技術者としてのゴールをどう管理しているか？
司会）会場から質もう一つ質問。牛尾さんが一つの目標として一流のプログラマを目指していくとき、どうやってその目標を管理しているかとか、どうやってらっしゃるんですか。
それはすごい難しいですね。僕がね、もうそれを達成していれば「こうです」ってかっこよく言えるんですけど、達成してないんでね。
僕の今のゴールはプリンシパルエンジニアになることを考えています。
プリンシパルがだいたいどういうレベルかっていうと、クロスオーガニゼーション（組織横断）に対してインパクトを与えられる。言ってみれば、Azureで販売できるレベルのサービスを1人で作れるぐらいの勢い、それぐらいの技術力です。
そのプリンシパルになれたら、僕は多分、自分を一流のプログラマになりましたって自信を持って言えると思うんですよね。
そういうのに目標を置いて、僕はOKRを個人的に回したりとか、でも手探り状態です。
あとやってるのはメンタリングセッションっていうのがあって、相手がOKなら自分が指定したメンターに隔週ぐらいでメンタリングしてもらえるんです。
僕自身は三流やけど、僕の周りはもう超イケてる人たちがいるわけです。
僕はAzureのいろんなサービスをゼロから開発してきたというすごい人がいるんですが、その人にメンタリングをお願いしていて、アドバイスをもらったりとか、困っていることに相談に乗ってもらったりみたいな。超贅沢ですよね、これはねもう最高です。
超絶賢い同僚がどういうふうに仕事をしているのかを、直で見る機会があるので、そういうのを見習いながら自分なりに計画を立ててイテレーティブにやっています。これが本当に有効かどうかは分からないし、つねにストラグルですね。
チームワークを大事にするにはダイバーシティとトラストが大事
司会）3年間米国にいらっしゃる牛尾さんから見て、チームワークを大事だと心で思ってる日本人がちゃんとチームワークを発揮するために、こうしたらいいんじゃないかっていう、何かアドバイスあったらぜひお聞きしたいです。
チームはやっぱりダイバーシティとトラストじゃないすかね。人との違いを認めるというか。
マイクロソフトも標語として「ダイバーシティ&インクルージョン」って言ってますが、末端までそれが染み渡ってる感じです。
僕は「あいつは（開発速度が）遅いな」とか言われたことないです。実際は僕の方がみんなより遅いんですよ。観察するとどう見ても遅いけど、マネージャは僕にそんなこと言ったこともないし、僕の同僚が僕を見下したりとかしたことは1回もないです。
アメリカのカルチャーなのか会社のカルチャーなのか分からないですけど、そういう環境があるので、自分のベストを尽くせる環境にフォーカスできる。
だから僕は他の人と比べてじゃなくて、僕が今の僕よりも成長できたら会社にとって貢献だし、それがチームの成功に繋がるのでWin-Winなんですよね。
マネージャも僕が成長すればチームの勝利に繋がるし。
だから尻を叩くとかそういうのって日本ではよくあったかもしれませんが、今から考えたらパワハラかなとか、人を子供扱いしてるっていうか。みんなそれぞれ違っていて生産性も考え方も、みんな違う中でね、他の人と比べるってのは意味がないですよね。
その人を採用したら、ファイア（解雇）しない限りはその人がいかにベストを尽くせるかどうかが重要であって。給料も決まっているので他の人と競争という仕組みもないっていうところはあります。
トラストは、ちゃんと信じて任せてくれるというか。
日本の組織の場合って何かこういうルールみたいなたくさんあったりしますが、あれって基本的に、エンジニアというかエンプロイを信頼してないからじゃないですかね。
そういうトラストとダイバーシティをちゃんと重視してくれる二つの基盤があって、他の人と比較する必要もないし自分が信じてもらえるので、他の人にも寛容になれる、っていうサイクルになってるんじゃないかなと思います。
司会）牛尾さんは「これはやばい、自分はクビになる」って思ったことはありますか？
ありましたよ。すげえ失敗したことあります。さっき言ってた、1週間で出来ると思ったやつが半年かかったやつなんですけど。
このチームに入って、6カ月ぐらい試用期間があって、そこであまりにもできへんかったら、そこでファイアされるかもしれないですけど、そこをちゃんと生き延びたら、あとはマネージャとかはメンバーに居続けてほしいみたいですね。
基本的にマネージャは本当は各メンバーがチームにいてほしい。というものらしいです。
やっぱりエンジニアの採用は今すごい大変です。だから開発してる人がハッピーになるっていうこともすごく重要みたいですよ。そこで働いてる人はみんな快適に働いていてそしたら、さらにタレンテッド（有能）な人が来てくれるやないですか。だからそういうのにすごい気を使ってるみたいです。
司会）牛尾さん、ありがとうございました。みなさん、大きな拍手をお願いします。
関連記事
2016年に行われたエバンジェリスト時代の牛尾さんの講演も非常に大きな反響がありました。あわせてお読みください。
- 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
- 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016
Regional Scrum Gathering Tokyo 2022
あわせて読みたい
さくらのレンタルサーバがリニューアル、価格据え置きで最大で性能5倍の新サーバ提供へ。既存ユーザーの移行も可能
≪前の記事
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022
