製品力を高めるための アジャイル開発超入門 技術部アジャイル開発センター藤井拓
アジェンダ アジャイル開発超入門 アジャイル開発手法の適用事例 2
開発手法の普及率 世界での普及 (Forrester Research, 2010) ウォーターフォール13% 反復開発 21% アジャイル開発 35% Scrumの利用は10.9% で一番多い 方法論利用せず30.6% 日本 (IDC Japan, 2011) ウォーターフォール開発が 51.2% 反復型開発が 29.7% アジャイル開発が 19.1% 3
アジャイル開発普及の背景 ビジネス競争の激化 新たな価値 ( 製品 サービス ) をどれくらい早く市場に投入できるか 新たな価値 予め答えが見えない ( 要求の不確定性 ) 新技術 デバイス サービスの活用 早く市場に投入 要求定義と開発を並行する ちょっとずつ機能追加してリリースする 4
ウォーターフォール開発 始めに適切な要求を決められる! 要求 という仮説の正しさを開発途上で確かめずに開発を行う 要件定義 要求 設計 要件定義 要求 設計 実装 実装 テスト リリース テスト リリース 時間 時間 5
アジャイル開発 始めに適切な要求を決められない! 要求 という仮説の正しさを開発途上 で確認しながら開発を行う 要求 計画 計画 計画 開発 開発 開発 評価 フィードバック 評価 フィードバック リリース 時間 6
要求の不確定性 経験がない製品やサービスの考案 これまで経験が無いような新たな製品やサービス ( 業務 ) の考案 競合他社や市場の動向 刻々と競合他社や市場が変化していく 新技術 / デバイスの登場 クラウド モバイルなどの新技術 / デバイスの活用方法の考案 これらの要因にスピーディーに対応するため開発途上に要求が変化する! 7
アジャイル開発への取り組み状況と 期待する効果 アジャイル開発への取組み状況 アジャイル開発に期待する効果 弊社のエンタープライズアジャイルセミナーのアンケートの集計結果から 8
変化への対応力 要求などの不確定性に対応するためには 変化への対応力 ( 柔軟性 ) が必要 柔軟性を低下させるもの プロセスの細かいマニュアル化 ( 分業 ) 詳細なドキュメントによる情報伝達 契約上の駆け引き 計画の硬直的な順守 柔軟性を低下させるもののをすべて一気に排除する必要はないできるところから少しずつ改善すればよい 9
アジャイル開発の特徴 反復的な開発 一定の期間毎に動くソフトウェアを作る形でソフトウェア開発を進める 顧客との協調 顧客と協調し 顧客のビジネスの成功を支援する チームワーク重視 ( 人間中心 ) 開発者の自律性 コミュニケーション 改善を重視 技術的裏付け 変化の影響を抑える技術プラクティス ( 設計 / コード品質 自動化 ) の適用 10
アジャイル開発フレームワークスクラム (Scrum) とは Ken Schwaber, Mike Beedle, Jeff Sutherland によって提案された ( プロジェクト管理 ) 手法 ラグビーのスクラムに ちなんだ名称 野中らの知識創造プロセスの影響を受けている ラグビーボールはある一定のやり方では動かない.. ラグビーボールの動きは, フィールドでのチームメンバーの連携プレーから生まれてくるのである. それは, チーム メンバー間の濃密で骨の折れる相互作用を必要とする. ( 知識創造企業からの引用 ) 欧米ではスクラムがもっとも普及している 11
スクラムの基本 スプリント 1 週間から 30 日間のサイクルの反復をスプリントと呼ぶ スプリントの期間中は, 外乱を抑え, 目標達成に専念できるようにする 体制 プロダクトオーナー, スクラムマスター, 開発チームが連携して開発を進める 開発チームの規模は, 7±2 人 12
スクラムのプロセス スプリント目標 実行可能なソフトウェア ( インクリメント ) Schwaber, K. et al., Agile Software Development with Scrum, Prentice Hall, 2002の図をベースに作成 13
スクラムの事例 組み込みシステムの開発 新しいハードウェアの開発と並行して開発 中間に従来と異なる言語のインターフェイスを設ける ( 非同期通信 ) インターフェイスは開発と並行して 別会社と一緒に策定 従来の半分のコスト 少ない経験者で開発することを求められた 従来のやり方では開発できない! アジャイル開発 14
開発当初の状況 プロジェクトのメンバー プロジェクト管理者 この分野の開発の経験者 目的指向 柔軟性に富み 楽観的な 開発リーダー 優秀なエンジニアだが 自分で手を動かしてしまうタイプ 開発メンバー 経験者 1 名 割と近い分野の経験者 1 名 未経験者 1 名 プロジェクト管理者がプロダクトオーナーの役割を 開発リーダーがスクラムマスター兼開発メンバーの役割を担った 15
開発スケジュール (1) #1 #2 #3 #4 #5+5.5 #6 #7 #8 #9 #10 #11 #12 スクラムと開発内容の習得 新ハード対応 ( 一部 ) 新アーキテクチャの検証とインターフェイス仕様の調整 機能の作りこみ (2 階層スクラム ) 残機能の完成と外部対応 (2 階層スクラム ) 03/12 04/2 04/4 04/6 04/8 04/10 04/12 #1,#2 スプリント ( 方向づけ ) 開発内容とスクラムによる開発の進め方の習得 たいてい最初の 2 イテレーションぐらいは実績が目標を大幅に下回る 例外的に スプリントの中間点で目標を見直した 16
開発スケジュール (2) #1 #2 #3 #4 #5+5.5 #6 #7 #8 #9 #10 #11 #12 スクラムと開発内容の習得 新ハード対応 ( 一部 ) 新アーキテクチャの検証とインターフェイス仕様の調整 機能の作りこみ (2 階層スクラム ) 残機能の完成と外部対応 (2 階層スクラム ) 03/12 04/2 04/4 04/6 04/8 04/10 04/12 #6 スプリント チームの開発生産性も掴めたので 残る期間で開発を完了するための要員を追加 (26 名体制 ) 既存のメンバーからサブチームのリーダーを選抜 #3-5.5 でスプリント毎 (?) に 1 名程度開発メンバーを追加 17
2 階層スクラム (Scrum of Scrums) 18
開発メンバーの評価 利点 人材が育成できた点 プロジェクト管理として有効だった コミュニケーションとチームワークが良好 課題 チーム規模拡大による自律性の低下 開発終盤や環境整備チームの目標管理の難しさ 開発ペースのむら テストの自動化が一部に留まった 19
成功要因の分析 フィードバック フィードバックによる計画の見直し スクラムマスター スクラムマスターによる問題解決 同席 1 つの部屋に集まれたこと スキル 上位チームのメンバーのスキルが高かったこと 段階的なスケールアップ チーム規模の段階的なスケールアップ 20
技術的なプラクティス テスト駆動開発 テストケースをまず考え そのテストケースを実装してから本体コードを実装し 実装した本体コードをテストするという開発手法 継続的なインテグレーション 各メンバーが開発し 単体テストに合格したコードを随時コードリポジトリにチェックインする コードリポジトリ内のコードは自動ビルドされ テストを実行され その結果が報告される 21
まとめ 近年 欧米及び日本でアジャイル開発が普及してきている ビジネス競争の激化 より手堅く開発を行う アジャイル開発の特徴 反復的な開発 顧客との協調 チームワーク重視 技術的裏付け 22
OGIS Scalable Agile Method 日本固有の事情を克服してアジャイル開発を活用するためのフレームワーク 開発手法部分 スクラムとアジャイル UP を組み合わせた開発手法 測定部分 機能規模測定手法 COSMIC 法に基づく測定を活用し 見積もり 契約の問題に対処し 開発をモニタリング 改善する 23
参考文献及びサイト スクラム (Scrum) ケン シュエイバー他 : アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003 知識創造プロセス 野中郁次郎, 竹内弘高, 知識創造企業, 東洋経済新聞社, 1996 アジャイルモデリングへの道 : 第 2 回 スクラム組んで開発しよう! http://www.ogisri.co.jp/otc/hiroba/technical/introasdoosquare/chapter2/introscrumcas estudymay2005.html 2012 OGIS-RI Co., Ltd. All rights reserved 24