なぜ、マネジメントが重要なのか？　米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part3

ハッカソンがエンジニアにもたらすもの

河野通宗氏（以下、河野）：では、話の続きをやります。（スライドを指して）ハッカソンの力って書いてあるんですけど、ハッカソンって、みなさんどういうイメージをお持ちでしょうか。

会社がそのサービスを使ってもらうために集客するイベントであったり、あるいは自分たちの勉強会の一部というイメージもけっこう強いと思うんですけれども、我々はこれをガチでやっていまして、そのApp Serviceのチーム内で年に1回ぐらいやっているんですね。

今、我々が提供している機能の半分以上は、このハッカソンから出てきたものです。使っている方はご存じかもしれませんが、スロットであるとか、LinuxのWorkerも実はこのハッカソンから（出ました）。そういうのって、トップダウンで「お前らこれやれ」と言われたわけじゃなくて、我々が「楽しいからちょっとやってみようよ」って始めたんです。

これは1日じゃなくて、1週間どーんとハッカソンに使わせてもらって、その間、アサインされている作業は止めていいと、マネジメントがもうがっちり固めてくれます。そこがすごく大事なんですよね。

「本当はこういうのが作りたい」って、たぶんみなさん心の中にあると思うんですよ。業務と関係ないかもしれないけど、でも、そういうパワーってものすごいものがあって。ゲームチェンジになる可能性がけっこうある。

エンジニアの方だったらたぶんわかってもらえると思うんですけど、そういう場が与えられると、なにかやりたくなるじゃないですか。しかも、それをAzureのプロダクトにできる。これはもうたまらないですよね。

そういう機会を設けてもらってまして。私、 LinuxのWorkerを4年前ぐらいに1回そのハッカソンでやって、その時はポカーンとされたんですけど、その次の年に別の人たちがLinuxのWorkerというかApp ServiceのLinux版を始めて、そこから本当にプロダクションになりました。

あともう1個。私、実はその時まったく別のハッカソンのテーマを出して、それはめでたく入賞しました。審査員がいて、アワードをもらいまして。Amazonの商品券なんですけども。

（会場笑）

やっぱりうれしいですね。そういう業務と直接関係ないように見えるところで、なにか自分のアイデアを活かせる場が開発の中にあるというか。これだけでワクワクしますよね。

これってすごく大事なところでして。エンジニアリングが持ってるポテンシャルを活かす場というのは、別にハッカソンに限らず、なにかしら会社の中にあると、そこは必ずポジティブな力として進んでいく。

そこにマネジメントのバックアップは絶対必要です。そこ（のバックアップ）がないとまったく進まないと思います。ですので、組織全体でエンジニアリングに対する、embraceと英語で書きましたけども、進めていく力というのは、我々組織の人間としては大事かなと思います。

参加者6：今のハッカソンについて質問なんですけれども。お客様はまったく絡まずに、社内のエンジニアと社内のアイデアだけでハッカソンするだけなんでしょうか？

河野：そうです。その時は我々のチーム100人ぐらいでやったんですね。「ハッカソンイベントを1週間、この週でやるよ」「テーマを募集してね」と言うと、もうだーっと40個ぐらいテーマが出てくるんです。僕は1人でやったんですけれども、3人ぐらいのチームが多いです。ぶわーっとアイデアがたくさん出てくるんです。

そういう中に、別に入賞しようがなんだろうが、自分はそれをいいアイデアだと信じているような（アイデアがあって）。誰かそれに共感してくれる人をつかまえて巻き込んで、そこから実際にフィーチャーとしてお客さんに提供するものができる。そうやって、みなさんに喜んで使ってもらえているフィーチャーを提供することができています。

マネジメント側は「なにがゴールなのか」を発信し続けるべき

「マネジメントの力」。もうだいぶお話ししちゃいましたけどね。私は雑魚なのでマネージャーじゃないですが、日々マネジメントの大切さは痛感しております。

お話したように、デベロッパーの仕事って、コードを作って運用するという、そこまで全部に責任を持つ仕事をやっています。例えばバグがあるとか、「これをなんとか今日までにやりたい」みたいな。頭をずっとこうして（パソコンを見つめて）やっちゃうときが当然あるんですね。

そういうデベロッパーがバラバラにやっているのに対して、「今はこっちじゃない。今フォーカスすべきはこっちだよ」とちゃんと指導してくれる、ディレクションをしてくれる。船のキャプテンと同じですよね。そこをしてくれる人がいないと、チームとして発散しちゃいます。

ポイントとして、常にマネジメント側から「なにがゴールか」というのをメッセージとして出し続ける必要があります。「我々がこうやるのはどうして必要なのか？」あるいは「これをやることでお客さんに喜んでもらえる。だからやろう」と。これって最初に言うだけじゃなくて、毎日のように言うんですね。

人の心に響く部分って、共感してくれる人なら1分もかからないんですけどね。でも「本当にそんなの意味あるの？」みたいな人はたぶんいます。だから、やっぱり継続的なメッセージの発信はとても大事。それがトップから降りてきて浸透するまでには、当然すごく時間がかかります。

前CEOスティーブ・バルマー氏が語った「One Microsoft」

「CEOがサティアという人に変わったことでだいぶMicrosoftの雰囲気が変わった」という記事がいろいろなところで出ています。一部はそのとおりなんですが、実はその前から変わり始めていました。

というのは、その時のスティーブ・バルマーは、外からの評判は悪いですが、当然CEOなので頭がいいんですよね。社外でなにを言われているかは当然わかっている。どう改善すればいいかも、だいぶ理解していました。

私、今でも覚えていることがあります。全社でcompany meetingというのを9月に社員を集めてやるんですけど、その時に「One Microsoft」という概念をバルマーが言っていました。「俺たちは1つの組織なんだ。だから、みんなでやろうよ」と。

それまでって、みなさんご覧になったことありますかね？　Microsoftの社内の関係図で、お互いのチームが銃を向け合ってる、というのを見たことある方おられると思うんですけれども、それまではわりとそんな感じだったんですね（参考）。でも「One Microsoft」のイメージとしてデモを見せてくれたんですね。

そのデモは、例えば「Bing」というサーチエンジンがありますけれども、サーチで検索した結果がXboxで動いている。これをOfficeに取り込んだり、あるXboxで出たゲームのデータがクラウドに上がって、それがこっちで見える。PCでもストリームできる。そんなふうに、いろんなプロダクトを出しているところが連携してつながることで、Microsoftはもっとおもしろくなるということを見せてくれた。

「ああ、こういうことか。じゃあ、なにか一緒にやればもっと楽しいことができるじゃないか」と教えられたというか。それがまさにビジョンでした。

それって下から上がってくるのは難しくて。やっぱりトップの仕事って、自分たちの行き先を大きく示してくれて、それを我々が個別に解釈しながら、アイデアを出し合いながら、一緒になってお客さんにいい価値を提供できるというふうにできれば、会社としてすごく健全で、私としても働きやすい。今も引き続き楽しく働くことができています。

よく、エンジニアだと「マネージャーになりたくないよ」とか「マネージャーって別にいなくていいじゃん？」って聞くんですけれども、実はとても大事で。むしろそこが組織としての力の源泉かなと思います。

変わらなかったことは「変わり続けた」こと

ざっと本当に思ったことをダラダラと並べたんですけれども、基本的に僕が変わらなかったことって1つだけあって。それは常に変わり続けた、ということだけでしたね。もう本当にいろんなことが変わりました。最初怖かったんですけれども、「とにかく変わることが当たり前。変わらないことこそが怖い」というふうにマインドセットが変わると、それはすごく楽しくなるんです。

日本には「諸行無常」ってあるじゃないですか。常に変化する。留まらない。消えちゃうのはちょっといやなんですけど、基本的にいろんなことは1つとして常に同じものはない。日本のそういう教えって、結局こういうことなのかなと。自分なりの解釈ですけれども、今はそう理解しています。

スタンドアップミーティングは報告会ではない

最後にいくつか、私なりの理解というか、「こういうことが大事だよ」というところをちょっとだけ挙げてみました。共感する部分・しない部分があると思います。

まず、スクラムですね。というか、スタンドアップミーティングですけれど。あれって短いミーティングじゃないんですよ。短くしようとしすぎると、ただの時間の短い報告会になっちゃって「これ結局やっても意味ないじゃん」ってなっちゃいます。惰性というか、つまらないと。

僕なりの解釈は、そのスクラムというのは、自分のwork itemsをできるだけちゃんと早く終わらせるための場であるということです。自分が今どんな問題を抱えてて、「ここがblocking。これに対してどう進めたらいいか知恵を借りたい」とか。あるいは、そういったほかの人のリクエストに対して「じゃあ、自分が貢献できるよ。協力しよう」という、その協力の場を作るためのトリガーの部分だと思います。

そうじゃないと「自分は昨日これをやりました。今日はこれやります。以上」。それをなんか5人ぐらいでやっても……そんなのはもうやめちゃいました。

（スライドを指して）あと2番目のこれはマネジメントとも関係しますけど、私たちのロールですね。Developerと、Program Managerというのがいます。

PMは我々でいいますと、Product ManagerじゃなくてProgram Managerといいます。Program Managerは、ほかのチームとのコミュニケーションや、あとプライオリティの調整など、いろんなことをやってくれます。

ただ、PMが上とかじゃないんです。我々コードを書く人間とPMというのは同列です。ここってすごく大事なところで。同列じゃないと、なんかPMが「お前ら、やれ」ってやると、たちどころに「我々はそんなところにいたくないです」ってあっという間に（デベロッパーが）いなくなっちゃう。だってつまらないじゃないですか、そんな仕事をしてたら。

デベロッパーに対しての尊敬、PMに対しての尊敬。お互い同列の単に別々のロールで、ゴールはいいものをできるだけ早くお客さんに届けるという、ただそれだけです。そこの意識を揃えるのってマネジメントの力なんですが、ここがすごく大事だと思います。

日本でよく見る、「プログラマってつまらない」みたいなやつ。下というか下流というか。上流の設計を書く人間のほうが偉いみたいな話を時々見ます。本当なのかどうか知らないんですけれども。

設計はデベロッパーの仕事で、プログラムに対してすべての責任を持ちます。PMというのは、それらに対してうまく調整する役目です。お互いが協調していい仕事をする。もうそれだけですね。

上司を上手く活用せよ

（スライドを指して）あと3番目には「上司 is 使うもの」と書いてます。これはさっきのservant leadershipに関係しますけれども、上司、マネージャーというのは、会社としてのdecisionを伝える役目はあるんですけれども、同時に、我々が働きやすい環境を提供するための人です。ちょっとわかってもらえるか、あれなんですけど。

そのためには、部下としての自分が今どういう問題を持っていて、どうすればよくなる、あるいは自分が次にどんなことをしたいというのは、常に上司に対して伝える必要があるんです。

「自分は今ものすごく忙しい。これ以上仕事をアサインしないでくれ」「次のものをやりたい」「今こっちは別の仕事ができるから、自分はこれをやりたい」というイベントをどんどん上司に対してfireする（訴える）必要があります。

私もそこがうまくできるようになるまで、最初すごく時間がかかりました。その当時のマネージャーに、スイッチを切り替えろと言われてわかったんですけれども。それでもわかったあとに実践できるようになるまで、ずいぶんかかりました。

というのは、やっぱり日本的な考えだと、上司が指示して自分は「へへー」みたいなイメージがあったので。でも、そこで「上司とは自分のパフォーマンスを最大化してくれるための良きパートナー」だと（考えた）。そこってマインドシフトがすごく大事でした。

あとは、最初にお話ししましたが、設計書なんていらないですね。書いてメモだけで十分です。どうせ来週には意味なくなります。

バグ0って絶対ありえないですよね。バグはあって当たり前です。大事なのは、お客さんのコードをちゃんと動かせること。それだけだと思います。

座ってるだけの会議には出なくていい

それから、これ「participate」と書きました。これ日本語で辞書で引くと「参加」とか「出席」という言葉になっちゃうんですけれども、英語ではもっと別のニュアンスを持っています。

participateというと、会議に対して積極的に参加することを意味します。意見を言ったり、質問したり、そのミーティングの中で決めなきゃいけないことに対して、なんらかの貢献をすることを指します。

ただ座ってるだけなら、いなくていいんです。いる必要がないし、むしろその時間がもったいない。ほかのより生産的なことをしたほうがいいです。あと、自分のトピックが終わったら、別にその場にいる必要すらありません。

日本的なマインドだと、僕は昔、「会議」ってそこに座っていることだと思ってたんですけど、実はそうじゃなくて。会議というのは、なにかの意思決定をしたり、作業を前に進めるための場場なので、自分がそれに対して貢献できるならいるし、貢献し終わった、あるいは自分は関係ないんだったら、もういなくていいんですよ。

これって部下も会社そのものも、そういう意識に変える必要があります。「スタスタっと外に出ていって、あいつはなんだ？」みたいに言われたらそれは困っちゃうので、これって全社的な意識の変更が必要だなと思います。これとくに日本に対してのアドバイスですけど。

あとミーティングをやると、だいたい誰か1人「書記やります」と言ってなんかメモ取ってて、ミーティングが終わるとメール投げたりしますよね。あれ、いらないです。お客さんに対して必要な面はあるかもしれないですけど、基本的に中ではまったくいらないです。

どうしてかというと、メールの送り先はその意思決定に参加しなかった人なんですよ。だったら別にその人に対して、わざわざ送ってやる必要はないですね。

しかも、その議事録をとっている人は書くことに集中しちゃってて、その意思決定にだいたい参加できないですよね。書記としてカタカタカタやっておしまい。そうじゃなくて、今決めなきゃいけないことに対して意見を言うことのほうがはるかに大事。

あと紙の書類で最近、僕が印刷したのって、ここに来るScrum Gatheringに参加するためのものを印刷したのが最後ぐらい。あと、Excelはもう一切立ち上げないですね。あれ、やめてくださいね。害悪1位のシステム。

（会場笑）

属人化を避けることは無意味である

最後にテーマである「属人化したExpert集団こそ最強」。そこだけ最後にお話しします。

よくオペレーションの話になると、「属人化を避けよう。知識をできるだけ共有して、みんなで誰のwork itemsでもできるようにしようと。トラブルが起きても、あるいはその人がいなくなっても、作業に滞りが出ないようにしよう」ってあります。

一面正しいと思います。ただし、これだけ世の中が常に変化して、いろんなフレームワークが毎週のように出てきてとなると、その中で全員の知識レベルが上がっていくのって、まず無理ですね。

当然誰でも、得意分野・不得意分野があります。例えば私は昔、低レイヤが大好きでOS作ってた人間です。あとネットワークとか、そういうことが好きな人もいるし、Webのフレームワークが大好きな人もいる。あと社内のほかのサービスに対してものすごく詳しい人がいる。

そういう将棋の駒というか、サッカーでストライカーとかディフェンダーとかいますよね。そういう人たちを「全員ストライカーにしましょう」と言うと、たぶんみなさん「何言ってるの？」ってなると思います。

ワールドカップで勝つためには、ものすごくいいストライカーと、ものすごくいいミッドフィールダーと、ものすごくいいディフェンダーをうまく揃えなきゃ絶対できない。勝てないです。それらをうまく統御するコーチが必要です。それらの人をサポートするために、ものすごくいろんな環境が必要です。

だから、実際に働くプレイヤーは11人ですけれども、そこに対して膨大な数の人がサポートしています。これらに対しての上下とかないですよね。ゴールは勝つことなので、そのためにはその最適な手段をとる必要がある。

我々の場合は、OSとかフレームワークをとことん追求してもらいます。そういう人たちじゃないと、ハッカソンでいいアイデアって出てきません。当たり前ですけど、尖ってないと、いいアイデアであっても、それを3日間で作ることはできないので。

そういう人たちをうまくポートフォリオで揃える。その人たちがどこかに行っちゃわないように、うまくゴールを揃えながら楽しく働いてもらうというのが、組織として、私ども社員として、楽しく働けるモチベーションになっています。

たぶん、いろいろあるかと思うので、ぜひあとで議論したいところですけれども、私の現状としてはこんな感じでやっています。

現在は夢のような世界

最後に一言だけ。何度も繰り返していますけれども、私はコードを書くのがものすごく大好きなんです。私、本当にそれだけで……。小学校1年生の時の誕生日に、親がコモドール社の「PET 2001」を買ってくれたのが始まりでして。今年でコンピュータ歴がたぶん39年か38年ぐらい。とっくに「35歳説」というのは過ぎている人間なんですけれども。

価値ってすごくボヤっとはしていますけれども、昨日のキーノートでもありましたけど、お客様が喜んでくれるって、やっぱりすごく大事というか、うれしいことですね。ソフトウェアは使ってもらう人がいてなんぼの世界ですので。とくに今の世界ってGitにプッシュすれば、それだけで全世界の人が見てくれて、使ってくれます。

昔『アスキー』とか『I/O』の本を見ながら打ち込んで楽しんでた人間からすると、夢のような環境。これはもう使わない手はないということで、私は日々これからもどんなことができるかってワクワクしながら考えています。みなさんにもぜひプログラムを書き続けてほしいなと思っています。

雑多な話で恐縮です。以上で私の話を終わります。ありがとうございました。

（会場拍手）

MTGに意思決定者が参加できない時にどうするか

司会者：河野さん、ありがとうございました。もう少し時間取れると思いますので、ご質問ありましたら、ぜひ挙手をお願いいたします。

質問者7：最近というか、一昨日ぐらいにうちのチームであったことなんですけど。意思決定に参加するタイミングで、どうしても（ミーティングに）来れない。けど、例えば2〜3人ぐらいで話し合って「こういうふうにしよう」と決めた結論が、あまりいいものに思えなかった場合って、どういうふうにコミュニケーションを取りますか？

河野：2通りあります。まず1つは、ミーティングのスケジュールが出た時点で、「自分は参加できないけど、これには自分は絶対に関わりたい」からと言って、リスケジュールしてもらうのが1つ。

リスケできなかった場合は、あとでもう1回全員を集めてミーティングし直す必要があります。そのときに「やっぱり自分はもっといいアイデアがある。だから協力して」というふうに（伝える）。

ミーティングの結論に対して後から「これはお前はダメだろう」と言うと、当然みんな保守的になるじゃないですか。「いや、だってこれ俺たちが決めたし、あんたいなかったじゃん？」ってなりますよね。そこってコミュニケーションがすごく大事で。みんなが楽しく働き続けられるようなメッセージで伝える必要があるかなと思います。

日本語ってすごく難しくて。「これどうなっているの？」と言うと、なんかシンプルな質問なのに、すごくいろんな意味を汲み取る人がいるじゃないですか。

（会場笑）

誰もが攻撃的じゃない質問をする。あと、ゴールはなにかを常に意識する。これはいいソリューションを作ることですね。「バグを憎んで人を憎まず」ってよく言うじゃないですか。それを上からの継続的なメッセージとして出すことがとても大事だと思います。

そのメッセージを受けることで、自分も「ああ、別にこれは攻撃されてるんじゃないんだな」っていう安心感が出ます。「じゃあ、いいソリューションを一緒に作っていきましょう」と、またミーティングをできるかなというふうにします。実際、我々もそういうのがよくあります。

質問者7：「バグを憎んで人を憎まず」は初めて聞きました。

河野：ああ、そうですか（笑）。

テストとドキュメントについて

質問者8：貴重な発表をどうもありがとうございます。私、QAをやってるプログラマなんですけれども、ちょっとドキュメントのことでお話が聞きたいです。

チームのウォーターフォールのところで「ドキュメントどうする？」だったりがあるじゃないですか。そのときに、チーム内ではどういうことをやってて、どう変わっていったのかというのと……。

もう1つは、そのドキュメントって、設計書なんかないというのがよくあるんですけど、サポートのチームとかで外の人たちに使うときは、やっぱりドキュメントっているんじゃないかなと思うんですけど、そこらへんののお話を聞かせていただけますか？

河野：じゃあ、最初の質問にまずお答えします。実は私、デベロッパーになる前、Microsoftの中にSDET（テストデベロッパー）というロールがあって、テストコードを書きつつ、テスト全体に対しての責任を持つQAみたいなものをやっていました。だからコードを書くのが仕事なんですけれども、わりとドキュメントがないとガクッときたというのよくわかります。「なにしたらいいの？」ってなりますよね。

我々が今やっていることは、テストコードを一緒にチェックインする。たぶん、みなさん、だいぶやっておられると思いますけど、ユニットテスト、ファンクションテスト、End-to-Endでのシナリオテストなどを作ります。

レビューは、コードレビューを自分の関係ある人たちに対して送って、その人たちがテストも一緒に見てくれます。「ここ足りないんじゃないか？」あるいは「ここユニットテストしなきゃダメだよ」とか。

昔はテストプランを書いたり、テスト項目の洗い出しとかをよくやったんですけれども、次の週には無駄になっちゃうんですよね。なので、我々の結果としては結局、生き残るのってコードだけだったという感じになっています。

ただ、サポートのチームはソースコードにアクセスできないので、それだけじゃ足りなくなります。我々の中でどうやっているかというと、そのサポートのためのツールをたくさん提供しています。

あと、新しいフィーチャーを出すときとかは、やっぱりミーティングをして「これはこういう機能があって、こういうものがあって、試してフィードバックしてください」って言うんです。

サポートのチームって優秀でして、我々の最初のお客さんなんですよ。とにかく使ってもらって、「インターナルプレビュー」と私たちは言いますけれども、その人たちからのフィードバックって本当に貴重でして。ものすごく知識が豊富なので。

その人たちのフィードバックを受けてバグを直してから、パブリックレビューとかやりますね。お客さんに使ってもらったりします。そんな感じでお答えになってますかね。

電話番をやってみてわかること

もう1個は、私たちはいわゆる電話番というのをやります。年に2回ぐらいなんですけど、この1週間はカスタマーのリクエストに対して、もうその問題を解決することだけにフォーカスするというのを順番にやります。

すごく大変なんですよ。だいたい1日6〜7個ぐらい問題が来て、それを解決し続けるというのをずっと1週間やる。夜中も電話がかかってくるんです。ずっとやってると、胃が痛くなるのがあるんじゃないかなと思うんですけど。でも、やっぱりお客さんの痛みを直接味わうってすごく大事だと、サービスを運営している側からは思います。

インシデント処理をうまく回すためのシステムがいろいろあって。アラートコールとか、電話も自動でかかってきたりとか、それに対して何分でresolveできたかが全部トラックされたり、いろいろあります。

お客様のリクエストに対して、できるだけ早く解決するのってとても大事なことなので、そこに対しては継続的に改善しながらフィードバックして、プロセスに戻したりとかは常にやっています。

司会者：では、時間になりましたので、こちらで1回締めさせていただきたいと思います。河野さん、どうもありがとうございました。

（会場拍手）