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

やりたいこと

最終的には:

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

そのために:

• 資源評価「業務」の本質を抽出する必要がある: すぐには無理。身動きを取りやすい状態にしてから、徐々に進めていくとよい
• 計算エンジンには 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 スクリプトが吸収していた自由度は減る
  • この自由度をいい塩梅にするのが設計の一つの見せ所となる
• 障害発生時には複数の担当者が影響を受ける可能性がある
  • インフラコストと対障害性能のトレードオフ設計が重要になる
• インフラ料金が発生する
  • こればかりはどうしようもない
• 複数のコードベースを意識する必要が生じる
  • 適切な責務分離が重要になる

最初のステップ

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

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

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

まとめ

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