400医療機関で導入済みのtoB SaaSは、 本当にアジャイル開発可能なのか！？
Ubie株式会社 / Ubie Discoveryで、医療機関向け事業のプロダクトオーナー（PO）を務めている、まつむら (@matsumura_ubie) です。
突然ですが皆さん、アジャイル開発を楽しんでいますか？ たくさんリリースできていますか？
SaaS全盛期の昨今ですが、toB SaaSはtoCと違って、アジャイル開発にあまり向いていないのでは？ 高速でリリースし続けるのは色々と難しいのでは？ という声をしばしば聞きます。
一方で、toBプロダクトであるAI問診ユビーは、現在でも1Sprint = 1週間、
週3日 = 年間150回リリースのハイペースでのアジャイル開発を、頑なに維持し続けています。
Ubieがなぜこれほどまでにハイペースでのアジャイルにこだわるのか、そしてどんな工夫をしているのか、ご紹介いたします。
前提：AI問診ユビーは、400医療機関の外来業務に根ざしたサービス
医療機関向けのプロダクトである「AI問診ユビー」は、 外来業務に深くビルトインされた業務系SaaSです。問診やカルテ文章の作成など、従来紙や電子カルテで行われていた業務をサポートするツールです。
クリニック向けはいわゆるSMB、病院向けはいわゆるEnterprise SaaSと言えます。病院は規模によっては医師10-20名、外来スタッフ30-40名が日々利用するサービスです。
一度使い始めるとAI問診なしでは業務が難しくなる、という業務系SaaSとしての特徴があります。そのため、ユーザーの負荷をいかに抑えつつ、リリースによって価値を提供し続けるか、が創業当初からのテーマです。
toB SaaSをアジャイル開発するのは、なぜ難しいと言われるのか？
toB SaaSを開発する際の懸念は、下記のようなイメージでしょうか？
「業務が複雑なので、広い範囲で要件をカチッと決める必要がある」
ある一部の業務プロセスから少しずつシステム化することは難しい。なぜなら、ある業務プロセスをシステム化したら、隣接する業務のシステム化も検討しないと使いづらい。そこで、ワークフロー全体の要件を決めきり、開発して、リリースが必要、という考え方です。ウォーターフロー的とも言えます。
例えば、問診取得をシステム化したら、関連する業務として問診チェック、問診票管理、スタッフ間の連携... もシステム化が必要なので、全部作って一気にリリース、といった具合です。
価値・機能が比較的独立させやすいtoCサービスに比べ、一連のワークフローにビルトインしていくtoBサービスのほうが、ウォーターフォール的にならざるを得ない気がしてきます。
（クリニックの業務フローイメージ。複雑）
「ユーザーの体験の連続性を保つ必要がある」
サービスによってできることがコロコロ変わるとユーザーが困ってしまう、ということです。「昨日出来ていたことができなく」なり、業務が立ち行かなくなるのは最悪です。紙や手作業に戻せるならまだしも、データが取り出せなくなった、といった場合はサービスレベルとして明らかにNGです。
つまり、一度作った機能の除却が難しいため、手戻りが無いように十分に計画・設計してから作りたくなります。試しに作ったけどイケてなかったので取り下げる、というアジャイルなアプローチがしづらい理由です。
「頻繁な業務変更をユーザーが嫌う」
toBのユーザーは、業務手順書やマニュアルを更新したり、関係するスタッフに変更を周知するケースがあります。頻繁にツールや業務が変更されると大変だということは、容易に想像がつきます。
そして、ユーザー数が増え、顧客基盤が拡大してくると、社内でも様々な意見が出始めるのではないでしょうか。
顧客接点を持つチーム（カスタマーサクセスやカスタマーサポートなど）から、「頻繁な仕様変更で顧客が疲弊している」「サクセスチームのキャッチアップが大変だ」という声があがり、リリース頻度を落とさざるを得ない、といったことが起きそうです。
（顧客からお褒めと困惑のフィードバック）
それでもUbieがアジャイル開発と週3日リリースを続ける理由
toB SaaSでアジャイルが難しい要因は色々ある。それでも、Ubieがアジャイルにこだわる理由は何でしょうか。それは、
「ユーザーに価値を届ける上で、何が真に価値あるものなのか、それは結局ユーザーの行動から学習しないと分からないから。」これに尽きます。
アジャイル開発を行う最大の理由に立ち戻ってみましょう。それは開発チームが「不確実性に向き合う」ためです。
「何が求められているのか」「どうやったら実用に足るのか？」といった「不確実性」に直面し続ける開発において、その疑問をいち早く確信に変え続けるためには、頻繁にリリースしてユーザーの反応や結果から学んでいくほかありません。
...と、教科書のような理想論を書いてしまいましたが、この信念をチーム全体で共有して貫き通せている理由は、つまるところ「無数の失敗をし続けている」経験があるからです。それは、恐怖体験として刷り込まれているから、と言ってもよいかもしれません。
最初のリリースから3年経ち、様々な知見が溜まってきた現在でも、「全く使われない機能」を作ってしまうことがたまにあるんです。
社内にはドメインエキスパートたる医師もいて、
密に会話ができる業務委託の医師もいて、
外来現場に100回以上通っているサクセスメンバーがいて、
無数のリリースとその後のログ/データからユーザーの反応を見てきている開発メンバーがいて...
それでも失敗するんです。
失敗は0にはならない。であれば、早く失敗して、早く学んで、早く軌道修正したほうが、結果的には価値あるものを早く作れる。この共通認識こそが、様々な困難を乗り越えつつ、Ubieがアジャイルにこだわる一番の理由です。
アジャイル開発を進めるためのUbieの工夫
数々の失敗を積み重ね、Ubieでは色んな工夫をしてきています。チーム自ら運営を改善できるのも、スクラム開発の醍醐味ですね。
・ユーザーには予め、AI問診ユビーが常に進化するサービスだと伝える
アジャイル開発を進めるには、ユーザーの理解が必要です。Ubieでは、アジャイル開発のメリットを、導入の早い段階から顧客に繰り返しお伝えしています。
「クラウドベースのSaaSである強みを活かし、皆さまのご意見・ご要望を踏まえ、すぐに機能改善に反映します」と、ポジティブに訴求しています。
一般的な医療システムは、特にオンプレミス型を中心に、半年〜数年に1回の更新・改善頻度が主流です。そのため、現場ユーザーの中には、始めは体験がこまめに（週に何度も！）変わることに戸惑う方もいます。
一方で「不満や要望をすぐに反映してくれた」「早いスパンで進化が垣間見えて楽しい」と感じていただけるユーザーも増えてきています。
・先行リリース対象ユーザーを巻き込んだPoCを行う
リリースされた機能が取り下げられたり突然大きく変わるのは、ユーザーからは非常によくない体験です。
そこで、不確実性の大きな検証中の機能は、リリース対象ユーザーを大幅に絞って、PoC（概念実証）という形で検証を進めることを徹底しています。
対象の医療機関は、特に、ユビーの進化を楽しみに協力していただけるユーザー、現状の機能に大きな不満を抱えているユーザーを中心にいくつか選定し、提案と依頼のお声がけをします。
「あなたの声が機能開発にダイレクトに反映される」メリットをお伝えし、合わせて「開発中の機能である」「機能が変わったり取り下げられたりすることもある」ことも期待値調整し、インタビューや視察、アンケートなどにご協力いただいています。
先行する医療機関で価値を感じて継続して利用していただけるようになったら、始めて全ての医療機関に展開する、という流れを取ります。
（リリース案内資料の例。先行リリースとして協力をお願いしている）
・リリース案内を丁寧に行う
ユビーの機能リリースに応じて、ユーザー側にもワークフローの見直しや、マニュアル更新などの作業がどうしても発生します。
ユーザーの負担を最小限に抑えつつ、案内が遅れてリリースが遅延することのないように、最適なリリース案内のあり方を常に改善しています。
ユーザーと直接、あるいは顧客接点を持つチームとコミュニケーションをする役割の、PMM（プロダクトマーケティングマネージャー）を設置したり、案内の手順やルールの整備を進めています。
（リリース案内のルールをNotionに整備し、随時更新）
・検証と観察を大切に、チームに知見を溜めていく
チームの中でいまいち確信が持てない状態でリリースし、ユーザーのリアクションを元に学習していく、というのがアジャイルの醍醐味です。
ウォーターフォール開発の要件定義フェーズのような、betterな要件を考え抜く活動に時間をかけすぎない代わりに、リリース後の結果からなるべく多くを学習できるように工夫をしています。
そうでなければ、いつまで経っても「雰囲気で適当に作る」「打率の低い」開発になってしまうからです。
例えば最近では、上手くいくかどうかの当落線上にあるような「仮説」を、開発前に持つことを意識しています。「多分これでいけそうだけど、もしかしたら受け入れられないかも」という「不安」があるくらいのリリースのほうが、学びは大きいため、優先して着手します。
また、使った/使わなかったという結果だけではなく、理由やメカニズムの理解も心がけています。
外来スタッフの実際の挙動や画面操作を観察したり、デプスインタビューをして、定性的に材料を集め、解釈をしていきます。
社内医師が、「あー確かに医師が使わない気持ちも分かる。なぜならここでは医師はそういう思考に至らないから」など、理由を裏付けしてくれたりすると、学びが多くて楽しいです。
・プロダクトをとにかく小さく切る。顧客への提供価値は一度に大きくなくてもよい
MVP（検証可能な最小単位のプロダクト）が大きくなると、開発に時間がかかり、クイックにリリースできなくなります。
Ubieでも、MVPの開発に1ヶ月かかってしまった...という失敗が頻発しました。そしてそういう機能に限って、結局使われなくなるものです、悲しいことに。
最近は、MVPをとにかく刻んで小さくすることを、チーム全体で意識しています。最も不確実性の大きい部分、多くの場合は「本当にニーズ/価値があるのか？」を検証さえできれば、他の付加価値（”あった方が便利”）や、ユーザビリティ（”この方が使いやすい”）は極力排除すべきです。はじめは。
先行ユーザーにリリースして「確かに便利ではある。が粗削りでちょっと使いにくいね（苦笑）」と言ってもらえればそれで勝ちです。後はユーザビリティを上げるだけです。
施策ぎめの議論では、とにかく激論が繰り広げられます。「この検証にこの要件は必要なのか？」「MVPで複数の検証をしようと欲張り過ぎてないか？」など。MVPが小さくなると、早く検証したいね、という気持ちが湧くのでリリースが楽しみになります。
（振り返りでも、プロダクトがデカすぎ問題はよく取り上げられる）
・施策だし＆詳細検討に十分時間をとって不確実性は社内で下げる
アジャイルの理解を間違えると、とりあえず手当たり次第にリリースし、当たればラッキーのような探索的なアプローチになりがちです。顧客やカスタマーチームが、悪い意味で「振り回される」状況は最悪です。
不確実性はなるべく早く、つまりできれば社内で下げたほうがよいので、最近は施策だし＆詳細検討（リファインメント）に十分な時間をかけるようにチームで意識しています。
過去得られた結果をちゃんと参照したり、医師・エンジニア・デザイナー・現場リサーチャーの知見で多角的に完了条件・受入基準（AC）を確認したりすることを意識しています。
そうすると、どうしても議論に時間がかかりがちですが、事前にチケットや論点を確認して議論時間を短縮したり、トリプルトラックアジャイルという運用方法を取り入れて、時間がかかる開発については発散と収束の活動を切り出して行う、といった工夫もしています。
おわりに
toB SaaSで、アジャイル開発をし続けるための工夫を紹介しました。
アジャイルは思想です。思想を貫いて恩恵を得るためには、まず信念が必要で、その上でプラクティスを積み上げる必要があると考えています。
今後もUbieは、最短最速で顧客に価値を届け続けるために、信念を貫きつつ、工夫を重ねてアジャイル開発を続けていきたいと思っています。
そして、なんと言ってもアジャイルな開発は楽しいです。自分では思ってもない発見や驚きがユーザーから得られ、それをプロダクトに反映できるなんて、これほどまでに知的好奇心をくすぐられる仕事もないと感じています。
AI問診ユビーは、ユーザーも拡大し、機能も提供価値も拡張し続けています。Ubieで一緒に、楽しいアジャイル開発をしながら、刺激的な毎日を一緒に送ってみませんか！？
Ubieのアジャイル開発の詳細や、Ubieで働くことにご興味のある方は、ご連絡をお待ちしております。
関連するその他の記事もどうぞ！
この記事が気に入ったらサポートをしてみませんか？