Ulsアジャイル推進室エンタープライズアジャイルがやってくる！ 20160312

ULS
Copyright © 2011-2015 UL Systems, Inc. All rights reserved.
Proprietary & Confidential Powered by
いまさらアジャイル巡業 in 広島
エンタープライズアジャイルがやってくる！
2016/3/12 アジャイル推進室
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems.co.jp
Tel: 03-6220-1420 Fax: 03-6220-1402

ULS
Proprietary & Confidential Powered by 1
目次
自己紹介
1. アジャイル開発
– どんなときにアジャイルを適用すべきか
– アジャイルは要求のギャップを埋める
– システム開発の考え方を変える（逆転の発想）
– アジャイル開発の流れ
2. エンタープライズアジャイル開発
– エンタープライズアジャイルとは
– エンタープライズアジャイルのKFS（Key Factor for Success）
– ①要求分析の工夫
– ②大規模開発
– ③関係者が同じゴールを見る
ウルシステムズのエンタープライズアジャイル支援

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. アジャイル開発
「エンタープライズアジャイルがやってくる！」

ULS
どんなときにアジャイルを適用すべきか
ユーザに出来上がったシステムを見せたら、「依頼したのはこんなシステムで
はなかった」「イメージと違う」と言われた経験があるでしょうか
ユーザと開発側で要件定義した内容への理解が異なることが原因です。文章
で書かれた要件だけでは、人によって捉え方が異なります
仮に、このセリフをユーザが言う可能性があるのであればアジャイルを適用す
べきです。ウォーターフォールでは解決不可能です
欲しかったのはこんなシステムではなかった

ULS
アジャイルは要求のギャップを埋める
アジャイルの特徴は超短期イテレーション&リリースです（推奨は2週間）。ウォ
ーターフォールでは達成不可能な超短期です
超短期イテレーション&リリースによるユーザ価値は次のものです
– ユーザに見せて要件へのフィードバックを得られる
– 計画的に仕様変更を取り入れられる
– ユーザは開発した機能を早く利用できる
システム開発という受注生産方式において、ユーザが期待するイメージと、完
成品のギャップは最大のリスクです。アジャイル開発とはこのリスクを限りなく
ゼロにするための手法です
要求
動くシステム
超短期
イテレーション
ユーザ
確認
何度も繰り返す
イテレーションの度に実際に
動くシステムを操作して確認する

ULS
 システム開発は、ある要求を、限られたリソースで、決められた日程で作成すること
です。仮に、この3つを同時に満たすことが難しくなった場合に、ウォーターフォール
とアジャイルでは何を調整するかが異なります
 ウォーターフォールでは追加要員（コスト増）やリリース延期で調整しますが、アジャ
イルではリソースと日程は変えずにスコープ調整だけを行います。簡単に言えばリ
リースできる機能を減らすのです
 このアジャイルの考え方には前提となる思想があり、「多くの場合、全ての機能が
必須ということもなく、しばらくであれば手動で業務を行うことも可能」ということです
システム開発の考え方を変える（逆転の発想）
調整
固定
要求
リソース（人）日程要求
リソース（人）日程
ウォーターフォールアジャイル
追加要員リリース延期スコープ調整

ULS
アジャイル開発の流れ
アジャイル開発はユーザからみた優先度の高いタスクから行います。タスクは
チャンク（一口大）と呼ばれるような小さな単位にしておきます
開発チームは動くソフトウェアを開発して、ユーザが評価をします。問題なけれ
ば次のタスクに進み、問題があれば修正します
バックログ
タスク1
タスク2
タスク3
評価
次を着手
[OK]
[NG]
ユーザが評価して
NGであれば修正
するために再度イ
テレーションで扱う
ユーザが評価する
超短期
イテレーション
ユーザからみた
優先度の高いタ
スクから行う
動くソフトウェア

ULS
2. エンタープライズアジャイル開発
「エンタープライズアジャイルがやってくる！」

ULS
エンタープライズアジャイルとは
アジャイル開発をエンタープライズシステム（企業システム）に適用するために
拡張したものです。前提とするエンタープライズシステムは次のようなものです
– 所謂、業務システム、基幹システムです
– 開発規模は数百人月を超えます
– 開発期間は半年から数年まであります
– 仕様は比較的複雑なものが多いです
– 開発は内製することもあれば、外部の開発パートナーと協同で行うこともあります。
請負のように外部に任せっきりにはしません
内容は珍しいものではありません。ウォーターフォールであればよくある開発で
す。これを要求のギャップを埋めるためにアジャイル開発で行います

ULS
エンタープライズアジャイルのKFS（Key Factor for Success）
アジャイル開発をエンタープライズシステムに適用するためには、そのままで
は足りません。次の考慮が必要です
– ①要求分析の工夫
 普通のアジャイル開発ではユーザーストーリーのように要求を簡単に記載するだけですが
、エンタープライズシステムでは要求が複雑で、量が多いことが多く、何も考慮せずにアジ
ャイル開発を適用すると上手く行きません
 エンタープライズアジャイルではユースケース分析やデータモデリングなどを行って、ある
程度は要求を明確に定義する必要があります
– ②大規模開発への適応
 エンタープライズシステムは大規模なものが多いです。ここで言う大規模とは、数百人月を
超えるような単一のアジャイル開発チームでは手に負えない大きさのことです
 普通のアジャイルは単一チームの運営を前提にしていますが、エンタープライズアジャイ
ルともなると複数チームになります
– ③関係者が同じゴールを見る
 エンタープライズでは関係者も多く、利害も絡んで、ワンチームになるのが難しいことが多
くあります

ULS
①要求分析の工夫
エンタープライズアジャイルを行った場合、最も大きな問題は要求分析（≒要件
定義）がイテレーションの中で終わらないことです
ウォーターフォールでもそうですが、要求分析は非常に時間が掛かります。プ
ロジェクトの多くが要求分析が原因で失敗しているといったデータもあります
要求分析に時間が掛かる主な理由
– 現在の仕様を知っている人がいない
– 多くのステークホルダーと調整しなければ要求を決められない
– 誰も要求を最終決定することが出来ない
– そもそも要求分析は計画を立てにくい
通常、アジャイル開発ではイテレーションの中でプロダクトオーナーに質問する
ことで要求を明確にします。プロダクトオーナーが全てを答えられればいいので
すが、実際には何でも答えられるプロダクトオーナーはいません。そこで、エン
タープライズアジャイルではイテレーションの前に要求の全体像を把握するた
めにアジャイルモデリングを実施します

ULS
①要求分析の工夫（続き）
普通のアジャイル（スクラム）
エンタープライズアジャイルで「アジャイルモデリング」を行う
プロダクトオーナー
開発チーム
開発チーム
アジャイルモデリング
プロダクトオーナー
プロダクトオーナーと並
走しながら、アジャイル
モデリングを行う
モデリングには多少の
時間が掛かるため、ア
ジャイルモデリングは少
しだけ先行して行う

ULS
①要求分析の工夫（続き2）
アジャイルモデリングとは、要求を効果的にモデリングして、文章化するための
手法です。重要なことは変化を受け入れられるようにモデリングを行うことです
そのため、アジャイルモデリングはXPの「コミュニケーション」、「シンプリシティ」
、「フィードバック」、「勇気」、「リスペクト」という5つの価値を取り入れています。
シンプリシティ（簡潔さ）は変化に対応するためには非常に重要です
アジャイルモデリングの成果物
– ユースケース記述
– ビジネスルール定義
– 概念モデル
他にも必要なら業務フローを作成したり、現状分析（AS-IS）も行います。とも
かく、プロダクトオーナーが適切に優先度を付けられ、仕様を答えられるレベル
まで要求分析します

ULS
①要求分析の工夫～事例
製造業のM社（マツダ様ではなく）では、棚卸資産圧縮（仕掛在庫・製品在庫の
削減）、リードタイム短縮、利益向上、顧客満足度の向上といったビジネス目標
を達成しようとされていました
そのためにはウォーターフォールのような硬直した方法ではなく、もっと柔軟な
方法が必要になり、アジャイル開発を採用されました
アジャイル開発を導入する上で、要求分析をきちんと実施して、ビジネス目標と
システム要求を関係者で共有し、優先順位を付けて計画できるようにしました。
これによって決められた体制と期間の中でプロジェクト目標を達成することがで
きました
アジャイル開発でありながら要求分析をきちんと実施するためには工夫が必要
です。具体的には、要求分析と開発のサイクルを少しずらすことで、次イテレー
ションへの移行を容易にしました
要求分析
開発
要求分析
開発

ULS
エンタープライズシステムでは、100人月を超える開発規模であることは珍しく
ありません。仮に、500人月のシステムを1年半でアジャイル開発するとして、9
人のチームが3チーム必要になります
サブシステムに分割して開発するので、リリース前には結合する必要がありま
す。また、この3チームが同じ部屋になることは難しく、各チームが地理的に分
散して開発することになります
チームが複数になり、作業場所が異なると次のような考慮が必要になります
– （A）チーム間でアーキテクチャを共通化しなければならない
– （B）チーム間で要求を整合させなければならない
②大規模開発
Aチーム
Bチーム
Cチーム

ULS
②大規模開発～（A）チーム間でアーキテクチャを共通化しなければならない
普通、アジャイル開発ではアーキテクチャは事前に作るものではなく、イテレー
ションを繰り返すことで自然発生するものだとあります
しかし、チームが複数になるエンタープライズアジャイルでは、アーキテクチャ
を意識的に共通化しなければなりません。チーム毎に異なるアーキテクチャを
採用しては、後でサブシステムを結合してリリースできなくなります
そのため、エンタープライズアジャイルでは先行してアーキテクチャを構築する
活動が必要になります。具体的にはイテレーション1の前にイテレーション0を
設けて、アーキテクチャの先行検討を行います。さらに、イテレーション1以降
のイテレーションでは、アーキテクチャの拡張・保守のために、アーキテクチャ
チームを専門に編成します
先攻チーム
#1 #2 #3 #4
アーキテクチャ
チーム
アプリチーム
#0

ULS
②大規模開発～（B）チーム間で要求を整合させなければならない
普通、アジャイル開発では要求をドキュメントとして明文化せずに、ユーザスト
ーリーと呼ばれる要求を簡易に記載したものを使用します
– 例、「客として、商品をカートに入れることができる」
しかし、ユーザストーリーでは余りに内容が薄く、エンタープライズシステムの
要件を記載するものとしては不足です。例えば、「発注条件」など、業務ルール
を記載することが出来ません。もちろん、従来の重厚な要件定義書を作成する
訳にもいきません
そこで、エンタープライズではユーザストーリーの代わりにユースケース記述を
作成します。ユースケース記述はユーザがシステムをどのように使うかをシナ
リオとして順列にしたものです。要求仕様を網羅的に記述するには最適なもの
です。ユーザストーリーよりも記載する手間はかかりますが、エンタープライズ
にはユースケース記述が最適です
また、チームが複数に分かれたときにでも要求が整合とれるように、プロダクト
オーナーがチームを跨って要求を管理するようにします

ULS
②大規模開発～事例
製造業のM社では、基幹システムのリプレースにアジャイル開発を導入しまし
た。それは、複数チームが同時開発する大規模アジャイルでした
複数チームが同時開発するため、標準チームを開発チームとは別に編成して
、フレームワークの整備や標準化を行いました
最初は標準チームが上手く立ち上がらず、標準化が開発よりも後手になりまし
たが、なんとか立てなおして現在は問題なく機能しています
標準チーム
開発チームB開発チームA
標準チーム
開発チームB開発チームA
最初その後
立ち上がらなかった

ULS
③関係者が同じゴールを見る
従来の方法からアジャイル開発にやり方を変えるケースでは、関係者が同じゴ
ールを共有することが重要です
従来の方法はウォーターフォールなどが多いと思いますが、その従来の方法
に組織もメンバーも慣れ親しんでいます。その慣れ親しんだ方法を変えること
になるので、アジャイル開発を適用することはちょっとした変革をもたらします
慣れた方法をやめることは痛みを伴います。小さな成功体験を積み重ねること
ができなければ、アジャイル開発を導入することに反対することになります

ULS
ウルシステムズのエンタープライズアジャイル支援
企業にアジャイル開発を導入するためには、開発側にエンタープライズアジャ
イルを導入できること、発注側も適応するためのコンサルティングが必要です
この2つを支援できる会社はウルシステムズ以外にありません
ウルシステムズのエンタープライズアジャイル支援
発注側
（業務部門、情シス）
開発側
（アジャイル）
要求
超短期リリース
フィードバック
PO
※POとはプロダクトオーナー（要求をまとめる役割）
開発側にエンタープライズアジャ
イルを適用する
＜標準化・開発支援＞
発注側をエンタープライズアジャ
イルに適応させる
＜コンサルティング＞

ULS
Be agile with us!

Ulsアジャイル推進室エンタープライズアジャイルがやってくる！ 20160312

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Ulsアジャイル推進室エンタープライズアジャイルがやってくる！ 20160312

Similar to Ulsアジャイル推進室エンタープライズアジャイルがやってくる！ 20160312 (20)