GxPが目指す「回し続ける内製化」

石黒：GxPの石黒と申します。本日はお足元の悪い中、ご参加いただきありがとうございます。内製化を掲げたはずなのに、気づけばまたSI依存に陥っている。そんなご経験はないでしょうか。本日はその背景にある構造に切り込みたいと思います。セッション後半ではファストドクターの井本さんよりRetoolを活用した実際の内製化プロセスを共有いただきます。

私たちGxPは2008年に設立し、グループで約300名でエンタープライズDXを推進しています。特徴はお客様の変革を構想で終わらせず、実装までやりきること。戦略の立案から開発、内製化まで一気通貫で伴走し、作って終わりではなく現場に定着させるのがGxPグループの役割です。私自身は2024年よりGxPにてRetool事業の日本責任者を務めています。



企業の内製化において、こんな状態に陥っていないでしょうか。内製化を始めてみたものの特定のベンダーやSIに依存してしまっている。PoCの域を出ないまま本番利用ができない。改善要望が開発待ちになり、外注した方が確実だと逆戻りしてしまう。Excelやスプレッドシートが乱立し、誰も全体像を把握できない状態になっていないでしょうか。

内製化が止まる構造とRetoolによる突破口

内製化が止まるのは技術力がないからではありません。本番要件を最初から個別開発で背負い込み、改善を前提としない仕組みになっているからです。権限設計は誰が決めるのか、改善の要望はどこに溜まるのか、本番環境に出す承認フローはどうなっているのか。改善を前提とした仕組みが欠けています。

生成AIの登場でコードを作るスピードは格段に上がりましたが、速さだけでは本番では使えません。セキュリティや保守性のリスクを管理する仕組みがないまま作り続けると、さらなる負債を生み再び外部への依存を高めてしまいます。



内製化の勝敗を決めるのは初期開発の完成度ではなく、ビジネスの変化に応じて改善を速く回し続けられるかです。自然言語で誰でも業務アプリが作れるバイブコーディングの時代ですが、それを本番で回せるかは別の話です。権限管理や運用、役割分担を最初から仕組みとして組み込み、内製化を「作る」から「回し続ける」へと転換する必要があります。



RetoolがPoCで終わらない理由は大きく3つあります。1つ目に、業務ツールを圧倒的なスピードでかつ柔軟に構築できること。2つ目に、SSOや監査ログなど大企業に不可欠なエンタープライズ要件を標準で搭載していること。3つ目に、最初から本番運用を前提とした設計思想になっていることです。SIerに頼らずとも、セキュアで統制の効いた環境のもと、内製で本番運用まで実現が可能になっています。

情シス部門と現場の役割分担がもたらすスケール

Retoolは企業における役割分担のあり方を大きく変えます。情報システム部門は基盤設計やセキュリティ、ガバナンスといった本来注力すべき領域に集中し、現場の事業部門が自ら画面の改善や業務変更を行いPDCAを主体的に回す。特定の人に依存することなく組織全体で改善が回り、エンジニアはより高度な基盤開発に集中できるようになります。



Retoolは2018年のローンチ以来、すでに世界1万社以上が導入しています。重要なのは1万社という数ではなく、PoCで終わらない思想を持つ企業がRetoolを選択しているということです。日本国内でもこの後ご登壇いただくファストドクターさんのように、PoCや初期開発で止まらない「回り続ける内製開発」を実現し始めている企業が出てきています。

我々GxPは日本唯一のRetoolの公式パートナーとして、2020年から日本国内で内製化を止めずに回し続ける支援を続けてきました。日本の組織特有の意思決定プロセスやガバナンス要件を踏まえた、実効性のある内製化設計をお客様と一緒に考え推進しています。提供しているのはライセンスだけではなく、内製化の設計図そのものです。内製化に必要なのは単に作る技術ではなく、変化に耐え、変化を回し続けられる仕組みです。本日はその具体的なアプローチをぜひ体験してください。それでは井本さん、よろしくお願いします。

ファストドクターの事業と医療が直面する3つの課題

井本：ファストドクターの井本と申します。本日は主にRetoolを活用し、私を含む非エンジニアを中心にPDCAサイクルを回せるに至った実例と、それを経て得た具体的な学びについてお話しします。

弊社ファストドクターは2016年に代表の医師・菊池が立ち上げた医療プラットフォーム企業で、従業員数は162名です。



我々が向き合う課題は大きく3つあります。1つ目は医療供給バランスの崩壊です。2040年には日本の全人口の約35%が65歳以上になると推計されており、医療需要が高まる一方で担い手となる生産人口は減少していきます。2つ目は救急車の軽症利用の増加です。救急搬送は年々増加していますが、約半数が救急搬送は不要であったというデータも出ています。

3つ目はかかりつけ医の高齢化です。開業医の約4人に1人は70歳以上になっており、地域の診療所が継承問題を抱えている状況です。こうした背景から、代表の菊池が救急医として勤務していた時代に、特に夜間や休日に緊急性の高くない搬送患者が相次ぐことで重症患者への対応が遅れるという負の連鎖を目の当たりにし、ファストドクターを立ち上げました。



これらの社会課題に対して、私たちは「生活者の不安と医療者の負担をなくす」というミッションを掲げています。祖業である往診事業だけでなく、オンライン診療やかかりつけ機能の強化など、多様なサービス形態でミッション実現に向けた取り組みを拡大しています。病院機能の前段階であるかかりつけ機能や病院前機能を補完・強化する位置づけを担っています。

現在、約20の医療機関と提携し、約5,000名の医師が登録するプラットフォームを運営しています。在宅事業、オンライン事業、医療系支援事業の3つの基幹事業を展開し、テクノロジー部門が各事業の成長をさらに加速させています。本日は私自身が所属するオンライン診療サービスでの事例をご紹介します。

改めまして自己紹介させてください。私自身は大学卒業後、SIer企業にて4年半勤務し、当時走りであったBIツールの構築を主に担当していました。その後、総合コンサルティング会社にて約10年勤務し、製造業から小売・商社など様々なドメインの企業様の業務標準化や基幹システム導入プロジェクトを担当してきました。約4年半前の2021年にファストドクターに入社し、入社後しばらくはテクノロジー部門のDX担当として社内生産性改善をリードしていました。その後、事業部側へ所属を移し、現在は新しい診療科の立ち上げやLTV向上に向けた企画立案・実行のリード、医療品質グループの統括を担当しています。

POCからコアプロダクト化へ至る3ステップの拡大方針

弊社のオンライン事業では、新規事業のメインとして新たな診療科の立ち上げを置いています。元々は急な発熱などの急性期症状をメインとしたサービスを展開していましたが、ビジョン2030として「一億人のかかりつけ機能を担う」を掲げ、慢性症状を診れる診療科を拡充しています。



新規診療科の立ち上げとプロダクト拡大はスリーステップで実行しています。ステップ1がPOCフェーズで、新規事業を開始するのに必要な最小限の仕組みをRetool等で迅速に構築します。ここでまさにRetoolを多く活用しています。

ステップ2がPMFフェーズで、各診療科ごとに設計したKPI──新規獲得数と平均利用回数など──の達成をもとにPMFを判断します。PMF達成に向けてユーザーニーズの適合性検証を数多く実施していきますが、そのサイクルにもRetoolを活用しています。ステップ3がコアプロダクト化のフェーズで、PMFが判定された診療科はローコードツールやスプレッドシート、手運用を交えながら拡大してきたものを、基幹プロダクトへ統合していくフェーズになります。

オンライン診療は、予約、受付、診察、処方、算定、請求、フォローアップという標準プロセスになっています。大まかなプロセス自体はどの診療科でも同じですが、診療科によって期待されるニーズが異なります。急性期では「一秒でも早く薬が欲しい」というスピードが最大の価値である一方、慢性期では利便性と継続性が重視され、心療内科では「前回と同じ先生に診てもらいたい」というように科目ごとに期待値が細分化されます。こうした多岐にわたるニーズに対応する施策をいかにクイックに実行・検証できるかが非常に重要です。

Retoolで構築した3つの業務ツールと定量成果

Retoolは非エンジニアでもドラッグ&ドロップで業務画面を構築できるローコードツールです。SQLやJavaScript、Pythonによる独自ロジックの記述や、外部データベース・APIとの連携も可能で、こうした柔軟性から弊社での採用に至りました。PoCフェーズで具体的にどんなプロダクトを作ったのか、実例をご紹介します。

1つ目は新しい診療科の案件管理ツールです。患者情報の表示、書類発行管理、フォローアップ管理など、業務に必要な項目を自由にカスタムして登録でき、データベースに一元管理されます。事業推進担当が1人で約3週間で構築し、スプレッドシートや手運用と比較して約40%の運用コスト改善を実現しました。

2つ目は処方箋発行ツールです。コアプロダクトから処方箋データを取得し、ドキュメント作成からFAX送信までを自動化する仕組みで、ステータス管理やフィルタ機能も備えています。2名体制で約1カ月で構築しました。作業ログ分析のダッシュボードも併せて作成し、オペレーション改善を行うことで診察から処方箋作成・送付までのリードタイムが約55%短縮しました。

3つ目はRetool Workflowで実装した次回予約日の自動リマインド機能です。コアプロダクトからデータを取得し、外部API経由でSMSを送信するというシンプルな作りで、送信履歴をデータベースに蓄積して効果検証ができるようになっています。毎日スケジュール起動で自動実行され、エラー発生時はSlackへ担当者にメンション通知される仕組みです。

実はこの仕組みは私自身が設計・実装したもので、テスト込みで約2時間で作成しました。施策開始判断の直後に実装し、翌日から検証開始できるスピード感です。実績として、無断キャンセルを約10%抑制することができました。



2026年2月現在、Retoolのアプリ数は152、ワークフロー種類数は107、月間のワークフロー実行数は42,000回、アクティブユーザーは231名となっています。大半の社員とアルバイトがRetoolで毎日何らかの業務を行っている状況です。

これらのアプリやワークフローは、私を含む非エンジニアでほぼ全てを開発しています。エンジニアはコアプロダクトの開発に集中でき、PoCに必要な開発コストも圧倒的に抑えることができています。

PDCAサイクルを高速に回すための4つの要件

この成果を生み出すために重要であったことを4点まとめました。1つ目は人です。非エンジニアがメインでしたので、コーディングを含むテックスキル自体はエンジニアに劣る一方、エンドツーエンドで業務解像度が高い人材がRetoolプロダクトを開発しました。現場の一次情報を解像度高く理解し、筋のいい仮説や課題抽出を自ら立てられるということが重要でした。

2つ目は検証設計とそのスキルです。PDCAサイクルを高速に回すには、実行後のデータ分析や可視化をクイックにできることが求められます。3つ目はそれを実現するためのデータ基盤です。弊社ではあらゆるデータをBigQueryに集約しているため、探索的なデータ分析が可能になり、精度の高いデータ検証を実現できました。

4つ目は振り返りの徹底です。スクラム開発的な考え方を取り入れ、一般的な週次サイクルに対してRetool開発では午前中に開発したものをすぐ午後にフィードバックを受けるスピード感で回していました。1つ目や2つ目のスキル面を一人で補えない場合は、少人数のチーム体制でカバーするという方法もあります。

POC・PMF・移行期それぞれの失敗と教訓

ここまで主に成功ポイントについてお話ししてきましたが、当然多くの失敗や教訓もありました。



POCフェーズでは、Retoolは設計やコーディングの自由度が高い一方で、設定に任せるのかコーディングで実装するのかという基準が属人化してしまいました。開発標準の粒度が粗かったという反省があり、品質とスピードのトレードオフを許容しつつ開発標準の強化を同時に行うべきでした。また、基幹システムの中間プロセスにRetoolプロダクトを置いたケースでは、トラブル時にプロダクトをまたいでデータ整合を担保しなければならず、運用保守の難易度が格段に上がりました。基幹システムの枝に位置するプロセスのみにRetoolを適用するか、コアプロダクトへの移行前提で超短期間利用を目的とするなど、適用箇所の吟味が重要だと学びました。

PMF期に顕在化したのは、データ量や処理トランザクション数が増加した時のデータ不整合などの課題です。この時期は非機能要件に関わる課題が多く発生し、スピードを重視しつつも初期段階からエンジニアレビューのプロセスを組み込んだ方がベターでした。

コアプロダクトへの移行期では、Retoolはローコードツールとしての制約や癖があるため、完全スクラッチで開発しているコアプロダクトとデータベース構造やソースコード構造がフィットしない場面があり、移行に想定以上の工数が発生しました。設計時点でコアプロダクト化を見据えたエンジニアレビューを組み込むか、移行時の追加工数を織り込んで進めるコンセンサスがあるとよかったと振り返っています。

全体的には、1名でもRetoolに明るいエンジニアを任命するか、GxPさんのようなプロに相談しながら進められる体制が取れると、我々が経験した大変さは回避・抑制できたと感じています。

非エンジニアによるプロダクト開発の民主化とその先

組織としては、Retoolによってプロダクト開発がより民主化されました。私のような元コンサルやPdMなどの非エンジニアへプロダクト開発の裾野を広げることができたことで、プロダクト開発のエンジニア依存は圧倒的に抑えることができました。同時にPDCAサイクルのスピードも上がりましたし、さまざまな運用危機をRetoolによって回避・打開できたのも事実です。

失敗から得た教訓を活かして、ローコードツールでの開発プロセスを改善し、エンジニアと非エンジニアがより共創していくことで、さらに強い事業組織とプロダクト開発組織を目指せると感じています。

ただ、我々の実態としては、まだまだ多くのプロセスに人が介在して操作や判断をしている状況です。今回ご紹介したツール群も、人が判断して操作するというプロダクトが主でした。仕組み化でここまで成長してきたファストドクターですので、今後はAIエージェントを活用した自動判断を実現する世界線を目指していきたいと考えています。

ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。