ユーザーへの価値提供を追求するために。 スクラムチームの自律的な体制変化。

写真左から沼田、野村、河口

沼田 歩実（ぬまた・あゆみ）筑波大学芸術専門学群でビジュアルデザインを専攻。大学では「センスの問題」と片付けられがちなデザインに興味を持ってもらう方法を模索し、卒業制作ではノンデザイナー向け書籍を制作。新卒入社した会社でUI/UXデザイナーとしてプロダクト開発を経験。 学ぶことを一生楽しめる人を増やしたい思いと、atama plusのメンバー全員がユーザーの視点に立ちプロダクトを作る姿に感動し、2018年11月より参画。

野村 宏幸（のむら・ひろゆき）小学生から20年ほどピアノを続けながら、東京理科大学理学部を卒業。新卒入社の企業でエンジニアとして３年程経験した後、災害サービス企業にて２つの自社プロダクトのPM、スクラムマスターとして活動。 業務委託によるシステム改修等も経験した後に、atama plusのテクノロジーによる教育改革のMissionに共感しジョイン。

河口 康平（かわぐち・こうへい）大阪府出身、京都大学でアカペラにのめり込み大学をゆっくり卒業。新卒でフォルシアに入社し、MRO業界、旅行業界のシステムの営業からプロジェクトマネージメントを担当。2018年3月に営業部長に昇進した後、偶然の出会いで2018年7月にatama plusにJOIN。カスタマーサクセスを経て、プロダクトオーナーを経験後、現在は専任のスクラムマスターとして横断的な組織課題に取り組む。

過度な役割分担が生んだ、ミニウォーターフォール

― atama plusの開発体制の変遷を順を追って伺いたいのですが、まず2019年あたりの状況から教えてください。

河口：2019年5月頃、atama plusは2チーム体制（Terakoyaチーム＆Kaizenチーム）で開発を進めていました。当時はデュアルトラックアジャイルを実践する中で色々と試行錯誤していました。ソリューションアイデアの検証を中心としたディスカバリートラックと検証済みのソリューションアイデアを作り込むデリバリートラックという2つのトラックを並行して開発を進めるのですが、簡単に言えば、そのトラックの受け渡し部分がうまく機能していない状態でした。

沼田：各チーム内で、ディスカバリーした内容を共有する「ディスカバリーレビュー」の時間がどんどん膨れ上がっていました。原因は開発速度を上げるために工夫をした結果としての過度な役割分担。UX/UIデザイナーの企画した内容に対して、エンジニアからの質問が殺到し、ミーティングはいつも2〜3時間かかってしまう状況にありました。

河口：このディスカバリーレビューが実質、UX/UIデザイナー（以下デザイナー）からエンジニアへの「受け渡しミーティング」になってしまっていました。よく言われる「ミニウォーターフォール」のような状況でした。デュアルトラックアジャイルのディスカバリートラックとデリバリートラックそれぞれが、実質デザイナートラックとエンジニアトラックという職種ごとのトラックになっていたのです。2019年9月に3チーム目（Oyakataチーム）が立ち上がっても、依然として状況は変わりませんでした。新しいメンバーが増えるたびに、ミーティングの時間は伸びるばかり。「いよいよ変えなきゃいけない」と各チームが動き出したのが2019年末でした。
そして2020年の1月。プロダクトオーナーを僕から他のメンバーに引き継いで、専任のスクラムマスターとして動き始め、Oyakataチームの支援を開始しました。まずやったことは「ボランチ」という役割の提案です。

― ボランチって、あのサッカーのポジションですか？

河口：そのイメージです。チームにデザイナーが2人いたのですが、そのうちの1人が半分のリソースを使ってエンジニア側のサポートに入ってみるというチャレンジでした。ボランチは、ポルトガル語で「ハンドル」。まさに、舵取りをし、橋渡しをする役割を担ってもらうことが狙いでした。
例えばエンジニア側で「このUI挙動はどうなるんだっけ？」と疑問が出たとします。でも、デザイナー側はすでに次のディスカバリーに着手しているため時間をとることができません。まさに、その部分に入ってフォローをするのがボランチの役割です。

野村：こういった動きからデザイナー側からエンジニア側への歩みよりが生まれ、エンジニア側からデザイナー側への歩みよりも生まれました。お互いの仕事への関心をもっと持とう、という動きの機運が高まっていきました。スクラムマスターやボランチの存在が、コミュニケーションの原動力になったと思います。

河口：もともと朝会も別々にやっていましたが、次第に全て一緒にやるようにしていきました。さらには2020年3月、Oyakataチームに対して「ディスカバリーのバックログとデリバリーのバックログを統合して1つののプロダクトバックログにしませんか？」という提案もしました。そもそも、職種によって担当しているバックログが分かれていること自体が根本原因だと感じたのです。チームとして同じバックログにすることで同じ優先順位で動けるようになりとデザイナーとエンジニアが協働し始めました。

各チームにおける自律的な変化

― 他のチームの状況はどうでしたか？Oyakataチームに続く流れなどあったのでしょうか？

沼田：いえ、それとは逆に、私がいるKaizenチームでは、あえてバックログを分けるというOyakataチームと逆の選択をしました。

河口：少し補足すると、デュアルトラックアジャイルをチーム全員が深く理解できている場合は、ディスカバリーのバックログとデリバリーのバックログを分けるというプラクティスがあります。一方でバックログとともに、担当者を分けてしまうと上記のようにミニウォーターフォールが起きていしまいます。

沼田：Kaizenチームの選択は、より本質的なデュアルトラックアジャイルの追究でした。しかし課題は先ほどのOyakataチームと近いものでした。週1回の「ディスカバリーレビュー」の場で1週間やってきたことがひっくり返るんです。「この一週間やってきたことはなんだったんだ・・・」ということがよく起きていました。
そこで2019年10月ごろにKaizenチームで「ディスカバリー勉強会」を実施。書籍をベースにして互いの認識を揃えていったのですが、そこには「ディスカバーはエンジニアも入ってやるものだ」とガッツリ書いてありました。
エンジニアもデザイナーもこれまでと違うスキルを求められる難しさも感じましたが、勉強したことを1つずつ実践していきました。ディスカバリートラックで新しい発見があれば1日単位で方向性を変える決断をしたり、迷う判断についてはチーム全員で議論してみたり。この繰り返しで、少しずつ状況が改善していきました。

― チームによって意思決定が異なるのは面白いですね。

野村：そうですね、スクラムチームとして、自律的に変化することを大事にした結果ですかね。もちろん、他チームにも学びは共有しますが、一人ひとりが変化を恐れずにチャレンジするカルチャーだからできるのかもしれませんね。

― ちなみにその後、ミニウォーターフォールの状況はどのように改善されていったのでしょうか？

沼田：2020年3月に、新型コロナウイルス感染症拡大に伴う緊急事態宣言が発令されましたよね。私たちもその対応の一つとして、生徒が自宅でも授業が受講可能となる「atama＋」のWeb版を緊急で開発することになり、「受け渡しが〜」とか言っている場合じゃなくなって、はからずもチームがひとつになりましたね（笑）。そして、コロナ対応の真っ最中に、LeSS（Large-Scale Scrum）導入の検討が始まりました。

全体最適に向けてLarge-Scale Scrumを導入

― 目まぐるしいですね。なぜこのタイミングでLeSS導入に至ったのでしょうか？

河口：端的に言えば、プロダクト戦略が局所最適に陥らないためです。atama plusが対象とするユーザーには、生徒さんの他に、塾のコーチや教室長もいます。LeSS導入前までは、ユーザーごとにスクラムチームを作っていました。ただ、それぞれの体験を向上させるためには、個別に考えるだけでなく、連携した施策も必要になります。
対象ユーザーごとのチームに分けると、各チームはそれぞれの領域で最適なプロダクト戦略を作ります。ただ、atama plusの場合は、各ユーザーが使うプロダクトが密に連携し合って「生徒の学習成果を上げる」という価値を出す仕組みです。そのため、優先順位がユーザーごとの局所最適になることの課題は大きいですよね。今後人数が増えて、スクラムチームが更に増えていく前にその連携ができる体制を整えるほうがよいとの判断で、コロナ対応の真っ最中でしたが、大規模アジャイルのフレームワークである「LeSS」の導入に踏み切りました。

― 時期的なこともあって、ずいぶん大変だったのではないですか？

河口：それはもう大変でしたよ（笑）。半年前までは3チームそれぞれ2つずつ、計6つのバックログが走っていたものが、全てを統合して1つのバックログになるんですから。また当時はリモートワークに不慣れな中でのLeSS体制への移行だったので、全てが初体験でした。

沼田：5月のゴールデンウィーク明けからの運用開始の時は、なんとか形を保つことにもいっぱいいっぱいになってましたね。

河口：影響が大きかった変化は、プロダクトオーナーが一人になったことですね。LeSS導入前は各チームに1人いたプロダクトオーナーが全体で1人になったんです。

野村：前までは各チームのプロダクトオーナーが仕様について丁寧に設計していたところを、スクラムチームのメンバーが自分たちで考えて実践する必要があったので、各自が新しいスキルを身につける必要がありました。チームメンバー一人ひとりがユーザーのことを理解して、より自律的にものづくりをする必要に迫られたんですよね。

河口：さらにLeSS導入して間もない2ヶ月後には、4チーム目となるAkindoチームが立ち上がりました。それに併せてBX（Business UX）という役割も新設しました。

― BXって耳慣れない言葉ですが、どんな役割なんでしょうか？

河口：開発チームに入ってもらっている、ビジネスサイド出身のメンバーです。課題をヒアリングして構造化・整理して、プロダクトオーナーが考えるプロダクト戦略を支援したり、各チームとともに課題発見を行ったりする役割を担っています。BXの新設にともなって、ビジネスチームから1名、アプリチームに完全移籍してもらいました。

沼田：ビジネスサイド出身のBXは導入塾に対するドメイン知識があります。通常のUXデザイナーが「プロダクトでどのように解決するか」を考えるのに対して、BXは「どの課題を解決するのか？」という観点で課題選定をする役割です。

変化を恐れない、自律したチームであり続けたい

― 現在の状況はいかがでしょうか？

河口：LeSS導入から8ヶ月後には、5チーム目となるSouzouチームも立ち上がりました。この頃になると、ようやくLeSSにも慣れてきて、チーム一丸となってのディスカバリーも定着してきました。

野村：エンジニアとして一番変わったなと感じるのが、他チームへの関心が醸成されたことだと思います。ワンチームになって活用されたものの一つが「トラベラー」というプラクティスです。今までは自チームだけで完結する前提がありました。しかし、旅行者として数スプリント、他チームで経験を積むことで、例えば主に生徒向け機能のチームのメンバーが、教室長のことをより深く理解できる流れをつくることができました。

沼田：2年前と比べると、かなりフットワークが軽くなりましたよね。
今の体制になって「より価値を出せそうなものをより早く」という動きに磨きがかかってきたと思います。もっと改善していくために何ができるか、その方法を考えるのがすごく楽しい。2年前にKaizenチームのデザイナー2人でなんとかしようという世界から、プロダクトチーム50人でなんとかしようになっている。そう実感しています。

野村：まさにそうですね。僕が最初に入った頃はエンジニア5〜6人という状況でした。自分の強みを活かすというよりかは、フルスタックじゃないとついていけないところがありました。
それがワンチームになって、みんなを頼れるようになってきましたね。みんなの得意なところをそれぞれが最大限に伸ばせるようになって、気持ちの余裕も出てきました。プロダクトの進化に合わせて、「こういう視点から作った方が良い」と先を見据えた開発ができるようになってきたのです。だいぶプレッシャーが減って、健康的な開発ができるようにもなってきましたね（笑）

― 今後に向けた思いを聞かせてください。

河口： 2019年からの変遷をお伝えしたのですが、根底にある「ユーザーに価値を提供する」という思想やコンセプトは、ずっと変わっていません。その前提で、日々の試行錯誤を繰り返しながら、ちょっとずつ、目指したいものづくりのあり方へと近づいていると思っています。

沼田：今後も、特別なことをするというよりかは、今までのように失敗を繰り返していきながら、私たちなりの最適解を探っていく。これを愚直にやっていくことが、結果としてチーム全体の学びになって、今までよりユーザーへの価値を提供できるチームへとステップアップしていくと思っています。これからも変化を恐れない自律的な組織であり続けたいなって思ってます。

◆　atama plusについてもっと知りたい方はこちら！　atama plusのすべてがわかる11のイベント

その４ ：転職直後のエンジニアが、初めて機能リリースするまでの話

その５：13,000件以上の現場フィードバック？！新しい学習体験を探求し続けるUXデザイナーの仕事