CodeZine(コードジン)

特集ページ一覧

現場起点のアジャイル開発でビルドトラップを避け、組織のカルチャーにより「熱狂」を届ける【デブサミ2021】

【19-B-3】現場起点のアジャイル開発と組織のカルチャー ~ビルドトラップを避け、生徒に“熱狂”を届ける~

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/03/31 12:00

 「教育に、人に、社会に、次の可能性を。」をミッションに掲げ、AIなどの最新技術を活用したプロダクト開発を行うatama plus。そこでは「現場での学びや気づき」が重視され、ビルドトラップ(生み出された価値ではなく、機能を開発することそのものに集中してしまう状況)を避けるためのさまざまな工夫が凝らされ、多くの挑戦が行われてきた。その経緯と開発組織のカルチャーを、同社の江波拓郎氏が紹介した。

atama plus株式会社 Product Owner/Product Success 江波拓郎氏
atama plus株式会社 Product Owner/Product Success 江波拓郎氏

ビジョン先行型の開発で陥りがちな「ビルドトラップ」とは?

 予測不可能なVUCA時代を生き抜くため、「まずは子どもたちが効率的に基礎学力を習得できるようになり、それにより余った時間を『社会でいきる力』を身に付けるための学びに活用することを想定している。私たちは、それぞれに向けたプロダクトの提供を目指している」と江波氏は説明する。現在は前者の「基礎学力の効率的な習得」に集中しており、そこに該当するプロダクトが個別学習型のAI先生「atama+(アタマプラス)」だ。

 「atama+」はAIが一人ひとりの得意や苦手、進捗などの情報を収集・分析して個別の専用カリキュラムを提供するという学習塾・予備校向けのSaaS型のサービス。また、2020年7月から駿台予備校とともに開始した「オンライン模試」の分析結果と連携することで、効率的に学びを加速させる仕組みを構築した。2021年1月現在、「atama+」は全国の塾・予備校トップ100の約3割に導入され、2,100教室以上で活用されている。

「atama+」の導入塾・予備校は急拡大している
「atama+」の導入塾・予備校は急拡大している

 この「atama+」の開発環境について江波氏は、「より良いプロダクトを作る意識が組織全体に浸透していることが大きな強み」と語る。事実、Slackに投稿されるプロダクトに関するフィードバックやアイディアは年間3,000件を超え、エンジニアを含めた社内メンバー全員が導入塾を訪問し、生徒の活用状況を観察したり、ユーザーインタビューを実施したりするなど、実際にプロダクトが活用された現場を理解することがカルチャーとして根付いている。コロナ禍においても、塾の協力によりZoomで授業を中継してもらい、現場訪問の機会を作り続けている事実からも、会社がいかに現場やプロダクトを大事にしているかが伝わってくる。

 また、江波氏は「現場を最重要視していることからプロダクト・サービスのペインを発見・収集しやすくなっているのはもちろん、カスタマーサクセスの体制が充実していることにより、顧客からのフィードバックや要望が集まりやすい」と述べる。そして「プロダクト開発に直接携わるメンバーだけではなく、ビジネスチームやコーポレートチームまで含めた全員でプロダクトづくりに取り組むカルチャーによって、機能改善や新機能のアイディアが豊富に得られる。さらに、“Wow students.(生徒が熱狂する学びを。)”に向けて全力で取り組むカルチャーが醸成されているからこそ、技術的にも難易度の高いプロダクトをすばやく届けることができる」と胸を張った。

「atama+」の開発を取り巻く環境
「atama+」の開発を取り巻く環境

 こうしたビジョン先行型の開発は、ある意味とても理想的に見える。その一方で「だからこそ、『ビルドトラップ』に陥るリスクもある」と江波氏は語る。ビルドトラップとは、書籍『プロダクトマネジメント』(オライリージャパン、メリッサ・ペリー:著、吉羽龍太郎:翻訳)内で登場する言葉で、組織がアウトカム(成果)ではなく、アウトプットで成功を計測しようとして、行き詰まってしまう状況を指す。つまり、実際に生み出された価値ではなく、機能の開発とリリースに集中してしまうということだ。

 では、ビルドトラップに陥っていると具体的に何が起きるのか。江波氏は次の例を紹介した。

  • 顧客・社内外のステークホルダーの意見や要望をそのまま受け入れる。
  • 目に付いた課題をピックアップし、その解決策を考える。
  • 良さそうなアイディアを受け入れ、そのまま開発に着手する。
  • 「こうしたい・こうあるべき」に愚直に従って機能を開発する。

 「これらはいずれも『作ること・届けること』に目が向いており、実際に生み出される(であろう)価値や成果に目が向いていない」と江波氏は指摘する。

「デュアルトラックアジャイル」で潜むリスクを早期に回避

 それでは、どうすればビルドトラップを避けられるのか。江波氏はatama plusが実践する工夫とチャレンジについて次の3つを紹介した。

 まず1つ目が「デュアルトラックアジャイル」だ。「ディスカバリー(課題発見)」と「デリバリー(開発)」の両方のトラックを並行して行う開発手法であり、同社では(プロダクト)ディスカバリーを「アイディアの妥当性の検証プロセス=アイディアの構築→検証→学習→意思決定・判断」と位置付けている。無駄を減らし、組織のROIを高めることが目的だ。

 リリースしてみたものの課題解決につながらない、使われない、すなわち成果(アウトカム)につながらないのはままあること。しかし「全力」で作った後に判明することは最もコスト高な手痛い学習であり、避けたいものだ。そこで、アイディアに潜むリスク(=不確実性)を早期に発見し、成果につながらない「無駄」への投資を最小化するようにしている。

 atama plusでは、職能横断チームによるデュアルトラックアジャイルを採用している。前述の「オンライン模試」では、「紙の模試と比べて問題が見にくい・解きにくい」という最も重要な課題に対し、以下のようなアプローチでプロダクト開発を進めた。プロダクトオーナーが持っている課題解決のアイディアをそのまま実装するのではなく、まずはチームメンバー全員で手書きによるアイディア出しと各アイディアに対する評価を行い、最初に構築するプロトタイプの方針を決定した。決めた方針に従って必要最小限のプロトタイプを構築し、ユーザーテストを行ってその様子をチーム全員で観察した上で、そこからの学びをチーム全員でシェアしながらネクストアクションの意思決定を行った。とは言え、一度で実装の意思決定に至るケースはほとんどなく、プロトタイプ構築からの観察、結果と学びのシェアを何度か行うことになるという。繰り返すうちに明確なアイディアに結実し、そこで初めてデリバリーの意思決定がなされて実装フェーズへと移行していく。

職能横断チームによるデュアルトラックアジャイル
職能横断チームによるデュアルトラックアジャイル

 このアプローチにより最短距離で成果が上がり、結果的に生徒から「オンライン模試のほうが、紙の模試よりも使いやすい」との評価を得るに至ったという。江波氏は「これはあくまで一例であり、取り組む課題の内容に応じてやり方も変えていく。さまざまな方法で、アイディアの妥当性を事前に検証することが大事」と語った。

 また、プロダクトディスカバリーにおける重要ポイントとして「必要最低限のプロトタイプを用いて現場や実ユーザーでの検証を重ね、求めるアウトカムにつながるか否か、見落としているリスク(不確実性)がないかをシビアに評価することが大事。アイディアの棄却はもちろん、時には取り組む課題自体を棄却することもある」と説明した。

 そして「現場のリアルの前に、それまでの自分の仮説やこだわりを軽やかに捨て、大胆に方向変換できるしなやかさを持つ」というatama plusのカルチャーコードを紹介し、「私たちのプロダクト開発において現場のリアルは何よりも大切なもの。リアルを起点にアジャイルに開発を進めることを組織として大切にしている」と語った。

プロダクトオーナーに伴走する「BX」と「課題整理トラック」で意思決定の精度を向上

 続いて、ビルドトラップを避けるための工夫の2つ目である「BX(Business Experience)」の設定と「課題整理のトラック」について紹介された。

 事業・プロダクトの成長に伴い、開発に関する課題整理や優先順位付けのために、塾の事業や経営・ビジネスモデル、生徒や保護者について理解しなければならない水準が上がっていく。その結果、1人のプロダクトオーナーがすべての課題の依存関係や構造を含めて正しく把握・理解し、取り組む課題の選択・優先順位付けを行うことが難しくなってきたという。

 そこでプロダクトオーナーのサポート役として新たにBXという役割を新設し、それまでビジネスサイドでカスタマーサクセスや事業開発などを行ってきたメンバーがその役割を担っている。そして、その人員はプロダクトチームへの完全移籍であり、兼務でないことがポイントだ。

 これまではデュアルトラックアジャイルとして、ディスカバリーとデリバリーは並行して行われてきたが、プロダクトの課題が複雑化するにつれて、そもそもの取り組むべき課題を正しく捉え、整理・構造化する必要性が増してきていた。そこで、ディスカバリートラックの前段に「課題整理トラック」を明示的に置き、ここをBXが担っている。さらに、開発に携わる全員が課題を正しく認識し続ける重要性が高いため、BXは課題整理トラックにとどまらず、ディスカバリー・デリバリーのそれぞれのトラックで、プロダクトオーナーや開発チームに伴走してサポートを行う体制にした。

課題整理トラック(プロセス)の新設
課題整理トラック(プロセス)の新設

 「顧客観点・ビジネス観点をプロダクトオーナーおよび開発チームに持ち込むことで、プロダクトチーム全体が現場や課題の解像度を高め、理解を深めていくことを望んでいる。ここでも重要になるのは現場であり、表面的な理解や打ち手を回避し、現場で起きていることを正しく捉え、意思決定を行うため挑戦をしている」と江波氏は語った。

ビジネスとプロダクトの双方理解を深める「現場」の共有

 そして江波氏は、3つ目の「ビジネスチームとの共通理解を醸成するための工夫」について紹介。そもそも「ステークホルダーの意見や要望をそのまま受け入れる」ことはビルドトラップのリスクがあるとは言え、決して無視や軽視すべきものではない。プロダクトチームはそれらを正しく咀嚼し、意思決定する必要がある。江波氏は「ビジネス対プロダクトの構造を作らないことが大切」と述べ、「そのためにはビジネスチームによるプロダクト理解と、プロダクトチームによるビジネス理解の両方が不可欠」と語った。

 同社はビジネスチーム(コーポレートを含む全社員)がプロダクト理解をし続けるために、週に1回、全社でプロダクトを理解する時間を取り、新規開発・改善した機能紹介、それぞれの開発背景、ディスカバー結果の共有などを行っている。「触っておいて」「資料を見ておいて」ではなく、全員が同じ場で実際のプロダクトを見ながら共有することを大事にしているという。さらに入社時には、職種問わずプロダクト体験・研修はもちろん、プロダクトに実装されたアルゴリズムの説明も含め、プロダクト関連だけで10時間以上の入社研修を行い、全社員がプロダクトを深く理解する取り組みに力を入れている。

 プロダクトチームによるビジネス理解については、まずビジネスチームが感じている課題感を、テキストではなく「生の声」で伝える場が高頻度で開催されている。またビジネスチームで行っているカスタマーサクセス事例・ナレッジの共有会にはプロダクトチームも参加しており、さらにビジネスチームが塾と行うミーティング、ヒアリングにプロダクトチームが同席することも推奨している。

 江波氏は「同じ現場・場面を見て、同じ景色・時間を共有することが大切。プロダクトチームがビジネスチームと共通理解を持つことで、フィードバックや要望の背後にある課題を正しく理解できるようになる」とその効果を語った。

表面的なメソッド導入だけではNG! ミッションに熱狂しチャレンジに貪欲な組織カルチャーを醸成

 江波氏は、こうした取り組みの最たる土台は「組織のカルチャー」だと話す。実際、これがないままに、表面的なメソッドや取り組みを取り入れても、根付かせることは難しい。カルチャーレベルでそうした取り組みを推奨することが不可欠だ。

 そして「私たちが何よりも大切にしているのは“Wow students.”を提供すること。これがミッションを実現する一番の近道だということを全員が理解している」と語り、ほかにも大切にしている3つの行動である“Think beyond(常識は、さておき。)” “Speak up(話そう、とことん。)” “Love fun(楽しくなくっちゃ。)”を紹介した。この3つを体現するために必要なことは、精緻に言語化した「カルチャーコード」として共有されており、組織全員の意識がそろっていることが、さまざまな施策を有効化する土台となっていることがよくわかる。

大切にしているカルチャーコード
大切にしているカルチャーコード

 江波氏は「まだミッション実現の途中」としながらも、表れている成果として、成績向上の実例や、生徒たちが楽しみながら学んでいる声などを紹介。そして新しい挑戦として、あしなが育英会への「atama+」の無償提供や、立命館との「新しい高大接続と入試の在り方を考える共同研究会」の立ち上げなどを紹介し、「ミッションの実現に向けて走り始めたばかりで、やりたいこと・やれることがたくさんあるので、チャレンジの速度を上げたい」と語り、まとめの言葉とした。

関連リンク

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5