関するクラウド基盤ソフトウェ アの開発
開発期間
8
ヶ月 開発チーム人数4
～10
名 開発規模40
人月開発環境
Mule ESB Open AM Java
SOURCEFORGE.JPで公開中 http://sourceforge.jp/projects/citk/
36
当プロジェクトにおける課題
研究開発で不確定な要求が多く、それらに対処 するために、プロジェクトはスクラムを採用する
一部の開発を委託するパートナー企業は「一括 請負」「非アジャイル（ウォーターフォール）」を希 望する
１つのプロジェクト内でスクラムによる
アジャイル開発とウォーターフォールによる
非アジャイル開発をどのように併存させるか？
http://agilemanifesto.org/
38
アジャイルと非アジャイルの複合チーム体制
開発チームは２チーム体制（アジャイルと非アジャイル）
プロジェクトルームを準備し、チーム全員の同席を採用
アジャイル開発センターは教育面・プロセス面をサポート
リーダー
開発チーム スクラム
マスタ
プロダクト オーナー
開発チーム
アジャイル コーチ
報告・Q&A 成果物送付 仕様・設計伝達
成果物受け入れ パートナー企業
非アジャイル開発チーム(3～5名) 弊社アジャイル
開発チーム(4名前後)
アジャイル開発センター
教育・プロセス 教育・プロセス
非アジャイル（一括請負）
作業の持ち帰りを希望 スクラムを導入
プロジェクト開始時点での全体の進め方
開発
弊社
プロジェクト ルーム
パートナー 企業
[チーム全体] 初期要求の洗い出し
（プロダクトバックログ作成）
[非アジャイルチーム]
ウォーターフォール [非アジャイルチーム]
ＷＢＳ作成と見積もり
[弊社アジャイルチーム] スクラムを適用
[プロダクトオーナー] プロダクトバックログの コントロール、成果物受け入れ
作業の 持ち帰り
初期計画 開発 リリース
40
非アジャイルチームとの作業範囲の合意
プロジェクト全体の初期要求をプロダクトバックログとして 洗い出す
プロジェクトの実施計画をもとに初期要求を洗い出す
非アジャイルチームが持ち帰り可能な要求の選定
プロダクトバックログから要求がハッキリし、他と依存していないものを 選択
作業範囲を合意にするためにＷＢＳを作成
１、２週間間隔で中間成果物の確認が可能なタスク粒度
非アジャイルチームは見積もりを実施し、作業範囲を合意して作業を持 ち帰る
非アジャイルチームの作業進捗の確認方法
日次報告
日々の成果物（ソースコード、ドキュメント等）
定例会議（1回／週）
デモンストレーション
ソースコードレビュー
ドキュメントレビュー
仕様説明
タスク毎に受け入れを実施。
⇒ 指摘事項をフィードバックし、
対応確認後、クローズする
デモンストレーションやレビューを行い、
進捗レベルを共有した。
プロジェクトの結果
非アジャイル開発チームが作業を自社に持ち帰り、開発が進 むにつれて、問題が顕著に発生
プロジェクトの途中経過
８ ９ １０ １１ １２ １ ２ ３
プロジェクト 全体
非アジャイル チーム 設計／開発 非アジャイル
チーム テスト／受入
予定
実績 問題 発生
予定
予定 実績
44
非アジャイルチームで発生した問題と解決策
解決策
プロジェクトルームに非アジャイルチームも同席
原因
技術力不足 コミュニケーションロス
発生した問題
日々の成果物が未提出 進捗遅れ
新しい技術 不慣れな技術
作業場所が 異なる 動かして確認
できない
指定した技術が 利用されていない
キャッチアップのための対策（アジャイルの導入）
ホワイトボードを使った設計やアジャイルモデリング
ペアプログラミング
文書や対話より
コードは素直に伝わる
46
アジャイルプラクティス導入から約２週間で効果がみられた。
プロジェクト全体は計画当初の予定から１カ月遅れでリリース。
プロジェクトの結果
８ ９ １０ １１ １２ １ ２ ３
プロジェクト 全体
非アジャイル チーム 設計／開発 非アジャイル
チーム テスト／受入
予定
実績問題 発生
予定
予定 実績
実績 １２月初旬
同席・アジャイルモデリ ング・ペアプログラミング
を導入
１２月初中旬 動くソフトウェアを確認 しながら開発が行える
ようになった
48
１．プロダクトオーナーは、チームの一員になること
プロダクトオーナーは、チームと距離を置くの ではなく、積極的にチームの一員になる
チームとの協力関係が成り立たなければ、要
求のコントロールも難しい
２．同席によるコミュニケーションの効果は大きい
チームの状況が把握しやすい
要求に対する問題や課題のフィードバックが 早いため、問題が大きくなる前に対処できる
動くソフトウェアに目を向けることができ、
ソフトウェア開発に注力できる
50
３．個人の能力の差は、チーム力でカバーできる
チームの個々のメンバーの能力は高いにこし たことはないが、最初から高い能力は必要ない
個々の能力のウィークポイントは、チーム力で
カバーできる
52
アジャイル開発の導入効果の評価（１）
導入前 反復開発
導入後 スクラム
結果
要求変更へ
の対応 抵抗感があった。 対応能力が備わった。
自ら改善案を提示す るようになった。
大きく 改善
迅速なリ
リース リリース前の不 具合改修が間に 合わない。
不具合の早期検出・
早期対応で計画通り、
リリースできた。
大きく 改善
品質向上 リリース直前の 不具合検出量が 多い。
導入前に比べ、減少
傾向。 改善
■アジャイル＋オフショア開発
アジャイル開発の導入効果の評価（２）
導入前 ウォーター
フォール
導入後
部分的にアジャイル プラクティスを導入
結果
要求変更へ の対応
抵抗感があった。 コミュニケショーンで仕 事が進むようになり、細 かな要求の調整は気にな らなくなった。
小さく 改善
迅速なリ リース
開発期間中、ソフト ウェアの動作確認が 不可能だった。
常にソフトウェアの動作 確認ができる状態になっ た。
改善
品質向上 修正毎にデグレート が多く発生した。
テストコードを作成した ため、修正時のデグレー ドが大きく減少した。
大きく 改善
■アジャイル＋研究開発（非アジャイルチーム）
54
発注者の特徴とパートナー企業に与えた影響（１）
■アジャイル＋オフショア開発
発注者の得意な専門分野
プロジェクトマネージメント
発注者が努力した点
開発チームの自主性を尊重
プロマネの経験の活用
発注者がパートナー企業に与えた影響
開発チームのモチベーションの向上
開発チームの作業効率や品質の向上
発注者の得意な専門分野
開発技術
発注者が努力した点
パートナー企業に歩み寄り、協力体制を確立
パートナー企業にアジャイルプラクティスを導入
発注者がパートナー企業に与えた影響
動くソフトウェアを見ながら開発が行えるようになった
気が付けば、アジャイル開発を実践していた
発注者の特徴とパートナー企業に与えた影響（２）
■アジャイル＋研究開発事例
56
事例からみた発注者の人物像
成功する発注者の心構え
発注 者
スクラム マスター
アジャイル コーチ
業務 ＰＭ 開発
チーム
仕様や プロダクトバッ
クログの作成 を
サポート
プロセス面、
教育面を サポート
各調整や コスト管理等 仕様調整や
プロダクトバッ クログの作成
をサポート
プロセス面、
教育面を サポート 技術面を
サポート