オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2011年7月定例会発表資料です。 Open Community "Requirement Development Alliance" 2011/7 regular meeting of the presentation materials.

1. 間欠的ビッグバンから継続的リフォームへ
～エンタープライズシステム再構築のパラダイム転換～
リフォーマブル・プラットフォーム・アーキテクチャ
株式会社 メソドロジック
1

2. 継続的リフォームパラダイムへ
• バラバラのシステム群の保守・運用の負担はますます重くなる
• 全社視点でのエンタープライズシステム構築が必要
• どうしてもはずせないレガシーや大物ERPがある
• 業務の変化、ニーズにこまめに対応できない
• ITの進化（技術革新、サービスの発展）を享受できない
• 大型投資による更地からの再構築はもはや現実的でない
• リフォームを前提とした工法に切り替える
• 古くても必要なら残す
• 変わりやすいところはユニットで変える
• 利用者に負担をかけないでリフォームする
• こまめな投資とこまめなリターン
• 少しずつ手を加えて、老朽化させない
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

3. エンタープライズシステムの発展経緯
ベースは部門のサポートとして成長した個々のシステム
• 販売管理、顧客管理（営業）、生産管理（製造）、在庫管理（物流）
• 利用者が部門内に閉じていた
• 部門間は人系（伝票など）で連携
全体最適を目指して、とりあえず連携
• つぎはぎながら、必要なデータは何とか渡し合う
• サプライチェーンなど業務の流れをカバー
• ITのコンベアーに各担当が作業を加える（主客の逆転）
企業活動の全体を支える１つのエンタープライズシステム
• 個々のシステムの集合体が企業インフラとなる
• エンタープライズシステムとして保守していく
• ERPやホスト系レガシーなどの大物システムや小型のWebシステムなど、様々な規模、
粒度のシステムが混在している
• 理想には遠い、継ぎはぎの温泉宿化
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

4. 改めて１つのエンタープライズシステムとして見る
エンタープライズシステムとしてのアーキテクチャがない
• 全体で統一した考え方がない
• ばらばらのシステムの寄せ集め
• データ、機能の重複や不整合
あるべき姿に程遠い
• バラバラなままで保守、運用。非効率、高コスト
• 経営に必要な情報をすぐに集められない
• つぎはぎで複雑化。業務に追従できない。足かせになる
エンタープライズとしての枠組み（フレームワーク）が必要
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

5. 繰り返される間欠的再構築
身動きできない状況の一気解消をはかる
• 全体最適の目的のもとに新たな視点で根本的に作り直し、現状のビジネ
スをカバーする
• たび重なる更改で複雑になりすぎたシステムのリファクタリング
• データの一元化を行う
• 業務改革と合わせて、業務の共通化、標準化を行う
更地開発に立ちはだかる壁
• 対象が広すぎて一気に全貌を見通せない
• すでにうず高く累積されたIT資産。莫大なコスト
• どうしても止められないレガシーシステム
• デグレード（今までできたことができなくなる）のリスク
• 業務へのインパクト。現場への負担。
• 今後１０年にわたる陳腐化に甘んじる
• 業務は変わり続ける。今の最適が明日の最適ではない。
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

6. リフォーム的発想へ
徐々にあるべき姿に近づける
• 一気に、いきなりやらない。順次再構築
既存のものを活かす
• はずせないものは残す。移せるところは部分的に移す。
毎年の平準的投資と短期でのリターンをこまめに得る
• 莫大な投資と長期の資産償却、陳腐化に陥らない
業務の改革と同期化して、標準化、効率化を進める
• 業務改革できたところからシステムも移行
新築を目指さず、常に平均“築３年”を目指す
• 次の年もまた“築３年”。常に新しくはなっていく
• 頻繁に変わる部分をよく取り替える
新しい技術を積極的に導入する
• 技術進化を享受する。クラウドの部分的組込み
変遷していることを常態ととらえる
• 移行を特別な作業と考えず、いかにインパクト少なく行えるかを仕組みにとして組み込む
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

7. リフォームを実現する要素
抜き差し自由なプラットフォーム
• リフォーマブル・プラットフォーム（業務・技術両面の変化に即応）
• サービスの組み合わせでアプリケーションを構成する仕組み
• 既存システムをサービス分解してプラットフォーム上に持ち込む仕組み
• 新たなサービスの配置、移行をスムーズに行う仕組み
• プログラムレスでサービスの組み合わせを変更する仕組み
業務をシステムに反映させる開発手法
• トレーサビリティを確保、維持して、保守フェーズも関連を見失わない
• 業務とシステムの一体設計
反復開発を実現する組織体制
• アジャイル組織
• ガバナンスと契約形態
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

8. プラットフォーム技術
エンタープライズとしてのフレームワーク
• 個々のアプリが上に乗る
• 各アプリが基盤を通じて高度に連携
• 全社としての共通機能を一元化
• 全体を止めずに部分的に保守・運用する仕組み
梁と柱を通して、アプリ、インフラを差替え自由に
• プログラムレスでサービス差替え
• 仮想化技術によってインフラ独立（ハード、ネットワークから空中浮遊）
• インフラは、ＩａａＳなどクラウド活用もあり
エンタープライズとしての共通機能を備える
• 保守・運用自動化のためのユーティリティ機能
• 帳票出力やメール配信などのアプリからの共通利用機能
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

9. エンタープライズ再構築で現れる課題
バラバラの複数システムの共通化
最近出会った事例
• Ｍ＆Ａや事業統合などで、似たようなシステムが散在 出版社
• 事業所ごとや商材・製品ごと、商流ごと、国ごとなど 鉄鋼商社
• それぞれの事情で完全に同じにはまとめられない 非鉄メーカー
• 業務プロセス、組織文化、法制度、歴史的背景 医療サービス
• 標準と非標準を適切に切り分ける 通信サービス
• アーキテクチャで差分をどう扱うか 測定機メーカー
業務改革とのすり合わせ
• 再構築には常に業務改革が伴う
• 業務改革は時間がかかる
• 段階的な移行
• 業務的に整理できたところからシステムも同期して対応する
業務インパクトを抑える
• 業務をできるだけ止めない
• 移行作業を極力無停止、短時間、自動作業で行う
• 現場に違和感を与えない
• 本質的なところだけ変える
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

10. 継続的リフォームへのステップ
継続的改善のサ
イクルへ
• ビジネスニーズへの
既存システムの基 迅速な対応
盤上への移行 • 業務改革のタイム
リーなサポート
• 現行システムのリプ • ＩＴの技術進化に同期
レース したサービスレベル向
• 共通化の推進と一元 上
管理へ
エンタープライズシ
ステム基盤の構築
• 既存システムの連携
• 共通ユーティリティの整
備
• 開発体制・環境の整備
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

11. リフォームパラダイムへ移行するために
• リフォームパラダイムを推進し、利点を活かすために以下のような取り組み
が必要
エンタープライズとしての基盤の構築
• 全社の主要システムを連携し、サービス指向で疎結合に構成されたエンタープライズシステム基盤
上へと移行させる
• 業務の変更や技術の変更に対して安定なレイヤーを維持し、それぞれの変更を吸収し継続的な進
化を可能にする
自由度の高い開発組織への移行
• 開発会社への一括発注では、リスクを載せた高い見積りとなり、細かな要求への対応も困難。事前
の仕様フィックスが強いられタイムリーに適切なサービスを提供できない。設計情報やノウハウが開
発会社に蓄積され、囲い込み状態で身動きがとれなくなる。システムが企業の中枢を担う状況で、
丸投げのアウトソースはありえない。
• 社内で安定したリソースを確保し、パートナー等を含めたイテレーション開発の体制を作る。アジャイ
ルに要求に応えるモデルで、継続的に業務改善を行う。設計情報やノウハウが社内組織に蓄積さ
れる。
業務をＩＴと結びつける手法の導入
• 業務を可視化し、上位目的に合致したシステム仕様をロジカルに導き出す手法により、必要となる
サービスを適正な粒度で切り出す。これによって基盤上のサービスと業務の対応がとれ、業務の変
更やＭ＆Ａ、アウトソーシング化などによるバリューチェーンの変更にも柔軟に対応できるようになる。
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.

12. 業務とＩＴを結び付ける手法
部門内に閉じたシステム
人系の業務フローを補助する計算機
部門間を横断するエンタープライズシステム
ベルトコンベアー脇で人が作業しているイメージ
業務はサイボーグ化している
業務は、サイボーグ状態
（人系とコンピュータ系の作業
が絡まり合う）
個別に設計していては、最適化
ははかれない
全体設計の中で、CPU化すべき部分を導き出す
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED.
12

13. 業務ニーズをシステムにマッピングする
ビジネス要求を開発する
経営企画
事業分析
事業上の目的を達成するため
のビジネス的要求を明らかに ビジネス要求をもとに
する システム要求を開発する
要求開発
ビジネス
要求 ビジネス要求のためにシステムを
企画する 立案
準備 デザイン シフト
在庫削減 決まったやり方がない システム要求をもとに
納期短縮 なんとなく人間系 システムを開発する
システム開発
ＸＸシステム
システム
要求 方向付け 推敲 構築 移行
ＹＹシステム
ＸＸシステム
○○機能 方向付け 推敲 構築 移行
△△機能
ＹＹシステム
○○機能
△△機能
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 13

14. 業務とＩＴの位置関係（業務からサービスを切り出す）
取引顧客 在庫センター 営業 経理 ＩＴシステム
販売管理システム
注文を登録す
る
商品を発注する
注文を受け付
ける
ＩＴはサブシ
請求書を送付
する ステム
商品在庫を確
認する
支払いを確認 入金管理システム
する
発送する
納品を確認する
入金を調べる
「業務」という上
位のシステム
注文をクローズ
する
ＩＴシステムの役割は業務の全体設計の中で決まる
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 14