「視座を上げてユーザーと向き合いたい」そのきっかけとなった現場コーチ(前編)

お客さまインタビュー：株式会社エウレカ 梶原様・丹様

開発現場でどのように現場コーチ中村は受け入れられたのか。現場コーチ導入の下地のつくり方から、社内スクラムマスターの育成などについて、エウレカの梶原様、丹様にうかがいました。
(肩書き、状況などは2017年8月24日当時のものです)

アジャイルな開発を正しく始めるために

梶原様(以下敬称略)：もともと楽天でアジャイル開発を進めていましたが、次の会社は ウォーターフォール開発でした。あまり良くないウォーターフォールでは自分に割り振られた限られた範囲の仕事しかしなくなりがちです。そのため、お互いの認識を合わすことなく進ん でしまい、最後に結合した時にその認識の違いから大変なことになる。何より一番大事だと私 が思う”ユーザーの価値”について語ることがなかった。そういうアジャイルとウォーターフォー ルの差を実感してからエウレカにきました。 エウレカのサービスは、男女が出会って結婚して……という本当に真面目な社会的意義性が高い マッチングサービスなので、多くのユーザに素晴らしい体験をしてもらいたくて、素早く価値を届けてあげたいと思っていました。

丹様(以下敬称略)：当時「もっと早く開発できるのに」とか「もっと助け合うチームとして
活動したい」と思っていた。そんな中で、リーダーになったタイミングで梶原さんと相談しました。
スクラムは前から知っていて、導入したいと思った時もあったのですが、なんとなくチームに反対されてそのままになっていました。今思えば、入社してすぐだったので信頼貯金があまりなかったからかもしれないですね。

梶原：僕がエウレカに入った時には、”チームで動く”概念があまりない感じがした。だから 「ユーザに早く価値を届けるためにはチーム力が必要だ」といったことを社内で発信したりしました。そのためには、自己組織化された強いチームが必要だと考えました。そういったチームをつくるには、アジャイルやスクラムの方法を取り入れるべきだと思ったわけです。
なぜアジャイルなのかは、ぜひ「アジャイル開発宣言」や、その背後にある原則を読んで頂くと理解できるかと思います。
組織の中で開発プロセスを変更すること、アジャイルに変更するのはとても簡単な作業ではありません。
チームの中に入っていって一緒に伴走する存在がいないとアジャイルの土台ってうまくできないと考えています。
自分の仕事もある中で僕がひとりで開発チームをサポートすると100%コミットした状態でチームと一緒に走ってあげられない。ふりかえりだけといったあるプラクティスだけをやるとか、スクラムイベントを価値も意味もわからずやるとかだと本質に辿り着かない。そこで「自分でやるなら今のアサインを外してもらう。それか、外部の人を入れてアジャイルな開発を正しく始めていくか、どっちにしましょう」みたいな会話をしました。

－ご自身が伴走者になるか、伴走者をどこかから連れてくるか、ですね。

梶原：お互い同じゴールと同じ価値観を共有していることで、得意領域を生かし弱点を互いに補完し合えるようないいチームになるんですよね。
スクラムはふりかえりがあって、計画をして、短い期間でやってみて、またふりかえるというのを繰り返していくことで、うまく作ることにフォーカスを当てられるフレームワークだと思っています。だから正しくやらないとダメ。アジャイルをやるなら、コーチを入れて正しくやりたいというのが相談した始まりでした。

中村：梶原さんのことは前から知っていたので、相談を受けたときにシンプルに助けてあげたいという想いがありました。

梶原：もともと僕と洋さんは、同じアジャイルのコミュニティで顔見知りで、相談をしたり
「こういう時どうしたらいいの?」みたいな感じで教えてもらったりしていたんですよ。

チーム内で会話が増えた

中村：現場によって課題はもちろん違いますが、その状況も違っています。課題そのものが見えてないこともあれば、見えているが共通認識をつくれていないこともある。
エウレカさんは、課題がある程度見えている状況だったと思います。その見えている課題に対しての原因、真因、解決策をすり合わせることがあまり得意ではない感じでした。

丹：当初はチームで話し合う習慣もなく、隣の人が何をやっているかわからなかった。そこへ継続的なふりかえりを取り入れて「これがうまくいかなかったから次はこうしよう」といった意見をチームで出しあうことから取り組み始めました。そうやってチームが抱えている課題をひとつずつ潰して、チームのやり方を改善できて仕事がやりやすくなっていった。
こんな風にチームで助け合うということができていきました。

梶原：スクラムでは、見積りも誰か一人が見積もるのではなくお互いの認識をすり合わせるようなやり方をします。例えば、サーバーサイドが得意なメンバーが「APIはこういう風につくるつもりだ」と言うと、アプリのメンバーが「そこのAPIをこういうつくり方にしてくれたらすごく楽 なんだけど」といった会話が頻繁にできるようになったんですよ。会話でちょっとずつ認識を揃えることが大事という価値観やユーザーの価値に対して一緒に作っていくといった気持ちに変化が起きた感じがすごくしました。

うやむやにしない、転んで気付くことも大切

中村：丹さんのふるまいを見てて関心するのが、チームがなんとなくはっきりせずにうやむやな感じで動き出そうとする時、ちゃんと踏みとどまって考えることを促していることです。

丹：チームとして向き合って、次のアクションをどうするか決めていかないと改善しないのて、特に注意しているところです。うやむやにならずに踏みとどまるのは、僕がスクラム経験があるからかもしれないですね。 チームがどれだけできるかというベロシティを無視して、スプリントに詰め込みすぎてダメ だった、ということを何回も経験してるし、その時の傾向も知っている。だから「うまくいかなそうだな」ってときは、はっきり言うか、もしくは逆にそのまま進んで、うまくいかないという体験を積んでもらうかしてますね。

中村：丹さんが「これはチームが経験した方がいい」とか、「これは自分が最初に入った方がいい」とかうまくやられていることもあって最近では丹さんのチームに関わることは減っていますね。

丹:人って言われただけだと聞かない。でも自分で経験したことって身に染みるじゃないですか。だから「本当に人間関係悪くなる」といったすごい失敗はないですが、すり傷ぐらいだったら、あえてうまくいかなかったことからなにか気づけることがあるだろうって、中村さんとも話しています。

中村：最初の頃に比べると「うまくいかないことを恐れずに、まず試してみよう」という雰囲気は増えていますね。以前はミーティングでも、やってみないとわからないことをああでもないこうでもないと推測で話すようなムダな会話も多くありました。

今は「どういうやり方なら素早く知りたいことがわかるか」みたいな種類の議論がちょっとずつ出始めてて自分たちのやり方の中で実験をしようとしている。それがそのうちプロダクトに対しても実験できるようになると、もっともっと良くなると思ってます。

梶原：実験してみないとわからないものがある。延々議論するよりも、まずはやってみて、実体験をもとに測定をしてみるのも大事なので、そういう意味での”失敗”は歓迎しています。「最終ゴールに向けての大事なつまずき」と思えば失敗じゃない。得た学びを活かして、さらに良いものをつくるための実験だと考えるようにして欲しいし、みんなの認識がちょっとずつそちらに向いていってると思います。

メンバー同士の対立ではなく、「問題」対「メンバー」

梶原：洋さんに入ってもらってから、経営層から「問題が見えるようになった」と、すごく言われますね。見えるようになったからか心配もしてるけど(笑)。

中村：スクラムはうまくいっていないこと、このままではうまくいかないことといった状態をできるだけ早く明らかにするフレームワークです。これまで見えていなかった課題が一度に出てきたように見える時期がある。事情を知らないステークホルダーは「あれもこれも問題がいっぱいだけど、どういうこと?」と焦るわけです。見えていかっただけて、以前から゙存在していたものが見えるようになっただけなんですけどね。

梶原：そういう、チームがうまくやることを阻害するような問題をどんどん登録をしていく「妨害リスト」というのがあります。その妨害リストにある課題をみんなで見て話す。課題と人が密接に関係していると、その人を責めたり、人同士の対立になりがちです。
妨害リストはそれを「問題と私たち」という構図にする。どこかのチームのプロセスが良くなかったらそれを妨害リストに入れて、コーチと僕と偉い人で課題に対して向き合う話ができるようになってきたと感じます。

小さくはじめて大きく広げた

中村：外から見てエウレカさんには、丹さん、梶原さんなど「うまくやりたい」という志がある人がちゃんといる。そういう現場の場合、タイミング良くちょっと外から背中を押すとグッと動いて、うまく回り出すことが多いと感じています。
中にそういった人がいなくて外から働きかけるだけの場合、コーチがいなくなったときに元の状態に戻ってしまう。
逆に内部だけだと、さっき丹さんの話のようになかなか聞いてもらえない場合や、梶原さんのように自分の仕事もありリソースが足りない場合もある。
外側のリソースであるコーチをうまく使って加速させて離陸できれ゙ば、後は自分達でうまくやれるパターンだと思っていました。

－「今までのやり方の方が良い」みたいな声はありましたか?

梶原：なかったですね。まずは当時の丹さんの開発チーム6人だけの振り返りから、とごく小さく始めたんですよ。

中村：複数の開発チームがある現場で、いきなり複数チームを一気に見るのは難しいです。
チームによって課題が違いますし、コーチも観察が足りず表面的な関わり方になってしまいます。

その点、梶原さんの「ひとつのチームがうまくやれるようになってから周りに広げていこう」という作戦は良かったと思います。丹さんも「うまくやりたい」という思いが強かったので、二人三脚でスタートできた。コーチにとっては、この現場の特徴を知る時間にもなりましたし、それが今の形にも繋がっていると思います。

－現場コーチが入って、予想外だったことってありますか?

梶原：大枠は作戦通りという感じです(笑)。ただ想定してたより全社にアジャイルな考え方やスクラムの導入が始まるのが早かった印象があります。それは、最初のチームがいい結果を出せたっていうのと、アジャイルを知ってもらうためのワークショップを洋さんに何度かやってもらったことも関係あるかと。

中村：紙飛行機ワークショップですね。

梶原：スクラムの疑似体験するワークショップに紙飛行機を使ったものがあります。紙飛行機をつくって飛ばして、計測して、もう少し飛ばすにはどうすればいいんだろうと振り返る、というのを繰り返す。 このワークショップにほとんどのメンバーが参加してくれ、90%くらいが「すごく良い」という評価でした。楽しそうな感想や「勉強になりました」みたいなフィードバックをみんなに見せ、誰でも聞ける、見れる、体験できる状況にしていました。 透明性を高くして「アジャイルをするとこういう風になるんだ」というイメージを持ってもらいやすくしたのが特徴かなと思っています。

中村：梶原さんにはアジャイルの知識も経験もあり、さらに「今の現場の状況にはこういう風に適用したらいいんじゃないか」っていう青写真もあったので、二人で相談しながら進めていく形がスムーズにできました。
例えば、あるチームに足りない知識がある場合、いきなり「本を読んでやってみよう」では難しいので、まずはミーティングに一緒に出てアドバイスしたり、体験できるワークショップから入るといった手段を使い分けながらやれたのはよかった。

梶原：二人で話して優先順位つけて「こういう順番でこういう風にやっていこう」みたいな感じだった。
あと、スクラムでは透明性はすごく大事な原則です。僕がそれをやらないと、説得力ないじゃないですか。だから僕のやるプロジェクトはみんな見れるし、みんな参加できる、というのはすごく意識してます。
メンバーを信頼して、正しい情報を透明性高くちゃんと伝えると、自律的に動くんですよね。
自分達はうまくできてないことを隣のチームはうまくやってるということも見えるようになる。「良くしたい」という気持ちもさらに強くなり、自律的に動くようになる。
こうなると、やらされてる感よりもやっている感が強くなる。やっている感が強くなると人って幸せになるんですよ。自分で決めて自分でやってるので、何もストレスがない。みんなを早くそういう風にしたいなと思っています。

丹：僕は自律的なチームをつくりたいってずっと思ってて、そういうところがすごくモチベーションになるかなと。

梶原：開発のgood(いいところ)とmore(もうちょっとのところ)を書いていくと、同じよう な課題がいくつか出てきた。開発チームがチームになってない、個人作業が多い、ふりかえりの習慣ができてないからうまくつくれない、リリース管理ができてない、プロダクトオーナーがいない…それらをひとつずつスクラムのやり方にはめていったらどうなるか、少しずつ検査と適応をしていきました。すると、毎日書いている日報にすごくいいコメントが増えてきた。「ユーザーが何を求めているか知りたいから営業に同行してみたい」「なぜ困ってるのかもっと明確にヒアリングして一緒に解決策を決めたい」「言われたものだけつくっていると価値が提供できないことがあったんだ」とか、いい感じの雰囲気がちょっとずつ蓄積されて、視点が変わってきた。僕はしめしめと思って見ていました。 やがて最初の丹さんのチームがうまくまわりだして、そこから全体で変えようとなってきたんですね。

－開発のスピード、中身はかなり上がってきたんですか?

丹：チームの体制が少し変わったりしていますが、今回発足したPairsのチームは徐々に上がっています。

中村：今は複数のチームと関わっていますが、どのチームも他責にしない癖はすごく良いなと思ってます。
例えば、必要な画像が他のチームや外部から予定通りに届かなかった時、「あれが予定通りに来なかったからできなかった」と言いがちですが、エウレカさんでは「来なかった事実を受け止めた上で、自分達は何かできたんじゃないか」と考える習慣が付いている人が多いと思います。「次同じようなシーンではどうするか」という話がしやすい。
行きすぎると自分側にすべての責任があると思ってしまうので裏表なんですが、愚痴を言わないのはすごく良いですね。

現場コーチを順調に導入し、社内に広めたエウレカ。学びをどのように深め、視座を上げていくのか、現在の取り組みについては後編でお伝えします。