SlideShare uma empresa Scribd logo
1 de 74
Baixar para ler offline
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
今なぜ超高速開発なのか? - What、Why および ビジネス上の価値、効果 - 
一般社団法人 ICT経営パートナーズ協会 
超高速開発コミュニティ 
大島 正善(MBC) 
2014年10月 
1
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
内容 
1.背景 
2.現状の基幹業務システムの課題 
3.あるべき姿 
4.超高速開発とは何か、そして、その狙いは? 
5.超高速開発ツールを使うとシステム開発は どう変わる? 
6.まとめ 
7.参考資料 
2
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
情報システム(IS)にまつわる長年の課題 
労働集約的な開発のやり方から脱却できない 
他の産業と異なり、自動化を推進し品質と生産性を高めよう という意識が欠如している 
一般の製品のように、長く使い続けることができず数年する と陳腐化し、再構築せざるを得ない(ライフサイクルコストが 低下しない) 
ベテランは年々減っており、業務ノウハウとシステムの全体 像を理解している技術者が少なくなってしまった(中堅企業・ 大企業では、業務システムを最初から構築することは、この 20年程度行われていない) 
保守コストは70%-80%を占める状況が続いている(新規投 資ができない) 
3
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
出典:経済産業省「次世代高度IT人材の人材像と能力」(H24.4.26)をもとに作成 
超高速開発の 
真の狙い(2つ) 
① 
② 
4
Copyright ©2014 MBC (Method Based Consulting) IPA: 「IT人材白書2014」概要 (2014.4) All Rights Reserved. 
5
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
価値を創る 
事業に生かす 
IPA: 「IT人材白書2014」概要 (2014.4) 
6
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
7 
根っこにある問題意識 
現状の情報システムは『ビジネ ス環境の変化に迅速に対応でき ているか?』 
情報システムを活用する“ユー ザー企業”からの視点
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ビジネスと情報システムとの間の”GAP” 
理念/目標/戦略/方針 
ビジネス・モデル 
(プロセス/組織…) 
情報システムモデル 
(アプリ/システム構造…) 
テクノロジーモデル 
(適用技術/製品選択) 
詳細モデル 
ビジ 
ネス 
領域 
情報 
シス 
テム 
(IS) 
領域 
分断されて 
いる 
8
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
現在の基幹業務システムの状況(その1) 
•経営環境の変化に迅速に対応できない 
•情報システム部門の中に、業務の仕組みと情報シ ステムの仕組みや仕様を理解している要員が減っ てしまった 
•バックログが減らない 
•怖くて手をつけられない 
•些細な変更もベンダに確認しないとできない 
•アプリケーション・システムが個別に開発され、重 複するデータが関連なく保持されてしまい、活用が 困難となっている 
•莫大な費用が請求されるERPのバージョンアップ 
9
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
現在の基幹業務システムの状況(その2) 
ソフトウェアの設計仕様は、ソースコード を見なければわからない 
それは、業務の仕組み(判断基準と実 行すべき行動)のことを理解している人 がいないことを意味する 
10 
この状況は、組織にとって解決すべき、 かなり優先度の高い課題ではないか?
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
現状のシステム開発の姿(伝言ゲーム) 
内部設計書 
(処理機能記述、 
ファイル・レイアウ 
ト、定義書、 
システム概要書 
(システム概要、ER図、 
共通機能、入出力等) 
共通部品の変更 
が適切に反映さ 
れていない 
PM / リーダー 
契約マスターの変更が他 
の成果物に反映されてい 
ないと聞いているが、他 
の変更は大丈夫なんだろ 
うか? 
現行プログラムの仕 
様の一部が内部仕 
様化されないことに 
なっても気がつかな 
い。 
共通部品を早く決め 
る必要があることは 
分かっているが、共 
通基盤のAPIも変更 
が頻発するし、部品の 
単位だって変える必 
要があるし、簡単に 
は決まらないさ 
事務設計書 
の記載とシス 
テム・フローに 
不整合がある 
な... 
プログラム仕様 
書 
共通部品 
契約マスター 
定義書 
外部設計書 
(システム・フロー/ 
機能構造定義/ 
部品仕様/ファイル 
仕様など)) 
事務設計書 
(業務フロー、業務仕 
様記述書、画面イ 
メージ、帳票イメージ 
等) 
業務分析担当 
レビュアー 
レビュアー 
PM 
アプリ設計担当 
DB設計担当 
部品設計担当 
開発担当 
開発担当 
不整合 
11
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
イノベーションが求められている 
企業や行政組織の情報システムの役割は拡大しており、ビジ ネス上あるいは法律や施策、さらには、社会ニーズを迅速に 情報システムに反映することが求められている 
現状の情報システムは、構造そのものが変化に対応できない ものになっている(構造不良を起こしている) 
一部の組織を除いて、情報システムの設計から実装に関わる ことができる人材が不足しており、ギャップを埋める必要があ る 
システム開発という作業を個人のスキルに依存せず管理可能 な状態にしていくことが求められている 
ビジネスや社会の変化に合わせて、ソフトウェアの継続的改善 を可能にする必要がある 
12
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
13
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“あるべき姿”は? 
14
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ビジネスと情報システムが一体化 
理念/目標/戦略/方針 
ビジネス・モデル 
(プロセス/組織…) 
情報システムモデル 
(アプリ/システム構造…) 
テクノロジーモデル 
(適用技術/製品選択) 
詳細モデル 
ビジ 
ネス 
領域 
情報 
シス 
テム 
(IS) 
領域 
15 
ビジネス・モデルの 
要素 
情報システム・ 
モデルの要素 
連携:トレースできる 
何ができればよいのか?
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ビジネス活動の主要要素 
顧客 
サプライチェーン 
扱う商品やサービス 
ビジネス・プロセス 
業務機能 
ビジネス・ルール(判断とその結 果の行動あるいは活動の基準) 
情報 
組織・役割・責任 
営業所、支店、拠点、工場などの 場所 
ITの仕組み(Web、クラウド、スマ ホ、ネットワーク) 
企業理念・目標・戦略・収益・利 益・社会貢献 
顧客 
商流 
販売するモノ(製・商品) 
ビジネス・プロセス 
業務機能 
ビジネス・ルール 
情報 
組織 
配置 
(ビジネス)コンテキスト 
16
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 
○ 
○ 
戦略もチャネルもさらに詳細化する 
17 
多次元ワールド。 
人が管理できる限界 を超えている!
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
事業 
ビジネス・ 
プロセス 
ビジネス・ 
プロセス 
事業 
事業 
データ項目 
ビジネス・ 
プロセス 
情報 
事業 
ビジネス・ 
プロセス 
組織 
拠点 
データ項目 
ビジネス・ 
ルール 
ビジネス・ 
ルール 
業務機能 
目標 
目標 
戦略 
ビジネス・モデルの要素間の関連の全体図の例 
18
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
システムの構成要素間の関係 
情報 
データ 項目 
システム 機能 
システム 機能 
レベル2 機能 
レベル2 機能 
システム機 能 
製品 
非機能 要件 
非機能 要件 
レベル4 機能 
DB 
DB 
画面 
帳票 
JOB 
アプリ機能 
製品・基盤機能 
DB 
画面 
帳票 
JOB 
プログラム 
ソフトウェ アの構造 
非機能要件 
エンティティとデータ項目 
エンティティ 
業務プロセス 
業務プロセス 
・業務機能 
システム機能 
(レベル1) 
システム機能 
(レベルn) 
システム機能 
基盤要件 
製品 
基盤機能・製品 
DB 
データ項目 
19 
システムの世界も 
多次元ワールド。 
人が管理できる限界 を超えている!
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
リポジトリとは? 
1.ビジネス・モデルの構成要素間の関 連を保持する 
2.ソフトウェア・モデルの構成要素間の 関連を保持する 
3.ビジネス・モデルとソフトウェア・モデ ルの関係を保持する 
20 
“ビジネス活動全体の部品表”
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
リポジトリの役割 
(業務プロセス、 
業務ルール、 
データ項目、 
画面、帳票等) 
21 
業務プロセスが変わる 
仕事のやり方が変わる 
判断基準が変わる 
管理するデータが追加される 
情報の管理単位が変わる 
画面が追加される 
帳票が追加される 
変更は自動的に 
すべての要素(ビジネス およびシステムの両方) に反映される! 
整合性が担保される 
リポジトリ 
プロセスの順序A⇒B 
ルールX ⇒ Y 
データ項目c⇒d1&d2 
画面u1,u2追加 
業務フロー、 
システム機能、 
画面、帳票、 
DB など 
多くの超高速開発ツールはリポジトリを持ち、重要な役割はリポ ジトリに保管される情報の維持管理である!!
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
リポジトリを使ったシステム開発の姿 
リポジトリ 
(部品表) 
詳細仕様 
業務フロー 
データモデル /データ項目 定義 
運用テスト・シナ リオ 
詳細仕様 
システム・テスト・ 
シナリオ 
統合テスト 
シナリオ 
ルール記述 
画面/帳票/ インターフェー ス仕様 
トラン仕様/ 
バッチ仕様 
テスト担当2 
設計担当1 
ITベンダ 
テスト担当1 
設計担当2 
設計担当3 
設計担当4 
業務分析担当 
整合性が保証される 
22
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発とそのツールが可能にすること 
 情報システムの変化への対応力強化 
 情報システム構築のハードルを下げる (業務担当 
者ができるようになる) 
情報システム 
開発の現場 
業務部門 
の現場 
従来 
超高速開発 
現場のミドルが強い日本の 
企業には最適な手段! 
23
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“超高速開発”とは? 
24
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発とは?(定義) 
△「プログラムを自動生成する開発ツールを用いた開 発のこと」 
◎業務のデザイン(1)から運用・保守工程をも含めたシ ステム・ライフサイクル全般にわたる生産性向上と 継続的品質改善を行うやり方 
(1)業務要件をもとに、業務のあるべき姿を設計すること 
◎「超高速」には、「期間短縮」、「工数削減」と「品質向 上による手戻り削減」の意味を含む 
•労働集約的な開発のやり方との比較 
25
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“超高速開発ツール”の特長 
設計情報から実装コードを生成する、UIをすばやく開 発する 
だけではない 
ビジネス・プロセスなどの業務に関わる情報やシステ ム設計に関する情報をリポジトリーで管理している 
⇒ 業務の可視化 
⇒ 設計の可視化 
⇒ 業務(設計)から実装までの追跡可能性の担保 
⇒ 変更の影響分析が可能 
マルチプラットフォームに対応 
26
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“超高速開発ツール”のタイプ 
リポジトリー型 
プログラム生成 
中間言語生成+実行エンジン 
ビジネス・モデル管理、設計情報管理、テスト情報 管理 
フレームワーク・パターン適合型 
プログラム部品の組み合わせ 
半製品、UI部品の組み合わせ 
27
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“従来の開発のやり方と 何が変わるのか?” そして どのような効果を生むのか? 
28
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
何が変わるのか(例) 
1.品質の作りこみの実現 
整合性の維持、トレーサビリティの確保 
レビューでの確認ではなく、担当者自身が確認できる 
2.プロジェクトの実態が見えるようになる 
品質・進捗はリポジトリの状況から判断できる 
問題の早期発見が可能になる 
人の報告より“はるかに”信頼できる 
3.柔軟性が求められる 
個人技からチームでの作業になる 
4.見積もりの基準が変わる 
WBSが変わる 
工程モデルが変わる 
工数配分比率、期間配分比率、要員投入比率が変わる 
29
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“超高速開発ツール”導入の効果 
1.品質の作りこみの実現 
2.高度な設計・開発スキル習得からの解放(特殊技能 者の開発から工業生産化へ) 
3.要件追加・変更、機能拡張期間の大幅短縮の実現 
4.開発・保守コストの大幅削減 
5.テストでのバグ発生の大幅減少 
6.ユーザー要件の意思決定スピードの改善 
7.システムライフサイクルの長期化(TCOの削減) 
8.投資効果がないと思われていた業務のシステム化の実現 
9.業務分析・モデリング作業へのスキルのシフト(知識労働へ) 
10.業務担当者が情報システムの構築に関与できるようになる( ビジネスとISが一体化している時代には大事) 
30
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
☆システム開発の工程モデル 
☆製造業の製品開発の工程モデル 
販売 
製造 
研究 開発 
製造(改善・改良) 
保守(業務での活用) 
設計・ 開発 
・テスト 
再構築 
保守 不能 
企画・ 
要件 
定義 
製品開発工程モデルとシステム開発工程モデル 
31
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
保守 
SLCPが暗黙的に持つ弊害 
32 
企画 
シス テム・ テスト 
統合 テスト 
開発 
内部 
(詳細) 設計 
要件 定義 
運用 準備 
外部 (基本) 設計 
「開発された完成品の状態を保ち続けるの が保守」という認識 
できるだけ多くの要件を入れ込みたくなる (ユーザ側) 
要件の変更は、変更ではなく、追加に見える(作業としては、 まさに追加になる) 
要件 
完成!
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
Maintenance(維持改善) 
これからは、保守(維持改善)こそが重要! 
企 画 
シ ス テ ム ・ テ ス ト 
統 合 テ ス ト 
開 発 
内 部 
( 詳 細 ) 設 計 
要 件 定 義 
運 用 準 備 
外 部 ( 基 本 ) 設 計 
維持改善プロセス 
企画プ ロセス 
開発プ ロセス 
運用 プロ セス 
稼働後に、ビジネスの変化に合わせて低コストで容易にシ ステムを修正できることが求められている 
現在のSLCPは、時代のニーズにそぐわなくなっている? 
パッケージ導入/ 
手作りシステム 
破綻 
従来 
33
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発はアジャイル型とWF簡易型が可能 
システム運用 
第1反復 
テス ト 
開 発 
要 求 
第n反復 
テス ト 
開 発 
要 求 
・・・ 
リリース 
・・・ 
第1反復 
テス ト 
開発 
要 求 
第n反復 
テス ト 
開発 
要 求 
・・・ 
リリース 
・・・ 
第1反復 
テス ト 
開 発 
要 求 
第n反復 
テス ト 
開 発 
要 求 
・・・ 
リリース 
企画 
・・・ 
Ⅰ.アジャイル型 最初に10-20%程度の重要基本機能を開発しインクリメンタルに開発。 
システム運用 
2-3回程度のイ ンクリメンタル 
Ⅱ.WF簡易型 アーキテクチャはツールの仕様に任せる、あるいは、選択する 
・設計主体 ・コーディングレス ・単体テストレス 
・要求分析 ・アーキテクチャ選 択 
企画 
テス ト 
開 発 
要 求 
保守 
保守 
保守 
要求分析結果の 記述の整合性と統 一性の確保が容 易(定形化・パター ン化された記載と なるため) 
•機能変更・追加の 影響分析が可能 
•使用変更をリポジト リーに登録する 
リポジトリーの活用 
テス ト 
開発 
要 求 
リリース 
テス ト 
・設計主体 ・コーディングレス ・単体テストレス 
•使いながら常時 改善する 
34 
基幹・管理 業務系 
Web・フ ロント系、 情報系 
リポジトリーの活用(保有しないツールもある)
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
アジャイル開発の得意分野と不得意分野 
アジャイル開発の得意とする状況 
クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性が なく、人命に関わらないシステム) 
熟練した開発者が参加する場合 
開発中に頻繁に要件が変わる場合 
開発者が少ない場合 
混沌とした状況に意欲をもって取り組む組織的文化 
計画重視開発の得意とする状況 
クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、 もしくは人命に関わるシステム) 
経験の少ない開発者が多い場合 
開発中に要件がほとんど変わらない場合 
開発者が多い場合 
秩序を重視する組織的文化 
Wikipediaより Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. 2004. ISBN 0321186125 
赤字の箇所が 課題 
35
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
アジャイル手法適用の条件 
1チームは少人数である 
チームの数もそれほど大きくない(コミュニケ ーションとイメージの共有が可能な範囲) 
QCDS(Quality, Cost, Delivery, Scope)に対す る責任を持つ人が、実質のプロジェクト・オー ナーである 
ビジネス上の意思決定権限を持つ人が参加 する 
長期的に安定したシステムを開発するのであ れば、リポジトリを持つツールを利用する 
36
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ユーザー主体開発を実現する超高速開発 
企画、要求分析・モデリング、 
アーキテクチャ設計 
運用(業務での活用) 
製造 
研究 
開発 
保守(改善・改良) 
設計の具象化、開発・テスト 
継続的改善 
ユーザー主体の DevOps を実現する “超高速開発” 
37
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
小さく始めて大きく育てる ~インクリメンタルな開発~ 
38 
ライフサイクル全期間にわたる継続的改善 
優先順位の 高い機能を 最初に開発 
ビジネスの変化に 合わせて機能を追 加・変更 
継続的改善
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
システム開発は日常業務へ! 
プロジェクト・タイプ の仕事(期間限定の 仕事) 
QCDをすべて等しく 重視 
専門家がやるべき仕 事(しかし、資格は前 提でない) 
SIベンダーが開発 (QCD)の責任 
39 
日常業務になる 
QCD・S(Scope)の 中から優先順位を つけて開発を行う 
組織人全員が関与 する 
一部の専門性 (ノンコア・コンピテン シー)を外部に求め る 
従来 
今後
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
人の役割は非定型業務へシフトし続ける 
40
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ウォーターフォール(WF)との生産性の比較 
備考 
JFS:JUAS Function Scale。画面数と帳票数から規模を換算した値。既存WFの 
データを基に画面数+帳票数×2/3 を算出(ユーザー発注者が明確に判るのは画 
面数、帳票数である)。また、係数はグラフにプロットしたときの傾きを示す。xRADは 
係数が小さいので、規模による生産性の変動が少ない。 
・費用・工数・工期ともに超高速開発はウォーターフォール法の3分の1である 
備考: 表はJUAS様作成 
41 
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
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
開発生産性向上実績(例1) 
アプリケーション 
労働集約的方法に よる提案 
xRAD実績 
削減率 
A社生産管理シ ステム 
100人月 
35人月 
65%削減 
B社基幹業務 
300人月 
167人月 
45%削減 
C社輸出入業務 
185人月 
45人月 
75%削減 
42 
ツールA 
ツールB 
アプリケーション 
労働集約的方法に よる提案 
xRAD実績 
削減率 
D社法定帳票作 成システム 
160人月 
60人月 
62%削減 
E社 仕訳検証シ ステム 
50人月 
10人月 
80%削減 
F社 基幹システム 
400人月 
200人月 
50%削減
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
開発生産性向上実績(例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%削減 
43 
ツールC 
ツールE 
企業 
削減率 
H社 
連携フローの開発効率は2倍 
I社 
開発効率を30%向上 
ツールD 
以下はお客様の評価
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
保守効率の向上実績(例1) 
アプリケーション 
導入前 
導入後 
削減率 
J社 
年間外部支払料金 6,000万~8,000万 
年間外部支払料金 
100万 
98% 
K社 
4名(10システム) 
4名(15システム以上) 
同じ要員で追加 システム開発 
44 
ツールA 
ツールB 
アプリケーション 
導入前 
導入後 
削減率 
D社法定帳票作 成システム 
1人/100人月 
1人/50人月 
(変更対応200件/年間) 
50%削減 
F社 基幹システ ム 
3,000万円(ERP 年間ラ ンニングコスト) 
年間保守料(ライセンス 込)1,000万円 
66%削減
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
保守効率の向上実績(例2) 
45 
ツールD 
企業 
削減率 
O社 
更新負荷66%減少 
P社 
運用負荷70%削減 
Q社 
ECサイトへの出店を30日から2日へ 
ツールC 
アプリケーション 
導入前 
導入後 
削減率 
L社 基幹システ ム 
年間保守料金 
2,520万円 
年間保守料金 
336万円 
85%削減 
以下はお客様の評価
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
生産性が向上すると市場は小さくなるのか? 
他の業界では、生産性を向上させることを業務改善の常態と して行っている 
生産性の向上は市場規模の拡大と利益向上につながってい る 
生産性を上げても市場が大きくならないのは、そもそも商品 やサービスに欠陥があるから 
IT業界で、生産性の向上に熱心でないのは、システ ム開発サービスという商品にそもそも価値がない(と 経営者が深層では考えている)ということの証拠 
技術者の数で売り上げ規模が決定されるビジネスモデルを採用するかぎ り、市場は大きくならない(人口減少は確実なので) 
46
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
8,442 
4,595 
労働集約型産業の行く末(人口の減少) 
50年で売り上げ ▼45%(10年ごとに 約1割減少) 
47
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発ツールを活用すると、 市場は縮小するどころか大きくなる! 
Gartner Seminar in Sydney 2011 をもとに作成 
構造化された定型 業務 
人の仕事の80%は、構造化されない作業 
膨大なIT化市場! 
(超高速開発ツール がないとシステム化 が不可能) 
構造化されていない 
さまざまな情報が飛び 交っている世界 
48
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
評価項目 
WFモデル 
xRAD超高速開発 
ハイブリッド・アジャイル 
生産性 
×:ドキュメント作成工数が 大 
◎:設計情報がリポジトリーで管理されるので、 ドキュメントが減少 
△:ドキュメント削減効果が低い 
品質 
○:テスト工程で確実に検証 
◎:設計情報の整合性が担保される 
○:テスト工程で確実に検証 
リリース 
×:全工程が終了する迄 
◎:一部機能のリリースも可能、追加開発が容 易 
X:基本的には全工程終了時とな る 
スコープ管理 
○:上流工程で確定 
○:設計の不整合がわかるので機能漏れの発 見が容易 
△:上流工程で一度確定し、変更 分は随時調整 
変更要望への 対応 
×:設計工程迄の手戻りが 発生 
◎:変更影響範囲が明確になるので対応が容 易 
○:基本設計迄戻るもの以外はソ フトウエアの修正のみ 
仕様誤確認の 早期発見 
×:業務側の確認テスト時 
◎:画面についてはその場で実用モデルを作成 するので、漏れは減少 
○:事前に確認、かつイテレーショ ンごとに業務側の確認実施 
大規模開発 
○:複数チーム構成がやりや すい 
△:大人数プロジェクトには向いていない。小規 模から発展させることは可能 
○:1チーム10名程度までの複数 チーム構成 
分散開発 
○:ドキュメントでの仕様伝 達 
○:分散開発が容易、設計情報は集中管理可 能 
○:必要なドキュメントは作成。分 散開発環境の導入可能 
保守(引き継 ぎ) 
○:保守用ドキュメントが残さ れ、引き継ぎ可能 
◎:リポジトリーに全情報が保持されているので、 保守しやすい 
○:保守用ドキュメントが残され、 引き継ぎ可能 
管理 
○:工程ごとに報告と承認 
◎:工程ごとに報告と承認。進捗情報、品質情 報がシステムにより把握されている 
○:工程ごとに報告と承認 
ITベンダーとの 契約 
○:特に無理な契約方法は ない 
○:変更対応が容易なので、スコープ変更や追 加要件に対して契約上の問題が発生しにくい 
△:請負契約には、変更量の調整 が必要 
参考資料: WFモデルとハイブリッド・アジャイルは、「ハイブリッドアジャイルの実践」 リックテレコム社 英 繁雄 他著 ISBN978-4-8979-7935-9 を参照。 xRAD超高速開発は、JUAS様と作成。 
プロジェクトマネジメントの観点からの比較 
49
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発ツールが与える影響 
【ユーザー企業】 
ユーザー主体開発(もしくは内製化)へのシフトを加速 
運用と保守もユーザー企業が主体的に行う方向へ 
自社の業務システムは資産継承しながら独自化に向かう 
情報システム部門の動き方で、各社収益性に差が出る 
OS,DBの変更によるシステム開発は減少 
【ITコンサルタント、ITC】 
技術の幅を広げられる(自らやって見せることができる) 
中小企業の業務のIT化推進に直接的に貢献(ToBeの姿を見せることが できる) 
【ITベンダー】 
下流工程(プログラミング、テスト工程)の発注が激減 
ユーザー企業から直接受注するITベンダーが増加 
業務の分析とモデリング・スキルが重要になる 
オフショア開発への発注が減少(ユーザー企業のスピード変更重視) 
クラウドで提供することが増加(システムを迅速に変更できる) 
見積方法 人月工数見積から価値見積へ移行 
50
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“IT経営プロセス”における超高速開発ツールの適用分野 
出典:ITコーディネータ(ITC) プロセスガイドライン Ver 2.0 
51 
超高速 
開発の 
考え方 
を適用 
すること 
ができ 
る分野
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
P.ドラッカー 「ネクスト・ソサエティ」 
こうして、われわれの眼前に膨大な仕事が 横たわっている。第一に、情報に通暁しなけ ればならない。そのためには、一人ひとりが 情報リテラシーを習得する必要がある。... 情報を仕事の道具として見なければならな い。...第二に、外部で起こっていることを 理解するために、その情報リテラシーを実際 に使わなければならない。 
2002年出版 (上田惇生 訳) 
不可欠の情報リテラシー 
52
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
組織活動は情報システムである 
•情報管理(Information Management)の重要性は、 1970年代から語られている 
•理論にいたっては、1950年代まで遡ることができ る 
–組織は高度な情報処理と様々なレベルでの意思決定の 必要性の協調システムである(H.サイモン:1958) 
•政府や自治体の組織の活動において、今後ますま す情報の活用とその管理が重要になる。(全省庁・ 自治体職員が情報とそれを扱う仕組み[情報システ ム]に精通することが必要になる。将来の課題。) 
53
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
“現行システムをどのように 新世界に移行するのか?” ☆リバースツールRESCUEのご紹介 
54 
•RESCUEは、株式会社ソフトウェア・ジェネレーション社の商標です。 
•引き続く7枚は株式会社ソフトウェア・ジェネレーション社の了解のもとに、ご紹介します。
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
COBOL資産のマイグレーション(新リポジトリ構築) 
55 
リポジトリ 
xRADツール 
リポジトリ生 成
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
データ項目単位でのプログラム間のトレース機能 
56
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
仕様書生成機能一覧 
57
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
まとめ 
58
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その1 - 
ツールの特質の理解 
ツールへのインプット情報が何かを理解する 
インプットを作成するための作業は何か(ビジネス・プロセス/ワークフロー 作成、データ項目定義、ビジネス・ルールの識別など)を理解する(DOAをコ ンセプトとしているツールが多い) 
ツールの最終成果物が何かを理解する 
複数のツールの組み合わせが現実的(ビジネス・ロジック、UI、情報分析、 バッチ、テスト、スマホ・タブレットアプリなど) 
リポジトリが管理しない要求事項・仕様は別の管理が必要 
最初の要求事項(改善案・懸案事項の解決方針など) 
性能、信頼性、可用性、障害対策などの非機能要件 
ツールが対応する場合もある(セキュリティ機能、OSの違いなど) 
プロトタイプ作成 
業務での活用場面をイメージできるプロトタイプの作成は必ず行う 
UIは、言葉で伝えるのではなく作って評価する 
59
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その2 - 
発注者のオーナーシップの確立 
最終的なQCD+S(Scope)の責任をベンダに任せない 
Scopeを調整する権限を持つ責任者が参加すること(法律の規定と直接関 係しない画面や帳票の仕様の取捨選択) 
運用テストケースの作成と検証は発注者の責任 
Web系システムは、小さくはじめて徐々に機能追加をするのが望ましい 
リポジトリのクロスリファレンンス機能を自ら使う(品質・進捗の客観的判断 の助けになる。ベンダの報告の検証ができる。) 
業務運用の仕組み(業務フロー、例外処理、人の作業など)を明確にする のは発注者の責任 
ベンダとの契約モデルの見直し 
アジャイル型で行う場合の契約形態は注意が必要 
多重下請けの禁止(機密保持契約の問題があり、One Teamにならない) 
多段階契約は困難(工程を区切るのは不可能) 
60
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発ツールの活用準備(再構築に向けて) 
“怖くて手をつけられない”基幹システムを抱えてい る企業は多い 
現行の大規模基幹システムの仕様の把握は困難 
ERPに手をいれ改修に困っている企業もある 
稼働後、短期間で再構築を繰り返している 
3-5年の間に基幹システムの再構築の波が来る 
そのとき、相変わらず“大量の要員”による開発がで きるとは考えられない 
今から、少しずつ超高速開発ツールを調査・テスト 利用すべき 
61
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
経営活動にはどちらを使いたいですか? 
どちらに多くのお金を払っていますか? 
62
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
参考 
63
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発コミュニティ ( http://www.x-rad.jp/ ) 
企業のスピード経営の実現 
魅力あふれるIT業界への変革 
64 
2013/8/6 発足 
•記者会見を実施。報道関係各社ご出席。 
理念
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 目指すところ 
企業のスピード経営の実現 
–開発や保守にかかる工数を削減し、期間を短縮する。 
–ユーザー主体開発の実現 
魅力あふれるIT業界への変革 
–超高速開発の実践をとおして「顧客指向、高付加価値、 高給与」を実現する。 
65
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ミッション 
•超高速開発(考え方、手法、ツール)の認 知度の向上 
•超高速開発の適切な活用方法と効果の 啓蒙 
•技術者への実践的活用ノウハウの共有 
66
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発コミュニティ 会員数 (2014.10.7 現在) 
 正会員 
•ユーザー企業 52社 
•ツールベンダー、システム開発会社 28社 
 準会員 
•法人企業 37社 
•個人 48名 
合計 165名 
(メルマガ会員数 約1,200名) 
67
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
活動内容と外部連携支援 
超高速開発というテーマについての啓蒙活動 
–メールマガジン発行(2回/月) 
–コミュニティ主催セミナー/ワークショップ開催(毎月) 
–他団体との連携 
•東京商工会議所 
•一般社団法人 ICT経営パートナーズ協会 
•NPO法人 システムイニシアティブ協会 など 
–外部イベント、セミナーへの参加・出展 
•地域のITコーディネータ主催団体(千葉、埼玉、多摩、東京イースト) 
•ITMS (ITマネジメント・サポート協同組合), (公財)全国中小企業取引振興協会 
•京都ASTEM(公益財団法人 京都高度技術研究所) [京都市からの紹介] 
•一般社団法人 ガバナンスアーキテクト機構セミナー 
•城南信用金庫フェア 
【超高速開発】に賛同・関心をいただいている団体 
•METI、内閣府CIO補佐官、IPA、JISA、JUAS、ITCAなど多数(これらの団体の方々には、 各種セミナーに出席いただいています) 
会員同士の自主的な情報交換のための分科会 
68
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発コミュニティに参加しているツール・ベンダーとツール 
(as of 2014.10.31 ) 
69 
会社名 
ツール名 
株式会社アイエルアイ総合研究所 
STiLL-X (スティル) 
株式会社アトリス 
PEXA Suite 
株式会社インテリジェント・モデル 
ODIP(オーディップ) 
インフォテリア株式会社 
ASTERIA WARP 
株式会社ウイング 
GeneXus 
株式会社エス・エー・エフ・データ 
SAF Product 
株式会社SCSK 
FastAPP 
キヤノンソフトウェア株式会社 
Web Performer 
株式会社KMK WORLD 
A’s Style(アズスタイ ル) 
株式会社コアネクスト 
GeneXus 
株式会社コラボスタイル 
コラボフロー 
株式会社JBCC(旧ケン・システムコン サルティング株式会社) 
Xupper II, MDFrame/X 
サピエンス・ジャパン株式会社 
Sapiens eMerge 
会社名 
ツール名 
株式会社JIEC 
CA-Gen 
株式会社ジェーエムエーシステム ズ 
GeneXus,Wagby,seap 
株式会社ジェナ 
seap(シープ) 
株式会社ジャスミンソフト 
Wagby 
スマーテックワークス株式会社 
SWAT 
株式会社パルシス 
Wagby 
パワードプロセスコンサルティング 株式会社 
Metasonic Suite 
株式会社ファルコン 
TALON 
株式会社フロンテス 
STAR-ATT, STAR-Lite 
株式会社bluememe 
OutSystems Platform 
マジックソフトウェア・ジャパン株式 会社 
Magic xpa, Magic xpi 
有限会社ユニバーサル・シェル・プ ログラミング研究所 
ユニケージ(R)開発手 法
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
超高速開発コミュニティに参加している ツールベンダーのツールの種類 
1.コード生成 
GeneXus, Web Performer, MDFrame/X, Wagby, OutSystemsPlatform, CA- Gen, SAF Product 
2.実行エンジン 
PEXA, A’s Style, Sapiens, TALON, Magic xpa, FASTApp 
3.バッチ実行エンジン 
ODIP 
4.ワークフロー作成と実行エンジン 
コラボフロー, Metasonic Suite 
5.Excelアドイン・アプリケーション作成 
STiLL 
6.ビジネス・プロセス作成・管理 
Xupper II 
7.アプリケーション統合・データ連携(EAI) 
ASTERIA WARP, Magic xpi 
8.テスト自動実行 
STAR-ATT, STAR-Lite, SWAT 
9.タブレット・アプリ作成 
seap 
10.シェル・プログラミング・ツールと手法 
ユニケージ(R)開発手法 
注意: ここに示した分類は、例にすぎません。ツール・ベンダー各社が承認したものではありませんのでご注意ください。 
(as of 2014.10.31 ) 
下線付きは 
リポジトリを持つ タイプ 
70
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
ツール選定で重視すること 
機能の豊富さ, 4 
機能の拡張性, 2 
開発の自由度, 3 
ツールの品質, 8 
開発と保守の 
生産性, 14 
習得の容易性 , 7 
価格, 9 
開発規模との 
適合性, 4 
導入実績, 4 
ブランド、0 
サポート力, 1 
自社のスキル・カバ レッジ, 2 
その他, 1 
2014.1.7のQCD研究会での、超高速開発に関する説明に対するアンケート結果(2014.3.4に依頼したもの)サマリー 
71
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
導入先の業種と企業規模 
35.1 
19.7 
8.0 
3.4 
23.4 
1.1 
4.3 
4.9 
製造 
流通 
金融 
通信 
サービス 
建設 
公共・公益 
その他 
※ 2013/11月時点の12ツールの累計導入社のうち判別できた事例 5,723社より 
9% 
17% 
16% 
23% 
28% 
7% 
100人以下 
100人から300人以下 
300人から1000人以下 
1000人から3000人以下 
3000人以上 
不明 
72
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
インソーシング(内製)利用状況 
※ 2013/11月時点の6ツールの累計導入社のうち判別できた事例 1,916社より 
34.0 
11.0 
55.0 
ユーザ主体開発 
ユーザ主体、一部SIer参画 
SIer主体開発 
73
Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 
終わり 
74

Mais conteúdo relacionado

Mais procurados

ビジネスに貢献するIT部門への変革に必要な3つのポイント
ビジネスに貢献するIT部門への変革に必要な3つのポイントビジネスに貢献するIT部門への変革に必要な3つのポイント
ビジネスに貢献するIT部門への変革に必要な3つのポイントUNIRITA Incorporated
 
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...Trainocate Japan, Ltd.
 
IT部門がビジネスに貢献するためのメソドロジー
IT部門がビジネスに貢献するためのメソドロジーIT部門がビジネスに貢献するためのメソドロジー
IT部門がビジネスに貢献するためのメソドロジーUNIRITA Incorporated
 
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ - 日本情報システム・ユーザ...
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ -  日本情報システム・ユーザ...[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ -  日本情報システム・ユーザ...
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ - 日本情報システム・ユーザ...Trainocate Japan, Ltd.
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかYusuke Suzuki
 
ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ESM SEC
 
【A-1】すべてがつながるIoT時代の共創のあり方
【A-1】すべてがつながるIoT時代の共創のあり方【A-1】すべてがつながるIoT時代の共創のあり方
【A-1】すべてがつながるIoT時代の共創のあり方Developers Summit
 
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~Developers Summit
 
Why Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARCWhy Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARCKenji Hiranabe
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とはStudyTech
 
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudyリーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy満徳 関
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
ユーザ事例から見るITサービスマネジメントツールの活用効果
ユーザ事例から見るITサービスマネジメントツールの活用効果ユーザ事例から見るITサービスマネジメントツールの活用効果
ユーザ事例から見るITサービスマネジメントツールの活用効果UNIRITA Incorporated
 
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方Yusuke Suzuki
 
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」Keiichiro Seida
 
XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」 XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」 Yusuke Suzuki
 
IT関連コストの最適化コンサルティング・サービス
IT関連コストの最適化コンサルティング・サービスIT関連コストの最適化コンサルティング・サービス
IT関連コストの最適化コンサルティング・サービスsinrock
 
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.120160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1it-innovation
 

Mais procurados (20)

ビジネスに貢献するIT部門への変革に必要な3つのポイント
ビジネスに貢献するIT部門への変革に必要な3つのポイントビジネスに貢献するIT部門への変革に必要な3つのポイント
ビジネスに貢献するIT部門への変革に必要な3つのポイント
 
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...
[G-Tech2015]攻めのIT経営銘柄に選ばれたアサヒグループホールディングス様の基幹刷新への取り組み ~MCFrameによる基幹システム刷新事例 F...
 
IT部門がビジネスに貢献するためのメソドロジー
IT部門がビジネスに貢献するためのメソドロジーIT部門がビジネスに貢献するためのメソドロジー
IT部門がビジネスに貢献するためのメソドロジー
 
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ - 日本情報システム・ユーザ...
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ -  日本情報システム・ユーザ...[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ -  日本情報システム・ユーザ...
[G-Tech2015]攻めのITとは、それを実現する人材とは ~IT関係者は期待されている!そして期待に応えるために!~ - 日本情報システム・ユーザ...
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
 
ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用
 
【A-1】すべてがつながるIoT時代の共創のあり方
【A-1】すべてがつながるIoT時代の共創のあり方【A-1】すべてがつながるIoT時代の共創のあり方
【A-1】すべてがつながるIoT時代の共創のあり方
 
事業に貢献するIT~ITサービスマネジメントとITIL(r)
事業に貢献するIT~ITサービスマネジメントとITIL(r)事業に貢献するIT~ITサービスマネジメントとITIL(r)
事業に貢献するIT~ITサービスマネジメントとITIL(r)
 
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
 
Why Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARCWhy Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARC
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とは
 
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudyリーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
ユーザ事例から見るITサービスマネジメントツールの活用効果
ユーザ事例から見るITサービスマネジメントツールの活用効果ユーザ事例から見るITサービスマネジメントツールの活用効果
ユーザ事例から見るITサービスマネジメントツールの活用効果
 
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
 
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
 
Agile overview
Agile overviewAgile overview
Agile overview
 
XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」 XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」
 
IT関連コストの最適化コンサルティング・サービス
IT関連コストの最適化コンサルティング・サービスIT関連コストの最適化コンサルティング・サービス
IT関連コストの最適化コンサルティング・サービス
 
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.120160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
 

Semelhante a Base 20141011 1_for_slideshre

第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料Tae Yoshida
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織Recruit Technologies
 
Introduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentIntroduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentKent Ishizawa
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)伸夫 森本
 
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」PC Cluster Consortium
 
企画開発運用部門の協調とは
企画開発運用部門の協調とは企画開発運用部門の協調とは
企画開発運用部門の協調とはUNIRITA Incorporated
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立についてMasahiko Ebisuda
 
ITIL準拠のツールでアジャイルな変革を実現
ITIL準拠のツールでアジャイルな変革を実現ITIL準拠のツールでアジャイルな変革を実現
ITIL準拠のツールでアジャイルな変革を実現UNIRITA Incorporated
 
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリングMasanori Kaneko
 
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?IMJ Corporation
 
アクセス解析サミット2011「データドリブンなチームを目指せ」
アクセス解析サミット2011「データドリブンなチームを目指せ」アクセス解析サミット2011「データドリブンなチームを目指せ」
アクセス解析サミット2011「データドリブンなチームを目指せ」Makoto Shimizu
 
IT業界理解お助け資料V2.0
IT業界理解お助け資料V2.0IT業界理解お助け資料V2.0
IT業界理解お助け資料V2.0Jun Chiba
 
第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料Tae Yoshida
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」Cybozucommunity
 
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜Takashi Takebayashi
 
OutSystems ユーザー会 セッション資料
OutSystems ユーザー会 セッション資料OutSystems ユーザー会 セッション資料
OutSystems ユーザー会 セッション資料Tsuyoshi Kawarasaki
 
リクルートにおけるPaaS活用事例
リクルートにおけるPaaS活用事例リクルートにおけるPaaS活用事例
リクルートにおけるPaaS活用事例Recruit Technologies
 
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?Takashi Takebayashi
 
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan Yusuke Suzuki
 

Semelhante a Base 20141011 1_for_slideshre (20)

第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
 
Introduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentIntroduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement Development
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)
 
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」
PCCC21:株式会社日立製作所 「研究開発力向上のための研究DXソリューション」
 
企画開発運用部門の協調とは
企画開発運用部門の協調とは企画開発運用部門の協調とは
企画開発運用部門の協調とは
 
ndsと要求開発
ndsと要求開発ndsと要求開発
ndsと要求開発
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について
 
ITIL準拠のツールでアジャイルな変革を実現
ITIL準拠のツールでアジャイルな変革を実現ITIL準拠のツールでアジャイルな変革を実現
ITIL準拠のツールでアジャイルな変革を実現
 
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
 
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?
【IMJ】失敗するデジタルマーケティング戦略、その原因&成功のカギとは?
 
アクセス解析サミット2011「データドリブンなチームを目指せ」
アクセス解析サミット2011「データドリブンなチームを目指せ」アクセス解析サミット2011「データドリブンなチームを目指せ」
アクセス解析サミット2011「データドリブンなチームを目指せ」
 
IT業界理解お助け資料V2.0
IT業界理解お助け資料V2.0IT業界理解お助け資料V2.0
IT業界理解お助け資料V2.0
 
第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
 
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜
プロセスの過去から未来への物語 〜イマドキのチーム開発を支えるプロセスとは?〜
 
OutSystems ユーザー会 セッション資料
OutSystems ユーザー会 セッション資料OutSystems ユーザー会 セッション資料
OutSystems ユーザー会 セッション資料
 
リクルートにおけるPaaS活用事例
リクルートにおけるPaaS活用事例リクルートにおけるPaaS活用事例
リクルートにおけるPaaS活用事例
 
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?
第25回 #TFSUG ノウハウお伝えします! 鉄人から学ぶ TFS セミナー編 - イマドキのチーム開発を支えるプロセスとは?
 
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
 

Último

HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用
HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用
HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用wataruhonda3
 
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパンYusuke Katsuma
 
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。takuyamatsumoto29
 
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介していますchizurumurakami
 
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profilevrihomepage
 
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------ssusercbaf23
 
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdfjun_suto
 
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続Yusuke Katsuma
 
ROMS_recruting_deck_for_website_20240322.pdf
ROMS_recruting_deck_for_website_20240322.pdfROMS_recruting_deck_for_website_20240322.pdf
ROMS_recruting_deck_for_website_20240322.pdfhirokisawa3
 
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』Kousuke Kuzuoka
 
chouhou_obuse_reiwa6nenn_4_2404slide.pdf
chouhou_obuse_reiwa6nenn_4_2404slide.pdfchouhou_obuse_reiwa6nenn_4_2404slide.pdf
chouhou_obuse_reiwa6nenn_4_2404slide.pdfssuser31dbd1
 

Último (12)

Japan IT Week 2024 Brochure by 47Billion
Japan IT Week 2024 Brochure by 47BillionJapan IT Week 2024 Brochure by 47Billion
Japan IT Week 2024 Brochure by 47Billion
 
HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用
HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用
HRMOS(ハーモス)タレントマネジメント_ご紹介資料_Saleshub掲載用
 
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン
第15回販促コンペ 審査員個人賞(林 知幸 氏) アルカナ? アディダスジャパン
 
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。
株式会社AllAdsと申します。サービス紹介資料で御座いますので、是非ご覧くださいませ。
 
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています
株式会社フィジオ会社説明資料|採用の際の福利厚生やカルチャーなどを紹介しています
 
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile
株式会社ベクトル総研会社概要 Vector Research Institute (VRI) Corporate Profile
 
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------
HCCソフト株式会社 2025年新卒採用向け 会社紹介・採用情報資料------
 
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf
令和5年度_サステナブルツーリズムセミナー_ビジュアルレポート(公開用).pdf
 
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続
JAPAN WEB3.0 AWARD 2023 ブロックチェーン(NFT)技術を活用したアイディア 優秀賞作品 遺3.0相続
 
ROMS_recruting_deck_for_website_20240322.pdf
ROMS_recruting_deck_for_website_20240322.pdfROMS_recruting_deck_for_website_20240322.pdf
ROMS_recruting_deck_for_website_20240322.pdf
 
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』
エンジニア採用のミスマッチを防ぐコーディング試験サービス『HireRoo(ハイヤールー)』
 
chouhou_obuse_reiwa6nenn_4_2404slide.pdf
chouhou_obuse_reiwa6nenn_4_2404slide.pdfchouhou_obuse_reiwa6nenn_4_2404slide.pdf
chouhou_obuse_reiwa6nenn_4_2404slide.pdf
 

Base 20141011 1_for_slideshre

  • 1. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 今なぜ超高速開発なのか? - What、Why および ビジネス上の価値、効果 - 一般社団法人 ICT経営パートナーズ協会 超高速開発コミュニティ 大島 正善(MBC) 2014年10月 1
  • 2. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 内容 1.背景 2.現状の基幹業務システムの課題 3.あるべき姿 4.超高速開発とは何か、そして、その狙いは? 5.超高速開発ツールを使うとシステム開発は どう変わる? 6.まとめ 7.参考資料 2
  • 3. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 情報システム(IS)にまつわる長年の課題 労働集約的な開発のやり方から脱却できない 他の産業と異なり、自動化を推進し品質と生産性を高めよう という意識が欠如している 一般の製品のように、長く使い続けることができず数年する と陳腐化し、再構築せざるを得ない(ライフサイクルコストが 低下しない) ベテランは年々減っており、業務ノウハウとシステムの全体 像を理解している技術者が少なくなってしまった(中堅企業・ 大企業では、業務システムを最初から構築することは、この 20年程度行われていない) 保守コストは70%-80%を占める状況が続いている(新規投 資ができない) 3
  • 4. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 出典:経済産業省「次世代高度IT人材の人材像と能力」(H24.4.26)をもとに作成 超高速開発の 真の狙い(2つ) ① ② 4
  • 5. Copyright ©2014 MBC (Method Based Consulting) IPA: 「IT人材白書2014」概要 (2014.4) All Rights Reserved. 5
  • 6. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 価値を創る 事業に生かす IPA: 「IT人材白書2014」概要 (2014.4) 6
  • 7. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 7 根っこにある問題意識 現状の情報システムは『ビジネ ス環境の変化に迅速に対応でき ているか?』 情報システムを活用する“ユー ザー企業”からの視点
  • 8. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネスと情報システムとの間の”GAP” 理念/目標/戦略/方針 ビジネス・モデル (プロセス/組織…) 情報システムモデル (アプリ/システム構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデル ビジ ネス 領域 情報 シス テム (IS) 領域 分断されて いる 8
  • 9. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現在の基幹業務システムの状況(その1) •経営環境の変化に迅速に対応できない •情報システム部門の中に、業務の仕組みと情報シ ステムの仕組みや仕様を理解している要員が減っ てしまった •バックログが減らない •怖くて手をつけられない •些細な変更もベンダに確認しないとできない •アプリケーション・システムが個別に開発され、重 複するデータが関連なく保持されてしまい、活用が 困難となっている •莫大な費用が請求されるERPのバージョンアップ 9
  • 10. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現在の基幹業務システムの状況(その2) ソフトウェアの設計仕様は、ソースコード を見なければわからない それは、業務の仕組み(判断基準と実 行すべき行動)のことを理解している人 がいないことを意味する 10 この状況は、組織にとって解決すべき、 かなり優先度の高い課題ではないか?
  • 11. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 現状のシステム開発の姿(伝言ゲーム) 内部設計書 (処理機能記述、 ファイル・レイアウ ト、定義書、 システム概要書 (システム概要、ER図、 共通機能、入出力等) 共通部品の変更 が適切に反映さ れていない PM / リーダー 契約マスターの変更が他 の成果物に反映されてい ないと聞いているが、他 の変更は大丈夫なんだろ うか? 現行プログラムの仕 様の一部が内部仕 様化されないことに なっても気がつかな い。 共通部品を早く決め る必要があることは 分かっているが、共 通基盤のAPIも変更 が頻発するし、部品の 単位だって変える必 要があるし、簡単に は決まらないさ 事務設計書 の記載とシス テム・フローに 不整合がある な... プログラム仕様 書 共通部品 契約マスター 定義書 外部設計書 (システム・フロー/ 機能構造定義/ 部品仕様/ファイル 仕様など)) 事務設計書 (業務フロー、業務仕 様記述書、画面イ メージ、帳票イメージ 等) 業務分析担当 レビュアー レビュアー PM アプリ設計担当 DB設計担当 部品設計担当 開発担当 開発担当 不整合 11
  • 12. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. イノベーションが求められている 企業や行政組織の情報システムの役割は拡大しており、ビジ ネス上あるいは法律や施策、さらには、社会ニーズを迅速に 情報システムに反映することが求められている 現状の情報システムは、構造そのものが変化に対応できない ものになっている(構造不良を起こしている) 一部の組織を除いて、情報システムの設計から実装に関わる ことができる人材が不足しており、ギャップを埋める必要があ る システム開発という作業を個人のスキルに依存せず管理可能 な状態にしていくことが求められている ビジネスや社会の変化に合わせて、ソフトウェアの継続的改善 を可能にする必要がある 12
  • 13. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 13
  • 14. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “あるべき姿”は? 14
  • 15. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネスと情報システムが一体化 理念/目標/戦略/方針 ビジネス・モデル (プロセス/組織…) 情報システムモデル (アプリ/システム構造…) テクノロジーモデル (適用技術/製品選択) 詳細モデル ビジ ネス 領域 情報 シス テム (IS) 領域 15 ビジネス・モデルの 要素 情報システム・ モデルの要素 連携:トレースできる 何ができればよいのか?
  • 16. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ビジネス活動の主要要素 顧客 サプライチェーン 扱う商品やサービス ビジネス・プロセス 業務機能 ビジネス・ルール(判断とその結 果の行動あるいは活動の基準) 情報 組織・役割・責任 営業所、支店、拠点、工場などの 場所 ITの仕組み(Web、クラウド、スマ ホ、ネットワーク) 企業理念・目標・戦略・収益・利 益・社会貢献 顧客 商流 販売するモノ(製・商品) ビジネス・プロセス 業務機能 ビジネス・ルール 情報 組織 配置 (ビジネス)コンテキスト 16
  • 17. 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 ○ ○ 戦略もチャネルもさらに詳細化する 17 多次元ワールド。 人が管理できる限界 を超えている!
  • 18. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 事業 ビジネス・ プロセス ビジネス・ プロセス 事業 事業 データ項目 ビジネス・ プロセス 情報 事業 ビジネス・ プロセス 組織 拠点 データ項目 ビジネス・ ルール ビジネス・ ルール 業務機能 目標 目標 戦略 ビジネス・モデルの要素間の関連の全体図の例 18
  • 19. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. システムの構成要素間の関係 情報 データ 項目 システム 機能 システム 機能 レベル2 機能 レベル2 機能 システム機 能 製品 非機能 要件 非機能 要件 レベル4 機能 DB DB 画面 帳票 JOB アプリ機能 製品・基盤機能 DB 画面 帳票 JOB プログラム ソフトウェ アの構造 非機能要件 エンティティとデータ項目 エンティティ 業務プロセス 業務プロセス ・業務機能 システム機能 (レベル1) システム機能 (レベルn) システム機能 基盤要件 製品 基盤機能・製品 DB データ項目 19 システムの世界も 多次元ワールド。 人が管理できる限界 を超えている!
  • 20. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. リポジトリとは? 1.ビジネス・モデルの構成要素間の関 連を保持する 2.ソフトウェア・モデルの構成要素間の 関連を保持する 3.ビジネス・モデルとソフトウェア・モデ ルの関係を保持する 20 “ビジネス活動全体の部品表”
  • 21. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. リポジトリの役割 (業務プロセス、 業務ルール、 データ項目、 画面、帳票等) 21 業務プロセスが変わる 仕事のやり方が変わる 判断基準が変わる 管理するデータが追加される 情報の管理単位が変わる 画面が追加される 帳票が追加される 変更は自動的に すべての要素(ビジネス およびシステムの両方) に反映される! 整合性が担保される リポジトリ プロセスの順序A⇒B ルールX ⇒ Y データ項目c⇒d1&d2 画面u1,u2追加 業務フロー、 システム機能、 画面、帳票、 DB など 多くの超高速開発ツールはリポジトリを持ち、重要な役割はリポ ジトリに保管される情報の維持管理である!!
  • 22. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. リポジトリを使ったシステム開発の姿 リポジトリ (部品表) 詳細仕様 業務フロー データモデル /データ項目 定義 運用テスト・シナ リオ 詳細仕様 システム・テスト・ シナリオ 統合テスト シナリオ ルール記述 画面/帳票/ インターフェー ス仕様 トラン仕様/ バッチ仕様 テスト担当2 設計担当1 ITベンダ テスト担当1 設計担当2 設計担当3 設計担当4 業務分析担当 整合性が保証される 22
  • 23. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発とそのツールが可能にすること  情報システムの変化への対応力強化  情報システム構築のハードルを下げる (業務担当 者ができるようになる) 情報システム 開発の現場 業務部門 の現場 従来 超高速開発 現場のミドルが強い日本の 企業には最適な手段! 23
  • 24. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “超高速開発”とは? 24
  • 25. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発とは?(定義) △「プログラムを自動生成する開発ツールを用いた開 発のこと」 ◎業務のデザイン(1)から運用・保守工程をも含めたシ ステム・ライフサイクル全般にわたる生産性向上と 継続的品質改善を行うやり方 (1)業務要件をもとに、業務のあるべき姿を設計すること ◎「超高速」には、「期間短縮」、「工数削減」と「品質向 上による手戻り削減」の意味を含む •労働集約的な開発のやり方との比較 25
  • 26. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “超高速開発ツール”の特長 設計情報から実装コードを生成する、UIをすばやく開 発する だけではない ビジネス・プロセスなどの業務に関わる情報やシステ ム設計に関する情報をリポジトリーで管理している ⇒ 業務の可視化 ⇒ 設計の可視化 ⇒ 業務(設計)から実装までの追跡可能性の担保 ⇒ 変更の影響分析が可能 マルチプラットフォームに対応 26
  • 27. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “超高速開発ツール”のタイプ リポジトリー型 プログラム生成 中間言語生成+実行エンジン ビジネス・モデル管理、設計情報管理、テスト情報 管理 フレームワーク・パターン適合型 プログラム部品の組み合わせ 半製品、UI部品の組み合わせ 27
  • 28. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “従来の開発のやり方と 何が変わるのか?” そして どのような効果を生むのか? 28
  • 29. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 何が変わるのか(例) 1.品質の作りこみの実現 整合性の維持、トレーサビリティの確保 レビューでの確認ではなく、担当者自身が確認できる 2.プロジェクトの実態が見えるようになる 品質・進捗はリポジトリの状況から判断できる 問題の早期発見が可能になる 人の報告より“はるかに”信頼できる 3.柔軟性が求められる 個人技からチームでの作業になる 4.見積もりの基準が変わる WBSが変わる 工程モデルが変わる 工数配分比率、期間配分比率、要員投入比率が変わる 29
  • 30. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “超高速開発ツール”導入の効果 1.品質の作りこみの実現 2.高度な設計・開発スキル習得からの解放(特殊技能 者の開発から工業生産化へ) 3.要件追加・変更、機能拡張期間の大幅短縮の実現 4.開発・保守コストの大幅削減 5.テストでのバグ発生の大幅減少 6.ユーザー要件の意思決定スピードの改善 7.システムライフサイクルの長期化(TCOの削減) 8.投資効果がないと思われていた業務のシステム化の実現 9.業務分析・モデリング作業へのスキルのシフト(知識労働へ) 10.業務担当者が情報システムの構築に関与できるようになる( ビジネスとISが一体化している時代には大事) 30
  • 31. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ☆システム開発の工程モデル ☆製造業の製品開発の工程モデル 販売 製造 研究 開発 製造(改善・改良) 保守(業務での活用) 設計・ 開発 ・テスト 再構築 保守 不能 企画・ 要件 定義 製品開発工程モデルとシステム開発工程モデル 31
  • 32. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 保守 SLCPが暗黙的に持つ弊害 32 企画 シス テム・ テスト 統合 テスト 開発 内部 (詳細) 設計 要件 定義 運用 準備 外部 (基本) 設計 「開発された完成品の状態を保ち続けるの が保守」という認識 できるだけ多くの要件を入れ込みたくなる (ユーザ側) 要件の変更は、変更ではなく、追加に見える(作業としては、 まさに追加になる) 要件 完成!
  • 33. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. Maintenance(維持改善) これからは、保守(維持改善)こそが重要! 企 画 シ ス テ ム ・ テ ス ト 統 合 テ ス ト 開 発 内 部 ( 詳 細 ) 設 計 要 件 定 義 運 用 準 備 外 部 ( 基 本 ) 設 計 維持改善プロセス 企画プ ロセス 開発プ ロセス 運用 プロ セス 稼働後に、ビジネスの変化に合わせて低コストで容易にシ ステムを修正できることが求められている 現在のSLCPは、時代のニーズにそぐわなくなっている? パッケージ導入/ 手作りシステム 破綻 従来 33
  • 34. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発はアジャイル型とWF簡易型が可能 システム運用 第1反復 テス ト 開 発 要 求 第n反復 テス ト 開 発 要 求 ・・・ リリース ・・・ 第1反復 テス ト 開発 要 求 第n反復 テス ト 開発 要 求 ・・・ リリース ・・・ 第1反復 テス ト 開 発 要 求 第n反復 テス ト 開 発 要 求 ・・・ リリース 企画 ・・・ Ⅰ.アジャイル型 最初に10-20%程度の重要基本機能を開発しインクリメンタルに開発。 システム運用 2-3回程度のイ ンクリメンタル Ⅱ.WF簡易型 アーキテクチャはツールの仕様に任せる、あるいは、選択する ・設計主体 ・コーディングレス ・単体テストレス ・要求分析 ・アーキテクチャ選 択 企画 テス ト 開 発 要 求 保守 保守 保守 要求分析結果の 記述の整合性と統 一性の確保が容 易(定形化・パター ン化された記載と なるため) •機能変更・追加の 影響分析が可能 •使用変更をリポジト リーに登録する リポジトリーの活用 テス ト 開発 要 求 リリース テス ト ・設計主体 ・コーディングレス ・単体テストレス •使いながら常時 改善する 34 基幹・管理 業務系 Web・フ ロント系、 情報系 リポジトリーの活用(保有しないツールもある)
  • 35. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. アジャイル開発の得意分野と不得意分野 アジャイル開発の得意とする状況 クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性が なく、人命に関わらないシステム) 熟練した開発者が参加する場合 開発中に頻繁に要件が変わる場合 開発者が少ない場合 混沌とした状況に意欲をもって取り組む組織的文化 計画重視開発の得意とする状況 クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、 もしくは人命に関わるシステム) 経験の少ない開発者が多い場合 開発中に要件がほとんど変わらない場合 開発者が多い場合 秩序を重視する組織的文化 Wikipediaより Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. 2004. ISBN 0321186125 赤字の箇所が 課題 35
  • 36. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. アジャイル手法適用の条件 1チームは少人数である チームの数もそれほど大きくない(コミュニケ ーションとイメージの共有が可能な範囲) QCDS(Quality, Cost, Delivery, Scope)に対す る責任を持つ人が、実質のプロジェクト・オー ナーである ビジネス上の意思決定権限を持つ人が参加 する 長期的に安定したシステムを開発するのであ れば、リポジトリを持つツールを利用する 36
  • 37. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ユーザー主体開発を実現する超高速開発 企画、要求分析・モデリング、 アーキテクチャ設計 運用(業務での活用) 製造 研究 開発 保守(改善・改良) 設計の具象化、開発・テスト 継続的改善 ユーザー主体の DevOps を実現する “超高速開発” 37
  • 38. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 小さく始めて大きく育てる ~インクリメンタルな開発~ 38 ライフサイクル全期間にわたる継続的改善 優先順位の 高い機能を 最初に開発 ビジネスの変化に 合わせて機能を追 加・変更 継続的改善
  • 39. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. システム開発は日常業務へ! プロジェクト・タイプ の仕事(期間限定の 仕事) QCDをすべて等しく 重視 専門家がやるべき仕 事(しかし、資格は前 提でない) SIベンダーが開発 (QCD)の責任 39 日常業務になる QCD・S(Scope)の 中から優先順位を つけて開発を行う 組織人全員が関与 する 一部の専門性 (ノンコア・コンピテン シー)を外部に求め る 従来 今後
  • 40. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 人の役割は非定型業務へシフトし続ける 40
  • 41. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ウォーターフォール(WF)との生産性の比較 備考 JFS:JUAS Function Scale。画面数と帳票数から規模を換算した値。既存WFの データを基に画面数+帳票数×2/3 を算出(ユーザー発注者が明確に判るのは画 面数、帳票数である)。また、係数はグラフにプロットしたときの傾きを示す。xRADは 係数が小さいので、規模による生産性の変動が少ない。 ・費用・工数・工期ともに超高速開発はウォーターフォール法の3分の1である 備考: 表はJUAS様作成 41 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
  • 42. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 開発生産性向上実績(例1) アプリケーション 労働集約的方法に よる提案 xRAD実績 削減率 A社生産管理シ ステム 100人月 35人月 65%削減 B社基幹業務 300人月 167人月 45%削減 C社輸出入業務 185人月 45人月 75%削減 42 ツールA ツールB アプリケーション 労働集約的方法に よる提案 xRAD実績 削減率 D社法定帳票作 成システム 160人月 60人月 62%削減 E社 仕訳検証シ ステム 50人月 10人月 80%削減 F社 基幹システム 400人月 200人月 50%削減
  • 43. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 開発生産性向上実績(例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%削減 43 ツールC ツールE 企業 削減率 H社 連携フローの開発効率は2倍 I社 開発効率を30%向上 ツールD 以下はお客様の評価
  • 44. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 保守効率の向上実績(例1) アプリケーション 導入前 導入後 削減率 J社 年間外部支払料金 6,000万~8,000万 年間外部支払料金 100万 98% K社 4名(10システム) 4名(15システム以上) 同じ要員で追加 システム開発 44 ツールA ツールB アプリケーション 導入前 導入後 削減率 D社法定帳票作 成システム 1人/100人月 1人/50人月 (変更対応200件/年間) 50%削減 F社 基幹システ ム 3,000万円(ERP 年間ラ ンニングコスト) 年間保守料(ライセンス 込)1,000万円 66%削減
  • 45. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 保守効率の向上実績(例2) 45 ツールD 企業 削減率 O社 更新負荷66%減少 P社 運用負荷70%削減 Q社 ECサイトへの出店を30日から2日へ ツールC アプリケーション 導入前 導入後 削減率 L社 基幹システ ム 年間保守料金 2,520万円 年間保守料金 336万円 85%削減 以下はお客様の評価
  • 46. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 生産性が向上すると市場は小さくなるのか? 他の業界では、生産性を向上させることを業務改善の常態と して行っている 生産性の向上は市場規模の拡大と利益向上につながってい る 生産性を上げても市場が大きくならないのは、そもそも商品 やサービスに欠陥があるから IT業界で、生産性の向上に熱心でないのは、システ ム開発サービスという商品にそもそも価値がない(と 経営者が深層では考えている)ということの証拠 技術者の数で売り上げ規模が決定されるビジネスモデルを採用するかぎ り、市場は大きくならない(人口減少は確実なので) 46
  • 47. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 8,442 4,595 労働集約型産業の行く末(人口の減少) 50年で売り上げ ▼45%(10年ごとに 約1割減少) 47
  • 48. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールを活用すると、 市場は縮小するどころか大きくなる! Gartner Seminar in Sydney 2011 をもとに作成 構造化された定型 業務 人の仕事の80%は、構造化されない作業 膨大なIT化市場! (超高速開発ツール がないとシステム化 が不可能) 構造化されていない さまざまな情報が飛び 交っている世界 48
  • 49. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 評価項目 WFモデル xRAD超高速開発 ハイブリッド・アジャイル 生産性 ×:ドキュメント作成工数が 大 ◎:設計情報がリポジトリーで管理されるので、 ドキュメントが減少 △:ドキュメント削減効果が低い 品質 ○:テスト工程で確実に検証 ◎:設計情報の整合性が担保される ○:テスト工程で確実に検証 リリース ×:全工程が終了する迄 ◎:一部機能のリリースも可能、追加開発が容 易 X:基本的には全工程終了時とな る スコープ管理 ○:上流工程で確定 ○:設計の不整合がわかるので機能漏れの発 見が容易 △:上流工程で一度確定し、変更 分は随時調整 変更要望への 対応 ×:設計工程迄の手戻りが 発生 ◎:変更影響範囲が明確になるので対応が容 易 ○:基本設計迄戻るもの以外はソ フトウエアの修正のみ 仕様誤確認の 早期発見 ×:業務側の確認テスト時 ◎:画面についてはその場で実用モデルを作成 するので、漏れは減少 ○:事前に確認、かつイテレーショ ンごとに業務側の確認実施 大規模開発 ○:複数チーム構成がやりや すい △:大人数プロジェクトには向いていない。小規 模から発展させることは可能 ○:1チーム10名程度までの複数 チーム構成 分散開発 ○:ドキュメントでの仕様伝 達 ○:分散開発が容易、設計情報は集中管理可 能 ○:必要なドキュメントは作成。分 散開発環境の導入可能 保守(引き継 ぎ) ○:保守用ドキュメントが残さ れ、引き継ぎ可能 ◎:リポジトリーに全情報が保持されているので、 保守しやすい ○:保守用ドキュメントが残され、 引き継ぎ可能 管理 ○:工程ごとに報告と承認 ◎:工程ごとに報告と承認。進捗情報、品質情 報がシステムにより把握されている ○:工程ごとに報告と承認 ITベンダーとの 契約 ○:特に無理な契約方法は ない ○:変更対応が容易なので、スコープ変更や追 加要件に対して契約上の問題が発生しにくい △:請負契約には、変更量の調整 が必要 参考資料: WFモデルとハイブリッド・アジャイルは、「ハイブリッドアジャイルの実践」 リックテレコム社 英 繁雄 他著 ISBN978-4-8979-7935-9 を参照。 xRAD超高速開発は、JUAS様と作成。 プロジェクトマネジメントの観点からの比較 49
  • 50. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールが与える影響 【ユーザー企業】 ユーザー主体開発(もしくは内製化)へのシフトを加速 運用と保守もユーザー企業が主体的に行う方向へ 自社の業務システムは資産継承しながら独自化に向かう 情報システム部門の動き方で、各社収益性に差が出る OS,DBの変更によるシステム開発は減少 【ITコンサルタント、ITC】 技術の幅を広げられる(自らやって見せることができる) 中小企業の業務のIT化推進に直接的に貢献(ToBeの姿を見せることが できる) 【ITベンダー】 下流工程(プログラミング、テスト工程)の発注が激減 ユーザー企業から直接受注するITベンダーが増加 業務の分析とモデリング・スキルが重要になる オフショア開発への発注が減少(ユーザー企業のスピード変更重視) クラウドで提供することが増加(システムを迅速に変更できる) 見積方法 人月工数見積から価値見積へ移行 50
  • 51. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “IT経営プロセス”における超高速開発ツールの適用分野 出典:ITコーディネータ(ITC) プロセスガイドライン Ver 2.0 51 超高速 開発の 考え方 を適用 すること ができ る分野
  • 52. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. P.ドラッカー 「ネクスト・ソサエティ」 こうして、われわれの眼前に膨大な仕事が 横たわっている。第一に、情報に通暁しなけ ればならない。そのためには、一人ひとりが 情報リテラシーを習得する必要がある。... 情報を仕事の道具として見なければならな い。...第二に、外部で起こっていることを 理解するために、その情報リテラシーを実際 に使わなければならない。 2002年出版 (上田惇生 訳) 不可欠の情報リテラシー 52
  • 53. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 組織活動は情報システムである •情報管理(Information Management)の重要性は、 1970年代から語られている •理論にいたっては、1950年代まで遡ることができ る –組織は高度な情報処理と様々なレベルでの意思決定の 必要性の協調システムである(H.サイモン:1958) •政府や自治体の組織の活動において、今後ますま す情報の活用とその管理が重要になる。(全省庁・ 自治体職員が情報とそれを扱う仕組み[情報システ ム]に精通することが必要になる。将来の課題。) 53
  • 54. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. “現行システムをどのように 新世界に移行するのか?” ☆リバースツールRESCUEのご紹介 54 •RESCUEは、株式会社ソフトウェア・ジェネレーション社の商標です。 •引き続く7枚は株式会社ソフトウェア・ジェネレーション社の了解のもとに、ご紹介します。
  • 55. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. COBOL資産のマイグレーション(新リポジトリ構築) 55 リポジトリ xRADツール リポジトリ生 成
  • 56. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. データ項目単位でのプログラム間のトレース機能 56
  • 57. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 仕様書生成機能一覧 57
  • 58. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. まとめ 58
  • 59. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その1 - ツールの特質の理解 ツールへのインプット情報が何かを理解する インプットを作成するための作業は何か(ビジネス・プロセス/ワークフロー 作成、データ項目定義、ビジネス・ルールの識別など)を理解する(DOAをコ ンセプトとしているツールが多い) ツールの最終成果物が何かを理解する 複数のツールの組み合わせが現実的(ビジネス・ロジック、UI、情報分析、 バッチ、テスト、スマホ・タブレットアプリなど) リポジトリが管理しない要求事項・仕様は別の管理が必要 最初の要求事項(改善案・懸案事項の解決方針など) 性能、信頼性、可用性、障害対策などの非機能要件 ツールが対応する場合もある(セキュリティ機能、OSの違いなど) プロトタイプ作成 業務での活用場面をイメージできるプロトタイプの作成は必ず行う UIは、言葉で伝えるのではなく作って評価する 59
  • 60. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールの活用にあたって - 発注者に理解していただきたい点 その2 - 発注者のオーナーシップの確立 最終的なQCD+S(Scope)の責任をベンダに任せない Scopeを調整する権限を持つ責任者が参加すること(法律の規定と直接関 係しない画面や帳票の仕様の取捨選択) 運用テストケースの作成と検証は発注者の責任 Web系システムは、小さくはじめて徐々に機能追加をするのが望ましい リポジトリのクロスリファレンンス機能を自ら使う(品質・進捗の客観的判断 の助けになる。ベンダの報告の検証ができる。) 業務運用の仕組み(業務フロー、例外処理、人の作業など)を明確にする のは発注者の責任 ベンダとの契約モデルの見直し アジャイル型で行う場合の契約形態は注意が必要 多重下請けの禁止(機密保持契約の問題があり、One Teamにならない) 多段階契約は困難(工程を区切るのは不可能) 60
  • 61. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発ツールの活用準備(再構築に向けて) “怖くて手をつけられない”基幹システムを抱えてい る企業は多い 現行の大規模基幹システムの仕様の把握は困難 ERPに手をいれ改修に困っている企業もある 稼働後、短期間で再構築を繰り返している 3-5年の間に基幹システムの再構築の波が来る そのとき、相変わらず“大量の要員”による開発がで きるとは考えられない 今から、少しずつ超高速開発ツールを調査・テスト 利用すべき 61
  • 62. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 経営活動にはどちらを使いたいですか? どちらに多くのお金を払っていますか? 62
  • 63. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 参考 63
  • 64. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発コミュニティ ( http://www.x-rad.jp/ ) 企業のスピード経営の実現 魅力あふれるIT業界への変革 64 2013/8/6 発足 •記者会見を実施。報道関係各社ご出席。 理念
  • 65. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 目指すところ 企業のスピード経営の実現 –開発や保守にかかる工数を削減し、期間を短縮する。 –ユーザー主体開発の実現 魅力あふれるIT業界への変革 –超高速開発の実践をとおして「顧客指向、高付加価値、 高給与」を実現する。 65
  • 66. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ミッション •超高速開発(考え方、手法、ツール)の認 知度の向上 •超高速開発の適切な活用方法と効果の 啓蒙 •技術者への実践的活用ノウハウの共有 66
  • 67. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発コミュニティ 会員数 (2014.10.7 現在)  正会員 •ユーザー企業 52社 •ツールベンダー、システム開発会社 28社  準会員 •法人企業 37社 •個人 48名 合計 165名 (メルマガ会員数 約1,200名) 67
  • 68. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 活動内容と外部連携支援 超高速開発というテーマについての啓蒙活動 –メールマガジン発行(2回/月) –コミュニティ主催セミナー/ワークショップ開催(毎月) –他団体との連携 •東京商工会議所 •一般社団法人 ICT経営パートナーズ協会 •NPO法人 システムイニシアティブ協会 など –外部イベント、セミナーへの参加・出展 •地域のITコーディネータ主催団体(千葉、埼玉、多摩、東京イースト) •ITMS (ITマネジメント・サポート協同組合), (公財)全国中小企業取引振興協会 •京都ASTEM(公益財団法人 京都高度技術研究所) [京都市からの紹介] •一般社団法人 ガバナンスアーキテクト機構セミナー •城南信用金庫フェア 【超高速開発】に賛同・関心をいただいている団体 •METI、内閣府CIO補佐官、IPA、JISA、JUAS、ITCAなど多数(これらの団体の方々には、 各種セミナーに出席いただいています) 会員同士の自主的な情報交換のための分科会 68
  • 69. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発コミュニティに参加しているツール・ベンダーとツール (as of 2014.10.31 ) 69 会社名 ツール名 株式会社アイエルアイ総合研究所 STiLL-X (スティル) 株式会社アトリス PEXA Suite 株式会社インテリジェント・モデル ODIP(オーディップ) インフォテリア株式会社 ASTERIA WARP 株式会社ウイング GeneXus 株式会社エス・エー・エフ・データ SAF Product 株式会社SCSK FastAPP キヤノンソフトウェア株式会社 Web Performer 株式会社KMK WORLD A’s Style(アズスタイ ル) 株式会社コアネクスト GeneXus 株式会社コラボスタイル コラボフロー 株式会社JBCC(旧ケン・システムコン サルティング株式会社) Xupper II, MDFrame/X サピエンス・ジャパン株式会社 Sapiens eMerge 会社名 ツール名 株式会社JIEC CA-Gen 株式会社ジェーエムエーシステム ズ GeneXus,Wagby,seap 株式会社ジェナ seap(シープ) 株式会社ジャスミンソフト Wagby スマーテックワークス株式会社 SWAT 株式会社パルシス Wagby パワードプロセスコンサルティング 株式会社 Metasonic Suite 株式会社ファルコン TALON 株式会社フロンテス STAR-ATT, STAR-Lite 株式会社bluememe OutSystems Platform マジックソフトウェア・ジャパン株式 会社 Magic xpa, Magic xpi 有限会社ユニバーサル・シェル・プ ログラミング研究所 ユニケージ(R)開発手 法
  • 70. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 超高速開発コミュニティに参加している ツールベンダーのツールの種類 1.コード生成 GeneXus, Web Performer, MDFrame/X, Wagby, OutSystemsPlatform, CA- Gen, SAF Product 2.実行エンジン PEXA, A’s Style, Sapiens, TALON, Magic xpa, FASTApp 3.バッチ実行エンジン ODIP 4.ワークフロー作成と実行エンジン コラボフロー, Metasonic Suite 5.Excelアドイン・アプリケーション作成 STiLL 6.ビジネス・プロセス作成・管理 Xupper II 7.アプリケーション統合・データ連携(EAI) ASTERIA WARP, Magic xpi 8.テスト自動実行 STAR-ATT, STAR-Lite, SWAT 9.タブレット・アプリ作成 seap 10.シェル・プログラミング・ツールと手法 ユニケージ(R)開発手法 注意: ここに示した分類は、例にすぎません。ツール・ベンダー各社が承認したものではありませんのでご注意ください。 (as of 2014.10.31 ) 下線付きは リポジトリを持つ タイプ 70
  • 71. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. ツール選定で重視すること 機能の豊富さ, 4 機能の拡張性, 2 開発の自由度, 3 ツールの品質, 8 開発と保守の 生産性, 14 習得の容易性 , 7 価格, 9 開発規模との 適合性, 4 導入実績, 4 ブランド、0 サポート力, 1 自社のスキル・カバ レッジ, 2 その他, 1 2014.1.7のQCD研究会での、超高速開発に関する説明に対するアンケート結果(2014.3.4に依頼したもの)サマリー 71
  • 72. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 導入先の業種と企業規模 35.1 19.7 8.0 3.4 23.4 1.1 4.3 4.9 製造 流通 金融 通信 サービス 建設 公共・公益 その他 ※ 2013/11月時点の12ツールの累計導入社のうち判別できた事例 5,723社より 9% 17% 16% 23% 28% 7% 100人以下 100人から300人以下 300人から1000人以下 1000人から3000人以下 3000人以上 不明 72
  • 73. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. インソーシング(内製)利用状況 ※ 2013/11月時点の6ツールの累計導入社のうち判別できた事例 1,916社より 34.0 11.0 55.0 ユーザ主体開発 ユーザ主体、一部SIer参画 SIer主体開発 73
  • 74. Copyright ©2014 MBC (Method Based Consulting) All Rights Reserved. 終わり 74