今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。
私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。
だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。
気になっていたSamの一言
VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行ったときに、彼がある先進的な会社を訪問した時に私にぽろっと言っていた事を思い出した。
先進的な企業と言っているけど、レイアウトが全然アジャイルじゃない。オールドファッションな日本企業だ。
その当時自分はその言葉の意味が分からなかった。オープンなスペースで、プログラマに対してもディスプレィもしっかり複数支給されていて、見晴らしも良い。だからスルーしたのだが、心には引っかかっていた。Matthewのチームを見にきて「ああ、そういうことか！」ということが相当腹落ちした。
伝説のルームレイアウトが眼前に広がった
開発チームがいる部屋に入ってみると、みんながとても歓迎してくれた。私はみんなは、日本では有名でヒーローなんだよ という話をしてあげたらとても喜んでいた。
ルームを見ると、小さな島で構成されている。部屋はオープンスペースで、とてもペアプログラミングがしやすい構成になって いる。その中の「マネージャ」という人がポイントを教えてくれた
すべての机に滑車がついているだろう？だから、簡単に場所を移動できるので、ペアプログラミングとかしたくなったら移動 できてすごく楽なんだよ。
そして、彼は続けて説明してくれた。
もし、集中したくなったら、フォーカスルームを用意しているから、そこにこもって集中することもできるようになっているんだ。みんなが作業に集中できるようにね。
オープンスペースでの開発は、大きなディスプレイが与えられて、頻繁に声を掛け合いながら開発をしている。横の人が ペアプログラミングを始めた。
この感覚はなんだろう。Extreme Programmingの白本で見た、当時衝撃を受けたあのレイアウトだ。フォーカスルームの アイデアも何かで読んだことがある。しかし、日本ではここまでしっかりやってるところはどれぐらいあるだろうか？なんで私は今まで「知っている」はずのものをたいして効果がないだろうと決めつけてやらなかったのだろうか？そんなことを考えるとさらにドキドキしてきた。
強烈なフォーカスを生み出す力は、フォーカスできる環境から
各プログラマがそれぞれフォーカスできるようにとても工夫しているようにも感じた。ペアプログラミングをしている人以外は 集中したい人は大きなヘッドフォンをしているし、スタンディングディスクになっているので、スタンディングスタイルにチェンジして開発を始めた人もいる。
マイクロソフト最高のチームは、特に日本にないような特別の部屋で開発をしているわけではないし、我々もやろうと思えば 全然できてしまうはずなのだが、彼らは私が本を読んで知っているはずの事を忠実に実行していた。
日本よりアクティブなスタンドアップ
次にスタンドアップが始まった。時間は 13:30 。もちろん、VSTSのソフトウェア看板がどっかーんと表示されたバカでかい スクリーンの前にみんなが集合してきた。意味不明だが、なぜかMacだった。 みんな今日やる作業に関しての共有が始まったが、日本で行われている朝会よりもずっと「アクティブ」に感じた。日本のは もっと淡々と「きのうやったこと、きょうやること、課題」を共有していく感じだが、そこに、時間は短いけど「ディスカッション」が入る感じ。教科書通りだと、「ソリューション」は終わった後で個別に解決が定石だが、ディスカッションの時間と問題解決が速いので、特に問題に感じなかった。むしろ相当効率的に感じた。
このチームには、休暇含む９名のメンバーと２名のリモート（中国、インド）のメンバーがいるチームだった。リモートのメンバーの一人が、横にあるディスプレィで、常時顔が見えるようになっていた。
カンバンの工夫
ただ、ソフトウェアKanbanに、レーンが設定されていたので、それは何かを聞いてみた。実は一瞬「ま、まさかバッドプラクティスのミニウォーターフォール？」と思ったがそうではなかった。レーンは
Backlog -> Up coming -> Investigate / Design -> Implementation -> Pull Request -> Evaluate -> nag -> Done
となっていた。各レーンは、ワークアイテムの最大数が決まっている。Backlogの優先順位が高いものから、Up comingに取り込んで 、Designに移る。Designは、企保的にストーリが「理解できたら」次のimplementationに移るらしい。その後、Pull request を実施したら、Evaluateだ。例えばあるペアが開発を行ったワークアイテムだと、それ以外の人がをのプルリクエストを見るようにしているらしい。駄目じゃない？というときはnagに移すとのこと。
テレメトリの徹底活用
さて、ここまでは特に特別なことはないのだが、次の２つはアジャイルチームではなく、DevOps チームである特徴にあふれていた。 まず、一点目は、徹底的にテレメトリをとって、それをいつでも見えるように共有していることだ。PowerBIをつかって、大きなスクリーンに画面いっぱいのさまざまなテレメトリをリアルでチェックできるようになっている。朝会でも見ていたが、常にこれを見ることができる。
Fチーム / Lチーム
次のプラクティスが結構すごいと思ったのだが、Fチーム、Lチームという考え方だ。このチームは内部で２つのチームに分かれている。だから今どちらのチームにだれがいるか？というダッシュボードも存在している。
Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。
Ｆチームは、プログラマがフォーカスできることと、品質を高めることを重視している。だから、開発中に実施できるワークアイテムの数を例えば５に制限している。お偉いさんがやってきて、今すぐ機能を対応してほしいときは、その枠を超えないように入れ替えをする。
Fチームの開発に関しては、基本的にペアプログラミングのペアで作業している。これは、すべての機能を誰か一人しか知らない状況を防ぐためとのことだ。さらにペアは組み替えられる。 ここで、私はＦチームは楽しそうだと感じた。メールもほぼほぼ見る必要もないし、割り込みも入らない。これは相当集中できるだろう。
しかし、Lチームはおもろないやろなー。と。しかし、Matthewは続けた
Fチームと、Lチームは、定期的に入れ替える。単純にそれぞれのチームに最も長く滞在しているメンバをスワップするんだ。 そうしたら、ペアのうちの一人が入れ替わるから、知識共有の面でもいいだろう？
自己組織チームはこういう姿
なるほどー。と思った。これは素晴らしいアイデアだ。フォーカスルームやレイアウトもそうだが、このチームは徹底的にプログラマが集中できるような環境を工夫して改善していると感じた。Fチームは、Lチームのおかげで相当集中して、安定した機能をデリバリできるだろう。Matthewによると、この方法でもう１年ぐらい運用しているが、すごく生産性と品質が向上しているらしい。近々Mathew本人が記事を書いてくれるらしいので楽しみにしていよう。
そして、チームメンバが同じゴールに向かって、相当いい感じで、楽しく仕事ができているようだった。完全に自律的なチームで、まさに自己組織化チームだ。マネージャと呼ばれる人はいるけど、チームを助けてすごくサポーティブだ。
９割は既に知っていたはずの事だった
このチームを観察して感じたことは、「新しいことを知った」とか、「見たこともない最新技術を見た」とかいうことでは決してなく、最先端の DevOps チームというものは自分たちが「知っていたはず」のことを着実に忠実に実行して、そのうえでしっかり改善を続けているチームだったということだ。何のマジックもそこにはない。
ただ、私は今まで出会った中で最高のプロフェッショナルなチームだと感じた。観察していると全く無駄がないし、各メンバーはリラックスしながらも誰に言われるわけでもなく、すごく集中して作業を実施している。自分が勝手に「あまり効果がない」と思ってやらなかったことの積み重ねが本当は重要なんだということを思い知らされた。 彼らに限らないことなのだが、こっちにいると、本当にみんなプロフェッショナルなのだ。誰もダラダラしている人がいないし、無駄話もだれもしていない。このオフィスも遊びの要素はほとんどなくて、集中しているが、定時になったらみんなバリューを出してさっと帰っていく。 そこからいろいろ楽しむのだろう。
フォーカスへの投資が効率を生む
スタンディングディスク、複数台の大きなディスプレィ、可動式のディスク、フォーカスルーム、大きな看板用のディスプレイなども、日本の会社だと認められないかもしれないが、そういうものが本当に生産性を生むということを本当に認識した。生産性をあげるためには、チームをルールで縛るのではなく、チームの自律的な「フォーカス」を生み出すことに集中するべきなのだろう。しかし、我々は本当に、エンジニアが、「フォーカス」できることに徹底的に投資してきたのだろうか？ 彼らはフォーカスのためにあらゆることを実施していた。
正直なところ、私がかつてこの目で見たチームの中で、圧倒的に効率がいいと感じた。しかも、それは、ほとんど自分が知っているプラクティスによって生み出されていた。我々はどこまでプラクティスを本当の意味や、価値、そしてそのバリューを理解してきたのだろうか？簡単に日本では通用しないと魔改造してきたのではないだろうか？でも、私が見た彼らは圧倒的に洗練されていた。言語とかツールじゃないのだ。
我々がすべきことは、「当たり前の事」をできること
我々が彼らのスピードに追い付くためにやるとよさそうな事は、「まず教科書通りにやってみる」ことじゃないだろうか？と思った。彼らを観察すると、バカにされるかもしれないが本当に「教科書」的に、愚直に実施している。ソフトウェアエンジニアリングの基礎、ペアプログラミング、スタンドアップ、Kanbanの運用、スプリント、継続的インテグレーション / デリバリ 我々が見たExtreme Programmingの本や、Scrum、DevOpsの本や講演で見聞きしたプラクティスが、そのまま行われている。それをきっちりやったうえで新しいプラクティスを積み重ねて、さらなる工夫をしている感じだ。
我々は現場に合わないと、すぐに駄目だということにして、違う方向に改造してしまう。しかし、本当に重要なことは、何千人もの人が実施して認めたベストプラクティスをまずは正しく理解して、愚直にやってみることかもしれない。我々はそこにも到達していないのでないだろうか？という思いを新たにした。
まとめ
今後、PaaS, SaaSの力が増大し、マイクロサービスの時代、そして、現在はServerlessに注目が集まっている。今後は 人手が多くいることはどんどん自動化してくるだろう。そして、人でしかやれない部分が残る。そういう時代に必要なのは、本当にプロフェッショナルでスキルの高く、自分で考えることのできるエンジニアになってくるのではないだろうか？誰かが考えたことの作業をするだけの人は、要らなくなる。 そうなってくると、本当に生産性を上げるのに重要なのは、実際に開発や運用をする人が如何に効率よく作業を実施できるかにかかってくる。
プログラミングは高度な頭脳労働が残る。そして、プログラマの生産性の差は10 - 25倍と言われるのだから、これからは、「チーム」や「人」を重視して、彼らが「フォーカス」を獲得するために何をするかが、地道だが差別化のポイントじゃないだろうか？