Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
今なぜ超高速開発なのか? - What、Why および ビジネス上の価値、効果と事例 - 
MBC(Method Based Consulting) 
超高速開発コミュニティ 事務局 
一般社団法人 ICT経営パートナーズ協会 
大島 正善 
...
内容 
1.背景 
2.現状の基幹業務システムの課題 
3.あるべき姿 
4.超高速開発とは何か、そして、その狙いは? 
5.超高速開発ツールを使うとシステム開発は どう変わる? 
6.参考 
2
情報システム(IS)にまつわる長年の課題 
労働集約的な開発のやり方から脱却できない 
他の産業と異なり、自動化を推進し品質と生産性を高めよう という意識が欠如している 
一般の製品のように、長く使い続けることができず数年する と陳腐化し...
出典:経済産業省「次世代高度IT人材の人材像と能力」(H24.4.26)をもとに作成 
超高速開発の 
真の狙い(2つ) 
① 
② 
4
IPA: 「IT人材白書2014」概要 (2014.4) 
5 
価値を創る 
事業に生かす
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
6 
企業IT動向調査2014(JUAS)
7 
根幹の問題 
現状の情報システムは『ビジネス環 境の変化に迅速に対応できている か?』 
情報システムの構築時の“ユーザー 企業”における活用の視点 
“開発すること”のみを考えている 
Copyright ©2014 MBC (M...
ビジネスと情報システムとの間の”GAP” 
理念/目標/戦略/方針 
ビジネス・モデル 
(プロセス/組織…) 
情報システムモデル 
(アプリ/システム構造…) 
テクノロジーモデル 
(適用技術/製品選択) 
詳細モデル 
ビジ 
ネス...
現在の基幹業務システムの状況(その1) 
•経営環境の変化に迅速に対応できない 
•情報システム部門の中に、業務の仕組みと情報シ ステムの仕組みや仕様を理解している要員が減っ てしまった 
•バックログが減らない 
•怖くて手をつけられない 
...
現在の基幹業務システムの状況(その2) 
ソフトウェアの設計仕様は、ソースコード を見なければわからない 
それは、業務の仕組み(判断基準と実 行すべき行動)のことを理解している人 がいないことを意味する 
10 
この状況は、組織にとっ...
現状のシステム開発の姿(伝言ゲーム) 
内部設計書 
(処理機能記述、 
ファイル・レイアウ 
ト、定義書、 
システム概要書 
(システム概要、ER図、 
共通機能、入出力等) 
共通部品の変更 
が適切に反映さ 
れていない 
PM / リ...
イノベーションが求められている 
企業や行政組織の情報システムの役割は拡大しており、ビジ ネス上あるいは法律や施策、さらには、社会ニーズを迅速に 情報システムに反映することが求められている 
現状の情報システムは、構造そのものが変化に対応で...
IT調達法の多様化 
①経営とITの融合: 
a.上流工程及び運用管理の重視 経営戦略・戦術策定とIT活用戦略策定との同期化 ➡経営とITとは表裏一体 
b.経営問題に強い「士資格者」やITコーディネータとSEとの 連携強化 
c.情報システム...
パン切り包丁 
目的・用途によって違う包丁がある 
出刃包丁 
薄刃包丁 
三徳包丁 
麺切包丁 
牛刀 
カービングナイフ 
フィレナイフ 
丸包丁 
クレーバー 
菜切り包丁 
鮪包丁 
中華包丁 
刺身包丁 
14
多様化するIT調達法の使い分け 
①ウォータフォール型開発は、今後も「高度大型システム」や「企業固有の 戦略システム」の開発には必要 
②一般の業務システム(バックエンド系)は、極力ソフトウェアPKGの利用、 クラウドの利用を図るべき。 
③適...
「作らない開発」への動き 
①最も付加価値が低く、最も工数が掛かるソフトウェア製造 工程を極限まで減らしたい。 
②コスト削減を狙ったオフショア・ソフト開発先の人件費の高騰 →労働集約型な仕事を受けたがらない。 
工 数 
付 加 価 値 
髙...
17
“あるべき姿”は? 
18
ビジネスと情報システムが一体化 
理念/目標/戦略/方針 
ビジネス・モデル 
(プロセス/組織…) 
情報システムモデル 
(アプリ/システム構造…) 
テクノロジーモデル 
(適用技術/製品選択) 
詳細モデル 
ビジ 
ネス 
領域 ...
ビジネス活動の主要要素 
顧客 
サプライチェーン 
扱う商品やサービス 
ビジネス・プロセス 
業務機能 
ビジネス・ルール(判断とその結 果の行動あるいは活動の基準) 
情報 
組織・役割・責任 
営業所、支店、拠点、工場...
ビジネス活動の要素間の関連 
商品・サービス 
事業 
A 
事業 
B 
事業 
C 
事業 
D 
事業 
E 
事業 
F 
顧 
客 
セグメント 
1 
○ 
○ 
セグメント 
2 
○ 
○ 
○ 
○ 
セグメント 
3 
○ ...
事業 
ビジネス・ 
プロセス 
ビジネス・ 
プロセス 
事業 
事業 
データ項目 
ビジネス・ 
プロセス 
情報 
事業 
ビジネス・ 
プロセス 
組織 
拠点 
データ項目 
ビジネス・ 
ルール 
ビジネス・ 
ルール 
業務機能...
システムの構成要素間の関係 
23 
情報 
データ 項目 
システム 機能 
システム 機能 
レベル2 機能 
レベル2 機能 
システム機 能 
製品 
非機能 要件 
非機能 要件 
レベル4 機能 
DB 
DB 
画面 
帳票 
J...
ビジネス要件情報 
情報データ項目 
システム機能 
システム機能レベル2機能 
レベル2機能 
製品システム機能 
非機能要件 
非機能要件 
レベル4機能 
DB 
DB 
画面 
帳票 
JOBNET / 
JOB 
ビジネス要件 
St...
はトレーサビリティを示す 
事業 
ビジネス・ 
プロセス 
ビジネス・ 
プロセス 
事業 
事業 
ビジネス・ 
プロセス 
ビジネス・ 
ルール 
目標 
アプリ機能 
アプリ機能 
レベル2機 能 
レベル2機 能 
基盤・部 品 
レ...
システム開発で必要な情報(成果物)の関連 
:ドメイン間の関係として管理すべきだが、ツールを使わずに行うことが困難な部分 
N次元の管 理が必要 
アプリケーション・ 
ドメイン 
(AA) 
ビジネス・ 
ドメイン 
(BA) 
テクノロジー...
QFD(Quality Function Deployment)例 
http://www.matrixprojects.ltd.uk/Images/diagrams%20etc/QFD.jpg 
品質機能展開 
ソフトウェアも 
このような ...
リポジトリとは? 
1.ビジネス・モデルの構成要素間の関 連を保持する 
2.ソフトウェア・モデルの構成要素間の 関連を保持する 
3.ビジネス・モデルとソフトウェア・モデ ルの関係を保持する 
28 
“ビジネス活動全体の部品表” 
Copy...
リポジトリの役割 
(業務プロセス、 
業務ルール、 
データ項目、 
画面、帳票等) 
29 
業務プロセスが変わる 
仕事のやり方が変わる 
判断基準が変わる 
管理するデータが追加される 
情報の管理単位が変わる 
画面が追加される 
帳...
リポジトリを使ったシステム開発の姿 
リポジトリ 
(部品表) 
詳細仕様 
業務フロー 
データモデル /データ項目 定義 
運用テスト・シナ リオ 
詳細仕様 
システム・テスト・ 
シナリオ 
統合テスト 
シナリオ 
ルール記述 
画面...
“超高速開発”とは? 
31
超高速開発? 言葉の解釈 
32 
“超”+“高速”+“開発” ? 
“超高速”であり 
“超開発”でもある 
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
超高速開発とは?(定義) 
△「プログラムを自動生成する開発ツールを用いた開 発のこと」 
◎業務のデザイン(1)から運用・保守工程をも含めたシ ステム・ライフサイクル全般にわたる生産性向上と 継続的品質改善を行うやり方 
(1)業務要件をもと...
“超高速開発ツール”の特長 
設計情報から実装コードを生成する、UIをすばやく開 発する 
だけではない 
ビジネス・プロセスなどの業務に関わる情報やシステ ム設計に関する情報をリポジトリーで管理している 
⇒ 業務の可視化 
⇒ 設計の可...
①業務、データ中心にした設計・変更が可能 
②プログラミング技術不要 
③データベースの自動設計 
④稼働後の柔軟な変更、追加 
超高速開発メソッド/ツールの有効性 
ビジネスルール管理 
設計情報管理 
運用・保守管理 
各種言語によ...
要求の変化を短期間で吸収する 
要求機能と のGAP 
WF型開発で 実現した機能 
超高速開発で 実現した機能 
要求機能と のGAP 
機能レベル 
時間 
要求されている機能 
36
ビジネス・ 
プロセス 
情報管理体系 
事業の種類 
組織構造 
調達先 
物流構造 顧客カテゴリー 
DFD コンテキスト・ダイアグラム: LAC社 販売管理業務の位置づけ (販売管理業務と他の業務との情報の流れ:販売管理にかかわる情報のみ...
“従来の開発のやり方と 何が変わるのか?” そして どのような効果を生むのか? 
38
超高速開発ツールが与える影響 
【ユーザー企業】 
ユーザー主体開発(もしくは内製化)へのシフトを加速 
運用と保守もユーザー企業が主体的に行う方向へ 
自社の業務システムは資産継承しながら独自化に向かう 
情報システム部門の動き方で、...
何が変わるのか(例) 
1.品質の作りこみの実現 
整合性の維持、トレーサビリティの確保 
レビューでの確認ではなく、担当者自身が確認できる 
2.プロジェクトの実態が見えるようになる 
品質・進捗はリポジトリの状況から判断できる 
問...
☆システム開発の工程モデル 
☆製造業の製品開発の工程モデル 
販売 
製造 
研究 
開発 
製造(改善・改良) 
保守(業務での活用) 
設計・ 開発 ・テスト 
再構築 
保守 不能 
企画・ 要件 定義 
製品開発工程モデルとシステム開...
保守 
SLCPが暗黙的に持つ弊害 
42 
企画 
シス テム・ テスト 
統合 テスト 
開発 
内部 (詳細) 設計 
要件 定義 
運用 準備 
外部 (基本) 設計 
「開発された完成品の状態を保ち続けるの が保守」という認識 
...
Maintenance(維持改善) 
これからは、保守(維持改善)こそが重要! 
企 画 
シ ス テ ム ・ テ ス ト 
統 合 テ ス ト 
開 発 
内 部 
( 詳 細 ) 設 計 
要 件 定 義 
運 用 準 備 
外 部 ( 基...
システム開発において重要なのは、業務ノウハウ! 
JUAS資料をもとに作成 
源流 
超上流 
開発上流 
開発下流 
保守 
基本 設計 
詳細 設計 
要件 定義 
プログラミング 
テスト・検収 
利活用 
要求 
仕様 
事業 戦略 
...
超高速開発はアジャイル型とWF簡易型が可能 
システム運用 
第1反復 
テス ト 
開 発 
要 求 
第n反復 
テス ト 
開 発 
要 求 
・・・ 
リリース 
・・・ 
第1反復 
テス ト 
開発 
要 求 
第n反復 
テス ト...
アジャイル開発の得意分野と不得意分野 
アジャイル開発の得意とする状況 
クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性が なく、人命に関わらないシステム) 
熟練した開発者が参加する場合 
開発中に頻繁に要件が変...
アジャイル手法適用の条件 
1チームは少人数である 
チームの数もそれほど大きくない(コミュニケ ーションとイメージの共有が可能な範囲) 
QCDS(Quality, Cost, Delivery, Scope)に対す る責任を持つ人が、...
ユーザー主体開発を実現する超高速開発 
企画、要求分析・モデリング、 
アーキテクチャ設計 
運用(業務での活用) 
製造 
研究 
開発 
保守(改善・改良) 
設計の具象化、開発・テスト 
継続的改善 
ユーザー主体の DevOps 
を実...
超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その1 - 
ツールの特質の理解 
ツールへのインプット情報が何かを理解する 
インプットを作成するための作業は何か(ビジネス・プロセス/ワークフロー 作成、データ項目...
超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その2 - 
発注者のオーナーシップの確立 
最終的なQCD+S(Scope)の責任をベンダに任せない 
Scopeを調整する権限を持つ責任者が参加すること(法律の規定...
小さく始めて大きく育てる ~インクリメンタルな開発~ 
51 
ライフサイクル全期間にわたる継続的改善 
優先順位の 高い機能を 最初に開発 
ビジネスの変化に 合わせて機能を追 加・変更 
継続的改善 
Copyright ©2014 MBC...
システム開発は日常業務へ! 
プロジェクト・タイプ の仕事(期間限定の 仕事) 
QCDをすべて等しく 重視 
専門家がやるべき仕 事(しかし、資格は前 提でない) 
SIベンダーが開発 (QCD)の責任 
52 
日常業務になる 
...
ウォーターフォール(WF)との生産性の比較 
備考 
JFS:JUAS Function Scale。画面数と帳票数から規模を換算した値。既存WFの 
データを基に画面数+帳票数×2/3 を算出(ユーザー発注者が明確に判るのは画 
面数、帳票数...
開発生産性向上実績(例1) 
アプリケーション 
労働集約的方法に よる提案 
xRAD実績 
削減率 
A社生産管理シ ステム 
100人月 
35人月 
65%削減 
B社基幹業務 
300人月 
167人月 
45%削減 
C社輸出入業務...
開発生産性向上実績(例2) 
アプリケーション 
既存システム 
xRAD実績 
削減率 
G社 基幹システム 
6,000万 
800万 
86%削減 
既存言語 
現行規模 
xRAD実績 
削減率 
COBOL 
1,300k steps...
保守効率の向上実績(例1) 
アプリケーション 
導入前 
導入後 
削減率 
J社 
年間外部支払料金 6,000万~8,000万 
年間外部支払料金 
100万 
98% 
K社 
4名(10システム) 
4名(15システム以上) 
同じ要...
保守効率の向上実績(例2) 
57 
企業 
削減率 
O社 
更新負荷66%減少 
P社 
運用負荷70%削減 
Q社 
ECサイトへの出店を30日から2日へ 
アプリケーション 
導入前 
導入後 
削減率 
L社 基幹システ ム 
年間保...
ITエンジニアに 
求められているスキル 
58
アプリケーションの種類とIS技術者の役割 
基幹業務アプリ 
BtoC Web 
アプリ 
情報分析、 
ビッグデータ分析 
重視する 要素 
品質+コスト 
品質+スピード 
コスト+スピード 
適用可 能な開発 モデル 
ウォーターフォール...
イノベーションの推進:3段階の体系化を! 
Technology Architecture 
Application Architecture 
Data Architecture 
Business Architecture 
業務改善・標準...
アプリケーションの設計=業務の設計 
アプリケーション構造定義、機能定義、データ構造設計、モ ジュール化、データベース設計、UI設計、製品機能割り当て 
今まで 
今後 
業務プロセス設計、ビジネス・ルール設計、 抽象化、データ構造設計、機...
参考:高いテクニカル・スキルが要求される分野 
社会インフラ・ 
システム 
アーキテク チャ 
製品・ツール 
の開発 
組込ソフトウェア 
重視 する 要素 
品質 
品質 
品質 
品質+スピード 
重要 なス キル 
設計、プロジェ ク...
参考 
63
導入事例(超高速開発コミュニティ 事例集より) 
11.バッチ処理プログラムのステップ数が 1/17に 
12.非常に短期間で業務全体を“見える化” 
13.国防総省が認めた世界最高水準の品質 と生産性 
14.端 末 の 変 更 に 影 響 ...
導入事例(スライドのみ) 
このように短納期で開発できたのは、Magicで開発した、ECサイト構築パッ ケージ「EC FORWARD」をハワイアンズ様に合わせてカスタマイズを行 ったためです。Magicの自由に、容易にカスタマイズできるという...
導入事例(スライドのみ) 
https://www.x-rad.jp/usecase/ より 
ライオン株式会社 研究開発本部様では、超高速開発ツール「GeneXus」 をベースにしたサービス....を用いて、研究開発テーマ管理システムをス ...
導入事例(スライドのみ) 
従来のパッケージ製品はロジックに触れることができず、簡単な文言の修正で も社外のSI企業に依頼する必要があるなどの悩みがありました。ユニケージ 開発手法で再構築した新システムでは実際の業務フローに沿って、『こ のデ...
導入事例(スライドのみ) 
PEXAによる業務分析は、各業務担当者にヒアリングしながらその場で 入力し、担当者に確認しながら業務フロー図ができる....ひと通りヒアリン グをし業務フロー図が描けた後は、それらを「製品受注」「出荷指示」等のシナ...
導入事例(スライドのみ) 
•機械工具やメンテナンス部品を販売するビジネスを展開している千葉産業様で は、全社員へiPadを配布して業務活用を検討されていました。20万点以 上の商品を取り扱っているため、お客様の幅広いニーズに応えるため には業...
生産性が向上すると市場は小さくなるのか? 
他の業界では、生産性を向上させることを業務改善の常態と して行っている 
生産性の向上は市場規模の拡大と利益向上につながってい る 
生産性を上げても市場が大きくならないのは、そもそも商品 やサ...
8,442 
4,595 
労働集約型産業の行く末(人口の減少) 
50年で売り上げ ▼45%(10年ごとに 約1割減少) 
71 
Copyright ©2014 MBC (Method Based Consulting) All Right...
SI ビジネス規模 
一般社団法人 電子情報技術産業協会(JEITA) 2014.6.30 「 2013年度 ソフトウェアおよびソリューションサービス市場規模調査結果について」 http://home.jeita.or.jp/cgi-bin/p...
超高速開発ツールを活用すると、 市場は縮小するどころか大きくなる! 
Gartner Seminar in Sydney 2011 をもとに作成 
構造化された定型 業務 
人の仕事の80%は、構造化されない作業 
膨大なIT化市場! 
(超...
P.ドラッカー 「ネクスト・ソサエティ」 
こうして、われわれの眼前に膨大な仕事が 横たわっている。第一に、情報に通暁しなけ ればならない。そのためには、一人ひとりが 情報リテラシーを習得する必要がある。... 情報を仕事の道具として見なけれ...
組織活動は情報システムである 
•情報管理(Information Management)の重要性は、 1970年代から語られている 
•理論にいたっては、1950年代まで遡ることができ る 
–組織は高度な情報処理と様々なレベルでの意思決定の...
IT投資に熱心でない日本 
一般社団法人 電子情報技術産業協会(JEITA) 2013.10.9 「ITを活用した経営に対する日米企業の相違分析」調査結果の公表について http://home.jeita.or.jp/upload_file/2...
Technology とは? 
Technologyという英語は、コンピュータ が生まれる前からある言葉 
•Knowledge about scientific or industrial methods, or the use of th...
“IT経営”とは? 
IT(Information Technology)を使った経営 のこと?(スマホやタブレットやツールを 駆使して経営を行うこと[日本語の語感 からするイメージ]) 
I(Information)をビジネス活動に生かす...
塩野七生 
歴史を書きながら痛感させられることに一つは、情 報とは、その重要性を理解したものにしか伝わらな いということだ。(中略)ユリウス・カエサルも言ってい る。「人間ならば誰にでも、現実のすべてが見えるわ けではない。多くの人は、見たい...
IT と IS は異なる概念 
IT(Information Technology) 
•“情報の活用方法に関する業界のノウハウ” 
•ハードウェア/ソフトウェアという手段を企業活動 に有効に活用すること(結果としてこのような意 味も生まれる...
Upcoming SlideShare
Loading in …5
×

超高速開発の基礎概念 20141119 0

4,441 views

Published on

超高速開発の概念をまとめた資料です。ビジネスの変化に迅速に対応できる情報システムを構築することが求められています。そのような時代に、労働集約的な開発をしていることに根本的・本質的な無理難題が存在することを理解いただくための資料です。システム開発のイノベーションが必須であり、適用している企業では、すでに多大な効果が出ています。そういったことをまとめています。

Published in: Business
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

超高速開発の基礎概念 20141119 0

  1. 1. 今なぜ超高速開発なのか? - What、Why および ビジネス上の価値、効果と事例 - MBC(Method Based Consulting) 超高速開発コミュニティ 事務局 一般社団法人 ICT経営パートナーズ協会 大島 正善 2014年11月 1
  2. 2. 内容 1.背景 2.現状の基幹業務システムの課題 3.あるべき姿 4.超高速開発とは何か、そして、その狙いは? 5.超高速開発ツールを使うとシステム開発は どう変わる? 6.参考 2
  3. 3. 情報システム(IS)にまつわる長年の課題 労働集約的な開発のやり方から脱却できない 他の産業と異なり、自動化を推進し品質と生産性を高めよう という意識が欠如している 一般の製品のように、長く使い続けることができず数年する と陳腐化し、再構築せざるを得ない(ライフサイクルコストが 低下しない) ベテランは年々減っており、業務ノウハウとシステムの全体 像を理解している技術者が少なくなってしまった(中堅企業・ 大企業では、業務システムを最初から構築することは、この 20年程度行われていない) 保守コストは70%-80%を占める状況が続いている(前向き の投資ができない) 3
  4. 4. 出典:経済産業省「次世代高度IT人材の人材像と能力」(H24.4.26)をもとに作成 超高速開発の 真の狙い(2つ) ① ② 4
  5. 5. IPA: 「IT人材白書2014」概要 (2014.4) 5 価値を創る 事業に生かす
  6. 6. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 6 企業IT動向調査2014(JUAS)
  7. 7. 7 根幹の問題 現状の情報システムは『ビジネス環 境の変化に迅速に対応できている か?』 情報システムの構築時の“ユーザー 企業”における活用の視点 “開発すること”のみを考えている Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  8. 8. ビジネスと情報システムとの間の”GAP” 理念/目標/戦略/方針 ビジネス・モデル (プロセス/組織…) 情報システムモデル (アプリ/システム構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデル ビジ ネス 領域 情報 シス テム (IS) 領域 分断されて いる Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 8
  9. 9. 現在の基幹業務システムの状況(その1) •経営環境の変化に迅速に対応できない •情報システム部門の中に、業務の仕組みと情報シ ステムの仕組みや仕様を理解している要員が減っ てしまった •バックログが減らない •怖くて手をつけられない •些細な変更もベンダに確認しないとできない •アプリケーション・システムが個別に開発され、重 複するデータが関連なく保持されてしまい、活用が 困難となっている •莫大な費用が請求されるERPのバージョンアップ 9 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  10. 10. 現在の基幹業務システムの状況(その2) ソフトウェアの設計仕様は、ソースコード を見なければわからない それは、業務の仕組み(判断基準と実 行すべき行動)のことを理解している人 がいないことを意味する 10 この状況は、組織にとって解決すべき、 かなり優先度の高い課題ではないか? Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  11. 11. 現状のシステム開発の姿(伝言ゲーム) 内部設計書 (処理機能記述、 ファイル・レイアウ ト、定義書、 システム概要書 (システム概要、ER図、 共通機能、入出力等) 共通部品の変更 が適切に反映さ れていない PM / リーダー 契約マスターの変更が他 の成果物に反映されてい ないと聞いているが、他 の変更は大丈夫なんだろ うか? 現行プログラムの仕 様の一部が内部仕 様化されないことに なっても気がつかな い。 共通部品を早く決め る必要があることは 分かっているが、共 通基盤のAPIも変更 が頻発するし、部品の 単位だって変える必 要があるし、簡単に は決まらないさ 事務設計書 の記載とシス テム・フローに 不整合がある な... プログラム仕様 書 共通部品 契約マスター 定義書 外部設計書 (システム・フロー/ 機能構造定義/ 部品仕様/ファイル 仕様など)) 事務設計書 (業務フロー、業務仕 様記述書、画面イ メージ、帳票イメージ 等) 業務分析担当 レビュアー レビュアー PM アプリ設計担当 DB設計担当 部品設計担当 開発担当 開発担当 不整合 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 11
  12. 12. イノベーションが求められている 企業や行政組織の情報システムの役割は拡大しており、ビジ ネス上あるいは法律や施策、さらには、社会ニーズを迅速に 情報システムに反映することが求められている 現状の情報システムは、構造そのものが変化に対応できない ものになっている(構造不良を起こしている) 一部の組織を除いて、情報システムの設計から実装に関わる ことができる人材が不足しており、ギャップを埋める必要があ る システム開発という作業を個人のスキルに依存せず管理可能 な状態にしていくことが求められている ビジネスや社会の変化に合わせて、ソフトウェアの継続的改善 を可能にする必要がある 12 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  13. 13. IT調達法の多様化 ①経営とITの融合: a.上流工程及び運用管理の重視 経営戦略・戦術策定とIT活用戦略策定との同期化 ➡経営とITとは表裏一体 b.経営問題に強い「士資格者」やITコーディネータとSEとの 連携強化 c.情報システム開発・活用のPDCAサイクルを回しながら、 継続的にシステムを成長させていく。 ②IT調達法の多様化: a.従来はウォータフォール型による固有ソフト開発が主流 ➡今後も高度大型システムや企業固有の戦略的システム開発は必要 b.「クラウド活用」「超高速開発メソッド/ツール活用」などの選択肢が 増えてきた。 c.システムに応じて、これら多様の方法を的確に使い分けていく力が 重要 13
  14. 14. パン切り包丁 目的・用途によって違う包丁がある 出刃包丁 薄刃包丁 三徳包丁 麺切包丁 牛刀 カービングナイフ フィレナイフ 丸包丁 クレーバー 菜切り包丁 鮪包丁 中華包丁 刺身包丁 14
  15. 15. 多様化するIT調達法の使い分け ①ウォータフォール型開発は、今後も「高度大型システム」や「企業固有の 戦略システム」の開発には必要 ②一般の業務システム(バックエンド系)は、極力ソフトウェアPKGの利用、 クラウドの利用を図るべき。 ③適したソフトウェアPKGが無い場合、超高速開発メソッド/ツールを積極 的に活用すべき。 固有システム へのこだわり、 特に差別化を 図る場合には 上記③が適し ている。 高度大型システム (唯一無二) 企業固有の戦略的システム (含、特別ノウハウ) 情報システム (フロントエンド系) 一般の業務システム (バックエンド系) その他ユティリティシステム 個別開発 (ウォーターフォール型開発) 個別開発 (超高速開発) パッケージ活用 クラウド利用 BPO活用 <システム種> <調達法> 15
  16. 16. 「作らない開発」への動き ①最も付加価値が低く、最も工数が掛かるソフトウェア製造 工程を極限まで減らしたい。 ②コスト削減を狙ったオフショア・ソフト開発先の人件費の高騰 →労働集約型な仕事を受けたがらない。 工 数 付 加 価 値 髙い 低い 多い 少ない 最多 最低 要求定義 設計 製造 テスト ソフトウェア開発の自動化が必須 16
  17. 17. 17
  18. 18. “あるべき姿”は? 18
  19. 19. ビジネスと情報システムが一体化 理念/目標/戦略/方針 ビジネス・モデル (プロセス/組織…) 情報システムモデル (アプリ/システム構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデル ビジ ネス 領域 情報 シス テム (IS) 領域 19 ビジネス・モデルの 要素 情報システム・ モデルの要素 連携:トレースできる 何ができればよいのか? Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  20. 20. ビジネス活動の主要要素 顧客 サプライチェーン 扱う商品やサービス ビジネス・プロセス 業務機能 ビジネス・ルール(判断とその結 果の行動あるいは活動の基準) 情報 組織・役割・責任 営業所、支店、拠点、工場などの 場所 ITの仕組み(Web、クラウド、スマ ホ、ネットワーク) 企業理念・目標・戦略・収益・利 益・社会貢献 顧客 商流 販売するモノ(製・商品) ビジネス・プロセス 業務機能 ビジネス・ルール 情報 組織 配置 (ビジネス)コンテキスト 20 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  21. 21. ビジネス活動の要素間の関連 商品・サービス 事業 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 ○ ○ 戦略もチャネルもさらに詳細化する 21 多次元ワールド。 人が管理できる限 界を超えている! Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  22. 22. 事業 ビジネス・ プロセス ビジネス・ プロセス 事業 事業 データ項目 ビジネス・ プロセス 情報 事業 ビジネス・ プロセス 組織 拠点 データ項目 ビジネス・ ルール ビジネス・ ルール 業務機能 目標 目標 戦略 ビジネス・モデルの要素間の関連の全体図 22 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  23. 23. システムの構成要素間の関係 23 情報 データ 項目 システム 機能 システム 機能 レベル2 機能 レベル2 機能 システム機 能 製品 非機能 要件 非機能 要件 レベル4 機能 DB DB 画面 帳票 JOB アプリ機能 製品・基盤機能 DB 画面 帳票 JOB プログラム ソフトウェ アの構造 非機能要件 エンティティとデータ項目 エンティティ 業務機能 業務プロセス ・業務機能 システム機能 (レベル1) システム機能 (レベルn) システム機能 基盤要件 製品 基盤機能・製品 DB データ項目 情報 多次元ワールド。 人が管理できる限 界を超えている!
  24. 24. ビジネス要件情報 情報データ項目 システム機能 システム機能レベル2機能 レベル2機能 製品システム機能 非機能要件 非機能要件 レベル4機能 DB DB 画面 帳票 JOBNET / JOB ビジネス要件 Start ビジネス・ プロセス 目標・ 施策 アプリ機能 製品・基盤機能 DB 画面 帳票 JOB プログラム ソフトウェア の構造 非機能要件 エンティティとデータ項目 要件 業務と情報システムとの関係は複雑なn次元構造 ソフトウェア に関わること 業務に関 わること 追跡可能性の確 保が鍵 (人手で管理するのは人間の能力の限界を超えている!!) 24
  25. 25. はトレーサビリティを示す 事業 ビジネス・ プロセス ビジネス・ プロセス 事業 事業 ビジネス・ プロセス ビジネス・ ルール 目標 アプリ機能 アプリ機能 レベル2機 能 レベル2機 能 基盤・部 品 レベル4機 能 画面 帳票 JOBNET / JOB エンティティ ビジネス・ プロセス 基盤・部 品 基盤・部 品 国 の 施 策 ビジネス・ プロセス 情 報 管轄 領域 省 庁 省庁・ 出先 機関 ビジネス・ ルール 事務機能 目標 アプリ機能 製品 画面 帳票 JOB プログラ ム ソフトウェア構造 非機能 要件 エンティ ティ DB データ項目 基盤機能 (共通プラットフォーム)) エンティティ エンティティ DB DB アプリ機能 Start 25 ビジネス・プロセス、 業務の機能、各種ビ ジネス・ルールなどを 最新状態に維持する ことで、ソフトウェア の機能が自動的に 変更される世界を実 現することを狙う! この領域はソフトウェアが実現(手作りやパッ ケージの場合、関連が管理されていないので、 変更対応に時間と労力がかかる) Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  26. 26. システム開発で必要な情報(成果物)の関連 :ドメイン間の関係として管理すべきだが、ツールを使わずに行うことが困難な部分 N次元の管 理が必要 アプリケーション・ ドメイン (AA) ビジネス・ ドメイン (BA) テクノロジー・ ドメイン (TA) データ・ ドメイン (DA) N次元の管 理が必要 N次元の管 理が必要 目標、要求事項、プロセス、情 報、組織などの視点がありn次 元で管理することが必要 データは構造を持つが、 エンティティとデータ項目 との2次元で管理できる 機能要件、サブシステム、Tierと Layer、画面、帳票、インター フェース等があり、全体の構造を n次元で管理することが必要 設計方針や非機能要件に対 して、HW,SW,ネットワーク、 基盤技術などがあり、n次元 で管理することが必要 N次元の管 理が必要 26 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  27. 27. QFD(Quality Function Deployment)例 http://www.matrixprojects.ltd.uk/Images/diagrams%20etc/QFD.jpg 品質機能展開 ソフトウェアも このような 多次元構造 27
  28. 28. リポジトリとは? 1.ビジネス・モデルの構成要素間の関 連を保持する 2.ソフトウェア・モデルの構成要素間の 関連を保持する 3.ビジネス・モデルとソフトウェア・モデ ルの関係を保持する 28 “ビジネス活動全体の部品表” Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  29. 29. リポジトリの役割 (業務プロセス、 業務ルール、 データ項目、 画面、帳票等) 29 業務プロセスが変わる 仕事のやり方が変わる 判断基準が変わる 管理するデータが追加される 情報の管理単位が変わる 画面が追加される 帳票が追加される 変更は自動的に すべての要素(ビジネス およびシステムの両方) に反映される! 整合性が担保される リポジトリ プロセスの順序A⇒B ルールX ⇒ Y データ項目c⇒d1&d2 画面u1,u2追加 業務フロー、 システム機能、 画面、帳票、 DB など 多くの超高速開発ツールはリポジトリを持ち、重要な役割はリポ ジトリに保管される情報の維持管理である!! Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  30. 30. リポジトリを使ったシステム開発の姿 リポジトリ (部品表) 詳細仕様 業務フロー データモデル /データ項目 定義 運用テスト・シナ リオ 詳細仕様 システム・テスト・ シナリオ 統合テスト シナリオ ルール記述 画面/帳票/ インターフェー ス仕様 トラン仕様/ バッチ仕様 テスト担当2 設計担当1 ITベンダ テスト担当1 設計担当2 設計担当3 設計担当4 業務分析担当 整合性が保証される 30 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  31. 31. “超高速開発”とは? 31
  32. 32. 超高速開発? 言葉の解釈 32 “超”+“高速”+“開発” ? “超高速”であり “超開発”でもある Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  33. 33. 超高速開発とは?(定義) △「プログラムを自動生成する開発ツールを用いた開 発のこと」 ◎業務のデザイン(1)から運用・保守工程をも含めたシ ステム・ライフサイクル全般にわたる生産性向上と 継続的品質改善を行うやり方 (1)業務要件をもとに、業務のあるべき姿を設計すること ◎「超高速」には、「期間短縮」、「工数削減」と「品質向 上による手戻り削減」の意味を含む •労働集約的な開発のやり方との比較 33 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  34. 34. “超高速開発ツール”の特長 設計情報から実装コードを生成する、UIをすばやく開 発する だけではない ビジネス・プロセスなどの業務に関わる情報やシステ ム設計に関する情報をリポジトリーで管理している ⇒ 業務の可視化 ⇒ 設計の可視化 ⇒ 業務(設計)から実装までの追跡可能性の担保 ⇒ 変更の影響分析が可能 マルチプラットフォームに対応 34 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  35. 35. ①業務、データ中心にした設計・変更が可能 ②プログラミング技術不要 ③データベースの自動設計 ④稼働後の柔軟な変更、追加 超高速開発メソッド/ツールの有効性 ビジネスルール管理 設計情報管理 運用・保守管理 各種言語による 自動プログラミング <リポジトリ> <プログラム自動生成ツール> + [注目すべき特徴] 35
  36. 36. 要求の変化を短期間で吸収する 要求機能と のGAP WF型開発で 実現した機能 超高速開発で 実現した機能 要求機能と のGAP 機能レベル 時間 要求されている機能 36
  37. 37. ビジネス・ プロセス 情報管理体系 事業の種類 組織構造 調達先 物流構造 顧客カテゴリー DFD コンテキスト・ダイアグラム: LAC社 販売管理業務の位置づけ (販売管理業務と他の業務との情報の流れ:販売管理にかかわる情報のみを示す) 総務・人事 管理業務金融機関 注文書、受注情報、 顧客情報、納入先情報 引合・商談情報、見積情報、 納品物受領書、 プロジェクト状況 契約書、 発注書[注文書] 支払い通知書、 請求先情報 販売計画 (予算) 販売計画(確定)、 販売実績 支払予定情報 (EBデータ) 人件費、 原価情報 製商品・サービスの 提供 LACHD お客様/ プロジェクト 請求先 仕入先 経理・会計業務 経営管理業務 販売計画 (予算) FC情報、 販売実績 見積書、提案 書、 注文請書 見積情報 見積書(仕入)、納期回答情報、 納品書(受領書・直送案内書)、 仕入先情報、製商品情報 請求書 入金情報 売上実績、 仕入実績、 原価情報原価情報 外部倉庫 入庫情報 販売管理業務 未入金情報 ビジネス・プロセス全体図 業務フロー(上位1) Ⅰ-2/3 営業検定 プロジェクト検定 Ⅰ-4 与信管理 Ⅰ-5 案件作成 Ⅰ-6 受注処理 Ⅰ-8 出荷依頼 出荷 Ⅰ-12 売上請求 Ⅰ-13 売上請求締 Level1 販売サイクル(売切) Ⅰ-4 契約書審査 見積書 注文書 契約書 EDI受注 お客様試算書① ② 仕入処理 ⑥ 入庫情報 Ⅱ-16 月次締処理 Ⅱ-17 月次処理 受注連絡票 ④ 出荷計上依頼書 ⑧ 納品書/受領書 売上請求書 ⑤ ⑦ 出荷計上依頼書 ③ 売上一覧 出荷情報 販売管理営業業務営業業務 営業 物流・売上業務 売上請求売上請求 プロジェクト管理 業務シナリオ A.通常処理の場合①→④→⑤→⑦→③→⑧ B.先行発注の場合②→⑦→①→④→⑥→⑧ C.例外出荷の場合 ②→⑦→③→⑧→①→④ G3 売掛金残高表 情報 シス テム 仕入 先/ 倉庫 事業 部・ 営業 部門 営業 管理 部 門・ 業務 管理 部門 経理 部門 お客 様 仕入入力 仕入 データ 支払予定 データ 受領および検収 納品書 (仕入) 請求書 (仕入) 証憑保管 請求書(仕入)の経 理部への回付 請求書 (仕入) 印 注文書 (物販)控 請求書 (仕入)控 納品書 (仕入) 見積書 (仕入業者) 印 印 印 神谷町・汐留で受領 出荷 入荷完了確認 請求書 (仕入) 印 製商品(もの) 発送 製商品(もの) 開始 製商品(もの) 終了 仕入承認入力 製商品(もの) 注文書 (物販または 委託) 印 発注 顧客へ直送の場合 神谷町あるいは汐留で受領 の場合 顧客へ直送の場合 終了 (売上確定へ) 神谷町あるいは汐留へ配送の場合 4.1 4.1 4.1 4.2 4.3 4.4 4.5 業務フロー(下位) 情報管理体系 製品/調達先マトリックス 製品/組織マトリックス BP/業務機能マトリックス 業務/システム機能マトリックス リポジトリが管理する情報と設計の可視化 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 37
  38. 38. “従来の開発のやり方と 何が変わるのか?” そして どのような効果を生むのか? 38
  39. 39. 超高速開発ツールが与える影響 【ユーザー企業】 ユーザー主体開発(もしくは内製化)へのシフトを加速 運用と保守もユーザー企業が主体的に行う方向へ 自社の業務システムは資産継承しながら独自化に向かう 情報システム部門の動き方で、各社収益性に差が出る OS,DBの変更によるシステム開発は減少 【ITコンサルタント、ITC】 技術の幅を広げられる(自らやって見せることができる) 中小企業の業務のIT化推進に直接的に貢献(ToBeの姿を見せることが できる) 【ITベンダー】 下流工程(プログラミング、テスト工程)の発注が激減 ユーザー企業から直接受注するITベンダーが増加 業務の分析とモデリング・スキルが重要になる オフショア開発への発注が減少(ユーザー企業のスピード変更重視) クラウドで提供することが増加(システムを迅速に変更できる) 見積方法 人月工数見積から価値見積へ移行 39
  40. 40. 何が変わるのか(例) 1.品質の作りこみの実現 整合性の維持、トレーサビリティの確保 レビューでの確認ではなく、担当者自身が確認できる 2.プロジェクトの実態が見えるようになる 品質・進捗はリポジトリの状況から判断できる 問題の早期発見が可能になる 人の報告より“はるかに”信頼できる 3.柔軟性が求められる 個人技からチームでの作業になる 4.見積もりの基準が変わる WBSが変わる 工程モデルが変わる 工数配分比率、期間配分比率、要員投入比率が変わる 40 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  41. 41. ☆システム開発の工程モデル ☆製造業の製品開発の工程モデル 販売 製造 研究 開発 製造(改善・改良) 保守(業務での活用) 設計・ 開発 ・テスト 再構築 保守 不能 企画・ 要件 定義 製品開発工程モデルとシステム開発工程モデル 41 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  42. 42. 保守 SLCPが暗黙的に持つ弊害 42 企画 シス テム・ テスト 統合 テスト 開発 内部 (詳細) 設計 要件 定義 運用 準備 外部 (基本) 設計 「開発された完成品の状態を保ち続けるの が保守」という認識 できるだけ多くの要件を入れ込みたくなる (ユーザ側) 要件の変更は、変更ではなく、追加に見える(作業としては、 まさに追加になる) 要件 完成! Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  43. 43. Maintenance(維持改善) これからは、保守(維持改善)こそが重要! 企 画 シ ス テ ム ・ テ ス ト 統 合 テ ス ト 開 発 内 部 ( 詳 細 ) 設 計 要 件 定 義 運 用 準 備 外 部 ( 基 本 ) 設 計 維持改善プロセス 企画プ ロセス 開発プ ロセス 運用 プロ セス 稼働後に、ビジネスの変化に合わせて低コストで容易にシ ステムを修正できることが求められている 現在のSLCPは、時代のニーズにそぐわなくなっている? パッケージ導入/ 手作りシステム 破綻 従来 43 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  44. 44. システム開発において重要なのは、業務ノウハウ! JUAS資料をもとに作成 源流 超上流 開発上流 開発下流 保守 基本 設計 詳細 設計 要件 定義 プログラミング テスト・検収 利活用 要求 仕様 事業 戦略 労働集約型から ツール活用(自動化)へ 商品・サービス 顧客・販売店 資材・原料 設備 資金 要員・組織 システム システム化の 方向性 技術者の シフト 自動化 (工業化) 44
  45. 45. 超高速開発はアジャイル型とWF簡易型が可能 システム運用 第1反復 テス ト 開 発 要 求 第n反復 テス ト 開 発 要 求 ・・・ リリース ・・・ 第1反復 テス ト 開発 要 求 第n反復 テス ト 開発 要 求 ・・・ リリース ・・・ 第1反復 テス ト 開 発 要 求 第n反復 テス ト 開 発 要 求 ・・・ リリース 企画 ・・・ Ⅰ.アジャイル型 最初に10-20%程度の重要基本機能を開発しインクリメンタルに開発。 システム運用 2-3回程度のイ ンクリメンタル Ⅱ.WF簡易型 アーキテクチャはツールの仕様に任せる、あるいは、選択する ・設計主体 ・コーディングレス ・単体テストレス ・要求分析 ・アーキテクチャ選 択 企画 テス ト 開 発 要 求 保守 保守 保守 要求分析結果の 記述の整合性と統 一性の確保が容 易(定形化・パター ン化された記載と なるため) •機能変更・追加の 影響分析が可能 •使用変更をリポジト リーに登録する リポジトリーの活用 テス ト 開発 要 求 リリース テス ト ・設計主体 ・コーディングレス ・単体テストレス •使いながら常時 改善する 45 基幹・管理 業務系 Web・フ ロント系、 情報系 リポジトリーの活用(保有しないツールもある) Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  46. 46. アジャイル開発の得意分野と不得意分野 アジャイル開発の得意とする状況 クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性が なく、人命に関わらないシステム) 熟練した開発者が参加する場合 開発中に頻繁に要件が変わる場合 開発者が少ない場合 混沌とした状況に意欲をもって取り組む組織的文化 計画重視開発の得意とする状況 クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、 もしくは人命に関わるシステム) 経験の少ない開発者が多い場合 開発中に要件がほとんど変わらない場合 開発者が多い場合 秩序を重視する組織的文化 Wikipediaより Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. 2004. ISBN 0321186125 赤字の箇所が 課題 46
  47. 47. アジャイル手法適用の条件 1チームは少人数である チームの数もそれほど大きくない(コミュニケ ーションとイメージの共有が可能な範囲) QCDS(Quality, Cost, Delivery, Scope)に対す る責任を持つ人が、実質のプロジェクト・オー ナーである ビジネス上の意思決定権限を持つ人が参加 する 長期的に安定したシステムを開発するのであ れば、リポジトリを持つツールを利用する 47 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  48. 48. ユーザー主体開発を実現する超高速開発 企画、要求分析・モデリング、 アーキテクチャ設計 運用(業務での活用) 製造 研究 開発 保守(改善・改良) 設計の具象化、開発・テスト 継続的改善 ユーザー主体の DevOps を実現する “超高速開発” 48 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  49. 49. 超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その1 - ツールの特質の理解 ツールへのインプット情報が何かを理解する インプットを作成するための作業は何か(ビジネス・プロセス/ワークフロー 作成、データ項目定義、ビジネス・ルールの識別など)を理解する(DOAをコ ンセプトとしているツールが多い) ツールの最終成果物が何かを理解する 複数のツールの組み合わせが現実的(ビジネス・ロジック、UI、情報分析、 バッチ、テスト、スマホ・タブレットアプリなど) リポジトリが管理しない要求事項・仕様は別の管理が必要 最初の要求事項(改善案・懸案事項の解決方針など) 性能、信頼性、可用性、障害対策などの非機能要件 ツールが対応する場合もある(セキュリティ機能、OSの違いなど) プロトタイプ作成 業務での活用場面をイメージできるプロトタイプの作成は必ず行う UIは、言葉で伝えるのではなく作って評価する 49 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  50. 50. 超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その2 - 発注者のオーナーシップの確立 最終的なQCD+S(Scope)の責任をベンダに任せない Scopeを調整する権限を持つ責任者が参加すること(法律の規定と直接関 係しない画面や帳票の仕様の取捨選択) 運用テストケースの作成と検証は発注者の責任 Web系システムは、小さくはじめて徐々に機能追加をするのが望ましい リポジトリのクロスリファレンンス機能を自ら使う(品質・進捗の客観的判断 の助けになる。ベンダの報告の検証ができる。) 業務運用の仕組み(業務フロー、例外処理、人の作業など)を明確にする のは発注者の責任 ベンダとの契約モデルの見直し アジャイル型で行う場合の契約形態は注意が必要 多重下請けの禁止(機密保持契約の問題があり、One Teamにならない) 多段階契約は困難(工程を区切るのは不可能) 50 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  51. 51. 小さく始めて大きく育てる ~インクリメンタルな開発~ 51 ライフサイクル全期間にわたる継続的改善 優先順位の 高い機能を 最初に開発 ビジネスの変化に 合わせて機能を追 加・変更 継続的改善 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  52. 52. システム開発は日常業務へ! プロジェクト・タイプ の仕事(期間限定の 仕事) QCDをすべて等しく 重視 専門家がやるべき仕 事(しかし、資格は前 提でない) SIベンダーが開発 (QCD)の責任 52 日常業務になる QCD・S(Scope)の 中から優先順位を つけて開発を行う 組織人全員が関与 する 一部の専門性 (ノンコア・コンピテン シー)を外部に求め る 従来 今後 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  53. 53. ウォーターフォール(WF)との生産性の比較 備考 JFS:JUAS Function Scale。画面数と帳票数から規模を換算した値。既存WFの データを基に画面数+帳票数×2/3 を算出(ユーザー発注者が明確に判るのは画 面数、帳票数である)。また、係数はグラフにプロットしたときの傾きを示す。xRADは 係数が小さいので、規模による生産性の変動が少ない。 ・費用・工数・工期ともに超高速開発はウォーターフォール法の3分の1である 備考: 表はJUAS様作成 53 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
  54. 54. 開発生産性向上実績(例1) アプリケーション 労働集約的方法に よる提案 xRAD実績 削減率 A社生産管理シ ステム 100人月 35人月 65%削減 B社基幹業務 300人月 167人月 45%削減 C社輸出入業務 185人月 45人月 75%削減 54 ツールA(ソース生成型) ツールB(実行エンジン型) アプリケーション 労働集約的方法に よる提案 xRAD実績 削減率 D社法定帳票作 成システム 160人月 60人月 62%削減 E社 仕訳検証シ ステム 50人月 10人月 80%削減 F社 基幹システム 400人月 200人月 50%削減
  55. 55. 開発生産性向上実績(例2) アプリケーション 既存システム xRAD実績 削減率 G社 基幹システム 6,000万 800万 86%削減 既存言語 現行規模 xRAD実績 削減率 COBOL 1,300k steps 34k steps 97%削減 PL/I 3,700k steps 78k steps 98%削減 RPG 100k steps 2.7k steps 97%削減 VB(C/S) 130k steps 8.5k steps 93%削減 55 ツールC(実行エンジン型) ツールE(実行エンジン型) 企業 削減率 H社 連携フローの開発効率は2倍 I社 開発効率を30%向上 ツールD(EAIツール) 以下はお客様の評価
  56. 56. 保守効率の向上実績(例1) アプリケーション 導入前 導入後 削減率 J社 年間外部支払料金 6,000万~8,000万 年間外部支払料金 100万 98% K社 4名(10システム) 4名(15システム以上) 同じ要員で追加 システム開発 56 ツールA(ソ-ス生成型) ツールB(実行エンジン型) アプリケーション 導入前 導入後 削減率 D社法定帳票作 成システム 1人/100人月 1人/50人月 (変更対応200件/年間) 50%削減 F社 基幹システ ム 3,000万円(ERP 年間ラ ンニングコスト) 年間保守料(ライセンス 込)1,000万円 66%削減
  57. 57. 保守効率の向上実績(例2) 57 企業 削減率 O社 更新負荷66%減少 P社 運用負荷70%削減 Q社 ECサイトへの出店を30日から2日へ アプリケーション 導入前 導入後 削減率 L社 基幹システ ム 年間保守料金 2,520万円 年間保守料金 336万円 85%削減 ツールC(実行エンジン型) ツールD(EAIツール) 以下はお客様の評価
  58. 58. ITエンジニアに 求められているスキル 58
  59. 59. アプリケーションの種類とIS技術者の役割 基幹業務アプリ BtoC Web アプリ 情報分析、 ビッグデータ分析 重視する 要素 品質+コスト 品質+スピード コスト+スピード 適用可 能な開発 モデル ウォーターフォール/ インクリメンタル インクリメンタル/ アジャイル N/A(通常業務) IS技術者 の参画 の程度 ◎ ○ △(データアナリスト/ データサイエンティスト) 業務部 門の参 画の程 度 △ ○ ◎ IS技術者が業務を分析できないと基幹業務アプリの 改善が進まない 59
  60. 60. イノベーションの推進:3段階の体系化を! Technology Architecture Application Architecture Data Architecture Business Architecture 業務改善・標準化 組織改革 ルール改善 ビジネス自体の改革 現場改善 商品・サービスの創造 顧客確保・拡大 境界範囲の抜本見直し 顧客志向、理想 ・帰納法→演繹法 ・漸進的、革新的 視点 視点 Enterprise Architecture コアコンピタンスの見直し 企画設計の流れ 戦略企画 要件定義・運用 要件定義~ 総合テスト 経営学・マーケティング 改善技術学 (IE、KT、WD、QC等) 情報工学 リーダーシップ・ コミュニケーション ビジネスモデル 業務システム 情報システム BPM BMDA (Business Model Driven Architecture) JUAS資料 60
  61. 61. アプリケーションの設計=業務の設計 アプリケーション構造定義、機能定義、データ構造設計、モ ジュール化、データベース設計、UI設計、製品機能割り当て 今まで 今後 業務プロセス設計、ビジネス・ルール設計、 抽象化、データ構造設計、機能定義、データ ベース設計、UI設計、部品管理、超高速開発 ツールの活用 プログム設計、コーディング、単体テスト データ中心の発想が求められている時代です 61
  62. 62. 参考:高いテクニカル・スキルが要求される分野 社会インフラ・ システム アーキテク チャ 製品・ツール の開発 組込ソフトウェア 重視 する 要素 品質 品質 品質 品質+スピード 重要 なス キル 設計、プロジェ クトマネジメン ト、システム設 計、プログラム 設計 等 発想力、創造 性、抽象化、 汎用化、モデ リング、セキュ リティ、プロダ クト・スキル、 OSS等 プログラム設 計、プログラミ ング、UI設計、 プロダクト・ス キル、セキュリ ティ、OSS等 発想力、創造性、 デザイン、UI設 計、プログラミン グ、プロダクト・ スキル、セキュリ ティ、OSS等 ハイレベルな技術スキル保有者の需要は減らない 62
  63. 63. 参考 63
  64. 64. 導入事例(超高速開発コミュニティ 事例集より) 11.バッチ処理プログラムのステップ数が 1/17に 12.非常に短期間で業務全体を“見える化” 13.国防総省が認めた世界最高水準の品質 と生産性 14.端 末 の 変 更 に 影 響 を 受 け な い 店 舗 シ ス テ ム 構 築 15.電子帳簿保存法に対応したシステムを2 ヶ月間で開発 16.iPad無人受付管理システムを3ヶ月でアジ ャイル開発 17.ASTERIA WARPを活用し工数を約60%削 減 18.輸出入管理システムを4か月間でリリース 19.Androidタブレットの作業実績管理 システ ムを3ヶ月でアジャイル開発 20.上流工程からの自動テスト連携 21.マンション賃貸管理拡張管理システム 1.初の公式ショッピングサイトを企画構想か ら3ヶ月で構築 2.ベネトン ジャパン株式会社様 ASTERIA WARPでECサイト出店を実 現 出店準備が30日から2日へ短縮! 3.“現場に負担のない研究テーマ管理”を 最短コースでシステム化 4.物流ラインでの欠品を正確に知らせるシ ステムを迅速に新規開発 5.通販事業の基幹システムを内製し、お客 様の要望に応える商品の企画や販売計 画の精度を向上 6.プロセスの電子手順化 7.顧客管理システム ~70種類にも及ぶペ ーパー業務にメス~ 8.製造業様向け基幹システム再構築に超 高速開発ツールWagby適用 9.グループ会社のワークフロー基盤をユー ザー担当者が2か月でリリース 10.流通システムにおけるテスト作業の品質 と生産性の向上 https://www.x-rad.jp/usecase/ より 64
  65. 65. 導入事例(スライドのみ) このように短納期で開発できたのは、Magicで開発した、ECサイト構築パッ ケージ「EC FORWARD」をハワイアンズ様に合わせてカスタマイズを行 ったためです。Magicの自由に、容易にカスタマイズできるという特性によ り、お客様ごとの仕様に柔軟に対応できるのです..... お客様からの要望 にも、随時対応可能なため、お客様の満足度も非常に高いものになって います。」 ベネトン ジャパン株式会社では、近年、国内ECサイトへの出店を加速しており 、2011年11月に「ZOZOTOWN」、2012年9月に「bidders」、2012年10月に は「楽天」と立て続けに出店した。こうしたサイトでは、サイトごとに独自の フォーマットで売上データが送られてくる... ZOZOTOWN出店時は、独自フォ ーマットの売上データをインフォテリア株式会社のデータ連携ミドルウェア「 ASTERIA WARP」によって社内標準フォーマットに変換。売上情報に加 え、バーコード情報、値引き、レシート番号といった情報までを店舗管 理サーバーに吸い上げる仕組みを、およそ1カ月という短期間で開発し た.....そのシステムをベースとすることで、その後のbidders出店時は3日間、 楽天出店 時はわずか2日間で開発を終えたという。 https://www.x-rad.jp/usecase/ より 65
  66. 66. 導入事例(スライドのみ) https://www.x-rad.jp/usecase/ より ライオン株式会社 研究開発本部様では、超高速開発ツール「GeneXus」 をベースにしたサービス....を用いて、研究開発テーマ管理システムをス ピード導入....これまで運用していたWEBシステムはフォーマットが決まっており 入力項目も膨大です。“でーたコレクト for Excel”ならば、研究所毎で使用し ているフォーマットをそのまま活用しながら、欲しい情報がタイムリーに 引き出せます...「必要なデータを入力したExcelファイルを準備する だけで簡単にデータが集約されました。また現状手で入力しているExcelの データも、時間がかからず集約できるようになると考えています」とのご感 想 大和ライフネクストは、販売管理システムを「Sapiens」で再構築。2005年にシス テム開発に着手し1年後の2006年11月にシステムサービスインを実現。システ ム規模はテーブル数180 画面数209 帳票数28 バッチプログラム数 40...「Sapiens」採用とサピエンスジャパンへの開発委託(外製)により、開発コス トは従来比40%以上のコスト削減を実現.....要件・仕様検討、エンドユーザー (社内)との調整、テスト・リリース判断となどに特化し、ビジネス検討にリソース を集中できる事になり、エンドユーザー要請に迅速に対応できるIT部門と して体制強化が出来た。又外製化したことで社内要員を割く事なく、事業環境 の変化に対応した機能追加、変更ニーズに柔軟に対応可能となった。 66
  67. 67. 導入事例(スライドのみ) 従来のパッケージ製品はロジックに触れることができず、簡単な文言の修正で も社外のSI企業に依頼する必要があるなどの悩みがありました。ユニケージ 開発手法で再構築した新システムでは実際の業務フローに沿って、『こ のデータとこのデータがつながり、こう動いている』といった見通しがよく なりました。そのため、担当者自ら機能面のカスタマイズを行うことが可能にな ってます。現在、開発・運用に携わるメンバーは3名。実際の運用でログ データを見ながら自分たちの手で改良を重ねるという開発の枠組みが できつつあります。基幹システムにパッケージ製品を使っていたときに 比べて、システムの運用・保守コストなども抑えられました。 高水準の企画開発力とマーケティング力、製造技術力を併せ持つエレクト ロニクスの総合商社であるダイトエレクトロン株式会社、グループ各社が 個別に導入していたワークフローシステムの統合.... 当時導入していたワ ークフローメーカー2社に工数....48人月はかかる.....採用されたコラボフロ ーの場合、ユーザー担当者の設定のみで開発でき、実際にかかった期 間は、2名が業務と掛け持ちで実施してたった2か月 https://www.x-rad.jp/usecase/ より 67
  68. 68. 導入事例(スライドのみ) PEXAによる業務分析は、各業務担当者にヒアリングしながらその場で 入力し、担当者に確認しながら業務フロー図ができる....ひと通りヒアリン グをし業務フロー図が描けた後は、それらを「製品受注」「出荷指示」等のシナ リオと、「受注」、「出荷」等のドメインに分類整理し、最終的にはマトリクスにして 弊社業務全体を一覧で見られる...業務フロー図を作成してみると、システ ムで運用できていないフローや無理やり入力でシステム的なつじつまを 合わせているフローの存在も明らかになり、単純なリプレースでなく、最適 化された新システム...業務フロー図の作成は2~3時間のヒアリング10回やっ た程度で出来上がったのは驚きでした。ヒアリングもシステムには全く関係 のない各業務担当者に対して、簡単な説明の後すぐに業務の流れを 聞き取りツールに入力し、確認しながら手際よく業務フロー図が出来上 がり。..後で業務フロー上承認のタイミングが異なっている事が判明しても、業 務フロー図を簡単に変更できる点も優れていました。 https://www.x-rad.jp/usecase/ より 68
  69. 69. 導入事例(スライドのみ) •機械工具やメンテナンス部品を販売するビジネスを展開している千葉産業様で は、全社員へiPadを配布して業務活用を検討されていました。20万点以 上の商品を取り扱っているため、お客様の幅広いニーズに応えるため には業務への熟練が必要とされて....iPadの導入に伴い、経験が少ない若 手の社員でも付加価値の高い営業活動を行うためのツールを探していた ところ「seap」に出会いました。営業ツール用のiPadアプリを開発する際には、 従来1アプリあたり 数百万円の費用と数ヶ月の期間を必要としますが、 「seap」を導入することにより、月額10万円で無制限にアプリを作成でき 、数時間でアプリを作成....導入後は、自社の強みをお客様に伝える....自 社の技術や人材を紹介するカタログアプリを作成....それ以外にも、直営店舗 に来店をせずとも商品の紹介ができるようなアプリも作成しました。特に 、自社製品の加工作業の工程もアプリ上に埋め込まれた動画を用いて説明で きることはお客様からの信頼性向上にも繋がり、....安心して仕事をまかせ て頂ける...今後iPadならではの...商品の紹介などにもチャレンジして、業界に おける営業の常識を変えられるような取り組みをしたいと考えて.... https://www.x-rad.jp/usecase/ より 69
  70. 70. 生産性が向上すると市場は小さくなるのか? 他の業界では、生産性を向上させることを業務改善の常態と して行っている 生産性の向上は市場規模の拡大と利益向上につながってい る 生産性を上げても市場が大きくならないのは、そもそも商品 やサービスに欠陥があるから IT業界で、生産性の向上に熱心でないのは、システ ム開発サービスという商品にそもそも価値がない(と 経営者が深層では考えている)ということの証拠 技術者の数で売り上げ規模が決定されるビジネスモデルを採用するかぎ り、市場は大きくならない(人口減少は確実なので) 70 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  71. 71. 8,442 4,595 労働集約型産業の行く末(人口の減少) 50年で売り上げ ▼45%(10年ごとに 約1割減少) 71 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  72. 72. SI ビジネス規模 一般社団法人 電子情報技術産業協会(JEITA) 2014.6.30 「 2013年度 ソフトウェアおよびソリューションサービス市場規模調査結果について」 http://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=706&ca=1 ? 72
  73. 73. 超高速開発ツールを活用すると、 市場は縮小するどころか大きくなる! Gartner Seminar in Sydney 2011 をもとに作成 構造化された定型 業務 人の仕事の80%は、構造化されない作業 膨大なIT化市場! (超高速開発ツール がないとシステム化 が不可能) 構造化されていない さまざまな情報が飛び 交っている世界 73
  74. 74. P.ドラッカー 「ネクスト・ソサエティ」 こうして、われわれの眼前に膨大な仕事が 横たわっている。第一に、情報に通暁しなけ ればならない。そのためには、一人ひとりが 情報リテラシーを習得する必要がある。... 情報を仕事の道具として見なければならな い。...第二に、外部で起こっていることを 理解するために、その情報リテラシーを実際 に使わなければならない。 2002年出版 (上田惇生 訳) 不可欠の情報リテラシー 74 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  75. 75. 組織活動は情報システムである •情報管理(Information Management)の重要性は、 1970年代から語られている •理論にいたっては、1950年代まで遡ることができ る –組織は高度な情報処理と様々なレベルでの意思決定の 必要性の協調システムである(H.サイモン:1958) •政府や自治体の組織の活動において、今後ますま す情報の活用とその管理が重要になる。(全省庁・ 自治体職員が情報とそれを扱う仕組み[情報システ ム]に精通することが必要になる。将来の課題。) 75 Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved.
  76. 76. IT投資に熱心でない日本 一般社団法人 電子情報技術産業協会(JEITA) 2013.10.9 「ITを活用した経営に対する日米企業の相違分析」調査結果の公表について http://home.jeita.or.jp/upload_file/20131008112419_odi62Sl49b.gif なぜ、こういう結果になるのでしょう? 76
  77. 77. Technology とは? Technologyという英語は、コンピュータ が生まれる前からある言葉 •Knowledge about scientific or industrial methods, or the use of these methods (ロ ングマン現在アメリカ英語辞典) “情報の活用方法に関する業界の ノウハウ” Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 77
  78. 78. “IT経営”とは? IT(Information Technology)を使った経営 のこと?(スマホやタブレットやツールを 駆使して経営を行うこと[日本語の語感 からするイメージ]) I(Information)をビジネス活動に生かす 方策(Technology)を使って企業を経営す ること(英語圏の人のとらえ方) Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 78
  79. 79. 塩野七生 歴史を書きながら痛感させられることに一つは、情 報とは、その重要性を理解したものにしか伝わらな いということだ。(中略)ユリウス・カエサルも言ってい る。「人間ならば誰にでも、現実のすべてが見えるわ けではない。多くの人は、見たいと欲する現実しか 見ていない」情報を活用できるのは、見たくな い現実でも直視する人だけなのである。 皇帝フリードリッヒ二世の生涯 79
  80. 80. IT と IS は異なる概念 IT(Information Technology) •“情報の活用方法に関する業界のノウハウ” •ハードウェア/ソフトウェアという手段を企業活動 に有効に活用すること(結果としてこのような意 味も生まれるが、基本は情報をどのように生かす のか?という視点) IS(Information System) •情報を扱う仕組み(プロセス、体制、役割、権限、技術の 活用など) Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 80

×