PM視点で読み解く 基幹システム運営録 3：構成は“最適解”ではない — 意思決定の積み重ねとしてのアーキテクチャ

基幹システムの構成について、「なぜこの形なのか？」と問われることがあります。
しかし実際には、現在のアーキテクチャは一度の設計で完成したものではなく、障害対応や性能改善、コスト制約、組織的事情といった現実への対応の積み重ねによって形成されたものです。

本連載ではこれまで、終わらない運営をどう管理するかという観点から基幹システムを捉えてきました。本稿ではその延長として、現在の構成を「最適解」ではなく、意思決定の履歴としてのアーキテクチャという視点から解釈してみます。

構成は「設計結果」ではなく「運用の到達点」

基幹システムの構成を見た時、多くのエンジニアはこう感じるのではないでしょうか？

• もっとモダンなアーキテクチャにできたのではないか？
• 依存関係を整理すれば、もっとシンプルになるのではないか？
• 責務の分離が甘いのではないか？
• etc...

答えはすべてYesであり、同時にすべてNoです。

「理想形」ではないという意味でYesであり、「理想形」を追求できないという意味でNoです。
エンジニアの脳裏に浮かぶ理想形に照らすと、基幹システムの構成というのはほぼ及第点を得ることができません。それは、基幹システムというものが、原初の無垢なる状態から設計されたモノではなく、現実の荒波に揉まれる中で磨き上げられた運用の到達点としての在り方に依拠するモノであるということを示しています。

そこにあるのは理路整然とした設計結果ではなく、様々な制約から生じた意思決定の履歴としての構造なのです。

なぜ理想的な構成にならないのか

一般的なエンジニア、開発者の脳裏に浮かぶ思考は、作る立場の思考であることがほとんどです。
そこには、いま現出している

• すべての要求
• すべての要件
• すべての制約
• すべての運用

が見えていることを暗黙の前提としています。
確かに、それなら理想的な構造で作り上げることができるでしょう。

しかし、この基幹システムが生み出され、そして変化していく過程において、前出の要求、要件、制約、運用がすべて見えていたことは一度たりともないのです。一度たりとも、です。

すべてを見通すことはできず、この先どうなるかわからない状況下。それでも行われてきたこと、それは意思決定の積み重ねです。基幹システムの現状の有り様というのはその履歴なのです。「理想形」というものは、時間の流れのある一点を固定しなければ構想し得ないものなのです。

さらに、基幹システムには独特の制約があります。それは現在動いているシステム、およびその運用を止めないことです。作る、開発するというときに、真っ新な状態から作るということは基幹システムにおいてはほぼ許されません。

• 既存資産（レガシーコード、運用）という強力な制約
• （新規システムを作るなら）移行コストとリスク
• システム、運用のダウンタイム許容度
• ビジネス優先順位（安定運用よりもしばしばビジネスチャンスが優先されます）
• 組織・人材・スキルの制約（プロフィットセクターではない以上、リソースは常に非常に限られています）

こうしたことを考慮にいれながら改善を進める必要があるのが、基幹システムというものです。

あなたが、一エンジニアとして「なぜ、こんな不合理なアーキテクチャになっているんだ。理想形を追求すべきだ」と感じるのは正しいです。ですが、同時にあなたは次の質問への答えも持っていなければいけません。

「いま現在、理想的ではないかもしれないが回っているシステムと運用。そこにコストをかけてまで「理想形」にする価値はなんなのか？」

意思決定は常にトレードオフの上にある

誤解しないでいただきたいのは、理想を追求してはいけないと言っているのでもなければ、追求していない訳でもないということです。その場、その場において、見える範囲において、最適解は追求するのです。しかし、それでも、すべての時間軸で切り取って最適な状態というものは存在しないのです。

基幹システムの有り様は、意思決定の履歴であると書きました。
そして、意思決定には常にトレードオフが伴うことも忘れてはいけないポイントです。

• 可用性 vs コスト
• スピード vs 安定性
• シンプルさ vs 互換性
• 将来最適 vs 現在最適
• etc...

例えば、将来の拡張性を勘案して導入した入力項目が、運用メンバーにとってはシステム利用の複雑さ、難解さをあげてしまい、結果的に運用がうまく行われずに当初の目的を果たせない、というようなことはザラにあるのです。では、といって、入力項目をシンプルにした結果、恣意的な運用が増えてデータ品質が低下するということもままあることなのです。

局所最適の積み重ねが全体構造を作る

さらに運用が進むに従って、様々な新規要求、要件が発生します。これは使われているシステムである以上避けられない宿命です。基幹システムはその定義上、「使われ続けるシステム」である故に、継続的な改修（「保守」）は欠かせないのです。

そして、各改修には追加や例外対応が必ず発生します。必ずです。
なぜなら、既に存在している機能や運用とのコンフリクトが発生するからです。

既にある運用に適応しつつ、もしくは影響を最小化しつつ、新しい要求に応える必要がある。これは非常に局所最適になりやすい環境と言えるでしょう。そして、そうした局所最適の積み重ねが全体構造を作っていくのです。

もう一つ、忘れてはいけないのが、局所最適な意思決定によって発生した依存関係は簡単には消えないし、消せないということです。例えば、Aという状況があり、B、Cと機能拡張が遷移していったとします。この際、BはAという機能の存在に依拠して作られることがままあります。そして、CはBに依拠して作られる。すると、CはBだけでなく、実はAにも依拠していることになる。

一つの意思決定によって生み出された依存関係はこうして、その後の派生機能の中に織り込まれていくのです。

ゼロベースに、ドラスティックに、全体最適を模索する。この発想はだから基幹システムとは非常に食い合わせが悪いです。
企業活動を数年止めていいなら、こうしたことも可能ですが、基幹システムの定義上それはできない。

基幹システムの有り様がカオスに見えたとしても、それは「後から歪んだ」のではなく「連続的に変形した」結果なのです。

構成を理解するには「歴史」を読む必要がある

第４話で詳説する予定ですが、例えばクラスメソッドのSFA/CRMはHubSpotとSalesforceに別れています。

そこだけをみると、似たようなSaaSを二つ使っているなんて意味不明だと感じる向きもあるでしょう。
実際、二つのSaaSに分たれていることにより、様々な課題もありましたし、現在もあります。

しかし、そこには様々な「歴史的経緯」というものがあるのです。

• なぜその技術が採用されたのか？
• 判断当時の制約条件はなんだったのか？
• 現在もその構造があり続ける理由は？
• etc...

未来を予測できる人間はいません。歴史はその都度の最適解（だと信じた意思決定）の積み重ねです。

現在の有り様が理想形じゃなかったとして、でも、それを軽々に捨て去ることはできないのです。なぜなら、捨て去るにしても一時的な足場は必要だからです。

構成改善は再設計ではなく再意思決定である

「理想形」を形作るのはほぼ不可能であることはご理解いただけたかと思います。
では、そうして歴史的経緯によって培われたカオス（＝イケてない構造）をそのままにしておいて良いのでしょうか？

答えはNoです。

部屋の掃除を想像してもらうのがわかりやすいかと思います。

貴方の部屋は理想的な状態ではないでしょう（多分）。
そこには積み重ねてきた意思決定の履歴が刻まれています。
いまや雑然とモノが詰め込まれたカラーボックスだって、買った時は明確な意思と用途があったはずです。

そんな理想形ではない部屋を貴方は放置するでしょうか？
しないでしょう。少なくとも掃除は続けるはずです。
そして、少しずつ改善しようとするでしょう。
それが使っているということだからです。

その都度、「今ならどう判断するか」という視点で部屋をブラッシュアップしていくことでしょう。
基幹システムはそれと同じことをしているのです。
つまり、構造を改善していくことは日々の取り組みであり、「再設計」ではなく「再意思決定」なのです。
ここには、技術的正しさだけでは進まない、様々な制約とのすり合わせが存在します。

ちなみに、全面刷新は「引越し」に相当するインパクトがあります。
これはかなりのリソースの消費とリスクがあることはすぐに想像がつくはずです。

まとめ：構成を見る視点を変える

基幹システムの現在の有り様、その構成は純粋な技術選択の結果であることは非常に稀です。
そうではなく、多くの場合は様々な制約下においての意思決定の履歴です。

その中でPMがまず抑えるべきは、現在の構成や運用に至った歴史的経緯を調べておさえることです。
そして、貴方がPMとして新たに下す意思決定も歴史の一つになっていくことを自覚することです。ゼロから作り直したいという欲望に抗することです。仮に作り直したとしても、ほぼ同じ歴史の繰り返しになります。

次回は実際の基幹システムの構成、その構成が出来上がった歴史的経緯、改善戦略などについて詳説していきたいと思います。