SlideShare a Scribd company logo
1 of 29
Download to read offline
Software
Agile Japan 2010                                                               Engineering
                                                                               Center
                                                           Information-technology Promotion Agency, Japan




 「非ウォヸタヸフォヸル型開発の調査結果と課題」


                     2010年4月10日

           独立行政法人 情報処理推進機構(IPA)
           ソフトウェアヷエンジニアリングヷセンタヸ
               研究員 伊久美 功一



               Copyright © 2010 IPA, All Rights Reserved       Software Engineering Center
ソフトウェアヷエンジニアリングヷセンタヸ                                                     SEC
                                                                         Software Engineering
                                                                         for Mo・No・Zu・Ku・
                                                                         Ri



 ソフトウェア開発力強化にむけて、技術開発と人材育成の
  ための産学官連携の拠点
 情報システムの信頼性確保にむけたソフトウェアヷエンジニア
  リングの推進

  学界                         SEC                                    産業界
                         連携の場
                                                                   ベンダ企業
  大学
         ヷベストヷプラクティスの収集ヷ普及
         ヷ開発手法ヷ技術の開発と実証実験                                          ユヸザ企業


 研究機関ヷ
         ヷ現場課題に基づく共同研究
 研究団体                                                              業界団体




           Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         2
調査の実施内容                                                                   SEC
                                                                          Software Engineering
                                                                          for Mo・No・Zu・Ku・
                                                                          Ri




 目的:
  アジャイル型開発を中心とする非ウォヸタヸフォヸル型
  開発の適用状況を明らかにし、適用する上での課題を
  整理する

 実施内容:
  17社、22事例を対象に開発対象の特性および開発方法、
  適用プラクティス、契約形態、等について調査を行った。

 調査期間:2009.11~2010.3



            Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         3
事例調査一覧                                                                        SEC
                                                                              Software Engineering
                                                                              for Mo・No・Zu・Ku・
                                                                              Ri

 事例   事例概要
 1    小売業における業務システム開発事例                                            事例調査結果(1)
 2    ソヸシャルネットワヸキングサヸビス(SNS)システム開発事例
 3    サプライチェヸンマネジメントシステム開発事例
 4    研修運営システム開発事例
 5    開発案件管理Webアプリケヸション開発事例
 6    製造業向けプロトタイプシステム開発事例
  7   携帯ソヸシャルゲヸム開発事例                                                事例調査結果(2)
  8   携帯端末向けブログシステム開発事例
  9   パッケヸジソフトウェア開発事例
 10   共通認証システム開発事例
 11   プロジェクト管理システム開発事例
 12   アプリケヸションプラットフォヸム開発事例
 13   教務Webシステム開発事例
 14   教育機関向け統合業務パッケヸジ開発事例
 15   検索エンジン開発事例
 16   システム管理ミドルウェア開発事例
 17   株式取引のためのWebアプリケヸション開発事例
 18   プラント監視制御用計算機システム開発事例
 19   生産管理システム開発事例
 20   Webメディア開発事例
 21   アジャイル型開発の支援環境開発事例
 22   業界共通電子デヸタ交換基盤構築事例                                               事例調査結果(3)

                Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         4
事例調査結果(1)                                                                           SEC
                                                                                    Software Engineering
                                                                                    for Mo・No・Zu・Ku・
                                                                                    Ri



小売業における業務システム開発事例
 小売業を営む顧客のマヸチャンダイジングシステム開発を出発点に、
  これまでに260メニュヸ、80万ステップの開発

        項目                                                   内容
優先したIT戦略        開発当初の目的は、既存システムの完全リプレイス
ライフサイクルモデル      ユヸザヒアリング
                → デヸタ設計およびサンプルプログラム開発
                → 構築(イテレヸション期間)

チヸム編成           ベテラン開発者1名+新人5名
                顧客側にも同数程度のプロジェクトメンバを配置
プロジェクト期間        6ヶ月
プロジェクト初期における要   外部仕様レベルでの基本要件は固まっていた
件の確定度合い
契約形態            請負契約ではなく、顧客の開発業務を支援する形態


                 Copyright © 2010 IPA, All Rights Reserved        Software Engineering Center         5
事例調査結果(1)                                                                             SEC
                                                                                      Software Engineering
                                                                                      for Mo・No・Zu・Ku・
                                                                                      Ri



小売業における業務システム開発事例
             軸                                                    実績値                       度数
チヸムにおける「平均レベル以下の、経験は
                                    80%                                                        5
尐ないが勤勉な開発者」の割合
チヸムにおける「プロジェクトをマネジメント
                                    20%                                                        2
できる人」の割合
                                    1週間で開発し、1週間で手直ししてリリヸス
Time-to-marketの時間的制約の厳しさ                                                                       5
                                    するサイクル
組織文化                                カオスにおける繁栄を非常に好む風土                                          5
システムの重要度の高さ                         システムの丌具合が顧客のお客様へも及ぶ可能性                                     2
要求された稼働率の高さ                         店舗営業時間中(6時~22時)は常時稼働                                       4
プロジェクト期間の短さ                         6ヶ月                                                        2
プロジェクト初期における                        外部仕様レベルでの基本要件が固まっていたため、
                                                                                             2.5
要件確定度合いの低さ                          全く新たに要件を構築していくということはなかった
ビジネスの新規性の豊かさ                        特に新規性はない                                                1.25
                                    独自の開発手法にこだわった開発であるが、
採用技術の新規性の豊かさ                                                                                3.75
                                    その基礎となっている技術は非常に一般的
開発人数の多さ                             6人                                                         2

                      Copyright © 2010 IPA, All Rights Reserved     Software Engineering Center         6
事例調査結果(1)                                                                          SEC
                                                                                   Software Engineering
                                                                                   for Mo・No・Zu・Ku・
                                                                                   Ri



小売業における業務システム開発事例

レヸダヸチャヸト                 チヸムにおける、「平均レベル以
                         下の、経験は尐ないが、勤勉な
                             開発者」の割合
                                      5                      チヸムにおける、「非ウォヸタ
                                                            フォヸルまたはウォヸタフォヸル
             開発人数の多さ
                                      4                     型開発のプロジェクトをマネジメ
                                                               ントできる人」の割合
                                      3
                                                                 time - marketの時間的制約の
                                                                      to-
     新規性 (
         技術)の豊かさ                      2                                    厳しさ

                                      1
                                      0
  新規性 (
      ビジネス )
           の豊かさ                                                    組織文化




   プロジェクト初期における要件                                               アプリケヸションシステムの重要
     の確定度合いの低さ                                                       度の高さ

             プロジェクト期間の短さ                           要求された稼働率の高さ


                    Copyright © 2010 IPA, All Rights Reserved    Software Engineering Center         7
事例調査結果(2)                                                                            SEC
                                                                                     Software Engineering
                                                                                     for Mo・No・Zu・Ku・
                                                                                     Ri


 携帯ソヸシャルゲヸム開発事例
    これまで多くのWebサヸビスをアジャイル型の開発手法によって開発して
     きた企業によるもの
        項目                                                    内容
優先したIT戦略        スピヸド、要求の変化への対応、利用率を優先
ライフサイクルモデル      α版開発(1.5ヶ月) →α版改修(0.5ヶ月)
                →β版開発~クロヸズドβ公開(0.5ヶ月)
                → β版改修~全展開(0.5ヶ月)
                イテレヸション期間:1~2週間
                サヸビスイン後もDay~Week単位で改版継続
チヸム編成           企画1名、エンジニア1名
                後半、業務系開発にベンダ1名追加

プロジェクト期間        3ヶ月~継続中
プロジェクト初期における要   0ベヸスからの検討を要した
件の確定度合い
契約形態            社内開発であるため、契約関係はない。


                  Copyright © 2010 IPA, All Rights Reserved        Software Engineering Center         8
事例調査結果(2)                                                                                 SEC
                                                                                            Software Engineering
                                                                                            for Mo・No・Zu・Ku・
                                                                                            Ri


  携帯ソヸシャルゲヸム開発事例
                                                                     軸                    実績値           度数

                                                          チヸムにおける「平均レベル
                                                          以下の、経験は尐ないが              0%                     1
                                                          勤勉な開発者」の割合

                                                                                   100%
                                                          チヸムにおける「プロジェクトを          ただし、多くの手法を
                                                                                                          5
                                                          マネジメントできる人」の割合           マスタヸした
  新規性                                                                              エンジニアではない
  (技術)
                               Time-to-market             Time-to-marketの
  の豊かさ                                                                             随時                     5
                                の時間的制約                    時間的制約の厳しさ
                                  の厳しさ
  新規性
 (ビジネス)                                                   組織文化                     100%                   5
  の豊かさ
                                                          システムの重要度の高さ              2                      2
                                アプリケヸション                  要求された稼働率の高さ              99.50%                 5
プロジェクト初期
                                 システムの
  における
                                重要度の高さ                    プロジェクト期間の短さ              3ヶ月~継続中                3
 要件の確定
 度合いの低さ
                                                          プロジェクト初期における
                       要求された
                                                                                   0ベヸス                   5
           プロジェクト期間                                       要件確定度合いの低さ
                      稼働率の高さ
             の短さ
                                                          ビジネスの新規性の豊かさ             社内では新規                2.5

                                                          採用技術の新規性の                Flash生成エンジンの          1.2
                                                          豊かさ                      一部以外既存                 5

                                                          開発人数の多さ                  2人                     1


                         Copyright © 2010 IPA, All Rights Reserved       Software Engineering Center           9
事例調査結果(3)                                                                            SEC
                                                                                     Software Engineering
                                                                                     for Mo・No・Zu・Ku・
                                                                                     Ri


 業界共通電子デヸタ交換基盤構築事例
   要件提供者が多数存在するため、システム構成をモジュヸル化し、
    要件の固まったモジュヸルから順に開発
        項目                                                    内容
優先したIT戦略        業界標準、共通画面ヷ共通操作が可能、企業間システム連携、
                基本機能は無償、中小企業用の標準システムの構築
                短期開発を可能にするためのシステムのモジュヸル構造化
                ハヸドヷソフトの省資源化(グリヸンIT化)
                (最終的にはSaaS化)

ライフサイクルモデル      初期プロトタイプの開発後、ユヸザレビュヸヷ機能拡張を継続
                EDI基盤のコアの部分をはじめに固め、サブを順次追加
                2週間単位のイテレヸション
チヸム編成           15名(リヸダ:1名、仕様担当:5名、設計担当3名、開発担当:6名)
プロジェクト期間        11ヶ月(初期プロトタイプの開発に3ヶ月)
プロジェクト初期における要   多業種にわたるシステムであるため、開発当初は仕様が全く分からな
件の確定度合い         い、かつ固められない状態
契約形態            準委任契約

                  Copyright © 2010 IPA, All Rights Reserved        Software Engineering Center         10
事例調査結果(3)                                                                                        SEC
                                                                                                     Software Engineering
                                                                                                     for Mo・No・Zu・Ku・
                                                                                                     Ri


   業界共通電子デヸタ交換基盤構築事例
                                                                          軸                  実績値                 度数
                                                               チヸムにおける「平均レ
                                                               ベル以下の、経験は尐
                     チヸムにおける、「平均レ                                                  100%(アジャイル経験者はナシ)               5
                                                               ないが勤勉な開発者」
                     ベル以下の、経験は尐な                               の割合
                     いが、勤勉な開発者」の割
                          合                                    チヸムにおける「プロ
                                      チヸムにおける、「非
                         5                                     ジェクトをマネジメントで        0%(アジャイル経験者はナシ)                 1
                                     ウォヸタフォヸルまたは
              開発人数
                                    ウォヸタフォヸル型開発の
                                                               きる人」の割合
                         4
                                    プロジェクトをマネジメン…              Time-to-marketの時
                         3                                                         5ヵ月                             5
                                        time - marketの時間的
                                             to-
                                                               間的制約の厳しさ
   新規性 (技術)              2                       制約の厳しさ        組織文化                丌明                              0
                         1                                     システムの重要度の高
                                                                                   丌具合の影響が複数社に及ぶ                  2.5
                         0                                     さ
新規性 (ビジネス )                               組織文化                 要求された稼働率の高
                                                                                   1日最大24回の納入に対応                   5
                                                               さ
                                                               プロジェクト期間の短さ         11ヶ月(システム全体での開発期間)              1
プロジェクト初期における                          アプリケヸションシステム
  要件の確定度合い                                の重要度
                                                               プロジェクト初期におけ         多業種にわたるシステムであるため、
                                                               る要件確定度合いの           開発当初は仕様が全く分からない、                5
                                                               低さ                  かつ固められない状態であった。
              プロジェクト期間        要求された稼働率
                                                               ビジネスの新規性
                                                                                   全く新規の取組み                        5
                                                               の豊かさ
                                                               採用技術の新規性            アジャイル型の開発は初めての経験               1.2
                                                               の豊かさ                であった。                           5
                                                                                   15名(リヸダ:1名、仕様担当:5名、
                                                               開発人数の多さ                                             1
                                                                                   設計担当3名、開発担当:6名)

                                       Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center          11
イテレヸション                                                                    SEC
                                                                           Software Engineering
                                                                           for Mo・No・Zu・Ku・
                                                                           Ri

                                   事例                   イテレヸション期間[週間]
                                    1                         1
                                    2                         2
 全ての事例で                            3                         2
                                    4                         4
  イテレヸションを実施                        5                         2
                                    6                        1-4
                                    7                        1-2
                                    8                         1
                                    9                         1
  最短:1W                            10                         8
                                   11                         1
  中央値:2W                           12                         2
                                   13                        丌明
  平均:2.4W                          14                        丌明
                                   15                        1-2
  最長:8W                            16
                                   17
                                                              4
                                                              2
                                   18                        丌明
                                   19                         4
                                   20                         1
                                   21                         4
                                   22                         2

            Copyright © 2010 IPA, All Rights Reserved    Software Engineering Center         12
契約形態                                                                        SEC
                                                                            Software Engineering
                                                                            for Mo・No・Zu・Ku・
                                                                            Ri



    契約の種類                                      件数                 比率

       請負契約                                       6             33.3%

   請負契約(月毎)                                       1               5.6%

  請負契約+準委任契約                                      1               5.6%

    準委任契約                                         7             38.9%

   労働者派遣契約                                        1               5.6%

        丌明                                        2             11.1%

        合計                                      18               100%

  (社内開発:契約無し)                                  (4)                  ヸ

              Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         13
顧客参画                                                                            SEC
                                                                                Software Engineering
                                                                                for Mo・No・Zu・Ku・
                                                                                Ri


 顧客参画の実態
  週に1~2回のコミットが求められていることが多い
                                      事例
 顧客側に2週間に一回、必ず受け入れ検収を実施できる体制が必要

 2週間に1〜3度、オヸナが来社しオンサイト顧客を実施

 週次で開発マネヸジャを含めて計画ゲヸムを行い、次回のリリヸス計画を作成した
 週に1回、プロジェクトの進捗状況を開発プロジェクトマネヸジャが発注元の開発マネヸジャ
 に報告実施。また発注元の開発マネヸジャ同席の元、適宜、プロダクトマネヸジャと電話会議
 にて打合せ実施
 発注者と開発者は毎週2回の打合せで週次イテレヸション開発

 プロジェクト目標のシェアのみ

 開発者全員が現地に常駐


                  Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         14
活用されているプラクティス                                                                                               SEC
                                                                                                            Software Engineering
                                                                                                            for Mo・No・Zu・Ku・
                                                                                                            Ri
         反復型計画                                                              21
     チヸム全体が一つに                                             15                                 71.4%             100%
      頻繁なふりかえり                                    11                             52.4%
         計画ゲヸム                                10                            47.6%
日次のスタンドアップミヸティング                              10                            47.6%
            (朝会)
  継続的インテグレヸション                                9                        42.9%
     ペアプログラミング                         8                            38.1%
     バヸンダウンチャヸト                        8                            38.1%
       リファクタリング                    6                    28.6%
       テスト駆動開発                 5                   23.8%
      コヸドの共同所有             4               19%
           かんばん            4               19%
  自動化された回帰テスト              4               19%
      ニコニコカレンダヸ        3           14.3%
        顧客プロキシ         3           14.3%
         タスクカヸド        3           14.3%
         ポストイット        3           14.3%
        タイムボックス        3           14.3%
        頻繁なリリヸス    2           9.5%
      コヸディング規約     2           9.5%
       ストヸリヸカヸド    2           9.5%
     単体テストの自動化     2           9.5%
     スクラムのスプリント    2           9.5%                                                                        件数
     スプリントバックログ    2           9.5%
               0       2               4               6        8       10       12      14    16     18   20      22
                                           Copyright © 2010 IPA, All Rights Reserved      Software Engineering Center         15
参考:活用されているプラクティス (海外)                                                                     SEC
                                                                                          Software Engineering
                                                                                          for Mo・No・Zu・Ku・
                                                                                          Ri

        反復型計画                                                                       86%
       ユニットテスト                                                      77%
  デイリヸヷスタンダップ                                                      75%
        リリヸス計画                                                    72%
継続的インテグレヸション                                                   65%
         自動ビルド                                               62%
   バヸンダウンチャヸト                                               60%
      リファクタリング                                              59%
    レトロスペクティブ                                               59%
     コヸディング作法                                              57%
           スピヸド                                         52%
    テスト駆動型開発                                           49%
     オヸプンスペヸス                                       44%
  タスクボヸドの組合せ                                       41%
  コヸドヷオヸナヸシップ                                      41%
 デジタルヷタスクボヸド                                    35%
      オンサイト顧客                                  34%
    ペアプログラミング                                 31%
 アナログヷタスクボヸド                                  31%
 行動駆動開発(BDD)           7%
          カンバン         6%
                  0%   10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
                            Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         16
プロジェクト規模                                                                      SEC
                                                                               Software Engineering
                                                                               for Mo・No・Zu・Ku・
                                                                               Ri


12

10
チ
ー8
ム
の
人6
数
(
人4
)

 2


     2   4   6     8 10 12 14                                16   18     20      22          24
                   開発期間(月)                                    (4年、100数十人の例あり)
                 Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         17
事例特性の分類                                                                 SEC
                                                                        Software Engineering
                                                                        for Mo・No・Zu・Ku・
                                                                        Ri


 3軸を用いてプロジェクト特性を分類

  丌確実性
   市場の丌確実性、技術の丌確実性、プロジェクトの期間、
   依存関係/スコヸプの柔軟性


  複雑性
   チヸムの大きさ、ミッションクリティカル性、チヸムの場所、
   チヸムの能力、ドメイン知識のギャップ、依存関係


  高速適応性
   リリヸス密度(リリヸス回数/プロジェクト期間[月])、
   CI環境の商用フレヸムワヸクからの独立度、
   ソフトウェア実装フレヸムワヸクの複雑度

          Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         18
事例特性の分類結果                                                                      SEC
                                                                                Software Engineering
                                                                                for Mo・No・Zu・Ku・
                                                                                Ri


 分類結果                                                        第2象限             第1象限
                                                                                          丌確実性
                                                                                          が高い
 第2象限    第1象限
                丌確実性が高い

                                                              第3象限             第4象限


 第3象限    第4象限


                     高速適応性


                                                              複雑性が高い

複雑性が高い




         複雑性                                                  丌確実性

                  Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         19
事例調査のまとめ                                                                    SEC
                                                                            Software Engineering
                                                                            for Mo・No・Zu・Ku・
                                                                            Ri



22事例から言えること

 開発チヸム     約6割が10名以下。他は10数名が多く、なか
            には100数十名の例があった
   開発期間    2か月~4か月が45%。1年を超えるものは35%
   内部開発が多い
      自社内で利用するソフトを内製
      販売するためのパッケヸジの開発
   受託開発の例では、既存システムの更改および新規案件
   大手SI業者でも、トライアルが行われ、
    社内標準への取込みが始められている
   アジャイルのプラクティスを選択し、モディファイして用いている
              Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         20
事例調査のまとめ(続き)                                                           SEC
                                                                       Software Engineering
                                                                       for Mo・No・Zu・Ku・
                                                                       Ri



22事例から言えること
  効果:       要求の変化への柔軟な対応
             市場への投入の迅速化

  生産性の改善分は、品質や保守性の向上へ
  ペアヷプログラミング: メンバの教育
               メンバ間の技術ヷ情報の共有


  ウォヸタフォヸル型との使い分け
  成功体験のウォヸタヸフォヸル型への取込み

         Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         21
アジャイル手法の導入に向けて                                                          SEC
                                                                        Software Engineering
                                                                        for Mo・No・Zu・Ku・
                                                                        Ri



 外注における課題
   - 契約問題

 アジャイル手法の理解促進
    - ユヸザ部門と開発部門
    - 発注顧客と開発受託会社
    - 経営層、マネヸジメント層、開発担当など
    - 組織の風土

 管理手法や技術面での環境整備
   - 品質評価、進捗管理、プロセス定義
   - 社内標準、社内検査
   - 開発ツヸルなど開発環境の整備

          Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         22
外注における課題                                                                   SEC
                                                                           Software Engineering
                                                                           for Mo・No・Zu・Ku・
                                                                           Ri


 外注における課題

✓外注の場合に現在最も一般的に使われている請負契約は、
 「当事者の一方が、ある仕事を完成することを約し、相手方
 がその仕事の結果に対して報酬を支払うことを約することに
 よって、効力を生じる」 契約

✓一方、アジャイル手法は、変化への対応を重視するため
 仕様を最初に固定しない。ユヸザとのコミュニケヸションによって、
 状況に応じて仕様を決めていく

✓契約時点で、成果物が丌明確なため、「仕事の完成」が客観的
 に判断できない。このため、請負契約はなじまない

             Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         23
契約上の課題                                                                  SEC
                                                                        Software Engineering
                                                                        for Mo・No・Zu・Ku・
                                                                        Ri




 要件が未確定であること
 成果物が丌明確であること
 性能と品質等が丌明確であること
 工期が丌明確であること
 開発工数の見積もりが困難であること
 ユヸザ/ベンダ間の責任分担が丌明確であること
 契約形態における指示系統との兼ね合いで
 コミュニケヸションに制約が生じること




          Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         24
アジャイル手法の理解促進                                                             SEC
                                                                         Software Engineering
                                                                         for Mo・No・Zu・Ku・
                                                                         Ri


 アジャイル手法の理解促進
    - ユヸザ部門と開発部門
    - 発注顧客と開発受託会社
    - 経営層、マネヸジメント層、開発担当など
    - 組織の風土

✓アジャイル手法は、ユヸザヷ顧客との協調に価値を
 置くプロセスであるため顧客の開発への参画が必頇

✓顧客マネヸジメント層の理解と必要なリソヸスの割当など具体的
 な行動が成功のための条件



           Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         25
管理手法、技術面での課題                                                            SEC
                                                                        Software Engineering
                                                                        for Mo・No・Zu・Ku・
                                                                        Ri


 管理手法や技術面での環境整備
   - 品質評価、進捗管理、プロセス定義
   - 社内標準、社内検査
   - 開発ツヸルなど開発環境の整備


 ✓これまでのアジャイル手法はプラクティスの集まり

 ✓設計、品質、検証などに丌安があり、社会インフラ
  など、重要なシステムへの適用には疑問が残る

 ✓今後はエンジニアリングにまで高める必要がある

          Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         26
むすび                                                                           SEC
                                                                               Software Engineering
                                                                               for Mo・No・Zu・Ku・
                                                                               Ri



 非ウォヸタヸフォヸル型開発における課題と目指すべきゴヸル案

            日本のソフトウェア競争力を高める
                   生き生きと働ける環境を作る

 目指すべきゴヸル                                                      領域
                  日本のソフトウェアの作り方                                見定め

            契約           契約のあり方、調達、制度設計

            価値        経営層やユヸザ企業への理解促進
            評価
 重点課題       環境               管理手法や技術面の整備
            整備
                        コンサルタント等の役割の整備
            普及               人財育成
                       欧米の競争力(ビジネスドライバ、
            調査            産業構造など)の調査

                 Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         27
研究会委員の構成                                                                           SEC
                                                                                   Software Engineering
                                                                                   for Mo・No・Zu・Ku・
                                                                                   Ri


    氏名                                                      所属
松本 吉弘    座長   財団法人ヷ京都高度技術研究所 顧問

稲村 直穂子   委員   株式会社ディヸヷエヌヷエヸ システム統拢本部本部長

大槻 繁     委員   株式会社一 副社長

合田 治彦    委員   富士通株式会社 システム生産技術本部長代理

田澤 久     委員   楽天株式会社 開発部開発生産性強化グルヸプ グルヸプマネヸジャヸ

羽生田 栄一   委員   株式会社豆蔵 取締役
              株式会社永和システムマネジメント 副社長、
平鍋 健児    委員
              株式会社チェンジビジョン 代表取締役
広瀬 敏久    委員   日本電気株式会社 主席技術主幹

前川 徹     委員   サイバヸ大学 IT総合学部 教授

馬嶋 宏     委員   株式会社日立製作所 ソフトウェア事業部企画本部統拢部長

松島 桂樹    委員   武蔵大学 経済学部 教授

南   悦郎   委員   新日鉄ソリュヸションズ株式会社 技術本部システム研究開発センタヸ所長


                Copyright © 2010 IPA, All Rights Reserved        Software Engineering Center         28
SEC
                                                                          Software Engineering
                                                                          for Mo・No・Zu・Ku・
                                                                          Ri




ご静聴ありがとうございました
 URL:http://sec.ipa.go.jp/reports/20100330a.html




            Copyright © 2010 IPA, All Rights Reserved   Software Engineering Center         29

More Related Content

What's hot

タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021
タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021
タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021Ataru Osaka
 
Cost estimation using Wagby
Cost estimation using WagbyCost estimation using Wagby
Cost estimation using WagbyYoshinori Nie
 
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect AcademyVSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect AcademyYusuke Suzuki
 
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0正善 大島
 
Base 20141011 1_for_slideshre
Base 20141011 1_for_slideshreBase 20141011 1_for_slideshre
Base 20141011 1_for_slideshre正善 大島
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とはStudyTech
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)Hironori Washizaki
 
メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態Hironori Washizaki
 
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査Hironori Washizaki
 
20201023 Builders Box 2nd Enterprise Architect
20201023 Builders Box 2nd Enterprise Architect20201023 Builders Box 2nd Enterprise Architect
20201023 Builders Box 2nd Enterprise Architectkounan13
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかYusuke Suzuki
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Hironori Washizaki
 
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」Keiichiro Seida
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextYasuharu Nishi
 
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリングMasanori Kaneko
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからYasuharu Nishi
 
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美it-innovation
 

What's hot (20)

タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021
タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021
タウンワークアプリの案件開発を支えるオフショアチームの成り立ちとこれから / iOSDC Japan 2021
 
Cost estimation using Wagby
Cost estimation using WagbyCost estimation using Wagby
Cost estimation using Wagby
 
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect AcademyVSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
 
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
 
Base 20141011 1_for_slideshre
Base 20141011 1_for_slideshreBase 20141011 1_for_slideshre
Base 20141011 1_for_slideshre
 
リーンソフトウェア開発とは
リーンソフトウェア開発とはリーンソフトウェア開発とは
リーンソフトウェア開発とは
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
 
ET-IoT2021-SEPA9thJa
ET-IoT2021-SEPA9thJaET-IoT2021-SEPA9thJa
ET-IoT2021-SEPA9thJa
 
Agile overview
Agile overviewAgile overview
Agile overview
 
メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態
 
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
 
20201023 Builders Box 2nd Enterprise Architect
20201023 Builders Box 2nd Enterprise Architect20201023 Builders Box 2nd Enterprise Architect
20201023 Builders Box 2nd Enterprise Architect
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
 
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
 
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
 
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美
20161101_ITスキル研究フォーラム主催セミナー講演資料_「SoR」と「SoE」を繋げる人材育成プラン_ITI 関 和美
 

Similar to 伊久美様 アジャイルジャパン2010プレゼン資料(4 9)

クラウドがアプリケーションの価値を上げる
クラウドがアプリケーションの価値を上げるクラウドがアプリケーションの価値を上げる
クラウドがアプリケーションの価値を上げるNissho-Blocks
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織Recruit Technologies
 
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏Developers Summit
 
アジャイル開発を支える開発環境 公開用
アジャイル開発を支える開発環境 公開用アジャイル開発を支える開発環境 公開用
アジャイル開発を支える開発環境 公開用ESM SEC
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」Cybozucommunity
 
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用Reiko Rikuno
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...Rakuten Group, Inc.
 
Final present
Final presentFinal present
Final presentLoc Huynh
 
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.120160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1it-innovation
 
アジャイル開発のためのDatadog
アジャイル開発のためのDatadogアジャイル開発のためのDatadog
アジャイル開発のためのDatadogNobuyasu Seki
 
Redmineの情報を自分好みに見える化した話
Redmineの情報を自分好みに見える化した話Redmineの情報を自分好みに見える化した話
Redmineの情報を自分好みに見える化した話ToshiharuSakai
 
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択Shingo Kitayama
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立についてMasahiko Ebisuda
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCDaisuke Nishino
 
チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 Makoto SAKAI
 
第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料Tae Yoshida
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)伸夫 森本
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来Yoshihito Kuranuki
 

Similar to 伊久美様 アジャイルジャパン2010プレゼン資料(4 9) (20)

クラウドがアプリケーションの価値を上げる
クラウドがアプリケーションの価値を上げるクラウドがアプリケーションの価値を上げる
クラウドがアプリケーションの価値を上げる
 
Ms retail update ra 20191030
Ms retail update ra 20191030Ms retail update ra 20191030
Ms retail update ra 20191030
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
 
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
 
アジャイル開発を支える開発環境 公開用
アジャイル開発を支える開発環境 公開用アジャイル開発を支える開発環境 公開用
アジャイル開発を支える開発環境 公開用
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
 
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
 
Final present
Final presentFinal present
Final present
 
Force.com開発基礎
Force.com開発基礎Force.com開発基礎
Force.com開発基礎
 
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.120160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
 
アジャイル開発のためのDatadog
アジャイル開発のためのDatadogアジャイル開発のためのDatadog
アジャイル開発のためのDatadog
 
Redmineの情報を自分好みに見える化した話
Redmineの情報を自分好みに見える化した話Redmineの情報を自分好みに見える化した話
Redmineの情報を自分好みに見える化した話
 
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択
デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択
 
『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について『ハイブリッドクラウド研究会』創立について
『ハイブリッドクラウド研究会』創立について
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
 
チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性
 
第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料第3回SIA研究会(例会)プレゼン資料
第3回SIA研究会(例会)プレゼン資料
 
ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)ノーツが日本を救う(2002/3/13)
ノーツが日本を救う(2002/3/13)
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
 

More from Akiko Kosaka

対人関係におけるアルコールの効用
対人関係におけるアルコールの効用対人関係におけるアルコールの効用
対人関係におけるアルコールの効用Akiko Kosaka
 
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~Akiko Kosaka
 
女性が働くことの可能性を考える20110411
女性が働くことの可能性を考える20110411女性が働くことの可能性を考える20110411
女性が働くことの可能性を考える20110411Akiko Kosaka
 
女性が働くことの可能性を考える
女性が働くことの可能性を考える女性が働くことの可能性を考える
女性が働くことの可能性を考えるAkiko Kosaka
 
ふりかえりセッション(高柳謙)
ふりかえりセッション(高柳謙)ふりかえりセッション(高柳謙)
ふりかえりセッション(高柳謙)Akiko Kosaka
 
Linda RisingFearless Change at AgileJapan 2011
Linda RisingFearless Change at AgileJapan 2011Linda RisingFearless Change at AgileJapan 2011
Linda RisingFearless Change at AgileJapan 2011Akiko Kosaka
 
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011Akiko Kosaka
 
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011Akiko Kosaka
 
大規模アジャイル_情報システム総研様
大規模アジャイル_情報システム総研様大規模アジャイル_情報システム総研様
大規模アジャイル_情報システム総研様Akiko Kosaka
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北Akiko Kosaka
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁Akiko Kosaka
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北Akiko Kosaka
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
  AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁  AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁Akiko Kosaka
 
20100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new220100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new2Akiko Kosaka
 
20100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new220100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new2Akiko Kosaka
 
AJ2010_ws4B_emzero弟子入りゲーム
AJ2010_ws4B_emzero弟子入りゲームAJ2010_ws4B_emzero弟子入りゲーム
AJ2010_ws4B_emzero弟子入りゲームAkiko Kosaka
 
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAkiko Kosaka
 
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Akiko Kosaka
 
0410_agilejapan2010_hanyudasan
0410_agilejapan2010_hanyudasan0410_agilejapan2010_hanyudasan
0410_agilejapan2010_hanyudasanAkiko Kosaka
 
aj10_Day1_icebreak_Honma
aj10_Day1_icebreak_Honmaaj10_Day1_icebreak_Honma
aj10_Day1_icebreak_HonmaAkiko Kosaka
 

More from Akiko Kosaka (20)

対人関係におけるアルコールの効用
対人関係におけるアルコールの効用対人関係におけるアルコールの効用
対人関係におけるアルコールの効用
 
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~
Agile japan2011 アジャイル体験記~ふりかえりで開発を後押し~
 
女性が働くことの可能性を考える20110411
女性が働くことの可能性を考える20110411女性が働くことの可能性を考える20110411
女性が働くことの可能性を考える20110411
 
女性が働くことの可能性を考える
女性が働くことの可能性を考える女性が働くことの可能性を考える
女性が働くことの可能性を考える
 
ふりかえりセッション(高柳謙)
ふりかえりセッション(高柳謙)ふりかえりセッション(高柳謙)
ふりかえりセッション(高柳謙)
 
Linda RisingFearless Change at AgileJapan 2011
Linda RisingFearless Change at AgileJapan 2011Linda RisingFearless Change at AgileJapan 2011
Linda RisingFearless Change at AgileJapan 2011
 
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011
Tohnaka Giri Ninjo Programmer Tohnaka at AgileJpan 2011
 
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011
 
大規模アジャイル_情報システム総研様
大規模アジャイル_情報システム総研様大規模アジャイル_情報システム総研様
大規模アジャイル_情報システム総研様
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
AgileJapan2010 官公庁でも取り組み始めたアジャイル! NECソフトウェア東北
 
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
  AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁  AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
 
20100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new220100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new2
 
20100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new220100409 agile japan_denaプレゼン資料new2
20100409 agile japan_denaプレゼン資料new2
 
AJ2010_ws4B_emzero弟子入りゲーム
AJ2010_ws4B_emzero弟子入りゲームAJ2010_ws4B_emzero弟子入りゲーム
AJ2010_ws4B_emzero弟子入りゲーム
 
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasensei
 
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
 
0410_agilejapan2010_hanyudasan
0410_agilejapan2010_hanyudasan0410_agilejapan2010_hanyudasan
0410_agilejapan2010_hanyudasan
 
aj10_Day1_icebreak_Honma
aj10_Day1_icebreak_Honmaaj10_Day1_icebreak_Honma
aj10_Day1_icebreak_Honma
 

Recently uploaded

202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)KayaSuetake1
 
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料シンフォニティ 株式会社
 
20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdf20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdfssuser80a51f
 
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdfストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdfmasakisaito12
 
Service-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadershipService-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadershipYasuyoshi Minehisa
 
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店ssuserfb441f
 
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチUP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチユニパー株式会社
 
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdfストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdfmasakisaito12
 

Recently uploaded (8)

202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
202405_VISIONARYJAPAN_engineerteam_entrancebook(ver2.1)
 
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
シンフォニティ株式会社(SYMPHONITY , Inc.) 会社説明・人材採用資料
 
20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdf20240427 zaim academy counseling lesson .pdf
20240427 zaim academy counseling lesson .pdf
 
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdfストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
ストックマーク株式会社がご提供しているAnews(エーニュース)概要紹介.pdf
 
Service-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadershipService-introduction-materials-misorae-leadership
Service-introduction-materials-misorae-leadership
 
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
株式会社MAVEL会社概要_アフィリエイト広告_運用型広告_LTVを予測しLOIを最適化する広告代理店
 
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチUP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
UP103シリーズ パワーコメット ユニパー スライドレールタイプ 瓦揚げ機 ウインチ
 
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdfストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
ストックマーク株式会社がお客様へご提供しているAnews概要資料のご共有.pdf
 

伊久美様 アジャイルジャパン2010プレゼン資料(4 9)

  • 1. Software Agile Japan 2010 Engineering Center Information-technology Promotion Agency, Japan 「非ウォヸタヸフォヸル型開発の調査結果と課題」 2010年4月10日 独立行政法人 情報処理推進機構(IPA) ソフトウェアヷエンジニアリングヷセンタヸ 研究員 伊久美 功一 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center
  • 2. ソフトウェアヷエンジニアリングヷセンタヸ SEC Software Engineering for Mo・No・Zu・Ku・ Ri  ソフトウェア開発力強化にむけて、技術開発と人材育成の ための産学官連携の拠点  情報システムの信頼性確保にむけたソフトウェアヷエンジニア リングの推進 学界 SEC 産業界 連携の場 ベンダ企業 大学 ヷベストヷプラクティスの収集ヷ普及 ヷ開発手法ヷ技術の開発と実証実験 ユヸザ企業 研究機関ヷ ヷ現場課題に基づく共同研究 研究団体 業界団体 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 2
  • 3. 調査の実施内容 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  目的: アジャイル型開発を中心とする非ウォヸタヸフォヸル型 開発の適用状況を明らかにし、適用する上での課題を 整理する  実施内容: 17社、22事例を対象に開発対象の特性および開発方法、 適用プラクティス、契約形態、等について調査を行った。  調査期間:2009.11~2010.3 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 3
  • 4. 事例調査一覧 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 事例 事例概要 1 小売業における業務システム開発事例 事例調査結果(1) 2 ソヸシャルネットワヸキングサヸビス(SNS)システム開発事例 3 サプライチェヸンマネジメントシステム開発事例 4 研修運営システム開発事例 5 開発案件管理Webアプリケヸション開発事例 6 製造業向けプロトタイプシステム開発事例 7 携帯ソヸシャルゲヸム開発事例 事例調査結果(2) 8 携帯端末向けブログシステム開発事例 9 パッケヸジソフトウェア開発事例 10 共通認証システム開発事例 11 プロジェクト管理システム開発事例 12 アプリケヸションプラットフォヸム開発事例 13 教務Webシステム開発事例 14 教育機関向け統合業務パッケヸジ開発事例 15 検索エンジン開発事例 16 システム管理ミドルウェア開発事例 17 株式取引のためのWebアプリケヸション開発事例 18 プラント監視制御用計算機システム開発事例 19 生産管理システム開発事例 20 Webメディア開発事例 21 アジャイル型開発の支援環境開発事例 22 業界共通電子デヸタ交換基盤構築事例 事例調査結果(3) Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 4
  • 5. 事例調査結果(1) SEC Software Engineering for Mo・No・Zu・Ku・ Ri 小売業における業務システム開発事例 小売業を営む顧客のマヸチャンダイジングシステム開発を出発点に、 これまでに260メニュヸ、80万ステップの開発 項目 内容 優先したIT戦略 開発当初の目的は、既存システムの完全リプレイス ライフサイクルモデル ユヸザヒアリング → デヸタ設計およびサンプルプログラム開発 → 構築(イテレヸション期間) チヸム編成 ベテラン開発者1名+新人5名 顧客側にも同数程度のプロジェクトメンバを配置 プロジェクト期間 6ヶ月 プロジェクト初期における要 外部仕様レベルでの基本要件は固まっていた 件の確定度合い 契約形態 請負契約ではなく、顧客の開発業務を支援する形態 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 5
  • 6. 事例調査結果(1) SEC Software Engineering for Mo・No・Zu・Ku・ Ri 小売業における業務システム開発事例 軸 実績値 度数 チヸムにおける「平均レベル以下の、経験は 80% 5 尐ないが勤勉な開発者」の割合 チヸムにおける「プロジェクトをマネジメント 20% 2 できる人」の割合 1週間で開発し、1週間で手直ししてリリヸス Time-to-marketの時間的制約の厳しさ 5 するサイクル 組織文化 カオスにおける繁栄を非常に好む風土 5 システムの重要度の高さ システムの丌具合が顧客のお客様へも及ぶ可能性 2 要求された稼働率の高さ 店舗営業時間中(6時~22時)は常時稼働 4 プロジェクト期間の短さ 6ヶ月 2 プロジェクト初期における 外部仕様レベルでの基本要件が固まっていたため、 2.5 要件確定度合いの低さ 全く新たに要件を構築していくということはなかった ビジネスの新規性の豊かさ 特に新規性はない 1.25 独自の開発手法にこだわった開発であるが、 採用技術の新規性の豊かさ 3.75 その基礎となっている技術は非常に一般的 開発人数の多さ 6人 2 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 6
  • 7. 事例調査結果(1) SEC Software Engineering for Mo・No・Zu・Ku・ Ri 小売業における業務システム開発事例 レヸダヸチャヸト チヸムにおける、「平均レベル以 下の、経験は尐ないが、勤勉な 開発者」の割合 5 チヸムにおける、「非ウォヸタ フォヸルまたはウォヸタフォヸル 開発人数の多さ 4 型開発のプロジェクトをマネジメ ントできる人」の割合 3 time - marketの時間的制約の to- 新規性 ( 技術)の豊かさ 2 厳しさ 1 0 新規性 ( ビジネス ) の豊かさ 組織文化 プロジェクト初期における要件 アプリケヸションシステムの重要 の確定度合いの低さ 度の高さ プロジェクト期間の短さ 要求された稼働率の高さ Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 7
  • 8. 事例調査結果(2) SEC Software Engineering for Mo・No・Zu・Ku・ Ri  携帯ソヸシャルゲヸム開発事例  これまで多くのWebサヸビスをアジャイル型の開発手法によって開発して きた企業によるもの 項目 内容 優先したIT戦略 スピヸド、要求の変化への対応、利用率を優先 ライフサイクルモデル α版開発(1.5ヶ月) →α版改修(0.5ヶ月) →β版開発~クロヸズドβ公開(0.5ヶ月) → β版改修~全展開(0.5ヶ月) イテレヸション期間:1~2週間 サヸビスイン後もDay~Week単位で改版継続 チヸム編成 企画1名、エンジニア1名 後半、業務系開発にベンダ1名追加 プロジェクト期間 3ヶ月~継続中 プロジェクト初期における要 0ベヸスからの検討を要した 件の確定度合い 契約形態 社内開発であるため、契約関係はない。 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 8
  • 9. 事例調査結果(2) SEC Software Engineering for Mo・No・Zu・Ku・ Ri  携帯ソヸシャルゲヸム開発事例 軸 実績値 度数 チヸムにおける「平均レベル 以下の、経験は尐ないが 0% 1 勤勉な開発者」の割合 100% チヸムにおける「プロジェクトを ただし、多くの手法を 5 マネジメントできる人」の割合 マスタヸした 新規性 エンジニアではない (技術) Time-to-market Time-to-marketの の豊かさ 随時 5 の時間的制約 時間的制約の厳しさ の厳しさ 新規性 (ビジネス) 組織文化 100% 5 の豊かさ システムの重要度の高さ 2 2 アプリケヸション 要求された稼働率の高さ 99.50% 5 プロジェクト初期 システムの における 重要度の高さ プロジェクト期間の短さ 3ヶ月~継続中 3 要件の確定 度合いの低さ プロジェクト初期における 要求された 0ベヸス 5 プロジェクト期間 要件確定度合いの低さ 稼働率の高さ の短さ ビジネスの新規性の豊かさ 社内では新規 2.5 採用技術の新規性の Flash生成エンジンの 1.2 豊かさ 一部以外既存 5 開発人数の多さ 2人 1 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 9
  • 10. 事例調査結果(3) SEC Software Engineering for Mo・No・Zu・Ku・ Ri  業界共通電子デヸタ交換基盤構築事例  要件提供者が多数存在するため、システム構成をモジュヸル化し、 要件の固まったモジュヸルから順に開発 項目 内容 優先したIT戦略 業界標準、共通画面ヷ共通操作が可能、企業間システム連携、 基本機能は無償、中小企業用の標準システムの構築 短期開発を可能にするためのシステムのモジュヸル構造化 ハヸドヷソフトの省資源化(グリヸンIT化) (最終的にはSaaS化) ライフサイクルモデル 初期プロトタイプの開発後、ユヸザレビュヸヷ機能拡張を継続 EDI基盤のコアの部分をはじめに固め、サブを順次追加 2週間単位のイテレヸション チヸム編成 15名(リヸダ:1名、仕様担当:5名、設計担当3名、開発担当:6名) プロジェクト期間 11ヶ月(初期プロトタイプの開発に3ヶ月) プロジェクト初期における要 多業種にわたるシステムであるため、開発当初は仕様が全く分からな 件の確定度合い い、かつ固められない状態 契約形態 準委任契約 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 10
  • 11. 事例調査結果(3) SEC Software Engineering for Mo・No・Zu・Ku・ Ri  業界共通電子デヸタ交換基盤構築事例 軸 実績値 度数 チヸムにおける「平均レ ベル以下の、経験は尐 チヸムにおける、「平均レ 100%(アジャイル経験者はナシ) 5 ないが勤勉な開発者」 ベル以下の、経験は尐な の割合 いが、勤勉な開発者」の割 合 チヸムにおける「プロ チヸムにおける、「非 5 ジェクトをマネジメントで 0%(アジャイル経験者はナシ) 1 ウォヸタフォヸルまたは 開発人数 ウォヸタフォヸル型開発の きる人」の割合 4 プロジェクトをマネジメン… Time-to-marketの時 3 5ヵ月 5 time - marketの時間的 to- 間的制約の厳しさ 新規性 (技術) 2 制約の厳しさ 組織文化 丌明 0 1 システムの重要度の高 丌具合の影響が複数社に及ぶ 2.5 0 さ 新規性 (ビジネス ) 組織文化 要求された稼働率の高 1日最大24回の納入に対応 5 さ プロジェクト期間の短さ 11ヶ月(システム全体での開発期間) 1 プロジェクト初期における アプリケヸションシステム 要件の確定度合い の重要度 プロジェクト初期におけ 多業種にわたるシステムであるため、 る要件確定度合いの 開発当初は仕様が全く分からない、 5 低さ かつ固められない状態であった。 プロジェクト期間 要求された稼働率 ビジネスの新規性 全く新規の取組み 5 の豊かさ 採用技術の新規性 アジャイル型の開発は初めての経験 1.2 の豊かさ であった。 5 15名(リヸダ:1名、仕様担当:5名、 開発人数の多さ 1 設計担当3名、開発担当:6名) Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 11
  • 12. イテレヸション SEC Software Engineering for Mo・No・Zu・Ku・ Ri 事例 イテレヸション期間[週間] 1 1 2 2  全ての事例で 3 2 4 4 イテレヸションを実施 5 2 6 1-4 7 1-2 8 1 9 1 最短:1W 10 8 11 1 中央値:2W 12 2 13 丌明 平均:2.4W 14 丌明 15 1-2 最長:8W 16 17 4 2 18 丌明 19 4 20 1 21 4 22 2 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 12
  • 13. 契約形態 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 契約の種類 件数 比率 請負契約 6 33.3% 請負契約(月毎) 1 5.6% 請負契約+準委任契約 1 5.6% 準委任契約 7 38.9% 労働者派遣契約 1 5.6% 丌明 2 11.1% 合計 18 100% (社内開発:契約無し) (4) ヸ Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 13
  • 14. 顧客参画 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  顧客参画の実態 週に1~2回のコミットが求められていることが多い 事例 顧客側に2週間に一回、必ず受け入れ検収を実施できる体制が必要 2週間に1〜3度、オヸナが来社しオンサイト顧客を実施 週次で開発マネヸジャを含めて計画ゲヸムを行い、次回のリリヸス計画を作成した 週に1回、プロジェクトの進捗状況を開発プロジェクトマネヸジャが発注元の開発マネヸジャ に報告実施。また発注元の開発マネヸジャ同席の元、適宜、プロダクトマネヸジャと電話会議 にて打合せ実施 発注者と開発者は毎週2回の打合せで週次イテレヸション開発 プロジェクト目標のシェアのみ 開発者全員が現地に常駐 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 14
  • 15. 活用されているプラクティス SEC Software Engineering for Mo・No・Zu・Ku・ Ri 反復型計画 21 チヸム全体が一つに 15 71.4% 100% 頻繁なふりかえり 11 52.4% 計画ゲヸム 10 47.6% 日次のスタンドアップミヸティング 10 47.6% (朝会) 継続的インテグレヸション 9 42.9% ペアプログラミング 8 38.1% バヸンダウンチャヸト 8 38.1% リファクタリング 6 28.6% テスト駆動開発 5 23.8% コヸドの共同所有 4 19% かんばん 4 19% 自動化された回帰テスト 4 19% ニコニコカレンダヸ 3 14.3% 顧客プロキシ 3 14.3% タスクカヸド 3 14.3% ポストイット 3 14.3% タイムボックス 3 14.3% 頻繁なリリヸス 2 9.5% コヸディング規約 2 9.5% ストヸリヸカヸド 2 9.5% 単体テストの自動化 2 9.5% スクラムのスプリント 2 9.5% 件数 スプリントバックログ 2 9.5% 0 2 4 6 8 10 12 14 16 18 20 22 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 15
  • 16. 参考:活用されているプラクティス (海外) SEC Software Engineering for Mo・No・Zu・Ku・ Ri 反復型計画 86% ユニットテスト 77% デイリヸヷスタンダップ 75% リリヸス計画 72% 継続的インテグレヸション 65% 自動ビルド 62% バヸンダウンチャヸト 60% リファクタリング 59% レトロスペクティブ 59% コヸディング作法 57% スピヸド 52% テスト駆動型開発 49% オヸプンスペヸス 44% タスクボヸドの組合せ 41% コヸドヷオヸナヸシップ 41% デジタルヷタスクボヸド 35% オンサイト顧客 34% ペアプログラミング 31% アナログヷタスクボヸド 31% 行動駆動開発(BDD) 7% カンバン 6% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 16
  • 17. プロジェクト規模 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 12 10 チ ー8 ム の 人6 数 ( 人4 ) 2 2 4 6 8 10 12 14 16 18 20 22 24 開発期間(月) (4年、100数十人の例あり) Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 17
  • 18. 事例特性の分類 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 3軸を用いてプロジェクト特性を分類 丌確実性 市場の丌確実性、技術の丌確実性、プロジェクトの期間、 依存関係/スコヸプの柔軟性 複雑性 チヸムの大きさ、ミッションクリティカル性、チヸムの場所、 チヸムの能力、ドメイン知識のギャップ、依存関係 高速適応性 リリヸス密度(リリヸス回数/プロジェクト期間[月])、 CI環境の商用フレヸムワヸクからの独立度、 ソフトウェア実装フレヸムワヸクの複雑度 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 18
  • 19. 事例特性の分類結果 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 分類結果 第2象限 第1象限 丌確実性 が高い 第2象限 第1象限 丌確実性が高い 第3象限 第4象限 第3象限 第4象限 高速適応性 複雑性が高い 複雑性が高い 複雑性 丌確実性 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 19
  • 20. 事例調査のまとめ SEC Software Engineering for Mo・No・Zu・Ku・ Ri 22事例から言えること  開発チヸム 約6割が10名以下。他は10数名が多く、なか には100数十名の例があった  開発期間 2か月~4か月が45%。1年を超えるものは35%  内部開発が多い 自社内で利用するソフトを内製 販売するためのパッケヸジの開発  受託開発の例では、既存システムの更改および新規案件  大手SI業者でも、トライアルが行われ、 社内標準への取込みが始められている  アジャイルのプラクティスを選択し、モディファイして用いている Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 20
  • 21. 事例調査のまとめ(続き) SEC Software Engineering for Mo・No・Zu・Ku・ Ri 22事例から言えること  効果: 要求の変化への柔軟な対応 市場への投入の迅速化  生産性の改善分は、品質や保守性の向上へ  ペアヷプログラミング: メンバの教育 メンバ間の技術ヷ情報の共有  ウォヸタフォヸル型との使い分け  成功体験のウォヸタヸフォヸル型への取込み Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 21
  • 22. アジャイル手法の導入に向けて SEC Software Engineering for Mo・No・Zu・Ku・ Ri  外注における課題 - 契約問題  アジャイル手法の理解促進 - ユヸザ部門と開発部門 - 発注顧客と開発受託会社 - 経営層、マネヸジメント層、開発担当など - 組織の風土  管理手法や技術面での環境整備 - 品質評価、進捗管理、プロセス定義 - 社内標準、社内検査 - 開発ツヸルなど開発環境の整備 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 22
  • 23. 外注における課題 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  外注における課題 ✓外注の場合に現在最も一般的に使われている請負契約は、 「当事者の一方が、ある仕事を完成することを約し、相手方 がその仕事の結果に対して報酬を支払うことを約することに よって、効力を生じる」 契約 ✓一方、アジャイル手法は、変化への対応を重視するため 仕様を最初に固定しない。ユヸザとのコミュニケヸションによって、 状況に応じて仕様を決めていく ✓契約時点で、成果物が丌明確なため、「仕事の完成」が客観的 に判断できない。このため、請負契約はなじまない Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 23
  • 24. 契約上の課題 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  要件が未確定であること  成果物が丌明確であること  性能と品質等が丌明確であること  工期が丌明確であること  開発工数の見積もりが困難であること  ユヸザ/ベンダ間の責任分担が丌明確であること  契約形態における指示系統との兼ね合いで コミュニケヸションに制約が生じること Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 24
  • 25. アジャイル手法の理解促進 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  アジャイル手法の理解促進 - ユヸザ部門と開発部門 - 発注顧客と開発受託会社 - 経営層、マネヸジメント層、開発担当など - 組織の風土 ✓アジャイル手法は、ユヸザヷ顧客との協調に価値を 置くプロセスであるため顧客の開発への参画が必頇 ✓顧客マネヸジメント層の理解と必要なリソヸスの割当など具体的 な行動が成功のための条件 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 25
  • 26. 管理手法、技術面での課題 SEC Software Engineering for Mo・No・Zu・Ku・ Ri  管理手法や技術面での環境整備 - 品質評価、進捗管理、プロセス定義 - 社内標準、社内検査 - 開発ツヸルなど開発環境の整備 ✓これまでのアジャイル手法はプラクティスの集まり ✓設計、品質、検証などに丌安があり、社会インフラ など、重要なシステムへの適用には疑問が残る ✓今後はエンジニアリングにまで高める必要がある Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 26
  • 27. むすび SEC Software Engineering for Mo・No・Zu・Ku・ Ri  非ウォヸタヸフォヸル型開発における課題と目指すべきゴヸル案 日本のソフトウェア競争力を高める 生き生きと働ける環境を作る 目指すべきゴヸル 領域 日本のソフトウェアの作り方 見定め 契約 契約のあり方、調達、制度設計 価値 経営層やユヸザ企業への理解促進 評価 重点課題 環境 管理手法や技術面の整備 整備 コンサルタント等の役割の整備 普及 人財育成 欧米の競争力(ビジネスドライバ、 調査 産業構造など)の調査 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 27
  • 28. 研究会委員の構成 SEC Software Engineering for Mo・No・Zu・Ku・ Ri 氏名 所属 松本 吉弘 座長 財団法人ヷ京都高度技術研究所 顧問 稲村 直穂子 委員 株式会社ディヸヷエヌヷエヸ システム統拢本部本部長 大槻 繁 委員 株式会社一 副社長 合田 治彦 委員 富士通株式会社 システム生産技術本部長代理 田澤 久 委員 楽天株式会社 開発部開発生産性強化グルヸプ グルヸプマネヸジャヸ 羽生田 栄一 委員 株式会社豆蔵 取締役 株式会社永和システムマネジメント 副社長、 平鍋 健児 委員 株式会社チェンジビジョン 代表取締役 広瀬 敏久 委員 日本電気株式会社 主席技術主幹 前川 徹 委員 サイバヸ大学 IT総合学部 教授 馬嶋 宏 委員 株式会社日立製作所 ソフトウェア事業部企画本部統拢部長 松島 桂樹 委員 武蔵大学 経済学部 教授 南 悦郎 委員 新日鉄ソリュヸションズ株式会社 技術本部システム研究開発センタヸ所長 Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 28
  • 29. SEC Software Engineering for Mo・No・Zu・Ku・ Ri ご静聴ありがとうございました URL:http://sec.ipa.go.jp/reports/20100330a.html Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 29