Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Information-technology Promotion Agency, Japan
SoftwareEngineeringCenter
『超上流』でのユーザ・ベンダの役割分担
2005年6月20日
エンタプライズ系プロジェクト開発プロセス共有化部会 主査
富士通株式会社村上憲稔
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
2Software Engineering Center
目 次
1.開発プロセス共有化部会の紹介
2.平成16年度活動成果の紹介
「経営者が参画する要求品質の確保
~超上流から攻めるIT化の勘どころ~」
3.平成17年度活動に向けて
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
3Software Engineering Center
1.開発プロセス共有化部会の紹介
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
4Software Engineering Center
活動の狙い
エンドユーザ、情報システム部門、ベンダなどの ステークホルダ(利害関係者)間で、ソフトウェア 開発における役割分担に関するベストプラクティス を提供し、ソフトウェア開発の失敗リスクを低減し、 プロジェクトを成功へ導く。
そのため、ユーザ、ベンダで合意した、産業界での 新しいルールとなるガイドラインを設定・普及を図り、 日本のIT産業の競争力を強化する。
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
5Software Engineering Center
部会の構成
主査 村上憲稔(富士通)
副主査 菊島靖弘(東京海上日動システムズ)
石川貞裕(日立製作所) 太田進一(東京電力)
小野原泰光(東京ガス) 加藤光明(CRCソリューションズ)
寺田尚弘(清水建設) 内藤裕史(日本アイビーエム)
端山 毅(NTTデータ) 深瀬光聡(新日鉄ソリューションズ)
森下哲成(リクルート) 山崎 剛/野村伸介(NEC)
若杉賢治(富士通) 石谷 靖(SEC/三菱総研)
小林陽二郎(SEC/CSK) 新谷勝利(SEC/国際基督教大)
室谷 隆(SEC/TIS) 安田 守(SEC/野村総研)
尾股達也(JISA) 角田千晴(JUAS)
橋本惠二(東京国際大) 祝谷和宏(経済産業省)
風間博之/上原 智(経済産業省)
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
6Software Engineering Center
2.平成16年度活動成果の紹介
「経営者が参画する要求品質の確保
~超上流から攻めるIT化の勘どころ~」
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
7Software Engineering Center
①発注者と受注者はお互いにまったく異なる要求/要件の設定に成功。
②それと共に、失敗への階段を確実に上り始める。
良く分からないから、とりあえず現行と同じ。
「現行と同じ?」何とか成るだろう。
こんなにも違う要求/要件
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
8Software Engineering Center
思い当たることはありませんか?
・ ITシステムで何がしたいのか、何ができるのか
はっきりした答えを出せない
・ 出せるユーザ企業は多くないと思う
・ はっきりしていないITシステムの開発要件がある
・ 初期の見積回答が縛りになっている
・ 開発に入った後で開発規模が膨れた経験がある
・ 運用テストで、大幅な手戻りした経験がある
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
9Software Engineering Center
第1章 情報化にあたって経営者は何を認識すべきか
第2章 ITシステム開発・調達の現場で何が起こっているか
第3章 要求品質の確保に向けて
第4章 超上流工程でやるべきことと役割分担
経営者が参画する要求品質の確保 ~超上流から攻めるIT化の勘どころ~
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
10Software Engineering Center
第 1 章
情報化にあたって
経営者は何を認識すべきか
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
11Software Engineering Center
行政行政 医療医療教育教育
金融金融
eSTB
家庭家庭 交通交通
全てがネットワーク化され社会インフラ化する
製造製造 流通流通
ネットワーク全体の信頼性アプリケーション連携
通信
放送
背 景
SEC設立記念講演会
富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
12Software Engineering Center
ユビキタス(自在なネットワーク)
生活者の嗜好
現場の進捗
製品の稼働状況
モノの動き
渋滞の状況
人の動き
狭い
見える範囲
広い
広いネットワークの拡がり
固定ネットワーク モバイル(柔らかいネットワーク)
SEC設立記念講演会
富士通講演資料より
IT利活用の広がり
• システムは社会基盤化• 要求は多様化• システムは社会基盤化• 要求は多様化
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
13Software Engineering Center
3.ステークホルダーの増加
IT担当
企画担当
商品・事務
営業推進
会計等
経営 個人のお
客様
企業のお
客様
営業
販売提携
企業
代理店
さん
銀行
監督官庁
アウトソーサー
ヘルプデスク
コールセンター
サービスセンター
開発・運用
菊島氏講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
14Software Engineering Center
業務規定書にそってシステム化
人が行う業務の 結果が入力され 処理された
業務規定書にそってシステム化
人が行う業務の 結果が入力され 処理された
システムから
出てくる情報で
人が業務を行う
システムから
出てくる情報で
人が業務を行う
現状現状従来従来
システムは業務基盤となったシステムは業務基盤となった
・ 業務は、ITシステムに支えられて運用
・ システムの停止 = ビジネスの停止
・ システムリスク = 経営リスク
システム品質向上はITガバナンスの重要課題
経営者がシステムに大きく関与していく時代
菊島氏講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
15Software Engineering Center
・ニーズ、企画、要求定義、設計、プログラミング、テストケース作成、テストなどあらゆる局面で人が関与。
・「どんなに自動化が進んでも、自動化しえない部分が
ある。そして、それこそが本質なのだ」ということを
正しく認識する必要がある。
システム開発は人間技
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
16Software Engineering Center
オープン化 と ITシステム
ISV
サーバ
アプリケーション
ネットワーク
サーバ
ストレージ ストレージ
アプリケーション
【1980年代:集中】メインフレームモデル・高い整合性・豊富なミドルウェア機能
【1990年代:分散】ベスト・オブ・ブリードモデル・選択の自由(検証の負荷)・ミドルウェア機能をアプリで補完
アプリケーション
ミドルウェア
ミドルウェア
ネットワーク IHV
富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
17Software Engineering Center
非機能要求
既存システム
コネクティビティ要件
プロジェクト要件
システム
要件
システム化 要求
システム化要件は拡大・複雑化システム化要件は拡大・複雑化システム化要件は拡大・複雑化
実現したいビジネス
菊島氏講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
18Software Engineering Center
第 2 章
ITシステム開発・調達の現場で
何が起こっているか
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
19Software Engineering Center
開発・調達の現場で起こっていること
(1) 産業界でのITシステム開発の取り組み
(2) 事業における業務システム、ITシステムとは
(3) 要件定義が正しくないと運用テストで・・・
(4) ソフト開発における手戻りとコストの関係
(5) 要求仕様書は書けなく(書かなく)なった?
(6) ものづくりの流れとソフトエンジの取り組み
(7) “ITシステムを求める人”と“ものづくりの人”
(8) ギャップを埋めるための手順の認識
(9) 規模が膨張する力学
(10) おのおの異なる想い
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
20Software Engineering Center
産業界でのITシステム開発の取り組み
企画 設計 開発 テスト 運用 保守
プロセス標準化(ex.SLCP,共通フレーム98)プロセス標準化(ex.SLCP,共通フレーム98)
プロセス評価(ex. ISO15504,CMM/CMMI)プロセス評価(ex. ISO15504,CMM/CMMI)
品質管理システム(ex. ISO9001)品質管理システム(ex. ISO9001)
プロジェクトマネジメント(ex. PMBOK)プロジェクトマネジメント(ex. PMBOK)
技法・ツール群
業務分析業務分析 設計開発設計開発 テストテスト 運用・保守運用・保守
“ものづくり”としてのソフトウェアエンジニアリングが中心
“ものづくり”に入る前に・・・
上 流 工 程
SEC設立記念講演会富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
21Software Engineering Center
事業における業務システム、ITシステムとは
事業
業務システム
ITシステム
ソフトウェア
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
22Software Engineering Center
要件定義が正しくないと運用テストで・・・
システム仕様システム仕様
プログラミングプログラミング
要件定義要件定義
システムテストシステムテスト
運用テスト運用テスト
ソフトウェア仕様
ソフトウェア仕様
ソフトウェアテスト
ソフトウェアテスト
要求は正しかったか?
仕様どおりか?
IT
シ
ス
テ
ム
業
務
シ
ス
テ
ム
評 価
ソフト
ウェア
事
業
システム化の方向性・システム化計画
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
23Software Engineering Center
発見工程別相対修正コスト
ソフトウェアテスト
システムテスト
運用テスト
ソフト開発における手戻りとコストの関係
システム仕様システム仕様
プログラミングプログラミング
要件定義要件定義
システムテストシステムテスト
運用テスト運用テスト
ソフトウェア仕様
ソフトウェア仕様
ソフトウェアテスト
ソフトウェアテスト
5
10
修 正 コ ス ト
出展:B.W.Boehm “Soft. Eng.” IEEE Trans. com (Nov ‘76)
SEC設立記念講演会富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
24Software Engineering Center
業務要求仕様は書けなく(書かなく)なった?
出典:JUAS 平成15年12月 ユーザ企業IT動向調査 調査概要報告書
16%16%
22%22%
33%
36%
41%
36%
9%
6%
0% 40% 80%
全体(n=653)
1000人以上 22%22%
16%16%
企業規模
ユーザ作成 細部はベンダ 大部分はベンダ
発注者としての反省点
257257 6767システム仕様の定義が不充分のまま発注
20 20 44 44
133133 109109
35030025020015010050
発注先に要求仕様条件を明確に提示しなかった
ユーザ部門に任せきりでIT部門が適切な介在を
しなかった 回答総数:621件
:1位
:2位
要求仕様書作成の役割分担
すべてベンダ
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
25Software Engineering Center
(6)ものづくりの流れとソフトエンジの取り組み
<これまで>
実業務(ex.業務規定書)
写像
写像??
Wants
<現在>
未知・未経験業務
(ex.経営に役立つIT戦略)
要求分析・定義 システム設計
・業務機能
・業務フロー
・画面遷移
・ER図
・・・
・システム方式
・システム構成
・機能設計
・・・
・・・
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
26Software Engineering Center
・経営に役立つ機能・スピード(早く)・費用(安く)・品質(良いものを)・使い易さ・セキュリティ・サービス性
・・・
“ITシステムを求める人”と“ものづくりの人”
変換
大きなギャップ
企画プロセス 開発プロセス
“ITシステムを求める人”(経営者、エンドユーザなど)
“ITシステムを求める人”(経営者、エンドユーザなど)
“ものづくりの人”“ものづくりの人”
・仕様の固まり具合・利害関係者の合意・IT技術・ソフトエンジのスキル・再利用・方式
・・・
VS
SEC設立記念講演会富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
27Software Engineering Center
ギャップを埋めるための手順の認識
Wants開発プロセス
家作りとソフト(システム)作りを対比させる等して分かり易く両者に見せる努力が必要
どの段階で、誰が、何を決めなければならないのか。
・ニーズの識別
・関係者間の合意
・利用シーン
・制約条件
・ ・ ・
・サブシステム構成
・システム要求定義
・業務分析
・妥当性確認
・要求との検証
・ ・
・業務/システム
の視点
・プロジェクトの視点
・役割分担
・ ・ ・
要件定義書
要件定義書
ギャップを埋めるために
利害関係者要求定義
利害関係者要求定義
システム分解業務分析
システム分解業務分析 範囲・深さの設定範囲・深さの設定
SEC設立記念講演会富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
28Software Engineering Center
規模が膨張する力学
やりたいこと(効率的な業務運用の視点)
やりたいこと(効率的な業務運用の視点)
できること(効率的なシステム開発の視点)
できること(効率的なシステム開発の視点)
現業部門 開発部門
業務とITのギャップ
現場のやりたいことを
最優先
SEC設立記念講演会富士通講演資料より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
29Software Engineering Center
おのおの異なる想い
要件定義システム
設計ソフトウェア
設計プログラミング
ユーザ企業
の想い
ベンダ企業
の想い
想い①【要件 】 はできだけじっくり詰めたい [ 後回し]
想い②【 予算 】 は早く投資判断をしたいので、早く欲しい [ 前倒し]
想い④【予算 】 はリスクがあるので、できるだけ後に出したい [ 後回し]
想い③【 要件 】 は一刻も早く確定したものが欲しい [ 前倒し]
システム化計画
システム化の方向性
投資判断に資す
る精度の見積
責任を持って
見積を出すの
に十分な要件
要件定義終了時
に求めるものユーザ ベンダ
やるべきこと 要件の確定( )予算 見積
の確定ユーザ ベンダ
想いは相
反するも
のばかり
共に100%を求めるのは無理。
レベルを決める必要がある。
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
30Software Engineering Center
第 3 章
要求品質の確保に向けて
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
31Software Engineering Center
部会の取り組みにあたって
基本スタンス:実務をベースにした課題解決
・開発に入る前の要求品質確保に焦点
・ユーザ企業参画の業界ルール作り
・「経営者の参画」を訴求
・関係者の役割と責任分担を明らかに
・どこまでできると固まったといえるか
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
32Software Engineering Center
開発に入る前の要求品質確保に焦点
システム仕様システム仕様
プログラミングプログラミング
要件定義要件定義
システムテストシステムテスト
運用テスト運用テスト
ソフトウェア仕様
ソフトウェア仕様
ソフトウェアテスト
ソフトウェアテスト
IT
シ
ス
テ
ム
業
務
シ
ス
テ
ム
システム化の方向性・システム化計画
評 価
ソフト
ウェア
事
業
菊島氏講演資料より
超上流プロセス
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
33Software Engineering Center
ユーザ企業参画の業界ルール作り
開発プロセス共有化部会の参加組織
(ユーザ企業) 東京海上日動システムズ、東京電力、
東京ガス、清水建設、リクルート、
日本情報システム・ユーザー協会
(ベンダ企業) CRCソリューションズ、日立、日本IBM、
NTTデータ、新日鉄ソリューションズ、NEC、
富士通、情報サービス産業協会
(官・学) 東京国際大、経済産業省、SEC
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
34Software Engineering Center
「経営者の参画」を訴求
経営者の役割と責任分担
例) 経営戦略実現の視点からの絞込み
適切なサイズのシステム化実現=
開発期間、費用、品質管理へ好影響
例) ROIの視点
ITシステム開発の軸(何が得られるか) VS
経営の軸(ビジネス上の価値を最大にするには何をすべきか)
システムリスクは経営リスクシステム品質向上はITガバナンスの重要課題経営者がシステムに大きく関与していく時代
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
35Software Engineering Center
シ ステム設
計
シ ステム設
計
確定
・プロセス定義と役割・責任の
マトリックス化
・ユーザが作成すべきoutput
・要求の固まり具合と
見積レベルの関係の明確化
・委託時の承認(責任)のとり方
・非機能要件も検討の俎上
関係者の役割と責任分担を明らかに
経営層
業務部門
情報システム部門
ベンダ
超超 上上 流流
システム化の方向性
システム化計画
要件定義
要件定義書
要件定義書
仮試算
試算 概
算
RFP
RFP
RFP
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
36Software Engineering Center
第 4 章
超上流工程で
やるべきことと役割分担
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
37Software Engineering Center
サブベンダ
アウトソーサ
元請けベンダ
ベンダ
システム子会社
システム開発担当
部門長
情報シス
テム部門
関連会社
システム推進担当
業務推進担当
部門長
業務部門
担当役員
社長経営層
要件の定義内容部署等/役割(ロール)
要件の定義と役割(ロール)
事業要件定義
ITシステム要件定義
業務システム要件定義
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
38Software Engineering Center
目的 内容 主体名称(大項目)
名称(小項目) (◎は主担当)
システム化方針の確認
事業戦略/事業計画
中長期システム化戦略
単年度システム開発計画
事業システム全体図
・・・
・・・
・・・
・・・
事業部門長(◎)
担当役員
システム推進担当
システム推進担当
システム開発担当
・・・
・・・
・・・
・・・
プロジェクトの背景・目的の共有
プロジェクト概要 ・・・
・・・
業務推進担当
業務推進担当
・・・
・・・プロジェクトの課題
・ ・・・
役割分担と成果物
例)
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
39Software Engineering Center
見積り時期と見積り誤差・リスク
仮試算 試算 概算 確定
システム化の方向性
設計システム化計画 時間時間
わずかな情報わずかな情報/高いリスク/高いリスク
妥当な見積妥当な見積
情報の充実/情報の充実/低いリスク低いリスク
誤差
製作要件定義
見積額
見積額
「不確定要素が多い中での見積もりをプロジェクトの目標値として設定すべきではない」(SEC:「定量的見積りの勧め」より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
40Software Engineering Center
ベンダ
見積・契約
サブベンダ
情報シス
テム部門
業務部門
経営層
システム化の方向性 システム化計画
方針/問題点
部門間の検討
RFP①
説明作成・打合
レビュー
承認
業務検討
方向性の確認
提案書
承認
部門間の検討
RFP②
方針稟議
概要の確認
システム化計画書作成
提案書
レビュー(計画・見積)
発注検討
コンサルタント契約 仮試算見積 サポート契約
承認
承認
確認
要求の固まり具合と見積レベルの関係 (1)
試算見積
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
41Software Engineering Center
ベンダ
見積・契約
サブベンダ
情報システム部門
業務部門
経営層
要件定義 システム設計
事業要件・業務
システム要件定義
RFP③
承認
提案書作成
承認
開発契約基本設計契約
業務要件
定義書作成
システム
要件定義
システム要件
定義書作成
レビュー
(
要件定義書・概算見積)
実行稟議
(
要件定義書・見積)
打合せ・発注検討
(
要件定義書)
画面帳票等の検討
設計(
外部)
設計(
内部)設計検討
レビュー(
システム設計)
要件定義契約
承認
承認
見積
説明
要求の固まり具合と見積レベルの関係 (2)
概算見積 確定見積
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
42Software Engineering Center
システム化の方向性・システム化計画工程
(1) 経営戦略とIT戦略の融合
(2) 超上流が『かぎ』
・ 経営層の明確な意思決定と責任
・ 経営層、業務部門、情報システム部門の
ステークホルダの合意形成
(3) 進めるうえでの7つのポイント(小冊子参照)
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
43Software Engineering Center
要件定義工程
(1) 要件定義工程のゴール
<顧客企業>
投資判断に耐えうる精度の予算算定が可能なこと
<ベンダ企業>
責任を持って見積りを出すのに十分な要件が
確定すること
(2) 課題解決への提案
・双方の価値観の共有、協力
・システムの「出来姿」を描ききる努力(業務、IT)
・最終仕様決定は顧客自身が行うという意識付け
など
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
44Software Engineering Center
3.平成17年度活動に向けて
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
45Software Engineering Center
17年度の取り組み方針
(1) 小冊子のキーワード(これだ!)で詳細化
・ 事例(問題の本質が分かるように)
・ ベストプラクティス(こうすればいいのか)
・ 用語(経営者に分かる平易な解説) など
(2) 普及のために
(3) 産業界のルールとして認識を強化するために
等
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
46Software Engineering Center
小冊子に寄せて
私はかねて、ITの活用、そのためのITガバナンスが
ビジネスの革新と企業の成長、社会的責任を実現する
と申してまいりました。
この冊子は、ITを活用しビジネスに革新をもたらそう
とされる方々にIT活用の基礎となる、示唆にとんだ、
正しい知識とノウハウを提供してくれます。
この冊子がひろく活用され、わが国のIT開発がより
洗練された、力強いものになることを願っています。
東京海上日動火災保険㈱ 常務 隅修三様より
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
47Software Engineering Center
ま と め
◎ 国をあげての取り組み
◎ ユーザ企業、ベンダー企業との総意
◎ 産業界の新しいルールつくり
あなたなら、どのように活用しますか?
開発に入る前の要求品質の確保
『超上流』でのユーザ・ベンダの役割分担
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
48Software Engineering Center
皆様に小冊子を是非読んでいただきたい。
ご静聴ありがとうございました。
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
49Software Engineering Center
(参考)SECエンタープライズ系領域の各活動
経営層
業務部門
情報システム部門
ベンダ
超上流超上流 開発開発プロセスプロセス
開発プロセス共有化部会
設計設計 開発開発 テストテスト
設計・開発技術研究部会
確定
見積手法部会
開発プロセス共有化部会の平成16、17年度重点領域
定量データ分析部会
運用運用 保守保守
システムの方向性
システム化計画
要件定義
仮試算
試算
RFP R
FP
要求工学研究部会
要件定義書
要件定義書
RFP
概算