ソフトウェアプロジェクトの成功要因と 情報システム ......2011/09/09  ·...

ソフトウェアプロジェクトの成功要因と情報システムアーキテクチャー

産業技術大学院大学

南波幸雄

略歴

1972年～1999年 ソニー株式会社 ソニー中央研究所で磁性材料の研究

1974年～83年 ソニー仙台（多賀城）で、磁気テープの製造技術生産技術、生産管理システム

1984年～ 磁気製品事業本部で製販物流プロジェクトなど

1990年～ 経営技術情報システム本部で、インフラ、情報技術など

2000年～2005年 マネックス証券株式会社 オンライン証券システムの運用と企画

2005年～ (有)エスバーグ・コンサルティング CIOアドバイザー

概念データモデリング指導

法務省CIO補佐官

2006年～2012/3 産業技術大学院大学

2011/9/9 2日立ソリューションズ（南波幸雄）

最近の活動

興味

企業情報システムアーキテクチャ

概念データモデリングの普及

谷島 宣之， “全部不安”な初プロジェクト、若手3人はいかにして乗り切ったか東京都江東区、3000人の勤怠管理システムを構築“http://business.nikkeibp.co.jp/article/tech/20110621/221045/?rt=nocnt

行政CIOの成功要因

クラウドの時代の情報システム部門の役割

CIO候補の教育

著書＆論文

企業情報システムアーキテクチャ, 翔泳社, 2009 ITと経営，経営情報学会（編），中央経済社，2011. 企業情報システムアーキテクチャの都市計画アプローチ，2011年春季経営

情報学会全国大会予稿集，2011.

2011/9/9 3日立ソリューションズ（南波幸雄）

今日の内容

プロジェクト評価としてのQとCD 2つのQ：要求と施工品質

プロジェクトマネジメント手法

情報システムアーキテクチャの観点からの考察

まとめ

2011/9/9 4日立ソリューションズ（南波幸雄）

今日の内容

プロジェクト評価としてのQとCDプロジェ口トの成功と失敗

QとC, Dプロジェクトが成功しない原因

2つのQ：要求と施工品質

プロジェクトマネジメント手法

情報システムアーキテクチャの観点からの考察

まとめ

2011/9/9 5日立ソリューションズ（南波幸雄）

ソフトウェアプロジェクトの成功と失敗

2011/9/9

成功 失敗概ね成功

失敗出典 対象

1994 16% 31% 53% Standish 米国

1996 27% 47% 33% Standish 米国

1998 26% 28% 46% Standish 米国

2000 28% 23% 49% Standish 米国

2004 34% 15% 51% Standish 米国

2006 35% 19% 46% Standish 米国

2008 32% 24% 44% Standish 米国

2005 46% 2% 52% IPA/SEC 日本

2006 60.0% 3.7% 36.3% IPA/SEC 日本

2007 59.5% 2.9% 37.6% IPA/SEC 日本

p.6日立ソリューションズ（南波幸雄）

出典： Standish Group, IPA/SEC

QとC, D Standish Gpの成功区分

Succeed Delivery Overrun Cost Overrun Abandon

IPA/SECの成功区分 成功

品質、納期、コストのどれかが問題

品質、納期、コスト全て問題＝失敗

最低品質が達成できなければプロジェクトは失敗

そのために、Cを犠牲にするか、Dを犠牲にするか

2011/9/9 日立ソリューションズ（南波幸雄） 7

これは同一基準か

これは同一基準か

Clear Statement of Requirement

13.0%

Proper Planning9.6%

RealisticExpectation

8.2%

User Involvement

15.9%

ExecutiveManagement

Support13.9%

Clear Vision & Objectives

2.9%

CompetentStaff7.7%

Hardworking Staff2.9%

Other13.9%

Ownership5.3%

Smaller ProjectMilestones

7.7%

要求定義34.0%

開発体制20.0%

プロジェクト計画

20.0%

技術力12.0%

構成管理7.0%

Pjt間調整3.0%

進捗管理3.0%

外注管理2.0%

品質保証体制2.0%

日本のプロジェクト 米国のプロジェクト

2011/9/9

日米プロジェクトの影響要因の比較

p.8日立ソリューションズ（南波幸雄）

出典： Standish GroupJISA

プロジェクトが成功しない原因

規模 大きくなるほどプロジェクトマネジメントのオーバーヘッドが増大

非合理なデータモデル

要求 要求・要件の妥当性

時間の経過による要求そのものの変質

プロジェクトマネジメント手法

非機能要求 特にパフォーマンス

移行 データモデルの相違

2011/9/9 日立ソリューションズ（南波幸雄） 9

FP規模と工数

2011/9/9 日立ソリューションズ（南波幸雄） 10

1 10 100 1,000 10,000 100,000

FP

1

10

100

1,000

10,000

100,000

1,000,000

工数（人時）

工数＝A x （FP規模）B

出典：IPA SEC 「ソフトウェア開発データ白書2008」日経BP社

2011/9/9

要求レベルの不適合

Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

機能の2/3はほとんど

使用されない！！

機能の2/3はほとんど

使用されない！！

p.11日立ソリューションズ（南波幸雄）

出典： Standish Group

要求・要件の妥当性

要求・要件

要求： 目的、効果、妥当性を検証し、関係者が合意

要件： 実現すべき業務、システムを定義したもの

だれが要求、要件を決めるか

要求： ユーザー部門主体

要件： システム部門主体

要求の妥当性をどう保証するか

要求の根源は、本来は実世界の写像であるべき

ユーザーの要望を全部取り入れるのが良い訳ではない

ユーザー間およびユーザーと情シス部門間の合意形成

2011/9/9 日立ソリューションズ（南波幸雄） 12

現時点の目標

時点1の目標 時点2の

目標

現時点

時点1での実際の位置

時点2での実際の位置

2011/9/9

時間の経過による要求そのものの変質

p.13日立ソリューションズ（南波幸雄）

今日の内容

プロジェクト評価としてのQとCD 2つのQ：設計（要求実現）品質と施工品質

設計監理と施工管理

誰が設計品質に対して責任を持つか

施工品質

プロジェクトマネジメント手法

情報システムアーキテクチャの観点からの考察

まとめ

2011/9/9 14日立ソリューションズ（南波幸雄）

設計監理と施工管理

建築の世界

設計監理： 設計者としての建築士が、設計通り工事が進行しているかを監理する

施工管理： 施行者としての施工会社の担当者が、工事の進度と手順、費用などを管理

情報システムの世界

設計監理： ？ 暗黙的にPMが監理

施工管理： PMが管理

2011/9/9 日立ソリューションズ（南波幸雄） 15

誰が設計監理に責任を持つか

情報システムの場合、誰が設計者か？

PM？

PMは、設計監理と施工管理

しかしQを決める設計監理とC, Dを決める施行監理は利益相反

2011/9/9 日立ソリューションズ（南波幸雄） 16

施工管理の課題

プロジェクト体制に関わる課題

マネジメントの参画

PMの資質と経験・知識

情報の鮮度とスピード

プロジェクトマネジメントに関する課題

前提は合理的な要件が決められていること

EVM等、精緻な管理手法は有効か？

イテレーション型をどうマネジメントするか？

2011/9/9 日立ソリューションズ（南波幸雄） 17

今日の内容

プロジェクト評価としてのQとCD 2つのQ：要求と施工品質

プロジェクトマネジメント手法

EVMCCPMアジャイルをどうマネジメントするか

情報システムアーキテクチャの観点からの考察

まとめ

2011/9/9 18日立ソリューションズ（南波幸雄）

EVM

2011/9/9 日立ソリューションズ（南波幸雄） 19

0

10

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25

工数（人日）

時間

BAC

AC

PV

EV

EVM 前提は、意味のあるWBSができているかどう

その前提は、妥当な要件定義ができているか

手戻りの保険をどうかけているか これがダメだと、まずACとPVの差が出てくる

未知な要素をどの程度包含しているか？ 不確定要素があるのがプロジェクト

タスクの進捗度の取り方

EVとACの差

データの鮮度 多段の委託構造を持っていると、データの時点が異る

タスク単位でACを計上している場合 あるタスクが伸びて要員に待ちができた時のACの値がタスク上に

出てこない

2011/9/9 日立ソリューションズ（南波幸雄） 20

CCPM(Critical Chain PM)

考え方は、タスク・要員単位のネットの工数とグロス工数の差を、プロジェクトバッファとして共通化すること

2011/9/9 日立ソリューションズ（南波幸雄） 21

Net Buffer Net Buffer Net Buffer

タスク1 タスク2 タスク3

Net Net Net Buffer

ネットのタスク 共通化されたバッファー

Waterfallの原論文

Royce, Winston W. “Managing the Development of Large Software Systems,” Proceedings, IEEE WESCON, August 1970, pp.1-9.http://portal.acm.org/ft_gateway.cfm?id=41801&type=pdf&coll

=GUIDE&dl=GUIDE&CFID=42793886&CFTOKEN=80709274 COMPUTER PROGRAM DEVELOPMENT FUNCTIONS

STEP 1: PROGRAM DESIGN COMES FIRST STEP2: DOCUMENT THE DESIGN STEP 3: DO IT TWICE STEP 4: PLAN, CONTROL AND MONITOR TESTING STEP 5: INVOLVE THE CUSTOMER

2009/7/6 AIIT ＩＴ特論 22

アジャイル開発のEVM

2011/9/9 日立ソリューションズ（南波幸雄） 23

時間

工数

AC

PV

コストの上限=BAC

時間の上限

EV=進捗率 x BAC

1回のイテレーション

※ BAC: Budget at Completion（完成時総予算）

進捗率はユーザーの感覚

EV=BACになったら開発完了

AC=BAC or時間の上限を超えたら開発終了

AC=BAC or時間の上限を超えたら開発終了

今日の内容

プロジェクト評価としてのQとCD 2つのQ：要求と施工品質

プロジェクトマネジメント手法

情報システムアーキテクチャの観点からの考察

ウィトルウィウスの三角形

発注者はだれか？

アーキテクトの役割

施工者の役割

アジャイル開発

まとめ

2011/9/9 24日立ソリューションズ（南波幸雄）

2011/9/9

アーキテクチャの要素

Utilitasニーズ＝機能発注者の視点

Venustasデザイン

アーキテクト

Firmitas構造

ビルダー

ウィトルウィウスの三角形

出典：スウェル&スウェル「職業としてのソフトウェアアーキテクト」

ピアソン･エデュケーション

ビジネスビュー

システム構築ビュー

p.25日立ソリューションズ（南波幸雄）

サービスデリバリービュー

発注者はだれか

カスタマーとユーザー

カスタマー： お金を出す人

ユーザー： システムを使う人

どちらの言う事を聞いて、システムを設計するか？

2011/9/9 日立ソリューションズ（南波幸雄） 26

2011/9/9

耐震強度偽装事件(マンションルート)

出典：金箱温春, “Kuramae Journal,” No.993, 2006. をもとに改変

建築主

設計者(建築士)

• 意匠設計者

施工者

売却

監理

報告

購入者

設計者の立場が弱いことが特徴

設計者との直接の対話がない

p.27日立ソリューションズ（南波幸雄）

良く分からないし、興味もないので、丸投げ

• 構造設計者

2011/9/9

アーキテクトの役割Utilitas

ニーズ＝機能発注者の視点

Venustasデザイン

アーキテクト

Firmitas構造

ビルダー

ウィトルウィウスの三角形

p.28日立ソリューションズ（南波幸雄）

要求

要件

誰が両者をつなぐべきか

誰が設計品質を担保すべきか

発注者の想いの明確化＝実世界の構造の把握と共有＝ビジネスアーキテクチャ

の共有

ビジネスビュー

システムビュー

アプリ設計と

インフラ設計との乖離

施工者の役割

要件を情報システムとして完成させる

要求で求められた品質のシステムを、コスト・納期ともに設定値を超えない範囲で完成させる

再構築の場合は、移行して運用できるまで

ここでの留意点に関して、通常のプロジェクトマネジメントで述べられているので割愛

2011/9/9 日立ソリューションズ（南波幸雄） 29

アジャイル開発

複数チーム（並行開発）

他チームのデータモデルの変更が共通エンティティの場合どう対応するか

サブシステムの境界が重なる可能性がある

2011/9/9 日立ソリューションズ（南波幸雄） 30

チームA チームB共通エンティティ

アジャイルといえども全体構造の設計が必用

単一チーム ユーザー要件はユーザーを代表しているか

機能追加によるデータモデルの変更により、他の機能が影響を受ける

まとめ

ソフトウェアプロジェクトの成功と失敗において、品質問題と、コスト・時間の問題は異なる

品質問題にも、設計監理と施工管理に起因する問題がある

情報システムプロジェクトにおいて、設計者の役割が不明なのが問題 アーキテクトの役割の認知が必用

施工管理に関しては、種々の手法があり、適切に使用すれば効果は高い

アジャイル開発のプロジェクトマネジメントに関しては今後の課題

ビジネスビューを明確にし、システムビューにつなぐのがアーキテクトの役割

2011/9/9 日立ソリューションズ（南波幸雄） 31

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

2011/9/9 日立ソリューションズ（南波幸雄） 32