現在私は、世界規模のクラウドの中の人になって一か月が経過しました。グローバルで、クラウドプラットフォーム自体を作って運用する側はどんなスタイルで開発されているのか興味がある人もあるかもしれないと思ってブログを書くことにしました。これは自分のチームや周りのチームを観察しただけであって、私の所属会社全体がそういうスタイルではないかもしれませんが、何らかの参考になるかもと思い書いてみました。

スモールチーム

世界規模のグローバルなシステムなので、ものすごい大人数で、ものすごく厳密に開発されているイメージがあるかもしれませんが、実際のところ小さなチームの集まりです。自分がアジャイルコーチだったころに学んだことですが、開発は２５人ぐらいのチームがマックスで、Amazon でも two pizza team といわれているように、ソフトウェア開発は少人数でないとまわらないのでそうなっているようです。沢山チームがありますが、チーム自体は小さいので意思決定のスピードはかなり速い感じです。既存で沢山のお客さんが使っているので慎重なところは慎重ですが、上の指示というよりエンジニアがそうしています。

個人事業主スタイル

自分たちを助けてくれるマネージャがいて、「今期はこんなことをやろう」とリードしてくれますが、具体的なことは各個人が決めます。お題に上がっているネタで自分がやりたければそれをピックアップします。誰かが指導してくれるということはありませんので、自分ですべて考えますが、自分がどうしたらいいかわからないときや、困ったときは、同僚やそのマネージャに相談すると、間違いなく助けてくれます。製品が出来てきたら、周囲の人に「デモ」をします。

「デモ」があると多くの人が認知してくれますし、プロダクトオーナーが気に入ったら、担いでくれるかもしれません。私はちなみに、初めてのデモは、リモートで画面共有してやったら全く動かず大失敗したいのですが、「デモ」を通じて「自分でプロモートするものだ」ということを学びました。失敗しても、日本ほど心象は悪くなりませんが、「成功」しないと多分誰もつかってくれないので、「デモ」がうまくいくための投資を自分にしているところです。親切な仲間が助けてくれる個人事業主の集まりのようなスタイルです。他の人や、他のチームとコミュニケーションや同期や確認をとる必要があるときは、エンジニア自らが連絡してコミュニケーションをとります。それを本人が気づいていない時は、日々のデイリースタンドアップで、マネージャがさり気に教えてくれたりしてフォローしてくれます。

アーキテクチャのレクチャ

中の人向けに、クラウドの中身の各パーツのアーキテクチャのレッスンが頻繁に行われていて、外からは知りえなかった内部アーキテクチャを学べて超楽しいです。

オンコール

プロダクトのエンジニアはオンコールと呼ばれる、お客さんから上がってきた障害報告のみに対応する週間があります。ローテーションで回ってきます。ものすごく自動化されていて、本当に凄いなと思いますが、内部の話なので、残念ながら公開はできません。ただ、開発者自ら、実際に運用と、障害の対応をすることによって、現場ではどんな問題が起きているか？を感じることができます。自分が書いたコードがもしバグったりしたり、障害の調査が難しかったら、きっと大いにフィードバックを受けて、二度とそういうことをしなくなるでしょう。そうやってセンスが磨かれるので、大変いい経験だと思っています。

自分が担当していない部分のアーキテクチャを学べたり、知らないことの調査の過程で教えてもらえるので、かなり理解も深まって一石二鳥で楽しいです！ちなみに、ガチでヤバイ障害が発生したときは、サティアの声で電話がかかってくるという伝説を聞きましたが、体験していないのでわかりませんw

日本で体験した開発の職場との違い

SIerで開発しているときは、たとえアジャイルであったとしても、もっと「チームで動く」とか、「トップダウン」の色合いが強くて、「各エンジニアが各自で判断する」とか「自分の機能は、自分がその機能の個人事業主になってなんでもやる」いう雰囲気はあまりなかったと思います。自分が一緒に仕事をした「永和システムマネジメント」のアジャイルチームはそんな感じでした。クラウドの中の人とかにかかわらず、アメリカとかだとそういう感じが多いのでしょうか。

そんなので回るの？

多分、そんなスタイルって優秀な人でないと無理なのでは？と思うかもしれませんし、私もそう思っていたかもしれませんが、前の職場、そして新しい職場で完全に考えがかわりました。こっちのほうが断然いいです。明らかにスキルも付きますし、自分の実力以上のことは仲間が助けてくれます。しかし、自分がリードします。それはたとえ自分が新人だったり、インターンであってそれは一緒です。 で、見ているとやれば出来るんですね。なぜかというと、自分にそこのセンスや、能力が仮になくても、周囲が助けてくれるからです。日本だと、新人だと、「できないもの」として扱う場合がほとんどですが、「できるもの」として扱うと、みんなちゃんとできるんですね。日本だと新人にはエクセルのスクショとか、簡単な仕事しかふられない場合が多いですが、「できるもの」＋周囲の助けで、本人も成長し、周りも自立した人が出来るので嬉しいことだらけです。だから、みんな堂々自信をもった顔をしていますし、新人も、年取った人も全く同じ同僚という扱いです。自分の周囲が親切に助けてくれることは、本当に生産性が上がるポイントだと思います。

失敗に対する反応の違い

この職場では失敗にとても寛容です。私はデモで大失敗して、まったく動かず、パワポと口頭と事前に撮ったビデオ（ただし、説明したいことと違う）を使ってやりましたが、自分的には１００点中５点ぐらいです。最初のデモをきっかけにわかりやすく説明するつもりだったので、最初のがこけたら何も説明できません。もちろん後でビデオをとったり、Getting Started を作ってシェアしたりしました。しかし、一番重要なはずの「Demo or Die」の世界で失敗するのは致命的です。自分の評価は下がっているとは思いますが、それでも「マネージャは気にしなくてもいいよ、自分たちは新しいことをやってるのだからこういうことは起こるんだよ」って言ってくれたりします。 自分がパイプラインで自動化してデプロイしているイメージがあって、それが数日後のBuildという最大のイベントでも大きく取り上げられているやつなのに、イメージが壊れていると連絡が入って、びっくりして、速攻でロールバックしたこともあります。悪いことほど速攻で連絡する癖があるので、マネージャに報告しましたが。「よくあることだよ。この前なんて、、、」みたいな話をしてくれました。これぐらいのかなりの失敗でも、こちらではかなり寛容なようです。それよりも、自分が失敗して、「I'm awfully sorry about that」とか言ってると、そんな反省しているみたいな空気がみんな苦手らしく、「問題ないよ」「助かったよ」とかポジティブな態度でいてほしいみたいです。失敗しても、ポジティブでいるほうが彼らには心地が良いようです。

自分はチャレンジしていなかった

このチームに来てから、先ほどの書いたとおり、死ぬほど失敗しています。かつてやったどの職場より失敗していると思います。さっきのデプロイにしても、デプロイしないと失敗しないわけです。でも、大きなイベントが控えているのに、デプロイをして失敗して、絶対やらかさないぞと思うから、いろいろ自動化して工夫をしたり、次失敗しないように必死でパラメータを調査したりします。自分もこのチームに来た時は正直通用するか不安でした。 日本にいるときは、なんだかんだいって、「成功」ばかりしてた気がしますが、これって自分の実力以上にチャレンジしていなかっただけやなと思い知りました。「失敗」って結局自分の能力を上回ることをするからするのであって、その領域のことをすることは恐怖感があるのですが、それをやることで、自分の実力も少しづつ向上していく気がします。ただ、誰が失敗しても、それに寛容であるというチームであることが重要であると感じました。私はまだまだ失敗を恐れている傾向にあるのでもっと勇気を持ってみます。

おわりに

クラウドの中の世界は、思ったよりずっと「人」任せの世界でした。アジャイルマニフェストでも「プロセスやツールよりも、個人とその相互作用」という価値がありますが、この意味はたぶんこういう世界のことを指すのかと思いました。この記事が何か少しでも参考になれば嬉しく思います。Amazon さんはきっと「ゆう」さんとかがシェアしてくれるかな？