ソリューション
連携し、整合性を保ち、監査に耐えるエンタープライズシステム
私たちは、組織の業務を支える社内アプリケーションとワークフロープラットフォームを構築し、既存のシステムと接続し、レガシー資産を境界の明確な単位ごとに一つずつモダナイズします。
課題の全体像
エンタープライズソフトウェアを特徴づけるのは、機能よりもそれを取り巻く環境です。新しいアプリケーションが導入される先には、すでにERP、CRM、人事システム、データウェアハウス、誰も全容を把握していないいくつものデータベース、そしてそれらのシステムが担っていない業務を引き受けるスプレッドシート群があります。新しいアプリケーションの価値は、それらすべてとどれだけ適切にデータをやり取りできるか、そしてどのシステムがどの事実を所有するかをどれだけ明確に定められるかで決まります。
繰り返し現れる問題は、連携と整合性です。1件の注文がCRM、ERP、倉庫管理システムに、3つの異なるステータスで存在します。顧客レコードが2か所で編集されています。夜間バッチジョブが誰にも気づかれずに失敗し、経理部門は月末になって初めてそれを知ります。所有権とデータフローに手を付けないままアプリケーションをもう1つ追加すれば、そのアプリケーション自体がどれほどよくできていても、状況は悪化します。
モダナイゼーションでは、さらに慎重さが求められます。レガシーシステムには、他のどこにも残っていない数十年分の業務ルールが埋め込まれていることが多く、それを1つのプログラムで一括して置き換える試みは、業界全体を見ても成功例が多くありません。私たちは段階的な変更を選びます。レガシーシステムの前に安定したインターフェースを置き、機能を1つずつその背後へ移し、結果が一致するまで新旧を並行稼働させ、その後で旧経路を廃止します。
なぜ難しいのか
エンジニアリング上の課題
ポイントツーポイント連携の乱立
新しいシステムが導入されるたびに、個別のスクリプト、ファイル連携、データベースリンクによって他の複数のシステムと直接つながれていきます。数年も経つと、あるフィールドを変更したときに何が壊れるのかを誰も答えられなくなります。連携部分は、資産全体の中で最も脆く、最も文書化されていない箇所になります。
単一の所有者がいない共有データ
複数のシステムが同じ顧客、商品、価格を編集できると、それらは食い違っていきます。レポートは参照元によって数字が合わず、担当者は手作業での突き合わせに時間を費やします。根本原因は、エンティティごとの記録システム（システム・オブ・レコード）が宣言されていないことにあります。
複数システムにまたがる更新
発注書の承認のような業務操作では、ワークフローシステム、ERP、通知サービスへの書き込みが必要になることがあります。これらをまたぐ分散トランザクションは存在しません。1つ目の書き込みが成功した後に2つ目が失敗すると、組織には、どのシステムも正当とは認めない状態が残ります。
止めることのできないレガシーシステム
置き換え対象のシステムは、いまも業務を動かし続けています。そこには文書化されていない挙動、バッチウィンドウ、テーブルを直接読み取る利用側システムが存在します。きれいに切り替えられることを前提にしたカットオーバーは、こうした依存関係を本番環境で発見することになりがちです。
ロールでは収まらなくなる認可
アクセスルールは少数のロールから始まり、やがてロール、部門、地域、承認限度額、権限委任からなるマトリクスになります。アプリケーションコードに散在していては、レビューは不可能です。監査人から、特定の日付にある取引を誰が承認できたのかを問われても、誰も確信を持って答えられません。
後付けの監査証跡
更新者の列と更新日時のタイムスタンプだけでは、以前の値が何であったか、誰がその変更を承認したか、上流のどのイベントが原因だったかは分かりません。アプリケーションログから履歴を再構成する方法は信頼できません。監査可能性は、データモデルそのものが備える特性でなければなりません。
構築の進め方
アーキテクチャ
アプリケーションは、業務ドメインに沿ったサービスまたはモジュールの集合として構築し、各外部システムを安定したコントラクトの背後に隔離する連携層を通じて、周囲のシステム群と接続します。
- 01
ドメインサービス
調達、承認、ケース管理といった業務機能は、明確な境界と固有のデータを持つモジュールとして実装します。これらを1つのモジュラーアプリケーションとしてデプロイするか、個別のサービスとしてデプロイするかは、チーム構成とスケール要件によって決まります。重要なのはデプロイ単位よりも境界です。何を独立して変更できるかを決めるのは境界だからです。
- 02
連携層と腐敗防止層のアダプター
各外部システムは、そのモデルとアプリケーション自身のモデルとの間で変換を行うアダプターで包みます。ERPの癖、レガシーなフィールド形式、ベンダーAPIの変更は、そのアダプターの中に封じ込めます。同期呼び出しは、タイムアウトとサーキットブレーカーを備えたAPIゲートウェイを経由します。データの伝播にはイベントまたは変更データキャプチャ（CDC）を使うため、下流システムが遅くてもユーザーの操作を妨げません。
- 03
ワークフローエンジン
承認、エスカレーション、タイマーを伴う長時間実行のプロセスは、ステータス列やスケジュールジョブに分散させるのではなく、ワークフローエンジン上で明示的にモデル化します。エンジンはすべてのインスタンスの状態を永続化するため、プロセスは再起動を越えて継続し、現在のステップを常に確認できます。プロセス定義はバージョン管理し、実行中のインスタンスは開始時のバージョンのまま完了します。
- 04
OutboxとSagaによる整合性
サービスは、トランザクショナルOutboxパターンを用いて、状態の変更と対応するイベントを1つのローカルトランザクションで書き込み、リレーがそのイベントを確実に発行します。複数システムにまたがる操作は、各ステップに補償アクションを定義したSagaとして調整します。コンシューマーは冪等であるため、再配信されても安全です。照合ジョブがスケジュールに従ってシステム間を比較し、差異があれば報告します。
- 05
IDと認可
ユーザーは、シングルサインオンを通じて社内のIDプロバイダーで認証します。認可は、ロールに組織単位や承認限度額といった属性を組み合わせ、中央のポリシーコンポーネントで評価します。そのルールはレビュー可能な設定として保持します。申請者は自分の申請を承認できないといった職務分掌の制約も、ここで強制します。
- 06
監査・履歴ストア
すべての状態変更は、実行者、時刻、変更前後の値、そして原因となったリクエストまたはイベントの相関IDとともに、追記専用のエントリとして記録します。この記録は変更と同じトランザクションで書き込まれるため、省略されることはありません。これにより監査クエリに対応でき、任意の日付時点のエンティティの状態を再構成できます。
- 07
モダナイゼーションのためのストラングラーファサード
レガシーシステムの前段にルーティング層を置き、機能ごとに旧実装または新実装のいずれかへ振り分けます。機能は1つずつ移行し、新旧を並行稼働させて出力を比較したうえで、トラフィックを切り替えます。機能が廃止されるにつれてレガシーシステムは縮小していき、どの段階でも、切り戻せる動作中の経路が残ります。
クライアント
- Webアプリ
- モバイルアプリ
- パートナー連携
APIゲートウェイ / BFF
- ルーティング
- 認証
- レート制限
- レスポンス整形
ドメインサービス
各サービスが1つの境界づけられたコンテキストを担う
- 注文
- 決済
- カタログ
- アカウント
- 通知
非同期メッセージング
- Kafkaトピック
- アウトボックス発行
- イベントコンシューマー
- デッドレターキュー
データストア
サービスごとにデータベースを持ち、テーブルは共有しない
- サービス別PostgreSQL
- Redisキャッシュ
- 検索インデックス
- オブジェクトストレージ
プラットフォーム
- トレーシングとメトリクス
- ログの集中管理
- CI/CDパイプライン
- サービス設定
プロジェクトの成果物
- ドメインモデルと、共有データの記録システム（システム・オブ・レコード）マップ
- 文書化されたAPIとイベントコントラクトを備えたアプリケーションサービス
- ERP、CRM、レガシーシステム向けの連携アダプター
- 承認、エスカレーション、権限委任のルールを含むワークフロー定義
- 監査履歴を備えたロールベース・属性ベースのアクセスモデル
- システム間の照合ジョブと差異レポート
- 並行稼働とロールバックの手順を含む段階的な移行計画
着手する前に
早い段階で決めておくべきこと
- パッケージ製品を設定して使うか、開発するか
- プロセスが標準的で、製品の流儀に業務を合わせる用意がある場合は、パッケージ製品を使います。財務会計、給与計算、基幹人事がその代表例です。プロセスが差別化の源泉である場合や、パッケージをカスタマイズするとアップグレードのたびに製品と格闘することになる場合は、開発を選びます。パッケージシステムへの過度なカスタマイズは、主導権を得られないまま、スクラッチ開発並みのコストを負うことになりがちです。
- システム間は同期APIか、イベントか
- 受注入力時の与信チェックのように、呼び出し側が先へ進むために応答を必要とする場合は、同期呼び出しを使います。他のシステムが、何かが起きたことを知るだけでよい場合は、イベントを使います。イベントは結合度を下げ、障害を吸収します。その代償は結果整合性であり、ユーザーとレポートがそれを許容できるように設計しなければなりません。
- レガシーシステムを置き換えるか、ラップするか
- システムが安定しており、ロジックも健全で、主な問題がそのデータや機能へのアクセスにある場合は、ラップします。システムが変更の妨げになっている場合、サポートの切れた技術の上で動いている場合、組織から失われつつあるスキルに依存している場合は、段階的に置き換えます。1回のリリースでの全面的な書き直しが正当化されるのは、網羅的に検証できるほどシステムが小さい場合に限られます。
- どこまで厳密な整合性が必要か
- 操作ごとに判断します。会計仕訳の計上や在庫の引き落としは、一般に発生した時点で正しくなければならず、1つのトランザクション境界に収めます。検索インデックス、ダッシュボード、通知は数秒遅れても問題ありません。こうした要件を明示的に定めることで、過剰な設計と、気づかれない不整合の両方を避けられます。
FAQ
よくあるご質問
当社のERPやCRMと連携できますか。
連携の可否は、そのシステムが公開しているインターフェースによります。REST APIやSOAP API、メッセージキュー、ファイル交換、あるいはデータベースレベルの変更データキャプチャなどです。私たちはまずそれらのインターフェースを評価し、サポートされていて安定しているものを軸にアダプターを構築します。ベンダー名は説明のために用いているものであり、当社がいずれかのベンダーとのパートナーシップや認定を主張するものではありません。
モダナイゼーションの間、業務をどのように継続させますか。
機能を1つずつルーティング層の背後へ移し、新しい実装を旧実装と並行して稼働させ、結果を比較してからトラフィックを切り替えます。各ステップにはロールバック手順を定めます。まだ移行していない部分については、レガシーシステムが引き続き正となります。
ローコードプラットフォームは使いますか。
適している場面では使います。ローコードツールは、連携要件が控えめな単純なフォームや部門内ワークフローに有効です。ロジックが複雑な場合、処理量が多い場合、変更に適切なバージョン管理、テスト、レビューが必要な場合には、制約になります。私たちは、いずれかの手法への好みではなく、プロセスの性質に基づいて提案します。
本番稼働後は誰がシステムを運用しますか。
それは最初の段階で合意します。システムは、お客様のチームが運用できるように、Infrastructure as Code、監視、ランブック、ドキュメントとともに納品します。Staroneが別途の取り決めのもとで、継続的なエンジニアリングと運用の支援を提供することも可能です。