修士論文概要と研究テーマ 2001/09/06 鎌田 真由美 (Mayumi Itakura Kamata) D1 @ 玉井研究室 [email protected] 自己紹介 鎌田 真由美 現在 東京大学大学院 広域システム科学専攻 玉 井研究室 博士課程1年。 &日本IBM（株） サービ ス事業コンピテンシーに所属する社会人学生 1998年-2000年筑波大学大学院にて経営システム科学を 専攻（吉澤研究室）し、無事修了後も課題は解決していない ことに気づき、さらに深く追究したい気持ちになる。 吉澤先 生のアドバイスで、要求定義について研究されている玉井 先生にお世話になることになり、今日に至る。目下の悩み は仕事が忙しすぎてまったく研究が進まないこと。 Mayumi I Kamata 2 本日の発表内容 修士論文概要 現在の研究の状況 現在の状況 本年度の目標 Mayumi I Kamata 3 修士論文概要 < 背 景> IT環境の変化 産業界の変化 メインフレーム → Unix, PC 言語主体開発 → GUI、IDEツール IT部門主体 → エンドユーザ主体 市場変化のスピード化 短期間システム開発への期待 重点分野 絞り込み 小規模システム開発の 適切な開発管理・品質管理を行なうことが 顧客・開発者双方にとって重要 Mayumi I Kamata 4 1.1 研究の目的 現場からの フィードバック 小規模システム開発に 特有な傾向や問題点を 明らかにする 現場への調査を行い実態を把握 小規模で ツールを活用した システム開発 Mayumi I Kamata 5 1.2 調査・分析 1. 調査の目的 小規模システム開発の客観的・数量的特長を把 握する → ヒストグラム、散布図、平均値 2. 調査方法 直接面談方式（インタビュー） 調査内容は「定型的」部分と「インタビュアーの問 いかけに自由に回答する」部分で構成 Mayumi I Kamata 6 1.2 調査・分析（補足） 実施期間：1999年8月～1999年11月 調査方法： 直接面談方式（インタビュー） 定型質問、インタビュアーの問いかけに対して自由回答 対象者 ： 日本アイ・ビー・エムの対象プロジェクトのプロ ジェクト・マネジャー，開発リーダー など 計35名 対象外サンプル，統計処理による外れ値（2σ外）を除去 小規模システム開発プロジェクト数 16サンプル インタビュー回数 インタビュー対象者数 インタビュー対象プロジェクト 総インタビュー時間 Mayumi I Kamata 計 30 回 計 35 名 計 41 プロジェクト 総計 45 時間 7 1.3 対象プロジェクト 顧客の要望に合わせて構築するタイプ 開発ツールは共通してLotus Notesを使用 n=29 (◆ = 16) 期間 →24週間以内 総ワークロード →1800時間以内 プロジェクト中の 人員変動 →小 Mayumi I Kamata 8 1.4 仮説 ① 要求定義作業期間・作業量の占める割合が高い ② ウォーターフォール型が適用されず，実際には連続し た局面である ③ 追加・変更要件とテスト項目に不整合があり、システム テスト時に発見されるフォールトが多い ④ プロジェクト対象部門が複数で、要求定義ではその調 整・交渉に時間がかかる ⑤ GUI, IDEツールを利用した開発では、従来型の変更管 理が機能せず、問題発生につながる Mayumi I Kamata 9 1.5 統計分析データ 要求定義期間 32.56% 48.04% 遅延プロジェクト平均 期間内プロジェクト平均 要求定義ワークロード 305.00時間 349.36時間 遅延プロジェクト平均時間 期間内プロジェクト平均時間 (差のポイント数 -13.56) Mayumi I Kamata 10 1.5 統計分析データ (2) 要求定義対象部門数 （2部門以上の割合） 遅延プロジェクト平均 期間内プロジェクト平均 75.0% 37.5% 変更管理 遅延プロジェクト 8件中 7件(87.5%)が実施せず プロトタイピング 遅延プロジェクト 8件中 4件(50%)が実施せず Mayumi I Kamata 11 2．親和図による「開発実施時の困難」把握 親和図とは… 新QC７つ道具の１つ “混沌事象の明確化と構造化の段階”で有効な手法 小規模システムにおける｢困難」とは？ 当事者の感じている原因とその構造を知る 期間内・遅延含む16プロジェクト 計146枚のデータカードを作成し 「小規模システム開発時の困難」について親和図を作成 Mayumi I Kamata 12 親和図 「小規模システム開発時に困ったこと」 要件がなかなか確定しない ツールの限界 要件の変更や 追加が多い ツール自身の 障害 ツールの持つ 機能制限 もともと要件が はっきりしない プロトタイピング による 要望増加 ユーザがなかなか 決断しない ユーザ側の問題 ユーザ自身で 運用ができない ユーザとの コミュニケーション ・ミス ユーザの参画 度合いが低い ユーザ自身が 高機能な システムを希望 複数ユーザ部門の 調整に難航 ユーザの社内的な 制約（稟議など） 制約条件の見落とし 運用体制不備 公的規制の見落とし ユーザの 社内標準の見落とし 2.1 親和図の分析 期間内・遅延に関わらず、当事者（PM, リーダー）が感じた 「小規模システム開発における困難」は 大きく4領域に分類される •最も複雑な構造を持つ問題点 “要件がなかなか確定しない” – 様々な原因があることを当事者は認識している •ツールの限界・制約条件の見落とし 短期間/限られたワークロード により、 さらに困難に Mayumi I Kamata 14 2.2 PM・リーダーが考える遅延原因 遅延したプロジェクトに特徴的な要因を追究 「遅延」に的を絞り特性要因図を作成 さらに、それらのカテゴリ（矢）の分布状況をパレート図で示す 遅延プロジェクトに特有な 問題・意識はあるのか？ カテゴリ（矢）は、親和図を元に作成する Mayumi I Kamata 15 特性要因図 「小規模システム開発遅延の特性要因図」 ｼｽﾃﾑ環境・技術 種類の多さ 要求定義 複雑 要件の質 受容期限 明確さ 環境 本番環境との差 外部接続 変 化 予測の甘さ 複数部門 量 実施者 パフォーマンス ＩＴ部門 エンドユーザ データ量の急増 不完全なテスト プロジェクト 管理 見積ミス 開発者の ﾓﾗﾙ低下 複数部門が オーナー 実現性 調査 決断が遅い 機能 体質 プロジェクト中の 組織変更 その他 追加要件 ﾕｰｻﾞ自身 態度 バグ 製品情報 非協力的 提供が不十分 開発ﾂｰﾙ 小 規 模 シ ス テ ム 開 発 遅 延 2.3 特性要因図の分析 ほぼ 「小規模システム開発における困難」（親和図） と対応づけられる •要求定義は 遅延・期間内に関わらず難易度の高いプロセス •“プロジェクト管理についての問題意識がある – 見積りミス – 不完全なテスト Mayumi I Kamata 17 パレート図 「小規模システム開発遅延の特性要因図」を基に要因を層別 小規模システム開発の遅延要因 30 100.0 100.00 25 91.80 24 80.33 20 75.0 65.57 16 15 50.0 39.34 9 10 7 5 5 0 要求定義関連 開発ﾂｰﾙ関連 ｼｽﾃﾑ環境･技術 ﾕｰｻﾞ側の問題 その他 25.0 0.0 度数 累積% 2.4 パレート図の分析 特性要因図のカテゴリ（矢）に沿って要因分布を把握 全遅延要因の6割が要求定義と開発ツールに集中 PM 及び リーダーの意識： 小規模システム開発プロジェクトの遅延原因の 60％以上が要求定義と開発ツールに関連 統計データとの比較は？ Mayumi I Kamata 19 2.5 統計分析データ との比較 (1) 要求定義 いくつもの要因で構成される複雑な問題 期間・ワークロードとも十分に必要 • 短期間・限られたワークロードであるため、代替手段・ 選択肢が少なく、遅延に直結しやすい • 現象と当事者の意識が一致しており、対策は取りや すい Mayumi I Kamata 20 2.5 統計分析データ との比較 (2) 変更管理 統計データ上、明白な差異が認められるデータ 遅延プロジェクト当事者の意識と結果に乖離がある （期間内プロジェクトは従来型とは異なる手法を採用） • プロジェクトの成否に関わる差異 • 変更管理についての無自覚さ・軽視 ： 小規模・短期 間だから把握できる という意識 • 収束しない要件変更・追加要件を誘発 Mayumi I Kamata 21 2.5 統計分析データ との比較 (3) プロトタイピング 統計データ上、大きな差異が認められるデータ “要求定義がなかなか収束しない”困難の一部 変更管理実施状況と関連させて考えるべきではないか • 遅延プロジェクトでは プロトタイピング実施率 50％か つ 変更管理実施 約10％ • 期間内プロジェクトではプロトタイピング実施率100％ かつ 変更管理実施率 65％ Mayumi I Kamata 22 3. 仮説の検証結果 <検証された仮説> ① 要求定義後も要件が確定しない。要求定義作業期間・作業量の占め る割合が高い ② ウォーターフォール型が適用されず，連続した局面になる <修正> ④ 要求定義対象部門が多く、その調整・交渉作業が発生する ⑤ GUI, IDEツールを利用した開発では、変更管理が軽視され、遅延に つながる <棄却> ③ 追加要件に関してテスト段階で不整合があり、遅延につながる Mayumi I Kamata 23 現在の研究の状況 テーマ 要求定義段階でのシステム依頼者と開発者・プ ロジェクトマネージャの間のギャップを埋める手 法の研究 現在の研究の状況 RFP(Rｅｑｕｅｓｔ for Proposal) を基に方法を模 索中。 テキストマイニング、各種発見手法 な ど 先行研究リサーチ （要求定義工学分野） Mayumi I Kamata 24 現在の研究の状況 本年度の目標 リサーチ論文作成 有効な手法について実データで検証 （検証方法は…？ 課題） Mayumi I Kamata 25 参考： 開発者のスキル Relation between developers’ skills and project delay 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%) ( ):Ratio to total この表においては、 統計的に開発者のスキルが, プロジェクト遅延に影響していない Mayumi I Kamata 26 2. 先行研究 プロジェクトの品質とは？ JIS Q 10006， PMBOK等に規格および指針 ［JIS Q10006(ISO10006:1997)］プロジェクトの品質の２つの側面 プロジェクトプロセスの品質と プロジェクトの製品の品質 ソフトウェア品質管理一般 ［菅野、吉澤 ら］ システム提供者の視点 TQC手法 → ソフトウェア製品の品質改善 事例分析を中心とした深い分析 参考：ISO/IEC9126にソフトウェア製品の品質特性 Mayumi I Kamata プロジェクトの 製品の品質 27 1.1 本研究の目的 グループウェアによる 業務システム開発プロジェクトの分析 統計的に分析し、遅延に結びつき易い３つの特徴を明らかにした 1．要求定義期間・ワークロード 2．変更管理実施 3．進化型プロトタイピングの適用 本研究では 同じ対象プロジェクトに品質管理手法を適用し 遅延につながる問題の所在を明らかにする Mayumi I Kamata 28 <参考> 分析結果 期 間 ワ ー ク ロ ー ド 要求定義期間・ワークロードは高い割合 全期間 （週） 13.8 小規模 (N=16) 中 規 模 以 上 (N=13) 小規模/中規模 % RD 期間 RD 期間の （週） 割合（%） 5.4 39.1 35.7 11.1 31.0 38.7 52.1 - 全 WL 平均 RDWL 平均 RDWL の （時間） （時間） 割合（%） 873.7 327.2 37.5 小規模 (N=16) 中 規 模 以 上 (N=13) 小規模/中規模 % 4073.5 1254.6 30.8 21.4 26.0 - Mayumi I Kamata 29 7．まとめ 見落とされがちな変更管理 遅延プロジェクトでは変更管理が見落とされがち 期間内プロジェクトでは、新しい変更管理を推進している。 例 ：インターネット等を利用し、限定した項目を管理（超整理法的） 小規模システム開発に必要なプロジェクト管理スキル は？ 変化するIT技術に適応したプロジェクト管理をタイムリーに 推進することがプロジェクトの明暗を分ける。 時間・ワークロードの余裕が無いのでリカバリーが困難 Mayumi I Kamata 30 <参考> 分析結果 ウォーターフォール型で計画 → 適用できず 小規模 (N=16) 中規模以上 (N=13) 計画時ｳｫｰﾀｰﾌｫｰﾙ(%) 62.5 38.5 実際にｳｫｰﾀｰﾌｫｰﾙ(%) 6.8 0.0 小規模ｼｽﾃﾑ開発でのｳｫｰﾀｰﾌｫｰﾙﾓﾃﾞﾙ適用状況 (N=16) プラン 実際 10 6 1 0% 15 20% 40% 60% 80% 100% ｳｫｰﾀｰﾌｫｰﾙ ｳｫｰﾀｰﾌｫｰﾙ以外 Mayumi I Kamata 31
© Copyright 2024 ExpyDoc
