0 nma0 0g0n 0æ0ü0¶0û0Ù0ó0À0n yrrr bÅ - ipainformation-technology promotion agency, japan...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

『超上流』でのユーザ・ベンダの役割分担

2005年6月20日　

エンタプライズ系プロジェクト開発プロセス共有化部会主査

富士通株式会社村上憲稔

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

2Software Engineering Center

目　次

１．開発プロセス共有化部会の紹介

２．平成１６年度活動成果の紹介

　　　「経営者が参画する要求品質の確保

　　　　～超上流から攻めるIT化の勘どころ～」

３．平成１７年度活動に向けて



１．開発プロセス共有化部会の紹介



活動の狙い

　　エンドユーザ、情報システム部門、ベンダなどの　　ステークホルダ（利害関係者）間で、ソフトウェア　　開発における役割分担に関するベストプラクティス　　を提供し、ソフトウェア開発の失敗リスクを低減し、　　プロジェクトを成功へ導く。

　　そのため、ユーザ、ベンダで合意した、産業界での　　新しいルールとなるガイドラインを設定・普及を図り、　　日本のＩＴ産業の競争力を強化する。



部会の構成

主査　　村上憲稔（富士通）

副主査　菊島靖弘（東京海上日動システムズ）

　　石川貞裕（日立製作所）太田進一（東京電力）

　小野原泰光（東京ガス）加藤光明（ＣＲＣソリューションズ）

　　寺田尚弘（清水建設）内藤裕史（日本アイビーエム）

　　端山　毅（NTTデータ）　　深瀬光聡（新日鉄ソリューションズ）

　森下哲成（リクルート）山崎　剛/野村伸介（NEC)　

若杉賢治（富士通）　　　石谷　靖（SEC/三菱総研）

小林陽二郎（SEC/CSK) 新谷勝利（SEC/国際基督教大）　

室谷　隆（SEC/TIS) 安田　守（SEC/野村総研）　

尾股達也（JISA) 角田千晴（JUAS)　

橋本惠二（東京国際大）祝谷和宏（経済産業省）　

風間博之/上原　智（経済産業省）



２．平成１６年度活動成果の紹介

　

　　「経営者が参画する要求品質の確保

　　　～超上流から攻めるIT化の勘どころ～」



①発注者と受注者はお互いにまったく異なる要求／要件の設定に成功。

②それと共に、失敗への階段を確実に上り始める。

良く分からないから、とりあえず現行と同じ。

「現行と同じ？」何とか成るだろう。

こんなにも違う要求／要件



思い当たることはありませんか？

・　ITシステムで何がしたいのか、何ができるのか

はっきりした答えを出せない

・　出せるユーザ企業は多くないと思う

・はっきりしていないITシステムの開発要件がある

・　初期の見積回答が縛りになっている

・　開発に入った後で開発規模が膨れた経験がある

・運用テストで、大幅な手戻りした経験がある

　



　

　　　　第１章情報化にあたって経営者は何を認識すべきか

　　第２章　ITシステム開発・調達の現場で何が起こっているか

　　第３章　要求品質の確保に向けて

　　第４章　超上流工程でやるべきことと役割分担

経営者が参画する要求品質の確保　　～超上流から攻めるＩＴ化の勘どころ～



　　　　　　　　　　　第　１　章

　

　　　　　　　　　情報化にあたって

　　　　　　経営者は何を認識すべきか



行政行政医療医療教育教育

金融金融

eSTB

家庭家庭交通交通

全てがネットワーク化され社会インフラ化する

製造製造流通流通

ネットワーク全体の信頼性アプリケーション連携

通信

放送

背　　景

ＳＥＣ設立記念講演会

富士通講演資料より



ユビキタス(自在なネットワーク)

生活者の嗜好

現場の進捗

製品の稼働状況

モノの動き

渋滞の状況

人の動き

狭い

見える範囲

広い

広いネットワークの拡がり

固定ネットワークモバイル(柔らかいネットワーク)

ＳＥＣ設立記念講演会


IT利活用の広がり

•　システムは社会基盤化•　要求は多様化•　システムは社会基盤化•　要求は多様化



３．ステークホルダーの増加

ＩＴ担当

企画担当

商品・事務

営業推進

会計等

経営個人のお

客様

企業のお

客様

営業

販売提携

企業

代理店

さん

銀行

監督官庁

ｱｳﾄｿｰｻｰ

ﾍﾙﾌﾟﾃﾞｽｸ

ｺｰﾙｾﾝﾀｰ

ｻｰﾋﾞｽｾﾝﾀｰ

開発・運用

菊島氏講演資料より



　業務規定書にそってシステム化　

　人が行う業務の　結果が入力され　処理された　

　業務規定書にそってシステム化　

　人が行う業務の　結果が入力され　処理された　

　　システムから

　出てくる情報で

　人が業務を行う

　　システムから

　出てくる情報で

　人が業務を行う

現状現状従来従来

システムは業務基盤となったシステムは業務基盤となった

　　

・　業務は、ＩＴシステムに支えられて運用

　　・　システムの停止＝ビジネスの停止

　　・　システムリスク＝経営リスク

システム品質向上はITガバナンスの重要課題

経営者がシステムに大きく関与していく時代




　　

・ニーズ、企画、要求定義、設計、プログラミング、テストケース作成、テストなどあらゆる局面で人が関与。

・「どんなに自動化が進んでも、自動化しえない部分が

ある。そして、それこそが本質なのだ」ということを

　正しく認識する必要がある。

システム開発は人間技



オープン化と ITシステム

ＩＳＶ

サーバ

アプリケーション

ﾈｯﾄﾜｰｸ

サーバ

ｽﾄﾚｰｼﾞｽﾄﾚｰｼﾞ


【１９８０年代：集中】メインフレームモデル・高い整合性・豊富なミドルウェア機能

【１９９０年代：分散】ベスト・オブ・ブリードモデル・選択の自由（検証の負荷）・ミドルウェア機能をアプリで補完


ミドルウェア

ミドルウェア

ﾈｯﾄﾜｰｸ IHV




非機能要求

既存ｼｽﾃﾑ　

ｺﾈｸﾃｨﾋﾞﾃｨ要件

プロジェクト要件

システム

要件

システム化　　　　　要求

システム化要件は拡大・複雑化システム化要件は拡大・複雑化システム化要件は拡大・複雑化

実現したいビジネス




　　　　　　　　　　　第　２　章　

　

　　　　　ITシステム開発・調達の現場で

　　　　　何が起こっているか



　開発・調達の現場で起こっていること

　　（１）　産業界でのITシステム開発の取り組み

　　（２）　事業における業務システム、ITシステムとは

　　（３）　要件定義が正しくないと運用テストで・・・

　　（４）　ソフト開発における手戻りとコストの関係

　　（５）　要求仕様書は書けなく（書かなく）なった？

　　（６）　ものづくりの流れとソフトエンジの取り組み

　　（７）　“ITシステムを求める人”と“ものづくりの人”

　　（８）　ギャップを埋めるための手順の認識

　　（９）　規模が膨張する力学

　（１０）　おのおの異なる想い



産業界でのＩＴシステム開発の取り組み

企画設計開発テスト運用保守

プロセス標準化（ex.SLCP,共通フレーム98）プロセス標準化（ex.SLCP,共通フレーム98）

プロセス評価（ex. ISO15504,CMM/CMMI）プロセス評価（ex. ISO15504,CMM/CMMI）

品質管理システム（ex. ISO9001）品質管理システム（ex. ISO9001）

プロジェクトマネジメント（ex. PMBOK）プロジェクトマネジメント（ex. PMBOK）

技法・ツール群

業務分析業務分析設計開発設計開発テストテスト運用・保守運用・保守

“ものづくり”としてのソフトウェアエンジニアリングが中心

“ものづくり”に入る前に・・・

上　流　工　程

ＳＥＣ設立記念講演会富士通講演資料より



事業における業務システム、ITシステムとは

事業

業務システム

ＩＴシステム

ソフトウェア



要件定義が正しくないと運用テストで・・・

システム仕様システム仕様

プログラミングプログラミング

要件定義要件定義

システムテストシステムテスト

運用テスト運用テスト

ソフトウェア仕様


ソフトウェアテスト


要求は正しかったか？

仕様どおりか？

ＩＴ

シ

ス

テ

ム

業

務

シ

ス

テ

ム

評　価

ソフト

ウェア

事

業

システム化の方向性・システム化計画



発見工程別相対修正コスト


システムテスト

運用テスト

ソフト開発における手戻りとコストの関係





運用テスト運用テスト





5

10

修　正　コ　ス　ト

出展：B.W.Boehm “Soft. Eng.” IEEE Trans. com (Nov ‘76)




業務要求仕様は書けなく（書かなく）なった？

出典：ＪＵＡＳ　平成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

発注先に要求仕様条件を明確に提示しなかった

ユーザ部門に任せきりでＩＴ部門が適切な介在を

しなかった回答総数：621件

：1位

：2位

要求仕様書作成の役割分担

すべてベンダ



（６）ものづくりの流れとソフトエンジの取り組み

＜これまで＞

実業務（ex.業務規定書）

写像

写像??

Wants

＜現在＞

未知・未経験業務

（ex.経営に役立つIT戦略）

要求分析・定義システム設計

・業務機能

・業務フロー

・画面遷移

・ER図

・・・

・システム方式

・システム構成

・機能設計

・・・

・・・



・経営に役立つ機能・スピード（早く）・費用（安く）・品質（良いものを）・使い易さ・セキュリティ・サービス性

・・・

“ITシステムを求める人”と“ものづくりの人”

変換

大きなギャップ

企画プロセス開発プロセス

“ITシステムを求める人”（経営者、エンドユーザなど）

“ITシステムを求める人”（経営者、エンドユーザなど）

“ものづくりの人”“ものづくりの人”

・仕様の固まり具合・利害関係者の合意・IT技術・ソフトエンジのスキル・再利用・方式

・・・

VS




ギャップを埋めるための手順の認識

Wants開発プロセス

家作りとソフト（システム）作りを対比させる等して分かり易く両者に見せる努力が必要

どの段階で、誰が、何を決めなければならないのか。

・ニーズの識別

・関係者間の合意

・利用シーン

・制約条件

　　　　　・　　　　　・　　　　　・

・サブシステム構成

・システム要求定義

・業務分析

・妥当性確認

・要求との検証

　　　　　・　　　　　・

・業務／システム

　の視点

・プロジェクトの視点

・役割分担

　　　　　・　　　　　・　　　　　・

要件定義書

要件定義書

ギャップを埋めるために

利害関係者要求定義

利害関係者要求定義

システム分解業務分析

システム分解業務分析範囲・深さの設定範囲・深さの設定




規模が膨張する力学

やりたいこと（効率的な業務運用の視点）

やりたいこと（効率的な業務運用の視点）

できること（効率的なｼｽﾃﾑ開発の視点）

できること（効率的なｼｽﾃﾑ開発の視点）

現業部門開発部門

業務とＩＴのギャップ

現場のやりたいことを

最優先




おのおの異なる想い

要件定義システム

設計ソフトウェア

設計プログラミング

ユーザ企業

の想い

ベンダ企業

の想い

想い①【要件】はできだけじっくり詰めたい [ 後回し]

想い②【予算】は早く投資判断をしたいので、早く欲しい [ 前倒し]

想い④【予算】はリスクがあるので、できるだけ後に出したい [ 後回し]

想い③【要件】は一刻も早く確定したものが欲しい [ 前倒し]

システム化計画

システム化の方向性

投資判断に資す

る精度の見積

責任を持って

見積を出すの

に十分な要件

要件定義終了時

に求めるものユーザベンダ

やるべきこと要件の確定( )予算見積

の確定ユーザベンダ

想いは相

反するも

のばかり

共に１００％を求めるのは無理。

レベルを決める必要がある。



　　

第　３　章　

要求品質の確保に向けて



　　部会の取り組みにあたって

基本スタンス：実務をベースにした課題解決

　・開発に入る前の要求品質確保に焦点

　・ユーザ企業参画の業界ルール作り

　・「経営者の参画」を訴求

　・関係者の役割と責任分担を明らかに

　・どこまでできると固まったといえるか



開発に入る前の要求品質確保に焦点





運用テスﾄ運用テスﾄ





ＩＴ

シ

ス

テ

ム

業

務

シ

ス

テ

ム

システム化の方向性・システム化計画

評　価

ソフト

ウェア

事

業


超上流プロセス



ユーザ企業参画の業界ルール作り

　　　開発プロセス共有化部会の参加組織

（ユーザ企業）　東京海上日動システムズ、東京電力、

　　　　　　　　東京ガス、清水建設、リクルート、

　　　　　　　　　日本情報システム・ユーザー協会　

（ベンダ企業）　ＣＲＣソリューションズ、日立、日本IBM、

　　　　　　　　　NTTデータ、新日鉄ソリューションズ、NEC、

　　　　　　　　　富士通、情報サービス産業協会

（官・学）　　　東京国際大、経済産業省、ＳＥＣ



「経営者の参画」を訴求

経営者の役割と責任分担

　例）　経営戦略実現の視点からの絞込み

　　適切なサイズのシステム化実現＝

　　　　　　　　　　　　　　　　　開発期間、費用、品質管理へ好影響

　例）　ROIの視点

　　ITシステム開発の軸(何が得られるか）　　　　　VS　

　　　経営の軸（ビジネス上の価値を最大にするには何をすべきか）

システムリスクは経営リスクシステム品質向上はITガバナンスの重要課題経営者がシステムに大きく関与していく時代



　シ　ステム設

　計　

　シ　ステム設

　計　

確定

・プロセス定義と役割・責任の

　マトリックス化

・ユーザが作成すべきoutput

・要求の固まり具合と

　見積レベルの関係の明確化

・委託時の承認（責任）のとり方

・非機能要件も検討の俎上

　　関係者の役割と責任分担を明らかに

経営層

業務部門

情報ｼｽﾃﾑ部門

ベンダ

超超　　上上　　流流



要件定義

　要件定義書

　要件定義書

仮試算

試算概

算

ＲＦＰ

ＲＦＰ

ＲＦＰ



　　　　　　　　　　第　４　章

　

　　　　　　　　　超上流工程で

　　　　　　やるべきことと役割分担



サブベンダ

アウトソーサ

元請けベンダ

ベンダ

システム子会社

ｼｽﾃﾑ開発担当

部門長

情報シス

テム部門

関連会社

ｼｽﾃﾑ推進担当

業務推進担当

部門長

業務部門

担当役員

社長経営層

要件の定義内容部署等／役割（ロール）

要件の定義と役割（ロール）

事業要件定義

ＩＴシステム要件定義

業務システム要件定義



目的内容主体名称（大項目）

名称（小項目）（◎は主担当）

システム化方針の確認

事業戦略／事業計画

中長期システム化戦略

単年度システム開発計画

事業システム全体図

・・・

･･･

・・・

･･･

事業部門長（◎）

担当役員



ｼｽﾃﾑ開発担当

・・・

･･･

・・・

･･･

プロジェクトの背景・目的の共有

プロジェクト概要･･･

・・・

業務推進担当

業務推進担当

･･･

・・・プロジェクトの課題

・・・・

　　　　　　役割分担と成果物

例）



見積り時期と見積り誤差・ﾘｽｸ

仮試算試算概算確定


設計システム化計画時間時間

わずかな情報わずかな情報／高いリスク／高いリスク

妥当な見積妥当な見積

情報の充実／情報の充実／低いリスク低いリスク

誤差

製作要件定義

見積額

見積額

「不確定要素が多い中での見積もりをプロジェクトの目標値として設定すべきではない」（SEC：「定量的見積りの勧め」より



ベンダ

見積・契約

サブベンダ

情報シス

テム部門

業務部門

経営層

システム化の方向性システム化計画

方針／問題点

部門間の検討

ＲＦＰ①

説明作成・打合

レビュー

承認

業務検討

方向性の確認

提案書

承認

部門間の検討

ＲＦＰ②

方針稟議

概要の確認

システム化計画書作成

提案書

レビュー(計画・見積)

発注検討

コンサルタント契約仮試算見積サポート契約

承認

承認

確認

　　要求の固まり具合と見積レベルの関係　（１）

試算見積



ベンダ

見積・契約

サブベンダ

情報システム部門

業務部門

経営層

要件定義システム設計

事業要件・業務

システム要件定義

ＲＦＰ③

承認

提案書作成

承認

開発契約基本設計契約

業務要件

定義書作成

システム

要件定義

システム要件

定義書作成

レビュー

(

要件定義書・概算見積)

実行稟議

(

要件定義書・見積)

打合せ・発注検討

(

要件定義書)

画面帳票等の検討

設計(

外部)

設計(

内部)設計検討

レビュー(

システム設計)

要件定義契約

承認

承認

見積

説明

　　要求の固まり具合と見積レベルの関係　（２）

概算見積確定見積



ｼｽﾃﾑ化の方向性・ｼｽﾃﾑ化計画工程

（１）　経営戦略とIT戦略の融合

（２）　超上流が『かぎ』

　　　・　経営層の明確な意思決定と責任

　　　・　経営層、業務部門、情報システム部門の

　　　　　ステークホルダの合意形成

（３）　進めるうえでの７つのポイント（小冊子参照）

　　　



要件定義工程　

（１）　要件定義工程のゴール

　　<顧客企業>

投資判断に耐えうる精度の予算算定が可能なこと

　 <ベンダ企業>

責任を持って見積りを出すのに十分な要件が

　　　確定すること

（２）　課題解決への提案

　　　・双方の価値観の共有、協力

　　　・システムの「出来姿」を描ききる努力（業務、IT）

　　　・最終仕様決定は顧客自身が行うという意識付け

など

　



３．平成１７年度活動に向けて



17年度の取り組み方針

（１）　小冊子のキーワード（これだ！）で詳細化

　　　　・　事例（問題の本質が分かるように）

　　　　・　ベストプラクティス（こうすればいいのか）

　　　　・　用語（経営者に分かる平易な解説）　　など

（２）　普及のために

（３）　産業界のルールとして認識を強化するために　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　等



小冊子に寄せて

　私はかねて、ＩＴの活用、そのためのＩＴガバナンスが

　ビジネスの革新と企業の成長、社会的責任を実現する

　と申してまいりました。

　　この冊子は、ITを活用しビジネスに革新をもたらそう

　とされる方々にIT活用の基礎となる、示唆にとんだ、

　正しい知識とノウハウを提供してくれます。

　　この冊子がひろく活用され、わが国のＩＴ開発がより

　洗練された、力強いものになることを願っています。

東京海上日動火災保険㈱　常務　隅修三様より



ま　と　め

　◎　国をあげての取り組み

　◎　ユーザ企業、ベンダー企業との総意

　◎ 　産業界の新しいルールつくり

あなたなら、どのように活用しますか？

開発に入る前の要求品質の確保

　　『超上流』でのユーザ・ベンダの役割分担



　　　　皆様に小冊子を是非読んでいただきたい。

　　　　　　　ご静聴ありがとうございました。　　　　

　　　



（参考）SECエンタープライズ系領域の各活動

経営層

業務部門

情報ｼｽﾃﾑ部門

ベンダ

超上流超上流開発開発プロセスプロセス

開発プロセス共有化部会

設計設計開発開発テストテスト

設計・開発技術研究部会

確定

見積手法部会

開発プロセス共有化部会の平成16､17年度重点領域

定量データ分析部会

運用運用保守保守

システムの方向性


要件定義

仮試算

試算

ＲＦＰＲ

ＦＰ

要求工学研究部会

要件定義書

要件定義書

ＲＦＰ

概算

0 nma0 0g0n 0æ0ü0¶0û0Ù0ó0À0n yrrr bÅ - ipainformation-technology promotion agency, japan...

Documents