マネージャーの高い技術力

牛尾剛氏:そういうふうな環境でマネージャーの技術力はどうやねんって話ですね。これもものすごく違っていて、僕の上のマネージャーはプラグナーっていうんですけど、この人はAzure FunctionsのJavaのランタイムを1から書いた人なんですよ。

その上のパートナーもAzure Automationの開発でどんな技術の話題でもめっちゃ深く理解して、すごいアイデアを出したりする人で、その上のフェローはアレですね。Azure AppServiceという、Azureのクラウドのフラッグシップのサービスを1から書いた人ですね。

つまり何が言いたいかっていうと、僕の上のマネージャーはすべて僕よりプログラムが明らかにできるんです。じゃあお前らがやったほうが絶対早いやろってぶっちゃけ思いますよ。そもそも、説得とか要らないですよ。

僕は日本にいる時に、例えば何か新しい技術をやろうとしたり、アジャイルを導入しようとしたら、「牛尾よ、まず俺のことを説得してみろ。俺にわかるように説明してみろ」みたいなことを、僕はすごくよく言われました。

だから僕も、「どうやって説明したらわかってもらえるかな」とかすんごく考えてやりましたよ。もう政治的にもいろいろなことをやったけど、こっちだったらそもそも上の人がみんな技術を知っているんで、説明せんでも「ああ、あれはこうです」みたいにわかってくれるんですよね。

それどころか、僕が発表しているじゃないですか。そしたらスループットとかのグラフの傾きとかを見て、「ああでもここの傾きがこうなっているということは、君はこういうふうの改善したほうがいいんじゃないか」みたいな、すっごくいいアドバイスが来たりするんですよ(笑)。いや、ほんますごいと思います。

だから、実際に開発をする時に本当にこういうのって組織としてめっちゃめちゃ楽ですね。開発に集中できます。だから実際に開発で技術が高いことがちゃんと評価されるし、本当に政治が要らないし、経営を勉強しろとか言われへんし、もう本当にここはすばらしいなと僕は思いますね。

納期の概念の違い

あとはけっこう自分的におもしろいところは、納期が基本的にはないっていうことです。これはカルチャー的なのがけっこう多いかなと思いますけど。日本にいる時は、今から振り返って考えると、僕はけっこうなんでも納期があった気がするんです。

例えば、本当は納期はどうでもええようなしょうもないやつでも、「牛尾さん、これを来週の月曜日までにお願いします」みたいな感じで言われていますよね。どんなものでもすべて納期があるみたいなノリだったと思うんですけど、アメリカに来てこういう仕事をしていても、納期はほぼほぼなくて、できた時が終了なんですよ。

納期がまったくないかっていうと、そんなことはないですよ。例えば、オリンピックのアプリを作るんだったらあるかもしれないですし、僕の場合だと、BuildっていうMicrosoftで1年に1回行われるカンファレンスがあって、そこのキーノートでドカンと発表されるようなシステムに関わっていると納期はあります。

だから、そういう時は納期はあるけど、そうでなかったら基本的に納期ってないし、納期に相当する英語すらないんじゃないかなと思います。だってこっちでdue dateとかdead lineとか言っていても、できへんかったら普通に延ばすしみたいなノリです。日本のように、納期を守られへんのは社会人じゃないみたいな、死んでも守るものっていうノリがぜんぜんないです。

それの体感的な効果としては、やはりこっちのほうがぜんぜん気分が楽です。当たり前やけど。当たり前やけど、僕らを信じてもらっているんですよ。そんなこと言わんでも君らはみんなプロフェッショナルやからさ、自分らのベストでやるやろ? って。

実際にみんなもそうですよね。誰も自らサボるようなやつはおれへんし。自分で考えるベストでそれぞれの人間がやるんやから、彼らをtrustするっていう姿勢ですよね。だからできた時が終わりでも、けっこう生産性よく仕事ができているんじゃないですかね。

何よりも、やはりソフトウェアと納期はあんまり向いていない(相性が良くない)気がしています。なんでかっていうと、ソフトウェアってすごく予見しにくいし、それを無理やり完成させて無理やりリリースしたら、結局品質が落ちるだけなんですよね。

そうしたら、誰も使ってくれないのではないですか。そっちのほうが大ダメージですよね。でも大抵のことって、1週間延ばしたからってすごい問題が起こることってそんなにないんじゃないですかね。先ほど話したみたいなオリンピックとかやったら別やけどね。だからそういうふうなところはちょっとおもしろい学びでしたね。

新人エンジニアの学習姿勢

あとぜんぜんノリが違う文化的なところでいうと。1つ例を挙げると、僕は三流エンジニアであほにゃんにゃんやけど、僕の周りにはめっちゃ優秀な人が多くて、すんげぇやつがいて、みんなスーパー賢いから、僕は大学出たての子とか新人くんみたいな人から学ぼうと。

でも、その大学を出たての子でも、うちのシステムはめちゃくちゃ複雑で、めっちゃいろいろなマイクロサービスが関連していて1個1個が複雑で、理解がすごく大変なのに、彼らは最初からガンガンにunderstandしてプルリクエスト送って変更してとかね、最初からガンガンにやっているんですよ。大学を出たてですよ。

だから彼らに聞いてみたんですよ。君らはなんでそんななの? 大学出たてであんな難しいことをすぐにやれるの? って聞いたんですよね。

僕らのチームは、小さなマイクロサービスでできていて、またマイクロサービス1個1個がクッソ複雑なんですよ。わかりにくいから、エンジニアがしゃべった1時間半ずつぐらいあるわかりにくいビデオがあって、それがマイクロサービスみたいになっていて。だから新しく来た人はそれを見てみたいなね、そういうノリになるわけです。

それは1個1時間半ぐらいなんです。(スライドを示して)そういうのがあるんですけど、僕はこのトニーっていう右側のやつに聞いたんですよ。「トニーさ、お前どうやってあんなのをすぐにできるの?」って言ったら、トニーが「そうっすよねー、あれめちゃくちゃ難しいっすよねー」って。「だから僕ね、あのビデオ1個1個あるじゃないですか。あれ1個につき10回ぐらい見ています」とか言って。

10回!? みたいな。僕はすごくびっくりしたんですよ。えーーっ!? みたいな。だって1時間半もあんねんで! 1時間半もある。僕だったらどうしていたかって言うと、あんなものは見てもどうせわかれへんと。だから1回見て、あとはもう行動にジャンプインして、たぶんやっていくうちにちょっとずつわかっていくんだろうなみたいな。どうせ僕はあんまり頭が良くないからわかりません! みたいに諦めていたんですよ。

そしたら横にいたクーパーも同じようなことを言いました。「そうっすよねぇ。あれはすごく難しいから、もう見ては巻き戻しして何回も巻き戻して見てますわ」みたいなこと言っていて。なんか、えーーっ!? って、僕にはそれはすごく衝撃的だったんです。

僕は何ていうの、賢い人ってあんなのはすぐに見てわかって賢いなぁ、賢くて羨ましいなぁって思っていたんですよ。でも実際はそうじゃなくて、賢い人って結局理解に時間をかけているだけなんですよね。だから、わかります? 賢い人でもunderstandすんのに、理解するのに時間がかかるんですよ。

だってトニーは10回見ているんやで。そう、だからあほにゃんにゃんの僕が1回見てわかるはずがないやん! そんな賢いやつですら10回見ているのに。だから、ああ理解に時間をかけるのってすごく重要なんだって思ったんですよね。

理解に時間をかけることの重要性

実はこれって、観察していると彼らだけじゃなくて、例えばミーティングをやっていても、みんなそういうノリなんですよ。僕が人生で会った中で一番賢いと思うポールってやつが僕の目の前に座っているんですけど。

例えば、会議をやっていて、僕だったらわからなくても、これは自分に関係ない話題やわってスルーしますよ。でもポールはそうじゃなくて、止めるんですよね。「ちょっとごめん、今のところがわからへんかった。もう1回説明してくれへん?」みたいな。それで他の人が説明してわかるまで聞くんですけど、わかるまで聞いたら「ああ、なるほど」って、1回understandしたら、その後にものすごいアイデアを出すんですよね。

もうすごく良いアイデアを出してくれたり。でも実は、それはポールだけじゃなくて、全員なんですよ。全員そういうノリなんです。僕のマネージャーのプラグナもそうです。彼女は理解でけへんかったタスクがあって、そのタスクをunderstandするためだけに僕と1時間のミーティングをしましたからね。僕やったらそんなんええ加減にしちゃうと思うんやけど。

周りのイケてる人って、誰もunderstandに手を抜かないんですよ。だから僕もそれに気づいてから、真似するようにしたんですよね。僕はあほにゃんにゃんやし、understandしないとよくないんだろうなと思って真似したら、いろんなことがわかりました。

僕みたいなあほにゃんにゃんでも時間をかけたらけっこうunderstandできるんですよ。焦らず自分のペースでやって。だから他の人がどれぐらいスピードがあるかとかそんなのは関係なくて、自分のスピードでやればunderstandできるんですよね。

そうすると、いっぺんunderstandするのは時間かかるんだけど、それをいったんunderstandしたら、もう他のことがスーパー早くなるというのがわかりました(笑)。だから、なんていうのかな。これはもう、understandするのに投資する価値があるんですよ。だから周りの人も誰も急かさないです。僕はこのチームに入ってから、何かを早くやってって言われたことはないですよ。

それどころか、僕が先ほどのプラグナーとかに「ごめん、俺は実装遅くてごめんなぁ」って言っていたら、「そんなことは気にしなくていい」と。「君のスピードで、君が納得するまでちゃんとした品質のものを出そう」っていつも言われますね。僕がむしろ早くしようとしてしまうみたいな。

やはりソフトウェアに関しては、それぐらいunderstandに時間をかけるとか、急がないことは本当に重要だと思っています。それによって実はそっちのほうが早くなるっていう感覚をすごく僕は感じています。だから理解には時間がかかるね。

アメリカの「速くない」と持続性

あともう1つ似たような例でいうと、米国は速くないっていうノリに、僕はこっちに来てから気がつきました。アメリカはいろいろなすごいサービスを発表するし、今までも作ってきたから、僕はさぞかしみんなすごく速いんだろうなと思っていました。だからすごい速く新しいものに実装できたりとか、速くunderstandしてなんかしているとか思っていたんですけど、むしろ逆でしたよね。日本のほうが速いです。

例えばChatGPTみたいなのが発表された時に、日本だったらその翌日ぐらいにみんな翻訳したりとかすごいブログを書いたりとか、「試してみました」「こんなん作ってみました」みたいなやつがもうあるじゃないですか。アメリカにはそんなノリはぜんぜんないですよ。みんな「ハァン、さよかー」みたいな感じなんですよ(笑)。

でも実はその後が違っています。日本の場合は発表されたらすごく盛り上がって、みんなが飛びついてPOCとかやるんやけど、実際その後はあんまりしないじゃないですか。

でもアメリカの場合はそんなにバァンとやる感じはぜんぜんないんですけど、着実にちょっとずつやるんですよね。ちょっとずつ。ほんまにやってみるんですよ。だからほんまにやって積み重ねていくから、しばらく、半年とか1年とか経ったら、あれ? なんかけっこうたくさんやっているな、みたいな。

だからみんな実際にやるというか、地道なことを積み重ねるというか。ほんとそれだけで、速い感覚はぜんぜんないんですよね。でも、結果としてはそっちのほうが速いみたいな、そういうノリがぜんぜん違うなぁと思いました。

(次回へつづく)