基幹システムの刷新時に着目すべきアーキテクチャとは？～SaaS統合で柔軟なシステム設計を実現～

Transcript

1. DX時代、基幹システムの更新に 「何億・何十億」もかけるべきなのか？ ～コスト削減と柔軟性・俊敏性の向上を実現する新しいアプローチ～ 2024 / 12 / 03 NCDC株式会社
2. • ビジネスはSOAで変革する。（IDGジャパン） • スマートデバイス×業務システム導入ガイド （秀和システム） プレゼンター紹介 ⚫ ITアーキテクチャのコンサルティング歴20年以上 ⚫ 20年前に現在のマイクロサービスの原型となるSOAの書籍を 日本で最初に執筆・出版 ITの広範囲な経験・実績と国立大学法人の講師も務めるビジネス の知識、起業の経験からビジネスとITを繋ぐ。ワークショップやファ シリテーションによるサービスの新規立ち上げやビジネスコンサル ティングを得意とする。 経歴 日本電信電話にてエンジニア、新規ビジネスプロデュースを経験後、HP， BEA、オラクル等の外資系IT企業にてITコンサルタント、製薬ベンチャーでの IT部門を統括。ベンチャー支援等の後 NCDCを創業。 NCDC株式会社 代表取締役CEO 早津 俊秀 和歌山大学経済学部 非常勤講師 元グロービス経営大学院 客員准教授 2
3. Business 新規事業立ち上げからの伴走 業務改革やIT改革の支援 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation Consultant デザイナーやエンジニアと協力して、新 規サービス立案の支援や新規性の高い システムの要件定義を行う。プロジェクト 全体のマネジメント役も担う。 UX/UI designer UIデザインはもちろん、デザイン 思考やUXデザインのフレーム ワークを用いて上流工程（サー ビス全体のUX設計）を担う。 Engineer モバイルやWeb、クラウド、IoTや AIなど、新しい領域の技術に特 化。つくるだけでなく技術コンサ ルティングができる知見を持つ 者も多数在籍。 Tech×Design×Biz 一体でお客さまを支援 ⚫ どこのベンダーも担ぐことなく中立性を維持 3
4. 本日のテーマの前提 ⚫ 基幹システム ⚫ 企業経営・企業活動に不可欠な業務をサポートするシステム ⚫ ERP（販売、生産、調達、原価管理、会計等）が代表的ではあるが、金融であれば 預金管理システム、建設であればプロジェクト管理システム、ITであればアサイン 管理システムなども基幹システム ⚫ スクラッチ開発の基幹システムは既存はJavaもしくは.Netが多いが、Cobolベース のホストコンピュータも数多く残っている 4
5. 基幹系システムの課題の歴史 5 必要最小限の基幹システム 周辺の小さいシステム ERP、Java（MVC）のスクラッチによる 基幹システム SaaS/PaaS ローコード・ノーコード MVVMのスクラッチ 1990年代 2000年代 2020年代 作ったが使われない システムが問題に • 使われるようにカスタマイズ だらけのパッケージ • 例外業務にまで対応した スクラッチシステム • 使われないシステムにならないように、例外的業務にもフィットするようにカスタマイズされ、 至れり尽くせりの機能まで実装されている老朽化してきた基幹システム • 新たなビジネス要求に応えるためにリプレースの検討をしなければならないが最適解が 見つからない 直面している課題感
6. トラブルプロジェクトを机上検証 ⚫ 大手食品メーカーのシステム開発トラブル ⚫ ERPの導入 ⚫ 当初計画は約3年間のプロジェクト期間 ⚫ 予算は215億円（実際は348億円になった） ⚫ システムトラブルで商品の出荷停止が２ヶ月続いた 6 計画時点で破綻しそうな理由が２つ 3年215億のプロジェクトを分解すると • 一人月200万円平均としても月平均300人の稼働 • ピーク時は倍の600人が稼働することが計画できる ※IR情報やインターネット等の外部情報を基に作成 600人でソフトウェア作り？ 1 2 一般的な製造業の基幹システムの規模？ • 相当なカスタマイズが想定される • 選定したERPに適合した使い方なのか
7. 7 ①新しいアーキテクチャを選定しましょう ②選定するアーキテクチャの特徴と 業務要件をフィットさせましょう 基幹システムのリプレースをどのように考えるか ※OpenAI DALL-E
8. アーキテクチャの進化 8 一軒ずつ個別に建てる 一軒単位で個別に借りる インフラ含めたサービスを借りる 固有の要件に応えられる 標準パッケージだがすぐに利用できる ホストコンピューター クラサバ Webアプリ（MVC） SPA（MVVM) パッケージ（ERP） SaaS PaaS 商 用 建 物 の ア ー キ テ ク チ ャ シ ス テ ム の ア ー キ テ ク チ ャ ①アーキテクチャは新しいほど洗練され進化している
9. アーキテクチャは制約条件でもある 9 大型ショッピングモール内に自店舗専用の駐車場やトイレ、決済手段、 特殊な営業時間を実現しようとしたら？ 一軒ずつ個別に建てる 一軒単位で個別に借りる インフラ含めたサービスを借りる 固有の要件に応えられる 標準パッケージだがすぐに利用できる 商 用 建 物 の ア ー キ テ ク チ ャ ②優れたアーキテクチャであってもその特性に合わせないと酷いことに
10. マイクロサービスアーキテクチャの「考え方」を取り入れる • SaaS、ERPなどのパッケージ系のサービスはカスタマイズはしない • パッケージ系で適合出来ない業務はスクラッチ • それらをAPIで呼び出し合う（最新のアーキテクチャを採用する） 原価管理 （クラウドネ イティブ スクラッチ） DB API 財務会計・生産管理 （APIが公開されている ERP） 勤怠管理 SaaS 財務会計ERPの標準UI API API API 勤怠管理の 標準UI 案件管理 （クラウドネ イティブ スクラッチ） DB API 営業支援 SaaS API 営業支援の 標準UI 既存生産管理 スクラッチ （MVC） DB API 生産管理 システムUI （View） Model フロントエンド 統合データ 基盤 （PaaS） DB API マイクロサービス的思考を取り入れたシステムイメージ 10
11. もう一歩考え方を進めると 11 目的別に訪問 距離や休みや営業時間の制約あり いつでもどこにでもありサービスを受けられる 利 用 者 に と っ て の サ ー ビ ス 〇〇コンビニエンス SaaSは業務システムのコンビニ 様々な業務システムのSaaSを組み合わせて 基幹システムとして使えないか？ ※OpenAI DALL-E
12. SaaS Integrationによる基幹システムの特徴 ⚫ 早く安く導入できるのがSaaS系 ⚫ ライセンス体系と社員数によっては高額になる場合もあるが保守運用がほぼゼロである ことを考えて投資対効果の検討が必要 12 種別 SaaS 従来型パッケージ（クラウドやオンプレ稼 働可能なパッケージ） システム構築 設定のみでITの専門家がいなくても導入 可能 SI企業やパッケージベンダー、そのパートナー による開発プロジェクト システム運用 ほぼゼロ クラウド上のリソースの監視・管理 セキュリティパッチの提供などが必要になる場 合がある 固有業務への 適合性 そのサービスのできる範囲内 従来型のカスタマイズが可能 初期コスト 非常に小さい 非常に大きい（構築費用＋ライセンス費用） 運用コスト SaaSライセンス形態と社員数によっては 大きい（サブスク費用） 初期コストに比例した保守費用が多い
13. 事例1 既存も併用しながらの組み合わせ ⚫ BtoBのプロジェクト型のビジネスモデル ⚫ 標準的業務と特殊性が高い業務を分離して、前者はSaaS利用、 後者はクラウドネイティブなスクラッチ開発を選択 13 ERPパッケージ 原価管理スクラッチ 勤怠工数管理パッケージ （カスタマイズ大） 経費申請スクラッチ プロジェクト管理スクラッチ 帳票パッケージカスタマイズ （カスタマイズ大） ERPパッケージ 既存ビジネスロジックのみ利用して API化 クラウドネイティブスクラッチ 勤怠管理SaaS 経費申請SaaS クラウドネイティブスクラッチ BIツール 旧アーキテクチャ 新アーキテクチャ 仕訳システムスクラッチ
14. 事例2 基幹システムをすべてSaaS型で運用 SaaS Integration ⚫ BtoBのプロジェクト型のビジネスモデル ⚫ システム管理の専任者ゼロで導入・運用 14 会計 人事給与 請求管理 原価管理 勤怠管理 工数管理 経費精算 SFA・CRM MA 固定資産管理 SaaSベンダーA社 SaaSベンダーB社 SaaSベンダーC社 SaaSベンダーD社 月次処理
15. ここまでのまとめ 1/2 ⚫ SaaS、ERP、スクラッチ開発など、業務要件に合わせて組み合わせるマイクロ サービス的な基幹システムが現実解 ⚫ どのアーキテクチャであってもAPIベースのアーキテクチャが必須 ⚫ クラウドベースのアーキテクチャであることが必須 ⚫ APIが公開されているSaaS、ERPを選定する ⚫ スクラッチ開発の場合はクラウドネイティブ（PaaS活用）なMVVMなアーキテクチャを 採用する ⚫ SaaSやERPを選定する場合はカスタマイズはしない ⚫ 複数SaaSをベースにした基幹システム導入も現実解になりつつある ⚫ SaaS Integration 15
16. ここまでのまとめ 2/2 16 昔のERPやSaaSなどのパッケージ製品 どうしても機能が貧弱で カスタマイズが避けられなった 業務を合わせるか、合わせられないなら クラウドネイティブなスクラッチで作る 最新のアーキテクチャのERPやSaaS ※OpenAI DALL-E ※OpenAI DALL-E
17. Cobol資産・メインフレームなど20年以上前の古いシステムのリプレース ⚫ ゼロベースで要件定義から始めることがお勧め ⚫ ベースが20年以上前のシステムの機能やデータ、処理能力は大きくはない ⚫ 既存業務フロー、既存画面、既存帳票、ヒアリングなどから要件定義を進め られる ⚫ 既存ロジックや既存ソースコードの解析からやるとそれだけで一年以上かか る。コストも非常に大きくかかる。それなら要件定義を一年かけずにやるほう が効果的 17
18. プロジェクトの進め方 ⚫ 要件定義の前段階としてどの業務にどういったアーキテクチャを適用するのか？を検討 するフェーズが必要 18 現状システム分析 新システム要求定義 アーキテクチャ定義 製品選定 新業務フロー・ 制約事項定義 現状システム分析・要求定義 アーキテクチャ定義・業務フロー定義 開発プロジェクト 要件定義 設計 プロジェクト検討・計画フェーズ
19. 19 DX時代、基幹システムの更新に「何億・何十億」もかけるべきなのか？ 業務を整理し、適材適所なアーキテクチャを組み 合わせることで、洗練されスリムな基幹システム は構築可能。 その結果、コストを抑えることが可能。 ※OpenAI DALL-E
20. 関心をお持ちの方はお気軽にご相談ください 20 ⚫ SaaS Integrationの可能性について個別に相談したい。まず現状システム分析からはじ めければならない。もうすぐ要件定義をはじめる予定がある…など、皆様の状況はそれ ぞれ異なると思います。 ⚫ NCDCは、お客様が現在抱えている課題に対して、その都度適した解決策を設計して オーダーメードのご提案しています。 ⚫ アンケートに下記の選択肢を用意しているので、ぜひご自身のニーズに近いものを選択 してご回答ください。まだ将来に向けての検討段階という場合でもご相談いただくのは問 題ありません。 ⚫ 自社のシステム更改について相談したい ⚫ コンサルティングサービスについて、費用感が知りたい ⚫ 他社事例について知りたい ⚫ サービス説明を聞きたい ※上記以外のご希望がある場合、自由記入欄をご利用ください