エウレカ CTO 梶原成親氏のLTがスタート
梶原成親氏（以下、梶原）：こんにちは。よろしくお願いします。エウレカCTO Officeで責任者をさせていただいております。
自分はエウレカでアジャイルコーチの人と一緒にチームビルディングをしたり、エンジニアのリクルーティングをしたり、採用広報をしたり、ちょっとマルチなポジションでやらせていただいております。
『Pairs』を使ったことがある人はいますでしょうか？
（会場挙手）
知っているという方は？
（会場挙手）
あ、けっこう知ってらっしゃいますね。ありがとうございます。Pairsはオンラインマッチングデーティングサービスです。オンラインで知り合ってデートするまでの価値を提供しているサービスです。
自己組織化したチームとはなにか
価値を提供するために最も良い手段はなにかと考えたときに、私たちエウレカは、すべてのチームが「自己組織化されたチーム」になることを目指しています。ユーザーに素晴らしい価値を提供するために、自分たちで考えられるチームになれればいいかなと考えています。
みなさんはチームを引っ張っていく立場の人たちなのでわかるかなと思うんですが、（スライドを指して）この絵を見て、この人に「今なにをしていますか？」と聞いたときに、ただ「レンガを積んでいます」という人がいます。また、「レンガを積むことで仕事になって、これで家族を養っていける」という目的の人、「このレンガを積むことによって教会が建ち、その協会の中で信仰が守られてみなさんの生活を豊かにすることができる」という目的を持っている人もいます。
レンガを積むという1つの仕事ですが、それぞれが積み上げたあとのクオリティには決定的な差が出るのは明白です。
いわゆるエラスティックリーダーシップにおけるチームのモードから解釈しているんですが、そもそも自己組織化されたチームとは、チームにスキルがある状態、もしくはチーム自身がチームに必要なスキルを定義して、獲得する方法を知っている状態であったりするかと思います。
チームに対して、リーダーは生産性に関与しない。自分たちで意思決定ができる。衝突を内部で解決できる能力を持つチームを多く作っていく。そういったことが必要だと考えています。
自分たちで判断できる範囲と、エスカレが必要な範囲の理解が重要
自己組織化されたチームが必要な理由として、私たちが作っているソフトウェアが経営に与える影響が年々大きくなっているのは、みなさんもご認識いただいている通りかなと思っています。
コンペティターもいるし、ユーザーの影響や、ユーザーからのフィードバック、ソフトウェアの出来によってその会社が伸びるとか、もしくはシュリンクしていくというのが明白な状況になっている。そういったなかで、現場で判断して問題や課題を解決することによって、早いサイクルで改善できるようになることが本当に重要だと思っています。
仲が良いチームはそれはそれで素晴らしいことですが、チームの中でちゃんと厳しい指摘をフィードバックしあったりすると、関係性がもっと良いかたちになるのではないでしょうか。最も大事なのはユーザーに価値を提供することなので、そのためにできることをフィードバックしあえるような関係性にならないと、強いチームにはならないと考えています。
もう1つは、チームの中で解決していくと裁量化が進んですごく早くなるんですが、大事なところをちゃんとエスカレーションできないというのは大きな問題になってくるということです。「自分たちで決められる範囲」「自分たちで判断する範囲」と「エスカレーションして指示を仰ぐ部分」をちゃんと理解すれば、判断待ちを最小にすることができるのではないかなと思っています。
自分たちで判断しなければならない範囲も全部エスカレーションしていたら、判断待ちや、確認待ちになってしまうので、そういうのを避けていきたいと考えています。
（スライドを指して）これは、Pairsで実際に結婚したり、交際が始まったりしたみなさんのポスターです。最初のレンガの話でもないんですが、僕たちは、価値を提供することによって出会ったり、子どもができたり、家族になったり、結婚したりということで、その人の人生にすごく大きな価値を与えることができるんだということを常に意識しなければいけないと思っています。
前置きで5分終わってしまいました。要は「僕たちが価値を提供するのが1日遅れたら、それを待っている人が1日待っているんだ」ということをよく理解してもらう、ということを念頭に置いていました。
4つのレベルで考える自己組織化のステップ
ここから本題になるんですが（笑）。自己組織化へのステップということで、まずは「課題を見える化する」「一緒に課題解決する経験をする」「チーム自身で課題を解決する」「チームで意思決定するのが習慣化する」という4つのレベルを置き、私たちコーチが関与するのは、「一緒に課題解決する経験をする」までとしていました。
なにをしたかと言うと、チームのプロセスを改善するために、1つのオペレーションの中で振り返って「僕たちうまくやれているんだっけ？」というのを確認するような振り返り会を持つようにしました。
振り返りの終わりに、例えばプロジェクトのゴールがあって、いつまでにリリースしなければいけないというときには「俺たちうまくやれているんだっけ？」というように、リリースまでにちゃんとできるかどうかをファイブフィンガーで確認するようにしています。
ファイブフィンガーを使うことによって、小さい感情の動きもそこでキャッチできるようになるんですよね。3とか2とか出していたら「なんで2なの？」「いや、こういうところが気になっているんです」という対話のきっかけになっています。
KPTにプラスして、改善に至った条件の計測を行なう
（スライドを指して）妨害リストというものがありまして、チームのプロセスを阻害しているものをリスト化することによって、そのプロセスを改善していくようになっています。
プロセスの振り返り会について話をしたいなと思います。例えばあるオペレーションの振り返りで、プロダクトバックログがReadyになっていない状態を改善した例です。（スライドを指して）これはホワイトボードの写真なんですが、Fact、仮説、解決策、計測方法を定義してみました。
事実を書き出して、意見を募って、ソリューションを定義します。ここらへんはKPTでもよくあるんですけど、プラス改善された条件を計測するのが大事なんですよね。
思い込みとか想いが先行して、「結局それってどうなったら改善してるの？」というのがわからないままトライしてしまう。大事な時間をそんなことに使ってしまうとふわっとして終わってしまうので、改善がちゃんと終わった条件を最初に定義して決めるというのを大事にしました。
結局ソリューションをいくつもやっていてもダメなので、そこもファイブフィンガーでこれをやりたいという人が多いやつをやったり、想いが強いやつに限って一つずつ改善したり、というようなことを一緒にやっていました。
振り返り会で得られた学びと実感
変わったこととして、ペアプロ（ペアプログラミング）とかペアワークというかたちで、属人性の解消を始めています。（スライドを指して）これはiOSのエンジニアとフロントエンドのエンジニアがペアワークしているところなんですが、役割もクロスファンクショナルになって、例えばiOSの仕事が滞ったとき、奥の彼がiOSの仕事を助けるとか、そういうことができるようになったりします。
フェーズごとに完了の定義があいまいだったので、品質を一定にするために完了の定義を明確にしました。トラブルになったことを未然に防ぐために、リリースが終わるときにはちゃんとカスタマーケアに共有できていることとか、1つずつ定義しています。
振り返り会から出てくる学びとしては、ユーザーが求めていることを知るために、「ユーザーに価値を提供するために困っていることがあったらみんなで片付けようぜ」というように、エンジニアであったとしてもユーザーのことをもっと知ろうということです。
例えば、ユーザー・ストーリーを検証するためのバックログを積んで、完全に稼働をかけて作り切る前に「これが本当に正しいんだっけ？」という確認をしてから作ろうとか、そういうかたちで1つひとつ変わっていきました。
「変わって良くなった」という成功体験によって、チームを自分のチームごととして捉えることができるようになってきています。例えば、仕様どおりに開発していたチームがユーザー価値に基づいて、「もっとよいユーザー価値にするにはどうしたらいいんだっけ？」というような話をするようになったりするんですね。
チーム全員でチームのプロセスをどうやって改善するのかを考えるようになったり。チームの問題に対して、よく「上司が……」と言う子がいるんですが、これによってチームの問題として捉えることができるようになりました。
どうもありがとうございました。
（会場拍手）
