???????????? - PowerPoint by Vqx1x9tO

VIEWS: 45 PAGES: 31

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




                        2001/09/06
     鎌田 真由美 (Mayumi Itakura Kamata)
                D1 @ 玉井研究室
           sq8t-kmt@asahi-net.or.jp
自己紹介

鎌田 真由美
現在 東京大学大学院 広域システム科学専攻 玉
 井研究室 博士課程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サンプル
   インタビュー回数                             計 30 回
   インタビュー対象者数                           計 35 名
   インタ         ク
      ビュー対象プロジェ ト                           ク
                                  計 41 プロジェ ト
   総インタビュー時間                      総計    45 時間

                Mayumi I Kamata                  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.親和図による「開発実施時の困難」把握


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


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


        期間内・遅延含む16プロジェクト
        計146枚のデータカードを作成し
  「小規模システム開発時の困難」について親和図を作成

            Mayumi I Kamata   12
親和図 「小規模システム開発時に困ったこと」
                   要件がなかなか確定しない
  ツールの限界                     要件の変更や
                              追加が多い
   ツール自身の
     障害
                                  もともと要件が
                                  はっきりしない
             プロトタイピング
   ツールの持つ       による
    機能制限       要望増加              ユーザがなかなか
                                   決断しない

                                        ユーザ側の問題
  ユーザ自身で           ユーザとの
                                         ユーザの参画
                 コミュニケーション
  運用ができない           ・ミス                  度合いが低い


   ユーザ自身が        複数ユーザ部門の               ユーザの社内的な
    高機能な          調整に難航                  制約(稟議など)
   システムを希望



                        制約条件の見落とし
   運用体制不備                               ユーザの
              公的規制の見落とし
                                      社内標準の見落とし
2.1 親和図の分析


 期間内・遅延に関わらず、当事者(PM, リーダー)が感じた
      「小規模システム開発における困難」は
         大きく4領域に分類される

 •最も複雑な構造を持つ問題点 “要件がなかなか確定しない”
   – 様々な原因があることを当事者は認識している
 •ツールの限界・制約条件の見落とし

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

             Mayumi I Kamata     14
2.2 PM・リーダーが考える遅延原因


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


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



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


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

        システム環境・技術              要求定義

   種類の多さ     複雑              要件の質
                                                  受容期限
 環境                             明確さ
                                                         追加要件
                                                                小
      本番環境との差  変             外部接続     複数部門                      規
               化
             予測の甘さ
                                                     量          模
                                    実施者                         シ
   パフォーマンス
                                       IT部門 エンドユーザ              ス
             データ量の急増                                            テ
                                                                ム
     不完全なテスト         複数部門が                 実現性                  開
プロジェクト               オーナー                                       発
管理                                     調査                       遅
   見積ミス           決断が遅い
                                             機能                 延
                      体質                          バグ
開発者の                                  態度
モラル低下
                                                         製品情報
             プロジェクト中の           非協力的
             組織変更                                    提供が不十分
 その他                ユーザ自身                開発ツール
2.3 特性要因図の分析


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

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

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




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

                              
                            ¬ K Í V X e J ­ Ì x v ö

  30                                                                                  100.0
                                                                             100.00
           24                                                   91.80
  25

                                                80.33                                 75.0
  20
                                65.57
                           16
  15                                                                                  50.0

                39.34
  10                                        9
                                                            7                         25.0
                                                                         5
   5


   0                                                                                  0.0
         
        v è ` Ö A       ُ
                        J ­ ° Ö A            Z 
                                        ¼½ Ãя« ¥p     Õ° ¤ Ì â è
                                                          »Þ 
                                                                       
                                                                        »Ì ¼          
                                                                                      x 
                                                                                      
                                                                                      Ý Ï %
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(Request for Proposal) を基に方法を模
     索中。 テキストマイニング、各種発見手法 な
     ど
    先行研究リサーチ (要求定義工学分野)

               Mayumi I Kamata           24
現在の研究の状況



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




           Mayumi I Kamata   25
参考: 開発者のスキル

 Relation between developers’ skills and project delay
                               Delay            On-schedule   Total


 Skilled engough                     4                   5           9
                               (44.0%)             (56.0%)      (100%)
 Lack of skills                      4                   3           7
                               (57.0%)             (43.0%)      (100%)
 Total                               8                   8          16
                               (50.0%)             (50.0%)      (100%)
                                                                ( ):Ratio to total
                              この表においては、
                           統計的に開発者のスキルが,
                          プロジェクト遅延に影響していない

                                 Mayumi I Kamata                         26
2. 先行研究


   プロジェクトの品質とは?
    JIS Q 10006, PMBOK等に規格および指針
     [JIS Q10006(ISO10006:1997)]プロジェクトの品質の2つの側面
     プロジェクトプロセスの品質と プロジェクトの製品の品質

   ソフトウェア品質管理一般 [菅野、吉澤 ら]
    システム提供者の視点
    TQC手法 → ソフトウェア製品の品質改善
    事例分析を中心とした深い分析                        プロジェクトの
                                          製品の品質
    参考:ISO/IEC9126にソフトウェア製品の品質特性

                     Mayumi I Kamata               27
1.1 本研究の目的

  グループウェアによる
  業務システム開発プロジェクトの分析
  統計的に分析し、遅延に結びつき易い3つの特徴を明らかにした
    1.要求定義期間・ワークロード
    2.変更管理実施
    3.進化型プロトタイピングの適用


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


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


                        全期間           RD 期間 RD 期間の
                        (週)           (週) 割合(%)
  期    小規模 (N=16)         13.8            5.4   39.1
  間
       中 規 模 以 上             35.7        11.1    31.0
       (N=13)
       小規模/中規模 %             38.7        52.1       -

                      全 WL 平均 RDWL 平均   RDWL の
   ワ                  (時間) (時間) 割合(%)
   ー   小規模 (N=16)         873.7   327.2     37.5
   ク
   ロ   中 規 模 以 上          4073.5       1254.6   30.8
   ー   (N=13)
   ド   小規模/中規模 %             21.4        26.0      -
                    Mayumi I Kamata                     29
7.まとめ

    見落とされがちな変更管理
     遅延プロジェクトでは変更管理が見落とされがち
     期間内プロジェクトでは、新しい変更管理を推進している。
     例 :インターネット等を利用し、限定した項目を管理(超整理法的)

    小規模システム開発に必要なプロジェクト管理スキル
     は?
     変化するIT技術に適応したプロジェクト管理をタイムリーに
     推進することがプロジェクトの明暗を分ける。
     時間・ワークロードの余裕が無いのでリカバリーが困難


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

                        計画時ウォーターフォール(%)         実際にウォーターフォール(%)
   小規模 (N=16)                       62.5                     6.8
   中規模以上 (N=13)                     38.5                     0.0

               ¼½ Ãя³ « À° « ÙÓÃÞ K 
               ¬ K Í   J ­ ÅÌ ° Ì °    ُp ó µ
                                         (N=16)




    v
                     10                       6




    À Û
         1                         15



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

                                                         ° Ì °
                                                      ³ « À° « Ù
                                                         ° Ì °È O
                                                      ³ « À° « ُ
                             Mayumi I Kamata                         31

								
To top