🤺

システム移行検討時にインタフェースで方針検討する

2023/05/18に公開

クラウド

移行

idea

はじめに

既存システムを新規プラットフォームへ移行検討するユースケースにおいて、インタフェース視点でシステムを考えることが重要となる。プロジェクト開始時に移行やプラットフォーム選定の基本方針を決めるが、その前にインタフェース精査を行ったほうがよい。

クラウド化であったり、採用する製品が決まった上でプロジェクトが開始されるとコストや機能において、マイナスに作用してしまう。無理やりその製品に合わせた作りこみが発生してしまう等。その前にいったんインタフェースを元にしたFIT&GAPフェーズを実施することで、移行プロジェクトの大方針がきまり、スムーズにプロジェクト遂行することができる。

以下を実施する。

インタフェース種別精査
コスト精査
プラットフォーム選定方針

インタフェース種別精査

各システム間のインタフェースを洗い出し、機能単位で種別分けする。プラットフォームで具備すべき機能を洗い出す。例えば以下のような機能群で分類していく。

フロントGUI向けAPI群
Provisioning／プロビジョニング
Payments／支払いに関するインタフェース
DWH／各種データを提供するためのGW

インタフェース種別単位の対処方法を決めていく。

コスト精査

プラットフォームをクラウド化する場合は、外部システムとのトラフィックコストにも留意する。例えば、Provisioningインタフェースが一部オンプレミスのシステム群に対してプロビを実施している場合はクラウドの従量課金を考慮する必要があるし、そのプロトコルがセキュリティ上問題ないか確認する必要がある。通常はAPIの形になるが、3306ポートで接続して、直接クエリ処理とかありえるかもしれないので、セキュリティに考慮する必要がある。
種別精査を行うことで似たインタフェースを統合したり、統合しながらベストなソリューションを検討する。例えばPaymentsのゲートウェイを複数持っている場合は、一つのペイメントゲートウェイサービスに集約する、またAPI連携できるものを選定する。

システム内部のインタフェース

主要なクラウドベンダーはAWS, GCP, Azureの3社である。AIやTranslate機能はGCP、Docker等のインフラ基盤はAWSを利用する等、機能に応じて各クラウドを使い分けるユースケースは結構ある。この場合IFとして「AWS～GCP」といったクラウド間で利用しているインタフェースも管理する。利用ユーザがリニアに増加すると、それに応じてトラフィックやサービス利用のため従量料金がかかる可能性があるため。将来的に経常的にかかるコストも試算しておく。

プラットフォーム選定

インタフェースを精査すると、割と簡易なシステムでも多くのインタフェースを持つパターンが多い。オートスケールに対応したクラウド化が方針としてあったとしても、オンプレの内部システムへのインタフェースが多い場合は、クラウド化が正解とはならない。

また、インタフェース機能群単位で新しいプラットフォーム・パッケージが対象機能として具備しているかどうか、FIT&GAPを行い、FITが多い場合は、そのパッケージ製品を採用する形となるし、GAPが多い場合は、フルスクラッチでの開発の可能性が高くなり開発費用もかかることになる。

現行の市場のパッケージ製品を複数比較して、GAPが多い場合は、そのプラットフォームを利用しているビジネスプロセスが独特なものであり、それを新ビジネスプロセスとしてシンプルかつコンパクトにする等、プラットフォーム側だけではなく、ビジネス側にも展開していく課題となる。

なので、クラウド化であったり、採用する製品が決まった上でプロジェクトが開始されるとコスト面や機能性において、マイナスに作用してしまう。その前にいったんインタフェースを元にしたFIT&GAPフェーズを用意することである程度防ぐことができる。

その前提情報を得た上で、プロジェクトの基本方針を決める、

パッケージ標準機能を最大限に活用する
パッケージに合わせたビジネスプロセスにする
具備していないものは、パッケージの機能に合わせる

プロジェクト大方針があると、プロジェクト遂行が行いやすい。パッケージに合わせる大方針であれば、無い機能については運用で巻き取る、もしくはサービス終了や他サービスへの移管などで対処する。

また、プラットフォームが変わるとそれを利用している運用者への配慮も必要となる。これまでの運用から変わることを是としないオペレーターは少なからずいる。そのプラットフォームであるが故のナレッジや経験知である部分が、新しいプラットフォームに移ることでゼロとなってしまうためである。ここで大方針がないとプラットフォームで機能を開発し、運用を変えない形とするか、それともその逆かで決定せずに無駄に時間がかかることはよくある。

パッケージに寄せるか、ビジネスに寄せるかの大方針があれば、粛々と課題を解決することができる。

システム開発チームの長よりも、オペレーションチームの長のほうが発言権が強いというケースがなぜだかよくある。

その他

システム外部のインタフェースについては、そのプラットフォームが提供しているサービスに必要となる外部SaaSとのインタフェースがある。コアな価値のあるサービスを自社開発で提供しているか、それとも外部SaaSを組み合わせることによりサービスを作り上げているか、そのプラットフォームの価値が見えてくる。また、利用しているSaaSがサービス終了のリスクはないか。代替のサービスを切り替える場合の工数等リスク算出しておく。

さいごに

システム移行検討時には、大方針を経営側とコミットした上でキックオフすることが大事である。そのうえで、インタフェース視点で検討し、大方針を決めることが大切だということを書いた。