リファクタリングの大まかな方針を再考した

Sat, 06 Jun 2026 00:00:00 +0900

ここまで、評価ステータスの管理からモデリングしてきたが、このままだといっこうに計算エンジンにたどり着ける気がしない。いったん仕切り直し、契約をベースとしてパッケージを分割する方法を考えてみる。

やりたいこと

最終的には:

資源評価業務がスムーズに回るようにしたい
ステークホルダーの納得感を高めるための技術的制約を取り払いたい

そのために:

資源評価「業務」の本質を抽出する必要がある: すぐには無理。身動きを取りやすい状態にしてから、徐々に進めていくとよい
計算エンジンには R を使い続けたい: 既存資産を有効利用したい
DB に業務データ（試算を含むパラメータセット）が溜まるようにしたい: これも事業の成果としてアーカイブしていく必要がある

これらの前提のもと、資源評価業務アーキテクチャの As-Is と To-Be を考えてみた。

As-Is

アーキテクチャといえる構造はない。雑だが、As-Is は下図のような状態にある:

現時点における資源評価の作業スタイル

破線矢印は、矢印の根本が矢印の先を利用していることを表している。

図が表す通り、現状では各担当者が単一の R パッケージをスクリプトから呼んで計算している。結果を報告書にする際には .docx で執筆している。この方法の利点・欠点は下記の通り:

利点 ✅:

R スクリプトでなんでもできる
複数の担当者に影響する単一障害点がない
インフラ料金がかからない
コードベースが 1 つだけという意味で認知負荷が低い

欠点 ❌:

同じ操作を複数人でやる必要があるという意味で人件費が無駄になる
環境（ランタイムやパッケージのバージョン）についての強制力がない
担当者のマシンがその資源の単一障害点となる
実行環境を監視できない
手続きが形式知化されていない
人件費投資の蓄積性が低い
シナリオ・パラメータ数のスケール性が低い
パッケージのビルド時間が長い

そういえば、複数の担当者に影響する単一障害点がないのはけっこう大きい利点かも。

To-Be

資源評価の業務特性を考えると、To-Be アーキテクチャは例えば下図のような感じになるだろう:

シナリオやパラメータの並行計算に有利なアーキテクチャの一例

破線矢印は利用を表し、実線矢印は（呼び出しではなく）データの流れを表している。マルチテナント観点でのリソース構成についてはまだ考えていない。

ステークホルダーに納得感を持ってもらうには、豊富なシナリオ・パラメータの組み合わせを計算するために並行ジョブ実行の仕組みが必要だ。何より、結果再現に必要な歴代のパラメータセットが一元管理されていることが重要だ。過去の結果を再検証する必要が「実際に」生じるかどうかはわからないが、数値を扱う国の事業には、こういった追跡性が保証されている必要があるだろう。現在の仕組みでも再現できないことはないが、ランタイムの調達のことを考えれば、時間が経つにつれて難しくなるだろう。

詳しいアーキテクチャは検討の余地がまだまだあるが、とにかく web アプリケーションに移行した場合の利点・欠点は下記の通り:

pros ✅:

共通処理の再利用性が高いため人件費の無駄がない
環境（ランタイムやパッケージのバージョン）を統一管理できる
担当者は web ブラウザだけあればよい
実行環境を監視できるためパフォーマンスチューニングやデバッグに有利
手続きをドメインモデル化することで形式知化できる
開発に当時た人件費はシステムに変化するので蓄積性が高い
シナリオ・パラメータセットごとに並行ジョブにできるためスケール性が高い
R パッケージを責務ごとに分割できるため、各機能の開発速度が上がる

cons ❌:

ad-hoc な対応など、R スクリプトが吸収していた自由度は減る
- この自由度をいい塩梅にするのが設計の一つの見せ所となる
障害発生時には複数の担当者が影響を受ける可能性がある
- インフラコストと対障害性能のトレードオフ設計が重要になる
インフラ料金が発生する
- こればかりはどうしようもない
複数のコードベースを意識する必要が生じる
- 適切な責務分離が重要になる

最初のステップ

パッケージを安全に分割するためには、単一パッケージをモノリスアプリケーションにしたうえで、契約レイヤーを介して利用するところから始めるとよい:

まずモノリスの web アプリケーションとして動かす

破線矢印は利用を表し、実線矢印は（呼び出しではなく）データの流れを表している。赤い四角で示した契約レイヤーを維持する限り、バックエンドアプリケーションの構成は自由に変更できる。

責務分割の第一歩は、既存の R パッケージを利用するモノリスの隣に、新しいサービスをデプロイすることから始める。このサービスは、既存の R パッケージをそのまま使うが、責務は契約の一部だけに限る。計算の重さを考えると、将来予測部分を切り出すとよいのだろうか。分割できたら、その機能についてのリクエストが新サービスを向くように契約レイヤーを変更する:

同じパッケージを使うが物理的には分割する

アプリケーションがバックエンドに新サービスを利用して動く状態になったら、次のステップへの準備が整ったことになる。新サービスが利用するパッケージの責務を小さくしたり、データベースへの保存を始めたりなど、必要な変更を施していく:

契約を維持したまま必要な変更を施していく

まとめ

以上、アーキテクチャ観点でのリファクタリングの方針を考えてみた。これまで、資源評価事業全体をスコープとして見切り発車してしまっていたが、いったん仕切り直し。まずは評価ステータスの管理などは無視してみる。つまり、R スクリプトを使った既存の担当者業務の web アプリケーション化。計算フローを 1 周回すのだけでもけっこう大変だった記憶があるが、サンプルデータを入手するなどして試してみる。

Refactor on Rindrics Mumbles

リファクタリングの大まかな方針を再考した

やりたいこと

As-Is

To-Be

最初のステップ

まとめ