発注者としての アジャイル開発体験報告 株式会社 オージス総研 張 嵐 中川 三千雄 株式会社 オージス総研 オージス総研は、コンサルティング、情報化戦略立案からシステムの 設計・開発、運用・管理まで、必要とされるソリューションメニューの すべてを提供できるシステム・インテグレータです。 社名 株式会社オージス総研 代表者 取締役社長 平山 輝（ひらやま ひかる） 設立 1983年6月29日 資本金 4億円(大阪ガス株式会社100%出資) 売上実績 ２８８億円（2011年度 単体） 従業員数 １３１７名 （2012年3月31日現在） 事業所 本社/岩崎コンピュータセンター 東京オフィス 千里オフィス 南港オフィス 尼崎オフィス 名古屋オフィス・豊田オフィス 海外法人 米国OGIS International,Inc. 品質 ＩＳＯ９００１認証取得 プライバシーマークの付与認定 2 本日の内容 3 アジャイル開発と当社の関わり 当社のアジャイル開発の取り組み 5 当社の代表的なアジャイル開発の実績年表 小規模はスクラム的、中規模以上は統一プロセス（ UP）の形で開発 30人 超 30人 以下 10人 以下 脱Waterfall 整理定式化 エンタープライズ アジャイル開発 6 オージス総研のアジャイル開発手法 OGIS Scalable Agile Method 開発手法部分 スクラムを基本とする アジャイルUPで補完する 測定部分 機能規模測定手法「COSMIC法」に基づ く測定を活用し、見積もり、契約の問題 に対処し、開発をモニタリング、改善する 7 アジャイル開発に対する期待と 発注者の役割 アジャイル開発に期待する効果 期待する効果 要求変更への対応 迅速なリリース 品質向上 弊社のエンタープライズアジャイルセミナーのアンケートの集計結果から 9 プロダクトオーナーは製品の成功に責任を持つ 顧客、ユーザ、 ステークホルダ との協調 チームとの協力 人 プロダクト バックログ 物 プロダクト プロダクト ビジョンと ロードマップ リリースプラン 価値 予算 これらの責務を一人でこなすのは大変難しい 10 プロダクトオーナーを皆で支える ここから、弊社の2つの事例を通して、プロダク トオーナーのあり方について考えていきます。 CaseStudy1 CaseStudy2 プロダクトオーナー の得意な専門分野 マネージメント 開発技術 開発の特徴 アジャイル＋ オフショア開発 アジャイル＋ 研究開発 便宜上：発注者 = プロダクトオーナー 11 オージス総研のグローバルデリバリーマップ CASE STUDY1： アジャイル＋オフショア事例 CaseStudy1の紹介内容 プロジェクトの概要と課題 アジャイル開発の導入 アジャイル開発の導入効果 プロダクトオーナーへのメッセージ 13 1. プロジェクトの概要と課題 考察対象のプロジェクト概要 Elapiz BE v3.4 開発内容 UMLモデリングツールの機 能改善、プラグインの追加 開発種類 パッケージ開発（.net） 開発期間 3ヶ月 開発チーム人数 12名 開発規模/ ソースコード規模 30人月/ 606KSLOC 開発環境 Visual Studio C#.net 15 今までのやり方 ミニWaterfall アジャイル開発のプラクティス を断片的に適用 残りの機能 システムテスト 単体テスト RC End WIP2 １ヶ月前後 重要な機能 結合テスト 作業依頼 範囲 コード作成 WIP1 ＞１ヶ月 基本設計 詳細設計 チケットで要求管理 チーム全体アプローチ KPTによる振り返り Start システムテスト 要件定義 0.5ヶ月 変更対応・ 不具合修正 システムテスト システムテスト ※）WIP(Work In Progress)：中間リリース。動作確認を行う RC(Release Candidate) ：最終リリース。受け入れを行う 16 顕在化した課題 エンドユーザから の新たな要望が あった 発注側が感じた4つの課題 品質 変更を柔軟に受け入れる許容度 もっと考えてくれ たらいいのに 要求の出し方とオフショア側の システム利用者の立場から考える力 この機能の開発 は終わったか？ プロジェクトの可視化 オフショア側の課題 モチベーション エビデンスのために一日中画面 のハードコピーを行うのは、私 の将来の糧になるのか？ 変更、変更、何の ために頑張ったか いわれることだけ やるのは、ちょっ とつまらない 17 支援 知識 2.アジャイル開発の導入 信頼 導入したもの プロジェクト管理 フレームワーク 技術プラクティス •Scrum •顧客指向 •チームビルディング ツール •Visual Studio 2010+Team Foundation Server（TFS) •品質 •リリース重視 •オフショア開発支援 19 要件の出し方：プロダクトバックログの作成 発注者 Team Foundation Server 要求を登録する プロダクトバックログ 優先順位をつける • ビジネス価値 • 実現の難易度 • 見積もり結果 要求一覧と見積り 結果を確認する 優先順位 高い方は より詳細的 開発チーム 要求を理解する 実現の可能性、難 易度を検討する 見積りを行う 優先順位 低い方は 曖昧のまま 要求の細分化、補 足を行う 20 開発の流れとプロダクトバックログの洗練化 変更を柔軟に対応するために 動くソフトウエアやユーザからフィードバックを受け、 プロダクトバックログを進化させる 要 求初 定期 義 リ 計リ 画ー ス ス プ 0 リ ン ト ス プ 1 リ ン ト ・・・・・・ ス プ 5 リ ン ト スリ プリ リー ンス ト プロダクトバックログの洗練化 スプリント0 スプリント１ スプリント2 ・・・・・・ スプリント５ 21 プロダクトオーナーとの常時コミュニケーション 有効性 • • • • 出張 Q&A レビュー結果 不具合 仕様に関するDiscussion SOBA TV会議 TFS/Wiki Skype メーリングリスト • • • • スプリント計画 スプリントレビュー 振り返り 仕様説明 利用頻度 メール 電話 chat 22 支援ツール mantis、Trac、mailなど複数のツールを整理し、Team Foundation Serverで一元化管理 Team Foundation Server 構成管理サーバ IDE Visual Studio 2010 Ultimate Mantisよる不具合管理 開 発 構成管理 集約 CI Tracによる要求管理、情報共有 自動ビルド・自動テスト P J 管 理 継続的なインテグレーション TFS＋MSF for Agile Software Development バックログの管理、テスト管理 Q&A、課題など情報共有 23 3.アジャイル開発の導入結果 品質：不具合が減少 Elapizの不具合曲線 段階的にアジャイル プラクティスを導入 Scrumを導入 25 品質：不具合は早期検出、早期対応 今までの開発（V3.3) 今回のアジャイル開発（V3.4) 終盤に集中し、最終盤 にピークがある 改修がリリースに間に 合っていない 30 25 20 開始から、終盤まで平均 化している 検出→修正のタイム間隔 が短縮 30 25 検出数 20 修正数 件 15 数 10 件 15 数 10 5 5 0 0 初期 プロジェクト期間 終盤 初期 プロジェクト期間 終盤 26 仕様変更：対応力が高まった 今までの開発 今回のアジャイル開発 発注時の 前提条件 要求はおおむね確定して いる 要求は開発と共に進化す る 開発の目的 要求を満たすため 要求を最適化するため 変更対応 • 次期開発で対応 • 対応せざるを得ない場 合、コストと納期に響く • 柔軟に対応 • 優先順位の調整を行い、 コストと納期への影響を 低減 柔軟に変更を 対応するため • 短い反復 • バックログの洗練化で 変更を察知する 27 可視化：プロジェクトの健康状態の見える化 Team Foundation Serverを活用し、リスク、進捗、品 質状況が見やすくなる 管理寄りのプラクティス チ ー ム の ツ ー ル スプリント バーンダウンチャート リリース バーンダウンチャート 継続的なインテグレーション スプリントレビュー アジャイルテスト プ ロ ダ ク ト オ ー ナ ー の ツ ー ル 技術寄りのプラクティス 28 チームのモチベーションと提案力が向上 開発チームの変化 縦割り指示型から自律性の高いチームになった 発注者はチームの一員になり、対等、協力の関係になった 作業項目を自分で選択し、責任を持って動くものを作る 開発者は自分の作品と認識し、製品を良くなるために提案す るようになった プロセス 離職率は低くなった スクラムマスタ 支援 要求 ビジネス プロダクト オーナー 技術 製品 チーム 29 課題と今後の方向性 発注側 オフショア側 Scrum • 頻繁なスプリントレ • スプリント毎に動くものをデモ ビューで疲れた するので、プロジェクト終了ま • ストーリーレベルで仕様 で緊張し、疲れた を提示し、仕様の説明 • タスクの選択は積極的ではな や確認の時間がかかっ かった た • スプリントレビューの準備不足 で、デモ対象の機能が動かな かった 継続的なインテ グレーション -- 大量のレガシーコードに対し、テ ストケースを一気に追加できない TFS -- 十分に使いこなせなかった 「個々のプロジェクトで頑張る」だけでは成功は約束されない。 組織からの支援が大切。 30 変更？次のスプリント で対応できるかを検 討する この機能は私の提 案だ！ 今日も○○さんと一緒 にペアで作業し、沢山 刺激を受けた。このチ ームが楽しい エンドユーザから の新たな要望が あり、対応しても らおう TFSでプロジェク トの状況をチェッ クする 不具合が確実に 減った よいアイデア！ 4.まとめ： プロダクトオーナーへのメッセージ プロダクトオーナーへのアドバイス チームと対等の信頼関係を持つ チームの意見を真剣に受け止め、オフショア側の自主的な活 動をサポート 組織からの支援が大切 アジャイルコーチ、技術支援、ツール導入支援 プロマネのスキルが必要 ユーザ調整、リソース配分、プロダクト全体の整合性への配 慮等 適切なツールも重要 32 CASESTUDY2： アジャイル＋研究開発事例 CaseStudyの紹介内容 考察対象のプロジェクト概要と課題 課題に対する解決策 プロジェクトの結果 アジャイル開発に関する３つの気づき 34 考察対象のプロジェクト概要 CITK (Cloud Integration Tool Kit) 開発内容 開発期間 開発チーム人数 開発規模 開発環境 セキュリティやシステム連携に 関するクラウド基盤ソフトウェ アの開発 8ヶ月 4～10名 40人月 Mule ESB Open AM Java SOURCEFORGE.JPで公開中 http://sourceforge.jp/projects/citk/ 35 当プロジェクトにおける課題 研究開発で不確定な要求が多く、それらに対処 するために、プロジェクトはスクラムを採用する 一部の開発を委託するパートナー企業は「一括 請負」「非アジャイル（ウォーターフォール）」を希 望する １つのプロジェクト内でスクラムによる アジャイル開発とウォーターフォールによる 非アジャイル開発をどのように併存させるか？ 36 http://agilemanifesto.org/ 課題に対する解決策 アジャイルと非アジャイルの複合チーム体制 開発チームは２チーム体制（アジャイルと非アジャイル） プロジェクトルームを準備し、チーム全員の同席を採用 アジャイル開発センターは教育面・プロセス面をサポート スクラムを導入 弊社アジャイル 開発チーム(4名前後) スクラム マスタ プロダクト オーナー 開発チーム 教育・プロセス 仕様・設計伝達 成果物受け入れ 報告・Q&A 成果物送付 アジャイル開発センター アジャイル コーチ 非アジャイル（一括請負） 作業の持ち帰りを希望 パートナー企業 非アジャイル開発チーム(3～5名) リーダー 開発チーム 教育・プロセス 38 プロジェクト開始時点での全体の進め方 初期計画 [チーム全体] 初期要求の洗い出し （プロダクトバックログ作成） 弊社 プロジェクト ルーム [非アジャイルチーム] ＷＢＳ作成と見積もり パートナー 企業 作業の 持ち帰り 開発 開発 リリース [弊社アジャイルチーム] スクラムを適用 [プロダクトオーナー] プロダクトバックログの コントロール、成果物受け入れ [非アジャイルチーム] ウォーターフォール 39 非アジャイルチームとの作業範囲の合意 プロジェクト全体の初期要求をプロダクトバックログとして 洗い出す プロジェクトの実施計画をもとに初期要求を洗い出す 非アジャイルチームが持ち帰り可能な要求の選定 プロダクトバックログから要求がハッキリし、他と依存していないものを 選択 作業範囲を合意にするためにＷＢＳを作成 １、２週間間隔で中間成果物の確認が可能なタスク粒度 非アジャイルチームは見積もりを実施し、作業範囲を合意して作業を持 ち帰る 40 非アジャイルチームの作業進捗の確認方法 日次報告 日々の成果物（ソースコード、ドキュメント等） 定例会議（1回／週） デモンストレーション ソースコードレビュー ドキュメントレビュー タスク毎に受け入れを実施。 ⇒ 指摘事項をフィードバックし、 対応確認後、クローズする デモンストレーションやレビューを行い、 進捗レベルを共有した。 仕様説明 41 プロジェクトの結果 プロジェクトの途中経過 非アジャイル開発チームが作業を自社に持ち帰り、開発が進 むにつれて、問題が顕著に発生 ８ プロジェクト 全体 非アジャイル チーム 設計／開発 非アジャイル チーム テスト／受入 ９ １０ １１ １２ １ ２ ３ 予定 実績 予定 問題 実績 発生 予定 43 非アジャイルチームで発生した問題と解決策 動かして確認 発生した問題 できない 日々の成果物が未提出 新しい技術 不慣れな技術 技術力不足 指定した技術が 利用されていない 進捗遅れ 作業場所が 原因 異なる コミュニケーションロス 解決策 プロジェクトルームに非アジャイルチームも同席 44 キャッチアップのための対策（アジャイルの導入） ホワイトボードを使った設計やアジャイルモデリング ペアプログラミング 文書や対話より コードは素直に伝わる 45 プロジェクトの結果 アジャイルプラクティス導入から約２週間で効果がみられた。 プロジェクト全体は計画当初の予定から１カ月遅れでリリース。 ８ ９ １０ １１ 非アジャイル チーム テスト／受入 １ ２ ３ 予定 プロジェクト 全体 非アジャイル チーム 設計／開発 １２ 実績 予定 問題 実績 発生 予定 １２月初旬 同席・アジャイルモデリ ング・ペアプログラミング を導入 １２月初中旬 動くソフトウェアを確認 しながら開発が行える ようになった 実績 46 アジャイル開発に関する３つの気づき １．プロダクトオーナーは、チームの一員になること プロダクトオーナーは、チームと距離を置くの ではなく、積極的にチームの一員になる チームとの協力関係が成り立たなければ、要 求のコントロールも難しい 48 ２．同席によるコミュニケーションの効果は大きい チームの状況が把握しやすい 要求に対する問題や課題のフィードバックが 早いため、問題が大きくなる前に対処できる 動くソフトウェアに目を向けることができ、 ソフトウェア開発に注力できる 49 ３．個人の能力の差は、チーム力でカバーできる チームの個々のメンバーの能力は高いにこし たことはないが、最初から高い能力は必要ない 個々の能力のウィークポイントは、チーム力で カバーできる 50 成功する発注者の心構え アジャイル開発の導入効果の評価（１） ■アジャイル＋オフショア開発 導入前 反復開発 要求変更へ の対応 導入後 スクラム 結果 抵抗感があった。 対応能力が備わった。 大きく 自ら改善案を提示す 改善 るようになった。 迅速なリ リース リリース前の不 具合改修が間に 合わない。 不具合の早期検出・ 大きく 早期対応で計画通り、 改善 リリースできた。 品質向上 リリース直前の 不具合検出量が 多い。 導入前に比べ、減少 傾向。 改善 52 アジャイル開発の導入効果の評価（２） ■アジャイル＋研究開発（非アジャイルチーム） 導入前 ウォーター フォール 要求変更へ の対応 抵抗感があった。 導入後 部分的にアジャイル プラクティスを導入 コミュニケショーンで仕 事が進むようになり、細 かな要求の調整は気にな らなくなった。 結果 小さく 改善 迅速なリ リース 開発期間中、ソフト 常にソフトウェアの動作 ウェアの動作確認が 確認ができる状態になっ 不可能だった。 た。 改善 品質向上 修正毎にデグレート テストコードを作成した が多く発生した。 ため、修正時のデグレー ドが大きく減少した。 大きく 改善 53 発注者の特徴とパートナー企業に与えた影響（１） ■アジャイル＋オフショア開発 発注者の得意な専門分野 プロジェクトマネージメント 発注者が努力した点 開発チームの自主性を尊重 プロマネの経験の活用 発注者がパートナー企業に与えた影響 開発チームのモチベーションの向上 開発チームの作業効率や品質の向上 54 発注者の特徴とパートナー企業に与えた影響（２） ■アジャイル＋研究開発事例 発注者の得意な専門分野 開発技術 発注者が努力した点 パートナー企業に歩み寄り、協力体制を確立 パートナー企業にアジャイルプラクティスを導入 発注者がパートナー企業に与えた影響 動くソフトウェアを見ながら開発が行えるようになった 気が付けば、アジャイル開発を実践していた 55 事例からみた発注者の人物像 56 成功する発注者の心構え スクラム マスター 技術面を サポート プロセス面、 教育面を サポート 開発 アジャイル チーム コーチ 仕様や 仕様調整や プロダクトバッ プロダクトバッ クログの作成 クログの作成 を をサポート サポート 発注 者 業務 チーム ＰＭ 各調整や コスト管理等 をサポート 57 ご清聴ありがとうございました。 株式会社 オージス総研 www.ogis-ri.co.jp
© Copyright 2024 Paperzz
