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

Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？～超高速開発ツールの導入が必然である理由～
MBC(Method Based Consulting)
代表コンサルタント大島正善
一般社団法人 ICT経営パートナーズ協会運営会員
超高速開発コミュニティ事務局
oshimac888@gmail.com
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
2

3

内容
1.背景
2.現状の基幹業務システムの課題
3.あるべき姿
4.超高速開発とは何か、そして、その狙いは？
5.超高速開発ツールを使うとシステム開発はどう変わる？
6.まとめ
7.参考資料
–超高速開発ツールの種類
–メトリックス調査結果（JUAS様調査報告）
4

出典：経済産業省「次世代高度IT人材の人材像と能力」（H24.4.26）をもとに作成
超高速開発の
真の狙い（２つ）
①
②
5

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

価値を創る
事業に生かす
IPA：「IT人材白書2014」概要（2014.4）
7

受託開発以外の
人材育成:
50%程度の企業
は何もしていない
理由:
ビジネスモデルを具
体化できていない
IPA：「IT人材白書2014」概要（2014.4）
8

9
根っこにある問題意識
現状の情報システムは『ビジネス環境の変化に迅速に対応できているか？』
情報システムを活用する“ユーザー企業”からの視点

10
現状の基幹業務システムは『ビジネス環境の変化に迅速に対応できていますか？』

ビジネスと情報システムとの間の”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
○
○
○
顧客も商品・サービスもさらに詳細化する
事業
A
事業
B
事業
C
事業
D
事業
E
事業
F
組
織
・
体
制
組織
1
○
○
○
○
組織
2
○
○
組織
3
○
○
○
○
組織
4
○
○
組織
5
○
○
組織・体制も商品・サービスもさらに詳細化する
事業
A
事業
B
事業
C
事業
D
事業
E
事業
F
調
達
先
調達先
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
アジャイル
/WF
xRAD/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

53
関連セミナーのご案内
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.なぜシステム開発は当初予算内で開発できないのか
d.なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか？（本日と同じ内容）
http://event.tokyo-cci.or.jp/event_detail-57548.html (8/25 )
いずれも『一般社団法人 ICT経営パートナーズ協会』の主催です。

54
個別案件のご相談も承ります
•『一般社団法人 ICT経営パートナーズ協会』では大企業の基幹業務システムの再構築から、中堅・中小企業の業務改善と IT化の推進、あるいは、システム再構築といった様々な課題に対応できるスキルを持った人材がおります。経営戦略を具現化するためのＩＴ支援のご相談もお受けしています。
•現状の基幹業務システムが“怖くて手をつけられない”状況で見直しを検討されている場合には、相談にのらせていただくことが可能です。移行など、本日お話しできなかった事柄についてもご相談にのらせていただくことが可能です。
•連絡は下記にお願いいたします。
oshimac888@gmail.com

55
有料ワークショップコースのご案内
A)自社のビジネスの仕組みを可視化しようその１
事業、顧客、チャネル、立地、組織、プロセスなどの関係の可視化をトライする
B)自社のビジネスの仕組みを可視化しようその２
BPMは難しくない/利益は確実についてくる
C)業務アプリ担当者のための業務分析入門
若手・中堅技術者向け
☆一般社団法人 ICT経営パートナーズ協会のHP（http://www.ictm-pa.jp/）でお知らせします

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

Recently uploaded

Recently uploaded (6)