取り組み概要

DXが進んだと言われる今も、外科系医療の現場には、紙、ホワイトボード、電話、PHSなど、アナログな業務が数多く残されている。株式会社クオトミーは、そんな外科系チーム医療のDXに取り組むスタートアップだ。整形外科医として現場に立ってきた代表の大谷隼一さんは、手術にまつわる業務を支えるプロダクト「OpeOne（オペワン）」を開発してきた。

そのクオトミーが新たに取り組むのが、転院時の紹介状作成をAIで支援する新規事業だ。この構想を現場で試せるプロトタイプへと落とし込む過程に伴走したのが、株式会社ZENだ。今回は、大谷さん、現役の整形外科医でもある児玉弘泰先生、株式会社ZEN代表の佐伯航平さんに、医療という専門性の高い領域で、ZENの伴走がどのように機能したのかを聞いた。

この記事に登場する人物

佐伯航平（Kohei Saeki）
サイバーエージェントでエンジニアとして開発経験を積んだ後、メルカリにてプロダクトマーケティングマネージャーとして事業成長に携わる。現在は株式会社ZENを経営し、プロダクトマネジメント、グロース、AI活用、クリエイティブ制作などを横断して、企業の新規事業・サービス成長を支援している。

大谷 隼一（Junichi Ohya）
株式会社クオトミー 代表取締役／整形外科医。2006年、名古屋市立大学医学部卒業。東京大学整形外科学教室に入局し、関連病院で研鑽を積む。2015年に米国留学した際、プロダクトによって生活や体験が変わることに衝撃を受ける。帰国後、医療者向けのプロダクトづくりで医療に貢献できないかと考え、2017年に株式会社クオトミーを創業。現在は外科系チーム医療DXプロダクト「OpeOne（オペワン）」を展開している。

児玉 弘泰（Hiroyasu Kodama）
整形外科医。東京大学卒業後、東京大学整形外科学教室に入局。都内・地方の関連病院で整形外科医としての臨床経験を積む。現在も研究・臨床業務に従事しながら、2025年3月よりクオトミーに参画。医療現場の業務効率化に課題意識を持ち、プロダクト開発にも関わっている。

外科医が感じた、医療現場に残るDXの余地

——まず、株式会社クオトミーの事業内容について教えてください。

大谷さん：私たちのミッションは、「医療者のポテンシャルを最大化し、健やかな医療をつくる」ことです。今は特に、外科系のチーム医療にフォーカスしています。この領域は、アナログな業務がすごく多いんです。そこをDXやAIで変えて、病院の中の人たちがもっと本来の力を発揮できるようにしたい。そういう思いで事業を進めています。

〈キャプション〉株式会社クオトミー 代表取締役／整形外科医　大谷 隼一さん

——大谷さんご自身、外科医として働く中でどのような課題を感じていたのでしょうか？

大谷さん：創業のきっかけのひとつは、UCサンフランシスコへの留学でした。プロダクトによって生活や体験が変わることに衝撃を受けたんです。一方で、アメリカの医療現場は、潤沢な医療システムを人で支えている面も大きい。日本にそのまま持ってくるのは難しいと感じました。だったら、日本の医療現場に合った形で、プロダクトによって解決できることがあるのではないか——そう考えたのが、起業のきっかけです。

日本でも医療DXの機運は高まっていますが、現場が本当に欲しいものはまだ少ない。予約システムのような外向きの仕組みは増えていますが、病院の中の業務を支えるDXやSaaSは、まだ十分ではないと感じています。

OpeOneが支える、手術にまつわる業務のDX

——既存プロダクトの「OpeOne（オペワン）」は、どのようなプロダクトなのでしょうか？

大谷さん：手術って、一人ではできないんです。患者さんと手術を予定し、チームで色んなことを調整・準備して、執刀し、術後の管理をして、退院につなげる。その一連の流れには、医師ひとりではなく、医師チーム、看護師、事務職、ソーシャルワーカーなど、さまざまな職種が関わっています。でも、その業務を回すためのツールがなかったんです。電子カルテは医療情報を残す記録システムであって、業務を回すためのものではありません。

OpeOneでは方針を調整する、チームに伝える、情報を蓄積して医療の質を高める。そうしたことを一括で管理できるようにしています。紙やExcel、対面のカンファレンスで補われていた情報を一つにまとめ、非同期でも業務が回るようにする。それがOpeOneの役割です。診断が目的の医療機器ではありません。

——業務がデジタル化されることで、現場にはどのような変化が生まれるのでしょうか？

大谷さん：電子カルテによって、医療情報の電子化は進みました。でも、それだけでは業務そのものの変革にはなっていない。OpeOneは、そこを変えていくためのプロダクトです。業務効率化から入り、蓄積されたデータを活用することで、病院の収益改善にもつなげていける。そこが強みだと思っています。

ZENとの伴走は、プロダクトとチームの現在地を整理することから始まった

——ZENの佐伯さんとは、どのようなきっかけでご一緒することになったのでしょうか？

大谷さん：プロダクトマネージャーを探していたことがきっかけでした。医療現場の課題は広く、プロダクトにさまざまな機能を足していく必要があります。でも、それを回してくれる人がいないと進められない。そこに課題を感じて相談しました。

〈キャプション〉株式会社ZEN 代表　佐伯 航平さん

佐伯さん：最初にお話を伺った時、すごく意義のある取り組みをされているなと思いました。僕はもともとゲームやフリマアプリを作ってきたのですが、そこで培った経験が医療のプロダクトに活かせるなら、すごく意味があると感じました。

——最初の頃は、具体的にどのようなことから始めたのでしょうか？

佐伯さん：最初は、プロダクトの現在地を整理するところから入りました。どこに課題があり、どこに向かっていくのか。ワークショップ形式で整理しながら、優先順位をつけていきました。

〈キャプション〉クオトミーで実施したプロダクトマネジメント・クライテリアの整理。プロダクトやチームの現在地を可視化し、優先して取り組むべき課題を確認した。

佐伯さん：大谷さんの強みは、課題の解像度の高さです。医療のような専門領域に、外部の立場からリサーチだけで入ろうとしても、現場にいた人には敵わない。だからこそ、僕はフラットな視点で課題を整理する役割を意識していました。大谷さんの中にあるアイデアや現場感を引き出しながら、それをプロダクトとして形にしていく。そういう進め方でしたね。

現役医師とプロダクトの専門家が、専門性を持ち寄り、形にする

——児玉先生も開発に加わっていらっしゃいますが、どのような経緯だったのでしょうか？

児玉先生：私は脊椎や頸椎、腰などの手術を専門にしている整形外科医です。大谷さんの勤務医時代の後輩で、同じ手術を担当することもありました。外科医って、正直つらいんです。スマートに働ける現場がほとんどなく、臨床ではAIもほとんど使えない。診療記録も電話も、まだアナログな部分が多い。そうした課題感から、クオトミーに関わるようになりました。

〈キャプション〉整形外科医　児玉 弘泰さん

佐伯さん：児玉先生は現場の課題や医療の前提を深く理解されていて、僕はプロダクトや開発の観点から形にしていく役割です。わからないことはその場で教えていただきながら、医療の知見とプロダクト開発の視点を掛け合わせて作っていく感覚でした。

大谷さん：まさに、そのバランスが良かったんです。僕自身、このプロジェクトにすべての時間を割けるわけではありません。既存プロダクトや営業もある中で、佐伯さんがプロダクトとして前に進めてくれて、児玉先生がドメインエキスパートとして現場の知見を入れてくれる。だからこそ、進められる体制になっていたと思います。

児玉先生は現役なので、現場の課題感をリアルタイムで拾ってこられる。それがまたアイデアになり、プロダクトに落ちていく。実際に使う医師の感覚を反映しながら開発できるのは、すごく大きかったですね。

新規事業「転院アシスト」へ。医師待ちで止まる業務をAIで動かす

——新規事業「転院アシスト」は、いつ頃から始まったのでしょうか？

大谷さん：本格的に動き始めたのは4月頃です。医療制度の変化もあり、病院側でも患者さんの転院をよりスムーズに進める必要性が高まっていました。ただ、既存プロダクトの改善や営業もある中で、社内のメンバーだけで新しい仮説検証まで進めるのは難しかった。そこで、佐伯さんに相談しました。

——具体的にどのような課題を解決するものなのでしょうか？

大谷さん：前提として、病院の役割分担が少しずつ変わってきています。大きな病院では、手術後も患者さんに長く入院してもらうことが難しくなってきているんです。そのため、手術が終わった患者さんを、リハビリ専門の病院などに転院させる必要があります。

ただ、転院には医師の紹介状が必要です。手術が終わる前からドラフトを書き始めている医師もいますが、現実にはそこまで手が回らないことも多い。忙しいために、どうしても後回しになってしまう。そこをAIで支援できないかと考えました。

〈キャプション〉「転院アシスト」の画面イメージ。OpeOneに蓄積された情報をもとに、平均在院日数や退院率、収益効果などを可視化し、転院調整を支援する。

佐伯さん：OpeOneには、手術内容や患者さんの状態など、紹介状を作るうえで必要な情報が蓄積されています。その情報をもとに、AIが紹介状のドラフトを作る、というものです。最初の叩き台があれば、医師が紹介状を一から書き始めなくても、確認や修正をするだけで済みます。。転院調整を担うソーシャルワーカーさんも早い段階で動き出せる。AIを活用することで、医師の業務効率化にもなりますし、病院の生産性の向上にも寄与します。

〈キャプション〉「転院アシスト」では、紹介状ドラフトの生成から医師確認、転院打診、承認までの流れを可視化。医師やソーシャルワーカーなど、複数職種で転院調整の進捗を共有できる。

——なぜ、AIと相性がいいのでしょう？

大谷さん：病名や術式が決まれば、次にどんな病院へ、いつ頃転院するのがよいかは、ある程度パターンがあります。OpeOneのデータを使って紹介状のドラフトや転院の流れを支援できれば、医師の業務負担を減らすだけでなく、病院経営の改善にもつながる可能性があります。

もともとOpeOneは、業務効率化から入るプロダクトです。でも、そこから経営の改善にもつながる。転院支援は、その打ち手のひとつだと思っています。

要件定義書ではなく、壁打ちでつくる。AI時代のプロトタイピング

——課題が見えてから、ZENではどのように形にしていったのでしょうか？

佐伯さん：最初に細かな要件定義書を作り込まず、お二人と壁打ちしながら形にしていくことを選びました。医療現場の前提を教えてもらいながら、まず触れる状態のものを作る。AIを活用することで、数日で叩き台を出せるので、それを見ながら違和感を確認し、修正していけるんです。

最近は、顧客の現場に入り込みながら課題を聞き、プロダクトに落とし込んでいく「フォワードデプロイドエンジニア（FDE）*1」のような働き方が注目されていますが、それに近い感覚がありました。外から要件だけを受け取って作るのではなく、現場の知見を聞きながら、実際に使える形へ近づけていく。今回の転院アシストでも同じように、現場の声を聞きながら進められたことで、ブラッシュアップのスピードはかなり速かったと思います。

大谷さん：最初に作ってくれたものの完成度が高かったんですよね。画面として見えるものがあると、議論が一気に進みます。週次で打ち合わせをしながら、気になった点はNotionに書いておけば、非同期でどんどん反映してくれる。それがすごくやりやすかったです。

佐伯さん：最初は中心となる機能を作り、そこから「診療科ごとにどう分けるのか」「タスク一覧としてどう見せるのか」といった部分を詰めていきました。医師だけでなく、ソーシャルワーカーなど複数の職種が使う前提で、必要な画面や機能を現場の知見をもとに足していく進め方でした。

——ZENが入ったことで、スピードや完成度にはどのような変化がありましたか？

大谷さん：まずMVP*2を作って、お客さんのところに持っていける状態にする。これがすごく大事なんです。私たちのようなフェーズのスタートアップは、いろいろなプロダクトの可能性を試したい。一方で、既存プロダクトの改善や営業もある中で、社内のエンジニアに新しい仮説検証まで任せるのは難しい部分があります。

その点、佐伯さんはAIや既存のリソースを活用しながら、アイデアを素早く形にしてくれる。営業先で見せられる叩き台があるだけでも、議論の進み方は大きく変わります。そこに外から入ってもらう価値がありました。

佐伯さん：AIによって、MVPを作るハードルはかなり下がっています。ただ、実際に現場で見せられる状態まで持っていくには、課題の整理や画面の作り込み、使う人に合わせた調整が必要です。途中まで作って終わりではなく、現場で試せる形にする。その部分を一緒に進められることに、今の時代の伴走の価値があると思っています。

医療者が、本来の仕事に集中できる現場へ

——最後に、クオトミーとして今後どのように医療現場を変えていきたいか、聞かせてください。

大谷さん：今は本当に激動の時期です。国の政策、テクノロジー、現場で起きていること。そうしたものをまとめて、事業計画やプロダクトロードマップを作らなければいけません。その中で、現場の業務効率化だけでなく、収益が上がる、費用対効果が高いものを作れる企業が選ばれていくと思っています。自分たちの価値提供を、どんどんブラッシュアップしていきたいですね。

児玉先生：手術そのものをAIに任せることはできません。でも、その周りの業務は変えられる。医師が本来やるべきことに集中できる環境を作りたいんです。外科医を無理に増やさなくても、医療がちゃんと回っていく。そういう社会を作りたいと思っています。

佐伯さん：クオトミーさんは、課題解像度の高さと、それを形にするスピードの両方を持っている稀有なチームです。ZENとしても、頭の中にあるアイデアを、現場で試せる形にするところで、これからもお役に立てればと思っています。

取材・文・写真：藤井由香里

*1 フォワードデプロイドエンジニア（FDE）：
Forward Deployed Engineerの略。顧客や現場に入り込み、課題を聞きながら、プロダクトの実装・改善・定着までを支援する役割のこと。

*2 MVP：
Minimum Viable Productの略。本格開発の前に、顧客や現場に見せて反応を確かめるための、最小限の機能を備えたプロダクトのこと。