FORBiS Architecture Office
通販・ECの事業とITを、ひとつの構造として設計し続ける。
個別のシステムを作るところから始めるのではなく、事業・業務・データ・システムをひとつの構造として考える。その構造を、プロジェクトが終わっても継続して預かる——それが私たちの「設計室」です。
EC、受注、在庫、物流、会計、MA、BI、そしてAI。それぞれに良い製品があり、それぞれを正しく選んできたはずなのに——気づけば、つながらない。データが合わない。どこを直せば何が壊れるか、誰も分からない。
これは、個々のシステムの問題ではありません。一つひとつを最適に選んだ結果として起きる、構造の問題です。だから、一つひとつを見る人ではなく、全体を見続ける人が要ります。
Architecture Office は、コンサルティングの商品名ではありません。企業のIT全体を継続的に考え、判断し、必要なら実装まで行う機能そのものです。プロジェクトの上流工程ではなく、プロジェクトより上位にあって、終わらない役割だと考えています。
プロジェクトは、始まって、終わります。けれど事業は続きます。個別の案件が動いていない時期にも構造を見続ける人がいるかどうかで、数年後のシステムは変わります。
| 比べられるもの | その立ち位置 | Architecture Office |
|---|---|---|
| ITコンサルティング | 提言書を納品して終わる | 実装できる設計だけを描く。必要なら自分たちで作る |
| CTO代行 | 個人の力量に依存する | 専門チームで対応。個人技ではなく、工法として再現する |
| PMO | 決まったプロジェクトを回す | プロジェクトそのものを定義する |
| システム開発会社 | 案件単位。終われば関係も終わる | 案件をまたいで続く。案件がない時期こそ本領 |
| 情報システム部門の代行 | 運用・窓口を引き受ける | 構造を決める。手を動かす代行ではない |
扱う領域：事業構造・業務ライフサイクル・ドメイン境界／現行および目標の全体構成・責任分担・段階的刷新／データの所有と連携・履歴・分析／クラウド構成・API・イベント・非同期・性能・可用性
3つのメニューから選んでいただくのではなく、ひと続きの流れです。多くの場合は「診る」から始まり、必要に応じて「描く」へ、さらに「預かる」へと進みます。途中で終わっても構いません。
業務・システム・データ・連携を実際に調査し、いま何がどうつながっているのかを構造にします。感想ではなく、事実としてお見せします。
基幹刷新、EC刷新、新規事業、業務改革——目的に対して、数年後に破綻しない構造を設計します。一度に作り替えない前提の、段階移行まで含めて描きます。
社外の設計部門として、継続してご一緒します。案件が動いていない時期にも、構造を見続ける——そこにこの段階の価値があります。
私たちは通販基幹「Vegas」を持ち、フルスクラッチの開発力もあります。だからこそ、はっきり書いておきます。設計の結論は、既存システムをそのまま使う／SaaSを採用する／他社のパッケージを選ぶ／他社に開発を依頼する／私たちがスクラッチで作る／Vegasを使う——そのどれにもなり得ます。
判断の基準は、私たちにとって何を売るのが都合がよいかではなく、その企業全体にとって何が合理的かです。
ただし、私たちが実装できることには意味があると考えています。作れない人が描いた構造は、作る段階で必ずどこかが破綻するからです。実装できる設計だけを描く。それが、絵を描いて終わるコンサルティングとの違いです。
何から手を付け、何を残し、どの順で移行するか。一度に作り替えない前提で設計します。
提案内容・見積・前提を第三者として読み、経営が判断できる言葉に翻訳します。
どのシステムが何の正本を持つのかを決め直し、データの所有と連携を整理します。
原因が要件なのか、構造なのか、体制なのかを切り分けたうえで、定義し直します。
止めずに、部分から。段階的に置き換えられる構造へ変えていきます。
API・権限・状態・業務ルール・承認・操作履歴・復旧——AIが安全に操作できる構造から設計します。
アーキテクチャの方法論だけを持ち込む会社ではありません。受注・在庫・物流・販促・債権——通販の業務そのものを、作って、動かして、直してきた専門チームが設計します。
1995年から通販ひとすじ。業務を知らないまま引く境界線は、必ずどこかで現実と合わなくなります。
自社フレームワーク（Waikiki／AyersRock）と通販基幹Vegasを自ら開発・運用。机上ではない設計ができます。
「難しい判断を、仕組みに宿す」——20年以上、そう考えてきました。設計も同じで、属人的な勘には頼りません。
外部という立場を越えて、部門間の調整まで担ってきました。正しい境界は、業務と組織の両方を知らなければ引けません。
化粧品通販で注目を集める株式会社ランクアップ様では、オリジナル顧客管理システムの立ち上げ時の混乱を、私たちが1か月かけて交通整理し、PMとして社内をまとめました。以来、個別の開発案件を越えて、継続的に相談をいただく関係が続いています。——Architecture Office は、この関わり方に名前をつけたものです。
設計の結論が「作る」であれば、そのまま私たちが実装できます。通販基幹が必要ならVegas、独自要件が中心ならフルスクラッチ。もちろん、他社に発注するという結論でも構いません。考える会社と、作る会社を、分けなくていい——その選択肢があること自体に意味があると考えています。
むしろ、決まる前の段階こそが私たちの仕事です。事業と業務の構造から、一緒に整理します。「今のベンダーの提案が正しいのか分からない」「何が問題なのかも言葉にできない」——その状態で結構です。