IoT 時代に向かい, 進化し続けるアジャイル ~ 来たるべき商品 / サービス競争時代を勝ち抜くために ~ ET/IoT 年 11 月 16 日 Information-technology Promotion Agency, Japan Copyright 2016 IPA,

Size: px

Start display at page:

ともなりすみだ
4 years ago
Views:

IoT 時代に向かい, 進化し続けるアジャイル ~ 来たるべき商品 / サービス競争時代を勝ち抜くために ~ ET/IoT 2016 2016 年 11 月 16 日 Information-technology

1 IoT 時代に向かい, 進化し続けるアジャイル ~ 来たるべき商品 / サービス競争時代を勝ち抜くために ~ ET/IoT 年 11 月 16 日 Information-technology Promotion Agency, Japan 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 山下博之

2 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 2

3 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 3

4 ICT システムの変遷と開発スタイル 1960 年代 1980 年代 2000 年代 2020 年代インターネットクラウド (IoT/IoE) (super AI)? ビジネスを支援する ICT ビジネスを実行する ICT PC ブラウザセンサーモバイル PC 携帯スマホ / タブレット? SoE SoR アジャイルウォーターフォール品質スピード価値 SoE: Systems of Engagement SoR: Systems of Record 4

5 インターネット関連ビジネスの歴史 1980 年代末営利目的のインターネットサービス ~1990 年代プロバイダ (ISP) が出現 1984 年 Cisco 設立 1985 年 Qualcomm 設立 1989 年世界初の商用 ISP(PSINet) 誕生 1994 年 2 月 Yahoo! 誕生 1994 年 7 月 amazon.com 創業 1994 年 12 月 Netscape Navigator 公開 1995 年 7 月 amazon.comサービス開始 1997 年 9 月 15 日 Google 検索登場 1998 年 9 月 Google 法人化インターネットの黎明期に新会社が設立, 新サービスが続々と登場 1992 年 12 月 IIJの企画会社設立 1993 年旧郵政省により日本におけるインターネットの商用利用が許可 1993 年 5 月 ( 株 )IIJに社名変更 11 月 IIJがISPサービス開始 ( 国内初 ) 1996 年 4 月 Yahoo! Japanサービス開始 1996 年 12 月 25 日 NTTの OCN の開始 1997 年 5 月楽天市場のサービス開始 1999 年 2 月 22 日 iモードサービス開始 2002 年 3 月 29 日東京電力 TEPCOひかりを開始 2004 年 2 月 4 日 Facebook 誕生 2005 年 2 月 15 日 YouTube 設立 2006 年 3 月 31 日ニフティのパソコン通信サービス終了 2006 年 6 月 Twitter 設立 2006 年 12 月 12 日ニコニコ動画サービス開始 2007 年 1 月 iphone 発売 2008 年 7 月 10 日 Appleが App Store を開始 2008 年 7 月 iphone 発売 2009 年 Uber が配車サービス開始 2011 年 6 月 LINE サービス開始進化し続ける 2014 年 11 月ソラコム設立 < 出典 > JPNIC: インターネット歴史年表, 等インターネットサービスが 5

6 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 6

7 新たな情報革命 :Cyber Physical System(CPS) つながる機器の分野台数は急増し, 従来デジタル化されることなく散在していたデータが大量にインターネットに流通より広範囲により深く < 出典 > 情報経済小委員会中間とりまとめ報告書, 産業構造審議会商務流通情報分科会, 平成 27 年 5 月 21 日をもとに加筆. ビジネス機会の増大セキュリティ等, リスク要因も増大 7

8 IoT 時代のビジネス領域 5つのレイヤシステム / デバイスコネクティビティプラットフォームアナリティクスアプリケーションビジネスの方向導入機器 / 導入地域の拡大導入目的 / 導入用途の拡大導入産業分野の拡大自社のビジネスはどこか? どの領域を狙うか? < 出典 > 国内 IoT 市場グローバル主要事業者分析結果を発表 2015 年 6 月 10 日 IDC Japan 株式会社プレスリリースをもとに作成 8

9 ビジネスのパラダイムシフト日産自動車の関係者は人工知能 (AI) を使うクルマになるとディープラーニングの機能は車体に組み込むというより走行中のデータをクラウドで処理しその結果生まれる新しい機能性能をクラウドからダウンロードするイメージだと話す ( 中山淳史そしてクルマはクラウドにつながる, 日本経済新聞,2016/6/7) 自動車産業におけるものからサービスへの流れ. クルマは, 所有するものから, 移動手段へ. ( 各種ソース ) ソフトウエアデファインド (Software- Defined) の時代ですアメリカのゼネラルエレクトリック社がすでに取り組んでいますが世界中に設置されている自社製の機械の動きを 24 時間 365 日クラウドで監視していて異常や故障の前兆が検知されたら予防保守をするか交換するユーザーは実質的に故障しない製品を買ったことになるのです ( つくだひとし講演採録派生開発推進協議会代表清水吉男氏 XDDP から IoT に挑む,IT 記者会レポート, ) 9

ビジネスに関わる IoT 時代の特徴 IoT(Internet of Things) 時代モノ, ヒトとネットワークとソフトウェアを組み合わせた強みを活用し, さらに AI やビッグデータ分析等の技術を組み合わせた商品 / サービス競争の時代取り巻く環境の変化が激しい時代

10 ビジネスに関わる IoT 時代の特徴 IoT(Internet of Things) 時代モノ, ヒトとネットワークとソフトウェアを組み合わせた強みを活用し, さらに AI やビッグデータ分析等の技術を組み合わせた商品 / サービス競争の時代取り巻く環境の変化が激しい時代インターネット上で時々刻々と新デバイスが接続, 新サービスが提供現状や未来の全体像を見通すことはできない顧客のニーズもそれらに誘発されて移ろいゆき, それがきっかけとなってさらにデバイスやサービスが更新相互に深く影響し合いながら進展するある日突然, 新たなセキュリティ上の脅威が発生対応の機敏さが死命を制する 10

11 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 11

12 企業活動のアジリティ ( 機敏性 ) IoT 時代における環境の変化に機敏に応じることが可能な商品 / サービスを市場に投入し続ける企業活動そのもののアジリティ今や企業活動の根幹を担う ICT システムについては迅速でかつ確実な開発更新エンタープライズアジャイルアジャイル開発手法 12

13 参考ビジネスステージと開発手法ソフトウェア製品のライフサイクルモデル例と開発手法アジャイルウォーターフォール A financial model of software product development. ビジネスの黎明期には, 競争優位を確保して生き残るために, 頻繁に新商品 / サービスを投入 < 出典 > Ram Chillarege: The Marriage of Business Dynamics and Software Engineering, IEEE SOFTWARE, November/December

14 参考データ日本の現状 (1) デジタルテクノロジの実装プロジェクトを担当する組織その他 1.9% プロジェクトチーム ( ビジネス部門とのタスクフォース ) 28.1% 従来の IT 部門内専門チーム 40.6% デジタルテクノロジを使用したプロジェクトの予定 / 実績がある企業のうち約 3 割は従来の IT 部門とは別に専門組織を立ち上げている従来の IT 組織とは別の新組織 29.4% 調査対象 309 人のうち, プロジェクトの予定 / 実績がある 160 人の回答者の内訳 < 出典 > ガートナーバイモーダルな IT 組織に関する調査結果を発表 2016 年 6 月 1 日ガートナージャパン株式会社プレスリリースをもとに作成 14

15 参考データ日本の現状 (2) (%) lot の推進体制を確立させている企業の割合の変化現在準備中 (1 年以内に実施 ) 年 2016 年 IOT の専門部署やグループができた lot に対する期待や不安社内の変革を推進する IT がよりビジネスに貢献できる IT 部門の新しい価値を発揮できる市場での競争を優位にするそう思ういまだにどこから手を付けるべきか分からない国内企業の IoT への取組み姿勢は慎重 < 出典 > (%) ガートナー日本におけるモノのインターネットに関する調査結果を発表 2016 年 4 月 26 日ガートナージャパン株式会社プレスリリースをもとに作成 15

16 参考データ日本の現状 (3) デジタル投資により期待する効果として収益へのインパクトを挙げていた割合は, グローバルの経営者では大幅に増加しているが, 日本はほぼ変わらず. デジタル投資の llot に期待する効果のうち, 収益へのインパクトを期待している経営者の比率グローバル日本 2014 年 31% 2014 年 34% 2015 年 57% 2015 年 32% 注 :2014 年の調査ではデジタル投資に期待する効果について,2015 年の調査では llot に期待する効果について質問 < 出典 > Industrial Internet of Things を価値創造につなげるグローバル CEO 調査 2015, アクセンチュアをもとに作成. 16

17 参考データ日本の現状 (4) グローバル企業の経営者は, 市場における創造的破壊がさらに進むと考えている. 日本の経営者で, 競合企業が市場のルールを一変させるという懸念を持つ者は少ない. 競合企業がビジネスモデルを大きく変化させる可能性があると考えている経営者の比較 68% 競合企業が市場を一変させるような製品サービスを打ち出す可能性があると考えている経営者の比率 62% 16% 16% グローバル日本グローバル日本 < 出典 > Industrial Internet of Things を価値創造につなげるグローバル CEO 調査 2015, アクセンチュアをもとに作成. 17

18 参考データ日本の現状 (5) IIoT がビジネスにプラスのインパクトをもたらす可能性としてグローバル企業の半数以上が新たな収益源の創出を挙げる. 日本企業は効率化への注目度が高い. グローバル 43% 57% 日本 68% 32% llot がオペレーション効率化 / 生産性向上に貢献すると回答 llot が新たな収益源の創出に貢献すると回答 < 出典 > Industrial Internet of Things を価値創造につなげるグローバル CEO 調査 2015, アクセンチュアをもとに作成. 18

19 参考組織の機敏性とは? What Defines Organizational Agility? 素早い応答短サイクル変更管理顧客の声を聞くリスク管理多様なチームサイロ化防止非常事対策反復プロセス技術の活用 < 出典 > PMI Pulse of the Profession In-Depth Report: Organizational Agility,

参考組織の機敏性が大きいほど, パフォーマンスはよくなる Success with new initiatives over the past 2-3 years Greater organizational agility leads to better performance providing organizations with a powerful edge on the

20 参考組織の機敏性が大きいほど, パフォーマンスはよくなる Success with new initiatives over the past 2-3 years Greater organizational agility leads to better performance providing organizations with a powerful edge on the competition. 成功率が増大している組織ほど, 高い機敏性を有する Those organizations that are successful report higher levels of organizational agility giving them a powerful edge on the competition. < 出典 > PMI Pulse of the Profession In-Depth Report: Organizational Agility,

21 参考組織の機敏性の度合いとプロジェクト成功率 Project Success Metrics by Level of Agility 納期内予算内ビジネス目標達成高い投資効果高いパフォーマンス機敏性の大きな組織競争力強化 < 出典 > PMI Pulse of the Profession In-Depth Report: Organizational Agility,

22 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 22

23 組込み機器システムとアジャイル開発組込み機器システムの開発に対しても, アジャイル開発手法の適用が必要となってきている 23

24 アジャイル開発の試行領域 ( 当時 ) アジャイル開発による経験が十分には蓄積されておらず現在チャレンジと創意工夫が求められている領域 : 1 大規模開発開発者 10 人程度を超えるとシステム分割チーム分割が必要その分割方法及び分割されたチーム間のコミュニケーションが課題 2 分散拠点 ( オフショア含む ) 開発開発拠点が分散しさらに時差によって分断される場合のコミュニケーション手法またそれをサポートするツールが必要 3 組織 ( 会社 ) 間をまたぐ開発チームによる開発共通のビジネスゴールを持ったチームを組むことが難しい 4 組込みシステム開発リリース後のソフトウェア修正が極めて困難であり採用には工夫要 < 出典 > 非ウォーターフォール型開発 WG 活動報告書 IPA/SEC, 平成 23 年 3 月 31 日. 24

25 組込み製品開発の特徴顧客 ( エンドユーザ ) が見えない経験と想像に基づく要求設定未来予測の要求への反映そもそも開発開始前の真の要求の確定は不可能多くの関係者 ( 関連部署 ) との協力による開発推進市場からのフィードバックを迅速に行う仕組み短いサイクルで機能を積み上げ, 評価しつつ, 製品の価値を高めていく 25

26 日米における今日のデバイスの比較日本米国 ( シリコンバレー ) ハードウェアソフトウェアハードウェアソフトウェアインターネットを介した改善 < 出典 > クリストファーテイトイノベーションを生み出す日本へ再び ~ ソフトウェアとハードウェアの対話が日本に強さもたらす ~ ET-West 2013 ヒートアップセッション HU-5 講演,2013 年 6 月 14 日, 大阪. 26

27 IoT 時代の組込み機器システムとアジャイル開発ハードウェアソフトウェアインターネットを介した改善更新の仕組みクラウド等 PLD フラッシュメモリ等 PLD: Programmable Logic Device 利用者の購入後にインターネットを介して定期的に機能拡張 * アジャイル開発エンドユーザ側データ ( 状態, 使用感, 等 ) の収集の仕組み * エンドユーザからのフィードバック対応を含む真の要求 27

28 組込み系とエンタプライズ系の技術者間の協働機器システムだけを見ていては不十分 ( イノベーションに結びつきにくい ) エンドユーザ側データ ( 状態, 使用感, 等 ) の収集の仕組みと運用機能拡張の仕組み ( サーバ / バックヤード / クラウド側 ) の理解機能拡張項目選定のトリガ ( 利用者の声を捉える仕組み ) の理解技術者に求められる行動組込み系とエンタプライズ系の協働 / 両スキルの獲得 28

29 本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 29

30 価値で決まる IT プロジェクトの成功は, もはや QCD ではなく, IoT の時代では価値を高め得る要素が増大 ( 顧客側の ) 価値や満足で決まる < アジャイル開発の特徴 > ( 顧客 ) 価値駆動型 30

31 参考データ IT プロジェクト成功の定義 ( あるアンケートの例 ) 3 要素 ( 予算, 納期, 機能充足 ) 15% 予算 C 32% 納期 D 30% 機能充足 ( スコープ ) Q 26% 目標 (*1) 29% 価値 52% 満足 41% 上記 6 要素の全て 33% (*1) 組織の戦略目標にどれだけ合致しているか? 6 要素のうち,4 つまで選択可.( 回答数 =309) < 出典 > CHAOS MANIFESTO 2014 Triple constraints 15% On budget 32% On time 30% On Target (scope) 26% On goal 29% Valuable 52% Satisfied 41% All of the above 33% 31

その中で,ICT システム開発については, アジャイル開発手法インターネットの黎明期を思い起こす

32 進化し続けるアジャイル主に技術者 IoT 時代に向かって, つながる機器の分野台数は急増し, デジタルデータが大量にインターネットに流通企業活動に求められるアジリティ ( 機敏性 ) その中で,ICT システム開発については, アジャイル開発手法インターネットの黎明期を思い起こすビジネス機会の増大主に経営層適用範囲がますます拡大手法自身も進化し続けている ( モデルやハードウェアをも対象, 等 ) 32

33 ご清聴, ありがとうございましたアジャイル開発に関する IPA/SEC の調査検討結果等は : 33

34 付録 37

35 ふり返り : アジャイル開発に関する IPA/SEC の取組み H21(2009) 年度 H22(2010) 年度 H23(2011) 年度 H24(2012) 年度課題抽出非ウォーターフォール型開発研究会報告書非ウォーターフォール型開発に関する調査事例収集 (1) 報告書 ( 公開中 ) 報告書非ウォーターフォール型開発 WG 課題検討提案報告書非ウォーターフォール型開発 WG 実証 / 模擬実験検証改善 ( 契約形態 ) 大規模開発事例収集 (2) 普及要因報告書報告書報告書非ウォーターフォール型開発 WG 事例収集 (3) プラクティスリファレンスガイド H21 年度版 H22 年度版 H23 年度版 ( 大規模開発 ) ( 普及要因 ) ( プラクティス ) 報告書 38

アジャイル開発プラクティス活用リファレンスガイドプラクティス : アジャイル開発を実践する活動項目 http://www.ipa.go.

36 アジャイル開発プラクティス活用リファレンスガイドプラクティス : アジャイル開発を実践する活動項目

37 ガイドの特徴アジャイル開発を実践する活動項目 55 個 * のプラクティス,26 個の事例,9 つの活用ポイント計 224 ページ日本国内の開発現場からのヒアリングにより収集した知見を, パターン記述形式で取りまとめ MS-Word ファイルを公開し, クリエイティブコモンズライセンスの下に, 改変自由営利目的利用可で使用許諾 * 類似のものを統合し, 最終的には 45 個 40

38 日次ミーティングふりかえりイテレーション計画ミーティングイテレーション紙手書きツール持続可能なペースチーム全体が一つにバーンダウンチャートタスクボード ( タスクカード ) ユニットテストの自動化インテグレーション専用マシン集団によるオーナーシップ自己組織化チーム継続的インテグレーション組織にあわせたアジャイルスタスプリントバックログリリース計画ミーティングファシリテータ ( スクラムマス迅速なフィードバックコーディング規約ユーザーストーリープロダクトバックログ ( 優先順ベロシティ計測リファクタリング共通の部屋プロダクトオーナースプリントレビュー自動化された回帰テストプランニングポーカーシンプルデザイン柔軟なプロセステスト駆動開発オンサイト顧客人材のローテーションペアプログラミングスパイクソリューションアジャイルコーチ受入テスト顧客プロキシバグ時の再現テスト逐次の統合インセプションデッキニコニコカレンダーかんばんシステムメタファ適用プラクティス ( 全体 ) 日次ミーティングふりかえりイテレーション計画ミーティングイテレーションの順に適用率が高くこれらはアジャイル開発を行う上でのほぼ必須のプラクティスであると言えるこれらのプラクティスは Scrum と XP に共通するプラクティスである 100% プラクティス適用率 (n=26) 80% 60% 40% 20% 0% : 適用数は適用を 1 件部分的に適用を 0.5 件として集計したシステムメタファは国内の 26 事例の中で活用されている事例はなかったガイド編プラクティス解説では海外の事例を調査した 41

39 リファレンスガイドプラクティス例概要日次ミーティング状況チームはプロジェクトのタスクをこなすためにほとんどの時間を使い状況や情報の共有のために取れる時間がほとんどない問題情報の共有遅れが問題を大きくする情報共有の時間が取れないまま状況認識と問題対処への判断が遅れると問題が大きくなるなどより深刻な状況を招いてしまうフォース関係者が多忙なため情報共有のための時間が取れない情報共有の間隔が空いてしまうと情報量が増え共有に必要な時間が余分にかかる利用例事例 (9): 遠隔地にいるメンバーも日次ミーティングに参加するためチャットツールや電話会議システムを利用した事例 (17): 1 日 3 回 ( 朝昼夕 )10 分程度のミーティングを実施問題を報告 / 解決するためのリズムが開発メンバー全員に浸透して短期での問題提起ができている留意点必ずしも朝の時間帯にこだわらず関係者が集まりやすい時間帯に開催する ( 例えば終業近い時間帯に開催する夕会 ) 解決策必要な情報を短い時間で毎日共有する関係者が長時間時間を取れないようであれば短い時間 (15 分を目安に ) で済むように共有を必要な情報に絞る 42

40 リファレンスガイドプラクティス例概要ふりかえり状況イテレーション毎にチームは動くソフトウェアとして成果を出そうとしているイテレーションを繰り返してチームはソフトウェアを開発していく問題開発チームはそこに集まったメンバーにとって最適な開発プロセスを最初から実践することはできないフォースイテレーションでの開発はうまくいくこともあるがうまくいかないこともある解決策反復内で実施したことを反復の最後にチームでふりかえり開発プロセスコミュニケーションその他様々な活動をよりよくする改善案をチームで考え実施する機会を設ける 1 メンバー全員で Keep( よかったこと続けたいこと ) Problem( 問題困っていること ) Try( 改善したいことチャレンジしたいこと ) を出し合いチームの改善を促す手法利用例事例 (25): 当初は KPT [ 1] を用いてふりかえりを行っていたがファシリテータの技量にふりかえりの質が依存してしまう声の大きいメンバーに影響を受けてしまうことに気づいたそのため意見を集めるやり方として 555(Triple Nickels) [ 2] を用いることにした留意点ふりかえりにチームが慣れていない場合は進行で各人の意見をうまく引出すようにしないとうまくいかない問題点を糾弾する場にしてしまうと改善すべき点を積極的に話し合えなくなってしまう改善案を出しても実際に実行可能なレベルの具体的なアクションになっていないと実施されない 2 アクションや提案に対するアイデアを出すための手法 5 人程度のグループで各人が 5 分間ブレインストーミングをしてアイデアを書き出す 5 分経過したら紙を隣の人にまわし新しいアイデアを書き加える 43

41 リファレンスガイドプラクティス例概要イテレーション計画ミーティング状況開発を一定期間のサイクル ( イテレーション ) で繰り返し行っているプロダクトバックログの内容をチームとプロダクトオーナーの間で合意している問題リリース計画は遠い未来の目標のためそれだけではイテレーションで何をどのように開発すれば良いか分からないフォースユーザーストーリーのままイテレーションの詳細な計画を立て開発を進めていくのは難しい解決策イテレーションで開発するユーザーストーリーとその完了までに必要なタスクおよびタスクの見積りを洗い出すミーティングを開く利用例 G 社事例 (9): ペーパープロトタイピング [ 1] を用いた UI デザインの共有と受入れ条件の確認をイテレーション計画ミーティングで行っていたそのため計画にはかなり時間を要していたが見積りの前提が具体的になったため見積り作業時間の削減に繋がった留意点見積りに関してチームが水増しする懸念を持つかもしれないがチームを信じるべきであるプロジェクトの目的を理解したチームは見積りが大きく外れるようであれば自らその原因を分析し次の見積りに活かすはずである 1 紙などを使った試作品でユーザビリティテストを行うこと 44

42 リファレンスガイド事例概要 << 中大規模適用プロジェクトの事例 >> 事例 (4) C 社プロフィール既存のサービスのリプレイス開発単純なサービスのリプレイスではなく新しい要件も加えながら開発したいとの要望があり C 社から顧客にアジャイル開発を提案して開始したリプレイスといいながらも顧客から要件を聞き出しながら開発を進めていった要件が固められない部分のみアジャイル開発を行い要件が明らかな部分についてはウォーターフォール型開発を実施したシステム種別 B2Cサービス中規模開発者 32 名規模インフラ 4 名管理その他 23 名計 59 名手法 XP 契約準委任契約 ( 四半期毎に更新 ) 期間開発拠点 2 年東京地方を含めた 3 拠点特徴的なプラクティス日次ミーティング : 複数のチームが存在したため二段階の構成で実施していた ( チーム間チーム毎 ) ふりかえり : チーム毎に実施した場合には他のチームへの不満などばかりになってしまい機能しなかったそのために複数チームの混成で実施することにより問題へ集中するように意識を変えさせたまた反復毎のふりかえりとは別に四半期単位でも実施して大きな改善点について話しあった顧客プロキシ : 当初は顧客に要件管理をしてもらっていたが機能しなくなったため C 社の社員が顧客の会社へ出向して顧客プロキシとなり全面的に支援した 45

43 リファレンスガイド活用のポイント (1) (1) 短納期開発期間が短い開発対象のボリュームに比して開発期間が短い場合チームの開発速度を計測しそのスピード感で予定している開発量が期限内に完了するのか常に点検する必要があるためベロシティ計測とバーンダウンチャートを活用するベロシティ計測は関係者であるプロダクトオーナーが理解できる基準で計測する必要がある (H 社事例 (11)) バーンダウンチャートは関係者と定期的に共有する機会を設けることが活用のポイントである (B 社事例 (2) J 社事例 (17)(18)) (2) スコープの変動が激しい開発中に要求の変更が頻繁に発生することが予想されるプロジェクトではチームが扱う要求の全体像と状態直近のイテレーションで何を開発するかが分かっており柔軟に優先順位を変えられる必要があるためプロダクトバックログ ( 優先順位付け ) スプリントバックログおよびプロダクトオーナーを活用するプロダクトバックログ ( 優先順位付け ) はイテレーション毎に整理を行いチーム全員で優先順位と内容を合意すると良い (B 社事例 (2)) プロダクトオーナーは業務や全社的に全体最適となる判断を行うこと (G 社事例 (10)) (3) 求められる品質が高い品質要求が高いプロジェクトではテストに関するプラクティスである自動化された回帰テストユニットテストの自動化を活用する自動化された回帰テストやユニットテストの自動化はプロジェクトの初期段階で実施有無実施のための取決め使用ツールを検討しておくことがポイントであるこれを後回しにすると必ず機能開発が優先され自動化にたどりつかない (B 社事例 (2)) 46

44 リファレンスガイド活用のポイント (2) (4) コスト要求が厳しい必要のないものを作るムダをなくし必要なものをより素早く提供することが ROI( 費用対効果 ) の向上につながりコスト要求に応えることができるそのためには的確に顧客の要求を把握し認識の相違をなくす必要があるためプロダクトバックログ ( 優先順位付け ) を活用するまた開発機能がプロダクトオーナーの意図通りになっているか否かの検証のために受入テストを活用するオンサイト顧客には優先順位や仕様の確認がその場で確認することができ迅速に方針を決められるというメリットがある (K 社事例 (20)) (5) チームメンバーのスキルが未成熟スキル的に未成熟なメンバーが成長していく機会としてプロジェクトを計画する必要があるためペアプログラミングとふりかえりを活用するペアプログラミングはベテランとメンバーが一緒に仕事をすることで技術的な指導を行うのに適したプラクティスである (C 社事例 (4)) ふりかえりはメンバーの成長の機会として捉えることができるふりかえりのやり方自体も見直しながらチームに適したやり方を模索すると良い (E 社事例 (6)) (6) チームにとって初めての技術領域や業務知識を扱うプロダクトの背景にある業界の知識や要求の理解と実装に必要な業務知識の獲得が必要となるためスパイクソリューションとシステムメタファを活用するスパイクソリューションを適用することはリスクとなりそうな技術課題についてプロジェクトの初期段階で実験的に小さく試しておくことでありチームとプロジェクトを後々助けることに繋がる (C 社事例 (4)) システムメタファは開発者にとってなじみの薄い業務知識を理解する手段として有効と考えられる 47

45 リファレンスガイド活用のポイント (3) (7) 初めてチームを組むメンバーが多い初めてチームを組むメンバーが多い場合チームが向かう方向を明確にすることとチームビルディングが必要となるためインセプションデッキやニコニコカレンダーを活用するインセプションデッキは作成を通じてプロジェクトの目的や目標が明らかとなる (B 社事例 (1)) ニコニコカレンダーはメンバーの感情や状況を可視化しチームメンバーのことを知ることがポイントになる (E 社事例 (6)) (8) オフショアなど分散開発を行うプロダクトオーナーと開発チームが別の拠点にいる場合オンラインでのコミュニケーション手段を検討し頻繁にコミュニケーションが取れるようにする必要があるため日次ミーティングや顧客プロキシを活用する TV 会議システムを使った日次ミーティングは離れた者同士が毎日顔を合わせる機会としてぜひ活用するべきである (G 社事例 (9)) 顧客プロキシは分散した環境下でも迅速なフィードバックが得られる工夫をしなければならない (9) 初めてアジャイル開発に取り組む初めてアジャイル開発に取り組む際には書籍や文書だけではなく人から人にやり方を伝えることが有効であるため社内にアジャイル開発に取り組んだ経験のある人がいる場合はその人に社内にない場合は社外からアジャイルコーチを頼んで導入の手伝いをしてもらうのがよい初めて取り組む場合はイテレーション期間を短くした上でふりかえりの中で改善点をチームで考え実行していくことが不可欠となる 48

46 アジャイル開発プラクティス活用リファレンスガイド事例一覧 (1) 調査先 No. 採用手法 [ 1] 特徴システム種別契約関係 [ 2] 開発言語 A 社 B 社 0 Scrum+XP B2C サービス ( 広告配信 ) 自社開発 Java, PHP, Perl 1 Scrum+XP B2C サービス ( 広告配信 ) 自社開発 Ruby 2 Scrum+XP B2C サービス (SNS) 自社開発 Java 3 Scrum+XP B2C サービス ( メール配信 ) 自社開発 Java C 社 4 XP+WF 中規模 B2C サービス ( メール配信 ) 受託開発 ( 準委任 ) Java D 社 5 XP B2C サービス (SNS) 自社開発 Java, PHP, Ruby E 社 6 Scrum 初導入社内システム自社開発 C# 7 Scrum+WF 中規模社内システム受託開発 ( 請負 ) Java, COBOL F 社 8 Scrum+WF 中規模社内システム自社開発 C# G 社 H 社 9 Scrum+XP 初導入社内システム実証事業 Ruby 10 Scrum+XP 社内システム受託開発 ( 請負 ) Ruby 11 Scrum B2C サービス ( 音楽配信 ) 12 Scrum B2C サービス ( エンターテイメント ) 13 Scrum 社内システム 14 Scrum B2C サービス ( ヘルスケア ) 自社開発 + オフショア ( 準委任 ) 自社開発 + オフショア ( 準委任 ) 自社開発 + オフショア ( 準委任 ) 自社開発 + オフショア ( 準委任 ) Java, C#, Objective-C Java, C#, Objective-C Java C# 49

47 アジャイル開発プラクティス活用リファレンスガイド事例一覧 (2) 調査先 No. 採用手法 [ 1] 特徴システム種別契約関係 [ 2] 開発言語 I 社 15 Scrum 中規模 ( 組織展開 ) B2C サービス ( 広告配信 ) 自社開発 Java, Objective-C 16 XP B2C サービス ( スマートフォンアプリ ) 受託開発 ( 請負 ) Java J 社 1:XP: エクストリームプログラミング Scrum: スクラム WF: ウォーターフォール UP: 統一プロセスもしくはこれらの手法の組み合わせ 17 XP B2C サービス ( クラウド基盤 ) 受託開発 ( 請負 ) Java 18 XP B2C サービス ( クラウド基盤 ) 受託開発 ( 請負 ) Java 19 XP B2C サービス (PaaS) 受託開発 ( 請負 ) Java K 社 20 Scrum B2C サービス (EC サイト ) 受託開発 ( 請負 ) PHP L 社 21 Scrum+UP 社内システム受託開発 ( 請負 ) Java 22 Scrum+WF 大規模社内システム中大規模 (30 名以上 ):6 件初導入 :2 件受託開発 ( 準委任 ) 23 Scrum+WF 技術評価受託開発 ( 請負 ) Java 24 Scrum パッケージ M 社 25 Scrum 大規模 ( 組織展開 ) 自社開発 + オフショア ( 請負 ) Java B2C サービス ( ソーシャルゲーム ) 自社開発 Perl 2: 自社開発自社組織内に開発部隊あり一部パートナー ( 派遣 ) 受託開発自社組織内に開発部隊なし外部ベンダに発注している C# 全 26 事例 50

48 アジャイル開発プラクティス活用リファレンスガイドプラクティス一覧 (1) カテゴリサブカテゴリプラクティス説明プロセスプロダクトリリース計画ミーティングプロダクトリリースのためのリリース計画ミーティングイテレーション ( スプリント ) ごとのリリース計画やアクティビティなどを計イテレーション計画ミーティング画するミーティングイテレーションゴールや結果にアプローチするプロセスを繰り返すことプランニングポーカースプリント計画時のタスクを見積もるためのプランニングポーカーベロシティ計測プロジェクトベロシティの計測プロセス日次ミーティング現在の問題を解決するための短いデイリーミーティングふりかえり前のスプリント ( イテレーション ) から学ぶためにふりかえるかんばんジャストインタイムの継続的なデリバリを強調した管理手法スプリントレビュー完了した仕事を表明するスプリントレビューミーティングタスクボード ( タスクカード ) ボードに貼られたメンバーが継続的に更新するタスクバーンダウンチャートスプリント進捗をモニターするためのバーンダウンチャート柔軟なプロセス状況や環境の変化に対応できる柔軟なプロセスにしているもしくはプロセスを柔軟に変更しているユーザーストーリー要求についての会話を行うときの開発チームとプロダクトオーナーの間の合意事項プロダクトオーナーとチーム間でのスプリントバックログへの相互コミットスプリントバックログプロダクトメントインセプションデッキ 10の質問によりプロジェクトの属性を明らかするプロダクトバックログ ( 優先順位付け ) プロダクトオーナーによる優先順位 ( プロダクトバックログ ) の管理フィードバック迅速なフィードバック迅速なフィードバックを得られるような取組みを行っている 51

49 アジャイル開発プラクティス活用リファレンスガイドプラクティス一覧 (2) カテゴリサブカテゴリプラクティス説明技術ツールペアプログラミングすべての製品コードはペアプログラミングで開発している自動化された回帰テスト自動化された回帰テストを行っているテスト駆動開発単体テストを書きそのテストを通るようなコードを実装するユニットテストの自動化ユニットテストの自動化受入テスト受入テストの実施とその結果を公開しているシステムメタファ関係者全員がそのシステムがどのように動くかについて伝えることができるストーリー設計開発リスクを軽減するために隠れた問題を探索するための簡単なプログスパイクソリューションラム ( スパイクソリューション ) の試作リファクタリング定常的なリファクタリングシンプルデザイン設計をシンプルに保つ逐次の統合一度に統合するコードはひとつだけとする継続的インテグレーション継続的インデグレーションまたは頻繁なインテグレーション集団によるオーナーシップ全員がすべてのコードに対して責任を持つコーディング規約同意された標準のためのコーディング規約障害対応バグ時の再現テストバグが見つかったときそのテストがまず最初に作られる利用ツール紙手書きツールポストイット ( 付箋紙 ) やCRC(class-responsibility-collaboration) カードなどの使用 52

50 アジャイル開発プラクティス活用リファレンスガイドプラクティス一覧 (3) カテゴリサブカテゴリプラクティス説明チーム運営組織チーム環境顧客プロキシ要件や仕様をまとめるために顧客の業務に精通した顧客プロキシの設置オンサイト顧客顧客といつでも / 定期的にやりとりが可能であるプロダクトオーナープロダクトオーナー役の設置人ファシリテータ ( スクラムマスター ) スクラムマスターによる開発プロセスとプラクティスのファシリテーションアジャイルコーチアジャイルコーチがプロジェクトに参加している自己組織化チームチームメンバーがタスクに志願するなど自律的なチームになっているニコニコカレンダーニコニコカレンダーを用いてメンバーの気持ちを見える化している進め方持続可能なペース継続的なペースで開発している組織導入組織にあわせたアジャイルスタイル組織にあった適切なアジャイルスタイルを用いるようにしている共通の部屋オープンスペースがチームに与えられているファシリティワーチーム全体が一つにチーム全員がひとつのゴールに向かうような取組みを行っているクスペース人材のローテーション多能工の育成などのため人材のローテーションを行っているインテグレーション専用マシン特定のインテグレーション用コンピュータ 53

51 参考データアジャイル開発を用いる技術者業務において最もよく用いられる開発プロセス ( 技術者別 ) 出典 : IT 人材白書 2014,IPA,2014 年 4 月 25 日. 54

参考業務運用とアジャイル開発環境経営業務顧客サプライチェーン環境変化 ( 顧客市場技術政策 ) 企業価値経営業務の運営業務運営企業価値業務の改革改善経営 (CIO 含む ) 経営 (CIO 含む ) 業務改善ニーズ業務改革企画 IT 企画新規開発拡充開発 ( 完全化保守 ) SLCP でカバーしているプロセス業務開発 1 業務改革プロジェクト業務設計

52 参考業務運用とアジャイル開発環境経営業務顧客サプライチェーン環境変化 ( 顧客市場技術政策 ) 企業価値経営業務の運営業務運営企業価値業務の改革改善経営 (CIO 含む ) 経営 (CIO 含む ) 業務改善ニーズ業務改革企画 IT 企画新規開発拡充開発 ( 完全化保守 ) SLCP でカバーしているプロセス業務開発 1 業務改革プロジェクト業務設計全体最適運用開発運用という流れで全体を捉えるべき教育 / 移行システム SW SLA SLA 管理サービスデスクインシデント問題管理キャパシティ管理オペレーション管理機能 IT 運用構成情報改革改善サイクル業務改革等への参加保守開発 ( 適応保守 ) 移管 / 移行 IT 取得構成情報要件定義 /SLA 定義設計開発 / 構築テスト移行 I T プロジェクト管理このサイクルを短期間でまわす 2 サービスマネジメント組織的支援 IT の運用 IT の改革改善 IT 開発出典 : 共通フレーム

53 参考要求変化対応ソフトウェアアーキテクチャ ( マイクロサービス 1/2) 従来のモノリシックタイプマイクロサービス複数の小さなサービスを組み合わせてアプリケーションを構築各サービスは独立にデプロイされ, 疎結合で独立動作. < 出典 > James Lewis: Microservices, ThoughtWorks, 25 March

54 参考要求変化対応ソフトウェアアーキテクチャ ( マイクロサービス 2/2) マイクロサービスの特徴俊敏な変更が可能必要なサービスのみ, 変更置換他のサービスへの影響の考慮不要置換対象サービス 1 軽量な, 標準インタフェース独立チームで特徴を活かすサービス 2 サービス 3 制約が少なく, 工夫挑戦する意識の高まり責任の明確化サービス 4 サービス 5 < 課題 > 不得手な制御もあるトラブル時の対応に配慮要開発運用の効率化のための支援環境が重要 57

55 参考 DevOps とマイクロサービスへの関心の高まり図 1 キーワード : DevOps と microservices の使用数の増加 (a Google Trends report に基づく ) < 出典 > Armin Balalaie, Abbas Heydarnoori and Pooyan Jamshidi: Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture, IEEE Software, Vol.33, No.03, pp: 42-52, May-June

本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 2

本日の講演内容 1. ICTシステムの進展 2. IoT(Internet of Things) の時代では IoT 時代に求められる, アジャイルな活動 4. 組込みシステム開発とアジャイル 5. まとめ 2 IoT 時代に向かい, 進化し続けるアジャイル ~ 来たるべき商品 / サービス競争時代を勝ち抜くために ~ ブースプレゼン @ET West IPA ブース 2016 年 7 月 7 日 Information-technology Promotion Agency, Japan 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 山下博之 http://www.ipa.go.jp/sec/index.html