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

1. 修士論文概要と研究テーマ 2001/09/06 鎌田　真由美 (Mayumi Itakura Kamata) D1@　玉井研究室 sq8t-kmt@asahi-net.or.jp

2. 自己紹介 • 鎌田　真由美 • 現在　東京大学大学院　広域システム科学専攻　玉井研究室　博士課程1年。　&日本IBM（株）　サービス事業コンピテンシーに所属する社会人学生 • 1998年-2000年筑波大学大学院にて経営システム科学を専攻（吉澤研究室）し、無事修了後も課題は解決していないことに気づき、さらに深く追究したい気持ちになる。　吉澤先生のアドバイスで、要求定義について研究されている玉井先生にお世話になることになり、今日に至る。目下の悩みは仕事が忙しすぎてまったく研究が進まないこと。 Mayumi I Kamata

3. 　本日の発表内容 • 修士論文概要 • 　現在の研究の状況 • 現在の状況 • 本年度の目標 Mayumi I Kamata

4. IT環境の変化 産業界の変化 メインフレーム → Unix, PC 言語主体開発 → GUI、IDEツール 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サンプル Mayumi I Kamata

8. 1.3　対象プロジェクト 顧客の要望に合わせて構築するタイプ 開発ツールは共通してLotus Notesを使用 n=29 (◆ = 16) 期間 →24週間以内 総ワークロード →1800時間以内 プロジェクト中の 人員変動 → 小 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

13. 親和図 「小規模システム開発時に困ったこと」 要件がなかなか確定しない 要件の変更や 追加が多い ツールの限界 ツール自身の 障害 プロトタイピング による 要望増加 もともと要件が はっきりしない ツールの持つ 機能制限 ユーザがなかなか 決断しない ユーザ側の問題 ユーザ自身で 運用ができない ユーザとの コミュニケーション ・ミス ユーザの参画 度合いが低い 複数ユーザ部門の 調整に難航 ユーザの社内的な 制約（稟議など） ユーザ自身が 高機能な システムを希望 制約条件の見落とし 運用体制不備 公的規制の見落とし ユーザの 社内標準の見落とし

14. 2.1　親和図の分析 • 期間内・遅延に関わらず、当事者（PM, リーダー）が感じた • 「小規模システム開発における困難」は • 大きく4領域に分類される • 最も複雑な構造を持つ問題点 “要件がなかなか確定しない” • 様々な原因があることを当事者は認識している • ツールの限界・制約条件の見落とし 短期間/限られたワークロード により、 さらに困難に Mayumi I Kamata

15. 2.2PM・リーダーが考える遅延原因 遅延したプロジェクトに特徴的な要因を追究 「遅延」に的を絞り特性要因図を作成 さらに、それらのカテゴリ（矢）の分布状況をパレート図で示す 遅延プロジェクトに特有な 問題・意識はあるのか？ カテゴリ（矢）は、親和図を元に作成する Mayumi I Kamata

16. ｼｽﾃﾑ環境・技術 要求定義 受容期限 複雑 種類の多さ 要件の質 明確さ 環境 追加要件 量 本番環境との差 変化 外部接続 複数部門 予測の甘さ 実施者 小規模システム開発遅延 パフォーマンス ＩＴ部門 エンドユーザ データ量の急増 不完全なテスト プロジェクト 管理 複数部門が オーナー 実現性 見積ミス 調査 決断が遅い 開発者の ﾓﾗﾙ低下 機能 バグ 体質 プロジェクト中の 組織変更 態度 製品情報 非協力的 提供が不十分 その他 ﾕｰｻﾞ自身 開発ﾂｰﾙ 特性要因図 「小規模システム開発遅延の特性要因図」

17. 2.3　特性要因図の分析 • ほぼ 「小規模システム開発における困難」（親和図） • と対応づけられる • 要求定義は 遅延・期間内に関わらず難易度の高いプロセス • “プロジェクト管理についての問題意識がある • 見積りミス • 不完全なテスト Mayumi I Kamata

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

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ｅｑｕｅｓｔ　forProposal)　を基に方法を模索中。　テキストマイニング、各種発見手法　など • 先行研究リサーチ　（要求定義工学分野） Mayumi I Kamata

25. 　現在の研究の状況 • 本年度の目標　 • リサーチ論文作成 • 有効な手法について実データで検証 • （検証方法は…？　課題） Mayumi I Kamata

26. 参考： 開発者のスキル Relation between developers’ skills and project delay ( ):Ratio to total この表においては、 統計的に開発者のスキルが, プロジェクト遅延に影響していない Mayumi I Kamata

27. 2. 先行研究 • プロジェクトの品質とは？ • JIS Q 10006， PMBOK等に規格および指針 • ［JIS Q10006(ISO10006:1997)］プロジェクトの品質の２つの側面 プロジェクトプロセスの品質と プロジェクトの製品の品質 • ソフトウェア品質管理一般 ［菅野、吉澤 ら］ システム提供者の視点 TQC手法 → ソフトウェア製品の品質改善 事例分析を中心とした深い分析 参考：ISO/IEC9126にソフトウェア製品の品質特性 プロジェクトの 製品の品質 Mayumi I Kamata

28. 1.1　 本研究の目的 • グループウェアによる業務システム開発プロジェクトの分析 • 統計的に分析し、遅延に結びつき易い３つの特徴を明らかにした • ．要求定義期間・ワークロード • ．変更管理実施 • ．進化型プロトタイピングの適用 本研究では 同じ対象プロジェクトに品質管理手法を適用し 遅延につながる問題の所在を明らかにする Mayumi I Kamata

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

30. 7．まとめ • 見落とされがちな変更管理 遅延プロジェクトでは変更管理が見落とされがち 期間内プロジェクトでは、新しい変更管理を推進している。 例 ：インターネット等を利用し、限定した項目を管理（超整理法的） • 小規模システム開発に必要なプロジェクト管理スキルは？ 変化するIT技術に適応したプロジェクト管理をタイムリーに 推進することがプロジェクトの明暗を分ける。 時間・ワークロードの余裕が無いのでリカバリーが困難 Mayumi I Kamata

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