ウォーターフォール→アジャイル開発への移行
河野通宗氏（以下、河野）：私がアメリカに移って、Azureのチームに移ったとき、アジャイルだったことは今お話しした通りです。そのときはAzureのSDKのチームでした。
その後、半年ぐらいして、WebSitesというチームができることになりました。IISというWindowsについてるWebサーバーのチームと合流することになったんですが、そっちのチームはWindowsの一部分なのでウォーターフォールで作っていました。そことJOINして一緒にやることになった。
つまり、ウォーターフォールでやってたチームと、アジャイルでやってたチームががっちゃんこしたんです。それでサービスを出すぞということになった。ご想像の通り、いろんなことが起きました。
まず、アジャイルって何？ スプリントって何？ 1ヶ月しかないのに何をリリースするの？ ドキュメントはどうするの？ 自分が最初に経験したことをチーム全員が経験するんです。当然すごくいろんな問題が起きました。
そこでマネージャーが言ったのが、とにかくやってみようよと。最初だったので、1つのスプリントに確か6週間くらいかけて、すごく長めでやりました。そこからだんだん4週間ぐらいにしていった。
最初に1、2回、とにかくやってみるとわかるんです。口で説明されても正直わからないじゃないですか。何がいいのとか、そんなことして意味あるのとか、萎えさせる言葉の代表例ですけど。とにかくやってみれば、良いことと悪いことがわかってくる。
当然、それは完璧じゃないので、継続してどんどん改善する意思を常に持ち続ける。そういうところはマネジメントとかチーム全体の意識合わせがすごく大事なんですが、我々はアジャイルな開発をすでにやっていた側がある程度いたので、そこは少しラッキーでした。1人で始めるなんて私にはちょっとできないです。そういうところで、昨日お話しされた方々（注：セッションスピーカーの人達）とか、すごいなと思います。
今はスプリント70ぐらい。1スプリント4週間くらいでやっているんですけど、それ以外に、セキュリティのホットfixとか、バグが見つかってすぐにfixをロールアウトしなければいけないとか。そのときにはもうその場でデプロイする体制になっています。
我々はプロダクションでお客様のコードを走らせているので、あんまり速くやりすぎても、いややめてっていう声もけっこう来るんです。そういう中でうまーく、お客さんに気付かれないように下だけを入れ替える、というところがすごく楽しい。
開発プロセスの変遷
じゃあ、次にApp Serviceの開発プロセスの変遷について話します。簡単に言うと、Dev+Ops→NoOps→Dev+Supportという感じです。
実は、DevOpsはもうやってないんです。最初は、デベロッパーとオペレーションのチームがいて、協力してやりましょうというふうにしていました。リリースのときに、TFS (Team Foundation Server)にデプロイ作業を登録して、オぺレーションはこれですって、書いたんですけど、当然デプロイメントのチームに負荷が集中するんです。こっちは一瞬でも早くfixをデプロイして改善をしたいのに、そこがボトルネックになっていた。あるとき、そのチームが全部なくなっちゃいました。今は全部我々がデプロイしています。
我々がデプロイするといってもISOの規定があるので、デプロイメントのリクエストをオートメーションで投げると、それがApprovalのリクエストになって他の人に飛びます。自分自身はApproveできないんですが、他の人間がApproveすることでデプロイメントのプロセスが実行されるかたちです。
今、これでわりと幸せになりまして。我々が何かバグを見つけたり、アラートが上がったり、なにかexceptionを見つけたら、じゃあそれをできるだけ早くfixしましょう、というかたちができている。それがすごく大きな変化だと思っています。
今はそれだけではなくて、クラウドは使ってもらってナンボの世界なので、サポートもすごく大事です。我々、正直ドキュメントをずっと怠ってたので、去年ぐらいから力を入れてるんですけど、ドキュメントだけじゃ、やっぱり足りないんですよね。
できるだけいろんなお客さんの持っている問題を直接吸い上げて、それに対して解決をできるだけ迅速に提供する。これはカスタマーサティスファクションで一番大事な部分です。
我々Devのチームは100人ぐらいしかいないんですが、サポートのチームはワールドワイドにいっぱいいまして、その人たちがお客さんからのリクエストを迅速に吸い上げて、できるだけそこで解決する。そこでも解決できない問題を我々に対して送る。ということで、Devチームとサポートのチームは、今ものすごく緊密にやり取りしています。
カスタマーチームに学んだこと
去年、出張でダラスにあるサポートのチーム行ってきまして。3日間、実際にサポートチームの人たちがどういうカスタマーコールを受けているかを見るという研修を受けました。
すごく勉強になるんです。我々はそういうことがないと、ふだんお客さんがどういうふうに使っているのかとか、どういうトラブルが起きているかを知る機会がなかなかありません。
すごく勉強になりましたし、そこから「じゃあこういうツールを作ろう」とか「サポートチームはどういうツールが欲しいの？」と、そこでのリクエストを吸い上げて、開発にあたれる。エラーメッセージがわかりにくいという話がすごく多かったので、わかったということで、我々の中でTryCatchでドーンって囲っていたところを、もっと細かく書いて、エラーごとに細かく理由を返すようにしました。いろいろ改善ができました。
我々の世界はすでに売り切りのモデルではないので、サービスとして継続して使ってもらえることが大事になる。いかに早く価値をお客さんに提供できるかが、キーになります。価値っていろんな面がありまして、コードであるとか、カスタマーの質問に対してのレスポンスであるとか、そういうことをひっくるめたいろんな部分、全部含めて価値として定義しています。それらをできるだけ早く提供して、お客様に喜んでもらうことがすごくうれしい。
このあたりの話は、Microsoftってそういう会社だったっけ？ と言われる部分も正直なくはないんですけど、Azureになってからだいぶ変わったというふうに思います。
Microsoftが5段階評価をやめた理由
あとは、切っても切れない評価システムの話をします。4年ぐらい前まで、Microsoftでの評価システムは、5段階評価でした。1が一番良くて5がさよならというやつです。
マネージャーが集まるキャリブレーションミーティングというところで、全員を成績順に並べます。その順番は我々には伏せられてますが、最終的な5階評価だけ教えられて、それによってボーナスが決まってました。
あるときから、全部止めました。理由は明確で、評価があるとどうしてもチームメイト同士の競争になっちゃうんです。「あいつは1をもらった、俺はあれだけがんばったのになんで3なんだ？」というふうにどうしても思ってしまう。
5段階評価を一切やめたおかげで、ものすごく働きやすくなりました。安心感ですね。常に後ろから追っかけられているような恐怖感があったんですけど、それがなくなりました。
質問者1：5段階評価を通知するのをやめたということですか？
河野：はい、5段階評価もしてないです。
質問者1：ボーナスはどうやって決めるんですか？
河野：どうやって決めているかは、正直わかりません。
（会場笑）
ただし、評価基準はあります。インパクトという基準ですが、すごくぼやっとしてます。
チームが1年間どれだけ儲けることができたかに対して、どれだけインパクトを与えたかに基づいて評価します。ぼやっとしてます。正確な基準はないんです。マネージャーの力量がすごくかかってくるので、マネジメントが大事な部分です。
マネージャーは部下をどう評価するか？
じゃあ、マネージャーは部下をどう評価するか？ チェックインの数とかバグを開いた数とか、そういうところは一切見ないです。やってることは、インパクト。数字はないです。
あとは、同僚をどれだけ助けたか。むしろそっちのほうが大事になります。自分が大きなアチーブメントができたと思ったら、そのとき一緒に働いてたチームメイト、同僚とかに対して、自分をレビューするリクエストを送るという社内のシステムがあるんですね。もちろんポジティブな評価をくれる人にしか送らないですけど。
そういう人たちが、自分を評価してくれる。それがマネージャーに対して送られる。自分には見えないんですが。そういう評価を集めて、マネージャーがこの人はすごくよくやったからプロモーションさせるべきだ、というふうにしてボーナスをあげる。
質問者1：何通送らなければいけないという決まりはあるんですか？
河野：ないですよ。
質問者1：じゃあ、送られるか送られないかは評価には繋がらない？
河野：ないです。ただ、当然、自分がすごくいい仕事した、あるいはすごく助けられたと思ったら、やっぱりリクエストがきたら返事したくなるじゃないですか。この人すごく助けてくれた。おかげで自分もすごくいい仕事ができたよ、ありがとう。そういうリクエストがいろいろくるんですよ。
そうしたら、自分もがんばってうまくできたらうれしいから、できるだけポジティブに返事を書きます。そういうことが積もり積もって、チーム全体がいい雰囲気になってくる。
評価システムは何のために存在しているか
サービスをする上で何が大事かというと、バグを開くこと、フィーチャーを開くことではなくて、どんないい価値をお客様にできるだけ早く提供できたかです。その結果、儲けられればもちろんハッピー。ビジネスを継続する上でとても大事な要素なので、それはもちろん評価するんですけど。それを俺1人だけでやったということは、今の複雑なシステムの上ではまずありえないですよね。
例えば自分が使うAPIが別のチームのもので、何か新しいリクエストを足して欲しいなら、そのチームと交渉しなければならない。その交渉にはそのPMの力が必要。一緒にやった。うまくできた。やっぱりその人に対してはありがとうと言いますよね、普通の人間関係です。
こういう積み重ねで、良い雰囲気のシステムをできるだけ維持し続けることは、評価のシステムと絶対に切っては切れないと思います。
よく、アジャイルって何の意味があるのって言われますけど、会社の側からしたら、正直言って別にアジャイルでやってるかどうかなんて関係ないんです。できるだけ早くお客様に対して提供できるかどうか。その一点なので、10年後は別のやり方をしていると思います。今私が紹介しているのは、あくまで私たちがやってきたこと、ですね。
ただ、そこで評価システムは切っても切れないので、曖昧ですけども、物を作る上では考慮の一部に含めるべきことだと思います。
上司を評価するということ
1個言い忘れました。もう1つ評価システムがありまして、マイクロソフトでは上司を評価するようになっています。
「いやうちのマネージャーさぁ、俺こんだけやってもぜんぜん評価してくれないんだよ」というよくある話があります。アメリカの学校とかだと、授業を受けるとだいたいサーベイがあって、今の授業はどれだけ満足できたかを調査します。大学でも、小学校ですらあります。
会社の中でももちろんあって、上司も常に評価されています。悪いマネージャー、つまりこの人の下ではパフォーマンスを発揮できないと部下が感じたら、そのレポートは上司の上司にいきます。
この上司はチームのパフォーマンスを上手く最大化できないと判断したら、従業員はだいたい他のチームとか他の会社とか、別のところに行っちゃうんです。雇用が流動化して、ポジションを移りやすい環境があるという文化的な側面はあると思いますが、すごく健全だと思います。
マネジメントって、それ自体がすごく特殊な能力・スキルの1つです。全員ができるわけではないです。僕もマネージャーできるとは思えないです。
さっき良いマネージャーが大事だって言いましたけど、良いマネージメントであるかどうかは、上からの視点と横からの視点と下からの視点でぜんぜん違います。ピアのレビューと部下からの評価、そういうことを多角的に見て、マネジメントを含めた全体の評価が決まります。
ここは日本的な文化とだいぶ相容れないところがあります。（日本人が）自分で上を評価しろって言われても、何を書いていいかわからない。そこに対しては、頭を切り替えることが必要です。
プロダクトチームはどれだけ儲かったかは知らない
質問者2：評価の話で、そのプロダクトチームがどれだけ儲けられたかが原資になるという話だったと思いますが、これってAzureにする前のWindowsってけっこう大きいから、どのプロダクトが儲けたか評価しづらかったというあたりが、大きく変わったところでしょうか。
河野：はい。今も、WindowsとかOfficeとかは儲けが大きいんですよ。Windowsにいた頃って、毎週金曜日くらいになるとお菓子が出たりしたんですけど、Azureに移ってから、何もなくなっちゃいました。
（会場笑）
本当に稼げなかったので、最初の4年ぐらいは何もなかったですよ。最近になってようやく上がってきたので、毎月やるチームのデモにピザが出るようになりました。
当然会社なので、原資としては、ポテンシャルであるとか、いろいろなものを見て多面的に評価していると私は信じています。それが信じられなかったら別のところに行っています。
質問者3：その、売上情報というか、クラウドを使ったらあるファンクションを使ったらお客さんからダイレクトにお金が入ってきてすぐわかると思うんですが、そのあたりの情報は完全に透明化されて、わかるようになっているんでしょうか？
河野：実は教えてもらえないんですよ。そこはPersonal Informationの塊なので、開発チームが知ってはいけないことです。クラウドだとよく割引モデルとかありますよね。我々はこのサブスクリプションが何時間どれだけのVMを使ったかということはテレメトリでとれるので知ってるんですが、それに対していくら売上があったかは知らないです。
セキュリティとコンプライアンスについて
質問者4：生産性について知りたいんですが、先ほど家とオフィスの話で、Microsoftのような大きな会社なのに、開発者の生産性を上げるためになるべく制約をかけないようにしているということですが。日本だとかなり個人情報の流出とかうるさくて、大きい会社でセキュリティホールがあったりすると大変ですが、アメリカの会社は開発者の自由を縛らない中で、どうやっているのでしょうか？
河野：セキュリティとか情報漏洩とかコンプライアンスについて、Microsoftはどうやっているのかという趣旨の質問だと思います。いくつかお話ができます。
セキュリティって、いうなれば建築会社の安全第一と同じで、コンピューターを使っている上では一番トップに来る問題です。ですので、まず入社したときに全社員がトレーニングを受けます。
内容は毎年変わっていておもしろいんですが、個人情報のカテゴライズとか、あるいはコンプライアンスとか、一通りのセキュリティについて講義を受けます。一番最初に新しくフィーチャーを作るときに、セキュリティのスレット・アナリシス (Threat analysis) をチームごとにやります。そのあたりは当たり前なのでおもしろくないですが。
あと、Microsoftは大きいので、セキュリティ専門の人たちがたくさんいます。レッドチームという名前のチームで、わざと我々のサービスを攻撃するんです。いつ誰にとか予告なしにいきなりやられます。彼らは何の事前情報もなしにいきなり攻撃をしかけるんです。
基本的に、いろいろな権限の獲得を狙ってきます。一度サブスクリプションの権限さえとれてしまえば基本的になんでもできるので、そういうところを彼らは狙います。あとは、ソーシャルエンジニアリングとかでパスワードを得ようとしたり。
そういうことを継続的にやってまして、3年前やられたときは彼らが成功したんですね。セキュリティのでかいトレーニングで、たくさん集めた会場で、俺たちはこれだけお前たちのところに入ったぞイエーイと言われて、すごい悔しかったことをいまだに覚えています。当然すぐ穴はふさぎますが。
逆に、そういう人たちが中にいてくれるので、かなり安心して開発できてるところはあります。これは個別の会社がやるとかなり大変なんじゃないかなと、個人的には思ってます。
Azureチームに移ったきっかけ
質問者5：儲かっているチームから新規事業に近いAzureのチームに移ったときに、評価がチームの儲かりに依存するという話がありました。サポート的なものとか、利用する側の心の持ちようとかありますか。
河野：それは人それぞれだと思うので、私の話しかできないですが、当時、その行く先のクラウドが儲かってるかどうかにはあまり興味がなかったんですよ。私はさっき申し上げたように、コードを書くことが楽しい人間なので、ここに行ったらおもしろいことできるかな、それだけでしたね。
ウェブサイトを見たら募集のリストがいつでも全世界に公開されていて、いくつか探してメールを書いたら、たまたま10分後くらいに返事がきたんです。じゃあインタビュー受けてみて、明日の朝やるよ、って言われて。そのとき日本にいたので、テレカンというか、Skype for Business、当時はLyncといったんですけど、そこでインタビューして、じゃあ行こうかと。
あんまり深く考えると、リスクがあまりにも大きすぎて決められないと思うんですよね。まぁ、奥さんに背中を押されたところはありましたが。実はその後、日本で私がいたチームは解散になってしまいました。選択としては合ってたのかなと思います。
