株式会社オージス総研

OGIS Scalable Agile Method 2.0入門 (株)オージス総研 技術部アジャイル開発センター

藤井 拓、張 嵐

2016/02/05

本文書では、要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、

「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かすため

の課題に対する解決策として考案した OGIS Scalable Agile Method 2.0（以降、

OSAM2.0と略す）の概要を説明する。まず、 OSAM 2.0を考案した動機を説明し、

スクラムとユーザーストーリーだけで開発を行うことの不十分点を説明する。次に、

OSAM 2.0の基本コンセプトと、OSAM2.0の基本形の構成要素である DtoD

( Discover to Deliver)と受け入れ駆動開発(A-TDD)の概要を説明する。さらに、

OSAM2.0の発展形の構成要素である SAFe (Scaled Agile Framework)の概要を説明す

る。

1

内容

1. OSAM2.0を考えた動機 .................................................................................................. 2

2. 従来手法の問題点............................................................................................................ 3

2.1. 開発初期段階に業務やユーザーニーズに合う要件を確実に定義できるか否か ..... 4

2.2. 開発要件を精緻に文書化すべきか否か ................................................................... 5

3. スクラムとユーザーストーリー ...................................................................................... 7

4. スクラム+ユーザーストーリーで足りないもの.............................................................. 9

5. OSAM2.0の基本コンセプト ......................................................................................... 11

6. DtoD .............................................................................................................................. 13

6.1. DtoDとは .............................................................................................................. 13

6.2. DtoDの基本概念 ................................................................................................... 14

6.3. DtoDの事前ビューセッションの進め方 ............................................................... 15

6.4. DtoDの現在ビューセッション ............................................................................. 18

6.5. DtoDと OSAM2.0の課題の関係 .......................................................................... 19

7. 受け入れテスト駆動開発(A-TDD)とは ......................................................................... 20

7.1. A-TDDを支援するツール ..................................................................................... 22

7.2. A-TDDのコスト .................................................................................................... 23

7.3. Given-When-Then：テストケースの記述 ............................................................ 24

7.4. OSAM2.0における A-TDDの実行 ....................................................................... 26

7.5. A-TDDと OSAM2.0の課題の関係 ....................................................................... 27

8. OSAM 2.0 基本形での開発の流れ ............................................................................... 28

8.1. 開発構想等の策定 .................................................................................................. 28

8.2. 価値観点の識別 ...................................................................................................... 28

8.3. DtoDの事前ビューセッションの準備................................................................... 29

8.4. DtoDの事前ビューセッション ............................................................................. 29

8.5. DtoDの現在ビューセッションの実行................................................................... 30

9. SAFeとは ..................................................................................................................... 30

10. OSAM 2.0の発展形 .................................................................................................. 34

11. 最後に ........................................................................................................................ 35

謝辞 ....................................................................................................................................... 35

参考文献 ............................................................................................................................... 36

2

1. OSAM2.0を考えた動機

OGIS Scalable Agile Method (以降、OSAMと略す) 1.0 [1] は、ユーザー企業と SI企業

に分かれた日本産業構造においてアジャイル開発を適用する課題を考慮し、それらの課題

をスクラム1[2]、アジャイル UP、測定の組み合わせで克服できるのではないかという解決

策を提案した。

OSAM1.0は、フェーズと反復で構成されるハイブリッドアジャイルの 1種であり、アジ

ャイルUPの発展形であるDisciplined Agile Delivery (DAD)[3]と測定以外の部分は類似し

ている。OSAM1.0を提案してから、このフェーズと反復で構成される反復開発やアジャイ

ル開発は日本でも多くの開発プロジェクトで適用されてきた。また、ハイブリッドではな

い形でスクラムをチームレベルで適用する事例も増えてきた。

ハイブリッドアジャイルとそうではないアジャイル開発の大きな違いの 1 つは、要求を

予め確定し、文書化するか否かという点である。前者は、既存の開発とのギャップが少な

いために実践しやすいという長所があるが、逆に「要求の変化に対応しながら開発する」

というアジャイル開発のメリットを活かしにくいという短所がある。後者の方式には、「市

場への投入期間の短縮」や「開発途上で明確化するユーザーニーズへの対応」という点に

おいて前者の方式に対する優位性が期待できるが、同時に「要求に関する試行錯誤」や「要

求の変化に起因する品質の低下」という点での潜在的なリスクもある。

要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、「要求の変化

に対応しながら開発する」というアジャイル開発のメリットを活かすためには以下のよう

な課題がある。

イ) 軽量で開発依頼者にも定義しやすい形での要求表現

ロ) 軽量で定義しやすい要求表現に内在しうる矛盾、抜け、あいまいさ等の解決

ハ) 要求に基づいて実装された動くソフトウェアの受け入れ基準の設定

ニ) 反復毎に実行される受け入れの労力の削減

ここで、受け入れ基準は「要求の変化に対応しながら開発する」場合に反復毎の計画（あ

るいはスプリント計画）が達成されているかの客観的な判断基準になる。そのため、先の

課題の一覧に加えている。

これらの中で、イ）についてはユーザーストーリーという要求表現が解決策として一般

的に用いられている2。残るロ)～二)の課題に対する解決策を提示することが、OSAM2.0策

定の最大の動機である。また、OSAM1.0を提案した時点で明示的に記さなかった課題とし

て以下のようなものがあった。

1 スクラムについては後の方で簡単に説明している 2 ユーザーストーリーについては後の方で簡単に説明している

3

ホ) 自己管理や自己組織化というチームの連携を活かしたスケールアップ3

これは、スクラムを実践する際の基本となる自己管理や自己組織化というチームの連携を

活かした形のスケールアップということである。

OSAM1.0の提案以降にこれらの課題の解決策を求めた結果、スクラムに以下のようなフ

レークワークや手法を組み合わせることが解決策になり得ることが分かった。

DtoD (Discover to Deliver) [4]：ロ）とハ）に対する解決策

受け入れ駆動開発（A-TDD）：ハ）と二）に対する解決策

SAFe (Scaled Agile Framework)[5]：ホ）に対する解決策

これら 3点とスクラムの組み合わせで構成される手法を OSAM2.0と呼ぶ。なお、OSAM2.0

において、スクラム、DtoD、A-TDDの 3点で構成されるものを OSAM2.0基本形と呼び、

この基本形に SAFeを加えたものを OSAM2.0発展形と呼ぶ。

本文書では、OSAM2.0が DtoD、A-TDD及び SAFeを組み合わせることでなぜ解決策に

なり得るのかを説明することを目指す。

2. 従来手法の問題点

以降では、業務システムを中心に従来手法の問題点を説明する。

従来手法の大きな問題点は、「業務に本当に役立つシステムや、新たなユーザーを獲得でき

るほど魅力的なプロダクトをタイムリーに開発できない」ということである。この結果が、

ビジネス機会を逸したり、他社との差別化ができず、価格競争に巻き込まれるなどのビジ

ネス上の優位性に大きく影響する。

従来手法の大きな問題点として先に挙げたことは、以下の 2点の問題に分解できる。

ニーズとのミスマッチ

開発初期に確定した要件定義どおりに開発したシステムが必ずしも業務やユーザ

ーのニーズにマッチしていない

開発期間が長い

要件定義も開発も時間がかかる

ここで要件定義する内容と言っているものには、以下の 2つが含まれる。

3 ここでのスケールアップは、チームのメンバー数を増やすことではなく、7±2名のチー

ムを複数編成することによるものを意味している。スケールアウトと呼んだ方が正確かも

しれない。

4

業務要件：システムで支援する業務内容（業務ルールや法規制を含む）

システム要件：業務要件を満足することを支援するシステムの仕様

これらの両方に登場する要件定義に注目すると、これらの問題は従来手法の要件定義に

対する以下の考え方4に根ざしていることが分かる。

開発初期段階に開発要件を確定すべきである

開発要件は精緻に文書化すべきである

これらの考え方の妥当性について、以下の 2つの観点で考えてみる。

A) 開発初期段階に業務やユーザーニーズに合う要件を確実に定義できるか

B) 開発要件は精緻に文書化すべきである

まず、A)については「確実に定義できる」ものと、「確実には定義できない（困難）」もの

があるだろう。B)の「文書化」は A）として「確実に定義できる」ことを前提にしている

と思われるが、B)のメリットとデメリットについては後で議論する。

2.1. 開発初期段階に業務やユーザーニーズに合う要件を確実に定義できるか否か

業務やユーザーニーズに合う要件を「確実に定義できる」例としては、経理データの仕

分けや合算など演算結果にビジネス価値が確実にあったり、経費精算などの定型業務でシ

ステム化することで業務が省力化できるようなものが考えられる。これらのシステムを「要

件を最初に確定できるシステム」と呼ぶ。

その一方で、業務やユーザーニーズに合う要件を「確実には定義できない」ものとして

は以下のようなものが考えられる。

新たな業務

他に類を見ないような新たな製品やサービス

つまり、IT を活用して新たな価値を創出する業務、製品、サービスを作る場合である。

例えば、営業支援システムや EC(BtoC)サイトであり、IoTであり、ネット系の保険販売で

あり、モバイルデバイスによる業務の革新であり、ビッグデータやデータ分析などである。

4 これらの考え方は、開発作業を分業したり、開発委託時の契約を定めるために有効だと従

来考えられてきた。しかし、後述するような「要件を最初に書く出来ないシステムやサー

ビス」の開発を他社に先駆けて行うことが必要になった場合には、分業できることや契約

がむしろ阻害要因と位置付られ、それらを止める方向に進む可能性がある。

5

これらは人間とシステムとの相互作用を中心としたシステムであり、このようなシステ

ムにはもたらす価値を開発前に予測することは困難なものも多い。それは、そのようなシ

ステムが想定している業務自身やユーザーの行動、さらにはシステムによる業務上の成果

拡大に仮説が含まれるからである。

例えば営業支援システムを例に考えると、たいていの場合現状の営業活動上の課題とそ

れに対して考え得る解決策をまず考えるだろう。この解決策には、おそらくなんらかの業

務の変更とそれに対応するシステムの変更が必要になるだろう。でも、この業務の変更や

システムの変更の効果はあくまで仮説であり、それらを変えてどの程度の効果が見込まれ

るかを予測することは困難である。

このような予測の困難さは、「既存の業務の延長ではない、新たな業務（複数の業務の

構造の大きな見直しによるものを含む）を、それを支援するシステムとともに実行したこ

と（裏付けとなるデータ）がない」ことに起因する。このようなシステム、サービス、製

品を「要件を最初に確定できないシステム」と呼ぶ。

「要件を最初に確定できないシステム」の対象となる業務がビジネス競争の核心に関わ

るものであればあるほど、その有効性を開発に先だって確認できるほどの時間的な猶予が

無いだろう。

このような状況に対応するためには、「実証主義的にシステムを作る」という方針が有効

である。つまり、システムのすべてを一気に作るのではなく、効果を確認できる単位で開

発し、得られたシステムを稼働させたり、ユーザーに評価してもらうことで効果の確認を

行うということである。つまり、システムのリリースを単位にして PDCA (Plan Do Check

Act) を回すのである。

後述するアジャイル開発でもっとも普及しているフレームワークであるスクラムでは、2

週間程度のスプリントという単位で動くソフトウェアを作成し、各スプリントの最後でデ

モを行うことで開発依頼者に作成したソフトウェアが意図通りであるかを確認する形で開

発を進める。さらに、複数回のスプリントを経てリリースが作成され、ある程度の業務を

システムで実行できるようになる。

アジャイル開発の利点の１つは、これら複数回のスプリントやリリースで PDCAを回し、

開発しているシステムが業務に役立つかを確認し、仮説が間違っていた場合には開発を中

断したり、軌道修正できる点にある。

2.2. 開発要件を精緻に文書化すべきか否か

先に述べたように「文書化」というのは、「業務に役立つ要件を確実に定義できる」こ

とが大きな前提になると思われるが、それでも開発依頼者から開発チームに自らの要望を

伝える何らかの手段が必要になる。

ここで要件定義と言っているものには、以下の 2つが含まれる。

6

業務要件：システムで支援する業務内容（業務ルールや法規制を含む）

システム要件：業務要件を満足することを支援するシステムの仕様

これら 2 つのなかで、文書量が多いのはシステム要件の方であり、システム要件を主に文

書化することの長所と短所を考えてみる。

まず、システム要件を文書化することの長所としては以下のようなことが考えられる。

品質の向上

仕様書をレビューすることで、仕様の間の不整合や仕様の抜けに気づけたり、開

発依頼者が自分の要望を満足するものであるどうかを確認できる

業務を「理解している」人の限定が可能

開発メンバーが業務を理解しなくても開発ができる

開発範囲の明確化

開発を委託している場合には、システムの詳細な仕様を規定することに、範囲の

漸次的な増加を防ぐという開発者側のメリットだけではなく、納品されるシステ

ムの機能を契約で規定するという発注者側のメリットもある

その一方で、システム要件を文書化することの短所としては以下のようなことが考えられ

る。

時間がかかる

文書化するための時間や作成された文書を確認（レビュー）するための時間がか

かる

記述が難しい

開発依頼者にとって、業務上のニーズを説明できたとしても、その業務を支援す

るシステムの仕様を記述することはハードルが高い

結局、開発依頼者が述べた抽象度が高い要望を開発者側が仕様書という文書で具体化し、

開発依頼者に確認してもらうというサイクルの効率が悪いのである。開発の出発点として

「開発依頼者が自分自身の言葉で述べた要望」は尊重すべきであるが、その要望に対応す

るソリューションの確認というステップをもっと効率化する必要がある。

アジャイル開発では、「変化にすばやく対応するために変更コストを増大させるようなド

キュメントをあまり作成しない」というのが基本的な方針となる。「精緻な文書」を作ると

いうのはその方針に反するが、「精緻な文書」のメリットを残しつつ、デメリットを減らす

ような方策をアジャイル開発においても考えていくことには価値がある。

7

3. スクラムとユーザーストーリー

2001年にアジャイル開発宣言が起草されて以来 14年が経過し、欧米ではアジャイル開

発が当たり前になりつつある。そのようなアジャイル開発の普及に大きく貢献したのが「ア

ジャイル開発のミニマムセット」と呼ばれる「スクラム」[1]というコンパクトなアジャイ

ル開発フレームワークである。「スクラム」は、単純化すると以下の 4つの特徴を持つ。

ビジネス条件,要求

プロダクトバックログ

スプリント計画ミーティング

標準規約

ガイドライン

スプリントバックログ

デイリースクラム

スプリント

実行可能なプロダクトのインクリメント

プロダクトオーナー

スプリント目標の設定：スクラムチーム+スクラムマスター, プロダクトオーナー, 管理者, ユーザスプリントバックログの設定：スクラムチーム+スクラムマスター

図 1 スクラムの開発の流れ

① スプリントという一定の期間毎に動くソフトウェアを作る

② 要求はプロダクトバックログという優先順位付けされた一覧表に保管される

③ 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チ

ームがスプリント内で開発できる目標を設定する

④ スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価

はプロダクトオーナーという役割の人が行う

①のように一定期間毎に動くソフトウェアを作ることをここでは時間枠（タイムボックス）

納品と呼ぶ。

スクラムは、優先順位付けされたバックログ項目の優先順位順に動くソフトウェアを作

り、作成されたソフトウェアを評価する形で開発を進めることに可能にした。その結果、

開発依頼者や市場のニーズに即したソフトウェア（プロダクト）をすばやく開発すること

を可能にした。この利点がスクラムの普及の大きな原動力となった。

その一方で、スクラムはコンパクトなアジャイル開発フレームワークとして誕生したた

8

めに以下のようなことの具体的な実行方法が当初規定されていなかった。

1. プロダクトバックログ項目の表現形式

2. プロダクトバックログ項目の定義プロセス

図 2 ユーザーストーリー（ユーザーの声形式）

これらについては、スクラムが発展する過程で、XP(eXtreme Programming)[6]というア

ジャイル手法の考え方を取り入れて 1 として図 2 に示すようなユーザーの声形式の「ユー

ザーストーリー」を用い、2として Ron Jefferiesの 3C（カード、会話、確認）の 3段階で

ユーザーストーリーを発展させる方法が提案された。

カード：１枚の情報カードにユーザーストーリーを書き記す

会話：カードは、ユーザーストーリーの詳細をさらに会話する約束を表す

確認：カードに記されたユーザーストーリーが完了したかどうかの判断のための受け

入れ基準を設定する

さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリ

リースや要求種別を軸に並べて各リリースの内容を考えることが提案された。これらの方

法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現した

り、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすること

が可能になった。

ただ、これらはユーザーストーリーの表現形式やそれを検討する過程を 3 段階で発展さ

せ、さらに計画と結びつけた方がよいということについて優れたアドバイスではあるもの

の、ユーザーストーリーをどのように考案するのかという具体的な方法を示すものではな

い。また、具体的な方法が示されてもその方法によりプロダクトオーナーが単独でユーザ

9

ーストーリーの考案や優先順位付けを実際に行えるのかという問題もある。

また、ユーザーストーリーはソフトウェアの機能的な要求しか表現しておらず、データ

や品質特性、環境などプロダクト開発に関係するニーズをより多面的に理解し、表現し、

開発内容を検討し、合意を形成することには力不足である。言いかえれば、従来開発の分

析に相当する作業が入りこむ余地があまりないのである。確かに従来開発の分析作業はあ

る程度の専門性が求められ、時間もかかるし、文章を中心とした成果物を作るという点で

もアジャイル開発とは相いれないものと思われるかもしれない。しかし、業務システムの

ように多数の利害関係者が関与するプロダクトに対するニーズをより多面的に理解し、表

現し、開発内容を検討し、合意を形成することが求められる場合も多い。

前節まで読まれた方は、本節で「要求」という言葉が登場したことに戸惑われたかもし

れない。本文書では、「要求」をシステム/プロダクトが満足すべきことを仕様書よりも抽象

度の高い形で表現するものという意味で用いる。また、そのような要求を満足しているか

どうかの判断は開発されたシステム/プロダクトの受け入れテストに基づいて行われると考

える。

4. スクラム+ユーザーストーリーで足りないもの

前節で説明したスクラムとユーザーストーリーとの組み合わせで規定されていないこ

とは以下のとおりである。

A) プロダクトバックログの項目をどのように定義するか

B) プロダクトバックログに対応して作成されたものをどのように受け入れるか

A)は、「OSAM2.0 を考えた動機」の節で課題に挙げた「イ）軽量で開発依頼者にも定義し

やすい形でどのように要求を表現するか」と「ロ) 軽量で定義しやすい要求表現に内在しう

る矛盾、抜け、あいまいさ等をどのようにすばやく解決するか」に対応する。B)の受け入

れ方法には、「ハ) 要求に基づいて実装された動くソフトウェアの受け入れ基準の設定」と、

「ニ) 反復毎に実行される受け入れの労力の削減」という課題が含まれる。

さらに、スクラムを実践する上で以下のような点が課題になることも多いだろう。

C) プロダクトオーナーの役割が重すぎる

また、「従来手法の問題点」の「開発要件を精緻に文書化すべきか否か」の節で挙げた以

下のような課題もある。

D) 仕様が暗黙知化し、開発者の理解の違いで仕様の不整合や仕様の抜けが発生するのを

如何に防ぐか

10

E) プロダクトの最低限の品質をどう確保するか

E)を考える上で、一般的に以下の 2種類の要求を出発点とする。

業務要求：ビジネスルール等の業務を行う上で本来的に満たすべきこと

システム要求：画面レイアウト等の業務要求に対応するプロダクトが満たすべきこと

システム要求は、さらに以下のように分類できる。

機能要求

非機能要求

さらに、要求が満足されているかどうかの確認作業はこれらの要求種別に対応して以下

のように述べられる。

業務要求 → 妥当性確認

システム要求 → 検証

本文書では、妥当性確認を行うためのテストを「受け入れテスト」と呼ぶ。

また、検証を実行するためのテストは要求の種類やシステムの構造に基づいて複数存在

する。

機能要求 → 機能テスト等

非機能要求 → 性能テスト等

品質を確保するためにまず大事なのは、以下の点である。

開発したシステムやプロダクトが業務要求やシステム要求を満足しているかを確かめ

るテストを考える

言い換えれば、ユーザーストーリーのような要求から如何にしてテストを考えるかという

ことがまず大きな課題になる。

次に、アジャイル開発の場合に機能の開発が終わってから、システム/プロダクトのリリ

ースを迅速に行うためには以下のような原則を守ることが大事である。

スプリント（反復）毎に開発したものの品質を確保する

11

これを実行するためには、アジャイル開発で発生する開発途上のスコープ変動やすでに開

発した部分に対する要求変化に対応するための以下の点が課題になる。

① スコープの変動に合わせてテストを開発する必要がある

② デグレードを早期に発見し、修正する必要がある

また、①に付随して「OSAM2.0を考えた動機」の節で課題に挙げた「ニ) 反復毎に実行

される受け入れの労力の削減」する必要が生じる。

最後に、開発を委託する側の立場の人の関心事として、さらに以下のようなことも気に

なるだろう。

プロダクトのドキュメントをどうするか

リリースの見通しをどのように検討すべきか

リリースというのは重要なマイルストーンであるが、リリースの内容をユーザーストーリ

ーのような形式で表現した場合にそこに内在するシステム要求の複雑さや難易度を想像し

て見積もりを行うのは難しい。

その一方で、アジャイル開発においてリリース毎に提供する価値をある程度計画し、そ

の計画を達成することが最低限の規範となる。つまりリリースで計画した機能を「概ね」

提供するということが最低限守るべきことになり、そのリリースでどれくらいの価値を提

供できたのかということが問われる。

最後に、観点がまったく変わるがプロジェクトの規模の拡大に対する対応についても考

える必要がある。スクラムが想定しているのは前述した 7±2名のメンバーから成るチーム

であり、スクラムの開発の進め方を活かした形でより多くのメンバーが必要な開発をどう

進めるかという点も解決しなければならない。これが「OSAM2.0を考えた動機」の節で上

げた「ホ) 自己管理や自己組織化というチームの連携を活かしたスケールアップ」である。

5. OSAM2.0の基本コンセプト

「OSAM2.0を考えた動機」の節での説明とも重複するが、OSAM2.0の基本コンセプト

は前節で述べた課題を以下の 2つの方法で解決するというものである。

① スクラム+ユーザーストーリーを DtoD+A-TDDで補う

② SAFeにより①を複数チームの体制で実践したり、企業や事業部の戦略と連携すること

を可能にする

12

①を OSAM2.0の基本形と呼び、②を OSAM2.0の発展形と呼ぶ。

以下が OSAM2.0の基本形における開発の進め方を図示したものである。

前節で挙げた課題をそれらの解決策としての DtoD、A-TDD、SAFeの対応関係を表にま

とめると以下のようになる。なお、SAFe については「複数チームが構成される開発体制」

を前提とした解決策になる点に注意して頂きたい。

課題 DtoD A-TDD SAFe

A)プロダクトバックログの項目をどのよ

うに定義するか

○

B) プロダクトバックログに対応して作成

されたものをどのように受け入れるか

○（入力） ○

C) 仕様が暗黙知化し、開発者の理解の違

いで仕様の不整合や仕様の抜けが発生す

るのを如何に防ぐか

○

D) リリースの見通しに関してどのように

検討すべきか

○ ○

E) プロダクトのドキュメントをどうする

か

○（入力） ○

F) プロダクトの最低限の品質をどう確保 ○ ○ ○

OSAM2.0の基本形

13

するか

G) プロダクトオーナーの役割が重すぎる ○ ○

この表で「入力」とは、課題を解決するための「入力」になり得ることを意味する。

以降、DtoD、A-TDD、SAFeの概要を説明し、それらが課題の解決にどのように役立つ

かを説明する。

6. DtoD

6.1. DtoDとは

「Discover to Deliver (DtoD)」[4]は、ファシリテーション[7]と要求/分析[8]の分野で長

年に渡り活躍してきた米国 EBG Consulting 社のエレン・ゴッテスディーナーさんとメア

リー・ゴーマンさんが考案したフレームワークであり、従来開発の要求定義や分析作業を

以下のように変えてアジャイル開発とうまく組み合わせられるものに発展させるものであ

る。

A) ワークショップの活用

専門家単独で行うのではなく、顧客、業務、技術という異なる視点の人々が参加するワ

ークショップを開催して、迅速にニーズをより多面的に理解し、表現し、開発内容を検

討し、合意を形成する。

B) 多様なモデルの活用

ワークショップで、ニーズや開発内容を軽量でとっつきやすい様々なモデル（短文記述

や図等）により多面的に表現し、理解する。これらは、「プロダクトの 7側面」という形

でまとめられる。

C) ビジネス分析者の役割の変更

ビジネス分析者がワークショップのファシリテーターやモデラーの役割を担うことで、

プロダクトオーナーの役割を分担する。

ここでプロダクトと言っているのは、開発の結果として作成されるものであり、一般消費

者が使うソフトウェアやハードウェア製品やクラウドサービスだけではなく、業務システ

ムのように特定の企業の業務を支援するシステムも含む。

DtoDでは、要求定義、分析、計画策定を行うワークショップを計画/分析セッションと呼

ぶ。DtoDの計画/分析セッションは、複数のリリース（全体ビュー）、次のリリース（事前

ビュー）、次の反復（現在ビュー）という 3つの計画策定期間に対して開催する。

また、先の説明ではスクラムを補うものとして DtoDを説明してきたが、DtoDはこれら

の計画/分析セッションの開催のタイミングを調整することで、カンバン（フロー納品）や

従来開発（従来納品）の中でも活用することができる。

14

以降の節では、DtoDの主要概念を説明し、さらに例とともに事前ビューの計画/分析セッ

ションの進め方の概要を説明する。

6.2. DtoDの基本概念

DtoDとは、プロダクトを構成し得るオプションを考え、それらのオプションの中で優先

度の高いものの組み合わせでストーリーを作るためのフレームワークである。このプロダ

クトを構成し得るオプションをプロダクトオプションと呼ぶ。

DtoDでは、特定の計画範囲を設定し、以下の 3種類の参加者が参加してプロダクトオプ

ションやソリューション5の候補を検討する。

顧客パートナー：システムやプロダクトの利用者を代弁する人

業務パートナー：業務的な観点でシステムやプロダクトのニーズを考える人

技術パートナー：開発や運用の観点でプロダクトの実現性や品質を考える人

これらの 3 種類の参加者をプロダクトパートナーと呼び、プロダクトオプションやソリュ

ーションの候補を検討する打ち合わせをセッションと呼ぶ。DtoDではスクラムのプロダク

トオーナーを「プロダクト擁護者」と呼ぶが、「プロダクト擁護者」は業務パートナーに分

類される。また、顧客の代表者が顧客パートナーになり、アーキテクト、ビジネス分析者、

開発メンバーが技術パートナーになる。

また、DtoDでは以下の 3つの計画範囲でセッションを開催する。

全体ビュー：複数のリリースを通じてどのようなソリューションを提供するか

事前ビュー：次のリリースでどのようなシステムやプロダクトを提供するか

現在ビュー：次の反復でどのようなシステムやプロダクトを提供するか

ここで、全体ビューではソリューションの候補を検討し、リリース毎にどんなソリューシ

ョンを提供するかという現時点での見通しをロードマップにまとめる。それに対して、事

前ビューや現在ビューでは後述する以下の７つの側面により、より詳細なレベルのプロダ

クトオプションを検討する。

ユーザー：プロダクトの利用者や利用者の役割を表現する

インターフェイス：プロダクトとユーザー、他システムとの相互作用を表現する

5 ソリューションとは、各リリースで提供されるプロダクトの機能を大きな観点で分類した

ものであり、プロダクトオプションよりも大きな粒度のものである。ロードマップのよう

に、複数のリリースにおいてプロダクトが提供する機能を示す時にソリューションを用い

る。

15

アクション：プロダクトが提供する機能を表現する

データ：プロダクトが対象とするドメイン（業務）やデータと、それらのデータ間の

関係を表現する

制御：プロダクトが機能する際に守るべき業務ルールや法規制を表現する

環境：プロダクトが利用される環境や開発される環境を表現する

品質特性：プロダクトが達成すべき利用上あるいは開発上の品質を表現する

事前ビューや現在ビューのセッションでは、７つの側面に識別された優先度の高いプロダ

クトオプションを組み合わせることで優先度の高いストーリー6とストーリーの妥当性確認

をするための成果物が得られる。

6.3. DtoDの事前ビューセッションの進め方

以降、事前ビューセッションの進め方を中心に説明し、その後で現在ビューの違いを説

明する。

事前ビューのセッションでは、これらの側面の検討の順番を決めて、各側面に対してプ

ロダクトオプションを識別する。その際に、事前ビューのプロダクトオプションは以下の

表で示されるようなモデル等の形で表現される。

6 DtoDでは、「ユーザーストーリー」のことを「ストーリー」と呼んでいる。

16

なお、品質特性側面のオプションでは性能や可用性などの非機能要求が識別され、それら

がシステムテストで行う性能テスト等の情報源となる。

各側面を検討する際には、識別されたプロダクトオプションを以下のオプションボード

と呼ばれるボードの対応する区画に貼り付ける。

事前ビューや現在ビューのセッションは以下の 3ステップで進める。

プロダクトの側面 オプションの識別方法 オプションの表現方

法（一部）

ユーザー側面 どんなユーザーロールを対象にすべ

きか

ユーザーロールマッ

プ

インターフェイス側

面

どんなユーザー、デバイスと他シス

テムと連携をするか

コンテキスト図

アクション側面

どんな業務上のきっかけに対してプ

ロダクトはどのようなことを行わけ

ればならないか

イベントと応答

データ側面

問題領域を構成する概念やエンティ

ティーとしてどのようなものが存在

し、それらの間にどのような関係が

あるか

概念モデル、論理デー

タモデル

制御側面 アクションが実行される際にどのよ

うな業務ルールが施行されるか

決定表、決定木

環境側面

プロダクトがどのような開発環境で

開発され、どのような運用環境で用

いられるか

環境オプションの記

述表

品質特性 プロダクトが利用上、開発上でどの

ような品質を達成すべきか

プランゲージ

Copyright © 2015 EBG Consulting All rights reserved.

17

調査する：ある側面のプロダクトオプションを思いつくがままに書き出す

確認する：「調査する」で識別されたプロダクトオプションをシステムやプロダクトが

提供する価値という観点で優先度の高いものに絞り込む

評価する：全側面の検討が終わった段階で、得られたストーリーの妥当性を確認する

つまり、各側面で「調査する」でオプションをどんどん書き出し、それを「確認する」で

絞り込み、すべての側面の検討が終わった段階で得られたプロダクトオプションの組み合

わせからストーリーを作成する。次に、そのストーリーの妥当性確認を行う。その際に、

事前ビューと現在ビューでは、ストーリーの粒度が異なるので異なる種類の妥当性確認を

行う。

事前ビュー：粒度の大きなストーリーに対して、そのストーリーが価値をもたらすか

どうかをそのストーリーの具体的な利用シーンをシナリオとして記述して確認する

現在ビュー：粒度の小さなストーリーに対して、そのストーリーの受け入れを行うた

めのシナリオやデータ例を書いて妥当性を確認する

これらの妥当性確認は、プロダクトの開発に先立って粒度の大きなストーリーが業務ニー

ズを満たすどうかや、粒度の小さなストーリーが実行される際に満たすべき業務ルールや

法規制などを満しているかを明らかにするために行う。

事前ビューでは、妥当性が確認された各ストーリーと非機能要求を考慮して T シャツサ

イズ（S、M、L）などの規模の概算見積もりを行い、リリースまでの（T シャツサイズベ

ースの）ベロシティーとの対比でリリース目標（計画）を策定する。

18

6.4. DtoDの現在ビューセッション

現在ビューでは、事前ビューよりもより詳細にオプションを表現する方法が用いられるも

のの基本的には事前ビューと同じようにプロダクトの７側面を「調査する」と「評価する」

の 2 ステップで順番に検討する。全側面の検討が終わったら、得られた粒度の小さいスト

ーリーに対するシナリオやデータ例を記述して「確認する」を実行する。

現在ビューで得られたシナリオやデータ例に基づいて「前提-場合-結果(GWT)」が定義さ

れ、それらを利用して自動または手動でスプリント（反復）単位の受け入れテストが実行

される。これらのより詳しい説明は、後の「受け入れテスト駆動開発とは」の節で説明す

る。

DtoD事前ビューセッション

DtoD全体ビューセッション

ビジョン

プロダクトパートナー

オプションボード

粒度の大きなストーリー

リリース計画

非機能要求（プランゲージ）

ロードマップ

全体ビューと事前ビューセッションの入出力

19

6.5. DtoDと OSAM2.0の課題の関係

前節で説明したOSAM2.0の課題がDtoDによりどのように解決されるかをまとめたもの

が次の表である。

粒度の大きなストーリー

DtoD現在ビューセッション

プロダクトパートナー

オプションボード

粒度の小さなストーリー

シナリオ

データ例

前提-場合-結果（GWT)

分析者

オプションボード

現在ビューの入力と出力

20

7. 受け入れテスト駆動開発(A-TDD)とは

従来の開発では、開発に関わる人々はそれぞれ異なるスキルを駆使し、分断されたフェ

ーズで、分業的に作業を行う。このような開発スタイルでは、関係者間の情報伝達、ドキ

課題 DtoDによる解決

A)プロダクトバックログの項目を

どのように定義するか

事前ビューと現在ビューのセッションを通

じて定義する

B) プロダクトバックログに対応

して作成されたものをどのように

受け入れるか

現在ビューの結果として得られるストーリ

ーに対するシナリオ、データ例、GWTを用

いて受け入れる

C) 仕様が暗黙知化し、開発者の理

解の違いで仕様の不整合や仕様の

抜けが発生するのを如何に防ぐか

事前ビューと現在ビューのセッションにお

いて７側面でプロダクトオプションを検討

することで仕様の不整合や仕様の抜けが発

生するのを防ぐ

D) リリースの見通しに関してど

のように検討すべきか

事前ビューのセッションの結果として、リリ

ース計画が得られる

E) プロダクトのドキュメントを

どうするか

現在ビューの結果として得られるストーリ

ーに対するシナリオ、データ例、GWTが最

低限のドキュメントになる。さらにドキュメ

ントが必要であれば、事前ビューと現在ビュ

ーのセッションで書きだしたプロダクトオ

プションに基づいてドキュメントを作成で

きる。

F) プロダクトの最低限の品質を

どう確保するか

前述したストーリーに対する受け入れテス

トと、品質特性側面から得られた非機能要求

に基づいたシステムテストで品質を確保す

る。但し、単体テストやシステムの詳細な機

能のテストは開発チームが実施することが

前提となる。

G) プロダクトオーナーの役割が

重すぎる

分析者がプロダクトオプションを識別した

り、シナリオ、データ例、GWTで受け入れ

テストを定義することでプロダクトオーナ

ーの負荷を軽減する。

21

ュメントによる作業の引き継ぎなどで情報の損失や、互いのフィードバックの遅延といっ

た問題が発生しやすい。

受け入れテスト駆動開発(A-TDD)は、以下の図 3で示すように、受け入れ側と開発側は共同で、

全員が読める言語で受け入れテストを先に書き、その実行を自動化するアプローチである。これに

より、作成した受け入れテストケースは業務の合理性、技術の実現可能性及び例外条件や境界値

など、より全面的に理解され、検討されたため、価値のある品質の良い製品を開発できる。

A-TDD と類似のアプローチとして、振る舞い駆動開発（BDD：Behavior-Driven Development） 、

実例仕様（SBE：Specification by Example）、アジャイル受け入れテスト（Agile Acceptance Testing）、

ストーリーテスト（Story Testing）等があるが、本章の説明では以下表 1で示すように、「受け入れ側

と開発側が共同で、あらかじめ受け入れテストを書き、その一部の実行を自動化する」ことを受け入

れテスト駆動開発（A-TDD）として定義する。

上記の定義から、A-TDD を実施することによって、以下のメリットが享受できる。

図 3 A-TDDのイメージ図

表 1 A-TDDの定義

定義 目的 手段

受け入れ側（顧客）、開発側（分析者、開

発者、テスト担当者）が 共同で、

開発内容に関する共通認識

を持つ

役割間の協力 （顧

客、業務、技術）

受け入れテストを 先に書き、 要求をテストケースとして、

文書化し、維持する

Given-When-Then

(Gherkin 言語)

一部の実行を自動化する 回帰テストによる継続な検証

を可能とする

自 動 化 ツ ー ル

（Cucumber）

22

受け入れテストを開発の早い時点から書くことで、受け入れ側と開発側の理解の違いが早期

に発見できる。

受け入れテストを全員が読める言語で記述することで、要求の可読性が向上でき、要求の曖

昧さを排除される。

受け入れテストを開発の早い段階から実行することで、受け入れテストは「実行可能な仕様」7[9]として作成され、保守していくため、ドキュメントの整合性問題が回避される。

すなわち、A-TDDの導入によって適切な製品が開発される確率を高めていくのである。

7.1. A-TDDを支援するツール

1996年にA-TDDはXPのプラクティス「自動化されたテスト」で紹介されたが、普及し始めたのは

2002 年の Ward Cunningham によるサポートツール Fit の公開からである。A-TDD は「自動化」を

強いてないが、開発者はシステムから迅速なフィードバックが得られ、回帰テストも実施しやすくな

るため、受け入れテストの自動化をサポートするツールが重要な役割を果たす。

2006 年以降、A-TDD をより実施しやすくするため、さまざまなサポートツールが登場した。大ま

かに以下のように分類できる。

テーブル形式で要求を表現する： Fit/FitNesse、Robot Frameworkなど

「Given – When - Then」形式で要求を表現する：easyb、JBehave、GSpec、Instinct、JDave、

beanSpec、tumbler-glass、JRuby+Rspec、Groovy+Spock、Cucumber+Java、Systir、specs2、

scalacheck、ScalaMockなど

GUI経由のテスト形式：Selenium、Web2Test、StoryTestIQなど

上記のツールに対し、調査と評価を行う、「OSAM2.0」では、以下表 2 で示す導入の容易さと実用

性から、A-TDDのサポートツールとして Cucumberの利用を推奨している。

7 原語は、”Executable specification”。書籍では、”Executable specification”を機能の階層

で構造化し、生きた文書化 (”Living documentation”)を行うことが推奨されている。

表 2 サポートツールの評価項目

評価項目

導入の容易さ ドキュメント管理の容易さ

環境構築の容易さ

受け入れでの利用の容易さ

受け入れテストの記述のやすさ

自動化コード作成の容易さ

受け入れテストの読みやすさ

受け入れテスト実行の容易さと結果の見やすさ

23

図 4 は Cucumber を利用する場合、A-TDD 実施するための各ファイルと実装する必要なクラスの

構成を示す。

① Excelテンプレートを利用し、受け入れテストを自然言語近く自動化できるGherkin形式（7.3を

参照）で記述する。

② Excel のマクロを利用し、上記の Gherkin 形式で作成した受け入れテストを実行するための

「.feature」ファイルを生成する。

③ Cucumber で受け入れテストを実行するための「Runner」とテストコードを記述するための「Step

Definition」のひな型（.java）を生成する。（7.4を参照）

④ 「Step Definition」を生成後に、各クラスに対象システムとの接続部分を追加する。

⑤ JUnitやMavenを利用し、「Runner」が「 .feature」ファイルを参照しつつ、「 Step Definition」を

順番に実行し、対象システムの検証を行う。

7.2. A-TDDのコスト

A-TDD の導入は、以下のコストが伴うことを念頭にしなければならない。これらのコストは開発コ

ストの 8%～45%に達する。

学習コスト

受け入れテスト作成のコスト

図 4 Cucumber利用時のファイル／クラス構成

24

自動化のコスト

受け入れテストの保守コスト

上記のコストを低減し、かつ適用効果を高くするためには、まず、A-TDD の導入によって解決した

い課題の分析を行い、それから、A-TDD の実施対象を選定し、サポートツールの選択や受け入れ

テスト自動化の範囲を検討する必要がある。

「OSAM2.0」では、A-TDD を導入する場合、以下 2つの指針を提供する。

1） A-TDDの実施対象は重要なビジネスロジックにフォーカスする。

Cucumber は柔軟なツールで、GUI 経由のサポートツール、例えば Selenium と組み合わせて

受け入れテストの自動化を実施できる。GUI 経由の受け入れテストは、実際のユーザー操作

に近い状態でテストできるというメリットがあるが、受け入れテスト自動化を検討する際に、以下

の理由でできるだけ GUIのテストとビジネスロジックのテストを分離することが望ましい。

① GUIが頻繁に変わる

② 受け入れテストを自動化する時、セットアップや結果へのアクセス処理が複雑になる

すなわち、受け入れテストの作成コストと保守のコストがともに高くなる結果になり得る。

図 5 は Mike Cohnのテスト自動化のピラミッドを示す。同様に、GUI経由のテストを少量にす

ることを推奨している。

2） 自動化の対象は、まず重要な業務フローに着眼する。

受け入れテストの自動化はコストがかかるため、自動化対象のコスト対効果を事前に検証すべ

きである。コスト対効果が十分でない部分には手動テストの併用を考える。当社の検証では、

重要な業務フロー（ユーザーが一連の操作を通じて業務目的を達成するための流れ）にフォ

ーカスし、受け入れテストを作成し、自動化を行う場合、増加した工数は開発工数の 8%に収め

ることができた。

7.3. Given-When-Then：テストケースの記述

A-TDD は受け入れ側と開発側のコラボレーションによって初めて成り立つため、実施可能な第

一条件は受け入れテストを「自然言語」で記述できることである。また、上記 7.1 で述べたツールに

図 5 Mike Cohnのテスト自動化ピラミッド

25

よって作成した受け入れテストを自動化するため、一定の形式を定めなければならない。受け入れ

側と開発側が自然言語で読め、かつ自動化できるという両方の条件を満たすため、

「Given-When-Then」（GWT、前提-場合-結果）は受け入れテストを記述する形式の一種として登

場した。この形式は「Gherkin」言語と呼ばれ、受け入れテストを自然言語近い形式で以下表 3 の 3

部分で記述できる。

DtoDでは、プロダクトオプションを調査し、確認するためにGWTを用いる。作成した受け入れテ

ストは計画ビューによって、具体化の程度が異なる。現在ビューでは、最も正確かつ具体的でテス

ト可能な受け入れテストが作成可能である。図 6 は、DtoD で用いられるユーザーストーリーの確認

表 3 Gherkin言語の予約語

予約語 意味 例

Given テストの事前条件をこの部分で記述する ○○な状態/状況で

When 具体的な操作を記述する ××をしたら

Then 期待する結果を記述する △△が起きる/結果になる

図 6 DtoDが推奨する受け入れテストの記述テンプレート

（EBG Consultingによる提供）

26

時に関連の受け入れテストを記述するためのテンプレートである。このような記述テンプレートを利

用し、受け入れ側と開発側がビジネスドメインの言語でコミュニケーションできるし、開発の目標を

確認できる。また、開発ドキュメント、特にビジネスルールの順守に関するドキュメントとして利用で

きる。

受け入れテストから迅速なフィードバックが求められているかどうかは、作成した受け入れテスト

から自動化対象を選定する場合の考慮ポイントである。Cucumber で受け入れテストの自動化を行

う場合、受け入れテストを GWT形式に準拠する Gherkin 言語で記述し、拡張子「.feature」のファイ

ルとして保存する。一般的に「.feature」ファイルでは受け入れテストを、フィーチャー (とストーリー)、

シナリオ及びステップ（Given、When、Then）の 3 階層で記述する。以下の図 7 では、DtoD が推

奨するテンプレートで作成した内容を「.feature」ファイルに取り入れる方法を示す。

一般的に、DtoD の事前ビューでは、フィーチャー（ユーザーストーリー）とシナリオを識別する。

現在ビューでは、各ステップと関連のデータ例を追加していく。

7.4. OSAM2.0における A-TDDの実行

以下、A-TDDのサポートツール Cucumberを利用し、A-TDDの実施例を示す。

1. 「.feature」ファイルの作成

① フィーチャーの作成

図 7 DtoDのテンプレートから「.feature」ファイルを作成する例

27

ビジネス目標を達成するために、受け入れ側と開発側は知識と経験を共有しながら、

自然言語を用いて受け入れテスト対象を定義する。「OSAM2.0」では、重要な業務フロ

ーやビジネスルールを検証するために作成する。

② シナリオの作成

自然言語で、ユーザーがシステムをどのように利用するかを記述する。

③ ステップの作成（Given-When-Then）

自然言語の曖昧さを排除するため、作成したシナリオに対し実例（データなど）を用い

て、説明する。また、自動化のために、洗練化を行う。

2. 自動化コードの作成

Cucumberで Runnerクラスと Step Definitionクラスの雛形をそれぞれ生成し、実行するため

のクラスと個々のステップに紐付けるテストコードを実装する。

3. Maven、Ant、JUnit、Jenkinsなどを利用し、実行する

フィーチャー、シナリオ及びステップは GWT で作成されるため、開発側（開発者、要求分析者、

テスター）及び受け入れ側にいるユーザーのいずれが記述してもよい。自動化コードについて、

開発側は Cucumber で生成した自動化のための雛形を利用し、作成していく。受け入れテストの

実行は受け入れ側と開発側が協力しながら行う。

7.5. A-TDDと OSAM2.0の課題の関係

「OSAM2.0」の課題が A-TDDによりどのように解決されるかをまとめたものが次の表で

ある。

課題 A-TDD

A)プロダクトバックログの項目をどのよ

うに定義するか

B) プロダクトバックログに対応して作

成されたものをどのように受け入れる

か

対応の受け入れテストを受け入れ側と開発側が共同で

作成し、それを用いて、開発されたものの受け入れを行

う。また、受け入れテストを自動化することで、繰り返しの

実行が可能になる。

C) 仕様が暗黙知化し、開発者の理

解の違いで仕様の不整合や仕様の

抜けが発生するのを如何に防ぐか

受け入れテストを先に書くことによって、受け入れ側と開

発側の理解の違いが早期に発見できる。また、要求の

実例化により可読性が向上でき、要求の曖昧さを排除さ

れる。

D) リリースの見通しに関してどのよう

に検討すべきか

E) プロダクトのドキュメントをどうする 受け入れテストは「実行可能な仕様」として作成され、保

28

か 守していくため、ドキュメントの整合性問題が回避され

る。

F) プロダクトの最低限の品質をどう確

保するか

顧客、開発者協同で受け入れテストを完成させるため、

要求の確実性が向上する。また、重要なビジネスフロー

やビジネスルールに対し、自動化された受け入れテスト

があり、テスト実行のオーバヘッドが低減されるので、品

質確保できる。

G) プロダクトオーナーの役割が重す

ぎる

8. OSAM 2.0 基本形での開発の流れ

この節では、前節までの DtoDと A-TDD の説明及び以下の図に基づいて OSAM 2.0 基

本形での開発の流れを説明する。

時間

事前ビューDtoD

A-TDD

スクラム

テストバックログ

現在ビュー

受け入れテスト

開発と実行

動くソフトウェア

バックログ

現在ビュー

受け入れテスト

開発と実行

動くソフトウェア

バックログ

現在ビュー

受け入れテスト

開発と実行

動くソフトウェア

業務要求の理解とDtoD準備

⋯

⋯

⋯

OSAM 2.0の基本形

8.1. 開発構想等の策定

まず、開発対象となるプロダクトの競合製品や既存システムに対する優位性をビジョン

[5]、エラー! 参照元が見つかりません。としてまとめるとともに、そのビジョンにより達

成しようとするビジネス目的やビジネス目標[4]を定める。

8.2. 価値観点の識別

このステップから DtoDに入る。まず、DtoDの推進者であるプロダクト擁護者（業務パ

29

ートナー）がユーザーの代表者やその代弁者（顧客パートナー）や、アーキテクト（技術

パートナー）を集めて、3 種類のプロダクトパートナーの観点でビジョン、ビジネス目的、

ビジネス目標を達成するためにプロダクトが提供すべき価値を挙げる。これにより得られ

た価値を価値観点と呼ぶ。

価値観点は、プロダクトが 3 種類のプロダクトパートナーにもたらす価値を定性的に表

現したものである。価値観点は、プロダクトにオプションを入れる際の優先順位付けを判

断する土台となる。価値観点の具体例は、[4]、[10]に記載されているので御参照下さい。

8.3. DtoDの事前ビューセッションの準備

DtoDの事前ビューセッションは、スクラムの「リリース計画」に対応する。事前ビュー

セッションでは、プロダクトパートナーを集めて 6.3節で説明したように以下の作業を行い

ます。

プロダクトの 7側面に渡り優先度の高いオプションを調査し、確認する。

得られた優先度の高いプロダクトオプションを組み合わせることで、粒度の大きなス

トーリーを作成する。

これら粒度の大きなストーリーに対するシナリオを書き、ストーリーが価値観点や業

務要求を満足するかを確認する。

ストーリーが価値観点や業務要求を満足することが確認できたら、それらのストーリ

ーの開発労力を見積もる

事前ビューセッションの準備では、本番の事前ビューを効率的に実行するために、準備

に参加可能なプロダクトパートナーを集めてこれらの 4つの作業を実行する。

8.4. DtoDの事前ビューセッション

事前ビューセッションでは、リリース内容の判断に関与すべきプロダクトパートナーの

参加の下に、前述した「DtoDの事前ビューセッションの準備」で得られた結果を使いなが

ら「DtoDの事前ビューセッションの準備」で行った 4つの作業を実行する。これらの 4つ

の作業を繰り返すことで、比較的短時間のセッションでプロダクトオプションの抜けや優

先度の設定に間違いがないかを確認するとともに、プロダクトオプションやストーリーの

優先度を確定させる。

さらに、結果として得られた優先度の高いストーリーに対して、次回のリリースで提供

できそうな範囲を確認する。この次回のリリースで提供できそう範囲のストーリーが次回

のリリース目標になる。

30

8.5. DtoDの現在ビューセッションの実行

DtoDの事前ビューセッションは、スクラムの「バックログの手入れ」に対応する。現在

ビューセッションでは、開発チームを含むプロダクトパートナーを集めて事前ビューで行

った以下の作業をより詳細なレベルで実行する。

① プロダクトの 7側面に渡り優先度の高いオプションを調査し、確認する。

② 得られた優先度の高いプロダクトオプションを組み合わせることで、粒度の小さなス

トーリーを作成する。

③ これら粒度の小さなストーリーに対するシナリオを書き、ストーリーが業務要求を満

足するかを確認する。

④ ストーリーが業務要求を満足することが確認できたら、それらのストーリーの開発労

力を見積もる

これらの作業の結果として、得られた粒度の小さなストーリーがプロダクトバックログの

項目になる。③のシナリオを書く作業は、現在ビューの時間的な制約ではごく限られた範

囲に留まる。この作業は、現在ビューセッションの終了後も以下のような形で継続する。

⑤ 粒度の小さなストーリーに対するシナリオをさらに拡充するとともに、それらに対す

るデータ例を考える

⑥ シナリオとデータ例に基づいて、受け入れ基準を策定する

⑤で得られたシナリオとデータ例は GWTを作成するための入力になるので、それらを入力

として 7.4節に記述した「OSAM2.0における A-TDDの実行」を実行する。

9. SAFeとは

SAFe (Scaled Agile Framework) は、企業や事業部の戦略に沿い、企業や事業部が一丸

となって強力なプロダクト、サービス、システムを企画し、開発する姿を描いたフレーム

ワークである。SAFeの考案者は、ソフトウェア要求の権威であり、かつ自身がいくつも企

業を起業し成功を収めている Dean Leffingwell 氏である。SAFe は、アジャイル、リーン

思考、プロダクト開発フロー、要求プラクティスを融合して Leffingwell氏が考案し、John

Deer社（農機具製造業）、BMC Software社（ソフトウェア製品ベンダー）、Discount Tire

社（小売業）、TradeStation社（金融サービス業）などの様々な分野の大規模開発に適用し

た経験を経て体系化したものである。SAFeは Leffingwell 氏の著書である「アジャイルソ

フトウェア要求」[5]という書籍で最初に世に出たが、表 4に示されるような改訂も経なが

ら現在も発展し続けている。

31

こ れ ら の 改 訂 を 取 り 入 れ て 発 展 し た 最 新 の SAFe の 説 明 は

www.scaledagileframework.com という web サイト（日本語訳は SAFe 日本語サイト[11]

で提供）から一般向けに提供されている。

SAFeでは、経営レベルで意思決定した戦略を複数のアジャイルチームからなるプログラ

ムが競争力のあるプロダクトに具体化するという事業部や企業の姿を提示する。そのため

に、SAFeは、意思決定及び実行のための 3階層と、カンバンや複数のバックログ（待ち行

列）による企画審査及び開発の連携を基本的な骨格としている。これらは、プロダクト開

発フローのテーマである分散された制御や待ち行列に基づいている。

SAFeの最大の特徴は、意思決定及び実行の階層として以下の 3つのレベルを設定したと

ころにある。

表 4 SAFeのこれまでの発展

リリー

ス年

SAFeの

バージョン 説明

2012年 1.0 書籍“Agile Software Requirements”でSAFeの全体像と全

体像を構成する要素が解説された

2013年 2.0 ポートフォリオレベル：価値のストリームを導入するとと

もに、アジャイルリリース列車(ART)の自立性を高めた

2014年 3.0

ポートフォリオレベル：投資テーマが戦略テーマに変わる

とともに、複数のアジャイルリリース列車による開発が描

かれる

プログラムレベル：潜在的に出荷可能なインクリメント

(PSI)等の用語が変更された

32

ポートフォリオレベル：プロダクト等の企画を評価、審査する

プログラムレベル：複数チームが連携してプロダクトのリリースを開発する

チームレベル：1つのチームがプロダクトの自チーム担当部分を開発する

ここで、「プログラム」とは複数チームで構成される大規模な開発体制のことを意味する。

SAFeのプログラムレベルでは、5-10チーム程度（開発者数が 50-100名程度）の規模を想

定している。

これらの 3つのレベルを図示したものが図 8であり、これを SAFeの全体像(big picture)

と呼ぶ。これらの 3つのレベルの概要については、[12]に記述されているのでそちらの御参

照をお願いする。

これらのレベルを通じて、SAFeが実現しようとしているのが以下の 4つの価値である。

図 8 SAFeの全体像

出典：www.scaledagileframework.comに掲載されていた図を

Leffingwell LLC.の許可の下で翻訳

33

ベクトル合わせ：3つのレベルのメンバーが戦略的な目標を共有し、その方向に向かっ

て力を合わせる

コード品質：技術プラクティスを実践することで大規模で品質のよいプロダクトを実

現する

プログラムの実行：開発メンバーの自律性に基づく自己組織化や自己管理、及び反復

のサイクルを自然な形でプログラムレベルにスケールアップすることで、大規模プロ

ジェクトを確約に基づきスケジュール通りに実行する

透明性：3つのレベルのメンバーが包み隠さず現状を共有することで、より良い連携を

もたらす信頼関係を醸成する

SAFe のもう 1 つの特徴は、以下のようなカンバンや複数のバックログを介して経営陣、

プログラム、チームが目標を共有し、連携することを提案している点にある。

ポートフォリオカンバンシステム：プロダクト等の企画を評価、審査するためのカン

バンシステム

ポートフォリオバックログ：承認済みのプロダクト等の企画を保持するバックログ

プログラムバックログ：1つのプログラムで共有する要求のバックログ

チームバックログ：１つのチームで共有する要求のバックログ

これらのカンバンやバックログには、プロダクトの企画や要求を表す以下のような項目

が入る。

エピック：プロダクトやシステムに対するニーズとそれを解決するソリューション

フィーチャー：エピックから導き出した最上位の要求

ユーザーストーリー：フィーチャーを実現するために必要なチームレベルの要求

ここで注意して頂きたいのが、「要求」という言葉の意味である。アジャイル開発では、「要

求」は開発依頼者が開発して「欲しい」と考えている機能等を表現するのにすぎず、開発

されることが約束されたものではないということである。

エピックは 1-2ページ程度の分量で、1つのフィーチャーやユーザーストーリーは索引カ

ード１枚に記述できるようなものであり、従来の要求成果物よりも軽量なものになってい

る。また、エピックには以下の 2種類のものがある。

ビジネスエピック：ユーザーに直接的に価値を提供するプロダクト、システム、サー

ビス

34

アーキテクチャーエピック：ユーザーに直接的には価値を提供しないプロジェクト横

断的な共通アーキテクチャーやインフラ、UXガイドライン

これらの要求がカンバンやバックログを介して 3 つの意思決定及び実行のレベルを流れ

ることで、SAFeでは戦略的な意思決定がチームレベルで開発される詳細な機能に具体化さ

れるのである。

10. OSAM 2.0の発展形

SAFeのチームレベルは一部拡張されたところがあるものの基本的にはスクラムとXPの

プラクティスを組み合わせたものである。また、SAFeのプログラムレベルは複数チームを

連携させるために以下のような仕組みを取り入れている。

アジャイルリリース列車

複数のチームが共通の開始、終了日に基づく 2 週間のサイクルで開発を進めて、

8-12週毎に評価可能なシステム（プログラムインクリメント）を提供する

リリース計画策定

各プログラムインクリメント(PI)サイクルの開始前に、プログラムにおいて優先度

の高いフィーチャーをチームに仮割り当てをして、それらのフィーチャーの PIで

の実現性を全チームのメンバーで検討するリリース計画策定打ち合わせを実施す

る

検査と適応ワークショップ

8-12 週で作成した評価可能なシステム（プログラムインクリメント）をデモし、

計画の達成度を評価するとともに、プログラムレベルでの改善を考えるためのワ

ークショップを開催する

これらを支援する役割として、SAFeではプログラムレベルでのプロダクトオーナーに相当

するプロダクト管理者という役割やプログラムレベルでのスクラムマスターに相当するリ

リース列車エンジニアという役割を設けている。

以下のように SAFe のプログラムレベルのイベントや役割は、スクラムを比較的自然に

スケールさせたものになっている。

イベント：リリース計画策定、検査と適応ワークショップはスクラムにおけるスプリ

ント計画、スプリントレビュー、振り返りを拡張したもの

役割：アジャイルリリース列車、プロダクト管理者、リリース列車エンジニアはスク

ラムの開発チーム、プロダクトオーナー、スクラムマスターを拡張したもの

35

このように SAFe のプログラムレベルは、スクラムを比較的自然にスケールさせたイベン

トや役割で構成されており、チームレベルでのスクラムの良さである自律性や自己管理を

活かす形で開発をスケールアップしている。

OSAM2.0発展形では、SAFeのチームレベルやプログラムレベルでのイベント、役割、

プラクティス等を取り入れることで複数のチームによる開発を実現する。

11. 最後に

本文書では、要求に関する試行錯誤を可能な限り減らしつつ、高い品質を確保しながら、

「要求の変化に対応しながら開発する」というアジャイル開発のメリットを活かすために

以下のフレームワークや手法でスクラムを補うことが有効なことを説明した。

A) DtoD (Discover to Deliver)

B) 受け入れ駆動開発（A-TDD）

さらにこれらをスクラムと組み合わせた開発の進め方を OSAM 2.0 基本形という形で提示

した。

また、自己管理や自己組織化というスクラムのチームの連携を活かしたスケールアップ

を実現する手段として以下のフレームワークが有効なことを説明した。

C) SAFe (Scaled Agile Framework)

また、これにより OSAM 2.0 基本形をスケールアップ可能にしたものとして OSAM2.0発

展形を提示した。

OSAM2.0を構成する A), C)についてさらに知りたい場合は、巻末の参考文献に書籍や解

説文書などを挙げているのでそちらを参照して頂くようにお願いします。さらに、スクラ

ム、A)～C)を習得したい方向けにはそれらのトレーニングの提供も行っておりますので、

それらの受講を御検討頂けたら幸いです。

謝辞

本文書は、2011 年から目指していた当社のアジャイル開発関係の技術開発成果の集大成

です。ここまでの道のりの歩み出しを促して下さった平山前社長、技術開発の取り組みを

辛抱強く見守って下さった山口部長と宗平前部長、アジャイルビジネス推進プロジェクト

の鈴木プロジェクトリーダー補佐と桝谷プロジェクトリーダー補佐、そして SAFe、DtoD

の書籍の翻訳を支援して下さったり、トレーニングを試行段階から受講して下さったアジ

ャイル開発センターの同僚の皆さんとそれ以外の同僚の皆さんにこの場を借りて感謝致し

ます。

36

参考文献

[1] 藤井 拓, オージス総研 アジャイル白書,

http://www.ogis-ri.co.jp/pickup/agile/docs/agile_wp_201305.pdf

[2] ケン・シュエイバー, マイク・ビードル, アジャイルソフトウェア開発スクラム, ピア

ソンエデュケーション, 2003

[3] Scott W. Ambler, Mark Lines, ディシプリンド・アジャイル・デリバリー エンター

プライズ・アジャイル実践ガイド, 翔泳社, 2013

[4] エレン・ゴッテスディーナー, メアリー・ゴーマン, 発見から納品へ: アジャイルなプ

ロダクトの計画策定と分析, BookWay, 2014

[5] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のための

リーンな要求プラクティス, 翔泳社, 2014

[6] ケント・ベック, XPエクストリーム・プログラミング入門―変化を受け入れる, ピアソ

ンエデュケーション, 2005

[7] エレン・ゴッテスディーナー, 要求開発ワークショップの進め方, 日経 BP, 2007

[8] エレン・ゴッテスディーナー, 実践ソフトウェア要求ハンドブック, 翔泳社, 2009

[9] Gojko Adzic, “Specification by example”, Manning, 2011

[10] 藤井 拓, DtoDに基づくアジャイル要求入門,

http://www.ogis-ri.co.jp/pickup/agile/docs/IntroARWithDtoD.pdf

[11] SAFe日本語サイト: http://www.scaledagileframework.com/jp/

[12] 藤井 拓, SAFe入門, http://www.ogis-ri.co.jp/pickup/agile/docs/safe_intro.pdf

アジャイル開発関連研修のご紹介

アジャイル開発

【東日本営業部】 〒108-0023 東京都港区港南2-15-1（品川インターシティA棟） TEL : 03-6712-1201 【中部日本営業部】 〒460-0003 愛知県名古屋市中区錦1-17-13（名興ビル） TEL : 052-209-9390 【西日本営業部】 〒560-0083 大阪府豊中市新千里西町1-2-1 TEL : 06-6871-8054 【OGグループ営業部】 〒555-0023 大阪府大阪市西区千代崎3-南2-37（ICCビル） TEL : 06-6584-4522

URL: http://www.ogis-ri.co.jp/ E-mail info@ogis-ri.co.jp

アジャイル開発研修のコースマップ

オージス総研はオブジェクト指向技術、そしてモデリングのリーディングカンパニーとしてこれまで培ってきた実績とノウハウを活かした各種の研修を開発し、世界に通用する技術の習得とキャリアアップを強力にサポートします。 このたび、アジャイル開発に取り組まれるお客様に向けて、関連する研修を取り揃えましたので、ご紹介いたします。

概論

実践

「体験！アジャイル超入門」（1日）

•講義形式に加えて、体を使った演習を通じてアジャイル開発の概要を体験します

•アジャイル開発において最も採用されているScrumの基礎知識を学習します

「Scrum入門」（1日）

•演習、及び、アジャイル開発の導入に関する事例紹介等を通じて、アジャイル開発手法の一つであるScrumを

使ったソフトウェア開発のプロジェクトの進め方を学習します

「アジャイル開発 総合演習」（3日）

• Scrumを採用した疑似開発プロジェクトを要求の抽出から実装まで実際に行い、アジャイル開発を実践します

基礎

オージス総研の研修サービスについて

オージス総研の研修サービスは１０年以上の実績に基づいて、「モデリングコース」，「IT基礎コース」，「共

通・業務基礎コース」の３コース、３０を超えるトレーニングメニューをご用意しています。詳細は以下オージスの研修・トレーニングページをご参照ください。 http://www.ogis-ri.co.jp/learning/c-00.html

アジャイル開発関連研修のご紹介 2 0 1 5 / 0 7月版

「SAFe（Scaled Agile Framework）リーダー研修」（2日）

•情報システム部門や製品開発部門の管理職、プロジェクト管理者を対象に、大規模アジャイル開発のために必要な基本知識を習得します

• リーン思考、アジャイル開発、プロダクト開発フローを理解し、組織内部にSAFeを推進できるリーダーを育成します

リーダー 育成

「アジャイル開発入門 技術編」（1日）

•実機演習を通じ、アジャイル開発プロジェクトを進める上で必要な技術プラクティスとして、テスト駆動開発と継続的インテグレーションを学習します

「Discover To Deliver に基づくアジャイル要求トレーニング」（2日）

• ビジネス分析や要求にかかわる方、アジャイル開発にかかわる方を対象に、Discover To

Deliver (DtoD)に基づき、納得感のある要求（ユーザーストーリー）を検討、合意する方法を学習します

•グループワークで、要求獲得セッションを一通り体験します

アジャイル開発関連研修のご紹介

アジャイル開発チーム チームを超えるアジャイル開発

分析 開発 テスト ビジネスアナリスト プロダクトオーナー

リーダーシップとガバナンス

経営

SAFeTM(Scaled Agile Framework)リーダー研修（2日）

アジャイル開発 総合演習 （3日、オンサイトの提供のみ）

Discover To DeliverTMに基づくアジャイル要求（2日）

Scrum入門（1日）

受け入れテスト駆動開発（1日）

アジャイル開発入門 技術編（1日）

体験！アジャイル超入門 （0.5日-1日） 概論

基礎

実践

リーダー 育成

アジャイル開発

アジャイル開発関連研修のご紹介 2 0 1 5 / 0 7月版

アジャイル開発研修のコースマップ

【東日本営業部】 〒108-0023 東京都港区港南2-15-1（品川インターシティA棟） TEL : 03-6712-1201 【中部日本営業部】 〒460-0003 愛知県名古屋市中区錦1-17-13（名興ビル） TEL : 052-209-9390 【西日本営業部】 〒560-0083 大阪府豊中市新千里西町1-2-1 TEL : 06-6871-8054 【OGグループ営業部】 〒555-0023 大阪府大阪市西区千代崎3-南2-37（ICCビル） TEL : 06-6584-4522

URL: http://www.ogis-ri.co.jp/ E-mail info@ogis-ri.co.jp

オージス総研の研修サービスについて

オージス総研の研修サービスは１０年以上の実績に基づいて、「モデリングコース」，「IT基礎コース」，「共

通・業務基礎コース」の３コース、３０を超えるトレーニングメニューをご用意しています。詳細は以下オージスの研修・トレーニングページをご参照ください。 http://www.ogis-ri.co.jp/learning/c-00.html

SAFeTM, Scaled Agile FrameworkTMは、Scaled Agile, Inc.の登録商標です。

Discover to DeliverTMは、EBG Consulting, Inc.の登録商標です。