スタディストでは、よりお客さまに価値を届けていくために、ビジネスと開発の連携を強めるため複数の施策を回しています。
その一環として、ビジネス側で発見したお客さまのプロダクトに対する要望を、すぐに実装できるようにする仕組み「ゴキゲン超特急」を運用しています。
これは、毎週4時間で、既存の開発ラインに乗っていない細かな改善要望 (ただし必ず出せば価値になるもの) を、数名のメンバーで企画・デザイン・実装・検証・オンラインマニュアルの更新まで進めてリリースしていく時間のことを指します。
なぜこのような施策を始めたのか、どのように運用しているのか、変遷をまとめてみます。
グロース期に差し掛かったプロダクトでは、開発ラインも複数走り、それぞれが優先度にしたがって開発を進めています。
そこに新しい施策を挟み込むのは難しいというのが実態です。特にユーザー影響のある施策だと関係者も多くなりがちで、すぐに実装するとは言いづらい傾向があります。
スタディストでも同様に、カスタマーサポート (以下、CS) 担当が聞いてきたお客さまの要望をすぐに解消できない状況に陥っていました。
「ゴキゲン超特急」を始めたのは、当時 Teachme BizのCSを担当していた遠藤の悩みがきっかけです。当時の悩みをリアルに振り返ってみます。
Teachme BizのCSは、お客さまから日々たくさんのプロダクトへの要望をいただいています。CSチームでは、いただいた要望の掘り下げまで行うようにしていたので、まだプロダクトでは実装されていないが必要そうな施策の仮説がどんどん溜まっている状態でした。
その中には、案件としては小さいけど、解決するとお客さまが必ず今より便利にプロダクトを使えるようになるものもあります。例えば「プロダクト上の？アイコンが何を指しているのかわからない」というような声です。(現在は解決済み)
スタディストでは、お客さまからいただいた声を、要件を具体化して共有する「要望回収フォーム」がかなり前から運用されています。ただ、このフォームに入れてみるだけでは、機能としてすぐに実装されていませんでした。
CS担当である遠藤としては、実装を進められない理由があることは分かりつつ、「何を解消したら検討が進みやすくなるのか」が分かっていない状態でした。
CSの遠藤は、このような状況を乗り越えるために「こんな声をもらっているんですが、すぐ改善するのは難しいですかね？」と開発メンバーに相談してみるアクションから始めてみました。
スタディストには、毎週決まった時間に開発メンバーに何でも質問・相談ができる「オフィスアワー」という制度があります。ここに遠藤から「このような要望をもらったんだけど、すぐに対応することって難しいでしょうか？」と相談を持ち込みます。
そこで開発メンバーから「良さそう」「ゴキゲンチャレンジに持ち込んでみたら？」という声をもらいます。
ゴキゲンチャレンジとは、スタディストの開発本部で運用されている「業務時間の10%（週4時間）をスタディストの事業・組織のためにやるべきと個人が信じることに時間を使える権利」です。「個人がやるべきと信じること=自身がゴキゲンになれることにチャレンジできる制度」のことを指します。
遠藤は手始めに、ゴキゲンチャレンジの場に「こんな課題で困っている人がいます」「一緒に改善を進めてくれる人はいませんか？」と呼びかけてみました。
しかし、一緒に改善を進める人がうまく集まらず、頓挫してしまいます。
その状況を見ていた現リサーチ&デザイン室の室長である磯野から、ある提案を持ちかけます。
「ゴキゲン超特急」の説明の前に、なぜこのように小さな改善が進みづらくなるのか？についても補足しておきます。
その要因の一つは、顧客に影響がある施策についてはエンジニア一人が手を上げてもリリースまで持っていくのが難しいということです。
デザイナーや開発メンバーも、要望はもちろん認識しています。ただ少しでもユーザーに影響がある機能要望に細かく対応していると、より大きな価値になる機能実装が進まなくなってしまいます。
そのため元々スタディストでは、顧客に影響がある施策は、開発ロードマップをもとに進めています。そのような丁寧に引かれた開発ロードマップにどう差し込むのかが検討しづらいのが実態でした。
しかしこのままでは、ユーザーに不便や不満を感じさせる部分を放置してしまうことになります。
CSはお客さまと日々直接やり取りをしていて「あの施策改善どうなりましたか？」と聞かれることもあるはずです。このような状況が続けば続くほど、ビジネスサイドからも「どうせ要望をあげても、解消されないし…」と要望があがりづらい状態が生まれてしまうことも予想できました。
そのため、小さくともユーザーに影響がある部分を放置しないために、より速く改善につなげられないか？ということを改めて考える必要がありました。
このような背景で実施開始したのが「ゴキゲン超特急」です。
「ゴキゲン超特急」は、顧客に価値を届け切ることを目的に、4時間のゴキゲンチャレンジの中で、企画・デザイン・実装・検証・オンラインマニュアルの更新・リリースまでを進めるような取り組みです。
ここからは、実験的に始めた導入期から、運用期、体制化期と進めてきた「ゴキゲン超特急」の仕組みづくりを時系列でまとめていきます。
取り組みに際して、ヒントにしたのが、freeeさんが公開されていたこちらの記事です。
最初の開催は2023年4月です。
遠藤と磯野がこの活動について初めて話したのが月曜日、そこから座組を整理し、メンバーを集め、その週の金曜日には第一回の「ゴキゲン超特急」を開催しました。(まさに超特急。)
さらに、奇跡的に初回はうまくリリースまで持っていくことができました。
そこからも毎週のゴキゲンチャレンジで、「4時間内で、少しでもお客さまに価値になるものをリリースする」という取り組みを継続していきます。
導入期は、まずは進め方を模索することが大きなテーマでした。
デザイナーやエンジニア、CSメンバーなど、さまざまな役割の人が関わるので、そもそもどういう流れでプロダクトの改善施策がリリースされるのかを全員が理解していく必要もあります。また、4時間という短いスパンで企画〜リリースまで持っていくにはどのような運用が必要かも探る必要がありました。
この時期に主に考えていたのは以下のような点です。
どうすれば4時間の進行をうまく行えるのか
誰を巻き込めば良いか
事前に何を決めておけば進められるのか
毎週のゴキゲンチャレンジで模索する中で、少しずつ型が見えてきました。
一つのポイントは、固定の主要メンバーで回してみることです。そもそも進行が型化されていない状態だったので、同じメンバーで回していく中で知見を磨いていく必要がありました。
他に分かったことは、複数職種が同じアジェンダに取り組んでいく方が良いということです。
例えば、要件としてまとまる前に、短い時間でうまく進めるためにエンジニアがコードから書き始めてしまうと、結局後から手戻りが発生することが起こりました。
そういった手戻りを防ぐため、まずは全員で変更内容を議論し理解するようにしました。
具体的には実際にコード上のロジック変更内容まで日本語で記述し、全員が内容を理解できるようにします。その後に並行してデザイン、実装、テスト設計、オンラインマニュアルの変更を行い、最後に全員でテストするという形に改善していきました。
このような進行の流れを、最終的には時間割のような形に落とし込んでいます。
また、事前に要件をまとめておく運用の工夫も始めます。4時間という短い時間でリリースまで持っていくには、最初に要件を整理しておくことが必須でした。
CSの遠藤が、お客さまから掘り下げてきた要望を「ゴキゲン超特急」の時間の前に整理しておき、それを超特急の場に持ち込みます。
運用方法が見えてきたところで、論点は「よりユーザーへの影響度が高い改善を、4時間でリリースするためには？」というポイントに移ります。
ここでは、以下の2つの課題解決に取り組みました。
より良い案件出しの工夫
案件によって最適なメンバーをアサイン
初めの頃はどうせならば、この4時間で扱う案件は「より顧客影響度が高いもの」としたいと考えて、インパクトがありそうな要望を選ぶようにしていました。
ただ、そうすると逆に、4時間という時間の中でリリースまで至らずに、次回に持ち越し、となってしまうことも起こってしまいます。
「ゴキゲン超特急」はあくまで、短時間でリリースすることに重きを置いており、何週もかけてリリースするとなると既存の開発ラインと変わらない仕組みになってしまいます。そうすると「自身がゴキゲンになれることにチャレンジできる制度」という定義からは外れてしまうので、4時間でリリースできないかということに出来るだけこだわりたいなと思っていました。
そこで「顧客影響度が高い」かつ「4時間でリリースできる」という条件が揃った施策を選ぶことに時間を使うようになりました。(この時期は、CSの遠藤が主導しているので、この辺りの肌感を持つのに苦労しました。)
より顧客影響度の高い施策を扱おうと思うと、案件によってはメンバー編成を変えた方が良いものもあることが分かってきました。
そこで、その週の「ゴキゲン超特急」で扱う案件を決めた後に、最適なメンバーをアサインできるように、定常的に開発本部のメンバーと仲間集めのコミュニケーションを行うことにも時間をかけていました。
例えば、具体的な案件候補を先に示しておいて、参加したいメンバーを募ってみたり。
また、経験豊富なエンジニアとのモブワークができる機会 (成長機会) として訴求してみたりと、自発的に参加したいメンバーをあの手この手で集めることに奮闘しました。
2024年3月、遠藤がカスタマーサクセス部に異動することとなり、一瞬「ゴキゲン超特急の運用どうする？」という状態になりました。
ただ、開発本部のエンジニアや、ビジネスサイドのメンバーからも「続けたい」「続けてほしい」という声が多くあがり、初期から超特急メンバーとして活動していたリサーチ&デザイン室の武波が運営を引き継ぐことになります。
この段階で「ゴキゲン超特急」の運用はすでに最適化され始めていたので、武波体制では、体制化を進めていくことに注力します。
運用期の課題を引き継ぎつつ、「ビジネスサイドとの連携を強める」ことに「ゴキゲン超特急」を活用することを新たにテーマとしました。
ここからは武波体制になってからアップデートした、現在の「ゴキゲン超特急」の運用について詳細にまとめます。
まず「必ずリリースされるサイズの案件に落とし込むような運用」をより徹底していくことに取り組みました。
「やりたいこと」を一覧化しておき、時たま「ゴキゲン超特急」の中で、「出発OK (=できそう) 」「到着 (=リリース済み) 」「運転見合わせ (=規模が大きい, プロダクト方針と違うのでやらない) 」というタブで仕訳するようにしています。
前述の通り、これまではどちらかというとユーザーインパクトの大きさを重視して、4時間の中でリリースまで持ち込めないものも多く扱っていました。
ただ「ゴキゲン超特急」の意義は、既存の開発ラインでは扱えないような小さな案件をすぐにリリースしていけることだと考えていたので、必ず4時間の中でリリースできるように案件の調整を行うようにしています。
(この点は、武波がデザイナー視点でより解像度を高めて選定を行えるようになったので、体制変更がうまく機能した部分かもしれません。)
また、メンバー集めの課題も解決する必要がありました。
毎回ベストなメンバーをアサインしてくるのは非常に大変なことなので、武波にバトンタッチしてからしばらくは、導入期のように固定化したメンバーで取り組むようにしました。
これによって、「4時間の間に既存の開発ラインでは扱えない小規模だが重要な改善を扱う、新たな開発ライン」が生まれているような構造をつくっています。
さらに、すでに機能し始めていた「ゴキゲン超特急」の目的に、ビジネスサイドとの連携を強めることを追加しました。
「ゴキゲン超特急」の立ち上げ当初は意識していなかった目線でしたが、運用が進んできたので、この機会を活用してビジネスサイドとしてももっと要望をあげやすくなるようにしていくことに取り組んでいこうとしています。
例えば、武波自身もビジネスサイドに留学する取り組みを始めてみました。
留学先では実際にカスタマーサクセスのメンバーとして活動する中で、顧客理解を深め、「ゴキゲン超特急」で解決できそうな案件の模索をするようにしています。
また、より誰でも気軽にゴキゲン超特急への要望をあげてもらえるように、Slackの「リアク字」を使った要望回収の仕組みを運用しています。
Slackメッセージの中で「これはゴキゲン超特急で扱って欲しい」と思うものにスタンプが押されると、自動で超特急メンバー宛に届けられるようにしています。
現在も、さまざまな取り組みを実験的に動かしているところです。
「ゴキゲン超特急」のしくみを運用し始めてから約1年半、プロダクト改善面・組織文化面の双方で効果が生まれています。
プロダクト改善については、「ゴキゲン超特急」発で “25件” もの改善施策がリリースされています。
これまでの開発ラインでは扱えなかったような、分かっているけど優先度がどうしても下がってしまっていた改善もいくつもあり、開発組織としても「変に誤魔化さずに」開発に取り組めているような感覚を持てています。
「ゴキゲン超特急」の存在や、価値が認知されてきたことで、ビジネスサイドのメンバーからも「これゴキゲン超特急でできませんか？」と声をかけてもらえることも起こっています。
さらに、カスタマーサクセスのチームや、ユーザーコミュニティのチームでは、「ゴキゲン超特急」の存在を、お客さまにも伝達してくれているそうです。
SaaSのお客さまの中には「どうせプロダクトへのフィードバックをしても改善されないだろう」と思ってしまう方も多くいると思います。Teachme Bizには「ゴキゲン超特急」のような改善の仕組みがあることが伝わると、お客さまもより安心して改善要望をあげてもらえる良い文化が生まれます。
今回の取り組みを通して、スタディストの中で「グロース期のサービスにおける持続的な改善」の方法を一つ見つけることができたと考えています。
初期は阿吽の呼吸で進められる開発も、徐々に体制が大きくなると部署が分かれてきて難しくなります。大きな価値を届けるための機能開発をしようとすると、丁寧にロードマップを引いていくことも必要となります。そうすると、逆に細かな改善要望へのリアクションスピードが遅くなってしまうこともあると思います。
今回の「ゴキゲン超特急」の取り組みは、そのような組織状況に対して、うまくハマる施策となりました。ユーザー影響が少しでもある改善を、メンバーが自発的にリリースしていくような体制ができたことで、よりスタディストの持続的な顧客価値向上の土台が整ってきたように感じます。
もう少し補足すると、今回の取り組みは「カスタマーサポート」「デザイナー」「エンジニア」「QA」などの別々に活動する職種の相互理解を促し、より業務を染み出していくことにもつながっています。
例えば、「ゴキゲン超特急」を立ち上げた発起人、CS担当だった遠藤は、現在はカスタマーサクセスとしてより広い範囲でお客さまに価値提供を行えるようになっています。これは、プロダクトがリリースされるまでの一連の流れを詳細にキャッチアップできたことが大きく経験として活きているなと感じています。
「ゴキゲン超特急」を現在運営しているデザイナーの武波も、つくったものが高速でお客さまに使われる体験を通して、これまでの開発ロードマップでは得られなかったお客さまのフィードバックを得ることができています。お客さまの理解が深まることで、デザイナーとしても非常にモチベーションが高まっています。
エンジニアメンバーが書いた記事もあるので、こちらもぜひご覧ください。
お客さまの価値になり、かつ、開発メンバーとビジネスメンバーの連携も強まる、このような施策を今後もスタディストでは多く実践していきます。