CLOSE

敢えて属人化せよ!エキスパートの集団こそが最強のチーム(全3記事)

米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1

2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ! エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。

マイクロソフト本社で働くエンジニア

河野通宗氏(以下、河野):Microsoftの河野と申します。ふだんはシアトルでAzureサービスを作っているんですけど、今回は川口さんにご縁があってお呼びいただきまして、このような場でお話しする機会をいただき、大変感謝しております。

本当はもうちょっと地味なタイトルだったんですけど、キャッチーにしてほしいということで、「敢えて属人化せよ」というタイトルをつけてみました。私、マイクロソフトの人間なので、最近ユーザーベースがちょっと下がって0パーセント台というWindows Phoneというものを使っておりまして。残念ながらアプリがなかったのですが、内容はたぶんWebでも見られると思います。ざっと内容をご覧になっている方もいらっしゃると思います。

今日の内容については、まず、日本のWindows開発チームからアメリカのAzure開発チームに移ったときの話をします。

Microsoftに入ったのが12年ぐらい前で、日本のマイクロソフトでWindowsを作っていました。Windows7を出した後ぐらいの、2010年に、アメリカに行こうかなということになりました。

そのとき、まだクラウド、Azureはすごくちっちゃなチームで、正直クラウドやってたら5年ぐらい食えるかなと思っていたんですけど、もうすでに8年経っちゃいました。毎日毎日楽しくコードを書いております。その8年間ですごくいろんなことを経験したので、そのあたりを中心にお話したいと思います。

私、普通の日本人で、日本で暮らしてきて、日本語で仕事してきた人間なので、そこからアメリカに移って、しかもクラウドの開発ということで、いろいろとカルチャーショックを受けました。さらにその後、IISっていうWindowsのWebサーバーのサービスのチームと合流したときにいろいろなことが起きました。そのあたりについても細かくお話します。

現行、App Serviceという名前でサービスをやってるんですが、その開発プロセス自体も7年間で常に変化してきたので、その流れについてもご紹介しようと思います。

最後に、エンジニアとして働く中で、アメリカで働いたり、エンジニアを続けるうえで大事だなと個人的に感じたことをご紹介したいと思います。あくまで私の体験なので、それが良いとか悪いとかは、とくにないです。私はコードを書くことが楽しくてたまらない人間なので、あえてご紹介することで、何かみなさんのお役に立てば、あるいは考えるきっかけになれば幸せです。

Azure App Serviceについて

本題に入る前に、うちのサービスを紹介していいらしいので、少しだけ紹介させていただきます。App ServiceはAzureの中でもPaaSと呼ばれるクラウドの種類に分類されるサービスです。WebAppsという、20秒くらいで簡単にWebアプリを作れるというところからスタートしました。

それが2011年から2012年ぐらいで、その後サービスがいろいろ増えて、最近流行ってたサーバーレスというテクノロジーに分類されるAzure FunctionsというものもApp Serviceの上で動いております。これ、WindowsだけじゃなくてLinuxもサポートしておりまして、(私は)両方やっています。めっちゃくちゃおもしろいです。もうたまんないです。本当おもしろいんです。

ちょっとお聞きしたいんですけど、みなさん、お使いの環境で、ふだん開発エディタよりExcelのほうが上がっている時間が長い方ってどれぐらいいますか? 

(会場挙手)

挙げづらいですよね(笑)。でもそんなにいらっしゃらないようで、ちょっとうれしいです。サービスが今けっこう成長してまして、スライドには1日でHTTPのリクエストが20Bって書いてありますが、1日で200億リクエストぐらいさばくようになりました。1ヶ月だと7000億リクエストぐらい。今、VMの数が45万ぐらい。先日のインテルのチップの脆弱性騒ぎのときにOSを全部入れ替えたんですが、だいたい1週間ぐらいでなんとかできました。

そういう、OSを入れ替えたりといったことも全部裏側でやります。ユーザーのアプリは当然走っているし、クラウドなのでメンテナンスで止めることができません。そんな中でどうやってOSをちゃんと入れ替えるのか、さらに問題を起こさずにどうやってやるかは日々チャレンジで、正解はないです。

未開の地を歩いている世界は不安なんですけど、その不安定な状態がものすごく楽しいです。最初は正直怖かったんですけど、スイッチが切り替わるともうやめられない。たまらないです。ということで日々楽しくやっております。

河野氏が手がけたサービス

ちょっとだけ、私自身が作ったものについてもご紹介させてください。ほとんど内部のものなのでここで言う意味はないんですけど、一応、本当にコードを書いてる人間だという証明で。

最初、私たち(のチーム)はAzure WebSitesというWebアプリからスタートしました。今はWebServicesということになってますが、もともとWebSitesというサービスだったんです。そのチームができたとき、オートメーションのフレームワークがなかったんですね。なので、フレームワークを全部作って、動かしました。当然、実行結果をメールで送ったりとか、そういうものも作ってます。

2点目はクラウドサービスだったので、モニタリングが命綱でした。当然、作ったらおしまいではなくて、テレメトリー情報は常に変化する必要があります。変化するということはつまり、問題を見つけた、あるいは新たにテレメトリーのモニタリングポイントをつけたら、できるだけ早くデプロイしなければいけないということです。そういうところをオートメーション、というか自動化する必要があったので、そのためのワークフローを作りました。

3点目は個人的にすごくおもしろかったです。スライドにはHigh availability testing framework for Azure Websitesって書いてますが、AWS(注:Netflix)のChaosMonkeyって聞いたことがあると思うんですけど、プロダクションにわざとリブートかけたり壊したりして、そういうときにもフォールトトレランシーをちゃんと確保するためのフレームワークを作りました。

Chaos Monkeyは外向けにもなっているんですが、我々は内部でAppServcie向けに作っていきまして、私が作りました。そのときChaos Monkeyはまだぜんぜん有名じゃなかったので、僕らも中で全部作ったんですが、AppServcie向けということで、例えばOSをクラッシュしたり、わざとBSoD(注:ブルースクリーン)起こしたり、ストレージのコネクション切ったり、データベースの負荷を上げてレスポンスを遅くしたりしてもSLAの確保をちゃんとできているかどうかを全部モニタリングする仕組みを作りました。

これはすごくおもしろかったです。最近Windowsを2016に移行したり、OSを入れ替えたりするときに、このフレームワークがすごく役に立ちました。やっぱりコードとして残しておくことは意味があると思います。

あと、スライドにBackend for App Service 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人とかすごい少人数での密なミーティングは大変でした。

自分の言うことは言えたんですけど、それだけしかできない。他の人が言っていることはわからない。あと、聞き返されるのがものすごく怖い。自分が言うこと言ったらとりあえずなんとか終わってくれと。そういう状態で最初はすごくつらかったです。

あと、怖いのはランチです。みなさん、アメリカに出張とか行かれたときに経験あるんじゃないですか。チームのメンバーから「じゃあランチ行こう」って言われるけど、まわりが喋ってることがわからないから、怖い。行きたくないなぁと。黙って座ってる。そうすると、1人でご飯を食べる方が気楽になるんです。だいたい半年間ぐらいかな、ずっとぼっち飯で、そのほうがいいやという感じでした。

怖くなくなってきたのは1年半ぐらい経ってからかもしれません。半年ぐらい経ってくると少し慣れてきて、喋れるようになってきたんですが、完全に恐怖感が抜けるには1年半ぐらいかかりました。スクラムで他の人が言っていることに対して質問したり、コントリビューションしたりするには、実質2年3年くらいかかったような気がします。

そういうとき痛感するのは、もっと若いうちに行きたかったなということですね。若い人で、アメリカで働きたいという変わった考えをお持ちの方は、ぜひ若いうちにトライしてもらえればなぁ、とすごく思います。大変でしたけど、すごく実になりました。本当に自分の中で代えがたい財産になったと思います。

「アジャイル開発はバックログと共に生きることと見つけたり」

一言だけいうと「アジャイル開発はバックログと共に生きることと見つけたり」。

(会場笑)

別にとくに意味はないです。深い意味も何もないです。でも、ウォーターフォールとの違いは、ここに集約されているような気がするんですよね。

バグとかを全部ゼロにして、ワークアイテムのリストを空っぽにして、これでおしまいって言ってリリースするものがRTM(Release to Marketing)です。でもアジャイルの世界って、基本的に「終わり」ってないんですよね。

SLAを確保して、これで一般提供 (GA) ですよって出しますけど、基本的にそのときまだまだワークアイテムのリストって山のように溜まっていて、バグも当然あります。その後も開発は続くんです。フィーチャーをどんどん足したりします。そのとき自分のカンバンを見ると、山のようにワークアイテムがある。毎日その状態。最初の頃、辛かったです。これ終わってないじゃんって心境、わかってもらえるかなぁ。

常にバックログがあることが、逆にいいと思えるようになるまでには、だいぶ時間がかかりました。つまり、常にやることがあるんです。これだけ自分が改善できるんだっていう。改善のためのリスト項目がここにあるんです。そこに自分もいつでも足せます。

ご存知のように、今のコンピューターの世界ってすごいものがありまして、改善を止めた時点でおしまいなんですよね。完璧って思った瞬間に、外からの変化に対して抵抗的になります。アドバイスを受けつけなくなったり、わりとネガティブな、自分を守る方向になったりします。

けど、バックログが常にある状態は、そこまでを含めて自分の世界ということで、常に変わっていけるためのものがここにあるんだ、というふうにマインドが変わってから楽しくなったのを覚えています。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 1年足らずでエンジニアの生産性が10%改善した、AIツールの全社導入 27年間右肩上がりのサイバーエージェントが成長し続ける秘訣

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!