修士論文概要と研究テーマ

2001/09/06鎌田　真由美 (Mayumi Itakura Kamata)

D1 　 @ 　玉井研究室sq8t-kmt@asahi-net.or.jp

Mayumi I Kamata 2

自己紹介

鎌田　真由美現在　東京大学大学院　広域システム科学専攻　玉

井研究室　博士課程 1 年。　 & 日本 IBM （株）　サービス事業コンピテンシーに所属する社会人学生 1998 年 -2000 年筑波大学大学院にて経営システム科学を

専攻（吉澤研究室）し、無事修了後も課題は解決していないことに気づき、さらに深く追究したい気持ちになる。　吉澤先生のアドバイスで、要求定義について研究されている玉井先生にお世話になることになり、今日に至る。目下の悩みは仕事が忙しすぎてまったく研究が進まないこと。

Mayumi I Kamata 3

　本日の発表内容

修士論文概要

　現在の研究の状況現在の状況本年度の目標

Mayumi I Kamata 4

修士論文概要　 < 背 景 >

小規模システム開発の適切な開発管理・品質管理を行なうこと

が顧客・開発者双方にとって重要

メインフレーム → Unix, PC言語主体開発 → GUI 、 IDE ツールIT 部門主体 → エンドユーザ主体

IT 環境の変化

市場変化のスピード化短期間システム開発への期待重点分野 絞り込み

産業界の変化

Mayumi I Kamata 5

1.1 研究の目的

現場への調査を行い実態を把握

小規模システム開発に特有な傾向や問題点を

明らかにする

現場からのフィードバック

小規模でツールを活用した

システム開発

Mayumi I Kamata 6

1.2 　調査・分析

1. 調査の目的 小規模システム開発の客観的・数量的特長を

把握する→ ヒストグラム、散布図、平均値

2. 調査方法 直接面談方式（インタビュー） 調査内容は「定型的」部分と「インタビュ

アーの問いかけに自由に回答する」部分で構成

Mayumi I Kamata 7

1.2 　調査・分析（補足）

実施期間： 1999 年 8月～ 1999 年 11月 調査方法： 直接面談方式（インタビュー）

定型質問、インタビュアーの問いかけに対して自由回答対象者 ： 日本アイ・ビー・エムの対象プロジェクトのプロジェ

クト・マネジャー，開発リーダー など 計35名対象外サンプル，統計処理による外れ値（ 2σ外）を除去 小規模システム開発プロジェクト数 16 サンプル

インタビュー回数 計 30回インタビュー対象者数 計 35名インタビュー対象プロジェクト 計 41プロジェクト総インタビュー時間 総計 45 時間

Mayumi I Kamata 8

1.3　対象プロジェクト

顧客の要望に合わせて構築するタイプ開発ツールは共通して Lotus Notes を使用

期間 →24週間以内総ワークロード →1800時間以内プロジェクト中の人員変動 → 小

n=29( = 16)◆

Mayumi I Kamata 9

1.4　 仮説

① 要求定義作業期間・作業量の占める割合が高い

②ウォーターフォール型が適用されず，実際には連続した局面である

③ 追加・変更要件とテスト項目に不整合があり、システムテスト時に発見されるフォールトが多い

④プロジェクト対象部門が複数で、要求定義ではその調整・交渉に時間がかかる

⑤ GUI, IDEツールを利用した開発では、従来型の変更管理が機能せず、問題発生につながる

Mayumi I Kamata 10

1.5　統計分析データ

要求定義期間遅延プロジェクト平均 32.56% 期間内プロジェクト平均 48.04%

要求定義ワークロード遅延プロジェクト平均時間 305.00時間期間内プロジェクト平均時間 349.36時間

(差のポイント数 -13.56)

Mayumi I Kamata 11

1.5　　統計分析データ (2)

要求定義対象部門数 （ 2 部門以上の割合）遅延プロジェクト平均 75.0% 期間内プロジェクト平均 37.5%

変更管理遅延プロジェクト 8件中 7件 (87.5%) が実施せず

プロトタイピング遅延プロジェクト 8件中 4件 (50%) が実施せず

Mayumi I Kamata 12

2．親和図による「開発実施時の困難」把握

親和図とは… 新 QC７つ道具の１つ“ 混沌事象の明確化と構造化の段階”で有効な手法

小規模システムにおける 困難」とは？｢当事者の感じている原因とその構造を知る

期間内・遅延含む 16プロジェクト計 146枚のデータカードを作成し

「小規模システム開発時の困難」について親和図を作成

ツール自身の障害

ツールの持つ機能制限

ツールの限界

ユーザ自身が高機能な

システムを希望

運用体制不備

ユーザ自身で運用ができない

公的規制の見落とし ユーザの社内標準の見落とし

制約条件の見落とし

要件の変更や追加が多い

プロトタイピングによる

要望増加

ユーザとのコミュニケーション

・ミス

ユーザがなかなか決断しない

もともと要件がはっきりしない

複数ユーザ部門の調整に難航

ユーザの参画度合いが低い

ユーザの社内的な制約（稟議など）

ユーザ側の問題

要件がなかなか確定しない

親和図 「小規模システム開発時に困ったこと」

Mayumi I Kamata 14

2.1 　親和図の分析

期間内・遅延に関わらず、当事者（ PM, リーダー）が感じた

「小規模システム開発における困難」は 大きく 4領域に分類される

•最も複雑な構造を持つ問題点 “要件がなかなか確定しない”

– 様々な原因があることを当事者は認識している•ツールの限界・制約条件の見落とし

短期間 /限られたワークロード により、さらに困難に

Mayumi I Kamata 15

2.2 　 PM ・リーダーが考える遅延原因

遅延したプロジェクトに特徴的な要因を追究「遅延」に的を絞り特性要因図を作成さらに、それらのカテゴリ（矢）の分布状況をパレート図で示す

遅延プロジェクトに特有な問題・意識はあるのか？

カテゴリ（矢）は、親和図を元に作成する

特性要因図 「小規模システム開発遅延の特性要因図」

小規模システム開発遅

延

複数部門

要求定義

追加要件

受容期限

量

要件の質

明確さ

実施者

ＩＴ部門エンドユーザ

開発 ﾂｰﾙ

調査

実現性

機能

提供が不十分

製品情報

バグ

環境・技術ｼｽﾃﾑ

環境

パフォーマンス

種類の多さ 複雑

変化

本番環境との差

データ量の急増

予測の甘さ

外部接続

自身ﾕｰｻﾞ

態度

非協力的

決断が遅い

複数部門がオーナー

体質

プロジェクト中の組織変更

その他

プロジェクト管理

不完全なテスト

見積ミス

開発者の低下ﾓﾗﾙ

Mayumi I Kamata 17

2.3　特性要因図の分析

ほぼ 「小規模システム開発における困難」（親和図）と対応づけられる

•要求定義は 遅延・期間内に関わらず難易度の高いプロセス

•“ プロジェクト管理についての問題意識がある– 見積りミス– 不完全なテスト

パレート図 「小規模システム開発遅延の特性要因図」を基に要因を層別

小規模システム開発の遅延要因

24

16

97

5

80.33

65.57

39.34

91.80

100.00

0

5

10

15

20

25

30

要求定義関連 開発ﾂｰﾙ関連 ｼｽﾃﾑ環境･技術 ﾕｰｻ 側゙の問題 その他0.0

25.0

50.0

75.0

100.0

度数%累積

Mayumi I Kamata 19

2.4　パレート図の分析

特性要因図のカテゴリ（矢）に沿って要因分布を把握全遅延要因の 6割が要求定義と開発ツールに集中

PM 及び リーダーの意識：小規模システム開発プロジェクトの遅延原因の

60％以上が要求定義と開発ツールに関連

統計データとの比較は？

Mayumi I Kamata 20

2.5　統計分析データ との比較 (1)

要求定義いくつもの要因で構成される複雑な問題 期間・ワークロードとも十分に必要

• 短期間・限られたワークロードであるため、代替手段・選択肢が少なく、遅延に直結しやすい

• 現象と当事者の意識が一致しており、対策は取りやすい

Mayumi I Kamata 21

2.5　統計分析データ との比較 (2)

変更管理統計データ上、明白な差異が認められるデータ 遅延プロジェクト当事者の意識と結果に乖離がある（期間内プロジェクトは従来型とは異なる手法を採

用）

• プロジェクトの成否に関わる差異• 変更管理についての無自覚さ・軽視 ： 小規模・短期

間だから把握できる という意識• 収束しない要件変更・追加要件を誘発

Mayumi I Kamata 22

2.5　統計分析データ との比較 (3)

プロトタイピング統計データ上、大きな差異が認められるデータ “要求定義がなかなか収束しない”困難の一部 変更管理実施状況と関連させて考えるべきではない

か

• 遅延プロジェクトでは プロトタイピング実施率 50％かつ 変更管理実施 約 10％

• 期間内プロジェクトではプロトタイピング実施率 100％ かつ 変更管理実施率 65％

Mayumi I Kamata 23

　 3. 　仮説の検証結果

< 検証された仮説 >① 要求定義後も要件が確定しない。要求定義作業期間・作業量の占める割合が高い

② ウォーターフォール型が適用されず，連続した局面になる

<修正>④ 要求定義対象部門が多く、その調整・交渉作業が発生する⑤ GUI, IDEツールを利用した開発では、変更管理が軽視され、遅延につながる

< 棄却 >③ 追加要件に関してテスト段階で不整合があり、遅延につながる

Mayumi I Kamata 24

　現在の研究の状況

テーマ　 要求定義段階でのシステム依頼者と開発者・プロジェ

クトマネージャの間のギャップを埋める手法の研究 現在の研究の状況

RFP(Rｅｑｕｅｓｔ　 for 　 Proposal) 　を基に方法を模索中。　テキストマイニング、各種発見手法　など

先行研究リサーチ　（要求定義工学分野）

Mayumi I Kamata 25

　現在の研究の状況

本年度の目標　 リサーチ論文作成 有効な手法について実データで検証 （検証方法は…？　課題）

Mayumi I Kamata 26

参考： 開発者のスキル

( ):Ratio to total

Delay On-schedule Total

Skilled engough 4(44.0%)

5(56.0%)

9(100%)

Lack of skills 4(57.0%)

3(43.0%)

7(100%)

Total 8(50.0%)

8(50.0%)

16(100%)

Relation between developers’ skills and project delay

この表においては、統計的に開発者のスキルが ,

プロジェクト遅延に影響していない

Mayumi I Kamata 27

ソフトウェア品質管理一般 ［菅野、吉澤 ら］

システム提供者の視点

TQC手法 → ソフトウェア製品の品質改善

事例分析を中心とした深い分析

参考： ISO/IEC9126 にソフトウェア製品の品質特性

2. 先行研究

プロジェクトの品質とは？ JIS Q 10006， PMBOK等に規格および指針 ［ JIS Q10006(ISO10006:1997)］プロジェクトの品質の２つの側面

プロジェクトプロセスの品質と プロジェクトの製品の品質

プロジェクトの製品の品質

Mayumi I Kamata 28

1.1 　 本研究の目的

グループウェアによる業務システム開発プロジェクトの分析

統計的に分析し、遅延に結びつき易い３つの特徴を明らかにした

1．要求定義期間・ワークロード

2．変更管理実施

3．進化型プロトタイピングの適用

本研究では同じ対象プロジェクトに品質管理手法を適用し遅延遅延につながる問題の所在を明らかにする

Mayumi I Kamata 29

<参考 >　分析結果 要求定義期間・ワークロードは高い割合

全期間（週）

RD期間（週）

RD期間の割合（%）

小規模 (N=16) 13.8 5.4 39.1

中 規模以 上(N=13)

35.7 11.1 31.0

小規模 /中規模 % 38.7 52.1 -

全 WL平均（時間）

RDWL平均（時間）

RDWLの割合（%）

小規模 (N=16) 873.7 327.2 37.5

中 規模以 上(N=13)

4073.5 1254.6 30.8

小規模 /中規模 % 21.4 26.0 -

期

間

ワー

クロード

Mayumi I Kamata 30

7 ．まとめ

見落とされがちな変更管理

遅延プロジェクトでは変更管理が見落とされがち

期間内プロジェクトでは、新しい変更管理を推進している。

例 ：インターネット等を利用し、限定した項目を管理（超整理法的）

小規模システム開発に必要なプロジェクト管理スキルは？

変化する IT 技術に適応したプロジェクト管理をタイムリーに

推進することがプロジェクトの明暗を分ける。

時間・ワークロードの余裕が無いのでリカバリーが困難

Mayumi I Kamata 31

<参考 > 　分析結果 ウォーターフォール型で計画 → 適用できず

計画時ｳｫｰﾀｰﾌｫｰﾙ(%) 実際にｳｫｰﾀｰﾌｫｰﾙ(%)小規模 (N=16) 62.5 6.8

中規模以上 (N=13) 38.5 0.0

小規模ｼｽﾃﾑ開発でのｳｫｰﾀｰﾌｫｰﾙ ﾓﾃ ﾙ゙適用状況 (N=16)

1

10

15

6

0% 20% 40% 60% 80% 100%

実際

プラン

ｳｫｰﾀｰﾌｫｰﾙｳｫｰﾀｰﾌｫｰﾙ以外