エンタープライズへのアジャイル開発の導入事例

ULS
Copyright © 2011-2016 UL Systems, Inc. All rights reserved.
Proprietary & Confidential Powered by
XP祭り2016
エンタープライズへのアジャイル開発の導入事例
「アジャイル開発で絶対に外せないコアプラクティス」
吉原庄三郎
2016/9/24
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems.co.jp
Tel: 03-6220-1420 Fax: 03-6220-1402

ULS
Proprietary & Confidential Powered by 1
はじめに
■アジャイル開発を書籍に書いてあるように実践しても上手く行きません。特にエ
ンタープライズにアジャイル開発を適用するには制約（しがらみ）が多く、プロ
ジェクトの状況にあわせてテーラリングすべきです
■そこで、アジャイル開発の本来の価値に立ち返り、アジャイル開発として最低
限行うべきであるコアプラクティスを考えました。本日はコアプラクティスを軸に
エンタープライズにアジャイル開発を適用する事例を紹介します
このセッションではXPではありませんが、アジャイル開発を
エンタープライズシステム開発に適用した事例を紹介します

ULS
自己紹介
■吉原庄三郎（ヨシハラショウザブロウ）
– shozaburo.yoshihara@ulsystems.co.jp
– ウルシステムズ株式会社
■ アジャイル推進室室長
– https://www.ulsystems.co.jp/
– 書籍執筆
■ はじめての設計をやり抜くための本（翔泳社）
– ISBN：9784798117065
– 定価：本体2,380円＋税
– 最近のWeb連載
■ ZDNet - まだまだ応用できる--今から始めるアジャイル開発の勘所
– http://japan.zdnet.com/cio/sp_15agile/
– コミュニティ活動
■ アジャイルプロセス協議会、エンタープライズアジャイル勉強会など

ULS
目次
1. アジャイルのコアプラクティス
1. アジャイルは難しい！？
2. 「過ぎたるは猶及ばざるが如し」
3. アジャイル開発の「ユーザー価値」
4. アジャイル開発の3つのコアプラクティス
5. アジャイルコーチは開発チーム状況に
合わせてバランスをとる
2. 事例紹介
1. ここから本題
2. プロジェクトの概要
3. プロダクトオーナー・プロキシ
4. プロジェクトのスケジュール
5. コーチングプラン
6. 最低限のプラクティスを導入する
7. プロジェクトの進め方
8. ①ユーザーストーリー抽出と全体計画
9. ②イテレーション0
10. ③イテレーション1
11. ユーザーの反応
12. 立ち上げのポイント
13. ④イテレーション2
14. ⑤イテレーション3
15. 開発生産性は上昇
16. 自己組織化の成熟レベル
3. まとめ

ULS
アジャイルのコアプラクティス

ULS
アジャイルは難しい！？
■色々な人からアジャイル開発で失敗した事例を聞くと、多くのケースでアジャイ
ルをやることに頑張りすぎていることに気が付きました
■例えば、アジャイルソフトウェア宣言にある4つの価値と12の原則をきっちり守
り、プラクティスも何十個も適用してしまうのです。忠実にアジャイルをやろうと
すればするほど、イテレーションでやらなければならないことが増えていきま
す。アジャイルをやることに頑張りすぎてしまい、肝心のシステム開発は遅々と
して進みません
①原則を守って、プラクティ
スも沢山適用して忠実なア
ジャイルをやるぞ！
②アジャイルってやること多
くて、なかなかシステムを開
発できないなぁ
③もっとアジャイルになるため
に、ドキュメントは廃止しよう。
プラクティスも追加しよう
④どうやっても生産性
があがらない・・・アジャ
イルって難しい
悪循環?

ULS
「過ぎたるは猶及ばざるが如し」
■プラクティスを増やせば増やすほど上手くいくのであればアジャイル開発はもっ
と簡単ですが、残念ながらそうではありません。理由はアジャイルというより、シ
ステム開発というものが人間を中心にした活動だからです。極端なやり方は人
間がついて行けません
■どこまでやるか、このバランスを取ることが必要です。ウォーターフォールでも
プロジェクトマネージャーが普通にやっていることです。アジャイルではアジャイ
ルコーチがこのバランスを取ります
アジャイルウォーターフォール
上手くいかないから、もっと
アジャイルのプラクティスを
追加しようか・・・
この線より左にいくとアジャ
イルの価値を達成できない。
これがコアプラクティス

ULS
アジャイル開発の価値
■ウォーターフォールでよくある机上で定義した要件と、実際にリリースされたシ
ステムとのギャップを埋めるということです
■ギャップを埋めるためには、どうする？
– 超短期イテレーションで素早く動くシステムをユーザーに見せます
– ユーザーは動くシステムを実際に確認してフィードバックします
– フィードバックを計画的にシステムへ反映します
アジャイルの価値とは、超短期イテレーションを繰り返すことで、
ユーザーが本当に望むシステムを実現すること
フィードバック
動くシステム
超短期
イテレーション
ユーザー
確認
何度も繰り返す
イテレーションの度に実際に
動くシステムを操作して確認する

ULS
コアプラクティス
■アジャイル開発に詳しい人ほど、多くのプラクティスを駆使しようとします。しか
し、先にも述べたようにプラクティスを多くすればするほど悪循環に陥り、成功
する可能性は低くなります
■そこで、コアプラクティスというものを考えます。アジャイル開発の価値である超
短期イテレーションを実現するためのキーとなるプラクティスをコアプラクティス
と定義します
超短期イテレーション？？？
？？？
？？？
コアプラクティス
アジャイル開発の価値
（ユーザー価値）
プラクティスA
プラクティスB
プラクティスC
プラクティスD
プラクティスE
プラクティス

ULS
3つのコアプラクティス
■これ以外は従来（ウォーターフォール）の手法でも構いません。まずは、超短期
イテレーションに慣れることが重要です。しばらくして慣れてきたらプラクティス
を追加すべきです
① 優先度に従って開発する
■ ユーザーストーリーでも機能一覧でもいいのでプロダクトオーナー相当の人に優先度
を付けてもらう。その優先度に従って順番にイテレーションで開発する
② ユーザーレビューをする
■ ユーザーに動くシステムを使ってもらって意見をもらいます。仕様変更や仕様追加が
あれば優先度を付けて、次のイテレーションの計画に反映します
③ ふりかえり／デイリーミーティングをする
■ 日々のデイリーミーティングや、イテレーションの終わりのふりかえりを行います。ユー
ザー満足、品質、生産性を改善するためにはどうするかを話し合います

ULS
アジャイルコーチは開発チーム状況に合わせてバランスをとる
■アジャイル開発はクスリのようなものです。どんな良薬も沢山投与しては逆効
果です。患者の状況に応じて適切な量とタイミングで投与すべきです
■アジャイルコーチは主治医のように相手の状態を診断して、適切な量とタイミン
グでプラクティスというクスリを投入します
アジャイルウォーターフォール
アジャイルコーチがバランスをとる
超短期イテレーションを回すための3つのコアプラクティス
• 優先度に従って開発する
• ユーザーレビューをする
• ふりかえり／デイリーミーティングをする

ULS
事例紹介

ULS
ここから本題
先に上げたコアプラクティスを軸にして、
最低限のプラクティスを見繕って、
実際にアジャイルコーチを行った
事例を紹介します

ULS
プロジェクトの概要
■会員向けポータルサイトをアジャイル開発で再構築します
■背景
– 顧客は某会社の情報システム部門です。以前からアジャイル開発を導入したいと考
えていました。今回、最適なトライアルプロジェクトがはじまることになりました
■開発規模
– 画面20程度
– バッチ5程度
■開発体制
– プロダクトオーナー顧客メンバー
– 開発チーム顧客メンバーから数名
– アジャイルコーチ私（吉原）
– 顧客メンバーは全員がアジャイル開発をやったことがありません。どちらかと言え
ば、「本当にできるの？」と懐疑的でした

ULS
プロダクトオーナー・プロキシ
■今回、プロダクトオーナーは情報システム部門が担いました。業務部門にお願
いするには負担が大きすぎるからです。日本のエンタープライズシステム開発
では最も多いパターンだと思います。この場合、プロダクトオーナーがユーザー
の要求を取りまとめます
■通常のプロダクトオーナーの責務
■今回のプロダクトオーナーの責務（エンタープライズでは多い）
開発チーム
プロダクト
オーナー
ユーザー
開発チーム
プロダクト
オーナー
要求や優先度
の決定
要求や優先度
の決定
要求や優先度
の取りまとめ

ULS
プロジェクトのスケジュール
■プロジェクトは5ヶ月程度あるが、アジャイルコーチによる支援は最初の3ヶ月
だけです。残り2ヶ月は顧客メンバーだけで運営します
ユーザーストー
リーの抽出と
全体計画
イテレーション開発リリース
アジャイルコーチ（3ヶ月）
開発全体（5ヶ月程度）

ULS
コーチングプラン
■まず、今回のプロジェクトでは現場のメンバーはアジャイル開発に半信半疑な
ので、まずはアジャイル開発の価値を実感してもらう必要があります。価値を実
感できればモチベーションも上がり、良いサイクルを作れます
早めにアジャイル開
発の価値を実感
ユーザーに動く画面を
早めに見せる
生産性を高める
プラクティスを最
低限にする
イテレーション期
間を短く
作業場所を同じ
部屋にする
イテレーション期
間を2週間
ゴールアクション
既存の開発標準
を出来るだけ踏襲
する
良い
サイクル
①ユーザーに動く画面
を早めに見せる
②ユーザーが喜
んでくれる
③ユーザーが喜べ
ば、開発チームも喜
ぶ
④開発チームは、
はりきって開発する

ULS
11 継続的インテグレーションプロダクトの問題を早期に効率的に発見する
12 テスト自動化デグレーションを防止する
最低限のプラクティスを導入する
■今回実践したプラクティス
■途中から状況にあわせて本格的に導入したプラクティス
# プラクティス内容
1 超短期イテレーション 2週間毎に動くプロダクトを開発する
2 インセプションデッキ開発チームでゴールと進め方を共有する
3 ユーザーストーリー顧客の要求を端的に表す
4 相対的な見積りストーリーポイントで相対的に見積る
5 全体計画リリースに向けての規模見積やスケジュールを決める
6 イテレーション計画イテレーションで開発する対象を決める
7 デイリーミーティング 1日単位で開発チームの進捗と課題を共有する
8 ふりかえり開発チームがより高い能力を発揮できるように議論する
9 プロダクトバックログ顧客の要求の内容、完了条件、優先順位を管理する
10 かんばんメンバーの作業内容を見える化する

ULS
プロジェクトの進め方
■①ユーザーストーリー抽出と全体計画のタイムボックスは2週間です
■②イテレーション0を開発準備として1週間とります。開発準備をすることでイテ
レーション1以降の生産性を高めます。ユーザーに動く画面を見せることで、良
いサイクルを作ります。イテレーション0はバッファでもあります。万が一、①
ユーザーストーリー抽出と全体計画が遅延したときに吸収します
■③イテレーション1以降はイテレーション開発です。期間は2週間とします。短く
することで頻繁にユーザーに動くシステムを提供します
①ユーザース
トーリー抽出と全
体計画
②イテレー
ション０
③イテレーション1 ④イテレーション2 ⑤イテレーション3
続く
1週間 2週間 2週間 2週間2週間

ULS
①ユーザーストーリー抽出と全体計画
■「ユーザーストーリー抽出と全体計画」の目的
– 開発を行うために要求分析や全体計画などを行います
■タスク
1. オリエンテーションの実施（約1日）
2. インセプションデッキの作成（約2日）
3. ユーザーストーリーの作成と優先度付け（約3日）
4. 全体計画の策定（約4日）
■ユーザーストーリーは100点を狙いません
– 3日間とタイムボックスを決めたのであれば、その期間で収まるように作業をします。
手元にある状況を整理して、課題を明確にしてユーザーにヒアリングできる状態にし
ます。スピード感を持って行います
■全体計画が成立しないことも
– 抽出したユーザーストーリーを一覧にして、ストーリーポイントを見積ります。ストー
リーポイントと生産性（ベロシティ）の仮定値で計算すれば、全てを開発するための
期間がわかります。実際、当初予定していたマイルストーンを超えることもあります
①ユーザース
トーリー抽出と
全体計画
②イテ
レーション
０
③イテレーショ
ン1
④イテレーショ
ン2
⑤イテレーショ
ン3

ULS
②イテレーション0
■イテレーション0の目的
– イテレーション1からスムーズに開発するために、開発標準や開発環境を整備しま
す。更に、要求に関する課題をユーザーヒアリングします
– 仮に、前の「ユーザーストーリー抽出と全体計画」が遅延する場合は、このイテレー
ション0をバッファとして使って、吸収します
■タスク
1. 環境構築とサンプル開発
2. ユーザーヒアリング&レビュー
3. ふりかえり
■ 開発標準や開発環境は開発チームが慣れているものを使います
– 特に問題がなければ、開発チームが今まで使ってきた慣れているものを利用しま
す。ウォーターフォール向けに作られているものは重厚長大なので、変えるという
よりも、不要なものを間引くのが良いでしょう。間引くだけなら時間もかかりません
①ユーザース
全体計画
②イテ
レーション
０
ン1
ン2
ン3

ULS
③イテレーション1
– 優先度が高い機能から、動く画面を確実に幾つか作り上げます
■タスク
1. イテレーション計画を立てる
3. 開発する
4. ふりかえり
■ 兎に角、動く画面を確実に幾つか作り上げます
– 2週間で数画面を確実に作り上げます。2週間で1人あたり1画面であれば、無理
な生産性ではないでしょう
– ウォーターフォールではこのタイミングで動く画面を見せる事はあり得ないので、
ユーザーは驚き、そして喜ぶことでしょう。さらにユーザーから仕様変更などの
フィードバックがあれば、優先度に従って対応します。対応の早さにユーザーから
の信頼は高まります。開発チームのモチベーションも上がります
①ユーザース
全体計画
②イテ
レーション
０
ン1
ン2
ン3

ULS
ユーザーの反応
■打ち合わせの終わりに、ユーザーに今回の開発の進め方についての現時点で
のご感想を伺いました。「いいね。すぐに修正してくれるのがいい。今までなら
完成してから見せられるので、文言を修正するだけでも費用がかかっていた」
とのコメントを頂きました
■「素早く開発して、すぐに確認する」ことがユーザーとの信頼関係を作る
– 仕様を確認した画面を、翌週には開発して動かして見せます
– ヒアリングした内容を、短期間に開発して、実際に見せることによって、ユーザーと
の間に信頼関係が生まれてきます
打ち合
わせ
打ち合
わせ
今日はこの画面につ
いて仕様をヒアリング
させてください
前回の打ち合わせで話をし
た画面ですが、開発してきた
ので確認をお願いします
翌週には見せる

ULS
立ち上げのポイント
①ユーザース
トーリー抽出と全
体計画
②イテレー
ション０
③イテレーション1 ④イテレーション2 ⑤イテレーション3
続く
1週間 2週間 2週間 2週間2週間
立ち上げ
ユーザーから好評を得て、開発チー
ムのモチベーションを上げます
出来るだけ、慣れ親しんでいる開発
標準や開発環境を利用します
アジャイル開発に慣れます
ユーザーストーリーの作成も全体計
画も100点を狙いません

ULS
④イテレーション2
– 顧客メンバー主体でプロジェクトを運営しはじめます。デイリーミーティングやふりか
えりを顧客メンバーが仕切って行い、アジャイルコーチはそれをサポートします
■タスク
1. イテレーション計画
3. 開発
4. ふりかえり
■ 自己組織化への第一歩
– ユーザーからアジャイル開発の進め方に好評を頂いたので、それを追い風にしてメ
ンバー主体で運営できるようにします。そのためには自己改善を強化する必要があ
るがあります。ときには、企業文化にメスを入れる必要があるかもしれません
①ユーザース
全体計画
②イテ
レーション
０
ン1
ン2
ン3

ULS
⑤イテレーション3
– 引き続き、顧客メンバー主体でプロジェクトを運営します。アジャイルコーチはサーバ
ントリーダーシップでサポートします
– 状況をみて、プラクティスを追加するなどやり方を改善します
■タスク
1. イテレーション計画
3. 開発
4. ふりかえり
■プラクティスを追加するなど、やり方を改善する
– ふりかえりなどで課題（Problem）として上がった内容で、プラクティスを追加するこ
とで改善するものがあればチームで追加の是非を話し合います。実際にあったのは
品質問題でした。単体テストのカバレッジを高めつつ、さらに手動テストをイテレー
ションの終わりに行うことにしました
①ユーザース
全体計画
②イテ
レーション
０
ン1
ン2
ン3

ULS
開発生産性は上昇
■開発チームがアジャイル開発に慣れてきて、ユーザーからの好評も後押しする
ことで開発生産性は少しずつ上昇してきました
最初はイテレーショ
ン0での準備もあり
高い生産性少し難しい機能
を開発する
リズムに乗り始める。
もっとプラクティスを
追加したくなる
アジャイル開発が楽しく
なってくる。もっとプラク
ティスを！
※少ないプラクティスか
ら始めているので、逆に
慣れてくるとプラクティ
スへの渇望が湧き上
がってくる。理想の形

ULS
自己組織化の成熟レベル
■開発チームの自己組織化の成熟レベルを次のように定義して、アジャイルコー
チとして評価しました
成熟レベル開発チームの状況必要な支援
1 初期メンバーはタスクを指示される。タスクに課題が
あっても解決に動けない
アジャイルコーチが必要
2 自立メンバーはタスクを指示される。タスクに課題が
あれば解決することができる。必要なら周りの助
けを求められる
3 課題解決メンバーはタスクを指示されるが、自分のタスク
だけでなく、他のメンバーの課題も積極的に解
決する
4 自己運営ゴールを達成するためのタスクを自分たちで作
り出せる。進捗管理や課題管理など自分たちで
運営できる
少しアジャイルな状態。ア
ジャイルコーチがふりかえ
りに入る
5 自己改善ゴールを達成するために自己分析して、自分た
ちで改善を行える。自分たちでルールを決める
ことができる
アジャイルな状態。アジャイ
ルコーチは居なくてもよい
3ヶ月前
現在
大きく成長

ULS
まとめ

ULS
シンプルなアジャイル開発に徹して、ユーザー価値を追求しましょう
■アジャイル開発を成功させるのであれば、ユーザーから好評を得て、開発チー
ムのモチベーションを高め、良いサイクルを回すことを目指すべきです
■そのためには超短期イテレーションを実現するための3つのコアプラクティスを
実践しなければなりません。ただし、これ以外のやり方は、従来（ウォーター
フォール）のやり慣れた方法にします
■最後に、アジャイル開発をプロジェクトの状況に合わせていくためには、アジャ
イルコーチに支援をしてもらった方が上手くいきます
【コアプラクティス】
① 優先度に従って開発する
② ユーザーレビューをする
③ ふりかえり／デイリーミーティングをする

エンタープライズへのアジャイル開発の導入事例

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to エンタープライズへのアジャイル開発の導入事例

Similar to エンタープライズへのアジャイル開発の導入事例 (20)

エンタープライズへのアジャイル開発の導入事例