「才能ない」と言われたエンジニアがAzure開発者になるまで　日米ソフトウェア開発文化の違いと挑戦

牛尾剛氏の自己紹介と経歴

牛尾剛氏：はい、おはようございます！　おはようございますじゃないんや、よくわからへんねん。僕は今10時ぐらいなんですけど、みなさんの時間帯がよくわからないですね。というわけで今日は、「米国巨大IT企業で働いてわかったソフトウェア開発の文化とマインドセットの違い」をテーマに、話をしたいと思います。

私はエンジニアをやっています。Azure Functionsという世界中で使われているクラウドの中の人として、中の開発をしています。ただ、今はエンジニアなんですけど、僕は実は昔はどっちかというとPMとかコンサルタントで、それからエバンジェリストを経て、今のプログラマーになったというキャリアを持っています。

1個だけ宣伝をすると、おかげさまで書いた本『世界一流エンジニアの思考法』が今9万部手前（現在は9万部越え）ぐらいまで売れているんで、もしよかったらみなさんも、買うてない人はぜひ買うて、僕の養分になっていただければなと思います。1個だけ自慢なんですけど、こんな感じで、一番いい時は『フリーレン』を倒しました、みたいなね。もうこれがたぶん人生の頂点ですけど、そんな感じでやっています。

キャリアの転機

今日の話はいろいろあるんですけど、なぜ米国でクラウドの開発者になったのかとか、そういう話から進めていきたいと思います。僕は子どもの頃からえらくコンピューターが好きで触っていて、実際に僕は大手SIerの日本のところに就職しました。

その時も面接で「えーっとですね、UNIXのコマンドを担当したいです！」って、僕はプログラマーになりたかったんで、そういうことを言ったんですよ。

そしたらどうなったかって言うと、ほぼ営業配属でございました。無念と。めっちゃやる気がなかったんですけど、5年目ぐらいやったかな、あるすごく良い上司が、僕をとうとうシステムエンジニアにしてくれました。昼間は営業して、夜によくUNIXとかを触ったりしていました。

システムエンジニアってすげぇ！　うれしい！　やっとコードが書ける！　と思ったら、まぁまるで役に立っていなかったですね。やっぱり人事の人はよく見ていました（笑）。

だから僕は昔からどういうタイプであったかって言うと、何やってもできないというか。特にエバンジェリストやコンサルみたいに、人にやってもらうことは得意なんですけれど、自分がやるってなると暗黒みたいな。だから、僕は昔からどうやったらできるような人になれるかっていうのをめっちゃ知りたかったっていうのが過去になります。

僕は、もうすっげぇできなかったんですけど、この風向きが変わってきたのが、2002年ぐらいにコミュニティに参加したぐらいですかね。その頃にアジャイルと出会って、そういうようなコミュニティに出るようになって、自分も事例を作ったり発表したり、そういうことをするようになって、会社の中でもちょっと風向きが変わってきました。

その後は、僕はアジャイルのコンサルみたいなやつをやっていたんです。こういうのをやっていて、そういうのはね、すごく上手くいくんですよ。お客さんにも喜んでもらえるし、仕事も尽きないし、とっても上手くいく。

でも僕は本当はプログラマーになりたいんで、PMとかコンサルとかをやりながら、「牛尾剛君にプログラムのタスクをアサインしよう」みたいなことを無理やりして、自分に無理やりプログラミングのタスクをアサインしてやろうとするんですけど、まぁこれが才能がなくて上手くいかないんですよ。

どうなったかって言うと、いつもよく、ほんとにみんなに言われていたのが、「いやぁ、牛尾さん。プロマネとかPMとかコンサルやったらすごく才能あるのに、ぶっちゃけプログラマーとしては才能ないですわ。ほんま、ほんまマジでやめといたほうがいいっすよ」って、「ほんませっかくやからコンサルしはったらいいのに」って、本当によく言われていました。

それぐらい僕はほんまに自分でやることに関しては才能がないです。だからもう仕方がなくて諦めて、またコンサルに戻るみたいな。そのイテレーションを繰り返していたみたいな、そんな感じでしたね。

Microsoft での経験

そして、アジャイルコンサルタントとしてやっていたんですけど、実はある程度の時から僕は壁を感じていました。だってアジャイルコーチを始めたのは僕はめっちゃ早くて、2003年ぐらいからやってるわけですよ。だからまぁ言うたらアメリカの人含めても、かなり初期メンバーみたいな感じなんですけど、なんかね、自分は薄っぺらいなぁって実は思っていました。

仕事は来るんですよ。　自分で会社やっても仕事は来るし、食べていけるんですけど、なんで俺は薄っぺら感があるんやろうみたいなことを、すごく思っていたんですよ。

それを考えると、なんやったんやろと。一緒にそういうアジャイルとかをやってきた仲間とかと比べると、いったい僕は何があかんねやろう？　ってフワッと思っていたんですね。

それを思っていた時に、ある時ふと気がついたんは、アジャイルって2つの要素があって、前に言うたいわゆるヒューマン系であるとか組織をどう回すかみたいな話のレフトウィングって話と、あともう1つはライトウィングといって技術系の話なんですよ。

先ほどシェアしたような僕のお友だちは、みんなそれぞれ、そもそもエンジニアとして成功してアジャイルコーチになっているんです。僕はエンジニアじゃないんです。じゃなかったんです。だからソフトウェアエンジニアになりたかったけど、才能がなさ過ぎてならなかったんですよ。まぁそういう人間です。

やっぱりこの技術の要素が自分に不足しているから、自分はシャローshallowなんやな、薄っぺらなんやなって思ったんですよね。

僕はだいたいそもそもプログラマーになりたくて、すげぇなりたいなって思っていたけど、日本ではぜんぜん通用しなかったっていう時がありました。その時にちょうどたまたま英語を勉強したんで、英語を使える仕事に就きたいなと思って、Microsoftのポジションが空いていたんで、Microsoftに応募してエバンジェリストになりました。

エバンジェリストっていうのは、僕にとってはすっごく良くて。なんでかって言うと、おもしろかったし、自分はプログラマーになりたいけど、コンサルとかPMをやっていた人がいきなりプログラマーをやるってすごくハードル高くないですか。でもエバンジェリストは人前でデモをする仕事とかやから、そこまでは技術力は要らないですよ。どっちかって言うと、ちゃんと人に説明できるとか、プレゼン力があるとか、そういうのが重要なわけであって、そこまでは技術力は要らないんですよね。

でも実際に自分でデモをしたり、コードを書いたりはするんで、コンサルとかよりはちょっとプログラマーに近いというふうな感じなんで、自分にとってすごく良いステップでした。

その頃からアメリカの本社とかに行く機会があって、僕はもともとアジャイルのコーチやったんで、そういう開発プロセスに興味あったし、日本とアメリカって何が違うんだろうっていつもすごく思っていました。

なのでアメリカっていつもそんなね、いつも最先端を行っている感じやし、日本とすごく差あるし、なんでやろうなぁ。これは何が違うんやろうっていうのが僕がずっと思っていたテーマです。ちょうど2018年12月にシアトルに移住したというのが、僕のキャリアになっています。

僕は日本ですら通用しなかったんですけど、実際にじゃあどうやって今のAzure Functionsっていうチームのメンバーになれたか。しかもSDE、つまりプログラマーとしてそういうのになれたかっていうのは、ここのブログに全部書いていますんで、もし興味があれば読んでみてください。

Azure Functions プロジェクトの特徴

今日はどっちかっていうとCTO協会の話なんで、ふだんとは違う話をしたいと思います。米国のMicrosoftみたいな巨大なところで働いている、ソフトウェアの開発の現場っていったいどんなんだろう？　っていうのを、みなさんにシェアしたいなと思っています。

僕が働いているところはこのMicrosoftのキャンパスっていうところです。こういうふうなビルが100個ぐらいレドモンド市にあるからキャンパスっていわれてるんですよ。すごく大きなところです。そんなに高くない建物が100個ぐらいあって、僕はそのビルディング18っていうところで働いています。

今日はどっちかと言うと、開発者さん向けというよりも、どういうふうにマネジメントするかみたいな話を中心にお届けしたいと思っているんですよね。ふだんあんまりそういう話はしないんですけど。

その僕がやっているAzure Functionsっていうサーバーレスのサービスが、どういう性質のプロジェクトというかチームであるかを紹介したいと思います。やっぱりプロジェクトによっていろいろ違うので、そういうことの前提をシェアしておきたいかなと思います。

こういうアイコンがあって、まずはMicrosoft。今どうなんやろうな、たぶん一位ですよね。一位の企業です。わかんないですけど、たぶん一位、少なくとも（過去には）一位やった企業です。

あとはサーバーレスのプラットフォームを提供しています。プラットフォームなんで、いろいろな世界中の企業さんがこれを使って、その上に開発をするものをクラウドで提供しています。

世界中の企業や政府が、そういうプログラムを開発したり運用したりとかする基盤、プラットフォームを提供しているんで、規模がクッソでかいわけですわ。世界中にサービスを展開しているし、クラウドを全部作っているんで、めっちゃめちゃでかいですね。

連携もすっごく多くて複雑で、実際めっちゃミッションクリティカルです。なんでかって言うと、僕らのサービスがコケたら、僕らを使ってくれているところが、みんな世界中で障害になるんですよ。だからスーパーめっちゃミスれない感じなんですよね。

あとは世界中でデータセンターを提供していたりとか、そういうふうな環境やねんけど、言うたらAWSさんやGCPさんがいるので、競合と激しいサービスのイノベーション競争はあるみたいな、こういう状況のソフトウェアを作っています。

Microsoft の開発プロセスとルール

最初にシェアしたいというか、僕が最初に来た時にびっくりしたことですけど、どんな標準プロセスやルールを作っているのかなと思ったけど、実は来てみたらぜんぜんないんですよ。標準のプロセスとか決まった「こういうやり方でやろう」とかがないんですよね。もう各チームが勝手に決めますみたいな、そういうノリですよ。

だから、チームにも標準プロセスみたいなのがないし、標準ルールみたいなのもないんですよね。だからみんなチームが考えてチームがやるみたいな感じになっています。

じゃあ、日本でよく使っているウォーターフォールの使用率はどれぐらいですかとか、僕はよく聞かれたんですけど、ぶっちゃけゼロパーセントですね。誰も使っていないですね。やっぱりウォーターフォールはさすがに、2024年になると今のテクノロジーにあんまり合っていない気がするので、やっぱりそろそろやめておいたほうがいいと思いますね。2024年の開発スタイルで、もっと楽なことをしたらいいんじゃないかなと思います。

（スライドを示して）というわけで、今話したようなことは、2024年の開発ってどんなんやねんって言うとこういうふうなことで、どう思う？　っていう自分なりの意見があったんで、それをブログに書いてみました。もし興味があれば読んでください。

（次回へつづく）