プロローグ ビジネスを取り巻く状況と IT 2

Transcription

1 アジャイル開発の現状と課題 ~ アジャイル開発への関心の高まりに応えるために ~ SEC セミナー 2015 年 7 月 8 日 Information-technology Promotion Agency, Japan 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 山下博之

2 プロローグ ビジネスを取り巻く状況と IT 2

3 ビジネスの 3 要素 5 ビジネスの 3 要素 ヒト ビジネスの 4 要素 ビジネスの 5 要素 モノカネ情報時間 Business Intelligence BigData 変化対応の俊敏性 (Agility) 3

4 参考データ システム開発における QCD の優先順位 システム企画工程における QCD の優先順位 品質 : 29(28,29)% コスト : 23(23,24)% 納期 : 48(49,47)% 調査で収集した 1021(918,801) プロジェクトのうち, QCD のうちのどれかを優先した という回答 (446(377,313) プロジェクト ) の内訳 [() 内は前年度, 前々年度の結果 ] < 出典 > ソフトウェアメトリックス調査 2014(2013,2012), 一般社団法人日本情報システム ユーザー協会 (JUAS). そうした事業環境の中, いわゆる QCD のうち, 特に納期を重視してものづくりを進めている. 品質の確保は当たり前. 開発 製造期間を短縮して製品の投入スピードをいかに速くできるかが, 世界を相手に競争優位を築くカギになる. < 出典 > CIO の哲学 : 三菱重工業児玉敏雄氏, 日経コンピュータ,

5 参考データアジャイル開発手法の導入理由 ( 海外 _2014 年 ) 40% 35% 30% 25% 20% 15% 10% 5% 32% 27% 23% 19% 1.Time-to-Market の加速 2. 変化する優先順位管理のため 前回調査と同傾向 18% 15% 12% 10% 8% 7% 7% 5% 4% 0% 加速 Time-to-Market の 管変理化のすたるめ優先順位 融合改善 IT とビジネスの 生産性向上 の向上 ソフトウェア品質 見える化 プロジェクトの リスク削減 コスト削減 簡易化 開発プロセスの やる気改善 チ向ー上ムの 保守性 / 拡張性 の導入 / 向上 エンジニアリング 分散チーム管理 (VersionOne 社アジャイル開発の現状調査第 8 回 2014 より ) 5

6 参考データアジャイル開発手法の導入理由 ( 海外 _2015 年 ) 60% 55% 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 59% 56% 53% Time-to-Market ( ) 製品出荷 の加速 管理のため 変化する優先順位 生産性向上 46% の向上 44% ソの製融見フ向品合とトえ上出改ビウジる荷ェ善ネ化ア予品測スの質力 上位は前回調査と同傾向 製品出荷予測力の向上 が新規 40% 40% 38% IT プロジェクトの リスク削減 26% やる気改善 チームの 25% の導入 / 向上 エンジニアリング 23% コスト削減 22% 向保上守性 / 拡張性 20% 分散チーム管理 (VersionOne 社アジャイル開発の現状調査第 9 回 2015 より ) 6

7 開発 ( 構築 ) 手法の選択環境の変化に対する俊敏な開発 ( 構築 ) が求められる場合俊敏な開発 ( 構築 ) 手法 少しずつ作って, 確かめながら a. 非ウォーターフォール型開発 ( アジャイル開発 ) b. クラウドコンピューティング 作らないで, 使う 超高速開発 パラメータを変更するだけ c. 自動コード生成 / ビジネスルールマネジメントシステム (BRMS) 1つのシステム全体を単一の手法で開発 ( 構築 ) する異なる手法で開発したことが適切ではない ( ケースもある )? SECセミナー ( ) 部品の組合せ? 7

8 重視事項は対象 ビジネス状況により異なる IT システムの対象や, それを使うビジネスの状況に応じ, 重視する評価ポイントは異なる 8

9 IT システムのクラスと特徴 高信頼重要インフラ等 ITシステム対象は拡大傾向共通基盤系短納期ビジネス戦略 ITシステム ( 変化俊敏対応 ) サービス系 ( 高速開発 ) 業務支援 ITシステム 各クラスに対応した 比較的長期間, そのまま運用 障害発生時の社会的影響大 一般利用者の厳しい反応 適切なアーキテクチャと, 構築 運用体制及び手法 従来のアジャイル開発の主対象 先を見通しにくい 激しい環境変化 競争優位の確保 9

10 参考データ システム構築時の重視事項 システム構築時の重視事項 (1,2 位の合計 %) 基幹系 業務支援情報系 Web フロント系 管理業務系 データ数 品質, 継承性重視 品質 コスト 開発スピード 変更容易性 継承性 開発スピード, 変更容易性重視 重要インフラ等 IT システム,Bsys( 共通基盤系 ) ビジネス戦略 IT システム ( サービス系 ) < 出典 > IT 動向調査 2014, 図表 8-3-1, 一般社団法人日本情報システム ユーザー協会 (JUAS). 10

11 ビジネス ステージと開発手法 ソフトウェア製品のライフサイクル モデル例と開発手法 アジャイル ウォーターフォール A financial model of software product development. < 出典 > Ram Chillarege: The Marriage of Business Dynamics and Software Engineering, IEEE SOFTWARE, November/December

12 価値 で決まる IT プロジェクトの成功は, もはや QCD ではなく, ( 顧客側の ) 価値や満足で決まる < アジャイル開発の特徴 > ( 顧客 ) 価値 駆動型 12

13 参考データ 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% 13

14 アジャイル開発の適用は増えている 日本でも, アジャイル開発の導入は進んでいる 14

15 参考データ アジャイル開発の適用状況 - 国内 -(1) 2010 年 12 月 2 日横浜 (72 名 ) 14% 24% 13% 0% 1% 4% 9% 48% 39% 26% 3% 3% 1% すべてのプロジェクトに適用している 0% ほとんどのプロジェクトに適用している 8% だいたいのプロジェクトに適用にしているほとんどのプロジェクトに適用していないすべてのプロジェクトで適用していない 38% 分からない無回答 47% ~IPA/SEC セミナー聴講者アンケート結果から ~ 多くのプロジェクトで使っている一部のプロジェクトで使っている使いたいと考えているが実現していない使う予定はないよく分からない / 関係ないその他無回答 3% 3% 3% 4% 5% 0% 1% 4% 3% 4% 6% 5% 8% 8% 47% 38% 29% 51% 2011 年 11 月 18 日横浜 (109 名 ) 2012 年 10 月 24 日東京 (76 名 ) 2013 年 3 月 18 日東京 (104 名 ) SECセミナー ( ) 15

16 参考データアジャイル開発の適用状況 - 国内 -(2) アジャイル開発を使っていますか? 2% 4% 27% 2% 9% 2% 54% 多くのプロジェクトで使っている一部のプロジェクトで使っている使いたいと考えているが実現していない使う予定はない よく分からない / 関係ないその他 10.2% 60.4% 無回答 2013 年 10 月 30 日東京 (55 名 ) アジャイルジャパン 2014 ( , 東京 ) 参加者アンケート (265 名 ) 16

17 参考データアジャイル開発の適用領域状況 ( 例 ) アジャイルジャパン 2014 ( ) 参加者アンケート (265 名 ) 17

18 参考データアジャイル開発の導入状況 - 海外 -(2013 年 ) 海外企業におけるアジャイル開発の導入状況 ( アジャイル開発を導入している企業のうち ) アジャイル開発を行っている期間 導入していない 16% 1 年未満 12% 5 年以上 14% 導入している 84% 1-2 年 38% 2-5 年 36% VERSIONONE : 7 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

19 参考データアジャイル開発の導入状況 - 海外 -(2014 年 ) 海外企業におけるアジャイル開発の導入状況 ( アジャイル開発を導入している企業のうち ) アジャイル開発を行っている期間 導入していない 12% 1 年未満 8% 5 年以上 19% 導入している 88% 1-2 年 40% 2-5 年 33% 海外でのアジャイル開発の導入も拡大傾向 VERSIONONE : 8 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

20 参考データアジャイル開発の導入状況 - 海外 -(2015 年 _1) 海外企業におけるアジャイル開発の導入状況 ( アジャイル開発を導入している企業のうち ) アジャイル開発を行っている期間 導入していない 6% 1 年未満 15% 5 年以上 24% 導入している 94% 1-2 年 29% 3-5 年 32% 海外でのアジャイル開発の導入も引き続き拡大傾向 VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

21 参考データアジャイル開発の導入状況 - 海外 -(2015 年 _2) アジャイル開発を導入しているチームの割合 全て 9% 無し 5% 半分以上 36% 半分以下 50% VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

22 アジャイル開発の導入ができていない組織も多い しかし, アジャイル開発を導入できていない組織は, いまだに少なからずある 22

23 参考データ アジャイル開発の適用状況 - 国内 -(3) 2010 年 12 月 2 日横浜 (72 名 ) 0% 1% 4% 14% 24% 9% 48% 3% 3% 1% すべてのプロジェクトに適用している 0% ほとんどのプロジェクトに適用している 8% だいたいのプロジェクトに適用にしているほとんどのプロジェクトに適用していないすべてのプロジェクトで適用していない 38% 分からない無回答 47% 多くのプロジェクトで使っている一部のプロジェクトで使っている使いたいと考えているが実現していない使う予定はないよく分からない / 関係ないその他無回答 3% 3% 5% 1% 4% 4% 3% 0% 3% 4% 6% 5% 8% 8% 26% 38% 13% 39% ~IPA/SEC セミナー聴講者アンケート結果から ~ 47% 29% 51% 2011 年 11 月 18 日横浜 (109 名 ) 2012 年 10 月 24 日東京 (76 名 ) 2013 年 3 月 18 日東京 (104 名 ) SECセミナー ( ) 23

24 参考データアジャイル開発の適用状況 - 国内 -(4) 2% 4% アジャイル開発を使っていますか? 27% 2% 9% 2% 54% 多くのプロジェクトで使っている一部のプロジェクトで使っている使いたいと考えているが実現していない使う予定はないよく分からない / 関係ないその他無回答 16.8% 3% 0% 4% 43% 0% 50% 2014 年 11 月 12 日東京 (28 名 ) 年 10 月 30 日東京 (55 名 ) 1% 6% 7% 6% 32% 2% 46% 2014 年 12 月 17 日東京 (68 名 ) アジャイルジャパン 2014 ( , 東京 ) 参加者アンケート (265 名 ) 24

25 参考データアジャイル開発の実績 着手意向調査例 実績 着手意向 SI 実績 着手意向 指数 指数 順位 順位 L. アジャイル開発 / 反復型開発 L. ウォーターフォール開発 ( 参考 ) 2013 年度版 L. アジャイル開発 / 反復型開発 L. ウォーターフォール開発 アジャイル開発の実績がやや減少. 着手意向は依然高い. < 出典 > JISA 報告書 (26-J008) 概要情報サービス産業協会 概要平成 26 年度情報サービス産業における技術マップに関する調査報告 6 付録要素技術の実績指数 着手意向指数一覧 (2014 年度版 ) 25

26 26 18% 12% 11% 9% 6% 6% 6% 4% 0% 5% 10% 15% 20% 企業哲学又は文化との相性手法への不慣れ分からない従来型開発採用への外部圧力チーム内での反発文化的な移行の欠如マネジメントの支援の欠如不十分なトレーニング (VersionOne 社アジャイル開発の現状調査第 7 回 2013 より ) 参考データ 11% 8% 6% 3% 失敗なしその他導入直後のため ( 初心者 ) 組織管理 コミュニケーション上の問題 失敗なし が最多 1. 企業哲学 文化との相性 2. 従来型開発採用への外部圧力 3. 組織管理 コミュニケーション上の問題アジャイル型開発プロジェクトの失敗理由 ( 海外 )

27 27 15% 13% 10% 7% 5% 3% 0% 5% 10% 15% 20% 企業哲学又は文化との相性手法への不慣れ分からない従来型開発採用への外部圧力チーム内での反発文化的な移行の欠如マネジメントの支援の欠如不十分なトレーニング 11% (VersionOne 社アジャイル開発の現状調査第 8 回 2014 より ) 10% 9% 3% 失敗なしその他導入直後のため ( 初心者 ) 組織管理 コミュニケーション上の問題 失敗なし が減少 手法への不慣れ が 2 ランクアップ 7% 7% 参考データアジャイル型開発プロジェクトの失敗理由 ( 海外 )

28 参考データアジャイル型開発プロジェクトの失敗理由 ( 海外 ) 50% 手法への不慣れ がさらに2ランクアップ 44% トップに! 40% 30% 20% 10% 0% 手法への不慣れ 42% 文化との相性 企業哲学又は 38% 支援の欠如 マネジメントの 37% への外部圧力 従来型開発採用 36% 欠如 文化的な移行の 33% プラクティス活用リファレンスガイド 33% 30% ケーション上の問 組織管理 を用いてアジャイル開発手法に慣れよう 反チ発ーム内での トレーニング 不十分な 6% 分からない その他 マネジメントの支援の欠如 も大幅 (6 ランク ) アップ コミュ題ニ (VersionOne 社アジャイル開発の現状調査第 9 回 2015より ) 28

29 本日の講演内容 1. ふり返り (IPA/SEC の取組み ) (1) アジャイル開発の特徴 (2) アジャイル開発の適用領域 (3) 顧客及び経営層の理解 (4) アジャイル開発人材 (5) アジャイル開発の契約 スキップ 2. アジャイル開発プラクティス活用リファレンスガイド 3. 組込み機器 システムとアジャイル開発 4. アジャイル開発の課題 本日のフォーカス 29

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

31 IPA/SEC の取組み : ステークホルダと検討項目 顧客 経営層の理解促進 顧客 ( ユーザ企業 ) アジャイル型開発にふさわしい契約モデル 契約書案 ベンダ企業 経営層 契約部門 契約部門 経営層 業務部門 情報システム開発運用部門 開発部門品質保証部門 人事部門育成部門 アジャイル型開発に必要な技術及びスキル 人材育成方法 31

32 対象等に応じてソフトウェア開発手法を選択する ソフトウェア開発においては, 開発対象と組織 プロジェクトの特徴に応じた 適切な形態 手法の選択が重要 < 参考 > 非ウォーターフォール型 ( アジャイル ) 開発の動向と課題,SEC journal, Vol.8, No.4, Dec アジャイル開発に関する IPA/SEC の検討結果等は : 32

33 (1) アジャイル開発の特徴 アジャイル開発のプロセスは, 大きく 3 つのモデルに分類される 33

34 アジャイル開発のモデル - プロセスの対応 - < 標準 > ソフトウェアライフサイクルプロセス (SLCP) 要求 開発 テスト ( 部品 ) 注 ) 図形のサイズは意味を持たない ( 時間, 規模を表さない ). < 実際 > 要求開発テスト ウォーターフォール型 大きなプロセスを順に実施し, それを 1 回で終了 アジャイル型 小さなプロセスを行き来しつつ実施し, それを何回も反復 注 ) 図形のサイズは意味を持つ. 34

35 調査事例から導かれた開発プロセス モデル (1) モデル 1 システム運用 企画 要求 開発 テスト 要求 開発 テスト 要求 開発 テスト 要求 開発 テスト 要求 開発 テスト 要求 開発 テスト 第 1 反復 第 n 反復 第 1 反復 第 n 反復 第 1 反復 第 n 反復 第 1 リリース n=1 のケースもあり 第 2 リリース 第 m リリース 考え方シンプルな基本形 35

36 調査事例から導かれた開発プロセス モデル (2) モデル 2 システム運用 企画 要求 アーキテクチャ設計 基盤開発 要求 開発 テスト 第 1 反復 要求 開発 テスト 第 n 反復 要求 開発 テスト 第 1 反復 要求 開発 テスト 第 n 反復 比較的大規模システム / 新規開発で全体のシステム構造が不明確なケースなど 第 1 リリース 考え方拡張形. 基盤 共通部といくつかの機能部とから構成されるソフトウェア ( 右図 ) において, 最初にまず, 基盤 共通部の開発を終えた後, 機能部群について, アジャイル開発を行う. 基盤 共通部が確固としていないと, 追加 変更時の機能部への影響が大きくなりすぎることを避ける. アジャイル開発では, 基盤 共通部の変更は, 原則として行わない. 第 m リリース 機能 1 機能 2 機能 3 機能 4 基盤 共通部 36

37 調査事例から導かれた開発プロセス モデル (3) モデル 3 システム運用 企画 要求 開発 テスト 第 1 反復 要求 開発 テスト 第 n 反復 リリース前テスト 要求 開発 テスト 第 1 反復 要求 開発 テスト 第 n 反復 リリース前テスト 第 1 リリース 第 m リリース アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが 各リリース工程前に行う重点的なテストを実施することがある リリースは複数回繰り返される 考え方顧客やビジネスの特徴から, 特に高い品質が求められたり, 品質がクリティカルであったりする場合に, リリース前に品質確保のための特別のアクションを実施する. 37

38 分析ウォーターフォール型とアジャイル型との手法の違い ウォーターフォール型 ( 開発が ) 失敗しないための手法 プロセス 重視 文化が異なるケースバイケースで使い分け アジャイル開発 ( ビジネスが ) 成功するための手法 人 重視 計画 駆動型 ( 顧客 ) 価値 駆動型 作るものも使用する技術も明確例 ) ビルや橋の建設 最初から綿密な計画を立て計画に従って着実に進める. 計画時には, ビジネス上, システム上の課題が未解決, 開始後も変更の可能性大 少し試して, その結果に基づいて次のステップを進める. 多くの組織, チーム, 個人にとって, アジャイル開発プロセスへの転換は 挑戦的 である. それは, ある種の文化的変革を必要とするからだ.[Agile transformation, IBM] アジャイルは, プロセスではなく文化である. Michael Sahota: An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture,

39 開発プロジェクトのパラメータ間の関係 スコープ ( 要求 ) のサイズが品質に影響 Q: 品質 参考 QCD の優先順位 固定 S: スコープ (R: 要求 ) 計画駆動 見積り 実際には変動 C: コスト D: 納期 Q: 品質品質を維持しようとするとコストと納期に影響 固定 C: コスト 価値駆動 S: スコープ (R: 要求 ) D: 納期 固定 各機能の価値 優先順に従って変動 優先度の低い機能は実装しても結局は使われない 無駄な実装はしない 機能 1 実装範囲 機能 2 機能 3 : 機能 M 要求 ( 優先順 ) : 全体の価値 機能 N 39

40 参考データ システム機能の利用度 ( 要求の劣化 ) よく使う 13% システムの機能の利用度 いつも使う 7% たまに使う 16% ほとんど使われない 19% 全く使われない 45% < 出典 > Standish group study report in 2000 chaos report ( 平鍋健児氏のプレゼン資料掲載 ) 40

41 (2) アジャイル開発の適用領域 アジャイル開発には, その5つの特徴から, 3つの適用領域と,4つの試行領域があるそして, 試行領域への適用が徐々に進み, 適用領域は拡大しつつある 41

42 アジャイル開発の適用領域 試行領域 アジャイル開発は 顧客の参画の度合いが強い 動くソフトウェアを成長させながら作る 反復 漸進型である 人と人のコミュニケーション コラボレーションを重視する 開発前の 要求の固定を前提としない という特徴を持つ 全てのソフトウェア開発に これらの特徴を有するアジャイル開発手法を適用できる あるいはすべきだ という立場ではない ビジネスや市場 その他の開発の コンテキスト によって ウォーターフォール型の開発が適している場面もあれば アジャイル型の開発が適している場面もある 42

43 アジャイル開発の適用領域 アジャイル開発が得意とし 現在 その適用により効果を挙げている領域 : 1 ビジネス要求が変化する領域 要求の変化が激しく, あらかじめ要求が固定できない領域 2 リスクの高い領域 不確実な市場を対象としたビジネス領域 ( 市場リスク ) 技術的な難易度が高い開発領域 ( 技術リスク ) 3 市場競争領域 他社に先駆けた製品 サービス市場投入が命題であり,TTM(Time to Market) の短縮が優先となる領域 (Web のサービス, パッケージ開発, 新製品開発 ). 43

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

45 参考中 大規模開発の事例一覧 (H23 年度調査 ) No. 規模 部分適用 採用手法対象システム種別契約 1 大独自 B2C サービス (SNS) 無 ( 自社内 ) 2 大 Scrum B2C サービス ( ソーシャルゲーム ) 無 ( 自社内 ) 3 大 Scrum ゲームソフト受託 ( 未公開 ) 4 大 Scrum+ 独自基幹システム受託 ( 準委任 ) 5 中 Scrum B2C サービス ( 会員サービス ) 無 ( 自社内 ) 6 中 Scrum+XP B2C サービス ( 医療 健康 ) 無 ( 自社内 )+ オフショア * 7 中 Scrum+XP B2C サービス ( エンタテインメント ) 無 ( 自社内 )+ オフショア * 8 中 XP B2C サービス ( 会員サービス ) 受託 ( 請負 ) 9 中 XP B2C サービス (EC サイト ) 受託 ( 請負 ) 10 中 XP B2C サービス ( 会員サービス ) 受託 ( 準委任 ) 中規模 :30~100 名, 大規模 :100 名以上独自 : 特に手法を決めず自ら定義,Scrum+XP: 両手法を組み合わせて実践 *: 準委任 < 出典 > 45

46 適用にあたっての主な工夫 (1/3: 一覧 ) 中 大規模開発特有の工夫 組織体制 チーム間ローテーション コミュニケーション 段階的朝会 チーム跨ぎのふりかえり 展開 漸進的な人数増加 漸進的な展開 社内勉強会 分散拠点開発 同一拠点から分散へ TV 会議 アーキテクチャ 組織の共通基盤アーキテクチャの利用 アーキテクチャについての教育 システム分割 / インテグレーション 同じリズム 品質 第三者テスト 部分適用 必要な部分のみ適用 疎結合なチーム 工程の見える化 小規模開発とは逆のアプローチをとる工夫 アーキテクチャ 最初のアーキテクチャ構築 アーキテクチャ専門チーム 運用保守チーム 品質 テスト フェーズ 小規模開発と同様だが特に注意して実施する工夫 コミュニケーション 完全透明性 展開 パイロット導入 認定研修 コンサルタントの利用 分散拠点開発 チケットシステム リアルタイムチャット アーキテクチャ アーキテクチャの改善 システム分割 / インテグレーション 疎結合で分割 早期からのインテグレーション 継続的インテグレーション 品質 重視するビジネス価値 ビジネス価値の変化 タイムボックス優先の品質 自動単体テスト 46

47 適用にあたっての主な工夫 (2/3) 工夫例 (1/2) チーム間ローテーションチーム間の知識伝播促進のため, メンバのローテーションを行う. 一時的に速度は落ちるが, 各チームの知識を効率よく伝播でき多能工化が高まる. 段階的朝会複数チーム間は朝会を段階的に実施. チーム 全体 ( チーム ). 漸進的な展開一度にすべてのチームに広げるのではなく, まずは導入障壁の低いところ, 最も必要なところから順次導入し, 少しずつ展開. ふりかえりで, 次はどこに広げていけばいいかを考える. コミュニケーション ツールの活用 TV 会議システム, 雑記帳システム (SNS,Blog 等 ) 47

48 適用にあたっての主な工夫 (3/3) 工夫例 (2/2) アーキテクチャの重視プロジェクト前半にアーキテクチャを構築する事例が多く, アーキテクチャ専門チームを編成して構築. 構築されたアーキテクチャを組織の共通基盤とし, 再利用できるようにしている事例あり. 疎結合な機能分割疎結合な機能でサブシステム分割を行う. 7 割のチームが CI( 継続的インテグレーション ) を実施. テスト専用フェーズプロジェクト後半で専用のテストフェーズを実施. プログラム開発の反復を停止する事例と, テストのみの反復期間を設ける事例あり. 48

49 浮かび上がった問題点 主な問題点 全体計画の把握困難要求の変化や開発状況に応じて着手する順番や範囲を決めるため, プロジェクト開始時にプロジェクト全体の把握が困難な事例あり. ビジネス企画側にボトルネック発生スクラム導入の結果, ビジネス企画者の決定待ち等のボトルネックが発生した事例が多い. 中には開発者の信頼をなくした事例もあり. 反復リズムとの不適合状態の発生セキュリティ監査や外部テスト業者, 発注者の外部組織や関連組織との関係において, 反復リズムと適合せずに問題が発生している事例あり. 49

50 (3) 顧客及び経営層の理解 ユーザ ベンダ共に, 経営層の一層の理解が求められる 50

51 顧客 経営層は開発への一層の関与が必要 顧客 ( ユーザ ) 経営層 ビジネス環境が激しく変化する現状において,IT システムに関し, 従来のように情報システム部門に任せきりでは適切に対応できない. 開発形態 (*) にも深く関与する必要がある. (*) アジャイル開発の採用, クラウドコンピューティングの利用, など < 経営層の責任 > 情報システムに関する理解の増進 迅速かつ適切な意思決定 関係部門との経営上の綿密な調整 ベンダ経営層 俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには, 自ら俊敏な開発を実施できる体制作りに取り組むと共に, その結果を顧客に売り込む必要がある. 51

52 参考環境変化に即応できるための経営の 柔軟性 予測性 : 可変要素が将来変化をする予兆を事前にとらえること拡張性 : 既存のリソース ( 人, モノ, カネ, 情報等 ) に将来の可変要素を想定した余裕を持たせておくこと迅速性 : 起きた変化 / 起こすべき変化に対して, すぐに対応できること適用性 : これまでと違った環境 シチュエーションに, うまく対応できること < 出典 > 平成 22 年度経済産業省委託調査 : IT 経営普及促進に向けた調査研究 報告書, 社団法人日本情報システム ユーザー協会, 平成 23 年 2 月,p pdf 52

53 分析環境変化への対応体制 - IT システム構築 運用 ユーザ企業 情報システム部門任せ ( コスト 時間をかけて ) 信頼性重視で構築 市場の監視 業務部門主導 IT 投資判断 IT 予算執行 経営の 柔軟性 マインドの転換 ユーザ企業には, ビジネス イノベーションを実現し, 競争優位を維持しつつ持続するために, 変化が求められている. 53

54 ベンダ経営層は開発への一層の関与が必要 顧客 ( ユーザ ) 経営層 ビジネス環境が激しく変化する現状において,IT システムに関し, 従来のように情報システム部門に任せきりでは適切に対応できない. 開発形態 (*) にも深く関与する必要がある. (*) アジャイル開発の採用, クラウドコンピューティングの利用, など < 経営層の責任 > 情報システムに関する理解の増進 迅速かつ適切な意思決定 関係部門との経営上の綿密な調整 ベンダ経営層 俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには, 自ら俊敏な開発を実施できる体制作りに取り組むと共に, その結果を顧客に売り込む必要がある. 54

55 システム開発ベンダにも求められる 柔軟性 人材のクラウド 企画要求設計製造試験運用 親会社 子会社 多様性 子会社 協力会社 連携会社 孫会社 孫会社 孫会社 協力会社 ( 子会社 ) ウォーターフォール型 アジャイル型 ( 非ウォーターフォール型 ) 個人に求められるスキル : マルチタレント (IT 人材白書, 他 ) 55

56 (4) アジャイル開発人材 アジャイル開発に特徴的なスキル, 姿勢がある アジャイル開発の特徴は, 技術者のモチベーションのドライブ要因とマッチしている 56

57 参考データアジャイル開発のためのトレーニング アジャイルジャパン 2014 ( ) 参加者アンケート (265 名 ) 57

58 参考 アジャイル開発プロセスの流れ : スクラムの例 タスクボード ToDo Doing Done ビジネス戦略 < 出典 > 株式会社豆蔵堀江弘志 : 初めての取組み事例に見るアジャイル導入の勘所, JASA 主催 /IPA 共催セミナー,

59 アジャイル開発者に求められるスキル アジャイル開発における発注者側に求められること : ( 全ての機能の仕様を洗い出す能力よりも ) コアとなる機能を見定め, 優先度を図りながら開発プロジェクトの運営を指揮していく能力 明確な仕様を決めなくても良いとはいうものの, 定期的なサイクルで実物を見てフィードバックのポイントを増やすことにより, 実際のシステムを目で確認しながら, 積み上げるように仕様を決定していく アジャイル開発の開発者にとって重要なスキル : 1 プロジェクトのアウトプットに関わる判断ではなく, アジャイル開発の進め方を踏襲させるためのファシリテーションスキル 2 反復活動の中で, 実際に動くものを作りながら, 小規模に, かつトータルにプロジェクトのアウトプットを積み重ねていくスキル 3 設計, コーディング, テストを一貫して実施出来るスキル 59

60 アジャイル開発人材の育成の考え方 アジャイル開発を実践する活動項目 < アジャイル開発の実際 > 一つのプロジェクトで全てのプラクティスを使う訳ではない 各プラクティスに厳格な規範はない 様々な方法論 数あるプラクティスから, プロジェクトや組織に適したものを取捨選択し, カスタマイズすることが必要 ( 平時 ) 一通りのプラクティスを理解する ( プロジェクト参画時 ) 使用するプラクティスの習得 全てを完全に身につけるより, 価値に従って行動する習慣を確実に身につけることが重要 価値 原則 手法 60

61 参考人材育成の事例 - スケジュール 開発メンバ育成 プロジェクト立上げ 開発チーム育成 スキル診断 開発技術 ( 基礎知識 ) 開発できるレベルまで育てる 卒業検定 キックオフ プロジ ェクト セミナー ルーキーズ 模擬開発 OJT 開発者向け ストーリーオーナー向けも別途行う 構成管理 / その他ツール テスト駆動開発 オブジェクト指向プログラム / 設計 Java 言語 / Eclipse ア 行 プジ動ロャ指ジイ針ェルク概ト要憲章 ア 開 フ 業ジ発レ務ャ標ー知イ準ムルワ識基ー礎ク知識 開 チ 自発ー己環ム紹境ビ介知ルド識獲得 サブチーム単位に行う 作ったものは捨てる 育成開始 標準 1 ヶ月 ( 習熟度により前後 ) 組閣 参画 プロパー プロダクトオーナー パートナー 1 日 2~3 日 5 日 開発開始 61

62 参考人材育成の事例 - 対象別育成カリキュラム例 開発チーム スクラムマスター 顧客 / プロダクトオーナー 先行チーム リーダー PM 経営者層 / 購買担 当など アジャイル概要 アジャイル基礎知識 アジャイル擬似体験 業務知識 * 開発環境 * 基本アーキテクチャ * 業務分析 / モデリング 開発技術 * ファシリテーション概要 ファシリテーション演習 アジャイル開発を初めて行う組織を対象 : 立上げ前後の必須教育の領域 : 事前に準備が困難で OJT が必要な領域 *: 内容を組織内で個別に検討する必要がある領域 62

63 参考人材育成の事例 - カリキュラム概要 名称 アジャイル概要 アジャイル基礎知識 アジャイル擬似体験 概要 アジャイル開発に携わる方向けの基礎知識 一般的なプラクティスについての紹介 アジャイル開発のプロセスを体験を通して理解するチームビルディング的な狙いもある 業務知識開発対象の業務を理解する ( 内容は先行チームと検討 ) 開発環境 基本アーキテクチャ 業務分析 / モデリング 開発に使用するツールなどを理解する ( 内容は先行チームと検討 ) 開発対象のシステム構成や 利用するフレームワークなどを理解する ( 内容は先行チームと検討 ) 業務を整理し 開発側に伝えるための手法を理解する 開発技術開発に必要な技術を身につける ( 必要に応じて ) ファシリテーション概要 ファシリテーション演習 ファシリテーションに関する知識を理解する ファシリテーションに関する知識を体験を通して理解する 63

64 参考データアジャイル開発技術者の仕事に対する感じ方 考え方 (1) アジャイル開発技術者は,WF 開発技術者に比べ, 仕事が好きな割合が高い 出典 : IT 人材白書 2014,IPA,2014 年 4 月 25 日. 64

65 参考データアジャイル開発技術者の仕事に対する感じ方 考え方 (2) アジャイル開発技術者は,WF 開発技術者に比べ, 仕事に満足している割合が高い 出典 : IT 人材白書 2014,IPA,2014 年 4 月 25 日. 65

66 参考データスキルを学ぶ (1/2) 出典 : IT 人材白書 2014,IPA,2014 年 4 月 25 日. 66

67 参考データスキルを学ぶ (2/2) アジャイル開発技術者は, 自主 独学で手法を学んでいる 出典 : IT 人材白書 2014,IPA,2014 年 4 月 25 日. 67

68 分析 モチベーション 科学的実証の結果 報酬のインセンティブは, 視野を狭め, 心を集中させることから, 単純な仕事では効果があるが, そうでない創造的な仕事では逆効果. 成果を高めるのは, 内的な動機付けに基づくアプローチ. すなわち, 重要だからやる, 好きだからやる, 面白いからやる, 何か重要なことの一部を担っているからやる, というもの. ( ある程度の ) 裁量仕事において重要な要素は次の3つ : スキルアップ 自主性 自分の人生の方向は自分で決めたいになる 成長 何か大切なことについて上達したい顧客の " 価値 " 目的 私たち自身よりも大きな何かのためにやりたいを高める < 出典 > Dan Pink on the surprising science of motivation ( ダニエル ピンク やる気に関する驚きの科学 ) 上記要素は開発手法とは独立であるが, アプローチのし易さに特徴が反映される. 68

69 参考データ IT 技術者の所属先の国別比較 IT 技術者の所属先 3,500,000 3,000,000 2,500,000 2,000,000 1,500,000 1,000, , ,362, ,069 1,452, , ,000 N/A 0 N/A 450, ,426 19,961 ユーザ企業単位 ( 人 ) ITサービス企業 365, ,721 1,446,809 49, , ,170 49, , ,000 出典 : グローバル化を支える IT 人材確保 育成施策に関する調査 概要報告書,2011 年 3 月 (IPA) 69

70 アジャイル開発の技術者認定 ( 例 ) Certified ScrumMaster etc. SCRUM ALLIANCE, Inc. PMI Agile Certified Practitioner (PMI-ACP) Project Management Institute, Inc. アジャイルソフトウェア開発技術者検定試験 アジャイルソフトウェア開発技術者検定試験コンソーシアム ( 設立 ) 70

71 (5) アジャイル開発の契約 日本におけるアジャイル開発にふさわしい 契約モデルを提案 71

72 アジャイル開発には どんな契約がふさわしいのか? 開発内容が決まっていない段階で 開発プロジェクト全体につき 一つの請負契約を結ぶのは適切ではない ( 何をいくらで完成させるか不明 ) 他方 開発プロジェクト全体を準委任契約にすることは ベンダが完成義務を負わない点で ユーザ側に不安がある ( たとえ成果物が完成しなくても ユーザは対価を支払う必要 ) また アジャイル開発の特徴であるユーザとベンダの協働関係を 契約に取り入れる必要がある 契約 注 ) ユーザ側での労働者派遣契約に基づく開発チーム構成には, 契約上の問題は特にない. ( 内製傾向の高まりに伴い増加?) 72

73 基本 / 個別契約モデルの概要 システム運用 企画 要開テ求発スト 要開テ求発スト 要開テ求発スト 要開テ求発スト 要開テ求発スト 要開テ求発スト 第 1 反復 第 n 反復 第 1 反復 第 n 反復 第 1 反復 第 n 反復 n=1 のケースもあり 第 1 リリース 第 2 リリース 基本契約 基本契約 第 m リリース 個別契約 個別契約 個別契約 個別契約個別契約個別契約 - 例 - 契約 73

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

75 参考データ ( 再掲 ) アジャイル開発の適用状況 - 国内 -(4) 2% 4% アジャイル開発を使っていますか? 27% 2% 9% 2% 54% 多くのプロジェクトで使っている一部のプロジェクトで使っている使いたいと考えているが実現していない使う予定はないよく分からない / 関係ないその他無回答 16.8% 3% 0% 4% 43% 0% 50% 2014 年 11 月 12 日東京 (28 名 ) 年 10 月 30 日東京 (55 名 ) 1% 6% 7% 6% 32% 2% 46% 2014 年 12 月 17 日東京 (68 名 ) アジャイルジャパン 2014 ( , 東京 ) 参加者アンケート (265 名 ) 75

76 参考データ ( 再掲 ) アジャイル型開発プロジェクトの失敗理由 ( 海外 ) 50% 手法への不慣れ がさらに2ランクアップ 44% トップに! 40% 30% 20% 10% 0% 手法への不慣れ 42% 文化との相性 企業哲学又は 38% 支援の欠如 マネジメントの 37% への外部圧力 従来型開発採用 36% 欠如 文化的な移行の 33% プラクティス活用リファレンスガイド 33% 30% ケーション上の問 組織管理 を用いてアジャイル開発手法に慣れよう 反チ発ーム内での トレーニング 不十分な 6% 分からない その他 マネジメントの支援の欠如 も大幅 (6 ランク ) アップ コミュ題ニ (VersionOne 社アジャイル開発の現状調査第 9 回 2015より ) 76

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

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

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

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

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

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

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

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

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

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

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

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

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

90 組込み機器 システムとアジャイル開発 利用者の購入後に インターネットを介して クラウド 定期的に機能拡張 * 真の要求 アジャイル開発 エンドユーザ側データの収集の仕組みがある * エンドユーザからのフィードバック対応を含む 90

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

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

93 アジャイル開発の課題 < 背景の出典 > All-in-One Agile Lifecycle Management Solution 93

94 アジャイル開発では顧客との調整が難しい アジャイル開発においては, 顧客との調整が難しい 顧客 ( ビジネス ) 側の理解 認識も重要 一層の連携を!! 94

95 参考データアジャイル開発のプロジェクト管理 アジャイルジャパン 2014 ( ) 参加者アンケート (265 名 ) 95

96 アジャイル開発の契約は運用で解決できる 私見 優先順位の問題. アジャイル開発が真に必要であると判断し, リスクをとる覚悟があれば, 契約の問題は, 運用を工夫することにより解決できるはず 96

97 アジャイル開発はそのままでは生産性が低い アジャイル開発の生産性を高めるためには, ツールの活用, 特に, テストの効率化 ( 自動化等 ) が必須である 日本におけるソフトウェア開発一般の生産性は, 諸外国に比べて低いと言われている. ALM(Application Lifecycle Management) の導入も検討すべきである. 平成 25 年度年次経済財政報告, 内閣府 97

98 参考データ各種開発手法の比較例 3 種開発法の比較 ( 参考値 ) 総費用 /JFS 工数 /JFS 工期 /JFS WF アジャイル xrad アジャイル /WF xrad/wf 平均 係数 平均 係数 平均 係数 データ数 注 ) xrad は超高速開発手法のツールの一つ. 平均は各開発法のデータの平均値であり, 係数は JFS の 1 単位増加に伴う総費用, 工数, 工期の増加を示す. 係数が大きいと, システム開発規模の増加につれて各要因の値の増加がより大きくなることを示す. アジャイルは, テストを繰り返す等の理由により, 工数大 < 出典 > ソフトウェアメトリックス調査 2014, 図表 6-258, 一般社団法人日本情報システム ユーザー協会 (JUAS). 98

99 参考データ適切なツールの活用 ( テストツールの活用状況 ) ( 件 ) テストツールの使用の分布 % % 8 4.5% テストツール使用の有無 件数 ( 件 ) 割合 (%) 使用している 使用していない 合計 % % テストツールの活用により, 繰返しテストの効率化を < 出典 > ソフトウェアメトリックス調査 2014, 図表 7-60,7-61, 一般社団法人日本情報システム ユーザー協会 (JUAS). 99

100 参考データ ALM(Application Lifecycle Management)(1/2) 修正 / 変更に必要なコストとプラクティス / 技法 開発の初期段階で不具合を発見 対処すればコストは小さい アジャイル開発のプラクティスの活用 < 出典 > Scott W. Ambler: Why Agile Software Development Techniques Work: Improved Feedback 100

101 参考データ ALM(Application Lifecycle Management)(2/2) ツール クラウド への期待 全ステークホルダを対象とし, 企画からデリバリまで一貫したマネジメントが有効 < 出典 > Scott W. Ambler: Why Agile Software Development Techniques Work: Improved Feedback 101

102 アジャイル開発向けのアーキテクチャがあるはず アジャイル開発向けのアーキテクチャ ( ソフトウェア構造 ) へのヒント 開発手法によるプロジェクト成功 / 失敗の比較 ウォーターフォール アジャイル 14% 9% 29% 57% 49% 42% 完全成功 (Successful) 一部成功 (Challenged) 失敗 (Failed) 注 ) 2002~2010 年の CHAOS プロジェクト データベースの内容をもとに集計 出典 :CHAOS MANIFESTO

103 要求変化対応ソフトウェア アーキテクチャ (BRMS 1/2) ビジネス戦略 IT 戦略 コア部分に適用 ビジネス アーキテクチャ写像 IT システム アーキテクチャ ビジネス プロセス + ビジネス ルール 固定的 汎用的 変動的 個別的 変更不要 変更対象 エンジン パラメータ ビジネス プロセスが, ビジネス ルールを実行 ビジネス環境の変化 SEC 特別セミナー ( ) 講演 ビジネスアナリシス最前線 ~ 北米のビジネスアナリシスを取り巻く最新技術動向解説 ~ (IIBA 日本支部理事. 宗雅彦 ) の内容をもとに作成 要求変化対応ソフトウェア アーキテクチャ ビジネス環境の変化に伴う, ビジネス ルールの変動に対応する, パラメータのみ ( 小規模 ) を変更 XML ベースのマークアップ言語による記述? 103

104 要求変化対応と安心 安全 (BRMS 2/2) 変化に追随しないシステムは安心して使えない システムの複雑さは信頼性を低下させる ルール データ 第 1 階層ルール 1 第 2 階層第 3 階層 ルール21 ルール22 ルール31 ルール32 ルール33 変更 ルール処理モジュールシステム v.s. モジュール 2 モジュール 3 モジュール 1 システム モジュール 5 モジュール 4 変更 104

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

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

107 アジャイル文化への組織の転換はタフなこと アジャイル文化への組織の転換 (Agile transformation) アジャイルは, プロセスではなく文化である. Michael Sahota: An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture, 多くの組織, チーム, 個人にとって, アジャイル開発プロセスへの転換は 挑戦的 である. それは, ある種の文化的変革を必要とするからだ. [Agile transformation, IBM] 107

108 参考データアジャイル開発手法の導入拡大の障壁 ( 海外 ) 55% 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 53% 変組化織能文力化の 42% 一変般化的へのな抵抗 35% の W ア F ジフャレイールムのワ整ー合クへ 1. 組織文化の変化能力 2. 変化への一般的な抵抗 3.WFフレームワークへのアジャイルの整合 前回調査と同傾向 33% 経ア験ジャ者イ不ル足 30% 支マネ援ジメントの 28% 複雑さ 規模 プロジェ クトの 25% 顧客の協力 23% 対規応模の拡自大信への 13% 13% 13% 許移さ行れまるで時に間 予算の制約 特になし (VersionOne 社アジャイル開発の現状調査第 8 回 2014 より ) 108

109 参考データアジャイル開発手法の導入拡大の障壁 ( 海外 ) 55% 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 44% 変組化織能文力化の 35% 経ア験ジャ者イ不ル足 34% 一変般化的へのな抵抗 1. 組織文化の変化能力はトップ変わらず 2. 経験者不足が上位に 3. 新規 2 項目追加 : 32% の W ア F ジフャレイールムのワ整ー合クへ 29% 上流での計画不足への管理上の懸念 経営管理の浪費に関する懸念 24% 23% 22% 16% 15% 支マへ上顧に経特規ネの対流援客関営模ジ管に応でのす管な拡メ理のの協る理し大ン上計懸自ト画力のの念浪信へ懸のの不費念足 (VersionOne 社アジャイル開発の現状調査第 9 回 2015より ) 109

110 参考データ ( 再掲 ) アジャイル型開発プロジェクトの失敗理由 ( 海外 ) 50% 手法への不慣れ がさらに2ランクアップ 44% トップに! 40% 30% 42% 38% 37% 36% 33% 33% 30% 20% 10% 0% 継続的に上位に位置する 手法への不慣れ 文化との相性 企業哲学又は 支援の欠如 マネジメントの への外部圧力 従来型開発採用 欠如 文化的な移行の ケーション上の問 組織管理 反チ発ーム内での トレーニング 不十分な 6% 分からない その他 マネジメントの支援の欠如 も大幅 (6 ランク ) アップ コミュ題ニ (VersionOne 社アジャイル開発の現状調査第 9 回 2015より ) 110

111 彼を知り己を知れば百戦殆うからず ソフトウェア開発においては, 開発対象と組織 プロジェクトの特徴に応じた 適切な形態 手法の選択が重要 彼を知り己を知れば百戦殆うからず ( 孫子 ) 変わる 変える 失敗しません! 111

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

113 補足情報 113

114 参考 アジャイル宣言における 4 つの価値 私たちは, ソフトウェア開発の実践を手助けする活動を通じて, よりよい開発方法を見つけだそうとしている. この活動を通して, 私たちは以下のことを重視する : 1 プロセスやツールよりも, 個人と対話を 2 包括的なドキュメントよりも, 動くソフトウェアを 3 契約交渉よりも, 顧客との協調を 4 計画に従うことよりも, 変化への対応を すなわち,1~4 の各文の前者 ( よりも の前の言葉 ) に価値があることを認めながらも, 私たちは後者 ( よりも の後の言葉 ) の事柄により価値をおく. アジャイル宣言 (Agile Manifesto) アジャイルな開発手法の提唱者 17 名が集まり,2001 年に発表

115 参考 アジャイル宣言の背後にある 12 の原則 私たちは以下の原則に従う 1 顧客満足を最優先し 価値のあるソフトウェアを早く継続的に提供する 2 要求の変更はたとえ開発の後期であっても歓迎する 変化を味方につけることによって 顧客の競争力を引き上げる 3 動くソフトウェアを 2-3 週間から 2-3 ヶ月というできるだけ短い時間間隔でリリースする 4 ビジネス側の人と開発者は プロジェクトを通して日々一緒に働く 5 意欲に満ちた人々を集めてプロジェクトを構成する 環境と支援を与え仕事が無事終わるまで彼らを信頼する 6 情報を伝える最も効率的で効果的な方法は フェイス トゥ フェイスで話をすることである 7 動くソフトウェアこそが進捗の最も重要な尺度である 8 アジャイル プロセスは持続可能な開発を促進する 一定のペースを継続的に維持できるようにしなければならない 9 技術的卓越性と優れた設計に対する不断の注意が機敏さを高める 10 シンプルさ ( ムダなく作れる量を最大限にすること ) が本質である 11 最良のアーキテクチャ 要求 設計は 自己組織的なチームから生み出される 12 チームがもっと効率を高めることができるかを定期的に振り返り それに基づいて自分たちのやり方を最適に調整する 115

116 分析 IT システムへの依存と, システム環境の変化 安 心 変化の俊敏な反映 安全 高信頼化 < 依存 > の拡大傾向 時間的 : 常時化 量的 : 広範囲化 質的 : クリティカル域 環境 国民生活社会経済活動 依存 IT サービス IT システム 情報技術 変化 ( 要求の変化 ) 反映 変化 価値観 ライフスタイル 法制度 社会情勢 ビジネストレンド < 変化 >の拡大傾向 時間的 : 頻繁に 量的 : 広範囲な影響 質的 : 複雑化 技術動向 新技術 コスト このような傾向を考慮した,IT システムの開発 運用 SECセミナー ( ) 116

117 分析要求の固定が ( ビジネス ) リスクを拡大 要求が固定されない リスク システム開発スケジュールの遅延 外部ビジネス環境 ビジネス戦略 要求を固定化 リスク外部ビジネス環境の変化への迅速な対応の遅れ 内部状態 IT 戦略 要求 IT システム 技術動向 117

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

119 分析アジャイル開発の推進に向けて トップダウン : ビジョン ボトムアップ : トレーニング パフォーマンス 価値 ( スループット ) は, 面積で表される 初期リリース 時間 コミュニケーションが最も重要 変化に対する抵抗が最大の障害 パフォーマンス 初期リリース 時間 < 出典 > 河合太郎 ( ヤフー ): 大規模開発におけるリーン スタートアップ, Innovate 2013, 継続的デリバリーでスループットを大きく 119

120 参考データ ハイブリッド型の適用が進む (1 _1 /2) 2% 2% 2% 1% 1% 1% 2% 4% 4% 7% 9% 11% 54% 使用するアジャイル手法 スクラム系が多い カスタム ハイブリッドも伸びている Scrum Scrum/XP Hybrid Custom Hybrid Scrumban Kanban Don't Know XP Feauture-Driven-Dvelopment Lean Other Agile Unified Process Agile Modeling DSDM Atern VERSIONONE : 7 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

121 参考データ ハイブリッド型の適用が進む (1 _2 /2) 2% 2% 1% 1% 1% 1% 1% Scrum 4% 3% 5% 6% 8% 10% 55% 使用するアジャイル手法 Scrum/XP Hybrid Custom Hybrid Scrumban Kanban Iterative Development I Don t Know Lean Development Other Agile Modeling Feature-Driven Agile Unified DSDM/Atern XP 上位は不変 XP の順位低下 VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

122 参考データハイブリッド型の適用が進む (2/2) 28 percent of 450 software professionals said they use a hybrid approach. Another 12 percent use lean software development, which includes agile processes. Source: 2011 Agile ALM and Testing Survey, SearchSoftwareQuality.com Of 4,770 respondents from 91 countries, 90 percent said they use some form of agile. Only 27 percent of respondents solely use one type of agile, while 35 percent mix agile with waterfall, and 39 percent mix agile with Scrum. Source: Analysis.Net and VersionOne Source: PM NETWORK, January 2012, Vol. 26, No

123 参考データアジャイル開発技術者の仕事に対する感じ方 考え方 (1) 出典 : IT 人材白書 2013,IPA,2013/3/

124 参考データアジャイル開発技術者の仕事に対する感じ方 考え方 (2) Q. 今の仕事に一生懸命取り組んでいるアジャイル型 :28.4% ウォーターフォール型 :12.5% Q. 仕事が好きであるアジャイル型 :23.4% ウォーターフォール型 : 9.9% Q. この仕事をしていることを誇りに思うアジャイル型 :19.9% ウォーターフォール型 : 7.3% < 回答 = よく当てはまる の割合 > 出典 : IT 人材白書 2013,IPA,2013/3/

125 アジャイル開発プラクティス活用リファレンスガイド事例一覧 (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# 125

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

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

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

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

130 参考データ調査事例 : 活用されているプラクティス ( 海外 _2014 年 ) 1 Daily Standup 3 Iteration Planning 2 Retrospectives 1 10 Unit Testing 1 17 Release Planning 8 Burndown/ Team-Based Estimation 23 Velocity 14 Continuous Integration Automated Builds 20 Coding Standards 2 26 Dedicated Product Owner Integrated Dev /QA 24 Refactoring 9 Digital Taskboard 2 25 Open Workarea 21 Story Mapping 44 Kanban 32 TDD 3 35 Pair Programming 12 Collective Code Ownership 38 Automated Acceptance Testing Continuous Deployment Analog Taskboard Agile Games Cycle Time BDD 左の数値は, 日本の事例調査における順位 22% 17% 15% 12% 0 10% 20% 30% 40% 50% 60% 70% 80% 90% (VersionOne 社アジャイル開発の現状調査第 8 回 2014より ) 30% 29% 28% 25% 45% 44% 41% 39% 38% 50% 47% 56% 55% 55% 60% 58% 75% 74% 72% 70% 69% 85% 130

131 参考データ調査事例 : 活用されているプラクティス ( 海外 _2015 年 ) Daily Standup Short iterations Prioritized backlogs Iteration Planning Retrospectives Unit Testing Release Planning Team-Based Estimation Iteration reviews Taskboard Continuous Integration Dedicated Product Owner Integrated Dev&testing Coding Standards Open Workarea Refactoring TDD Kanban Story Mapping Collective Code Ownership Automated Acceptance Testing Continuous Deployment Pair Programming Agile Games BDD 9% 13% 29% 27% 24% 24% 21% 34% 31% 38% 36% 56% 53% 53% 50% 48% 46% 43% 71% 69% 65% 65% 80% 79% 79% 0 10% 20% 30% 40% 50% 60% 70% 80% 90% (VersionOne 社アジャイル開発の現状調査第 9 回 2015より ) SECセミナー ( ) 131

132 参考データアジャイル開発の成功の尺度 分からない プロセス改善 予測性生産性 Don't know Process improvement Predictability Productivity プロジェクトの可視性 Project visibility プロジェクトのスコープ ビジネス価値 顧客 / 利用者 製品の品質 納期遵守 Product scope Business value Customer/user Product quality On-time delivery やはり, 納期 が一番 IT プロジェクト一般とは異なる結果 % VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

133 参考データ アジャイル開発の成功を測る ( 日々の ) 指標 Product utilization Revenue/sales impact Customer retention Earned value Cumulative flow chart Scope change in a release Test pass/fail over time Cycle time Individual hours per iteration/week Business value delivered Estimation accuracy Defect resolution Budget vs. actual cost Defects over time Defects in to production Work-in-Process (WIP) Customer/user satisfaction Pianned vs. actual release dates Burn-up chart Pianned vs. actual stories per iteration Release burndown Iteration burndown Velocity 開発速度 (59%), 反復バーンダウン (51%), リリースバーンダウン (39%) の順 % VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

134 参考データ 大規模開発へのアジャイル手法適用の成功要因 Internal agile support team 31 Agile consultants or trainers 35 Implementation of a common tool across teams 39 Executive sponsorship 40 Consistent process &practices 首尾一貫したプロセスとプラクティスが重要 % VERSIONONE : 9 th ANNUAL STATE of AGILE DEVELOPMENT SURVEY,

135 付録 135

136 アジャイル開発のメトリクスソフトウェア メトリクスの用途 ( 一般 ): 計画, 予測 Planning, forecasting 監視と制御 Monitoring & control パフォーマンス改善, ベンチマーキング Performance improvement, benchmarking 5つのコア メトリクス ( 一般 ): 規模 Product(size) 品質 ( 信頼性 ) Quality 工数 Effort 工期 Duration 生産性 Productivity < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/

137 開発手法とメトリクス コア メトリクスアジャイル開発ウォーターフォール型開発 規模 Product(size) 品質 ( 信頼性 ) Quality 工数 Effort 工期 Time 生産性 Productivity features, stories defects/iteration, defects, Mean Time to Defect (MTTD) story points *) duration (months) velocity (story points/iteration) FP, CFP, UCP defects/release, defects, Mean Time to Defect (MTTD) person months duration (months) hours/fp *) Story points are subjective and only apply to this project and this team < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/

138 計画 予測用メトリクス 指標 (Metric) 目的測定方法 フィーチャー数 (number of features) 反復 / リリース当りの計画ストーリー数 (number of planned stories per iteration/release) 反復 / リリース当りの受入れストーリー数 (number of accepted stories per iteration/ release) チームの開発速度 (Team Velocity) コード行数 (LOC) 1.Insight into the size of the product (and the entire release). 2.When status applied to features: insight in progress. 1.Insight into the size of the product (and the entire release). 2.When status applied to stories: insight in progress. To track progress of the iteration/release Refer to Monitoring & Control Indicates amount of completed work (progress), calculation of other metrics i.e. defect density. The product comprises features that in turn comprise stories. Features are grouped as to do, in progress, and accepted. The work is described in stories, which are quantified in story points. Stories are grouped as to do, in progress, and accepted. Formal registration of accepted stories. According to rules agreed upon which LOC s to count. < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/

139 監視 制御 ( 進捗, パフォーマンス ) 用メトリクス (1/2) 指標 (Metric) 目的測定方法 反復のバーンダウン (Iteration Burn-down) 反復当りのチーム開発速度 (Team Velocity per Iteration) リリースのバーンダウン (Release Burn-down) リリースのバーンアップ (Release Burn-up) 反復当りのテストケース数 (Number of test cases per Iteration) Performance per iteration, are we on track?. To learn historical Velocity for certain Team. Cannot be used to compare different teams. To track progress of a release from iteration to iteration are we on track for the entire release. How much product can be delivered within the given time frame. To learn amount of test work per iteration. To track progress of testing. Effort remaining (in hrs) for the current iteration (effort spent/ planned expresses performance). Number of realized story points per iteration within this release. Velocity is team and project specific. Number of story points to do after completion of an iteration within the release (extrapolation with certain velocity shows the end date). Number of story points realized after completion of an iteration over the total number of story points (of the release). On a time line it shows the progress of scope completion. Number of test cases per Iteration recorded as sustained, failed and to do. < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/ SECセミナー ( ) 139

140 監視 制御 ( 進捗, パフォーマンス ) 用メトリクス (2/2) 指標 (Metric) 目的測定方法開発サイクル時間 ( チームの Number of stories that can be To determine bottlenecks of the 受容力 ) handled per discipline within an process; the discipline with the (Cycle Time iteration (i.e. analysis- UI-designcoding - unit testlowest capacity is the bottleneck. (Team s capacity)) syst.-test). リトルの法則 (Little s Law cycle times are proportional to queue length.) Insight into duration; we can predict completion time based on queue length. Work in progress (# stories) divided by the capacity of the process step. < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/ SECセミナー ( ) 140

141 改善 ( プロダクト品質, プロセス改善 ) 用メトリクス 指標 (Metric) 目的 測定方法 累積不具合数 Logging each defect in defect (Cumulative number of To track effectivity of testing. management system. defects) テストセッション数 To track testing effort and compare it Extraction of data from the defect (Number of test sessions) to the cumulative number of defects. repository. 不具合密度 (Defect density) To determine the quality of the software in terms lack of defects. The cumulative number of defects divided by 1000LOC s (KLOC). 不具合の原因分布 (Defect distribution per origin) 不具合のタイプ分布 (Defect distribution per type) 不具合の解決時間 (Defect Cycle Time) To decide where to allocate quality assurance resources. To learn what type of defects are the most common and help avoid them in the future. Insight in the time solve a defect (speed of defect resolution). The faster the resolution, the lesser coding on top will be produced. By logging the origin of defects in the defect repository and extract the data by means of an automated tool. By logging the type of defects in the defect repository and extract the data by means of an automated tool. Opening date of the defect minus the resolution date (usually the closing date in the defect repository). < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/ SECセミナー ( ) 141

142 アジャイル開発用メトリクスのまとめ 1.The metrics used within the Agile methods and the units used (story points, velocity) are not standardized. This makes benchmarking problematic, if not impossible. 標準化されていない ベンチマーキングをする上で問題となる 2.When realized story points are expressed as LOC s, a correspondence may be established with standardized functional size units (FPn); even an organization s productivity or team productivity may be determined. FPが標準? 3.Agile methods could benefit from incorporating product metrics in consequence of an increase in customer satisfaction as a result of a higher product quality and lower development costs through improved understanding of the software development process. 顧客満足度向上のためにプロダクトメトリクスの導入 4.Within the Agile community many metrics are developed, that essentially are the same as metrics within the waterfall method, albeit they use agile-own units and concepts. 本質的にはウォーターフォール型と同じメトリクス 5.Agile methods do not recognize functional size. The size of a release is expressed as number of features or stories. The measurement story points does not yield a (functional) size, but rather an amount of required effort. 機能量は分からない < 出典 > John Kammelar: Agile Metrics, Nesma, 28/04/