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

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

Proprietary & Confidential Powered by

いまさらアジャイル巡業 in 広島

エンタープライズアジャイルがやってくる！

2016/3/12 アジャイル推進室

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

mailto:[email protected]

Tel: 03-6220-1420 Fax: 03-6220-1402


Proprietary & Confidential Powered by 1

目次

自己紹介

1. アジャイル開発

–どんなときにアジャイルを適用すべきか

–アジャイルは要求のギャップを埋める

–システム開発の考え方を変える（逆転の発想）

–アジャイル開発の流れ

2. エンタープライズアジャイル開発

–エンタープライズアジャイルとは

–エンタープライズアジャイルのKFS（Key Factor for Success）

–①要求分析の工夫

–②大規模開発

–③関係者が同じゴールを見る

ウルシステムズのエンタープライズアジャイル支援



自己紹介

吉原庄三郎（ヨシハラショウザブロウ）

– [email protected]

–ウルシステムズ株式会社

アジャイル推進室室長

マツダプロジェクト本部部長

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

–書籍執筆

はじめての設計をやり抜くための本（翔泳社）

– ISBN：9784798117065

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

–最近のWeb連載

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

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

– コミュニティ活動

アジャイルプロセス協議会、エンタープライズアジャイル勉強会など



1. アジャイル開発


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



どんなときにアジャイルを適用すべきか

ユーザに出来上がったシステムを見せたら、「依頼したのはこんなシステムではなかった」「イメージと違う」と言われた経験があるでしょうか

ユーザと開発側で要件定義した内容への理解が異なることが原因です。文章で書かれた要件だけでは、人によって捉え方が異なります

仮に、このセリフをユーザが言う可能性があるのであればアジャイルを適用すべきです。ウォーターフォールでは解決不可能です

欲しかったのはこんなシステムではなかった



アジャイルは要求のギャップを埋める

アジャイルの特徴は超短期イテレーション&リリースです（推奨は2週間）。ウォーターフォールでは達成不可能な超短期です

超短期イテレーション&リリースによるユーザ価値は次のものです

–ユーザに見せて要件へのフィードバックを得られる

–計画的に仕様変更を取り入れられる

–ユーザは開発した機能を早く利用できる

システム開発という受注生産方式において、ユーザが期待するイメージと、完成品のギャップは最大のリスクです。アジャイル開発とはこのリスクを限りなくゼロにするための手法です

要求

動くシステム

超短期イテレーション

ユーザ

確認

何度も繰り返す

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



システム開発は、ある要求を、限られたリソースで、決められた日程で作成することです。仮に、この3つを同時に満たすことが難しくなった場合に、ウォーターフォールとアジャイルでは何を調整するかが異なります

ウォーターフォールでは追加要員（コスト増）やリリース延期で調整しますが、アジャイルではリソースと日程は変えずにスコープ調整だけを行います。簡単に言えばリリースできる機能を減らすのです

このアジャイルの考え方には前提となる思想があり、「多くの場合、全ての機能が必須ということもなく、しばらくであれば手動で業務を行うことも可能」ということです

システム開発の考え方を変える（逆転の発想）

調整

固定要求

リソース（人）日程要求

リソース（人）日程

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

追加要員リリース延期スコープ調整



アジャイル開発の流れ

アジャイル開発はユーザからみた優先度の高いタスクから行います。タスクはチャンク（一口大）と呼ばれるような小さな単位にしておきます

開発チームは動くソフトウェアを開発して、ユーザが評価をします。問題なければ次のタスクに進み、問題があれば修正します

バックログ

タスク1

タスク2

タスク3

評価

次を着手[OK]

[NG]

ユーザが評価してNGであれば修正するために再度イテレーションで扱う

ユーザが評価する

超短期イテレーション

ユーザからみた優先度の高いタスクから行う

動くソフトウェア



2. エンタープライズアジャイル開発


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



エンタープライズアジャイルとは

アジャイル開発をエンタープライズシステム（企業システム）に適用するために拡張したものです。前提とするエンタープライズシステムは次のようなものです

–所謂、業務システム、基幹システムです

–開発規模は数百人月を超えます

–開発期間は半年から数年まであります

–仕様は比較的複雑なものが多いです

–開発は内製することもあれば、外部の開発パートナーと協同で行うこともあります。請負のように外部に任せっきりにはしません

内容は珍しいものではありません。ウォーターフォールであればよくある開発です。これを要求のギャップを埋めるためにアジャイル開発で行います



エンタープライズアジャイルのKFS（Key Factor for Success）

アジャイル開発をエンタープライズシステムに適用するためには、そのままでは足りません。次の考慮が必要です

–①要求分析の工夫

普通のアジャイル開発ではユーザーストーリーのように要求を簡単に記載するだけですが、エンタープライズシステムでは要求が複雑で、量が多いことが多く、何も考慮せずにアジャイル開発を適用すると上手く行きません

エンタープライズアジャイルではユースケース分析やデータモデリングなどを行って、ある程度は要求を明確に定義する必要があります

–②大規模開発への適応

エンタープライズシステムは大規模なものが多いです。ここで言う大規模とは、数百人月を超えるような単一のアジャイル開発チームでは手に負えない大きさのことです

普通のアジャイルは単一チームの運営を前提にしていますが、エンタープライズアジャイルともなると複数チームになります

–③関係者が同じゴールを見る

エンタープライズでは関係者も多く、利害も絡んで、ワンチームになるのが難しいことが多くあります



①要求分析の工夫

エンタープライズアジャイルを行った場合、最も大きな問題は要求分析（≒要件定義）がイテレーションの中で終わらないことです

ウォーターフォールでもそうですが、要求分析は非常に時間が掛かります。プロジェクトの多くが要求分析が原因で失敗しているといったデータもあります

要求分析に時間が掛かる主な理由

–現在の仕様を知っている人がいない

–多くのステークホルダーと調整しなければ要求を決められない

–誰も要求を最終決定することが出来ない

–そもそも要求分析は計画を立てにくい

通常、アジャイル開発ではイテレーションの中でプロダクトオーナーに質問することで要求を明確にします。プロダクトオーナーが全てを答えられればいいのですが、実際には何でも答えられるプロダクトオーナーはいません。そこで、エンタープライズアジャイルではイテレーションの前に要求の全体像を把握するためにアジャイルモデリングを実施します



①要求分析の工夫（続き）

普通のアジャイル（スクラム）

エンタープライズアジャイルで「アジャイルモデリング」を行う

プロダクトオーナー

開発チーム

開発チーム

アジャイルモデリング

プロダクトオーナー

プロダクトオーナーと並走しながら、アジャイルモデリングを行う

モデリングには多少の時間が掛かるため、アジャイルモデリングは少しだけ先行して行う



①要求分析の工夫（続き2）

アジャイルモデリングとは、要求を効果的にモデリングして、文章化するための手法です。重要なことは変化を受け入れられるようにモデリングを行うことです

そのため、アジャイルモデリングはXPの「コミュニケーション」、「シンプリシティ」、「フィードバック」、「勇気」、「リスペクト」という5つの価値を取り入れています。シンプリシティ（簡潔さ）は変化に対応するためには非常に重要です

アジャイルモデリングの成果物

–ユースケース記述

–ビジネスルール定義

–概念モデル

他にも必要なら業務フローを作成したり、現状分析（AS-IS）も行います。ともかく、プロダクトオーナーが適切に優先度を付けられ、仕様を答えられるレベルまで要求分析します



①要求分析の工夫～事例

製造業のM社（マツダ様ではなく）では、棚卸資産圧縮（仕掛在庫・製品在庫の削減）、リードタイム短縮、利益向上、顧客満足度の向上といったビジネス目標を達成しようとされていました

そのためにはウォーターフォールのような硬直した方法ではなく、もっと柔軟な方法が必要になり、アジャイル開発を採用されました

アジャイル開発を導入する上で、要求分析をきちんと実施して、ビジネス目標とシステム要求を関係者で共有し、優先順位を付けて計画できるようにしました。これによって決められた体制と期間の中でプロジェクト目標を達成することができました

アジャイル開発でありながら要求分析をきちんと実施するためには工夫が必要です。具体的には、要求分析と開発のサイクルを少しずらすことで、次イテレーションへの移行を容易にしました

要求分析

開発

要求分析

開発



エンタープライズシステムでは、100人月を超える開発規模であることは珍しくありません。仮に、500人月のシステムを1年半でアジャイル開発するとして、9人のチームが3チーム必要になります

サブシステムに分割して開発するので、リリース前には結合する必要があります。また、この3チームが同じ部屋になることは難しく、各チームが地理的に分散して開発することになります

チームが複数になり、作業場所が異なると次のような考慮が必要になります

– （A）チーム間でアーキテクチャを共通化しなければならない

– （B）チーム間で要求を整合させなければならない

②大規模開発

Aチーム

Bチーム

Cチーム



②大規模開発～（A）チーム間でアーキテクチャを共通化しなければならない

普通、アジャイル開発ではアーキテクチャは事前に作るものではなく、イテレーションを繰り返すことで自然発生するものだとあります

しかし、チームが複数になるエンタープライズアジャイルでは、アーキテクチャを意識的に共通化しなければなりません。チーム毎に異なるアーキテクチャを採用しては、後でサブシステムを結合してリリースできなくなります

そのため、エンタープライズアジャイルでは先行してアーキテクチャを構築する活動が必要になります。具体的にはイテレーション1の前にイテレーション0を設けて、アーキテクチャの先行検討を行います。さらに、イテレーション1以降のイテレーションでは、アーキテクチャの拡張・保守のために、アーキテクチャチームを専門に編成します

先攻チーム

#1 #2 #3 #4

アーキテクチャチーム

アプリチーム

#0



②大規模開発～（B）チーム間で要求を整合させなければならない

普通、アジャイル開発では要求をドキュメントとして明文化せずに、ユーザストーリーと呼ばれる要求を簡易に記載したものを使用します

–例、「客として、商品をカートに入れることができる」

しかし、ユーザストーリーでは余りに内容が薄く、エンタープライズシステムの要件を記載するものとしては不足です。例えば、「発注条件」など、業務ルールを記載することが出来ません。もちろん、従来の重厚な要件定義書を作成する訳にもいきません

そこで、エンタープライズではユーザストーリーの代わりにユースケース記述を作成します。ユースケース記述はユーザがシステムをどのように使うかをシナリオとして順列にしたものです。要求仕様を網羅的に記述するには最適なものです。ユーザストーリーよりも記載する手間はかかりますが、エンタープライズにはユースケース記述が最適です

また、チームが複数に分かれたときにでも要求が整合とれるように、プロダクトオーナーがチームを跨って要求を管理するようにします



②大規模開発～事例

製造業のM社では、基幹システムのリプレースにアジャイル開発を導入しました。それは、複数チームが同時開発する大規模アジャイルでした

複数チームが同時開発するため、標準チームを開発チームとは別に編成して、フレームワークの整備や標準化を行いました

最初は標準チームが上手く立ち上がらず、標準化が開発よりも後手になりましたが、なんとか立てなおして現在は問題なく機能しています

標準チーム

開発チームB開発チームA

標準チーム

開発チームB開発チームA

最初その後

立ち上がらなかった



③関係者が同じゴールを見る

従来の方法からアジャイル開発にやり方を変えるケースでは、関係者が同じゴールを共有することが重要です

従来の方法はウォーターフォールなどが多いと思いますが、その従来の方法に組織もメンバーも慣れ親しんでいます。その慣れ親しんだ方法を変えることになるので、アジャイル開発を適用することはちょっとした変革をもたらします

慣れた方法をやめることは痛みを伴います。小さな成功体験を積み重ねることができなければ、アジャイル開発を導入することに反対することになります




企業にアジャイル開発を導入するためには、開発側にエンタープライズアジャイルを導入できること、発注側も適応するためのコンサルティングが必要です

この2つを支援できる会社はウルシステムズ以外にありません


発注側（業務部門、情シス）

開発側（アジャイル）

要求

超短期リリース

フィードバック

PO

※POとはプロダクトオーナー（要求をまとめる役割）

開発側にエンタープライズアジャイルを適用する

＜標準化・開発支援＞

発注側をエンタープライズアジャイルに適応させる＜コンサルティング＞



Be agile with us!

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

Software

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

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

Software

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

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

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