AI ネイティブ医療企業の構築法 — Maven Clinic の Dan Feng氏

AI ネイティブ医療企業への転換：Maven Clinic が試みた組織・採用・開発プロセスの完全再構築

「トラクターは農家を置き換えるものではなく、トラクターを操れる農家がそうでない者を置き換える」という言葉があります。生成 AI の時代において、これは単なる比喩ではなく生存戦略そのものです。Maven Clinic の Dan Feng 氏は、同社が伝統的なテクノロジー企業から「AI ネイティブ」な組織へ移行する過程で、社内ツールの導入や製品への統合だけでなく、採用基準と開発プロセスの根本的な見直し、そして組織文化の変革という三本柱を掲げたと語ります。

社内ツール・製品・文化：AI ネイティブの三要素

「AI ネイティブ」という言葉には明確な定義や、これさえやれば成功するというマニュアルは存在しません。Maven Clinic が目指したのは、以下の三つの側面での徹底した変革です。

まず第一に社内ツールの活用です。日々の業務で手作業を要するタスク（日報作成、会議管理、Jira のチケット作成など）に対して、「AI でできないか」と自問することを徹底しました。特にリーダー層には、部下に指示を出す代わりに AI を駆使して自ら問題を解決する姿勢が求められています。

第二に製品への AI 統合です。これはユーザー体験の向上と運用コストの削減という二つの目的を達成するために行われます。例えば、24 時間 365 日対応可能な AI チャットボットの導入は、人間のオペレーターよりも迅速かつ安価に顧客の課題に対応できるため、大きな効果をもたらしました。

そして最も重要なのが組織文化とプロセスの変革です。単にツールを導入するだけでなく、AI が最大限に機能するような働き方そのものを再設計する必要があります。

採用基準の見直し：自律性と境界線の曖昧化を許容する人材へ

新しい技術の導入において、早期採用者（イノベーター）は放っておけばよく、重要なのは「真ん中」にいる大多数の人々です。Maven Clinic では、彼らが AI ツールを使いこなせるよう、共有インフラを整備し、使いやすさを追求しました。

しかし、最も劇的な変化が起きたのは採用と評価基準です。

従来の開発モデルでは、シニアエンジニアが問題を特定し解決策を提示して、他のエンジニアに実装を委任する「委任型」の働き方が一般的でした。しかし AI の登場により、シニアエンジニア自身も AI を使って即座に問題を解決できるようになり、「他者に委任する」という行為自体が非効率化しました。

そのため、Maven Clinic は以下のような人材を重視するようになりました。

• 自律的な問題解決能力: 誰かに指示を待つのではなく、AI を駆使して自ら問題を解決できる人材。
• PM とエンジニアの境界を越える人材: AI の力によりエンジニアは製品設計にも深く関与できるようになりました。ドメイン知識を持ち、複雑で曖昧な問題を処理できるエンジニアの方が、従来のソフトウェア専業のエンジニアよりも大きな貢献ができる時代です。

評価制度においても、「AI を活用してどれほどインパクトを最大化したか」が重要な指標となりました。AI に興味を持ち、新しい技術を学び続ける姿勢こそが、現代のエンジニアに求められる資質なのです。

アジャイル開発の再定義：長期計画から短期スプリントへ

「AI ネイティブ」な組織では、従来の開発プロセスも根本から書き換えられました。

かつては、数週間から数ヶ月かけてビジネス要件を洗い出し、設計を固めてから実装に着手する「ウォーターフォール的」なアプローチが主流でした。しかし、AI を使えば実装自体は数分で完了してしまいます。重要なのは、「実行（実装）」よりも「議論と検証」のコストが高いという点です。

Maven Clinic が採用したのは、以下のような新しい開発サイクルです。

1. 長期計画はインスピレーションとして: 「1 年後に AI が何をできるか」を夢想することは大切ですが、それは方向性を示すためのものに過ぎません。3 ヶ月や 6 ヶ月といった中期計画は、AI モデルの進化速度が速すぎて予測不可能なため、あえて行いません。
2. 短期スプリントでの迅速な検証: 焦点を「今後 2〜4 週間で何を提供するか」に絞ります。PM は次の要件を練る時間を持ちながら、エンジニアは現在のスプリントで実装・リリースを行います。
3. ドキュメントの簡素化: 数ページにも及ぶ詳細な仕様書（PRD）や設計書（TDD）よりも、2〜3 ページ程度の短いドキュメントを重視します。これはコミュニケーションと反復的な改善のためのものだからです。

「2 週間前に決めたことが間違っていた」という事態も、AI の力で迅速に修正できるため許容されます。これが、変化の激しい AI エラにおける効率的な働き方なのです。

コードレビューの変革と幻覚リスクへの対策

生成 AI の登場により、エンジニアが 1 日に書くコード量は数百行から数千行へと急増しました。これに対応するため、Maven Clinic はコードレビューのルールを大幅に改訂しています。

• 自己責任でのマージ許可: エンジニア自身が「この PR（プルリクエスト）はシンプルで問題ない」と判断すれば、他者のレビューなしでもマージを許可します。ただし、その責任はエンジニアが負うことになります。
• PR の分割と制限: 1 つの PR に含めるコード量は 500 行以内に抑えるよう徹底しました。数千行に及ぶコードは意味のあるレビューが不可能です。大規模な機能実装では、複数の PR に分割して段階的にレビューを行う「スタック PR」を採用しています。
• ラバー・スタンピングの排除: 「なんとなく OK」という形式的な承認（ラバー・スタンピング）は最も危険であると警告し、避けるよう指導しています。

また、生成 AI 特有の幻覚（ハルシネーション）リスクへの対策も講じられています。完全にゼロにすることはコストが高すぎるため、「許容される失敗」と「許容できない失敗」を明確に定義しました。その上で、多角的な検証や自動評価システム、そして将来的には監視・自己修復機能を持つ自律的なシステム構築を目指しています。

まとめ：AI は単なるツールではなく、組織の再設計を迫る

Maven Clinic の事例が示すのは、生成 AI の導入は単にツールの追加で終わらないという事実です。それは採用戦略、開発ライフサイクル、そして組織文化そのものを根本から再構築することを要求します。AI を自律的に使いこなし、リスクを管理しながら迅速に価値を生み出す仕組みこそが、これからの企業に求められる「AI ネイティブ」の姿なのです。