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

ULSCopyright © 2011-2016 UL Systems, Inc. All rights reserved.

Proprietary & Confidential Powered by

いまさらアジャイル巡業 in TokyoRe: エンタープライズへのアジャイル開発の導入事例「アジャイル開発で絶対に外せないコアプラクティス」

吉原庄三郎2016/11/19

ウルシステムズ株式会社http://www.ulsystems.co.jp

mailto:[email protected]: 03-6220-1420 Fax: 03-6220-1402


Proprietary & Confidential Powered by 2

はじめに

アジャイル開発を書籍に書いてあるように実践しても上手く行きません。特にエンタープライズにアジャイル開発を適用するには制約（しがらみ）が多く、プロジェクトの状況にあわせてテーラリングすべきです

そこで、アジャイル開発の本来の価値に立ち返り、アジャイル開発として最低限行うべきであるコアプラクティスを考えました。本日はコアプラクティスを軸にエンタープライズにアジャイル開発を適用する事例を紹介します



自己紹介

吉原庄三郎　（ヨシハラ　ショウザブロウ）– [email protected]

– ウルシステムズ株式会社アジャイル推進室室長

– https://www.ulsystems.co.jp/

– 書籍執筆はじめての設計をやり抜くための本（翔泳社）

– ISBN ： 9784798117065– 定価：本体 2,380 円＋税

– 最近の Web 連載 ZDNet - まだまだ応用できる -- 今から始めるアジャイル開発の勘所

– http://japan.zdnet.com/cio/sp_15agile/

– コミュニティ活動アジャイルプロセス協議会、エンタープライズアジャイル勉強会など



目次

1. アジャイルのコアプラクティス1. アジャイルは難しい！？2. 「過ぎたるは猶及ばざるが如し」3. アジャイル開発の「ユーザー価値」4. アジャイル開発の 3 つのコアプラク

ティス5. アジャイルコーチは開発チーム状況

に合わせてバランスをとる

2. 事例紹介1. ここから本題2. プロジェクトの概要3. プロダクトオーナー・プロキシ4. プロジェクトのスケジュール5. コーチングプラン6. 最低限のプラクティスを導入する7. プロジェクトの進め方

8. ① ユーザーストーリー抽出と全体計画

9. ② イテレーション 010. ③ イテレーション 111. ユーザーの反応12. 立ち上げのポイント13. ④ イテレーション 214. ⑤ イテレーション 315. 開発生産性は上昇16. 自己組織化の成熟レベル

3. まとめ



アジャイルのコアプラクティスRe: エンタープライズへのアジャイル開発の導入事例



アジャイルは難しい！？

色々な人からアジャイル開発で失敗した事例を聞くと、多くのケースでアジャイルをやることに頑張りすぎていることに気が付きました

例えば、アジャイルソフトウェア宣言にある 4 つの価値と 12 の原則をきっちり守り、プラクティスも何十個も適用してしまうのです。忠実にアジャイルをやろうとすればするほど、イテレーションでやらなければならないことが増えていきます。アジャイルをやることに頑張りすぎてしまい、肝心のシステム開発は遅々として進みません

① 原則を守って、プラクティスも沢山適用して忠実なアジャイルをやる

ぞ！

② アジャイルってやること多くて、なかなかシステムを開発できないなぁ

③ もっとアジャイルになるために、ドキュメントは廃止しよう。プラクティスも

追加しよう

④ どうやっても生産性があがらな

い・・・アジャイルって難しい

悪循環 ?



「過ぎたるは猶及ばざるが如し」

プラクティスを増やせば増やすほど上手くいくのであればアジャイル開発はもっと簡単ですが、残念ながらそうではありません。理由はアジャイルというより、システム開発というものが人間を中心にした活動だからです。極端なやり方は人間がついて行けません

どこまでやるか、このバランスを取ることが必要です。ウォーターフォールでもプロジェクトマネージャーが普通にやっていることです。アジャイルではアジャイルコーチがこのバランスを取ります

アジャイルウォーターフォール

上手くいかないから、もっとアジャイルのプラクティスを追加しよう

か・・・

この線より左にいくとアジャイルの価値を達成できない。これがコアプラ

クティス



アジャイル開発の価値

ウォーターフォールでよくある机上で定義した要件と、実際にリリースされたシステムとのギャップを埋めるということです

ギャップを埋めるためには、どうする？– 超短期イテレーションで素早く動くシステムをユーザーに見せます– ユーザーは動くシステムを実際に確認してフィードバックします– フィードバックを計画的にシステムへ反映します

アジャイルの価値とは、超短期イテレーションを繰り返すことで、

ユーザーが本当に望むシステムを実現すること

フィードバック

動くシステム

超短期イテレーション

ユーザー確認

何度も繰り返す

イテレーションの度に実際に動くシステムを操作して確認する



コアプラクティス

アジャイル開発に詳しい人ほど、多くのプラクティスを駆使しようとします。しかし、先にも述べたようにプラクティスを多くすればするほど悪循環に陥り、成功する可能性は低くなります

そこで、コアプラクティスというものを考えます。アジャイル開発の価値である超短期イテレーションを実現するためのキーとなるプラクティスをコアプラクティスと定義します

超短期イテレーション？？？

？？？

？？？

コアプラクティス

アジャイル開発の価値

（ユーザー価値）

プラクティス A

プラクティス B

プラクティス C

プラクティス D

プラクティス E

プラクティス



3 つのコアプラクティス

これ以外は従来（ウォーターフォール）の手法でも構いません。まずは、超短期イテレーションに慣れることが重要です。しばらくして慣れてきたらプラクティスを追加すべきです

① 優先度に従って開発するユーザーストーリーでも機能一覧でもいいのでプロダクトオーナー相当の人に優先度を付けてもらう。その優先度に従って順番にイテレーションで開発する

② ユーザーレビューをするユーザーに動くシステムを使ってもらって意見をもらいます。仕様変更や仕様

追加があれば優先度を付けて、次のイテレーションの計画に反映します

③ ふりかえり／デイリーミーティングをする日々のデイリーミーティングや、イテレーションの終わりのふりかえりを行い

ます。ユーザー満足、品質、生産性を改善するためにはどうするかを話し合います



アジャイルコーチは開発チーム状況に合わせてバランスをとる

アジャイル開発はクスリのようなものです。どんな良薬も沢山投与しては逆効果です。患者の状況に応じて適切な量とタイミングで投与すべきです

アジャイルコーチは主治医のように相手の状態を診断して、適切な量とタイミングでプラクティスというクスリを投入します

アジャイルウォーターフォール

アジャイルコーチがバランスをとる

超短期イテレーションを回すための 3 つのコアプラクティス• 優先度に従って開発する• ユーザーレビューをする• ふりかえり／デイリーミーティングをする



事例紹介Re: エンタープライズへのアジャイル開発の導入事例



ここから本題

先に上げたコアプラクティスを軸にして、

最低限のプラクティスを見繕って、実際にアジャイルコーチを行った

事例を紹介します



プロジェクトの概要

会員向けポータルサイトをアジャイル開発で再構築します

背景– 顧客は某会社の情報システム部門です。以前からアジャイル開発を導入した

いと考えていました。今回、最適なトライアルプロジェクトがはじまることになりました

開発規模– 画面 20程度– バッチ 5程度

開発体制– プロダクトオーナー顧客メンバー– 開発チーム顧客メンバーから数名– アジャイルコーチ私（吉原）

– 顧客メンバーは全員がアジャイル開発をやったことがありません。どちらかと言えば、「本当にできるの？」と懐疑的でした



プロダクトオーナー・プロキシ

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

通常のプロダクトオーナーの責務

今回のプロダクトオーナーの責務（エンタープライズでは多い）開発チームプロダクトオーナーユーザー

開発チームプロダクトオーナー

要求や優先度の決定

要求や優先度の決定

要求や優先度の取りまとめ



プロジェクトのスケジュール

プロジェクトは 5ヶ月程度あるが、アジャイルコーチによる支援は最初の 3ヶ月だけです。残り 2ヶ月は顧客メンバーだけで運営します

ユーザーストーリーの抽出と全体計画

イテレーション開発リリース

アジャイルコーチ（ 3ヶ月）

開発全体（ 5ヶ月程度）



コーチングプラン

まず、今回のプロジェクトでは現場のメンバーはアジャイル開発に半信半疑なので、まずはアジャイル開発の価値を実感してもらう必要があります。価値を実感できればモチベーションも上がり、良いサイクルを作れます

早めにアジャイル開発の価値を実感

ユーザーに動く画面を早めに見せる

生産性を高めるプラクティスを最低限にする

イテレーション期間を短く

作業場所を同じ部屋にする

イテレーション期間を 2週間

ゴールアクション

既存の開発標準を出来るだけ踏

襲する

良いサイクル

① ユーザーに動く画面を早めに見せる

② ユーザーが喜んでくれる

③ ユーザーが喜べば、開発チームも

喜ぶ

④ 開発チームは、はりきって開発す

る



11 継続的インテグレーションプロダクトの問題を早期に効率的に発見する

12 テスト自動化デグレーションを防止する

最低限のプラクティスを導入する

今回実践したプラクティス

途中から状況にあわせて本格的に導入したプラクティス

# プラクティス内容

1 超短期イテレーション 2週間毎に動くプロダクトを開発する

2 インセプションデッキ開発チームでゴールと進め方を共有する

3 ユーザーストーリー顧客の要求を端的に表す

4 相対的な見積りストーリーポイントで相対的に見積る

5 全体計画リリースに向けての規模見積やスケジュールを決める

6 イテレーション計画イテレーションで開発する対象を決める

7 デイリーミーティング 1 日単位で開発チームの進捗と課題を共有する

8 ふりかえり開発チームがより高い能力を発揮できるように議論する

9 プロダクトバックログ顧客の要求の内容、完了条件、優先順位を管理する

10 かんばんメンバーの作業内容を見える化する



プロジェクトの進め方

① ユーザーストーリー抽出と全体計画のタイムボックスは 2週間です

② イテレーション 0 を開発準備として 1週間とります。開発準備をすることでイテレーション 1以降の生産性を高めます。ユーザーに動く画面を見せることで、良いサイクルを作ります。イテレーション 0 はバッファでもあります。万が一、①ユーザーストーリー抽出と全体計画が遅延したときに吸収します

③ イテレーション 1以降はイテレーション開発です。期間は 2週間とします。短くすることで頻繁にユーザーに動くシステムを提供します

① ユーザーストーリー抽出と

全体計画

② イテレーション

０

③ イテレーション 1

④ イテレーション 2

⑤ イテレーション 3

続く

1週間 2週間 2週間 2週間2週間



① ユーザーストーリー抽出と全体計画

「ユーザーストーリー抽出と全体計画」の目的– 開発を行うために要求分析や全体計画などを行います

タスク1. オリエンテーションの実施（約 1 日）2. インセプションデッキの作成（約 2 日）3. ユーザーストーリーの作成と優先度付け（約 3 日）4. 全体計画の策定（約 4 日）

ユーザーストーリーは 100点を狙いません– 3 日間とタイムボックスを決めたのであれば、その期間で収まるように作業

をします。手元にある状況を整理して、課題を明確にしてユーザーにヒアリングできる状態にします。スピード感を持って行います

全体計画が成立しないことも– 抽出したユーザーストーリーを一覧にして、ストーリーポイントを見積りま

す。ストーリーポイントと生産性（ベロシティ）の仮定値で計算すれば、全てを開発するための期間がわかります。実際、当初予定していたマイルストーンを超えることもあります


② イテレーショ

ン０






② イテレーション 0 イテレーション 0 の目的

– イテレーション 1 からスムーズに開発するために、開発標準や開発環境を整備します。更に、要求に関する課題をユーザーヒアリングします

– 仮に、前の「ユーザーストーリー抽出と全体計画」が遅延する場合は、このイテレーション 0 をバッファとして使って、吸収します

タスク1. 環境構築とサンプル開発2. ユーザーヒアリング & レビュー3. ふりかえり

開発標準や開発環境は開発チームが慣れているものを使います– 特に問題がなければ、開発チームが今まで使ってきた慣れているものを利

用します。ウォーターフォール向けに作られているものは重厚長大なので、変えるというよりも、不要なものを間引くのが良いでしょう。間引くだけなら時間もかかりません



ン０






③ イテレーション 1 イテレーション 1 の目的

– 優先度が高い機能から、動く画面を確実に幾つか作り上げます

タスク1. イテレーション計画を立てる2. ユーザーヒアリング & レビュー3. 開発する4. ふりかえり

兎に角、動く画面を確実に幾つか作り上げます– 2週間で数画面を確実に作り上げます。 2週間で 1 人あたり 1 画面であれ

ば、無理な生産性ではないでしょう– ウォーターフォールではこのタイミングで動く画面を見せる事はあり得な

いので、ユーザーは驚き、そして喜ぶことでしょう。さらにユーザーから仕様変更などのフィードバックがあれば、優先度に従って対応します。対応の早さにユーザーからの信頼は高まります。開発チームのモチベーションも上がります



ン０






ユーザーの反応

打ち合わせの終わりに、ユーザーに今回の開発の進め方についての現時点でのご感想を伺いました。「いいね。すぐに修正してくれるのがいい。今までなら完成してから見せられるので、文言を修正するだけでも費用がかかっていた」とのコメントを頂きました

「素早く開発して、すぐに確認する」ことがユーザーとの信頼関係を作る

– 仕様を確認した画面を、翌週には開発して動かして見せます

– ヒアリングした内容を、短期間に開発して、実際に見せることによって、ユーザーとの間に信頼関係が生まれてきます

打ち合わせ

打ち合わせ

今日はこの画面について仕様をヒアリングさせてくだ

さい

前回の打ち合わせで話をした画面ですが、開発してきたので確認をお願い

します

翌週には見せる



立ち上げのポイント

① ユーザーストーリー抽出と

全体計画

② イテレーション

０




続く

1週間 2週間 2週間 2週間2週間

立ち上げ

ユーザーから好評を得て、開発チームのモチベーションを上げ

ます

出来るだけ、慣れ親しんでいる開発標準や開発環境を利用します

アジャイル開発に慣れます

ユーザーストーリーの作成も全体計画も 100点を狙いません



④ イテレーション 2 イテレーション 2 の目的

– 顧客メンバー主体でプロジェクトを運営しはじめます。デイリーミーティングやふりかえりを顧客メンバーが仕切って行い、アジャイルコーチはそれをサポートします

タスク1. イテレーション計画2. ユーザーヒアリング & レビュー3. 開発4. ふりかえり

自己組織化への第一歩– ユーザーからアジャイル開発の進め方に好評を頂いたので、それを追い風に

してメンバー主体で運営できるようにします。そのためには自己改善を強化する必要があるがあります。ときには、企業文化にメスを入れる必要があるかもしれません



ン０






⑤ イテレーション 3 イテレーション 3 の目的

– 引き続き、顧客メンバー主体でプロジェクトを運営します。アジャイルコーチはサーバントリーダーシップでサポートします

– 状況をみて、プラクティスを追加するなどやり方を改善します

タスク1. イテレーション計画2. ユーザーヒアリング & レビュー3. 開発4. ふりかえり

プラクティスを追加するなど、やり方を改善する– ふりかえりなどで課題（ Problem ）として上がった内容で、プラクティス

を追加することで改善するものがあればチームで追加の是非を話し合います。実際にあったのは品質問題でした。単体テストのカバレッジを高めつつ、さらに手動テストをイテレーションの終わりに行うことにしました



ン０






開発生産性は上昇

開発チームがアジャイル開発に慣れてきて、ユーザーからの好評も後押しすることで開発生産性は少しずつ上昇してきました

最初はイテレーション 0 での準備もあり高い生産性少し難しい機

能を開発する

リズムに乗り始める。もっとプラクティスを追加した

くなる

アジャイル開発が楽しくなってくる。

もっとプラクティスを！

※ 少ないプラクティスから始めているので、逆に慣れてくるとプラクティスへの渇望が湧き上がって

くる。理想の形



自己組織化の成熟レベル

開発チームの自己組織化の成熟レベルを次のように定義して、アジャイルコーチとして評価しました

成熟レベル開発チームの状況必要な支援

1 初期メンバーはタスクを指示される。タスクに課題があっても解決に動けない

アジャイルコーチが必要

2 自立メンバーはタスクを指示される。タスクに課題があれば解決することができる。必要なら周りの助けを求められる


3 課題解決メンバーはタスクを指示されるが、自分のタスクだけでなく、他のメンバーの課題も積極的に解決する


4 自己運営ゴールを達成するためのタスクを自分たちで作り出せる。進捗管理や課題管理など自分たちで運営できる

少しアジャイルな状態。アジャイルコーチがふりかえりに入る

5 自己改善ゴールを達成するために自己分析して、自分たちで改善を行える。自分たちでルールを決めることができる

アジャイルな状態。アジャイルコーチは居なくてもよい

3ヶ月前

現在

大きく成長



まとめRe: エンタープライズへのアジャイル開発の導入事例



シンプルなアジャイル開発に徹して、ユーザー価値を追求しましょう

アジャイル開発を成功させるのであれば、ユーザーから好評を得て、開発チームのモチベーションを高め、良いサイクルを回すことを目指すべきです

そのためには超短期イテレーションを実現するための 3 つのコアプラクティスを実践しなければなりません。ただし、これ以外のやり方は、従来（ウォーターフォール）のやり慣れた方法にします

最後に、アジャイル開発をプロジェクトの状況に合わせていくためには、アジャイルコーチに支援をしてもらった方が上手くいきます

【コアプラクティス】① 優先度に従って開発する

② ユーザーレビューをする

③ ふりかえり／デイリーミーティングをする

Software

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