実践「最高のアジャイルチーム」を作る方法

SkyWayの開発現場

iwashi86氏：よろしくお願いします。NTT Comの岩瀬と申します。

このタイトル（SkyWayの開発現場 〜いつの間にか最高のアジャイルチームになっていた件について）を見てわかるんですけど、ちょっと盛ってるんですよね。みなさん「最高ってなんですか？」と思うかもしれませんが、そもそも今日の「最高」の定義を言っておくと、あるアンケートを社内の組織でとった「チーム評価」の結果が由来です。

ご存じかどうかわからないですけど、厚生労働省が作っている「仕事のストレス判定図」というものがあります。

右側の図を見てもらうとわかりやすくて、真ん中が100で、縦軸と横軸が上司と同僚のサポートなんですよね。

100が全国平均な感じで、例えばこの「110」だと、そのチームの人たちのメンタルストレスって、メンタルヘルスが不調になるリスクが10パーセント上がります、というのが表の読み方です。

この赤軸が、一般的なサラリーマンの全国平均です。

じゃあ私が所属しているSkyWayのチームはどこかというと、余裕で圏外でした。「右上のこのへんにいました」というのが答えです。

今日は「なんでこうなっているんですか？」ということをしゃべりたくて、実践しているアジャイルのプラクティスをいくつか紹介したいと思います。

今日は「なんでこうなったんですか？」をみなさんに紹介して、なにか1つでもよい取り組みがあったら持って帰ってほしい、というのが私の今日のプレゼンのゴールですね。これをやっていきます。

申し遅れましたが岩瀬義昌といいます。

「@iwashi86」というTwitterのアカウントでやっていますので、今日のスライドをこのアカウントで放流します。

ふだんは、あとでしゃべる「WebRTCのSkyWay」というプラットフォームのテクニカルリードをやっています。あと、知らないかもしれないですけど、「Fukabori.fm」という技術系のPodcastのパーソナリティをメインでやっています。

みなさんに聞きたくて、一応宣伝なんですけど、「WebRTC」って聞いたことある人？

（会場笑）

おお、すごい！　さすがエンジニアが多いですね（笑）。聞いたことない人向けに、ちょっと持って帰ってほしいものがあるんですけど、WebRTCはWeb Real Time Communicationの略です。

何ができるかというと、例えば、みなさんもLINEやSkypeを使ったことあるじゃないですか。あれは通話機能を持っていますよね。それをadd-onで自分のアプリに実装できるのがWebRTCです。

最後にもう1個だけ、今日覚えてほしいのは、この開発・運用が沼なんですよ。いくらでも時間を吸い取られて、本当に面倒くさいので、その面倒くささを解消するためのプラットフォームを作りましたってのが「SkyWay」です。我々はこれをNTT Comでビジネスとしてやっています。

前提と今回のテーマ

ここまでが宣伝で、本題にいきます。今日はいくつか話をしたいんですけど、まず前提として「スクラム」の話をけっこうしていきます。

我々のSkyWayはスクラムで作っていて、1 week sprintで回しています。イベントは全部水曜日に行って、プランニングとか振り返りは水曜日にやっているという実装ですね。

メンバーはこんな感じで、専任のスクラムマスターを1人置いています。かつ、プロダクトオーナーとプロダクトマネージャーは一緒の人がやっていますね。

開発チームは8人ぐらいで、大企業的な傾向かもですが、みんな共通業務に悩まされているようなメンバーです。だから、開発チームは8人いるんですけど、完全に専任できてなくて、実質はもうちょっと少ないリソースですね。

特徴的なのは、チームの志向としてけっこうみなさんリモートワークが好きなんですよ。だからけっこうリモートワークをしています。ただ「水曜日だけは人が集まる」ようにしています。

こういう前提の下に今日3つほど話をしたくて。「プロセス」の話と「技術」と、最後は「人とチーム」の話をしたいと思います。

まず「プロセス」からいくと、こんな感じですね。

スクラムの実装についてしゃべっていきます。今日は「スクラムガイド」って読んだことある人が多いと思いますけど、スクラムガイドって軽量なおかげでぜんぜん……ぜんぜんと言うとあれですけど、具体的な取り組みがあまり書かれていないんですよ。

そのあたりを中心にお話ししたくて、最初にしゃべりたいのは「スプリントプランニングってどういう実装してますか？」というところです。

スクラムはプランニングからやっていきますよね。我々はけっこう苦労してこうなった、というところを1つお話しします。

キャパシティの管理、キャパシティマネジメントみたいな話が、企業ではよくあると思うんですけど、どうしても兼務じゃないとしても、変な業務が差し込まれて思いどおりに時間が使えないことがあったりするじゃないですか。スクラムとこれを混ぜ合わせるってけっこうよくなくて、最初に時間を算出しておくのが重要です。

スプレッドシートでいいんですが、地道にこんな感じでAさんとかBさんは「この1週間はこのぐらいの時間を使えます」ということを合計値で積算しておいて、最後にベロシティをちゃんと計算していく、ということをやっていたりします。

スプリントプランニングのポイント

あと、もう1つプランニングでやっている実装として、見積もりってみなさんされますよね。「このタスクってどのぐらいのポイントですか？」みたいなやつです。いろんな見積もりの方法もあるんですけど、我々はPlanning Poker＋Reference Taskをやっています。

Planning Pokerってめちゃめちゃ有名なので、あんまり今回はしゃべらないですけど、Reference Taskとは何かというと、これまでやったタスクとかをこんな感じで見れるんですよ。表で書いておくんですよね。

例えばインフラだったら、Terraformとかansibleとかありますけど。「そういうタスクをやったらこのぐらいのポイントになります」「アプリケーション実装してたらこのぐらいのポイントになります」とか、ぼかしちゃった部分は出せないんですけど、こんな感じで「このタスク1ポイントだったから、このタスク1ポイントだよね」みたいに効率的に見積もりをする、ということを我々はやっています。

もう1個はプロダクト・バックログの管理です。プランニングするときって必ずバックログをいじっていくじゃないですか。僕らのチームって週2回はほぼリモートしていて「同じオフィスにいない」という前提なので、みんなが普通に使っているような物理的なカンバンとかはなかなか使いづらいんですよね。

結果として、やっぱりオンラインのツールを使わなきゃいけなくて、けっこう渡り歩いてきました。

スクラム用のツールっていっぱいあるんですけど、例えばTrelloとかHuBoardとかいろいろあるんですけど、我々は最終的にTaigaというOSSのツールに落ち着いています。OSSじゃないやつもあります。

Taigaってどんな感じに見えるかというと、こんな感じですね。

左側の軸にストーリーラインみたいなものがあって、ストーリーごとに個々のタスクがあります。こんなTaigaのカンバンで我々は毎日スクラムを運用しています。

Taigaの何がいいかという宣伝なんですけど、個人的な好みをお話しすると、わかりやすいのは階層構造が簡単に作れる点です。Storyを分割していったら「このStory、全体的な流れとしてはこのTaskに紐づくよね」みたいなのが視覚的にすぐ見えるんですよね。

あと、Sprintの専用のURLを切り出せるので、「今回のSprintゴールはここに向かっています」みたいなことがチームとしてフォーカスしやすく、そういうポイントもあったりします。なので、Taigaけっこう使いやすくて、我々はTaigaを使っています。

リモートでスプリントを振り返る方法

次、これプランニングして実装していったら、「レトロスペクティブ」、振り返りです。もう聞き飽きていると思うんですけど、（我々の働き方は）リモート前提なんです。だから、よくある付箋にバーっと書いてみんなで共有するみたいなことはあんまりやってなくて。まぁ、やるときもあるんですけど、あんまりやってません。

じゃあどうするかというと、落ち着いたのがこれなんですよね。

Googleが提供しているプレゼンのツール「Google Slides」ってあるじゃないですか。これのすごくよいところがあって、例えばみんな同期的に作業できるんです。具体的にはメンバーが自分のページを用意しておいて、書いたアイデアをコピペできるんですよね。ホワイトボードに付箋をペタって貼る、みたいなイメージです。

ある別の個人ページからこの全体の共有ページみたいなところにペタって貼れるんです。そうすると、あたかも付箋を貼るかのように、かつ、オンラインでWeb会議とかつないでおけばかなり同期的にできるので、こんな感じで僕らはレトロスペクティブをやったりします。

これはタイムラインと組み合わせてやっています。時間軸がないとけっこうものごとを忘れちゃうので、そうやってKPTやっています。

KPT、みなさんもやってる人多いですよね。SkyWayのチームでもKPTやってたんですけど、KPTってやり続けてると問題が出てくるんですよ。何かというと、なんとなくProblemとかTryとかがだんだん固まってきて、「あれ、これいいProblemとかTryって出なくない？」って意見が出てくるんですよね。

そうすると鉄板のTryが出るんですよ。なんだと思いますか？　「レトロスペクティブを改善しよう」というTryが出るんですよ。これなんかネタっぽいですけど、当たり前の話で、じゃあ「新しい振り返りを試そう」という話です。いろんな手法があるので別の方法を今試しているところです。

何をやっているかというと、「タイムライン」と「555」（Triple Nickels）って言うんですけど、『アジャイルレトロスペクティブ』という本に載っている手法ですね。それを少しカスタマイズしてやっています。カスタマイズは完全に実装なので、ぜひ今回しゃべっておきたいと思っています。

アジャイルレトロスペクティブの実装

どんな実装しているかというと、まずタイムラインを作るのは共通です。

チーム全員で、これまたGoogleのSlidesに書いていきます。月曜日から金曜日まで「こんなできごとがありました」ってことをチームの行動を見ながら書いていきます。

さきほど書いていったものをベースにして考えながら、「じゃあ自分にとって重要なできごとってなんだろう？」ってことを、個人のスライドのページがあるので、そこに書いていきます。

トピックは5個ぐらいだいたいみんな書くんですけど、ちょっと秘密のものが多くて1個だけ出しておくと、これはチームビルディング合宿みたいなものです。あとでしゃべるんですけど、（こういったものが）あるんですね。「これ最高でした」ってことを、できごととして挙げています。

次のタイムボックスで、ほかのメンバーが自分の挙げたトピックに対して、どんどんコメント書いてくれるんです。

「こういうアイデアあるよね」「こういうコメントいいよね」ってどんどん増やしていくんですよね。そうすると、チーム内で相互のフィードバックがどんどん回るようなかたちになります。

最終的に、ハートマークで「投票」します。

投票して、みんなが重要だなと思ったポイントをチームでどんどん深掘りをしていきます。これは黄色でちょっと見せられないですけど、深掘りをするといろんなアクションが出てきます。

「じゃあ次のスプリントでこれやっていこうよ」と、アクションの抽出をしてやるというのが、我々が今回やっていった方式ですね。これがレトロスペクティブです。

オンラインでデイリースクラムを実施

もう1個いくと、日々の活動で必ずやるもの、デイリースクラムというのがありますよね。もうオンラインはいいですね。こんな感じでいつも朝会というWeb会議をしています。

みんなロケーションがバラバラなので、オンラインで入っています。これは自分たちのSkyWayベースの会議ツールを使っています。

オンラインでやるときには、ちょっとだけコツというかスクラムにないことをやっています。普通はスクラムってスクラムチームが集まってやりますよね。Devチームとスクラムマスタとか、そんな感じの構成でやりますよね。それのやってますが、SkyWayのチームではもう1個、別の全体の朝会をやっています。

何かというと、全チームが集まるんですよ。スクラムチーム、つまり開発チームとプロダクトオーナーだけじゃなくて、例えば、お客さんと相対しているDeveloper Relationsのメンバーとか、そういう人たちを集めてプロダクト全体のトピックの話し合うという時間を10分とか15分とか設けてやっています。トピックがない場合はすぐ終わります。

何を話すかというと、例えば、プロダクトマネージャーが「昨日ユーザーヒアリング行ってきたんですよ」と言った時に、そのユーザーの声を直で一番重要な声を伝えてくれるんですね。

そうすると開発チームにも刺さるし、プロダクトオーナー自身にも刺さって、優先度の並べ替えができたりするので、こういう話を全体のスクラム、デイリースクラムの前に話をしています。

アジャイル開発における技術について

あと2トピック「技術」と「人とチーム」の話をします。

今日はアジャイルの話をするので「技術」はちょっとだけ触れると、当たり前のことをたくさんやっています。スクラムなんですけど、XPのプラクティスをみなさんと同じくたくさん取り入れています。

テスト駆動開発、ペアプロ、あとリファクタリングとか自動テストとか継続的インテグレーションですね。こういうのを当たり前に、普通にやっています。

ポイントは、テスト駆動開発です。テスト駆動開発って勉強するの大変なんですよ。本もあるのでやったらいいんですけど、やっぱり専門家の力を借りるのがいいので、僕らはけっこうスタンドを召喚しています。

こちらは有名なt_wadaさん。

（会場笑）

スタンドを召喚するとすごい効果的。金で解決です。すいません。

あともう1個。XPじゃないけどモブプロ。今日、及部さんいらしたんですけど、及部さんも召喚できるんですよ。お金で（笑）。

（会場笑）

金で解決できます。はい。モブプロをやると、すごいチームのモチベーションが上がって、「こうやったらいいね」ってわかるじゃないですか。この写真は「僕らのチームで「やった！」というときの実際の様子です。

「技術」は、とにかく世の中のベストプラクティスをばんばん採用していきましょう。いいものは追っかけましょうということをやっています。

例えば、当たり前なんですけど、クラウドネイティブな設計ってまだわからない人っていらっしゃいますし、あとはアプリ作るんだったら12Factor Apps、 コンテナを使って作るアプリとか当たり前にやるじゃないですか。こういうのは普通に入れるというのが重要です。

ツールはこんな感じにやればいいです。参考ですけど、我々SkyWayのチームで、それなりに世の中に知見があるようなツールをバンバン使って作っているというのが実績となっています。

WebRTCプラットフォームをやると、WebRTCに限らず広い領域を、全部やらないといけない。だから、沼って言ってるんですよね。けっこう大変です（笑）。

透明性と心理的安全性をいかにして高めるか

最後に、人とチームの話をしていきたいと思っています。

切り離せないキーワードが2つあります。スクラムとかチーム開発だと、何かというと、もうみなさんわかっていますよね、スクラムの3本柱って1つが「透明性」ですよね。

あと、もう1個はタイムリーな「心理的安全性」というやつです。

最近なんかバズワードですけど、これがないとよいチームじゃないというのは、Googleのre:workとかにも書いてありますし、これは重要なんですよ。

「人と人の間の透明性」はなぜ必要か。透明性を出すためにはどうしても心理的安全性が必要で、つまり壁が低くないとしゃべれないんですよ。「この情報出していいんだっけ？」と不安になったりするじゃないですか。「この心理的安全性をどうやって高めていきますか？」っていう話です。

「心理的安全性を高めるってどうすればいいですか？」って、世の中に手法が多少あるんですけど、実はそんなに公開されてなくて。僕らのやっている手法をいくつか紹介すると、1つは「チームビルディング合宿」というやつです。

チームビルディング合宿の心得

ググるとわかるんですけど、いろんな会社さんがやっています。ただ、やり方はほとんど書いていない。それは理由があって、たぶんチームによってはぜんぜん汎用的にできない情報がいっぱいあるんですよ。だからやり方が書いてないだけであって、今日は僕らのチームの1実装を紹介するので、ぜひよかったら使ってくださいという感じです。

チームビルディング合宿とは何かというと、例えばこんな感じですね。

ふだんとぜんぜん違う場所にまず行きます。ふだんとぜんぜん違う場所というのは、例えば温泉でもいいですし、古民家でもなんでもいいですけど、そういうところへいきます。実際に我々は3回ぐらい行っています。

合宿では、チームメンバのモチベーションを共有しあいます。例えば、「なんで今この仕事しているんだっけ？」みたいなことを、自分探しみたいなことを伝え合うんですよね。そういうことをやっています。

実際にどんな様子でやっているかというと、例えば、これは秋葉原でやっているやつですけど、こんな感じでご飯を食べながらみんなでワイワイ雑談しながらやっています。

この右の上にある画面のスライドに書いてあるのは「つぎ働くならスタートアップ」って書いてあって。

（会場笑）

生々しいことをみんなでしゃべりまくって、チームメンバを理解しているんですね。このテーマは、なんか怒る人だったら怒りそうですが（笑）。

もうちょっと具体的に、他に何をやるかというと、アイスブレイク的なことはもちろんやって。「16Personalitiesテスト」というやつがあったりします。これはググれば出てくるんですけど、この人はこんな感じですというカテゴライズを16分類してくれるものをやったりします。

あとは、最近話題のやつだと、「ムービングモチベーターズ」ですね。10個のトピックを順番を並べ替えして、「私はこれが一番重要な価値観なんです」ということを並べ替えして、「この人そういうことを考えてるんだ」ということを理解するためのやつを実際にやったりしています。

転職者が出ても構わないというスタンス

あともう1つすごく重要なことは、さっきも言ったんですけど、「あなたは半年後とか1年後に何をやりたいですか？　どうやって生きていたいですか？」ということを、仕事の場なんですけど話し合うんです。

「僕はWebRTCの マニアになりたいです」という人もいるし、「僕は組織の改善したいです」ってことをやってもぜんぜんかまわなくて、その人のモチベーションを聞いた上で、やりたいことを聞いた上で、仕事とか「じゃあこれだったら業務方針を変えたほうがいいよね」ということを実際に話し合う。チームビルディング合宿で僕らは（そういう話し合いを）やっています。

あとは、決まったテーマだけでなく、後半でアンカンファレンスなどもやっています。ある程度の時間はほぼ雑談なんですよね。テーマは決めてないです。好きなことをしゃべる。

例えば、さっきも言ったんですけど「今転職したいか？」という質問やるんですよ。「スタートアップに行きたい」「別のメガベンチャーのほうがいいな」って。ちなみに「今転職したいか？」という質問をすると、何が起こると思います？

転職する人が出るんですよね。チームからマジで抜けちゃいます（笑）。

（会場笑）

「あれ？　これ、自分探しをした結果、私、このチームじゃないな」って人が1人いて、出ちゃいました。それで僕らは構わないと思っていて、やりたいことに沿ってやったほうが仕事って楽しいし、「これでいいじゃん？」ってチームでガンガン後押ししてやっていくスタイルです。

ポエムの重要性

あと、もう1つ重要なのはポエムですね。チームビルディング合宿をやる前に僕らはポエムを書いています。

僕らはQiita:Teamに契約しているので、「なんで今この会社にこのポジションで働いているんだっけ？」ということを小学校ぐらいからの掘り起こしてみんなで書いてるんですよ。「大学行ってこういう勉強しました。こういう経路で今のポジションに就きました」みたいなことをk感情や理由を含めて、書いていくと、人の価値観がすごいわかるんですよね。

これを書くのすごい時間がかかって、コストかかるんですけど、非常に重要です。なぜかというと、すごい自己開示できるので「あ、今ここであの人はこう考えているから、次は価値観でこうやって行動するだろう」という予測ができたりするためです。

実はニワタマが1個あるんです。「心理的安全性」と「自己開示」ってニワタマなんですね。

つまり、心理的安全性を確保するために自己開示するとすごい高まるんですよ。ただ一方で、自己開示をしようとするためにはやはり心理的安全性が必要なんです。怖くてしゃべれないじゃないですか。

これどうするかというと、誰かがドライブしないといけないので、僕みたいなどうでもいいやつといったらおかしいですけど、誰かが先陣を切っていくってやつですね。

もう1個ポイントがあって、書きたくない人もいらっしゃるので、そういう場合は決して強制せずに、やりたい人だけがやってチームの壁を下げていくことを僕らはやっています。

開発合宿をやる意味

チームビルディング合宿ともう1個合宿をやっています。これも鉄板ですが開発合宿というのをやっています。

これもオフサイトで必ずやっています。本来の業務のロケーションじゃなくて、別の場所に行ってやっています。たとえば伊東の山喜旅館という鉄板の場所ですね。（この写真は）ここでやっています。

ポイントがもう1個あって。開発合宿というとコードを書いてるようなイメージがあるんですけど、ビジネス的な人をどんどん入れましょう。プロダクトオーナー、さっき言ったデベロッパーリレーションとか、ぜんぜん違ってるところ。ほかのチームの営業とかをしてくれているメンバーでもぜんぜん構わず来てもらいます。

これをベースにみんなでワイワイガヤガヤ。ご飯食べる瞬間とか一緒なので、このときに自然と普段できない雑談もできたりして、深まっていきます。夜はお酒も飲みますし、すごい良いポイントです。

あと、開発テーマは僕らはけっこう自由にやっていて、本当に人によりますね。C++のBoostとかずっと読んでいる人。あとは、botをひたすら作って、開発環境を便利にしたり。あとはビジネス的な人だと、リーンキャンバスひたすら書いて議論してますとか、本当いろんなことをやっています。こういうのを自由にやっていますね。

最高のチームを作るために必要なこと

こういうことをがんばってみんなで合わせていった結果、何が起きたかというと、最初のこの図の結果になりました。

同じ組織の他のチームはプロットしていないですが、圧倒的に僕らのチームは良い結果がでました。

振り返ってみれば、「なんでこんなことできているんですか？」というと、すごい重要なことがあって、1つ目がほぼすべてではあります。

スクラムチームってステークホルダーが必ずいらっしゃいます。トップダウンでコマンドコントロールの世界で生きていると、ステークホルダーがわけわからないことをいっぱい言ってくるんですよ。スクラムチームで活動してると、透明性が増えて、チームの活動・プラクティスがどんどん外に出て見えていくので、わけわからない差し込みがいっぱい来ます。

「お前ら本当に仕事してるのか？」って言われるかもしれませんし、「お金の無駄づかいするんじゃない」みたいなことを言われるかもしれませんが、ある程度理解度のある上司とか支援者がいると、けっこうブロックしてくれます。こういう人を味方につけるのが最重要ですね。

彼らの理解度がとても重要で、とくにその人たちは権利と責任をセットでくれるから最高ですね。「ゴールはこんなものがいいです」っていうWhatに対して、上司が「それいいね」というコミットをしてくれたら、あとのやり方、howは全部任せてくれます。「自由にやっていいよ」と言われると、チームが勝手に育ちます。

最初はもちろん上手くチーム開発できてなかったんですが、僕らのチームはどんどん育っていって、すごく育った結果、今の状態になりました。なので、こういう上司たちに擁護者になってもらいましょう。

こんなこと言ってると「難しくない？」と言われますよね。

（会場笑）

「うちだと無理なんだけど」って。無理なケースはやっぱりあって、ただ、やり方はいくつかあります。

やり方は僕のPodcast(fukabori.fm)のエピソード10で「こうやったら説得できます。こうやったら説得できました」というのを紹介しているので、ぜひ興味があったら聞いてください。

ということで、今日はまとめとして、（まず）プロセスの話をしました。スクラムガイドに載っていないようなスクラムの実装を最初にしゃべりました。

（2番目の）技術の部分では、XPと組み合わせていますとか、あとは専門家を召喚するとか、そういうことをやっていましたね。

3番目、人とチームの話では、チームビルディング合宿とか開発合宿ですね。このへんを組み合わせてどんどんチームの自己開示というか安全性を高めて仕事をするということをやっていました。

ということで、僕の発表はこれでおしまいで、質問点あると思うので、あとは懇親会で聞いてください。以上です。ありがとうございました。

（会場拍手）

チームにモチベーションが低い人間が入らないようにする

司会者：ありがとうございました。少し巻いておりますので、今1人か2人ほど質問を受け付けてもよろしいでしょうか？　質問ある方、聞いてみたいなという方は？　すみません、（そちらの方に）お願いします。

質問者：合宿とかをうちの会社でもやってみたんですけど、飲んだくれて帰ってきて成果が出ていないという状況がしばらく続いていて、「どれぐらい上司の方が忍耐強く成果出るまで待ったんですかね？」という。

iwashi86：「飲んだくれて成果が出ていないという問題に対して、忍耐強くどれだけがんばったか？」という質問だと思うんですけど、幸いなことに、私のチームって意識高い人が多くて、1回目から成果が出ていたんですよ。

これ実は裏があります。ちょっとごめんなさい、どのぐらいの企業かは存じ上げないですけど、実際にはチームづくりの過程でモチベーションが高くない人もそれなりにいらっしゃるじゃないですか。

そういう場合はいろんなコントロールを使ってチームに入らないようにしています。なので、チームを作る時点ですごい考えていて、そういう人が集まっているというのが答えです。

質問者：ありがとうございます。

iwashi86：はい。

司会者：ありがとうございました。それでは、最後にもう一度拍手をお願いいたします。

（会場拍手）