【オンライン診療プロダクトの開発が"回らない"状態を立て直す】
要件定義・ロードマップ・改善運用を整え、医療×多職種チームでも納得して前に進める体制構築

1. 本事例の背景（相談の入口）

本事例の相談の入口としては、「PMFは迎えていて一定の需要はあるが、ここから更に事業を伸ばしたい」というフェーズ感でした。求められていたのは、単に手を動かす人ではなく、開発全体のネックを分析し、必要なら組織づくりまで含めて立て直せる人材ということで、池さんにお声がかかったとのことです。

今回のサービスは、女性向けにピルの処方や医師との非対面問診などを通じて、医療アクセスをより身近にすることを目指した女性向けオンライン診療プラットフォームです。池さんの参画時は、開発プロセスが体系化される前の段階で、ロードマップや改善項目の管理も整備途上でした。このフェーズでチームが直面しやすいのは、「やることが多い」こと自体ではなく、「今どこに向かっていて、次に何をすれば良いのか」が揃いきらないことです。改善要望は増えるのに、優先順位の決め方が毎回重くなりがちなうえ、多職種チームがゆえに前提がズレてしまうと、合意形成コストが跳ね上がりやすく、結果としてスピードも品質も落ちてしまいます。

そこで本支援では、まず「判断の軸」と「運用ルール」を整え、チーム全体が納得して前に進める状態を作ることにフォーカスしました。

2. 課題（支援先で起きていたこと）

いざ入ってみると、ボトルネックは「開発」そのものより、その手前の要求整理にありました。当時の構図は、CSや医療従事者チーム、経営層など、それぞれが開発への要求を持っており、その要求が「同じ土俵」で整理されないまま開発へ流れ込むと、優先順位は"説明可能な基準"ではなく"状況や声量、社内的な立場"に引っ張られやすくなっている状況でした。結果として、短期の火消しが増え、中長期のプロダクトの要件としては整合性が崩れていきます。さらには、池さんの参画時はPdM（要件定義を担う役割）が不在でした。PdMがいないと、要求が仕様へ翻訳される途中で抜け漏れが増え、エンジニアやデザイナーが"よしなに"で進める場面が増えます。当時は今と違いAIでの開発もまだない時代でしたので、デザインとして上がってきたものに対して都度レビューをするようなやり方のため、サイクルも開発スピードも遅く、加えて成果物として要件定義書がなく、プロダクトを触らないと要件が分からない状態でした。技術面でも、技術負債が積み上がると開発は遅くなる一方です。改善したいのに改善できず、改善が後回しになるほどさらに遅くなるという、典型的な負のループが生まれやすい状態でした。

表面化していた症状としては、「リリースが遅いけど、理由もわからない」「あげている要望が実現されない」といったような不満が、各現場から溢れでていました。ただ根っこは、"何を優先するか"を説明可能な形にできていないことと、"なぜそれをやるのか"が揃わないまま走ってしまうことにありました。「各々の部署からの要望が多い」ことではなく、要求が同じ土俵で整理されず、優先順位と合意の作り方が揃っていないことが原因でした。だからこそ次に必要だったのは、要件定義の型／ロードマップ／改善運用をセットで整え、チーム全体が「次に何をするか」を迷わず決められる状態にすることでした。

3. ゴール（何を"できる状態"にするか）

目指したのは、プロセスやツール導入そのものではありません。チームとして次の状態に持っていくことでした。

• どこに向かうかという方向性が言語化されている
• 次に何をやるべきかの優先順位が説明できる
• 「なぜそれをやるのか」が揃い、判断がしやすくなる
• 改善が運用として回る（技術負債も含めて手当てできる）

という状態を作ることでした。ロードマップと要求定義（TRD）を軸に、ステークホルダーが"前を向いて"議論できる状態を目指しています。言い換えると、目指したのは「うまく回っている感」ではなく、より再現性のある運用にしていくことです。人が入れ替わっても、要求が増えても、判断の型が残る。PdM組織を立ち上げたのもそのためでした。ここが整うほど、多職種チームでも前に進める確度が上がります。

4. 進め方（実行してきたこと）

4-1. 主要ステークホルダーにヒアリングし、課題を「レポート」して共通認識化

最初にやったのは、主要ポジションの人たちに一通り話を聞き、各視点の課題を集めて整理し、レポートとして示すことです。ここで重要だったのは、いきなり「要件定義プロセスを入れます」と言わないことでした。プロセスは"増えるように見えてしまう"ため、「今まで回っていたのになぜ？」となりやすいので、「みんなが困っている点」を先に言語化し、要求整理から入る形で合意を取りました。この"共通認識を作る"工程がないと、後のロードマップもバックログも「誰かの都合」に見えてしまいます。まずは同じ地図を持つ。ここを丁寧にやったことが、後工程の推進力になります。

4-2. 要件定義プロセスを導入し、仕様を"明文化"する

次に着手したのは、要件定義プロセスの導入です。要求を口頭で受けて"よしなに"進めるのではなく、仕様として明文化し、判断の材料が残る状態をつくるようにします。これだけでも、関係者が増えたときの認識合わせが進めやすくなります。いきなり詳細仕様へ落とすのではなく、TRD（要求定義）のような形で「この方向性で合っているか」を先に揃えていく、段階的な進め方も語られていました。"要求を整えてから仕様へ"という順序が、合意形成を軽くします。

また、運用だけ整えて終わりではなく、まず"型を体で作る"ところから入りました。最初の半年ほどは、要件定義書を実際に全部自分で書き、求める粒度・構成・判断の軸をチームに示していきました。型ができてから初めて、周囲に渡して回る状態になります。

4-3. WF・UIデザイン段階からレビューできる体制をつくる

要件定義と並行して、WF・UIデザイン段階からレビューできる体制を構築しました。"作ってから直す"ではなく、"作る前に揃える"。後工程での手戻りを減らし、関係者の不安を早い段階で解消するための前倒しです。

4-4. 半年〜1年のロードマップを策定し、四半期テーマで優先順位を揃える

半年〜1年スパンのロードマップを策定し、四半期単位で重点テーマを設けて、開発の優先順位を明確化しました。日々の要望に流されず「今期は何に集中するのか」をチームで握れる状態を整えます。これが、判断と実行の納得感につながります。ロードマップと要求定義書をセットで出していくことで「思っていたのと違う」が減り、打率が上がっていきました。

4-5. 改善要望はバックログで管理し、工数20％を割り当てる運用ルールを整備

改善は「余裕があればやる」だと、結局後回しになります。そこで改善要望はバックログで一元管理し、開発工数の20％を改善に割り当てる運用ルールを整備しました。改善を"気分"ではなく"運用"に載せる。技術負債を放置すると速度が落ち続けるため、枠を押さえて継続的に手当てできる状態に寄せた、という文脈で語られています。

4-6. 不要なツールやインフラ環境を見直し、開発コストを最適化する

あわせて、不要なツールやインフラ環境を棚卸しし、開発コストの最適化にも寄与しました。「作る」以外のムダを減らすことで、チームが前に進む余白を作っていきます。

4-7. "全部門に並走"して、現場の信用を取りに行く

上位ステークホルダーへのアプローチも含めて進めつつ、開発はもちろん、同時にCSや助産師チームなど"困っていた現場"にも並走し、口だけではなく一緒にやり切ることで信用を獲得していきました。その並走を支えた前提として大きいのが、池さん自身が開発だけではなく、QAやCSの観点まで含めて一通り見られることです。現場の要望をそのまま受け取るだけではなく、同じ目線かつ開発からの目線でも目を光らせながら並走をしました。結果として、部門間で分断しやすい論点を一つの土俵に乗せ、合意形成を前に進めやすくなりました。

象徴的なのが、難易度が高く放置されていたZendeskの全社導入を引き取り、運用ルール設計からレクチャーまでやり切ったことです。これが、池さんを「一緒にやり切ってくれる仲間」として現場との信頼形成に繋がりました。

5. 工夫点（意思決定を前に進めたポイント）

5-1. ロードマップ＋要求定義で「思っていたのと違う」を減らす

3〜6ヶ月ほどで変化が見え始め、ステークホルダー側には、ロードマップと要求定義書の提出が特に効いたと言います。「思っていたのと違う」が減り、打率が上がっていきました。加えて中長期の事業計画に対して「いつ頃どんな準備が必要か」を開発観点で議論できるようになったことが大きかった点でした。

5-2. 開発の中を変えにくいなら、開発の外（要求・合意）を変える

開発チームのトップ層に課題がある場合、チーム全体をガラッと変えるのは難しいことです。だからこそ、開発の中に閉じるより開発の外（要求整理・合意形成・運用ルール）を変えに行く比重が大きかったです。

5-3. 場をオープンにして「敵ではない」状態をつくる

開発チーム側に対しては、スプリント導入やバックログ整理の共有など、場をオープンにする工夫も入れています。プロセス導入は"監視される"と捉えられると反発が強くなるため、透明性を上げて合意形成を軽くさせます。その結果、「敵ではない」が伝わり、運用が回りやすくなりました。

6. 成果

今回の支援では、以下のような成果をもたらしました。

• 方向性と道筋を言語化・可視化し、納得感と主体性が向上
• 医療従事者を含む異なる専門性・文化でも、共通認識を持って一体的に進行できる体制を実現
• 「なぜその開発を行うのか」の視点が定着し、スループットと品質が改善
• プロジェクト期間中にGMVが大幅に成長

加えて、PdMチームを社内で立ち上げ、半年以上かけて育成したことや、離脱前に要件定義書の型・Confluenceの運用ルール・承認プロセスなどを整備して引き継いだことなどもあり、大きな財産を支援先に残されました。

"立て直して終わり"ではなく、継続できる形に落とし込んだ点が、この事例の特徴です。

7. インタビュイーからのワンポイントアドバイス

〜プロセスがないチームがつまずくポイントと発注側の覚悟〜

スタートアップやプロダクト初期立ち上げの現場では、仕様書を書かずに"手なり"で開発が進むことは珍しくありません。最初はそれでも走れます。ただ、組織が拡大し、目指すゴールが大きくなるにつれて、そのやり方ではどうしても限界が来ます。一番つまずくのは「必要性を理解できないこと」だと思われます。50人〜100人規模の大きな開発を経験している人がリード層にいれば、プロセス導入の意味は比較的スムーズに通りますが、スタートアップでは、そうした経験を持つ人がいない場合も多いです。そうなると、「なぜ今それをやるのか」が腹落ちせず、最初の段階でハレーションが起きやすいという事象が起きます。プロセスを入れると、短期的には手間が増えたように見えます。ただ、それは"遠回り"ではなく、"土台づくり"なのです。

そのうえで、発注側に求められるのは、「理解できないけど、頑張らなければいけない期間がある」という覚悟です。例えば学生時代の部活動では「この練習、何の意味があるんだろう」と思いながら続けて、半年後に「あ、このためだったのか」と気づくこともあるかと思います。プロセス導入もそれに近いと考えます。重要なのは、外部の提案を盲信することではありません。ただし、「今は前に進めると決める」「一定期間は信じてやってみる」という姿勢は必要になります。さらにもう一つの覚悟は、「これまでのやり方の一部が否定される」ことを受け入れることです。プロセスを整えるということは、属人的だった判断や進め方を見直すことでもあります。

実際の本事例でのプロジェクトでも、上層部の一部には「このままでは目指すゴールに届かない」という危機感があり、話が通じやすい土壌がありました。一方で、現場レベルでは実感が薄く、まずは信用を積み重ねるところから始める必要があったと語られています。

8. 最後に（総括）

本事例が示しているのは、「プロセスを整えれば成長する」という単純な話ではありません。本質は、"なぜそれをやるのか"を説明できる状態をつくることでした。要求が整理されずに流れ込む組織では、優先順位は声量や緊急度に左右されます。仕様が明文化されていない環境では、確認の往復が増え、スピードは落ちていきます。技術負債は、気づかないうちに判断力を鈍らせます。そうした状態を抜け出すために必要だったのは、大きな改革よりも、地道な言語化と可視化の積み重ねでした。最初の半年間は、すべての要件定義書を書き切り、全ステークホルダーと向き合い、要求を整理し、構造化する。コードも理解し、QAも担い、CSの視点にも立ち、各部門の間を行き来しながら翻訳し続ける。その結果生まれたのは、単なるドキュメントではなく、迷わず意思決定できる組織状態でした。

プロダクトが伸びるかどうかは、機能の良し悪しだけでは決まりません。組織が「どこへ向かっているのか」を共有できているかどうかに大きく左右されます。もしも今、リリースはしているが前に進んでいる実感がない・優先順位が毎回揺れる・要件が人に依存している。そんな状態があるとすれば、それは技術の問題ではなく、設計と体制の問題かもしれません。

今回の支援は、その土台を整えたという事例でした。成長を加速させる前に、まずは迷わない状態をつくことが、プロダクトを本当に伸ばすための第一歩なのだと、改めて感じさせられる取り組みでした。