Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。アメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。Engineerマイクロソフト本社で働くエンジニア河野通宗氏(以下、河野):Microsoftの河野と申します。ふだんはシアトルでAzureサービスを作っているんですけど、今回は川口さんにご縁があってお呼びいただきまして、このような場でお話しする機会をいただき、大変感謝しております。本当はもうちょっと地味なタイトルだったんですけど、キャッチーにしてほしいということで、「敢えて属人化せよ」というタイトルをつけてみました。Phoneというものを使っておりまして。残念ながらアプリがなかったのですが、内容はたぶんWebでも見られると思います。内容をご覧になっている方もいらっしゃると思います。今日の内容については、まず、日本のWindows開発チームからアメリカのAzure開発チームに移ったときの話をします。Microsoftに入ったのが12年ぐらい前で、日本のマイクロソフトでWindowsを作っていました。Windows7を出した後ぐらいの、2010年に、アメリカに行こうかなということになりました。そのとき、まだクラウド、Azureはすごくちっちゃなチームで、正直クラウドやってたら5年ぐらい食えるかなと思っていたんですけど、もうすでに8年経っちゃいました。毎日毎日楽しくコードを書いております。その8年間ですごくいろんなことを経験したので、そのあたりを中心にお話したいと思います。私、普通の日本人で、日本で暮らしてきて、日本語で仕事してきた人間なので、そこからアメリカに移って、しかもクラウドの開発ということで、いろいろとカルチャーショックを受けました。その後、IISっていうWindowsのWebサーバーのサービスのチームと合流したときにいろいろなことが起きました。そのあたりについても細かくお話します。Serviceという名前でサービスをやってるんですが、その開発プロセス自体も7年間で常に変化してきたので、その流れについてもご紹介しようと思います。最後に、エンジニアとして働く中で、アメリカで働いたり、エンジニアを続けるうえで大事だなと個人的に感じたことをご紹介したいと思います。私の体験なので、それが良いとか悪いとかは、とくにないです。私はコードを書くことが楽しくてたまらない人間なので、あえてご紹介することで、何かみなさんのお役に立てば、あるいは考えるきっかけになれば幸せです。Serviceについて本題に入る前に、うちのサービスを紹介していいらしいので、少しだけ紹介させていただきます。ServiceはAzureの中でもPaaSと呼ばれるクラウドの種類に分類されるサービスです。WebAppsという、20秒くらいで簡単にWebアプリを作れるというところからスタートしました。Serviceの上で動いております。これ、WindowsだけじゃなくてLinuxもサポートしておりまして、(私は)両方やっています。めっちゃくちゃおもしろいです。本当おもしろいんです。(会場挙手)挙げづらいですよね(笑)。そんなにいらっしゃらないようで、ちょっとうれしいです。サービスが今けっこう成長してまして、スライドには1日でHTTPのリクエストが20Bって書いてありますが、1日で200億リクエストぐらいさばくようになりました。1ヶ月だと7000億リクエストぐらい。今、VMの数が45万ぐらい。先日のインテルのチップの脆弱性騒ぎのときにOSを全部入れ替えたんですが、だいたい1週間ぐらいでなんとかできました。いう、OSを入れ替えたりといったことも全部裏側でやります。ユーザーのアプリは当然走っているし、クラウドなのでメンテナンスで止めることができません。そんな中でどうやってOSをちゃんと入れ替えるのか、さらに問題を起こさずにどうやってやるかは日々チャレンジで、正解はないです。未開の地を歩いている世界は不安なんですけど、その不安定な状態がものすごく楽しいです。最初は正直怖かったんですけど、スイッチが切り替わるともうやめられない。いうことで日々楽しくやっております。河野氏が手がけたサービスちょっとだけ、私自身が作ったものについてもご紹介させてください。ほとんど内部のものなのでここで言う意味はないんですけど、一応、本当にコードを書いてる人間だという証明で。WebSitesというWebアプリからスタートしました。今はWebServicesということになってますが、もともとWebSitesというサービスだったんです。そのチームができたとき、オートメーションのフレームワークがなかったんですね。フレームワークを全部作って、動かしました。実行結果をメールで送ったりとか、そういうものも作ってます。2点目はクラウドサービスだったので、モニタリングが命綱でした。作ったらおしまいではなくて、テレメトリー情報は常に変化する必要があります。変化するということはつまり、問題を見つけた、あるいは新たにテレメトリーのモニタリングポイントをつけたら、できるだけ早くデプロイしなければいけないということです。いうところをオートメーション、というか自動化する必要があったので、そのためのワークフローを作りました。3点目は個人的にすごくおもしろかったです。Websitesって書いてますが、AWS(注:Netflix)のChaosMonkeyって聞いたことがあると思うんですけど、プロダクションにわざとリブートかけたり壊したりして、そういうときにもフォールトトレランシーをちゃんと確保するためのフレームワークを作りました。Monkeyは外向けにもなっているんですが、我々は内部でAppServcie向けに作っていきまして、私が作りました。Monkeyはまだぜんぜん有名じゃなかったので、僕らも中で全部作ったんですが、AppServcie向けということで、例えばOSをクラッシュしたり、わざとBSoD(注:ブルースクリーン)起こしたり、ストレージのコネクション切ったり、データベースの負荷を上げてレスポンスを遅くしたりしてもSLAの確保をちゃんとできているかどうかを全部モニタリングする仕組みを作りました。これはすごくおもしろかったです。最近Windowsを2016に移行したり、OSを入れ替えたりするときに、このフレームワークがすごく役に立ちました。コードとして残しておくことは意味があると思います。Advisorとあるのは、ここしばらくで作ったものなんですけど、テレメトリーをモニタリングしてこのサイトで特定のクラッシュが頻繁に起きていたり、あるいはCPUが高くなっているような状態を検出して、メールで連絡したり、ポップアップを出したりするための裏側ですね。他にもAPIを作ったり、Linuxの対応とか、いろんなことをやってます。オープンオフィスと個室はどちらが良いか?メインテーマとしては、こういうものをやるための仕組みやプロセスに対して何が大事かをお話ししたいと思います。(スライドを指して)これが我々の環境、でした。過去形の理由は後でお話しします。この写真みたいな感じでやっていました。最初は個室だったんですが、4、5年前、もっとコラボレーションしやすくしようということで、こういうオープンスペースに移りました。私はこの窓際の端っこのほうに座っていたんですが、いわゆる現代的なコラボレーションしやすい環境になりました。最初の1ヶ月くらいは、正直みんな、個室から移りたくないと嫌がりました。移った後も、うるさいとか集中できないとかいろいろ不満はあったんですけど、しばらくすると、けっこうコミュニケーション取りやすくて、いいよね、と。わからないことがあったら、後ろを向けば質問できる。Slackやメールもありますけど、やっぱり直接の、レイテンシーのないコミュニケーションはとても大事だということは、みなさんよくご存知だと思います。実は、去年の10月からまた個室に戻りました。今のマイクロソフトのシアトルのキャンパスを大きく作り変えるプロジェクトが走りはじめまして、それで我々が移動しなくてはいけなくなったので、郊外に移ったんです。臨時の場所として、個室に移ったんですね。私はモニター5台を並べて使っています。これはこれでいいんですよね。モニターを広く置けるし、集中できるし、自分の電話をこの場で取れたり、いろんなものを置けたりする。同僚の1人だと最近はジグソーパズルをやってですね、横から見るとパズルやってるんですけどそれは別にぜんぜん構わなくて、先週見たら別の同僚も一緒になってパズルをやっていて。コラボレーションが起きているなと(笑)。喜ばしいことだと思います。オープンスペースと、こうしたフォーカスルーム、つまり個室みたいな集中力を維持できる環境、それぞれいいところと悪いところがあって、どちらがいいということはないと思います。人によっては絶対個室じゃなきゃ嫌だという人もいますし、オープンスペースのほうがコラボレーションしやすいしいいよねという人もいます。一言でいうと、銀の弾丸はないんだな、と。いうところはマネジメントの人たちとかが、常にチームの雰囲気を見ながら、うまく調整していく必要がある気がしています。クラウドを運用し続けるということところで、さっきも言いましたが、作ることって楽しいと思うんです。開発楽しいっていう人いらっしゃいます?(会場挙手)よかった、いらっしゃった。私、とくに今、すごい楽しいんです。その理由をいくつか挙げてみました。我々ソフトウェアエンジニアが、設計、実装、あとはクラウドだったらデプロイから運用まで全部、最初から考えてコードを書きます。運用も責任の一部なので、テレメトリを見て例外が起きていたら、当然自分が直す。いうテレメトリを埋め込めばいいか決めるのも自分の責任です。リリースしておしまい、そういうものじゃないんです。ここまでやらないとやっぱり、サービスを止めずに動かすシステムってできないって思うんです。クラウドって、いろんなサービスの大きな集合体なので、自分のところを(ダウンさせずに)動かし続けるしかないんです。ほかのサービスが一時的にダウンしても、当たり前に動かします。ネットワークが切れたり、毎日どこかが壊れるんです。いう中でも毎日動かしつづけるためには、テレメトリの運用、あとは、そういうのをあらかじめ全部考えた上での運用方法の確立というのは、絶対に必要です。ある時点でなにかがちゃんと動いていても、次の週にはもう前提が変わっているんです。完璧というのは世の中に存在しない。やってシステムを動かし続けるかには、答えはないんですけど、その中でやり続けることが、すごく楽しい。ご理解していただけると思います。いう中で安心してどんどん新しいことを試したり、テレメトリーを新しくデプロイするためには、やっぱり背骨がしっかりしてないと駄目で、その大きな1つとして、CIがちゃんと回っている、チェックインのモニタリングがちゃんと回っていることが絶対に必要だと思います。広くいうと環境なんですけど、システム的な環境も含めて、自分の外側にあるものがとても大事だと思います。これは反論する人あまりいないと思いますが。チームの本当にすごい人たちに、わからないことがあったらコンコンって行って議論したり、ここ教えてって言ったり、あるいは自分のアイデアを聞いてもらったり、そういうときにいつでもホワイトボードを使って議論できるということには、やっぱり得難いものがある。リモートじゃなかなかしきれない部分があるんですね。リモートは当然するものなんですけど、それでも直接の会話というものは何物にも代えがたいものがあるなと思います。働く環境としてのMicrosoftもう1つ、私は言ってみれば雑魚エンジニアなんですけど、だからこそ良いマネージャーとかディレクターがものすごく大事だと思います。みなさん良いマネージャーとか良いエンジニアだと思うのですごく同意していただけると思いますが、良いマネージャーって、探すのが難しいですよね。彼らは働きやすさにものすごくダイレクトに関わってくるので、良いマネージャーの下にいられることは、ある意味幸運かなと思います。良いマネージャーを探して職を移ったりとか、チームを変えたりすることも、普通にありえます。子どもを朝送って、夜というか昼は奥さんが(子供を)ピックアップしてくれるんですけど、だいたい6時には会社を出て、家でちゃんとご飯を食べるという生活をずっと続けています。リモート会議ができるということは当然ですよね。子どもが風邪引いたとか、熱出したとか、そういうときは家で作業する。家のなにかが壊れたとき、修理の人を呼びますけど、アメリカの人って時間通りに来ないんです。10時に来るって言いながら12時ぐらいに来たりする。いうときは、家にいるよってメールを送って、それだけです。業者が来なかったって言って。その後はもう、家で続きの仕事します。理由を書く必要もないです。そんな感じで、柔軟に働ける環境です。休みの取得は、最近忙しいのでちょっと減っていて、去年の11月は2週間ぐらいしか取れなかったんですけど、だいたい1ヶ月ぐらいは取るのがみんな当たり前になっています。この間はインテルの騒ぎで正月休みが正直なくて、そこだけはつらかったな。あと、広い机と速いマシン。これは、すごく大事なことだと思います。家より良いマシンがないと、会社に来る意味ないですよね。(会場笑)私、Facebookは怖くてやってないんですが、Twitterで、よく会社でラップトップしか使ってなくてメモリが4GBしかないって話を見かけるんです。それだったら別に家で、自分のマシンで仕事すればいい。当たり前の結論だと思うんです。それはやっぱりおかしい。ここだったら俺、楽しい作業に集中してできるぜ、っていう場所は、やっぱり提供すべきだと強く思います。さっきお見せしたモニターを5枚つなげられる個室は、僕はけっこう楽しんで気に入って使っています。楽しく開発するために大切なこと似たような話ですが、楽しく作るための条件がいくつかあります。今、私はソフトウェアエンジニアというロールです。簡単に定義すると、ソースコードに対して読み書きの権限を会社から与えられているということです。これってものすごい権限なんです。嬉しいことなんですね。ソースコードって、要はいろんな人たちの知識の蓄積なんです。これに対して読んだり、自分がアクセスできて、なおかつそれに対してコントリビューション、チェックインすることができる。これはものすごく素晴らしいことだと思うんです。アウトソースするなんてもったいない。これこそが我々の知識の集約。それを読めるということがもう、僕にとってはたまらないです。いう権限を会社が与えてくれていることは、すごく大きな信頼感につながっています。会社がそれだけの権限を与えてくれてるということは、自分はそこで大きなパフォーマンスを出す、準備ができるというふうに思える、といいますか。これも楽しく作れる条件だと強く思います。頼れる仲間、すごい人たちがいることももちろんそうですが、柔軟な働き方、このあたりも同じです。これはもう絶対条件です。みなさんあまり言わないと思いますけど、絶対欲しいじゃないですか。いらないって人いますか?(会場笑)たぶん、数ヶ月はいいと思うんです。「やりがい」で乗り切れる。それで1年2年3年(経つと)、やっぱりお金は欲しいじゃないですか。別にゲスい話じゃなくて、会社という組織が、従業員の評価として与えるものとしては、給料は一番正しい方法だと思います。ここは間違いなく、正しく報酬を与えるべきだと思います。アウトプットができていれば、制限には意味がない今挙げた項目を逆にひっくり返すと、あきらかにいきなり楽しくなくなります。今挙げたことが1個でもあると、だんだんと「俺、ここにいてもいいのかな」って気になると思います。私は言ったようにコードを書いて楽しく生きてる人間なので、自分がアクセスできる範囲が広いほうがうれしいです。お前はここしかやるなって言われたら、嫌ですよね。任されてない、会社から信頼されてないって思っちゃう。あと、Webのアクセスが制限されている会社がけっこうあると聞いているんですがMicrosoftはそういうことは一切ありません。普通にTwitter見ながら仕事しています。いうところって、楽しく仕事するためにはとても大事だと思います。Webで動画を見ながらやろうが、同僚なんてネットでゲームしながらコード書いてますけど、アウトプットがちゃんとしていればぜんぜん構わないです。そこでの制限は何の意味もないと自分はそう思っています。あと、タスクを押し付けられる。これやってあれやってとか。これ、すごく悲しいことですよね。そこは、マネジメントの範疇になります。実はマネジメントだけじゃなくて、自分のほうの何をすべきかということにも関わってきます。そのへんは後でもうちょっと詳しくお話しします。会社とかマネージャーは、楽しく作れる条件というものを一生懸命提供すべきだと強く思っています。マネージャーや会社の仕事は、一言でいうと、部下が最大限のパフォーマンスを発揮できる環境を提供することなんじゃないかと思います。昨日のロシェルさんのサーバントリーダーシップ(のお話)、など、たぶんそういうことがかなりダイレクトに効いてくるんだと思います。アメリカに移って感じたカルチャーショック私は今でこそ楽しく作ってますけど、最初はいろいろありました。そのあたりの話をすればなんかいろいろヒントを得られるのではないかと思います。いうことでアメリカに移ったときのことを話します。2010年まではWindowsをウォーターフォールで作っていました。だいたいみなさんのご想像通りですけど、最初にドキュメントを書く。それも、デベロッパードキュメント、テストドキュメント、その前にプランニングドキュメントみたいな。それぞれでレビューしてサインオフして、OKだったらよしコーディング始めよう、という。それをマイルストーン1とかマイルストーン2とかいって、1つずつ「終わったね、よし」と。「次のマイルストーンを始めましょう」ということで、またドキュメントを書く。リリースは3年に1回ぐらいしかできませんでした。実質、コードを書いて開発していた期間は、実は1年に満たないじゃないかと。言ってみれば随分もったいないわけです。そのおかげで年末ほとんど仕事がなくて、毎日4時ぐらいに帰ってました。最近はWindowsも頻繁にリリースしているのでそんなことはなくなったようですが。その世界からアジャイルなアメリカのクラウドのチームに移ったときに、最初にマネージャーに言われたことをいまだに覚えてます。タスクを1つアサインされました。ドキュメント書きます」と言いました。したらそのマネージャーが「別にしてもいいけどいらないよ」と。「それよりコード書いて」。それは僕にとってはものすごく衝撃だったんです。何を言っているかわからなくて。その後、1週間かけてプランニングドキュメント書いて、マネージャーに見せたら「ふーん、わかった」って言われたんですけど、マネージャーからすると、1週間無駄にしてるんですね。クラウドだから、ドキュメントの有効期間は1ヶ月とか2ヶ月しかないんです。そのために1週間使うのは無駄でしかない。それよりは知識の履歴としてのコードのほうが、はるかに価値があるという考えなんです。それは今もはっきり覚えているくらいのカルチャーショックのひとつでした。他人の話していることがわからないという恐怖あと、アジャイルというかスクラムに初めて参加したんですけど、英語なので、はっきり言ってぜんぜんわからなかったです。それまで日本のマイクロソフトにいたので、当然、英語でのミーティングには慣れていたんですけど、やっぱり現地での4-5人とかすごい少人数での密なミーティングは大変でした。自分の言うことは言えたんですけど、それだけしかできない。他の人が言っていることはわからない。あと、聞き返されるのがものすごく怖い。自分が言うこと言ったらとりあえずなんとか終わってくれと。いう状態で最初はすごくつらかったです。あと、怖いのはランチです。みなさん、アメリカに出張とか行かれたときに経験あるんじゃないですか。チームのメンバーから「じゃあランチ行こう」って言われるけど、まわりが喋ってることがわからないから、怖い。