獣医がん症例データベース
獣医療分野の学術団体から、 「犬・猫のがん症例データを蓄積し、条件に応じた生存期間・予後情報を分析できる会員向けWebシステムを作りたい」 という相談を受けました。 しかし、参考にできる既存システムも、完成形の仕様書もありません。 複数の獣医師・専門家と検討を重ねながら、症例データの構造、検索条件、生存分析、表示方法、会員権限まで、一つずつ試作・検証するアジャイル型で開発。 約3年にわたり改良を続け、システムの主要部分と不具合修正はほぼ完了しています。 現在も複数の専門家から出される要望の調整を続けており、本番公開に向けて継続開発中です。
完成形が分からないシステムでは、最初に仕様書を固定することはできません。
「作る → 専門家が使う → 検証する → 要望を整理する → 改良する」
という工程そのものを設計する必要があります。
依頼
獣医療分野の学術団体から相談されたのは、一般的な学会サイトの制作ではありませんでした。 犬・猫のがん症例データを蓄積し、そのデータを条件別に検索・分析することで、 「同じような症例では、どの程度の生存期間が見込まれるのか」 を獣医師が診療時の参考情報として確認できる会員向けWebシステムを構築したい、という依頼でした。 蓄積された症例から条件を指定し、その条件に該当するデータを抽出。 そこから統計的な生存分析を行い、結果をグラフ等で可視化する高度な症例データベースです。
最大の問題は「誰も完成形を知らない」
通常の業務システムでは、
「現在この業務をしている」、「この帳票を出したい」、「このデータを検索したい」
といった既存業務を整理し、システムへ置き換えることができます。
しかし、この案件は違いました。
同様の完成形を参照できる既存システムがなく、専門家側にも、
最終的にどのデータを、どのように登録し、どの条件で抽出し、どのような結果を提示すれば最も有用なのか
という最終形が最初から決まっていたわけではありません。
つまり、仕様書を書いてから開発する従来型のウォーターフォール方式では対応できませんでした。
アンドワンの判断
そこでアンドワンでは、最終仕様を最初に固定せず、 仮説 → 試作 → 専門家による確認 → フィードバック → 仕様変更 → 再実装 → 検証 を繰り返すアジャイル型で開発を進めました。
たとえば、
- 症例として何を登録するのか
- 犬・猫をどう分類するのか
- がん種をどう扱うのか
- 治療内容をどう記録するのか
- 生存期間をどう定義するのか
- どの条件を検索対象にするのか
- 欠損データをどう扱うのか
- 会員ごとに何を閲覧できるのか
- 分析結果をどう見せるのか
といった内容を、専門家との検討を重ねながら決めていきました。 これは単なるプログラミングではなく、 獣医学の専門知識を、コンピューターが処理できるデータ構造とロジックへ変換する作業 です。
企画・実装
症例データベースの構築
システムでは、蓄積される犬・猫のがん症例をデータベース化。会員の獣医師が条件を指定すると、該当する症例だけを抽出し、統計処理できる仕組みを構築しました。単純なキーワード検索ではありません。複数の条件を組み合わせて対象症例を絞り込み、その症例群を母集団として分析を実行します。
そのため、
- データベース設計
- 検索処理
- 統計処理
- 会員認証
- 権限管理
- グラフ表示
を一体として設計する必要がありました。
生存期間を分析するカプラン・マイヤー法
このシステムの中核となる機能の一つが、生存時間分析です。医学研究で広く利用されているカプラン・マイヤー法を用いて、抽出された症例群から生存曲線を算出します。
死亡などのイベントが発生した各時点について、その時点まで観察対象となっている症例数と、実際にイベントが発生した症例数を用いて生存確率を順次計算し、それを累積することで生存曲線を求めます。これにより、単純な平均値ではなく、途中で追跡できなくなった症例なども考慮した生存時間分析が可能になります。
想定外の技術的課題
開発を進める中で、大きな技術的問題が発生しました。
症例数が増え、複数条件による検索と生存分析を繰り返すと、
検索・集計・計算処理がサーバー側へ集中する
ようになったことです。
そのまま全処理をサーバーで実行すると、利用者が増えた場合にCPU負荷が集中し、レスポンス低下やサーバーリソースの枯渇につながる可能性があります。
単純にサーバー性能を上げる方法もあります。
しかし、それでは利用量が増えるたびにインフラコストを増やすことになります。
そこで、処理方法そのものを見直しました。
計算アルゴリズムを分解
アンドワンでは、カプラン・マイヤー法を含む一連の処理を、「本当にすべてサーバーで計算する必要があるのか」というところから分解しました。そして、サーバーで行うべき処理と、利用者のブラウザで処理できる部分を切り分けました。
【サーバー側】
サーバーには、データベースが得意とする処理を担当させました。
- 条件に一致する症例の検索
- 必要なデータの抽出
- 日付・期間等の前処理
- 生存期間順の並び替え
- 必要最小限のデータへの整形
そして、大量の症例データそのものではなく、計算に必要となる経過時間やイベント情報などに整理したデータをWebブラウザへ渡します。
【ブラウザ側】
そこから先の生存確率計算は、JavaScriptを利用してユーザー側のブラウザで実行します。
受け取ったデータから、
- 各時点で対象となる症例数
- イベント発生数
- 各時点の生存確率
- 累積生存率
を計算。 その結果を、そのまま生存曲線のグラフ描画処理へ渡します。
サーバー集中型から分散処理へ
この変更の重要な点は、単にJavaScriptを使ったことではありません。従来、
サーバー → 検索 → 集計 → 統計計算 → グラフ用データ生成 → ブラウザへ返却としていた処理を、
【サーバー】検索・データ抽出・前処理 → 【ブラウザ】統計計算・グラフ生成
へ分離したことです。
利用者が増えても、計算処理のすべてが中央のWebサーバーへ集中するわけではありません。
つまり、サーバー性能を増強して問題を押さえ込むのではなく、システムアーキテクチャそのものを変更してボトルネックを解消しました。
高度なWebシステムでは、「動けばよい」ではなく、
どこで処理するのが最も合理的なのか
まで考える必要があります。
現在も完成していない理由
このシステムは約3年間、開発と検証を継続しています。主要なシステム機能はほぼ実装され、技術的な不具合についても修正を進めてきました。それでも本番公開に至っていない大きな理由は、プログラムが完成していないからではありません。
複数の専門家が関わる研究システムであるため、
「何を最終仕様とするのか」について継続的な議論と調整が必要だからです。一人の担当者が仕様を決定する一般的な企業システムとは異なります。専門家ごとに研究上・臨床上の視点が異なり、新たな要望や検討課題が生まれます。そのため、現在も本番公開に向けて要件整理と改良を続けています。
現在までの到達点この案件では、「完成したから成功」とは考えていません。
約3年間にわたり、
- 大規模な症例データベース
- 会員認証・権限管理
- 高度な複合検索
- 症例データ抽出
- 生存時間分析
- カプラン・マイヤー生存曲線
- グラフ可視化
- サーバー／ブラウザ分散処理
- 管理システム
など、研究用途に対応する主要機能を構築してきました。
そして、想定していなかった性能上の問題が発生した際にも、サーバーを増強するだけではなく、計算ロジックそのものを分解し、バックエンドとフロントエンドで処理を分担することで解決しました。
これは、仕様書どおりにプログラムを作るだけでは対応できない開発です。
この事例から分かること
高度なシステム開発では、最初から正解が存在するとは限りません。特に研究・医療・学術領域では、専門家自身も、
「実際に動かしてみなければ分からない」ということがあります。
その場合に必要なのは、無理に最初から仕様を固定することではありません。
- 専門家の考えを聞く。
- システムとして実装する。
- 実際に動かす。
- 問題を発見する。
- 技術的に解決する。
- 再び専門家と検証する。
この繰り返しです。
また、技術上の問題が発生した場合にも、「もっと高性能なサーバーを用意する」だけが答えではありません。
処理を分解し、データベース、サーバー、ブラウザ、それぞれが得意な処理を担当させる。
アンドワンでは、依頼された機能を実装するだけではなく、目的、データ、利用者、処理負荷、運用方法まで含め、そのシステムに最も合理的なアーキテクチャを考えて構築します。
関連ページ
事例の手段ではなく、
同じ判断方法で企画します。
同じ業種でも課題と条件は異なります。現在の状況と実現したい成果から整理します。