3-1.なぜ今、基幹システムを刷新するのか。次期システムの全体コンセプト

ベンダーが決まった(その選定の記録は前シリーズ「基幹システム刷新の全記録 RFP編」に書いた)。ここからは、いよいよ何を作るかの話だ。新シリーズでは、次期基幹システムの要件定義と設計、そしてAI駆動開発という新しい作り方への挑戦を12回にわたって記録する。

先に、このシリーズを貫く一本の問題意識を置いておきたい。AIの進化で、「作る」という行為はコモディティになる。 コードを書く、画面を組む、機能を実装する——かつて差別化の源泉だった「手段」が、安く速く、誰にでも「できて当たり前」に横並びになっていく。だとすれば、問われるのはもう手段ではない。何を作るか。どんなデータ構造で持つか。どの基準で選ぶか。 その「本質」だけは、AIにも、ベンダーにも、自社の代わりに決めてはもらえない。設計とは、その本質を見極める作業だ。第1回は土台となる全体コンセプト——どんなアーキテクチャを目指し、なぜそう決めたのかを書く。

Before:データの分断と、残存するアナログ作業

旧システムの最大の問題はデータの分断だった。受注、生産、在庫、出荷、請求——それぞれの情報が繋がらず、部門の境界のたびに人間が転記し、Excelが補完し、メモ欄が活躍する。前シリーズで「全社で一意のIDを持つマスタが無い」ことを根本原因として特定したが、その帰結が、業務のあちこちに残るアナログ作業だった。紙のカンバン、電話での納期確認、FAXの発注書、月末に人手で突き合わせる売上と会計。一つひとつは小さな手作業でも、合計すれば膨大な時間であり、ミスの源泉であり、何よりデータが「使える形」で貯まらない構造そのものだった。

After:次期システムの2大コンセプト

次期システムのコンセプトは、突き詰めると二つに集約される。強固なデータ基盤——すべての業務データが一意のIDで貫かれ、矛盾なく一箇所に貯まる。受注を起点に、生産も在庫も売上も会計も、同じデータの異なる断面として存在する。業務のシームレスな連動——営業が受注を確定した瞬間に生産側へ指示の材料が渡り、出荷が確定した瞬間に売上が立ち、会計仕訳の元データが生まれる。部門の境界でデータが止まらない。

この二つは表裏一体だ。データ基盤が強固だから連動でき、連動するからデータが正しく貯まる。旧システムはこの逆回転——分断がアナログ作業を生み、アナログ作業がデータをさらに汚す——に陥っていた。回転の向きを変えるのが今回の刷新だ。そしてこの「どんなデータ構造で事実を持つか」こそ、AIに肩代わりさせられない本質の一丁目一番地だ。コードはAIが書ける。だが自社の業務をどう構造として彫り出すかは、自社にしか決められない。

マルチクラウドという選択

アーキテクチャの大きな決断がマルチクラウドだった。一つのクラウドにすべてを寄せるのではなく、領域ごとに最適なクラウドを使い分ける。業務システムの本体はあるクラウドで動かしつつ、認証はGoogle Workspaceの基盤に委ね、データ分析はBigQueryへ流す(第9回で詳述)。「一社に揃えたほうが楽では?」という意見は当然あった。だが、各領域で最も成熟したサービスを選べる自由と、特定ベンダーへの過度な依存を避けられることを重視した。Shopify内製化の「エコシステムの集合知に乗る」思想の延長で、今回は複数のエコシステムの良いとこ取りをする判断をした。クラウド間の連携という設計課題は増える。それは引き受ける覚悟のコストだ。どのクラウドも機能は横並びに成熟していく時代だからこそ、「一番すごいのはどれか」ではなく「自社のどの役割を、どこに置くか」という評価軸で選んだ。

ブラウザだけで完結するシステムへ

もう一つの決断が、Chromeブラウザのみで完結するモダンWebシステムへの全面移行だ。旧システムは専用クライアントをPCにインストールする方式だった。入れ替えのたびにセットアップが要り、バージョンアップは全端末に配布が要り、リモートでは使えず、拠点が増えるたびに情シスの負担が膨らむ。ブラウザ完結なら、URLを開けば最新のシステムがそこにある。会社はGoogle Workspaceを導入済みで、Chromeを標準ブラウザとした管理体制とも整合する。業務システムを「インストールするもの」から「アクセスするもの」へ。一行だが、運用負荷とセキュリティの設計思想を根本から変える転換だった。

コンセプトは「判断の憲法」になる

なぜコンセプトをここまで固めるのか。この先の要件定義では無数の判断が待っている。この機能は作るか、この例外業務は許すか、このデータはどちらのシステムが持つか。その場の議論で決めると、システムは継ぎ接ぎになる。コンセプトはその判断の憲法だ。「強固なデータ基盤に反しないか」「業務の連動を切らないか」——迷ったらここに立ち返る。前シリーズで数値目標が羅針盤になったように、設計フェーズではコンセプトが羅針盤になる。手段が安く速く手に入る時代ほど、「何を本質と定めたか」が、できあがるシステムの質を分ける。

次回は、このシステムの入口——Google Workspaceを活用したゼロトラスト認証基盤について書く。

評決ではなく、レンズを。

アーキテクチャの決断とは、結局「自社のどの役割を、どこに、どんな基準で置くか」という本質の見極めの連続です。クラウドもツールも横並びに成熟していくからこそ、選ぶ基準こそが差を生みます。

AIで「作る」はコモディティになります。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、どう活かすか——を見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は発注者にあります。

選定とAIDDレディネスの要点を1枚にした無料の「評価軸チェックシート」を配布中です。

▶ 無料で受け取る:https://atomb.it/lens?utm_source=note&utm_medium=article&utm_campaign=s3