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

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

2. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 自己紹介（大島正善）【経験・専門分野】 •システムズ・エンジニアリング（開発プロセス、開発技術など）および品質管理、品質保証（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

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

11. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネスと情報システムとの間の”GAP” 理念/目標/戦略/方針ビジネス・モデル (ﾌﾟﾛｾｽ/組織…) 情報システムモデル (ｱﾌﾟﾘ/ｼｽﾃﾑ構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデルビジネス領域情報システム（IS) 領域分断されている 11

12. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現在の基幹業務システムの状況（その１） •経営環境の変化に迅速に対応できない •情報システム部門の中に、業務の仕組みと情報システムの仕組みや仕様を理解している要員が減ってしまった •バックログが減らない •怖くて手をつけられない •些細な変更もベンダに確認しないとできない •アプリケーション・システムが個別に開発され、重複するデータが関連なく保持されてしまい、活用が困難となっている •莫大な費用が請求されるERPのバージョンアップ 12

13. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現在の基幹業務システムの状況（その２） ソフトウェアの設計仕様は、ソースコードを見なければわからない それは、業務の仕組み（判断基準と実行すべき行動）のことを理解している人がいないことを意味する 13 この状況は、組織にとって解決すべき、かなり優先度の高い課題ではないか?

14. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現状のシステム開発の姿(伝言ゲーム) 内部設計書（処理機能記述、ファイル・レイアウト、定義書、システム概要書（システム概要、ＥＲ図、共通機能、入出力等）共通部品の変更が適切に反映されていない PM / リーダー契約マスターの変更が他の成果物に反映されていないと聞いているが、他の変更は大丈夫なんだろうか？現行プログラムの仕様の一部が内部仕様化されないことになっても気がつかない。共通部品を早く決める必要があることは分かっているが、共通基盤のAPIも変更が頻発するし､部品の単位だって変える必要があるし、簡単には決まらないさ事務設計書の記載とシステム・フローに不整合があるな．．．プログラム仕様書共通部品契約マスター定義書外部設計書（システム・フロー／機能構造定義／部品仕様／ファイル仕様など））事務設計書（業務フロー、業務仕様記述書、画面イメージ、帳票イメージ等）業務分析担当レビュアーレビュアーＰＭアプリ設計担当 DB設計担当部品設計担当開発担当開発担当不整合 14

16. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネスと情報システムが一体化理念/目標/戦略/方針ビジネス・モデル (ﾌﾟﾛｾｽ/組織…) 情報システムモデル (ｱﾌﾟﾘ/ｼｽﾃﾑ構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデルビジネス領域情報システム（IS) 領域 16 ビジネス・モデルの要素情報システム・モデルの要素連携：トレースできる何ができればよいのか？

17. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 一般的なアプリケーション機能構造受注業務発注業務マスター管理受注登録受注変更受注取消受注照会通常受注特注自動発注発注登録．．．顧客情報管理商品情報管理発注変更．．．顧客情報登録顧客情報変更・削発注連動発注連動発注連動発注連動発注連動発注連動正しい構造か? X X システム 17

18. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネス活動の主要要素 顧客 サプライチェーン 扱う商品やサービス ビジネス・プロセス 業務機能 ビジネス・ルール（判断とその結果の行動あるいは活動の基準） 情報 組織・役割・責任 営業所、支店、拠点、工場などの場所 ＩＴの仕組み（Web、クラウド、スマホ、ネットワーク） 企業理念・目標・戦略・収益・利益・社会貢献 顧客 商流 販売するモノ（製・商品） ビジネス・プロセス 業務機能 ビジネス・ルール 情報 組織 配置 （ビジネス）コンテキスト 18

19. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネス活動の要素間の関連商品・サービス事業 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 多次元ワールド！！

21. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. システムの構成要素間の関係情報データ項目システム機能システム機能レベル２機能レベル２機能システム機能製品非機能要件非機能要件レベル4 機能 DB DB 画面帳票 JOB アプリ機能製品・基盤機能ＤＢ画面帳票 JOB プログラムソフトウェアの構造非機能要件エンティティとデータ項目エンティティ業務プロセス業務プロセスシステム機能（レベル１）システム機能（レベルn）システム機能基盤要件製品基盤機能・製品 DB データ項目 21

23. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. リポジトリの役割（業務プロセス、業務ルール、データ項目、画面、帳票等） 23 業務プロセスが変わる仕事のやり方が変わる判断基準が変わる管理するデータが追加される情報の管理単位が変わる画面が追加される帳票が追加される変更は自動的にすべての要素（ビジネスおよびシステムの両方）に反映される！整合性が担保されるリポジトリプロセスの順序A⇒B ルールX ⇒ Y データ項目c⇒d1&d2 画面u1,u2追加業務フロー、システム機能、画面、帳票、 DB など多くの超高速開発ツールはリポジトリを持ち、重要な役割はリポジトリに保管される情報の維持管理である！！

24. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. リポジトリを使ったシステム開発の姿リポジトリ詳細仕様業務フローデータモデル／データ項目定義運用テスト・シナリオ詳細仕様システム・テスト・シナリオ統合テストシナリオルール記述画面／帳票／インターフェース仕様トラン仕様／バッチ仕様テスト担当2 設計担当1 ITベンダテスト担当1 設計担当2 設計担当3 設計担当4 業務分析担当整合性が保証される 24

28. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発とは?（定義） △「プログラムを自動生成する開発ツールを用いた開発のこと」 ◎業務のデザイン(1)から運用・保守工程をも含めたシステム・ライフサイクル全般にわたる生産性向上と継続的品質改善を行うやり方 (1)業務要件をもとに、業務のあるべき姿を設計すること ◎「超高速」には、「期間短縮」、「工数削減」と「品質向上による手戻り削減」の意味を含む •労働集約的な開発のやり方との比較 28

29. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “超高速開発ツール”の特長 設計情報から実装コードを生成する、UIをすばやく開発するだけではない ビジネス・プロセスなどの業務に関わる情報やシステム設計に関する情報をリポジトリーで管理している ⇒ 業務の可視化 ⇒ 設計の可視化 ⇒ 業務（設計）から実装までの追跡可能性の担保 ⇒ 変更の影響分析が可能 マルチプラットフォームに対応 29

30. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネス・プロセス情報管理体系事業の種類組織構造調達先物流構造顧客カテゴリーＤＦＤ　コンテキスト・ダイアグラム：　ＬＡＣ社　販売管理業務の位置づけ (販売管理業務と他の業務との情報の流れ：販売管理にかかわる情報のみを示す）総務・人事管理業務金融機関注文書、受注情報、顧客情報、納入先情報引合・商談情報、見積情報、納品物受領書、プロジェクト状況契約書、発注書［注文書］支払い通知書、請求先情報販売計画（予算）販売計画（確定）、販売実績支払予定情報（ＥＢデータ）人件費、原価情報製商品・サービスの提供ＬＡＣＨＤお客様/ ﾌﾟﾛｼﾞｪｸﾄ請求先仕入先経理・会計業務経営管理業務販売計画（予算）ＦＣ情報、販売実績見積書、提案書、注文請書見積情報見積書（仕入）、納期回答情報、納品書（受領書・直送案内書）、仕入先情報、製商品情報請求書入金情報売上実績、仕入実績、原価情報原価情報外部倉庫入庫情報販売管理業務未入金情報ビジネス・プロセス全体図業務フロー（上位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

32. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 何が変わるのかその１（技術面） 1.品質の作りこみの実現 整合性の維持、トレーサビリティの確保 2.他の担当者がリアルタイムに設計を変更する 他の担当者の作業が自分の作業に影響する わずらわしいと感じられる 3.プロジェクトの状態が可視化される リポジトリの内容が進捗、品質をリアルに示す 人の報告より“はるかに”信頼できる 4.柔軟性が求められる 個人技からチームでの作業になる 32

33. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 何が変わるのかその2（マネジメント面） 1.品質管理の方法が変わる レビューでの確認ではなく、担当者自身が確認できる 2.組織体制が変わる マトリックス組織体制とマネジメントが条件になる 3.プロジェクトの実態が見えるようになる 品質・進捗はリポジトリの状況から判断できる 問題の早期発見が可能になる 4.見積もりの基準が変わる WBSが変わる 工程モデルが変わる 工数配分比率、期間配分比率、要員投入比率が変わる 33

38. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールが与える影響【ユーザー企業】 ユーザー主体開発（もしくは内製化）へのシフトを加速 運用と保守もユーザー企業が主体的に行う方向へ 自社の業務システムは資産継承しながら独自化に向かう 情報システム部門の動き方で、各社収益性に差が出る OS,DBの変更によるシステム開発は減少【ＩＴコンサルタント、ＩＴＣ】 技術の幅を広げられる（自らやって見せることができる） 中小企業の業務のIT化推進に直接的に貢献（ToBeの姿を見せることができる）【ＩＴベンダー】 下流工程（プログラミング、テスト工程）の発注が激減 ユーザー企業から直接受注するITベンダーが増加 業務の分析とモデリング・スキルが重要になる オフショア開発への発注が減少（ユーザー企業のスピード変更重視） クラウドで提供することが増加（システムを迅速に変更できる） 見積方法人月工数見積から価値見積へ移行 38

47. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールの活用準備（再構築に向けて） “怖くて手をつけられない”基幹システムを抱えている企業は多い 現行の大規模基幹システムの仕様の把握は困難 ERPに手をいれ改修に困っている企業もある 稼働後、短期間で再構築を繰り返している 3-5年の間に基幹システムの再構築の波が来る そのとき、相変わらず“大量の要員”による開発ができるとは考えられない 今から、少しずつ超高速開発ツールを調査・テスト利用すべき 47

49. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールの種類（例） 1.Webアプリケーション生成（リアル処理） 2.レガシー・アプリケーション生成（リアル処理＆バッチ） 3.バッチ・アプリケーション生成（バッチ処理） 4.ビジネス・プロセスの作成と管理(BPMS) 5.ビジネス・ルールの作成と管理(BRMS) 6.アプリケーション統合・データ連携（EAI) 7.テスト自動実行 8.タブレット・アプリ作成 9.Excelアドイン・アプリケーション作成 10.シェル・プログラミング・ツール等 49 下線付きはリポジトリを持つタイプ

50. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超上流源流開発上流開発下流運用システムシステム保守・運用利活用事業戦略・企画の検討商品サービス設備要員・組織（アウトソーシング）資材、原料顧客（販売店）資金システムの方向性システム化計画要件定義システム設計要求仕様書 (Dream, Demand, Desire ）要件定義書（Requirement）基本・詳細設計書コード化テストプログラムビジネスモデル検討業務モデルの検討情報システムの作成業務・情報システムの運用超上流の前に事業戦略・企画の「ビジネスモデル（源流）の検討フェーズ」がある。源流の発想と超上流以下の発想法は異なるユーザー/ ベンダー総合テスト製作担当会社のＰＭＳＩ会社のＰＭユーザー企業のＰＭロジカルシンキング（メカニカルシンキング）クリエイティブシンキングデザインシンキングイノベーションシンキングエモーショナルシンキングスキルセンス •超高速試作 •ウォーターフォール＋超高速開発（組み合わせ） •超高速保守・改善クリティカルシンキングマインド備考: JUAS様作成資料を基に作成 50

51. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ウォーターフォール(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

52. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 評価項目 WFモデル xRAD超高速開発ハイブリッド・アジャイル生産性 ×：ドキュメント作成工数が大 ◎：設計情報がリポジトリーで管理されるので、ドキュメントが減少 △：ドキュメント削減効果が低い品質 ○：テスト工程で確実に検証 ◎：設計情報の整合性が担保される ○：テスト工程で確実に検証リリース ×：全工程が終了する迄 ◎：一部機能のリリースも可能、追加開発が容易Ｘ：基本的には全工程終了時となるスコープ管理 ○：上流工程で確定 ○：設計の不整合がわかるので機能漏れの発見が容易 △：上流工程で一度確定し、変更分は随時調整変更要望への対応 ×：設計工程迄の手戻りが発生 ◎：変更影響範囲が明確になるので対応が容易 ○：基本設計迄戻るもの以外はソフトウエアの修正のみ仕様誤確認の早期発見 ×：業務側の確認テスト時 ◎：画面についてはその場で実用モデルを作成するので、漏れは減少 ○：事前に確認、かつイテレーションごとに業務側の確認実施大規模開発 ○：複数チーム構成がやりやすい △：大人数プロジェクトには向いていない。小規模から発展させることは可能 ○：1チーム10名程度までの複数チーム構成分散開発 ○：ドキュメントでの仕様伝達 ○：分散開発が容易、設計情報は集中管理可能 ○：必要なドキュメントは作成。分散開発環境の導入可能保守（引き継ぎ） ○：保守用ドキュメントが残され、引き継ぎ可能 ◎：リポジトリーに全情報が保持されているので、保守しやすい ○：保守用ドキュメントが残され、引き継ぎ可能管理 ○：工程ごとに報告と承認 ◎：工程ごとに報告と承認。進捗情報、品質情報がシステムにより把握されている ○：工程ごとに報告と承認ＩＴベンダーとの契約 ○：特に無理な契約方法はない ○：変更対応が容易なので、スコープ変更や追加要件に対して契約上の問題が発生しにくい △：請負契約には、変更量の調整が必要参考資料： WFモデルとハイブリッド・アジャイルは、「ハイブリッドアジャイルの実践」リックテレコム社英繁雄他著 ISBN978-4-8979-7935-9 を参照。 xRAD超高速開発は、JUAS様と作成。プロジェクトマネジメントの観点からの比較 52

53. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 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.なぜシステム開発は当初予算内で開発できないのか 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経営パートナーズ協会』の主催です。

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

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

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

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

Recommandé

Contenu connexe

Tendances

Tendances(20)

En vedette

En vedette(20)

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

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

Dernier

Dernier(20)