なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？～超高速開発ツールの導入が必然である理由～

Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.

なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？

～超高速開発ツールの導入が必然である理由～

MBC(Method Based Consulting)

代表コンサルタント大島正善一般社団法人 ICT経営パートナーズ協会運営会員

超高速開発コミュニティ事務局

[email protected]

2014年7月28日

1

東京商工会議所セミナー資料


自己紹介（大島正善）【経験・専門分野】

• システムズ・エンジニアリング（開発プロセス、開発技術など）および品質管理、品質保証（250プロジェクト超）

• 日本IBM社の開発標準であるADSG/DOAシリーズとオブジェクト指向方法論の開発と社内外研修(40社超)

• EA、データモデリング、プロセス・モデリング、某官庁最適化計画策定

• CMM/CMMIアプレイザル社内リーダー

• 大規模トラブル・プロジェクトの立て直しのために、本社サイドのリーダーとして参画（複数）

• ITプロジェクトの開発計画策定および見積もり（大規模金融システム、）

【主なIT関連外部活動】

日本規格協会のソフトウェア・ライフサイクル・モデル委員会委員（1993年－1996年）

経済産業省e-Japan推進検討準備委員(2002年)

JEITA SPA(Software Process Improvement) 推進検討委員(2003年)

千葉工業大学での非常勤講師(2002年)

一般社団法人 ICT経営パートナーズ協会会員(2013~)

超高速開発コミュニティ事務局(2013~)

情報システム学会会員（情報システム学体系化委員）(2012~)

JDMC会員(2013/11~)

JUAS QCD研究会(2014/1~) など

SEの基礎知識「アプリケーション開発技術」（リックテレコム社）出版（共著） 1997

「新情報システム学序説」（一般社団法人情報システム学会出版（共著） 2014

「超高速開発が企業システムに革命を起こす」（日経BP社）出版（共著） 2014

Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 2



内容 1. 背景

2. 現状の基幹業務システムの課題

3. あるべき姿

4. 超高速開発とは何か、そして、その狙いは？

5. 超高速開発ツールを使うとシステム開発はどう変わる？

6. まとめ

7. 参考資料

– 超高速開発ツールの種類

– メトリックス調査結果（JUAS様調査報告） 4


出典：経済産業省「次世代高度IT人材の人材像と能力」（H24.4.26）をもとに作成

超高速開発の真の狙い（２つ）

①

②

5

Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. IPA：「IT人材白書2014」概要（2014.4） 6


価値を創る

事業に生かす

IPA：「IT人材白書2014」概要（2014.4） 7


受託開発以外の人材育成:

50%程度の企業は何もしていない

理由:

ビジネスモデルを具体化できていない

IPA：「IT人材白書2014」概要（2014.4） 8


根っこにある問題意識

現状の情報システムは『ビジネ

ス環境の変化に迅速に対応でき

ているか？』

情報システムを活用する“ユー

ザー企業”からの視点



現状の基幹業務システムは

『ビジネス環境の変化に迅速

に対応できていますか？』


ビジネスと情報システムとの間の”GAP”

理念/目標/戦略/方針

ビジネス・モデル

(ﾌﾟﾛｾｽ/組織…)

情報システムモデル

(ｱﾌﾟﾘ/ｼｽﾃﾑ構造…)

テクノロジーモデル

(適用技術/製品選択)

詳細モデル

ビジネス領域

情報システム

（IS)

領域

分断されて

いる

11


現在の基幹業務システムの状況（その１）

• 経営環境の変化に迅速に対応できない

• 情報システム部門の中に、業務の仕組みと情報システムの仕組みや仕様を理解している要員が減ってしまった

• バックログが減らない

• 怖くて手をつけられない

• 些細な変更もベンダに確認しないとできない

• アプリケーション・システムが個別に開発され、重複するデータが関連なく保持されてしまい、活用が困難となっている

• 莫大な費用が請求されるERPのバージョンアップ

12


現在の基幹業務システムの状況（その２）

ソフトウェアの設計仕様は、ソースコードを見なければわからない

それは、業務の仕組み（判断基準と実行すべき行動）のことを理解している人がいないことを意味する

13

この状況は、組織にとって解決すべき、かなり優先度の高い課題ではないか?


現状のシステム開発の姿(伝言ゲーム)

内部設計書

（処理機能記述、ファイル・レイアウ

ト、定義書、

システム概要書

（システム概要、ＥＲ図、共通機能、入出力等）

共通部品の変更が適切に反映さ

れていない

PM / リーダー

契約マスターの変更が他の成果物に反映されていないと聞いているが、他

の変更は大丈夫なんだろうか？

現行プログラムの仕様の一部が内部仕様化されないことになっても気がつかな

い。

共通部品を早く決める必要があることは分かっているが、共通基盤のAPIも変更

が頻発するし､部品の単位だって変える必要があるし、簡単に

は決まらないさ

事務設計書の記載とシステム・フローに不整合がある

な．．．

プログラム仕様書

共通部品

契約マスター

定義書

外部設計書

（システム・フロー／

機能構造定義／

部品仕様／ファイル仕様など））

事務設計書

（業務フロー、業務仕様記述書、画面イ

メージ、帳票イメージ等）

業務分析担当

レビュアー

レビュアー

ＰＭ

アプリ設計担当

DB設計担当

部品設計担当

開発担当

開発担当

不整合

14


“あるべき姿”は?

15


ビジネスと情報システムが一体化

理念/目標/戦略/方針

ビジネス・モデル

(ﾌﾟﾛｾｽ/組織…)

情報システムモデル

(ｱﾌﾟﾘ/ｼｽﾃﾑ構造…)

テクノロジーモデル

(適用技術/製品選択)

詳細モデル

ビジネス領域

情報システム

（IS)

領域

16

ビジネス・モデルの要素

情報システム・モデルの要素

連携：トレースできる

何ができればよいのか？


一般的なアプリケーション機能構造

受注業務

発注業務

マスター管理

受注登録

受注変更

受注取消

受注照会

通常受注

特注

自動発注

発注登録

．．．

顧客情報管理

商品情報管理

発注変更

．．．

顧客情報登録

顧客情報変更・削

発注連動発注連動

発注連動

発注連動

発注連動

発注連動

正しい構造か?

X X システム

17


ビジネス活動の主要要素

顧客

サプライチェーン

扱う商品やサービス

ビジネス・プロセス

業務機能

ビジネス・ルール（判断とその結果の行動あるいは活動の基準）

情報

組織・役割・責任

営業所、支店、拠点、工場などの場所

ＩＴの仕組み（Web、クラウド、スマホ、ネットワーク）

企業理念・目標・戦略・収益・利益・社会貢献

顧客

商流

販売するモノ（製・商品）


業務機能

ビジネス・ルール

情報

組織

配置

（ビジネス）コンテキスト

18


ビジネス活動の要素間の関連

商品・サービス

事業 A 事業 B 事業 C 事業 D 事業 E 事業 F

顧客

セグメント 1 ○ ○

セグメント 2 ○ ○ ○ ○

セグメント 3 ○ ○ ○ ○

セグメント 4 ○ ○ ○ ○

セグメント 5 ○ ○ ○

顧客も商品・サービスもさらに詳細化する



組織・体制

組織 1 ○ ○ ○ ○

組織 2 ○ ○

組織 3 ○ ○ ○ ○

組織 4 ○ ○

組織 5 ○ ○

組織・体制も商品・サービスもさらに詳細化する



調達先

調達先 1 ○ ○

調達先 2 ○ ○ ○ ○

調達先 3 ○ ○

調達先 4 ○ ○

調達先 5 ○ ○

調達先も商品・サービスもさらに詳細化する

チャネル（販売、製造、調達、マーケティング … ）

チャネル A

チャネル B

チャネル C

チャネル D

チャネル E

チャネル F

方針

戦略 1 ○ ○

戦略 2 ○ ○

戦略 3 ○ ○ ○

戦略 4 ○

戦略 5 ○ ○

戦略もチャネルもさらに詳細化する

19

多次元ワールド！！


事業ビジネス・プロセス


事業

事業データ項目

ビジネス・

プロセス

情報

事業


組織

拠点

データ項目

ビジネス・ルール

ビジネス・

ルール

業務機能

目標

目標

戦略

ビジネス・モデルの要素間の関連の全体図の例

20


システムの構成要素間の関係

情報データ項目

システム機能

システム機能

レベル２機能

レベル２機能

システム機能

製品

非機能要件

非機能要件

レベル4機能

DB

DB

画面

帳票

JOB

アプリ機能

製品・基盤機能

ＤＢ

画面

帳票

JOB

プログラム

ソフトウェアの構造

非機能要件

エンティティとデータ項目

エンティティ

業務プロセス

業務プロセス

システム機能（レベル１）

システム機能（レベルn）

システム機能

基盤要件

製品

基盤機能・製品

DB データ項目

21


リポジトリとは?

1. ビジネス・モデルの構成要素間の関連を保持する

2. ソフトウェア・モデルの構成要素間の関連を保持する

3. ビジネス・モデルとソフトウェア・モデルの関係を保持する

22

“ビジネス活動全体の部品表”


リポジトリの役割

（業務プロセス、

業務ルール、

データ項目、

画面、帳票等）

23

業務プロセスが変わる仕事のやり方が変わる

判断基準が変わる

管理するデータが追加される情報の管理単位が変わる

画面が追加される帳票が追加される

変更は自動的に

すべての要素（ビジネスおよびシステムの両方）

に反映される！整合性が担保される

リポジトリ

プロセスの順序A⇒B

ルールX ⇒ Y

データ項目c⇒d1&d2

画面u1,u2追加

業務フロー、

システム機能、

画面、帳票、

DB など

多くの超高速開発ツールはリポジトリを持ち、重要な役割はリポジトリに保管される情報の維持管理である！！


リポジトリを使ったシステム開発の姿

リポジトリ

詳細仕様

業務フロー

データモデル／データ項目

定義

運用テスト・シナリオ

詳細仕様

システム・テスト・

シナリオ

統合テスト

シナリオ

ルール記述

画面／帳票／インターフェー

ス仕様

トラン仕様／

バッチ仕様

テスト担当2

設計担当1

ITベンダ

テスト担当1 設計担当2

設計担当3

設計担当4

業務分析担当整合性が保証される

24


超高速開発とそのツールが可能にすること

情報システムの変化への対応力強化

情報システム構築のハードルを下げる（業務担当者ができるようになる）

25

情報システム

開発の現場

業務部門

の現場

従来

超高速開発


“超高速開発”はバズワーズですか?

26


超高速開発? 言葉の解釈

27

“超”＋“高速”＋“開発” ？ “超”＋“高速開発” ？

“超高速”であり

“超開発”でもある


超高速開発とは?（定義）

△「プログラムを自動生成する開発ツールを用いた開

発のこと」

◎業務のデザイン(1)から運用・保守工程をも含めたシステム・ライフサイクル全般にわたる生産性向上と継続的品質改善を行うやり方

(1)業務要件をもとに、業務のあるべき姿を設計すること

◎「超高速」には、「期間短縮」、「工数削減」と「品質向上による手戻り削減」の意味を含む

• 労働集約的な開発のやり方との比較

28


“超高速開発ツール”の特長

設計情報から実装コードを生成する、UIをすばやく開発する

だけではない

ビジネス・プロセスなどの業務に関わる情報やシステム設計に関する情報をリポジトリーで管理している

⇒ 業務の可視化

⇒ 設計の可視化

⇒ 業務（設計）から実装までの追跡可能性の担保

⇒ 変更の影響分析が可能

マルチプラットフォームに対応

29



情報管理体系

事業の種類

組織構造

調達先

物流構造顧客カテゴリー

ＤＦＤ　コンテキスト・ダイアグラム：　ＬＡＣ社　販売管理業務の位置づけ (販売管理業務と他の業務との情報の流れ：販売管理にかかわる情報のみを示す）

総務・人事管理業務金融機関

注文書、受注情報、顧客情報、納入先情報

引合・商談情報、見積情報、納品物受領書、プロジェクト状況

契約書、発注書［注文書］

支払い通知書、請求先情報

販売計画（予算）

販売計画（確定）、販売実績

支払予定情報（ＥＢデータ）

人件費、原価情報

製商品・サービスの提供

ＬＡＣＨＤ

お客様/ﾌﾟﾛｼﾞｪｸﾄ

請求先

仕入先

経理・会計業務

経営管理業務

販売計画（予算）

ＦＣ情報、販売実績

見積書、提案書、注文請書

見積情報

見積書（仕入）、納期回答情報、納品書（受領書・直送案内書）、仕入先情報、製商品情報

請求書

入金情報

売上実績、仕入実績、原価情報原価情報

外部倉庫

入庫情報

販売管理業務

未入金情報

ビジネス・プロセス全体図

業務フロー（上位1）

Ⅰ-2/3営業検定

プロジェクト検定

Ⅰ-4与信管理

Ⅰ-5案件作成

Ⅰ-6受注処理

Ⅰ-8出荷依頼

出荷

Ⅰ-12売上請求

Ⅰ-13売上請求締

Level1　販売サイクル(売切)

Ⅰ-4契約書審査

見積書注文書契約書EDI受注

試算書 ①お客様

②

仕入処理

入庫情報⑥

Ⅱ-16月次締処理

Ⅱ-17月次処理

受注連絡票

④

出荷計上依頼書

⑧

納品書/受領書

売上請求書

⑤

⑦

出荷計上依頼書

③

売上一覧

出荷情報

販売管理営業業務営業業務

営業

物流・売上業務

売上請求売上請求

プロジェクト管理

業務シナリオＡ．通常処理の場合 ①→④→⑤→⑦→③→⑧Ｂ．先行発注の場合 ②→⑦→①→④→⑥→⑧Ｃ．例外出荷の場合 ②→⑦→③→⑧→①→④

G3

売掛金残高表

情報システム

仕入先／倉庫

事業部･営業部門

営業管理部門・業務管理部門

経理部門

お客様

仕入入力

仕入データ

支払予定データ

受領および検収

納品書（仕入）

請求書（仕入）

証憑保管

請求書（仕入）の経理部への回付

請求書（仕入）印

注文書（物販）控

請求書（仕入）控

納品書（仕入）

見積書（仕入業者）

印

印

印

神谷町・汐留で受領

出荷

入荷完了確認

請求書（仕入）印

発送製商品（もの）

製商品（もの）

開始


終了

仕入承認入力


注文書（物販または

委託）印

発注

顧客へ直送の場合

神谷町あるいは汐留で受領の場合

顧客へ直送の場合

終了

（売上確定へ）

神谷町あるいは汐留へ配送の場合

4.1

4.1

4.1

4.2 4.3

4.4

4.5

業務フロー（下位）

情報管理体系

製品/調達先マトリックス

製品/組織マトリックス

ＢＰ/業務機能マトリックス

業務/システム機能マトリックス

リポジトリが管理する情報と設計の可視化

30


“従来の開発のやり方と何が変わるのか?”

31


何が変わるのかその１（技術面）

1. 品質の作りこみの実現整合性の維持、トレーサビリティの確保

2. 他の担当者がリアルタイムに設計を変更する他の担当者の作業が自分の作業に影響する

わずらわしいと感じられる

3. プロジェクトの状態が可視化される

リポジトリの内容が進捗、品質をリアルに示す

人の報告より“はるかに”信頼できる

4. 柔軟性が求められる

個人技からチームでの作業になる

32


何が変わるのかその2（マネジメント面）

1. 品質管理の方法が変わる

レビューでの確認ではなく、担当者自身が確認できる

2. 組織体制が変わる

マトリックス組織体制とマネジメントが条件になる

3. プロジェクトの実態が見えるようになる

品質・進捗はリポジトリの状況から判断できる

問題の早期発見が可能になる

4. 見積もりの基準が変わる

WBSが変わる

工程モデルが変わる

工数配分比率、期間配分比率、要員投入比率が変わる

33


何が変わるのかその3（心理面)

1. 閉じこもって仕事をするタイプの技術者は心理的負担が増す

2. 間違いの指摘を歓迎できる心の持ち方が必要になる

3. 変更を受け入れることを躊躇しない（当たり前だと思う）態度が必要になる

34


☆システム開発の工程モデル

☆製造業の製品開発の工程モデル

販売

製造研究

開発

製造（改善・改良）

保守（業務での活用）設計・開発

・テスト

再構築保守不能

企画・

要件

定義

製品開発工程モデルとシステム開発工程モデル

35


ユーザー主体開発を実現する超高速開発

企画、要求分析・モデリング、

アーキテクチャ設計

運用（業務での活用）

製造研究開発

保守（改善・改良）

設計の具象化、開発・テスト

継続的改善

ユーザー主体のDevOps

を実現する “超高速開発”

36


小さく始めて大きく育てる～インクリメンタルな開発～

37

ライフサイクル全期間にわたる継続的改善

優先順位の高い機能を最初に開発

ビジネスの変化に合わせて機能を追

加・変更

継続的改善


超高速開発ツールが与える影響【ユーザー企業】ユーザー主体開発（もしくは内製化）へのシフトを加速運用と保守もユーザー企業が主体的に行う方向へ自社の業務システムは資産継承しながら独自化に向かう情報システム部門の動き方で、各社収益性に差が出る OS,DBの変更によるシステム開発は減少

【ＩＴコンサルタント、ＩＴＣ】技術の幅を広げられる（自らやって見せることができる）中小企業の業務のIT化推進に直接的に貢献（ToBeの姿を見せることが

できる）

【ＩＴベンダー】下流工程（プログラミング、テスト工程）の発注が激減ユーザー企業から直接受注するITベンダーが増加業務の分析とモデリング・スキルが重要になるオフショア開発への発注が減少（ユーザー企業のスピード変更重視）クラウドで提供することが増加（システムを迅速に変更できる）見積方法人月工数見積から価値見積へ移行

38


“現行システムをどのように新世界に移行するのか?”

☆リバースツールRESCUEのご紹介

39

• RESCUEは、株式会社ソフトウェア・ジェネレーション社の商標です。

• 引き続く７枚は株式会社ソフトウェア・ジェネレーション社の了解のもとに、ご紹介します。


COBOL資産のマイグレーション（新リポジトリ構築）

40


クロス照会機能（RESCUE）

41


データ項目単位でのプログラム間のトレース機能

42


プログラムとJCLの分析機能

再構造化を行う

43


仕様書生成機能一覧

44


仕様書例

45


仕様書例

46


超高速開発ツールの活用準備（再構築に向けて）

“怖くて手をつけられない”基幹システムを抱えている企業は多い

現行の大規模基幹システムの仕様の把握は困難

ERPに手をいれ改修に困っている企業もある

稼働後、短期間で再構築を繰り返している

3-5年の間に基幹システムの再構築の波が来る

そのとき、相変わらず“大量の要員”による開発ができるとは考えられない

今から、少しずつ超高速開発ツールを調査・テスト利用すべき

47


参考

48


超高速開発ツールの種類（例）

1. Webアプリケーション生成（リアル処理）

2. レガシー・アプリケーション生成（リアル処理＆バッチ）

3. バッチ・アプリケーション生成（バッチ処理）

4. ビジネス・プロセスの作成と管理(BPMS)

5. ビジネス・ルールの作成と管理(BRMS)

6. アプリケーション統合・データ連携（EAI)

7. テスト自動実行

8. タブレット・アプリ作成

9. Excelアドイン・アプリケーション作成

10. シェル・プログラミング・ツール等

49

下線付きはリポジトリを持つタイプ


超上流源流開発上流開発下流運用

システム

システム保守・運用

利活用事業戦略・企画の検討

商品サービス

設備

要員・組織

（アウトソーシング）

資材、原料

顧客（販売店）

資金

システムの方向性

システム化計画要件定義

システム

設計

要求仕様書

(Dream,

Demand,

Desire ）

要件定義書（Requirement）

基本・

詳細

設計書

コード化

テスト

プログラム

ビジネスモデル検討業務モデルの検討情報システムの作成業務・情報システムの運用

超上流の前に事業戦略・企画の「ビジネスモデル（源流）の検討フェーズ」がある。源流の発想と超上流以下の発想法は異なる

ユーザー/

ベンダー

総合テスト

製作担当会社のＰＭ

ＳＩ会社のＰＭ

ユーザー企業のＰＭ

ロジカルシンキング（メカニカルシンキング）

クリエイティブシンキングデザインシンキングイノベーションシンキング

エモーショナルシンキング

スキルセンス

•超高速試作 •ウォーターフォール＋

超高速開発（組み合わせ） •超高速保守・

改善

クリティカルシンキング

マインド

備考: JUAS様作成資料を基に作成 50


ウォーターフォール(WF)との生産性の比較

備考

JFS:JUAS Function Scale。画面数と帳票数から規模を換算した値。既存ＷＦのデータを基に画面数＋帳票数×2/3 を算出(ユーザー発注者が明確に判るのは画面数、帳票数である）。また、係数はグラフにプロットしたときの傾きを示す。xRADは係数が小さいので、規模による生産性の変動が少ない。

・費用・工数・工期ともに超高速開発はウォーターフォール法の3分の１である

備考: 表はJUAS様作成 51

WF アジャイル xRADアジャイル

/WFxRAD/WF

平均 112.19 135.45 40.7 1.21 0.36

係数 28.2 57.65 6.4

平均 1.28 2.15 0.48 1.68 0.37

係数 0.44 1.6 0.26

平均 0.31 0.24 0.1 0.77 0.32

係数 0.13 0.04 0.03

総費用/JFS

工数/JFS

工期/JFS


評価項目 WFモデル xRAD超高速開発ハイブリッド・アジャイル

生産性 ×：ドキュメント作成工数が大

◎：設計情報がリポジトリーで管理されるので、ドキュメントが減少

△：ドキュメント削減効果が低い

品質 ○：テスト工程で確実に検証 ◎：設計情報の整合性が担保される ○：テスト工程で確実に検証

リリース ×：全工程が終了する迄 ◎：一部機能のリリースも可能、追加開発が容易

Ｘ：基本的には全工程終了時となる

スコープ管理 ○：上流工程で確定 ○：設計の不整合がわかるので機能漏れの発見が容易

△：上流工程で一度確定し、変更分は随時調整

変更要望への対応

×：設計工程迄の手戻りが発生

◎：変更影響範囲が明確になるので対応が容易

○：基本設計迄戻るもの以外はソフトウエアの修正のみ

仕様誤確認の早期発見

×：業務側の確認テスト時 ◎：画面についてはその場で実用モデルを作成するので、漏れは減少

○：事前に確認、かつイテレーションごとに業務側の確認実施

大規模開発 ○：複数チーム構成がやりやすい

△：大人数プロジェクトには向いていない。小規模から発展させることは可能

○：1チーム10名程度までの複数チーム構成

分散開発 ○：ドキュメントでの仕様伝達

○：分散開発が容易、設計情報は集中管理可能

○：必要なドキュメントは作成。分散開発環境の導入可能

保守（引き継ぎ）

○：保守用ドキュメントが残され、引き継ぎ可能

◎：リポジトリーに全情報が保持されているので、保守しやすい

○：保守用ドキュメントが残され、引き継ぎ可能

管理 ○：工程ごとに報告と承認 ◎：工程ごとに報告と承認。進捗情報、品質情報がシステムにより把握されている

○：工程ごとに報告と承認

ＩＴベンダーとの契約

○：特に無理な契約方法はない

○：変更対応が容易なので、スコープ変更や追加要件に対して契約上の問題が発生しにくい

△：請負契約には、変更量の調整が必要

参考資料： WFモデルとハイブリッド・アジャイルは、「ハイブリッドアジャイルの実践」リックテレコム社英繁雄他著 ISBN978-4-8979-7935-9 を参照。 xRAD超高速開発は、JUAS様と作成。

プロジェクトマネジメントの観点からの比較

52


関連セミナーのご案内

a. 必見！変われない情報システム部門が招く経営リスク http://event.tokyo-cci.or.jp/event_detail-ｘｘｘｘｘ.html (8/7)

b. なぜ、情報システム導入の7割以上が失敗するのか http://event.tokyo-cci.or.jp/event_detail-57549.html (8/6)

http://event.tokyo-cci.or.jp/event_detail-xxxxx.html (9/3)

c. なぜシステム開発は当初予算内で開発できないのか http://event.tokyo-cci.or.jp/event_detail-xxxxx.html (9/3)

d. なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？（本日と同じ内容）

http://event.tokyo-cci.or.jp/event_detail-57548.html (8/25 )

http://event.tokyo-cci.or.jp/event_detail-xxxxx.html (9/16)

いずれも『一般社団法人 ICT経営パートナーズ協会』の主催です。

http://event.tokyo-cci.or.jp/event_detail-ｘｘｘｘｘ.html






http://event.tokyo-cci.or.jp/event_detail-57549.html






http://event.tokyo-cci.or.jp/event_detail-xxxxx.html

























個別案件のご相談も承ります • 『一般社団法人 ICT経営パートナーズ協会』では大企業の基

幹業務システムの再構築から、中堅・中小企業の業務改善と

IT化の推進、あるいは、システム再構築といった様々な課題

に対応できるスキルを持った人材がおります。経営戦略を具

現化するためのＩＴ支援のご相談もお受けしています。

• 現状の基幹業務システムが“怖くて手をつけられない”状況で

見直しを検討されている場合には、相談にのらせていただくこ

とが可能です。移行など、本日お話しできなかった事柄につい

てもご相談にのらせていただくことが可能です。

• 連絡は下記にお願いいたします。

[email protected]


有料ワークショップコースのご案内

A) 自社のビジネスの仕組みを可視化しようその１

事業、顧客、チャネル、立地、組織、プロセスなど

の関係の可視化をトライする

B) 自社のビジネスの仕組みを可視化しようその２

BPMは難しくない/利益は確実についてくる

C) 業務アプリ担当者のための業務分析入門

若手・中堅技術者向け

☆ 一般社団法人 ICT経営パートナーズ協会のHP

（http://www.ictm-pa.jp/）でお知らせします

http://www.ictm-pa.jp/%E4%B8%BB%E5%82%AC%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AE%E3%81%94%E6%A1%88%E5%86%85/

http://www.ictm-pa.jp/




ご清聴ありがとうございました

56

Business

なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？ ～超高速開発ツールの導入が必然である理由～

なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？～超高速開発ツールの導入が必然である理由～