発注者としての アジャイル開発体験報告 株式会社オージス総研 張嵐 中川三千雄

発注者としての

アジャイル開発体験報告

2

株式会社 オージス総研

オージス総研は、コンサルティング、情報化戦略立案からシステムの

設計・開発、運用・管理まで、必要とされるソリューションメニューの

すべてを提供できるシステム・インテグレータです。

社名 株式会社オージス総研 代表者 取締役社長 平山 輝（ひらやま ひかる） 設立 1983年6月29日 資本金 4億円(大阪ガス株式会社100%出資) 売上実績 ２８８億円（2011年度 単体） 従業員数 １３１７名 （2012年3月31日現在） 事業所 本社/岩崎コンピュータセンター 東京オフィス 千里オフィス 南港オフィス 尼崎オフィス 名古屋オフィス・豊田オフィス 海外法人 米国OGIS International,Inc. 品質 ＩＳＯ９００１認証取得 プライバシーマークの付与認定

6

当社の代表的なアジャイル開発の実績年表



小規模はスクラム的、中規模以上は統一プロセス（

UP）の形で開発

10人 以下 30人 以下 30人 超

脱Waterfall

整理定式化

エンタープライズ

_{アジャイル開発}

オージス総研のアジャイル開発手法



OGIS Scalable Agile Method



開発手法部分



スクラムを基本とする



アジャイルUPで補完する



測定部分



機能規模測定手法「COSMIC法」に基づ

く測定を活用し、見積もり、契約の問題

に対処し、開発をモニタリング、改善する

アジャイル開発に対する期待と

発注者の役割

アジャイル開発に期待する効果



期待する効果



要求変更への対応



迅速なリリース

10

プロダクトオーナーは製品の成功に責任を持つ

価値

物

人

顧客、ユーザ、 ステークホルダ との協調 チームとの協力 予算 プロダクト ビジョンと ロードマップ プロダクト バックログ リリースプラン プロダクト

これらの責務を一人でこなすのは大変難しい

プロダクトオーナーを皆で支える



ここから、弊社の2つの事例を通して、プロダク

トオーナーのあり方について考えていきます。

CaseStudy1

CaseStudy2

プロダクトオーナー

の得意な専門分野

マネージメント

開発技術

開発の特徴

アジャイル＋

オフショア開発

アジャイル＋

研究開発

便宜上：発注者 = プロダクトオーナー

CASE STUDY1：

アジャイル＋オフショア事例

プロジェクトの概要と課題

アジャイル開発の導入

アジャイル開発の導入効果

プロダクトオーナーへのメッセージ

考察対象のプロジェクト概要

Elapiz BE v3.4

開発内容

UMLモデリングツールの機

能改善、プラグインの追加

開発種類

パッケージ開発（.net）

開発期間

3ヶ月

開発チーム人数

12名

開発規模/

ソースコード規模

30人月/

606KSLOC

開発環境

Visual Studio

C#.net

16

今までのやり方



ミニWaterfall



アジャイル開発のプラクティス

を断片的に適用



チケットで要求管理



チーム全体アプローチ



KPTによる振り返り

要件定義 基本設計 詳細設計 コード作成 単体テスト 結合テスト システムテスト 作業依頼 範囲 Start End 重要な機能 残りの機能 変更対応・ 不具合修正 WIP1 WIP2 システムテスト _{システムテスト} ＞１ヶ月 １ヶ月前後 0.5ヶ月 システムテスト RC ※）WIP(Work In Progress)：中間リリース。動作確認を行う RC(Release Candidate) ：最終リリース。受け入れを行う

顕在化した課題



発注側が感じた4つの課題



品質



変更を柔軟に受け入れる許容度



要求の出し方とオフショア側の

システム利用者の立場から考える力



プロジェクトの可視化



オフショア側の課題



モチベーション

もっと考えてくれ たらいいのに エンドユーザから の新たな要望が あった いわれることだけ やるのは、ちょっ とつまらない 変更、変更、何の ために頑張ったか エビデンスのために一日中画面 のハードコピーを行うのは、私 の将来の糧になるのか？ この機能の開発 は終わったか？

2.アジャイル開発の導入

知識

支援

導入したもの

プロジェクト管理

フレームワーク

•Scrum

技術プラクティス

ツール

•Visual Studio

2010+Team

Foundation

Server（TFS)

•顧客指向

•チームビルディング

•品質

•リリース重視

•オフショア開発支援

20

要件の出し方：プロダクトバックログの作成

発注者

要求を登録する

要求を理解する

優先順位をつける

• ビジネス価値

• 実現の難易度

• 見積もり結果

要求の細分化、補

足を行う

プロダクトバックログ

見積りを行う

優先順位

高い方は

より詳細的

優先順位

低い方は

曖昧のまま

開発チーム

実現の可能性、難

易度を検討する

要求一覧と見積り

結果を確認する

開発の流れとプロダクトバックログの洗練化

初 期 要 求 定 義 リ リ ー ス 計 画 ・・・・・・ リ リ ー ス ス プ リ ン ト ス プ リ ン ト 0 ス プ リ ン ト 1 ス プ リ ン ト 5 スプリント0 スプリント１ スプリント2 ・・・・・・ スプリント５



変更を柔軟に対応するために



動くソフトウエアやユーザからフィードバックを受け、

プロダクトバックログを進化させる

プロダクトバックログの洗練化

22

プロダクトオーナーとの常時コミュニケーション

メール chat 電話 Skype TV会議 出張 SOBA TFS/Wiki メーリングリスト 有効性 利用頻度

• スプリント計画

• スプリントレビュー

• 振り返り

• 仕様説明

• Q&A

• レビュー結果

• 不具合

• 仕様に関するDiscussion

支援ツール



mantis、Trac、mailなど複数のツールを整理し、Team

Foundation Serverで一元化管理

自動ビルド・自動テスト 構成管理 IDE

Visual Studio 2010 Ultimate

開 発

CI

TFS＋MSF for Agile Software Development P J 管 理 継続的なインテグレーション バックログの管理、テスト管理 Q&A、課題など情報共有 Tracによる要求管理、情報共有 Mantisよる不具合管理 構成管理サーバ 集約

品質：不具合が減少



Elapizの不具合曲線

Scrumを導入

段階的にアジャイル

26

品質：不具合は早期検出、早期対応

今までの開発（V3.3)



終盤に集中し、最終盤

にピークがある



改修がリリースに間に

合っていない

今回のアジャイル開発（V3.4)



開始から、終盤まで平均

化している



検出→修正のタイム間隔

が短縮

プロジェクト期間 0 5 10 15 20 25 30 検出数 修正数 0 5 10 15 20 25 30 件 数 件 数 初期 終盤 初期 プロジェクト期間 終盤

仕様変更：対応力が高まった

今までの開発

今回のアジャイル開発

発注時の

前提条件

要求はおおむね確定して

いる

要求は開発と共に進化す

る

開発の目的

要求を満たすため

要求を最適化するため

変更対応

• 次期開発で対応

• 対応せざるを得ない場

合、コストと納期に響く

• 柔軟に対応

• 優先順位の調整を行い、

コストと納期への影響を

低減

柔軟に変更を

対応するため

-

• 短い反復

• バックログの洗練化で

変更を察知する

28

可視化：プロジェクトの健康状態の見える化



Team Foundation Serverを活用し、リスク、進捗、品

質状況が見やすくなる

チ

ー

ム

の

ツ

ー

ル

プ

ロ

ダ

ク

ト

オ

ー

ナ

ー

の

ツ

ー

ル

技術寄りのプラクティス

管理寄りのプラクティス

スプリント

バーンダウンチャート

リリース

バーンダウンチャート

スプリントレビュー

継続的なインテグレーション

アジャイルテスト

チームのモチベーションと提案力が向上



開発チームの変化



縦割り指示型から自律性の高いチームになった



発注者はチームの一員になり、対等、協力の関係になった



作業項目を自分で選択し、責任を持って動くものを作る



開発者は自分の作品と認識し、製品を良くなるために提案す

るようになった



離職率は低くなった

プロダクト オーナー スクラムマスタ チーム 要求 製品 支援

ビジネス

技術

プロセス

30

課題と今後の方向性

発注側

オフショア側

Scrum

• 頻繁なスプリントレ

ビューで疲れた

• ストーリーレベルで仕様

を提示し、仕様の説明

や確認の時間がかかっ

た

• スプリント毎に動くものをデモ

するので、プロジェクト終了ま

で緊張し、疲れた

• タスクの選択は積極的ではな

かった

• スプリントレビューの準備不足

で、デモ対象の機能が動かな

かった

継続的なインテ

グレーション

--

大量のレガシーコードに対し、テ

ストケースを一気に追加できない

TFS

--

十分に使いこなせなかった

「個々のプロジェクトで頑張る」だけでは成功は約束されない。

組織からの支援が大切。

4.まとめ：

プロダクトオーナーへのメッセージ

よいアイデア！ 不具合が確実に 減った エンドユーザから の新たな要望が あり、対応しても らおう TFSでプロジェク トの状況をチェッ クする この機能は私の提 案だ！ 変更？次のスプリント で対応できるかを検 討する 今日も○○さんと一緒 にペアで作業し、沢山 刺激を受けた。このチ ームが楽しい

32

プロダクトオーナーへのアドバイス



チームと対等の信頼関係を持つ



チームの意見を真剣に受け止め、オフショア側の自主的な活

動をサポート



組織からの支援が大切



アジャイルコーチ、技術支援、ツール導入支援



プロマネのスキルが必要



ユーザ調整、リソース配分、プロダクト全体の整合性への配

慮等



適切なツールも重要

34

考察対象のプロジェクト概要と課題

課題に対する解決策

プロジェクトの結果

アジャイル開発に関する３つの気づき

CaseStudyの紹介内容

考察対象のプロジェクト概要

CITK

(Cloud Integration Tool Kit)

開発内容

セキュリティやシステム連携に

関するクラウド基盤ソフトウェ

アの開発

開発期間

8ヶ月

開発チーム人数

4～10名

開発規模

40人月

開発環境

Mule ESB

Open AM

Java

SOURCEFORGE.JPで公開中 http://sourceforge.jp/projects/citk/

36

当プロジェクトにおける課題



研究開発で不確定な要求が多く、それらに対処

するために、プロジェクトはスクラムを採用する



一部の開発を委託するパートナー企業は「一括

請負」「非アジャイル（ウォーターフォール）」を希

望する

１つのプロジェクト内でスクラムによる

アジャイル開発とウォーターフォールによる

非アジャイル開発をどのように併存させるか？

38

アジャイルと非アジャイルの複合チーム体制



開発チームは２チーム体制（アジャイルと非アジャイル）



プロジェクトルームを準備し、チーム全員の同席を採用



アジャイル開発センターは教育面・プロセス面をサポート

リーダー 開発チーム スクラム マスタ プロダクト オーナー 開発チーム アジャイル コーチ 報告・Q&A 成果物送付 仕様・設計伝達 成果物受け入れ _{パートナー企業} 非アジャイル開発チーム(3～5名) 弊社アジャイル 開発チーム(4名前後) アジャイル開発センター 教育・プロセス 教育・プロセス 非アジャイル（一括請負） 作業の持ち帰りを希望 スクラムを導入

プロジェクト開始時点での全体の進め方

開発

弊社 プロジェクト ルーム パートナー 企業 [チーム全体] 初期要求の洗い出し （プロダクトバックログ作成） [非アジャイルチーム] ウォーターフォール [非アジャイルチーム] ＷＢＳ作成と見積もり [弊社アジャイルチーム] スクラムを適用 [プロダクトオーナー] プロダクトバックログの コントロール、成果物受け入れ 作業の 持ち帰り

初期計画

開発

リリース

40

非アジャイルチームとの作業範囲の合意



プロジェクト全体の初期要求をプロダクトバックログとして

洗い出す



プロジェクトの実施計画をもとに初期要求を洗い出す



非アジャイルチームが持ち帰り可能な要求の選定



プロダクトバックログから要求がハッキリし、他と依存していないものを

選択



作業範囲を合意にするためにＷＢＳを作成



１、２週間間隔で中間成果物の確認が可能なタスク粒度



非アジャイルチームは見積もりを実施し、作業範囲を合意して作業を持

ち帰る

非アジャイルチームの作業進捗の確認方法



日次報告



日々の成果物（ソースコード、ドキュメント等）



定例会議（1回／週）



デモンストレーション



ソースコードレビュー



ドキュメントレビュー



仕様説明

タスク毎に受け入れを実施。 ⇒ 指摘事項をフィードバックし、 対応確認後、クローズする デモンストレーションやレビューを行い、 進捗レベルを共有した。



非アジャイル開発チームが作業を自社に持ち帰り、開発が進

むにつれて、問題が顕著に発生

プロジェクトの途中経過

８ ９ １０ １１ １２ １ ２ ３ プロジェクト 全体 非アジャイル チーム 設計／開発 非アジャイル チーム テスト／受入 予定 実績 問題 _発生 予定 予定 実績

44

非アジャイルチームで発生した問題と解決策

解決策

プロジェクトルームに非アジャイルチームも同席

原因

技術力不足

コミュニケーションロス

発生した問題

日々の成果物が未提出

進捗遅れ

新しい技術

不慣れな技術

作業場所が

異なる

動かして確認

できない

指定した技術が

利用されていない

キャッチアップのための対策（アジャイルの導入）



ホワイトボードを使った設計やアジャイルモデリング



ペアプログラミング

文書や対話より

46 

アジャイルプラクティス導入から約２週間で効果がみられた。



プロジェクト全体は計画当初の予定から１カ月遅れでリリース。

プロジェクトの結果

８ ９ １０ １１ １２ １ ２ ３ プロジェクト 全体 非アジャイル チーム 設計／開発 非アジャイル チーム テスト／受入 予定 実績 問題 _発生 予定 予定 実績 実績 １２月初旬 同席・アジャイルモデリ ング・ペアプログラミング を導入 １２月初中旬 動くソフトウェアを確認 しながら開発が行える ようになった

48

１．プロダクトオーナーは、チームの一員になること



プロダクトオーナーは、チームと距離を置くの

ではなく、積極的にチームの一員になる



チームとの協力関係が成り立たなければ、要

求のコントロールも難しい

２．同席によるコミュニケーションの効果は大きい



チームの状況が把握しやすい



要求に対する問題や課題のフィードバックが

早いため、問題が大きくなる前に対処できる

動くソフトウェアに目を向けることができ、

ソフトウェア開発に注力できる

50

３．個人の能力の差は、チーム力でカバーできる



チームの個々のメンバーの能力は高いにこし

たことはないが、最初から高い能力は必要ない



個々の能力のウィークポイントは、チーム力で

カバーできる

52

アジャイル開発の導入効果の評価（１）

導入前

反復開発

導入後

スクラム

結果

要求変更へ

の対応

抵抗感があった。 対応能力が備わった。

_{自ら改善案を提示す}

るようになった。

大きく

改善

迅速なリ

リース

リリース前の不

_{具合改修が間に}

合わない。

不具合の早期検出・

早期対応で計画通り、

リリースできた。

大きく

改善

品質向上

_{リリース直前の}

不具合検出量が

多い。

導入前に比べ、減少

傾向。

改善

■アジャイル＋オフショア開発

アジャイル開発の導入効果の評価（２）

導入前

ウォーター

フォール

導入後

部分的にアジャイル

プラクティスを導入

結果

要求変更へ

の対応

抵抗感があった。

コミュニケショーンで仕

事が進むようになり、細

かな要求の調整は気にな

らなくなった。

小さく

改善

迅速なリ

リース

開発期間中、ソフト

ウェアの動作確認が

不可能だった。

常にソフトウェアの動作

確認ができる状態になっ

た。

改善

品質向上

修正毎にデグレート

が多く発生した。

テストコードを作成した

ため、修正時のデグレー

ドが大きく減少した。

大きく

改善

■アジャイル＋研究開発（非アジャイルチーム）

54

発注者の特徴とパートナー企業に与えた影響（１）

■アジャイル＋オフショア開発



発注者の得意な専門分野



プロジェクトマネージメント



発注者が努力した点



開発チームの自主性を尊重



プロマネの経験の活用



発注者がパートナー企業に与えた影響



開発チームのモチベーションの向上



開発チームの作業効率や品質の向上



発注者の得意な専門分野



開発技術



発注者が努力した点



パートナー企業に歩み寄り、協力体制を確立



パートナー企業にアジャイルプラクティスを導入



発注者がパートナー企業に与えた影響



動くソフトウェアを見ながら開発が行えるようになった



気が付けば、アジャイル開発を実践していた

発注者の特徴とパートナー企業に与えた影響（２）

■アジャイル＋研究開発事例

56

成功する発注者の心構え

発注

者

スクラム マスター アジャイル コーチ ＰＭ

業務

開発 チーム 仕様や プロダクトバッ クログの作成 を サポート プロセス面、 教育面を サポート 各調整や コスト管理等 仕様調整や プロダクトバッ クログの作成 をサポート プロセス面、 教育面を サポート 技術面を サポート

ご清聴ありがとうございました。

www.ogis-ri.co.jp