業務系システム、情報系システム
システムと言うと多くの方が１つの種類だと感じていることも多いと思います。今では、SoR(System of Recording)とかSoE(System of Engagement)とか言われていますが、個人的にはしっくり来ていません。
これからお話しするのは、私が25年以上前に提唱したシステムの相違についてです。なので他では聞いたこともない情報となります。
金融系フロント、バックオフィスシステム
きっかけは、金融のトレーディングシステムの設計に携わっていた時です。野村総研時代ですね。その頃の私はQuants（金融数理学）の観点と、トレーダの意思決定プロセスの観点から設計に携わっていました。
トレーダはいろんな情報を必要とします。現在のポジションもそうですし、様々なマーケット情報に至るまで、意思決定するために様々な情報を必要とするわけです。
しかも人によって求めるものが異なります。つまり画一的な仕組みを考えていては全然対応できないわけです。
従来のシステムはバックオフィス系が主体。早い話、受渡管理を行うシステムです。こちらも新しい要件は増えたりしますが、人によって大きく異なることは有りません。
この二つのシステムを見ていて、当時から何か「違い」を感じ始めていたわけです。
トレーディングシステム（フロントオフィス系）の場合、マーケット情報を使い、様々な表現で表示する必要があります。自ずとたくさんの画面があるわけです。当時のシステムはそれらを全部作っていました。
私はもともとゲームプログラマ。いろんな要望に応えるためには、どういうシステム構成であるべきか？を常に考える癖がついていたのですね。
そのため、
・データソース：リアルタイムデータ、属性データ
・計算部分：計算サーバー
・表示部分：ティッカー、テーブル、チャート
と明確に分離した構成を考えたわけです。
これって、今でいうと「MVC」的発想ですね。（MVCモデルは1979年パロアルト研究所で生み出されたようです。当時はそれを知らずにモデル化していました。ですが当時の上司は全く理解できなかったようです。「これで何ができるの？」と言われました。笑）
データに対する要求度も異なります。当然正確性は必要なのですが、それよりも迅速性。約定データは実際には受渡時に確定するのですが、そんなことをやっていたらポジションが分かりません。修正入る場合もありますが、フロントで処理するわけです。
つまり、バックオフィス系とフロントオフィス系はデータの振る舞いもシステムの作りも全く異なるわけです。
バックオフィスシステムの特徴
バックオフィスシステムは「バックオフィス業務」をつかさどるものです。特徴としては
・10人に聞いても方式は１つに定まる。
・迅速性より正確性を求める。
・確実性を求める。
など。
10人聞いても方式は１つに定まるのは、業務として定義されているためです。皆バラバラな作業をしていては統制取れないので当たり前ですね。
バックオフィス系の最たるものが「会計システム」です。
これこそ正確性の塊。
本来は、単に「記録しているだけ」（最近ではSoR＝System of Recordingと言うようですが）の仕組みです。ですが、単に記録するだけではなく「正確に記録する」ことを求められています。なのでロールバックやらトランザクションログやら正確性を担保するための仕組みがあちこちにあるわけです。
そのため、単に「記録」と言いながらもかなり複雑なことをしています。念には念を入れて的なモノ。
人間系業務でいうのであれば、「経理作業」そのものですね。
ただしく費目を選択し、処理する。締めという概念を持ち、確定したらデータを変えることはしない。変更する場合は「赤黒処理」的処理をする。
という具合です。
すると、どういうシステムになるかと言うと、「ガチガチ」の仕組みなわけです。しっかりと要件定義を行い、業務プロセスフローも定義、確認し、エラーハンドリングなども確認するわけです。自ずと工数もかかりますし、一度作ってしまうと改修することも大変というわけです。建築に例えるのであれば、がっちりしたビル建築みたいなものですね。
業務を中心に作られるので「バックオフィス＝業務系システム」とでも呼ぶことにします。
フロントオフィスシステムの特徴
一方フロントオフィスシステム（フロントシステム）は「フロント業務」をつかさどるものです。特徴としては
・10人に聞くと十人十色の要望が返ってくる。
・正確性は必要だが、迅速性の方が重要。
・意思決定のための情報を求める。
など。
ここで重要なポイントが「意思決定」です。
つまり、人間が何かしらの意思決定、行動をしたいから「情報」を求めているわけです。決まりきった「業務」を行っているわけではないということ。なので、人によっても異なりますし、同じ人だとしても急に要望が変わったりもします。
人間系業務で言うのであれば「営業業務」ですね。
相手によって行動を変えたり、やり方を変えたり。臨機応変に対応することが求められます。会計側（バック）では1円2円が重要ですが、営業系（フロント）では（多少は間違っていても）迅速性の方が要求されるケースもあります。特に、予実管理とかになると「予算」部分が曖昧なわけですからなおさらです。月末の収益を見たいのに、経理が締めてから・・となると困るわけです。
このようにデータの振る舞い方も異なります。
同じように建築で例えるのであれば、プレハブ住宅とか究極はテントですね。すぐにでも変えられる自由度が欲しいわけです。
情報（を取得して意思決定すること）を中心として作られるので「フロントオフィス＝情報系システム」と呼ぶことにします。
これら2つを比較すると当然、工法、構造も大きく異なります。皆さん、「システム」というとどうしても同じものに感じてしまうのですね。ですが、建築に例えると、これだけ違うと言う事、一目瞭然と思います。
業務系から情報系へのシフト
歴史をたどると最初に入るのは業務系システムです。会計などが重要だからです。これを俗に「基幹系システム」と呼んでいます。確かにこれがないと会社が回らないので「基幹」なわけですね。
なので、どうしてもこれをベースに考えてしまうのです。
すると、今までこんなことやってませんか？業務系システムに上記のような情報系システムを組むという行為を。
具体的には
・顧客メールアドレスを格納するようになったので、メールでお客様に情報を配信したい。⇒できたら、顧客属性別に送るものを変えたい⇒反応も見たい。
・基幹系に予実管理の仕組みを組み込みたい。
・限度額やコンプラの機能を組み込みたい。
（正確には限度やコンプラは私の頭の中では「ミドル」という概念になります。情報系の一種ではありますが、若干位置が異なります。理由はバックシステム内部でも動く可能性があるからです。）
おそらく、上記のようなことをやっていると思います。
これ、どう思いますか？
上記で書いたものは、人によってやり方が異なりませんか？要は改修要望が常に出て、バックログとなってしまう可能性が高いものとなります。
これが引き起こすものは何か？ということなのですが、
・カスタマイズ、変更に高いコストが発生する
ということなわけです。
今までの説明でお分かりと思いますが、ガチガチの仕組みに柔軟性を要求するものを突っ込んでいるから当然ですね。
建築に例えるのであれば、一時的に必要な機能なのに、コンクリートを打って強度も十分な構造物を作ってしまうようなものです。これでは、撤去するのも大変。これと同じです。
そしてこれがさらに引き起こすものは何かというと、基幹系システムの刷新に影響するわけです。
この辺については、またの機会に説明します。（簡単に言うと、カスタマイズ費などから倍以上の金額に膨れ上がる原因がここにあります。）
業務（バックオフィス）系、情報（フロントオフィス）系システム
整理すると次のようになります。
業務系（バック系）システム
・業務プロセスとして確定している。（10人に聞いても1手法）
・人間の意思は基本入らない。（業務として確定しているので）
・変更される頻度は低い。
・迅速性より正確性を優先する。
・頑健性を要する。（エラー修正やエラーハンドリングなども厳密）
情報系（フロント系）システム
・業務プロセスが確定していない。各人各様。
・人間の意思、判断が入る。
・変更される頻度は高い。
・正確性より迅速性を優先する。
・柔軟性を要する。
これだけ明確に異なるわけです。
世の中のニーズから考えると、まず間違いなく業務系が必須となります。なので、ここからスタートします。ですが、使っていくと、情報系のニーズが少しずつ出てくるのですね。これらは結果「カスタマイズ」という形で組み込まれてしまいます。
私から言わせてもらえれば、
・本来一緒にしてはいけないものを一緒にしてしまった
⇒技術負債＝機会コスト、潜在コストを増大させてしまった。
ということになるわけです。
軽微なものであれば、多少追加しても構わないのですが、これを意識して追加するのと、メクラ状態で追加するのは大きな相違です。意識しているのであれば、どこかのタイミングで新たに情報系システムを構築する計画を立てるはずだからです。
このシステムの性質の相違は単にシステムだけを見ていてはわかりません。これを理解するには業務プロセス、データの振る舞い（この言葉よく私は使うのですが）をきちんと理解していなければわからないと思います。
最後に
業務系システム、情報系システム。これらをごっちゃにすると、大きな問題を引き起こす＝多大な潜在的コストが発生することはご理解いただけたと思います。ですが、これが普通できないのですね。
これがデータの振る舞いを理解するという意味です。（業務系データ、情報系データの相違についてもどこかで詳述しようと思います。）
本来のDXコンサルはこの辺のデータの機微な動きまで見て行うのです。単なるシステムコンサルとは次元が異なるということです。
Copyright🄫 2024 Emzstyle.LLC
無料で1対1の相談に乗ります。詳しくはこちらへどうぞ
https://emz-style.com/onlineweb