Copyright 2015, OGIS-RI Co.,Ltd ·...

Copyright 2015, OGIS-RI Co.,Ltd

i

序文

2001 年にアジャイル開発の心得をまとめたアジャイル宣言が起草され、アジャイル開発

が一躍表舞台へと躍り出ました。それから 14年が経過し、欧米ではアジャイル開発はもは

や新し物好きの技術者集団が好む開発手法ではなく、一般的に使われる開発手法の主流に

なろうとしています。この一般化する流れの中で、アジャイル開発が適用するシステムは

大規模化したり、企業や事業部の標準的な開発手法としてアジャイル開発を採用する企業

が増えてきています。

しかし、翻って日本の現状を見ると「要求が変化したり、不確定であるという特殊な状

況に特化した小規模開発向けの手法」という印象がまだまだ多いというのが現実です。た

だ、日本でも e コマース、ゲーム開発、クラウドなどのソフトウェアの比重が高いビジネ

ス、プロダクト、サービス分野では「要求が変化したり、不確定である」状況は当たり前

になってきており、それが今後さらに様々な分野に広がっていくと期待できます。

本文書は、「変化したり、不確定な要求に対応して開発を行う」というアジャイル開発の

強みや特長を土台にして、企業全体の競争力を高めたり、大規模開発を行うためのフレー

ムワークである SAFe (Scaled Agile Framework )を紹介するものです。SAFeの大きな特

徴は、以下の 2点です。

思想的にはアジャイル開発、リーン思考、プロダクト開発フローに基づいている

3つのレベルからなる企業や事業部のプロダクト（システム）開発における取り組みの

全体像(Big Picture)を提供している

以降、煩雑なので「プロダクト（システム）」を「プロダクト」と呼びます。

リーン思考とは、「注文を受けてから納品するまでの間で発生する、価値の創造に結び付

かない時間を短縮する」ことを旨とする考え方でトヨタ生産方式（TPS）を起源とするもの

です。SAFeでは、プロダクト開発の一連の作業を「価値のストリーム」と捉え、これを継

続的に改善することがリーンでアジャイルな企業のゴールであり、管理者をこれらの改善

活動の推進役として位置づけています。

プロダクト開発フローは待ち行列理論と経済性を中心に、TPS やアジャイル開発の考え

方を統合し、プロダクト開発を成功させるための数多くの原則にまとめたものです。プロ

ダクト開発フローでは、8つのテーマを中心に原則が体系化されていますが、本書を通じて

これら 8つのテーマが SAFeを裏付ける大きな柱となっています。

次に SAFeの全体像を説明します。SAFeを構成する３つのレベルは、以下のようなもの

です。


ii

ポートフォリオレベル：経営陣の投資戦略と整合するように、プロダクトの企画を検

討するレベル

プログラムレベル：複数チームが連携してプロダクトを開発し、それに対するフィー

ドバックを得るレベル

チームレベル：自己組織化されたチームがスクラムのプロジェクト管理プラクティス

と XP (eXtreme Programming)の技術プラクティスを組み合わせて開発を行うレベル

ここで「プログラム」とは、複数のチームで構成されるような大規模プロジェクトを意味

します。

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

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

って力を合わせる

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

現する

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

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

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

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

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

3つのレベルでの取り組みにより、これらの 4つの価値をどのように実現すればよいかを

解説するという SAFe の中心的なテーマです。さらに、これらの取り組みをつなげる縦糸

がエピック、ビジョン、フィーチャー、ユーザーストーリーで構成される「アジャイルソ

フトウェア要求」です。ソフトウェア要求は、SAFeの考案者である Leffingwell 氏のもっ

とも得意とする専門分野であり、SAFeではアジャイルソフトウェア要求を生むためのプロ

セス、役割、モデリング手法、見積もり方法、さらには要求が実現されていることを開発

途上で早期に検証する受け入れテスト駆動開発という広範な話題がカバーされています。

本書は、SAFeの概要を説明することを目的とし、以下の 3章で構成されています。

第 1 章では、アジャイル開発手法の従来手法との違いや特徴を説明し、さらにアジャイ

ル開発手法の具体例としてスクラムというフレームワークを説明します。アジャイル手法

は、SAFeの源流の１つであり、スクラムは SAFeのチームレベルの大きな部分を占めてい

ます。最後に、スクラムと、スクラムの考案に大きな影響を与えたとされる野中先生等の

「知識創造企業」に記述されているプロダクト開発のプロセスを対比し、チームレベルを

超えたものの必要性を説明します。


iii

第 2章では、SAFeのアジャイル開発以外の源流である「リーン思考」と「プロダクト開

発フロー」の概要を説明します。リーン思考は、「より価値の高いプロダクトを、より速い

サイクルタイムで提供する」ことをゴールとして共有し、それを実現するために組織とし

て「人々への敬意」、「継続的な改善」、「上役のサポート」に注力するという考え方です。

また、「プロダクト開発フロー」は「より価値の高いプロダクトを、より速いサイクルタイ

ムで提供する」ことを実現するための原則を提供するものです。

第 3 章では、SAFe を構成する 3 つのレベルを各々に登場する要求プラクティスや役割、

開発の流れの概要とともに説明します。

SAFe の構成要素の説明や事例は www.scaledagileframework.com/jp というサイトでも

一般向けに提供されています。本書で紹介されている要求プラクティスや役割、開発の流

れのより詳しい説明を組織内で共有したり、SAFeに関する最新の情報を入手するためにこ

のサイトをご活用されることをお勧めします。

2015年 6月 4日

藤井拓


iv

目次

序文 .......................................................................................................................................... i

1. アジャイル開発が生まれた背景とその特徴 ................................................................... 1

1.1. アジャイル開発が生まれた背景 .............................................................................. 1

1.2. アジャイル宣言 ........................................................................................................ 3

1.3. アジャイル開発手法 ................................................................................................. 5

1.3.1. アジャイル開発手法の特徴 .............................................................................. 5

1.3.2. スクラム............................................................................................................ 6

1.4. チームを超えたものの必要性 ................................................................................ 10

2. アジャイル以外の SAFeの源流 ..................................................................................... 11

2.1. リーン思考 .............................................................................................................. 11

2.1.1. トヨタウェイ .................................................................................................. 13

2.1.2. 家の源流と中身 ............................................................................................... 14

2.2. プロダクト開発フロー ........................................................................................... 14

2.2.1. プロダクト開発フローの 8つのテーマ .......................................................... 15

2.2.2. 待ち行列理論 .................................................................................................. 17

2.2.3. 経済性 ............................................................................................................. 19

3. アジャイル開発を活用する企業や事業部像を提供する SAFe ..................................... 21

3.1. SAFeの特徴 .......................................................................................................... 21

3.2. SAFeの 3つのレベル ............................................................................................ 24

3.2.1. ポートフォリオレベルの概要 ......................................................................... 24

3.2.2. プログラムレベル ........................................................................................... 26

3.2.3. チームレベル .................................................................................................. 29

3.3. SAFeにおける管理者の役割 ................................................................................. 30

4. 結び ............................................................................................................................... 31

付録 ....................................................................................................................................... 33

参考文献 ............................................................................................................................... 34

1. アジャイル開発が生まれた背景とその特徴


1

1. アジャイル開発が生まれた背景とその特徴

アジャイル開発手法の従来手法との違いや特徴を説明し、さらにアジャイル開発手法の

具体例としてスクラムというフレームワークを説明します。アジャイル手法は、本書のテ

ーマである SAFe (Scaled Agile Framework)の源流の１つであり、スクラムは SAFeのチ

ームレベルの大きな部分を占めています。最後に、スクラムと、スクラムの考案に大きな

影響を与えたとされる野中先生等の「知識創造企業」に記述されているプロダクト開発の

プロセスを対比し、チームレベルを超えたものの必要性を説明します。

1.1. アジャイル開発が生まれた背景

ウォーターフォール型開発は、図 1 に示すように要求を開発初期段階に確定し、確定し

た要求に基づいて設計、実装、統合、テスティングを順次的に行う形の開発方法です。ウ

ォーターフォール型開発は、日本のソフトウェア開発プロジェクトの半分以上で採用され

ており、未だ大勢を占めています。

ウォーターフォール型開発には以下のような長所があります。

開発依頼者側の計画、契約の負荷（リスク）が小さい

開発初期段階に確定した要求に基づいて計画や契約を締結すれば、要求の実現の

責任を ITベンダーに転嫁できる

分業が可能

開発を複数フェーズに分けて、フェーズ間で文書による引き継ぎを行うことでフ

ェーズ毎に異なる開発者（役割）による分業が可能になる

要求

分析, 設計

コーディング

統合, テスト

図 1 ウォーターフォール型開発


2

この「分業が可能」という長所を利用して、日本ではソフトウェア開発において複数の階

層にも及ぶアウトソースという形態が一般化しました。また、フェーズ間での引き継ぎの

ために作成される文書をレビューすることで品質を管理するというアプローチも広まりま

した。

一方で、ウォーターフォール型開発の短所として以下のような点を挙げることができま

す。

要求確定後の仕様変更が困難

要求確定後に技術やビジネス状況の変化やビジネスニーズの理解が進んで要求を

変更したいと望んでも、対応は次バージョン以降になる

開発上の問題点が開発終盤に顕在化して遅れる

統合段階やテスト段階でアーキテクチャー上の問題やサブシステム間のインタフ

ェースの不整合などの問題が顕在化して納期が守れない

「要求確定後の仕様変更が困難」という点に付随する問題として、「文書で書き表した要求

では要求の有効性が判断できない」というものがあります。つまり、開発依頼者が明確に

要求を述べられる場合を除いては「要求」が ITベンダー主導で決められていき、その結果

として「本当のニーズとはかけ離れたソフトウェアが納品される」ような事態に陥る危険

性があります。つまり、ウォーターフォール型開発には「ビジネス価値が低いソフトウェ

アが開発されてしまう」というリスクがあります。また、「開発終盤に開発上の問題点が

顕在化して遅れる」ことで結果的には「納期が守られないことで、そのソフトウェアの運

用開始が遅れてビジネス上の損害が生じる」ような状況も現実には発生します。つまり、

実際には「計画や契約に伴うリスクが高い」こともありえるのです。

これらの長所と短所を考えると、開発依頼者にとってウォーターフォール型開発の長所

が発揮できるのは以下のような場合だと考えられます。

要求が開発初期に確定できる

アーキテクチャーやサブシステム間のインタフェースの不整合などのリスクが低い

欧米ではウォーターフォール型開発を適用するプロジェクト割合が半分以下に低下し、ア

ジャイル開発を適用する割合が増えているということも報告されています。欧米でウォー

ターフォール型開発が減少している原因として以下のようなものが考えられます。

ビジネスや技術の変化にすばやく対応するための開発が求められている

ユーザー企業がある程度開発要員を抱えている


3

Google社や SalesForce社のようにクラウドでビジネスを展開する企業も、Apple社のよう

にハードウェアデバイスやソフトウェアでビジネスを展開する企業も、Amazon社のよう

な販売でビジネスを展開する企業も競争に勝つために「ビジネスや技術の変化へのすばや

い対応」を重視しています。「ビジネスや技術の変化への対応」というのは以下のことを意

味します。

ビジネス形態（モデル）や市場の変化に対応する

新たな技術（IT機器）を組み込んだり、移行したりする必要がある

これらの「ビジネスや技術の変化」を事前に予測するのは不可能に近いと言えます。しか

しながら、変化に対応した製品やサービスを早く市場に投入しないと高い利益を得ること

ができません。このような状況に対応するためは、「ビジネスや技術の変化」に柔軟かつス

ピーディーに対応して開発することが求められます。その結果として、ウォーターフォー

ル型開発からアジャイル開発への移行が進んでいると考えられます。

また、同時に欧米では自社で開発要員を抱えている場合が多いために日本ほど「開発委

託側の計画や契約の負荷（リスク）」に対処する必要はありません。つまり、計画や契約と

いう敷居が低いこともウォーターフォール型開発からアジャイル開発への移行が欧米で進

んでいる理由になっていると考えられます。

1.2. アジャイル宣言

90 年代の終盤に、顧客と開発者との密な協力に基づいて、顧客に役立つソフトウェアを

すばやく開発する手法として XP (eXtreme Programming) [1]やスクラム[2]などの複数の

アジャイル開発手法が登場しました。これらのアジャイル開発手法の提案者達は 2001年に

集まり、アジャイル開発が共有する価値や原則をアジャイル宣言[3]という形でまとめまし

た。アジャイル宣言の価値は、以下の 4 つの項目で構成されます。

プロセスやツールよりも個人や相互作用

包括的なドキュメントよりも動くソフトウェア

契約上の駆け引きよりも顧客とのコラボレーション

計画を硬直的に守るよりも変化に対応する

これらの各行で下線を引いてある右側の部分を左側の部分より重視するということが価値

として宣言されたのです。また、アジャイル宣言には、さらに以下のような原則が付随し

ており、この宣言が推奨している開発の進め方をより具体的に説明しています。


4

1. ソフトウェアの早期、継続的な納品により、顧客の満足を達することが最優先である。

2. 開発の終盤であろうとも、要求内容の変更を歓迎する。アジャイルなプロセスは、顧

客の競争上の優位性のため、変化を制する

3. 数週間から数ヶ月間のサイクルで動作するソフトウェアを納品する。サイクルは短い

方が良い

4. ビジネス側の人間と開発者がプロジェクトを通じて日々協力をしなければならない

5. 志の高い開発者を中心にプロジェクトを編成する.必要な環境や支援を与え、任務をや

り遂げることを信じなさい

6. 開発チームの内外でもっとも効率的で効果的な情報伝達を行う手段は、顔をつき合わ

せて話し合うことである

7. 動作するソフトウェアが主たる進捗の確認手段である

8. アジャイルなソフトウェア開発は、持続的な開発を促す。開発資金の提供者、開発者、

ユーザは、必ず一定のペースを守れるべきである

9. 技術力と良い設計に絶えず気を配ることで、機敏さは向上する

10. 不必要なことを行わない技能である簡潔さは、本質的である

11. 自己組織化されたチームから最善のアーキテクチャー、要求、設計が生まれる

12. 定期的に、チームはもっと効果的になる道を考え、開発の進め方を調和させ、調整す

る

アジャイル宣言の原則の内容を大別すると、以下の 5 点にまとめることができます。

A. チームのあり方: 5, 6, 8, 11, 12

B. 個人の心構え: 9, 10

C. 動くソフトウェア: 1, 3, 7

D. 顧客とのコラボレーション: 4

E. 変化への対応: 2

A と B は、アジャイル開発の価値である"個人や相互作用"を個人に関する原則とチームに

関する原則に分解したものです。アジャイル宣言の 1、3、7 の原則は反復的な開発アプロ

ーチに関するものです。そのため、"動くソフトウェア"の価値と対応すると考え、C に分

類しました。さらに、D と E は顧客のニーズの変化に即応した開発を行うことであり、顧

客本位のソフトウェア開発を行うという方向性を示すものです。

これらの原則から、アジャイル開発にとって"顧客のニーズの変化に即応した開発"が大き

なテーマであり、A と B と C がその実現手段だといえます。すなわち、顧客のニーズの

変化に即応するためには、一定の作業内容や作業手順に従うだけでは不十分であり、機動

性に富んだチームと個人の自律性が必要になるということです。


5

1.3. アジャイル開発手法

1.3.1. アジャイル開発手法の特徴

前節で紹介したアジャイル宣言の原則に述べられているアジャイル開発の特徴を開発手

法という観点でまとめ直すと、以下の 4点になります。

A. 反復的な開発

B. 顧客との連携

C. チームワークの重視

D. 技術的な裏付け

A は、１週間から１ヶ月程度の一定の周期で動くソフトウェアを作るという形で開発を進

めるということです。この動くソフトウェアを作る１回の周期のことを「反復」と呼びま

す。A については、反復の期間が固定であることを強調する「タイムボックス」という言

葉で表現することもあります。

B は、顧客と連携して顧客のビジネスの成功につながるソフトウェアを作るということ

です。顧客がソフトウェアに求めることは、顧客を取り巻く状況の変化等により開発途上

で変化しえます。このような変化を反復単位で顧客からのフィードバックとして受け、計

画に取り込むことで、顧客のビジネスの成功につながるソフトウェアの開発を行うことが

できます。

C は、開発チームのメンバーの自律性や直接的なコミュニケーションを重視したチーム

の運営を行うということです。開発チームのメンバーの自律性という点では、従来のよう

な縦割りで計画や作業の割り当てを行い、メンバーが与えられた計画や割り当てを行うと

いうのではなく、開発チームのメンバー間の話し合いで計画や作業の割り当てを決めると

いうことです。このように自律性を尊重することで、開発メンバーのモチベーションが高

まり、より良い仕事のやり方を考える改善マインドが生まれます。

D は、要求の変化の結果としてソースコードの変更が発生するが、そのソースコードの

変更のコストをなるべく抑えるような技術的な工夫（プラクティス）を講ずるということ

です。アジャイル開発で広く使われている技術的なプラクティスとしては、以下のような

ものがあります。

テスト駆動開発（TDD: Test Driven Development）[4]

プログラムコードを書くときに、そのコードを検証するための単体テストコード

を先に書き、そのテストコードに合格するようにプログラムの本体コードを書く

（テストファースト）。作成された単体テストコードにより回帰テストが自動化さ

れるため、以降の開発でコードの変更や改良を安全かつ低コストで行う事ができ

る。


6

リファクタリング[5]

既に書いたプログラムコードの機能を保ったまま、プログラムコードの品質を高

めるための改良を行うこと。コードを改良することで、１カ所のコードの変更が

多くの箇所に波及しないようにする。

継続的なインテグレーション (CI: Continuous Integration)

各開発者が開発した本体コードとテストコードが蓄積された構成管理ツール内の

コードを自動的にビルドし、テストコードを自動実行し、それらの結果を開発メ

ンバーに通知するというもの。このような環境を構築することで、コード状態を

全員で共有し、不具合を起こすような変更を加えた場合に、それをすばやく検出

し、低いコストでコードを修正することができるようになる。

これらのプラクティスにより、加えたプログラムコードの変更による回帰エラーの発生を

すぐに検知したり、プログラムコードの変更が広範に波及しないようにプログラムコード

の品質を高めることが可能になります。このような回帰エラーの迅速な検出やプログラム

コードの品質向上によりソースコードの変更コストを削減することができ、アジャイル開

発に求められる変化への対応が実現できるのです。

技術的な裏付けは表から見えにくく、理解しにくいかもしれない特徴ですが、これを怠

ると開発が進むにつれて開発の生産性が低下したり、コードの保守性やその他の品質が低

下する危険性があります。

1.3.2. スクラム

1.3.2.1. スクラムの価値

スクラムは、Ken Schwaber と Jeff Sutherland、 Mike Beedle によって考案されたア

ジャイル開発手法です。スクラムという開発方法論の名称は, ラグビーのスクラムにちなん

で名づけられました。スクラムは、野中先生達が 80年代に日本の製造メーカーの新製品開

発において欧米のメーカーを凌駕した要因の研究をまとめた「知識創造企業」[6]などに触

発され、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出され

たものです。

スクラムは、他のアジャイル開発手法と同様に動くソフトウェアを順次作り、そのソフ

トウェアを発展させながら開発を進める反復的な開発アプローチに基づいています。アジ

ャイル開発手法は一般的に開発チームで共有すべき価値や作業の指針となる原則やプラク

ティスで開発の進め方を定めていますが、スクラムが定めている価値は以下の 5 点です。

確約 ( Commitment )

約束したことを確実に実現すること


7

専念（ Focus )

確約したことの実現に専念すること

隠さない ( Openness )

たとえ自分にとって不利なことでも包み隠さないこと

敬意 ( Respect )

自分と異なる人に敬意を払うこと

勇気 ( Courage )

確約し、隠さず、敬意を払うために勇気を持つこと

筆者は、スクラムを書籍で初めて学んだときにこれらの価値に共感したのですが、スク

ラムコミュニティーでは現在これらの価値が示されていないような気がします。その点が

個人的に残念です。

スクラムでは、このような価値以外にも開発の進め方や開発チームにおける役割につい

ても言及していますが、言及している範囲はプロジェクト管理作業に偏っています。スク

ラムは、プロジェクト管理的な作業に特化しているため、XPや統一プロセス(UP)など設計、

実装、テストの実践形態を規定している様々な反復的な開発手法と組み合わせやすい開発

手法です。

1.3.2.2. スクラムにおける開発の進め方

スクラムでは、 1 週間から 4 週間のサイクルで動くソフトウェアを作りながら開発を進

めます。図 2 は、スクラムによる開発の流れを示したものです。図中の用語の意味は、以

下のとおりです。

ビジネス条件,要求

プロダクトバックログ

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

標準規約

ガイドライン

スプリントバックログ

デイリースクラム

スプリント

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

プロダクトオーナー

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

図 2 スクラムにおける開発の流れ


8

プロダクトバックログ: 開発対象のソフトウェアに対する要求のバックログ

スプリント: 1週間から 4週間サイクルの反復

スプリント計画ミーティング: スプリントの開発目標 ( スプリント目標 ) とスプリン

トバックログを設定するミーティング

スプリントバックログ: スプリント目標の達成に必要なタスクのリスト

デイリースクラム: 日毎の進捗確認ミーティング

実行可能なプロダクトのインクリメント: スプリントの結果として作成される実行可

能なソフトウェア

図 2 に示されている標準、規約、ガイドラインは、開発組織において守ることが求められ

ている標準、規約、ガイドラインを意味します。

スクラムでは、開発は以下のようなステップで進行します。

1. ソフトウェアに要求される機能とその優先度をプロダクトバックログとして定める

2. プロダクトバックログからスプリントで実装するべき目標（スプリント目標）を選

択する

3. スプリント目標をより詳細なタスクに分解したスプリントバックログを作成し, タス

クの割り当てを行う

4. スプリントの間, 毎日決まった場所及び時間で開発メンバーが参加するデイリースク

ラムというミーティングを開催する

5. 1 回のスプリントが終了すると, スプリントレビューミーティングを開催し, 作成さ

れたソフトウェアを評価する

6. 開発メンバー全員で完了したスプリントに対する振り返りを行う

7. 次回のスプリントに備えてプロダクトバックログの内容と優先度の見直しを行う

図 2のスプリント計画ミーティングは、2、 3 の 2 ステップとして実行されます。

スクラムでは、一般の開発メンバーに加えて以下の 2 つの管理的な役割が定義されていま

す。

プロダクトオーナー: プロダクトバックログを定義し, 優先順位を決める人

スクラムマスター: プロジェクトが円滑に進むように支援する人

スクラムマスターは、通常のプロジェクト管理者のように開発者への作業の割り当て、

計画策定、進捗管理等を行うことではなく、スクラムに関する教育を行うとともに開発を

阻害する様々な障害を解決することを主任務とします。


9

スプリント計画ミーティングでは、スプリント目標とスプリントバックログが決められ

ます。スプリント目標は、プロダクトオーナーが中心になって顧客、管理職、開発チーム

との議論により決定されるスプリントの大雑把な目標です。例えば、スプリント目標は"

システムを構成する永続性や通信メカニズムを決定する"などと設定されます。スプリント

目標が設定された後、開発チームのメンバーが主体になってスプリント目標を達成するた

めに必要なタスクをリストアップしていきます。各タスクは、4-16 時間で完了できる粒度

で定義されます。さらに、抽出されたタスクから開発チームのメンバーが話し合いにより

スプリントで達成するタスクの割り当てを決めます。開発チームのこのようなタスクの定

義や割り当ては、顧客やプロダクトオーナーの介入なしに開発メンバーにより自律的に行

われます。

このような開発チームのメンバー間の自発的な議論を通じて、メンバー間の連携が自然

に形成されます。このチーム内の連携が自律的に形成される過程を Schwaber らは「自己

組織化による真のチーム形成」と呼んでいます。

デイリースクラムは、スプリントの期間中に毎日決まった場所及び時間に開催され、開

発チームのメンバー全員が参加するミーティングです。デイリースクラムでは、スクラム

マスターが開発チームの各メンバーに以下の 3 点を質問します。

前回のデイリースクラム以降の作業内容

次回のデイリースクラムまでの作業予定

作業を進める上での障害

デイリースクラムは、チーム内のコミュニケーションを促進するとともに、チームメンバ

ー全員がプロジェクトの現状についての認識を共有し、メンバーの連帯を深めるのに有効

です。また、スクラムマスターはデイリースクラムで報告された障害を解決することを支

援します。

スクラムの大事な点は、スプリントの期間中は開発チームに外乱を与えず、開発に専念

できるようにすることです。そのような外乱の発生を防ぐために、デイリースクラムには

開発メンバー以外の人々も参加できますが、意見や要望を述べたりすることは許されてい

ません。

以上説明したようにスクラムは「アジャイル開発のミニマムセット」と呼ばれるぐらい

シンプルなフレームワークになっており、それがゆえに手法としては全世界で最も普及し

たものになっています。但し、スクラムを実践すればそれで十分かというとそうではあり

ません。スクラムには、「技術的な裏付け（プラクティス）」が含まれないという点に注意

する必要があります。そのため、「スクラム」だけを単純に実践していると、開発が進むに

つれて開発の生産性が低下したり、コードの保守性やその他の品質が低下する危険性があ

ります。


10

1.4. チームを超えたものの必要性

スクラムに大きな影響を与えた野中先生等の「知識創造企業」[6]を読むと、そこで描か

れている 80年代の日本の企業の独創的な新製品開発の過程とスクラムとの間にはギャップ

があることに気づきます。「知識創造企業」に記されている新製品開発の過程は大雑把には

以下のようなものです。

A) 当初の製品企画案を策定する

B) 製品企画案の経営陣が承認する過程で、無謀とも思える課題設定をする(ハードルを上

げる）

C) プロジェクトリーダーが選ばれ、多才なメンバーを集め、製品コンセプトを具体化す

る

D) 直面する様々な課題を、プロジェクトリーダーの下で多彩なメンバーや外部の専門家

の連携で解決する

E) 得られた製品の設計を製造に移管する

また、このような製品開発が行われた時期は 70年代の高度経済成長の中で発展した日本の

製造メーカーが本格的な国際競争に突入した時期であり、企業の存亡がかかっているとい

う危機意識の下でこれらの製品開発に取り組んでいました。

著者の勝手な推測ですが、おそらく上記の C)、 D)あたりとソフトウェア開発の世界で既

に実践されていた反復開発とが結びついてスクラムが生まれたのではないかと想像するこ

とができます。スクラムはそれを 7±2名という規模の開発チームに焦点を絞ることでシン

プルなフレームワークになったのですが、それがゆえに知識創造企業の A)、 B)、E)のよう

なチームを超えたレベルの話が切り捨てられたのかもしれません。

また、80 年代と現代とを比べると「変化のスピードとグローバル化、さらにそれらに起

因する競争の激化」という点が大きく変化しています。これらの中で「変化のスピード」

という点では、「短期の反復で変化に対応する」というアジャイル開発（スクラム）の強み

が有効になったのではないかと考えられます。

それでも、知識創造企業に示された新製品開発の過程のようにチームを超えた様々な人

が関与することで規模が大きなものを含めてより強力なプロダクト、システム、サービス

が生まれる可能性があります。後述する SAFe (Scaled Agile Framework)は、このようなチ

ームを超えた組織の連携により、強力なプロダクト、システム、サービスを生む企業や事

業部像を提供するものと位置づけることができます。

2. アジャイル以外の SAFeの源流


11

2. アジャイル以外の SAFeの源流

SAFeの源流となるものとしては、第 1章で紹介したアジャイル開発やスクラムというも

のがまっさきに挙げられますが、それ以外に以下のようなものを挙げることができます。

リーン思考

プロダクト開発フロー[7]

要求プラクティス

これらの 3 点及び、これらを企業や事業部の単位でのプロダクト開発の流れを描いた全体

像が強力なプロダクト、システム、サービスを生む企業や事業部像の根幹を構成します。

これらの中でリーン思考とプロダクト開発フローの概要を本章で紹介し、次章では SAFe

を構成する 3つのレベルの説明の中で要求プラクティスの概要を説明します。

2.1. リーン思考

ソフトウェア開発でリーンと言えば「リーン開発」や「トヨタ生産方式(TPS)」が有名で

すが、SAFeにおけるリーン思考は図 3に示すような、強力なプロダクト、システム、サー

ビスを生み出す企業や事業部全体が共有する理念を意味します。この図に描かれた家を「リ

ーンソフトウェアの家」と呼びます。

目標：価値

第1の柱：人々への敬意

第２の柱：継続的な改善

土台：上役のサポート上役はリーン思考を適用し、教育する。この長期的な考えに基づいて決断する。

持続可能な最短のリードタイム。（人々と社会にとって）最高の品質と価値。ほとんどの顧客の喜び、最低のコスト、高いモラル、安全性

プロダクト開発フロー

1. 経済的な視点を取る2. 積極的に待ち行列を管理　　する3. バラツキを利用する4. バッチサイズを小さくする5. WIPの制約を適用する6. フローを制御する　　：リズムと同期7. 素早いフィードバックを適　　用する8. 制御を分散する

図 3リーンソフトウェアの家


12

なお、「アジャイルソフトウェア要求」[8]ではこの家を「リーンソフトウェアの殿堂」と

訳したのですが、書籍の刊行後にその訳語が不適切であることに気づきました。「アジャイ

ルソフトウェア要求」の読者の方にはこの場を借りてお詫び致します。

「リーンソフトウェアの家」は、強力なプロダクト、システム、サービスを生み出す企業

や事業部全体を表します。そして、家の骨格となる屋根、柱、土台がリーン思考であり、

その家の中身がプロダクト、システム、サービスなどの価値を生み出す活動のための原則

を表します。これら屋根（目標）、柱、土台、中身が意味するものは以下のとおりです。

目標：価値

持続可能な最短のリードタイム。（人々と社会にとって）最高の品質と価値。

ほとんどの顧客の喜び、最低のコスト、高いモラル、安全性

第 1 の柱：人々の敬意

第 2 の柱：継続的な改善

家の中身：プロダクト開発フロー

土台：上役のサポート

上役はリーン思考を適用し、教育する。この長期的な考えに基づいて決断する

目標は、TPSの考案者である大野耐一氏が述べた「顧客からの注文を受けてから、納品し、

代金を頂くまでのサイクルタイムを減らす」ということと、さらに「顧客に価値を提供す

ることを目指す」ということです。土台は、この目標を達成するために、チームのみなら

ず企業や事業部全体で連携し、リーダー（上役）はリーン思考を推進し、継続的な改善を

指導する役割を担うということを意味しています。第 1 の柱と第 2 の柱の意味は次の「ト

ヨタウェイ」の節で説明します。

この家は、リーンに結果を生む企業や事業部であるために、企業や事業部が全体として

共有する目標とその高いレベルの実現手段を図示したものなのです。このように図示する

ことで、プロダクトの開発だけに留まらず、業務分野や職階層を横断して目標と実現手段

を共有することができます。

リーンは、元々トヨタ自動車さんがはるかに大きな規模で大量生産（マスプロダクショ

ン）を行っていた欧米の自動車メーカーに対抗するために生みだしてきたものです。書籍[9]

では、このような厳しい競争において生き残り、成長してきたトヨタ自動車さんの強み

（DNA)としてトヨタウェイと TPSの 2つを挙げています。「リーンソフトウェアの家」の

骨格はこのトヨタウェイの部分に対応するものと考えられます。次節では、「リーンソフト

ウェアの家」の骨格の意味をもう少し具体化するためにトヨタウェイについて少し説明し

ます。


13

2.1.1. トヨタウェイ

トヨタウェイを説明する書籍[9]では、トヨタ自動車さんのアプローチは図 4に示される

ような 4つの Pで構成されると説明されています。また、それら 4つの Pをより具体化し

たものとしてトヨタウェイの 14の原則が示されています。これら 4つの Pのうち、「プロ

セス」の部分が TPSに対応します。残りの 3つの Pが「リーンソフトウェアの家」の第 1

の柱、第 2 の柱、土台に対応します。 TPS については御存じの方も多いでしょうし、「リ

ーンソフトウェアの家」の構成要素ではありませんので本文書では説明を省略します。

以下、「プロセス」以外の 4 つの P をそ

れに付随する原則とともに紹介します。

長期的思考 (Philosophy)

原則 1 短期的な財務目標を犠牲

にしてでも長期的な考えで経営

判断する

正しいプロセスが正しい結果を生む

(Process)

書籍[9]では原則 2-8 が示されて

いますが本記事では省略します

人とパートナー企業を育成して会社

の価値を高める (People and

Partners)

原則 9 仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する

原則 10 会社の考えに従う卓越した人とチームを育成する

原則 11 パートナーや部品メーカーの社外ネットワークを尊重し、改善するのを

助ける

継続して根本問題に取り組んで組織的学習を行う (Problem Solving)

原則 12 現地現物を徹底的に理解するように自分の目で確かめる（現地現物）

原則 13 意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十

分検討するが、実行はすばやく行う（根回し）

原則 14 執拗な反省と絶え間のない改善により学習する組織になる

これらの 7つの原則が、「リーンソフトウェアの家」の骨格の意味を理解するためには少し

継続的改善と学習(Problem Solving)

尊重、チャレンジ、チーム育成(People and Partners)

ムダ取り(Process)

長期的思考(Philosophy)

現地現物

尊重

とチームワーク

カイゼン

挑戦

図 4 4つの P


14

参考になるのではないかと考えられます。「アジャイルソフトウェア要求」でも「リーンソ

フトウェアの家」の説明が少ないのでより詳しく理解されたい方には SAFe の「リーンソ

フトウェアの家」の原形を提案している書籍[10]を参照されることをお勧めします。

2.1.2. 家の源流と中身

「リーンソフトウェアの家」は、SAFeのオリジナルではなく、元々Larman氏と Bodde

氏が提案した「リーン思考の家」[10]という図を翻案したものです。また、さらに遡るとラ

イカー氏の本[9]の中で似たような図として張富士夫氏が描いたとされる「TPS の家」とい

うものに由来するものではないかと考えられます。

元々の張富士夫氏が描いたとされる「TPSの家」の骨格は以下のようになっています。

屋根：最高品質・最小のコスト・最短のリードタイム、最も安全・最高の勤労意欲

第 1の柱：ジャストインタイム

第 2の柱：自働化

中身：継続的改善

土台：平準化、安定化して標準化された工程、目で見る管理、トヨタウェイの思想

これに対して、Larman氏等が提案した「リーン思考の家」は SAFeの「リーンソフトウェ

アの家」と屋根、柱、土台が同じで、中身だけ「トヨタウェイ」の 14原則の変形版とトヨ

タ自動車さんのプロダクト開発の原則になっています。Larman氏等は、開発手法としては

アジャイル（スクラム）を選択しながらも、それをチームを超えて企業や事業部に展開す

るために、TPSというプロセスではなく、トヨタウェイを中心に家を再定義したのです。

SAFeの「リーンソフトウェアの家」の中身であるプロダクト開発フローは、ソフトウェ

アの比重が高い効果的なプロダクト、システム、サービスを生み出すためのより具体的な

指針を提供するものになっています。また、SAFeにおけるプロダクト開発の流れはこのプ

ロダクト開発フローの原則と整合するものになっています。つまり、プロダクト開発フロ

ーが SAFeを支える原則になっているのです。そのため、SAFeをそのまま適用できないよ

うな状況に面した場合にはプロダクト開発フローまで立ち戻ることでその状況の解決策を

考える手がかりが得られる可能性があります。

2.2. プロダクト開発フロー

プロダクト開発フローは、Donald Reinertsen 氏が “The Principles of Product

Development Flow―Second Generation Lean Product Development”という書籍で記述

したリーンなプロダクト開発を実現するための原則集です。この書籍では、前回説明した

サイクルタイムに加えて経済性を重視すること、アジャイル開発のような一定のリズムで

の開発や早いフィードバックを得ることが強力なプロダクト開発には必要だと述べていま


15

す。言い換えれば、プロダクト開発フローは経済性を中心にリーンとアジャイル開発の融

合による強力なプロダクト開発を実現するための原則を提示しているのです。

2.2.1. プロダクト開発フローの 8つのテーマ

プロダクト開発フロー本では、プロダクト開発の現在の通説を信じることで以下のよう

な 12箇の重要な問題点が生まれると述べています。

経済性を正しく定量化することの失敗

待ち行列に対する無知

効率性への信奉

バラツキに対する敵意

従うことへの信奉

大きなバッチサイズの利用

リズムの過少な利用

待ち行列ではなくスケジュールの管理

仕掛かり作業(WIP)制限の不在

柔軟性のなさ

経済的ではないフローの制御

中央に集中された制御

これらの問題点で言及されている待ち行列などの言葉の意味は本記事の後の部分で説明し

ます。また、これらの問題点の多くの意味は後述する 8 つのテーマの裏返しになっている

のでここでは説明を省略します。

これらの問題点がプロダクトの開発にどのような影響を及ぼすかは、先の箇条書きを見

ても想像しづらいので、筆者の言葉で補足すると以下のようになります。

プロダクトの市場への投入が遅れてビジネス機会を逃す

プロダクトの方向性の誤りによる損失が膨らんだり、より大きな売り上げ/利益を上

げる可能性を失う

戦略的な狙いとは整合しなかったり、市場競争力がないプロダクトができる

ここで述べているプロダクトはシステムやサービスと読み替えることが可能で、その場合

「市場への投入」は「稼働」、「市場競争力がない」は「業務に役立たない」と読み替えれ

ばよいでしょう。

プロダクト開発フロー本では、プロダクト開発フローの 175 箇の原則が如何にこれらの

問題点を解決するかということを以下の 8つのテーマに沿って説明しています。


16

A) 経済性

品質、生産性等の指標ではなく、経済性を一次的な指標に用いるべきである。

また、経済性を高めるという観点でプロダクトの機能を作る順番を決めるべき

である。

B) 待ち行列

プロダクトの開発は待ち行列でモデル化できるので、そのモデルで性質を理解

すべきである。

C) バラツキ

リスクを恐れてバラツキをすべて抑えると、製品としての魅力が失われるので

リスクを取る必要がある。

D) バッチサイズ

バッチサイズを減らすことでプロダクトが得られるまでの期間（サイクル時間）

を短縮するとともに、サイクル時間のバラツキを減らすことができる。

E) 仕掛かり作業(WIP)制限

仕掛かり作業の数を制限することで、開発の流れ（フロー）を良くすることが

できる。

F) リズム、同期、フローの制御

分割して並行に作業を行う場合、作業結果の統合による遅れを減らすために頻

繁に同期した方がよい。また、一定のリズムでプロダクトを作ることでその評

価時期を予め計画することができる。

G) 速いフィードバック

フィードバックを得ることでプロダクトの方向性が正しいかが分かる。早いフ

ィードバックを得ることで、損失を減らしたり、より良い成果を得られる可能

性を高められる。

H) 分散された制御

刻々と変化する情勢において競争に勝つためには、戦略的なレベルでは大きな

方向性や終了状態を示すにとどめ、専門性や素早さが必要な判断は戦術レベル

に委譲すべきである。

以降で「待ち行列理論」と「経済性」を中心にこれらのテーマのいくつかを紹介します。


17

2.2.2. 待ち行列理論

待ち行列理論とは、特定の処理の手前で処理待ちの項目が滞留する状況を考え、その状

況が安定した場合の処理待ちの項目の平均の待ち時間を求めるための理論です。図 2 は、

待ち行列を図示したものであり、左手から処理対象の項目が到着し、それはいったん複数

の線で区切られた箱（処理待ちの列）に項目として追加されます。右手の箱は処理を表す

が、処理に空きができると処理は処理待ちの列から項目を取りだし順次処理を行い、処理

結果を右手に出力します。項目が処理待ちの列に入ってから処理結果として出力されるま

での時間の平均が平均の待ち時間になります。

このような待ち行列の具体例としては、ファーストフード等の店舗で商品を注文する

ためにレジの前に並んだ顧客の注文に対応する処理を挙げることができます。

処理待ちの項目がランダムに到着する場合、平均の待ち時間は以下のようなリトルの法

則で求めることができます。

Wq = Lq/λ

Wq: 平均の待ち時間

Lq：待ち行列の長さ

λ：処理の平均スループット

ここで、処理の部分に「ソフトウェア開発（あるいはプロダクト開発）」を当てはめ、待ち

行列を「要求の一覧」を当てはめると待ち行列でソフトウェア開発やプロダクト開発をモ

デル化できます。さらに、リーン開発で述べた「注文から価値の納品までに要する時間（サ

イクル時間）」は平均の待ち時間に相当します。以降の説明では、待ち行列を「要求の一覧」、

処理を「チーム単位でのソフトウェア開発」として説明します。

以降で、平均の待ち時間の削減方法と複数チームによる開発の同期についてさらに説明

します。

2.2.2.1. 平均の待ち時間の削減

アジャイル開発のように、動くソフトウェアを早く提示することによりプロダクトの有

処理

図 5 待ち行列


18

用性を開発依頼者に確認することができます。動くソフトウェアを早く提示するというこ

とはリトルの法則の「平均の待ち時間」を短縮することに相当し、そのためには「待ち行

列の長さ」を短くしたり、「処理の平均スループット」を向上させればよいことが分かりま

す。しかし、それらに加えて「平均の待ち時間」を短縮するために以下のような選択肢が

あります。

A) 待ち行列の長さを短くする

B) 処理の平均スループットを向上させる

C) バッチサイズを小さくする

D) 仕掛かり作業数を制限する

ここで、バッチサイズとは待ち行列の中の１つの要求の大きさであり、仕掛かり作業数と

は待ち行列の処理で並行に実行する作業の数のことです。

一般的に、開発チーム自身の正味の生産性（スループット）を大きく変えることは難し

いので「平均の待ち時間」を削減するための手段としては A), C) , D)が用いられます。

まず A)については既に述べたようにリトルの法則から「平均の待ち時間」を減らす効果

があることが分かります。

次に C)の影響を説明します。バッチサイズが大きいと、その処理に要する時間は増えま

す。例えば、ウォーターフォール開発は「要求の大きな塊（＝バッチ）」が１つ入力される

待ち行列とモデル化してみましょう。そのような場合は、バッチサイズが大きいためにそ

れらを開発し、納品するまでの待ち時間が長くなり、納品されたものが本当にニーズに合

致しているかを確認するタイミングが遅れます。それに対して、スクラムのプロダクトバ

ックログのように同じ要求を分割してバッチサイズを小さくすることで、それらを納品す

るまでの待ち時間を減らすことができます。つまり、バッチサイズを減らすことでより速

くフィードバックを得ることができるのです。

最後に D)の影響を説明します。仕掛かり作業数が多いと異なる作業間での切り替えのた

めのオーバーヘッドが生じます。そのために同じ作業を順番に行うよりもサイクル時間が

長くなります。そのため、納品までの待ち時間を短縮するためには仕掛かり作業の数に制

限を設けることが有効です。このような制限は仕掛かり作業(WIP：Work In Process)の制

限と呼ばれ、ソフトウェア開発におけるカンバンで積極的に活用されています。

2.2.2.2. 複数チームによる開発の同期

最後にチーム間での開発内容の統合間隔の影響を説明します。複数チームによる開発は

図 6に示されるように複数の待ち行列が合流するものとしてモデル化できます。その際に、

各チームの開発成果を統合する頻度をどのようにすればよいかということが問題になりま

す。統合すべき開発成果を生み出すもととなる待ち行列中の要求を各チームが順次開発し


19

ていき、全チームでそれらの要求すべての開発が終わった段階で統合する場合には、先に

述べたようなチーム毎のサイクル時間のバラツキが累積し、各チームが要求を開発し終え

るまでの期間に大きなバラツキが生じます。その結果、統合できる時期の予測が困難にな

ります。そのようなバラツキの累積を減らし、統合時期の予測性を高めるために短い間隔

でチーム間の開発内容を統合することが望ましいことになります。

2.2.3. 経済性

ハードウェアの製造工程とソフトウェアの比重が大きいプロダクトの開発は両方とも前

述した待ち行列でモデル化することができます。しかし、それらの両者の待ち行列にはい

くつかの違いがあります。以下がそのような違いの例です。

待ち行列中の項目が入れ替え可能か

バラツキに対する考え方

前者は、「ハードウェアの製造工程では一般的に先入れ先出し(FIFO)で処理が行われる」

のに対して「ソフトウェアの開発では開発する要求の順番を変更することが可能」という

違いです。つまり、ソフトウェアの開発の場合には待ち行列中の要求の各々に対する期待

されるビジネス上の恩恵を予測し、その予測に基づいて経済的により高い成果がより早く

得られるように開発する要求の順番を変更することができるということです。さらに、プ

ロダクト開発フローでは要求の順番を考える際に、「遅延のコスト」を考慮すべきだとして

います。「遅延のコスト」は、リリースが遅れることによるプロダクトの価値の経時的な減

少iを意味します。

後者は、「ハードウェアの製造工程ではバラツキを減らすことを重視する」が「ソフトウ

ェアではバラツキはプロダクトの差別化要素になりうるので、バラツキの排除だけを目指

処理

プロダクト処理

処理

図 6 複数の開発チームの開発結果の統合


20

さない方がよい」ということです。ソフトウェア開発において差別化要素になりうるよう

な新機能の開発では不確定性やリスクを伴うことが多くなります。このような不確定性や

リスクは、開発の入力となる待ち行列の項目の大きさの不明確さであり、バラツキと捉え

ることができます。つまり、ソフトウェアの比重が大きいプロダクトの開発でバラツキの

抑制を重視すると、不確定性やリスクを伴う新機能の開発を避けてしまい、結果としてプ

ロダクトを差別化する機能が開発されなくなる可能性があるということです。

3. アジャイル開発を活用する企業や事業部像を提供する SAFe


21

3. アジャイル開発を活用する企業や事業部像を提供する SAFe

3.1. SAFeの特徴

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

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

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

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

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

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

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

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

ア要求」[8]という書籍で最初に世に出ましたが、表 1に示されるような改訂も経ながら現

在も発展し続けています。

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

omという webサイト（日本語訳は SAFe日本語サイト[11]で提供）から一般向けに提供さ

れています。

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

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

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

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

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

表 1 SAFe のこれまでの発展

リリー

ス年

SAFeの

バージョン説明

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

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

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

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

2014年 3.0

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

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

かれる

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

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


22

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

ころにあります。

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

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

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

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

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

定しています。

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

と呼びます。あとの節で、これらの 3つのレベルの概要を説明します。

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

図 7 SAFe の全体像

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

Leffingwell LLC.の許可の下で翻訳

http://www.scaledagileframework.com/


23

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

って力を合わせる

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

現する

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

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

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

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

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

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

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

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

バンシステム

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

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

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

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

が入ります。

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

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

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

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

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

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

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

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

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

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

ビス


24

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

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

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

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

れるのです。

3.2. SAFeの 3つのレベル

3.2.1. ポートフォリオレベルの概要

企業や事業部門のおかれたビジネス状況、財務目標、ポートフォリオレベルのビジョン、

自組織の能力を勘案してプロダクトの方向性を示す箇条書きの戦略テーマを策定します。

この戦略テーマがプロダクトに投資する予算や企画の審査などの意思決定の土台になりま

す。

戦略テーマを実現するためのソリューションが前述したエピックになります。エピック

は当初様々なアイデアレベルで発想されますが、その有効性をポートフォリオカンバンシ

ステムにより以下の複数の段階で評価します。

じょうご

バックログ

分析

ポートフォリオカンバンシステムの各段階では、費用やビジネス効果という観点で粗く

ランク付けされ、上位のランクのものから実現方法や競合製品（従来システム）に対する

優位性、遅延のコストを含むプロダクトやシステムのより精度の高いランク付けや費用見

積もりを行うなどの評価を行います。このようなエピックの評価の過程はプロダクト開発

フローで紹介したカンバンの考え方を応用しています。つまり、仕掛かり作業制限をかけ

て、ある段階で評価対象のエピックの空きができたら前の段階で最もランクの高いエピッ

クから順にプルして評価を行います。さらに、分析を完了したエピックに対してプロダク

ト(システム)の審査会で開発を行うか否かの判断が下されます。

プロダクト(システム)の審査会で承認されたエピックはポートフォリオバックログに入

ります。ポートフォリオバックログに入ったエピックは、優先順位順に開発リソースを確

保し、全体の予算枠から予算割り当てを行い、プログラムレベルで開発に入ります。

この予算割り当てからプロダクトをその利用者に届けるまでの過程を SAFe では価値の

ストリームと呼びます。「リーン思考」の節で説明したように価値のストリームを通じて価

値を提供することが企業や事業部の共通の目標になります。具体的に価値のフローを実行

する中心になる体制を SAFe ではアジャイルリリース列車と呼びますが、承認されたエピ


25

ックが予算割り当てされたアジャイルリリース列車で自律的に開発される様子が SAFe の

全体像では予算と価値のストリームが直結する図で表現されています。

3.2.1.1. ポートフォリオレベルの例

SAFeでのプロダクト開発の流れをより具体的に説明するために、架空の製造メーカーの

家電という事業分野を考えてみることにします。この事業分野では、様々な従来製品が価

格競争にさらされており、そのような価格競争にさらされない事業戦略として「これまで

蓄積した高度なハード及びソフト技術を活用した健康志向でインテリジェントな家電を提

供する」という戦略テーマを設定することにしました。この戦略テーマに沿って実際に開

発するプロダクトの候補がエピックになります。

エピックの候補としてはまずアイデアレベルのものを広く募ります。例えば、インテリ

ジェント家電というテーマで「お掃除ロボット」、「インテリジェント冷蔵庫」、「インテリ

ジェント調理器」などがエピックの候補として得られたとします。それらのエピックの候

補は、「じょうご」のように広く集められ、じょうごのバックログに溜められて初期評価を

行いランク付けします。「じょうご」段階以降、「バックログ」、「分析」という段階を経て

エピックを評価します。このようなカンバンに基づくエピックの候補の評価プロセスによ

り「お掃除ロボット」という有望なエピックが素早く評価されます。

最終的に、「分析」段階で最上位ランクの候補がプロダクト審査会で審議され、開発する

かどうかの判断が下されます。「インテリジェント家電」の例では、「お掃除ロボット」と

インテリジェント家電

プロダクト審査会

ビジネス企画（予算、収支）、その他

お掃除ロボット

お掃除ロボット

インテリジェント冷蔵庫

インテリジェント調理機

ビジネスエピックの候補

戦略テーマ

ビジネスエピック

図 8 ポートフォリオレベルの例


26

いうエピックが開発対象として承認されます。

企画が承認された「お掃除ロボット」エピックはポートフォリオバックログというバッ

クログに保管され、バックログの最上位の項目から開発リソースの手当てがつき次第、次

のプログラムレベルに進み、開発が開始されます。

3.2.2. プログラムレベル

開発に着手することが判断されたエピックに対して、プロダクト管理者がそのエピック

を実現する最上位の要求をフィーチャーとして定義し、さらにビジョンやロードマップを

定義します。これらのフィーチャーは、優先順位付けされてプログラムが開発する機能候

補としてプログラムバックログに取り込まれます。このフィーチャーの優先順位付けにお

いてプロダクト開発フローの節で記述した「遅延のコスト」などを考慮します。

次に、これらのバックログの項目を開発するチームを編成し、これらのチームが 8-12週

毎にプログラムインクリメント(PI)と呼ばれる動くシステムを開発します。PI は、開発の

客観的な進捗の評価に用いられますが、さらにプロダクトの方向性の評価に用いられたり、

リリースされてお客様に提供されることもあります。1 つの PI は、複数回の反復を通じて

開発されます。この 1 つの PI の開発サイクルを PI リリースサイクルと呼ぶと、このサイ

クルは以下のように進行します。

A) 全チームが一堂に会して次の PIに対するリリース計画の策定を行う

B) リリース計画後に全チームは同じ反復周期でインクリメントを開発する

C) 各反復毎にシステムチームが全チームのインクリメントを統合し、統合したものの

テストやデモを行う

D) PI リリースサイクルの最後の反復は機能追加をしない特別な反復になる。この反復

を IP（Innovation Planning）スプリントと呼ぶが、この反復で行うことは以下の 4

点である。

必要に応じて、リリース前の最終テストを行って品質を確保する

今後の開発に備えて新技術の習得などを行う (イノベーション：Innovation)

検査と適合ワークショップで利害関係者向けの PIのデモを行うとともに、プロ

グラムレベルでの改善を行う

次の PIに対するリリース計画の策定を行う（計画策定：Planning）

ここで「インクリメント」とは、機能追加されたソフトウェアのことを意味します。

このような A)-D)の開発の進め方をアジャイルリリース列車と呼びます。このアジャイル

リリース列車が円滑に進むように支援するために SAFe ではリリース列車エンジニア

(RTE)という役割が設定されています。

A)のステップで、直近の PIの目標に含まれるフィーチャーは、開発チームによりユーザ


27

ーストーリーに分解されてチーム単位のバックログ（チームバックログ）へと変換されま

す。

B)において反復期間を統一しているのは、頻繁に同期することでバラツキの累積を防ぎ、

リリーススケジュールの確実性を高めるというプロダクト開発フローの考え方に基づいて

います。

D)では、リリース計画で PIの目標とされたフィーチャーが実装されるので、それを利害

関係者が評価し、その結果を考慮して次のリリース計画に策定します。

SAFeのプログラムでの管理は、チームやメンバーの自己組織化や自己管理に基づくもの

になっています。そのような点を含めて、表 2 に示すように SAFe のプログラムレベルは

スクラムを素直に拡張したものになっています。

SAFeのプログラムレベルには、先に言及したプロダクト管理者やリリース列車エンジニ

ア以外にもシステムアーキテクトや UX、DevOpsなどの専門家がおり、プログラム全体で

のアーキテクチャー、UXなどの品質を確保したり、開発環境から運用環境へのプロダクト

の配置の自動化を推進したりします。

3.2.2.1. プログラムレベルの例

「お掃除ロボット」エピックがポートフォリオバックログで最上位のランクにあり、開

発リソースが確保できた時点で「お掃除ロボット」の開発を進めるための体制（アジャイ

ルリリース列車）が編成されます。「お掃除ロボット」の開発のためのアジャイルリリース

列車は、以下の 5チームで編成されるとします。

システムチーム

走行機能チーム

吸引機能チーム

電源管理チーム

全体制御チーム

表 2 スクラムと SAFe のプログラムレベルの対比

スクラム SAFeのプログラムレベル

プロダクトバックログプログラムバックログ

インクリメントプログラムインクリメント(PI)

スプリント計画リリース計画

スプリントレビューと振り返り検査と適合ワークショップ

プロダクトオーナープロダクト管理者

スクラムマスターリリース列車エンジニア


28

まず、「お掃除ロボット」のエピックに基づき、プロダクト管理者が「お掃除ロボット」

のビジョンを書くとともに、「お掃除ロボット」のフィーチャーを定義し、それをプログラ

ムバックログに保管します。さらに、プロダクト管理者は次回の PI を含む、直近 3 回の

PIに対するロードマップを策定します。

リリース計画策定セッションでは、プロダクト管理者が定義したフィーチャーの上から

10 位までのフィーチャーを各チームに割り当てます。各チームは割り当てられたフィーチ

ャーの実現に必要なユーザーストーリーを書きだし、それらの規模を見積もり、各チーム

が PIまでの期間に開発可能な機能を明らかにします。また、各チームで開発するフィーチ

ャー間の依存性を明らかにします。リリース計画策定セッションの最後では、得られた計

画の達成をプログラムのメンバー全員が確信しているかを確認します。

リリース計画が策定されたら、プログラムは開発を開始し、全チームが同じ反復周期で

開発を行います。また、システムチームが各反復で開発されたコードを結合し、システム

レベルのテストやデモを行います。

通常の反復を４回実行した後、お客様を始めとする開発の利害関係者を集めて検査と適

合ワークショップを開催して、以下のようなことを実行します。

ビジネス企画（予算、収支）、その他

ビジネスエピック

お掃除ロボット第1PI の目標

· 基本走行機能

· 基本吸引機能

· 基本バッテリー残量管理機能

· 動作ログ記録機能

走行機能チーム

吸引機能チーム

電源管理チーム

全体制御チーム

基本走行機能

基本吸引機能

基本バッテリー残量管理機能

動作ログ記録機能

基本給電機能

軌跡記録機能

部屋の探査と地図作成

・・・

プログラムバックログ反復

PI (2.5ヶ月）

反復

プログラムインクリメント

フィーチャー


基本走行機能

基本吸引機能

基本バッテリー残量管理機能

動作ログ機能

システムチームシステム統合

図 9 プログラムレベルの例


29

システムデモ

定量的なデータに基づく振り返り

定性的な振り返り

これらで得られたお客様のフィードバック等によりプロダクトの有効性を評価し、次の PI

に向けたリリース計画の策定を行います。

3.2.3. チームレベル

チームレベルでは、第１章で説明したスクラムに基づき、チームバックログの内容を優

先順位に従って開発します。ここで、チームバックログとはチーム単位のバックログを意

味し、チームに割り当てられたフィーチャーを分解したユーザーストーリー等を保持する

ものです。また、開発するコードの品質を確保するために、SAFe では「テスト駆動開発」

や「継続的なインテグレーション」など XPというアジャイル手法で提案されたプラクティ

スや、アーキテクトと開発チームが連携してアーキテクチャーを構想し実現するアジャイ

ルアーキテクチャーという SAFe固有のプラクティスの適用を推奨しています。

各チームは、プロダクトオーナー、スクラムマスター、開発メンバーから構成され、7±

2名のメンバーで構成されます。SAFeにおけるプロダクトオーナーは、プロダクト管理者

と連携してチームが担当しているプロダクト部分のストーリーを定義し、開発メンバーか

らの質問に対応し、開発されたプロダクトの受け入れを行います。

チームレベルの例

各のチームは、リリース計画策定の過程で得られたユーザーストーリーをチームバック

ログに保管し、反復毎に以下のようなことを実行しながら開発を進めていきます。

反復計画の策定

反復の実行

反復デモと振り返り


30

3.3. SAFeにおける管理者の役割

SAFeの上位の 2レベルでは、経営陣あるいは事業部の上層部、プロダクト管理者、ライ

ンの管理者の役割が設定されており、チームレベルを超えて企業が一丸となって戦略的な

プロダクトやシステムを開発するアジャイルな企業のあるべき姿が提示されています。こ

こでプロダクト管理者とは、戦略的なプロダクトやシステムの開発のリーダーです。

また、SAFeではこれら経営陣から開発チームに至るまでの全メンバーはリーン思考の目

標である「顧客から注文を受けてから、価値を納品するまでのサイクルを短縮する」こと

を目指して改善を行います。その中で、ラインの管理者の担うべき役割としてはそのよう

な改善を自ら推進し、その改善活動の中で次世代を担う人材を育成することが設定されて

います。

基本走行機能

ストーリー１

ストーリー２

ストーリー３

ストーリー４

ストーリー５

ストーリー６

ストーリー７

・・・

チームバックログ

反復

PI (2.5ヶ月）

反復


プロダクトオーナー

スクラムマスター

開発チーム

基本走行機能

ｽﾄｰﾘｰ1

ｽﾄｰﾘｰ2

ｽﾄｰﾘｰ3

ｽﾄｰﾘｰ4

ｽﾄｰﾘｰ5

ｽﾄｰﾘｰ6

フィーチャー

図 10 チームレベルの例

4. 結び


31

4. 結び

2001 年に起草されたアジャイル宣言の時点では、アジャイル開発とリーン開発には多く

の共通点があるものの、掲げているゴールや原則の抽象度が異なっているためにこれらの

両者を効果的に活用する方法が明らかではありませんでした。プロダクト開発フローは、

待ち行列や経済性をベースにこれらの両者を融合する原則を提案しています。さらに、

SAFeはアジャイル開発、リーン思考、プロダクト開発フローの概念を融合し、大規模プロ

ジェクトや企業全体をリーン化、アジャイル化する枠組みを提案しています。今後、SAFe

のような枠組みにより企業全体のアジャイル化がさらに進展することが期待できます。

日本でアジャイル開発の普及を阻む大きな障害は、「開発当初に定めた要求を期日どおり

にすべて実現できたかどうかをプロジェクトの成功/失敗の主たる評価基準とする企業風土」

にあります。そのような企業風土を一挙に変えるのは難しいだろうが、企業の存亡に関わ

るような製品開発や、新たなビジネスに必要なシステムを開発する分野ではこのような形

式的なプロジェクトの成功/失敗の評価ではなく、より実質的なビジネスへの貢献度が本来

的に重視されるはずです。このような企業の存亡に関わるような製品開発や、新たなビジ

ネスに必要なシステムの開発において、アジャイルを適用するという戦略的な判断を下す

ことで日本でのアジャイル開発の普及が促進されることが期待できます。また、このよう

にアジャイルを適用するという戦略的な判断を下すためには企業の経営陣や中間管理職が

ビジネス的な観点でアジャイル開発の利点を理解することを促進する必要があります。

さらに、アジャイル開発を成功させるためには以下のものを導入したり、教育を実施す

ることが必要になります。

要求の表現形式とプラクティスの導入

従来のように精緻な要件を定義する代わりに、ビジネスニーズに基づいて開発内

容を開発者と話し合いながらソフトウェア要求を具体化していくための新たな要

求の表現形式とプラクティスを導入する

プロジェクト管理と技術プラクティスの習得

スクラムに基づくアジャイル開発のプロジェクト管理の枠組みをプロジェクトメ

ンバー全員が習得するとともに、開発メンバーはテスト駆動開発などの技術プラ

クティスも習得する

チームレベルでのアジャイルの導入が進めば、次の段階として考えるのは SAFe のように

企業や事業部の戦略に沿って強力なプロダクト、システム、サービスを開発する枠組みの

導入です。SAFeに関するトレーニング教材の開発やコンサルタント資格認定は米国 Scaled

Agile, Inc.社という会社が行っています。SPC (SAFe Program Consultant)ii等の認定トレ

ーニングの開催告知は、Scaled Agile Academy[12]というサイトに掲載されています。この


32

サイトをご覧頂くと、全世界で SPC認定トレーニングが毎週のように開催されている様子

が分かり、チームレベルを超えてアジャイル開発が広がりつつあることが実感できます。

最後に、本書を読んで SAFeに興味を持って下さり、SAFeをもっと詳しく知りたいとい

う方には「アジャイルソフトウェア要求」[8]や SAFe日本語サイト[11]を読んだり、SAFe

のトレーニングiiiを受講されることをお勧めします。


33

付録

「アジャイルソフトウェア要求」で解説された SAFe 1.0と本書で解説した SAFe 3.0と

の間の主な用語の変更は以下のとおりです。

SAFe 1.0 SAFe 3.0 備考

投資テーマ戦略テーマ

予算だけではなく、戦略的な狙い

を記述するようになった。また予

算は、「予算」と呼ばれるようにな

った。

潜在的に出荷可能なイ

ンクリメント (PSI)

プログラムインクリメン

ト (PI)

ポートフォリオレベルのビジョン

と区別するための名称変更と思わ

れる

プログラム PSI目標プログラム PI目標 PSIの PIへの変更を反映

チーム PSI目標チーム PI目標 PSIの PIへの変更を反映

HIPスプリント IPスプリント HIPの H (Hardening：硬化) が無

くなった


34

参考文献

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

ンエデュケーション, 2005

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

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

[3] アジャイル宣言（日本語訳）, http://agilemanifesto.org/iso/ja/

[4] ケント・ベック, テスト駆動開発入門, ピアソンエデュケーション, 2003

[5] マーチン・ファウラー, リファクタリング―プログラムの体質改善テクニック, ピアソ

ンエデュケーション, 2000

[6] 野中郁次郎, 竹内弘高, 知識創造企業, 東洋経済新報社, 1996

[7] Donald G. Reinertsen, Product Development Flow: Second Generation Lean

Product Development, Celeritas Publishing, 2009

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

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

[9] ジェフリー・ライカー, ザ・トヨタウェイ (上, 下), 日経 BP, 2004

[10] Craig Larman, Bas Vodde, Scaling Lean & Agile Development: Thinking and

Organizational Tools for Large-Scale Scrum, Addison-Wesley, 2008

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

[12] Scaled Agile Academyのサイト, http://www.scaledagileacademy.com/

i リリースの遅れにより起こり得る価値の低下（＝売り上げや利益の減少）のことを「コス

ト」として捉えている ii SAFe関連のトレーニングやコンサルティングを実施するための認定資格 iii 弊社でも Scaled Agile, Inc.社の教材を日本語化した「SAFeリーダー研修」を提供して

おりますので、受講をご検討下されば幸いです。

http://agilemanifesto.org/iso/ja/

http://www.scaledagileframework.com/jp/

http://www.scaledagileacademy.com/

アジャイル開発

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

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

揃えましたので、ご紹介いたします。

概論概論

実践実践

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

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

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

「スクラム入門」（1日）

• 演習、及び、アジャイル開発の導入に関する事例紹介等を通じて、アジャイル開発手法の一つであるScrumを使ったソフトウェア開発のプロジェクトの進め方を学習します。

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

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

基礎基礎

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

オージス総研の研修サービスは１０年以上の実績に基づいて、「モデリングコース」、「IT基礎コース」、「共通・業務基礎コース」の３コース、３０を超えるトレーニングメニューをご用意しています。オブジェクト指向、組み込み開発、UML、SｙｓML、分析モデリング、Javaプログラミング等、ITに関する様々なトレーニングメニューを提供しています。

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

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

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

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

※本コースは米国Scaled Agile, Inc.のトレーニングを日本語化したものです

リーダー育成

リーダー育成

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

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

実行力を強化するアジャイルメトリクスチーム、プログラム、ポートフォリオのために

チームのために

チームに適した独自のダッシュボードをカスタムする

• 進捗と優先順位を視覚化

• 誰が何の作業をしているか見える化し、チームのコミュニケーションと学習を促進

• チームの動向を分析し素早く状況に対応

プログラムのために

透明性が高く、全ての関係者に進捗や状況が手に取るようにわかるプログラムを実現する

• 開発全体の進捗から主要な機能別の作業状況まで視覚化

• 予測機能でリスクを管理し状況の変化に対応

• ボトルネックをいち早く発見し、問題化する前に処理

• バグや複数チームにまたがるタスク依存関係を把握

ポートフォリオのために

ポートフォリオ全体に渡るプログラムの健全性、投資テーマを明確にし、リアルタイムで管理可能にする

• アイデア段階から展開ソリューションにいたる投資パイプライン

• プログラム全体のリリースまでの進行具合

• プログラム全体の見積もりと実際の作業量の比較

• プログラム全体のチームと個人の割当状況

Hansoftは、製品やサービスのアジャイル開発においてマネジメントやチームコラボレーションを支援するツールです。電子工学、航空、宇宙開発、ゲーム開発、通信、クラウドサービスなど幅広い分野のお客様にご使用いただいております。Hansoftは、アジャイルADLM（アプリケーション開発ライフサイクル管理）、PPM（製品ポートフォリオ管理）、ビジネスインテリジェンス、ソーシャルコラボレーションを実現する一連の機能を備えています。10人以下の小規模チームから数千人の規模まで、様々な組織のあらゆるレベルのメンバーがHansoftを活用することができます。スクラム等個々のニーズに則したアジャイルメソッド、かんばん方式やガントチャートによる管理、バグトラッキング、ドキュメント管理、外部取引先との連携、長期的な計画立案、ダッシュボードによるリアルタイムレポート、作業量とポートフォリオ分析、アジャイルメトリクス……充実の機能が満載です無料9ユーザートライアル版を早速ダウンロード： www.hansoft.jp

Hansoft8の特徴は、Hansoft内のデータを使い協働できるプラットフォーム『ダッシュボード』によるビジネスインテリジェンスの実現です。数値化、視覚化された情報によってチーム、マネージャー、役員など関係者全員が即時に状況を把握し、迅速で適切な行動や意思決定を行えるようにします。

Hansoftでスケーラブルなアジャイルポートフォリオレベル• エピックを投資テーマに再構成し、優先順位をつける

• ポートフォリオ上のかんばんを利用して、エピックが進化していく過程を追跡し、また互いに関連しあう開発プログラムがどのように各エピックのフィーチャーを実現に近づけるかを記録

プログラムレベル• 各チームが自主的にリリース計画に参加しやすいようプログラムを

整理

• プログラムのバックログ、リリース計画、実行をリアルタイムに管理

• 各チームが自主的に計画を立てやすいよう、バックログの部分的委任が可能

• 複数プログラムに渡ってポートフォリオのエピックとフィーチャーを関連付け出来るので、どこからフィーチャーが起因しているか簡単に確認できる

チームレベル• 各チームにそれぞれが担当するバックログの管理を丸ごと委任可能。

チームメンバー自らがタスクを分解したり、好みの作業方法を選んだりすることができる

• チャット、ファイル共有、ライブニュースフィード上での仕事状況のフォロ―により、あらゆる局面でメンバー同士やチーム間の連携を促進。各チームの依存関係の把握も容易に

ポートフォリオ、プログラム、チームレベルの進捗状況を管理・記録しようHansoftのかんばん機能と進捗トラッキング機能はあらゆるレベルの管理で活かすことができ、開発プロセスの進行状況をポートフォリオ、プログラム、チームのどのレベルでも簡単に把握できる

株式会社オージス総研

http://www.ogis-ri.co.jp E-mail:[email protected]の説明：

http://www.ogis-ri.co.jp/product/1210106_6798.html Hansoft試用版のダウンロード： http://www.hansoft.com/get-hansoft/?partner=OGIS&lang=ja

書籍『発見から納品へ

：アジャイルなプロダクトの計画策定と分析』の御紹介

書籍情報

タイトル：発見から納品へ―アジャイルなプロダクトの計画策定と分析

著者：エレン・ゴッテスディーナー、メアリー・ゴーマン

出版社：自費出版

価格： ¥3,500 (税込)*

出版年： 2014年

ページ数： 287ページ

*: 本書のご購入に関する注意：本書は自費出版のため、一般の書店では御取り扱いされま

せん。ネット書店ではお取り扱いされますので、ご購入に際してはネット書店を御利用

下さるようにお願い致します。

本書の特徴

アジャイル開発、リーン開発、従来開発のために要求をとりまとめる分析者、要求エンジニア向けに本書は軽

量で迅速に要求を取りまとめるための手法を解説します。他の書籍と異なり、ユーザーストーリー一辺倒ではな

く、プロダクトを７つの側面と３つの計画ビューで考えることで要求の考案とそれらの計画へのマッピングを系

統的に行う方法( DtoD：Discover to Deliver )とそれらを支援するテクニック群を解説しています。また、事例も

ガラス清掃業のためのシステム開発を題材にしており、通常の業務アプリ開発に近いものになっています。

書籍の構成

セクション１：事例

ガラス清掃業を営むスクイーキー・クリーン (SK)社という設定で、その会社の課題、顧客、ビジネス、技術

的な観点での価値を議論し、それらの価値を実現するソリューションを次回のリリース（事前ビュー）、直近の

反復（現在ビュー）、ロードマップ（全体ビュー）という３つの時間軸で考えていく過程が記述されています。

以降のセクションで示される例もこのセクションの事例に基づいています。

セクション２：主要概念

"DtoD”の主要な構成要素であるプロダクト、プロダクトパートナー関係、価値、計画、構造化された会話の概

要が説明されています。セクション１は、これらを実践している具体例になります。「構造化された会話」とは、

「調査」、「評価」、「確認」の３段階を通じて候補ソリューションのオプションや要求に対する合意を形成するた

めのテクニックです。

セクション３：プロダクトの７側面

"DtoD”の構造化された会話では、話し合った内容を書き込むために「オプションボード」というものを使いま

す。このオプションボードには、ユーザー、インターフェイス、アクション、データ等７つの側面（欄）があり

ますが、それらの側面の概要とそれらの側面で議論が始まる例が示されています。

セクション４：構造化された会話

構造化された会話の「調査」、「評価」、「確認」の３つの段階を説明し、さらに構造化された会話で議論する対

象となる各オプションについてそれらを検討するための問いかけや、抽出や評価の進め方に対するアドバイスを

提供しています。

セクション５：プラクティスを適応する

構造化された会話や、納品（開発）方法、商用ソフトウェアの調達、ドキュメント作成、規制下にあるプロダ

クトの場合のプラクティスの適応方法に対するヒントが説明されています。

セクション６：ツールとテクニック

受け入れ基準一覧、ビジネスポリシーとルールなど"DtoD”を実践するのに役立つ各種テクニックやツールの概

要が紹介されています。

著者について

エレン・ゴッテスディーナー

EBG Consulting 社の創業者であり、社長であるエレン・ゴッテスディーナーは、要求 + プロダクト管理 + プ

ロジェクト管理をコラボレーティブな形で収束させた分野で世界的に認知されたリーダーです。エレンは、個人

やチームに対するコーチングやトレーニングを提供するとともに、様々な業種に渡って発見と計画策定ワークシ

ョップをファシリテートしています。エレンは、世界中で広く執筆、基調講演、講演を行っています。彼女は、

認定されたプロフェッショナルファシリテーターです。本書に加えて、エレンは『Requirements By

Collaboration（邦訳「要求開発ワークショップの進め方, 日経 BP, 2007」）』と『The Software Requirements

Memory Jogger（邦訳「実践ソフトウェア要求ハンドブック, 翔泳社, 2009」）』という高い評価を得ている 2冊

の書籍の著者です。

メアリー・ゴーマン

EBG Consulting 社の品質と納品担当の副社長であるメアリー・ゴーマンは、ビジネス分析と要求でリーダー

と認知されています。メアリーは、プロダクトチームをコーチしたり、発見ワークショップをファシリテートす

るとともに、価値の高いプロダクトを定義するのに不可欠なコラボレーションプラクティスでビジネス、顧客、

技術の利害関係者にトレーニングをしています。メアリーは、商業カンファレンスで講演し、アジャイル、ビジ

ネス分析、プロジェクト管理コミュニティー向けに執筆しています。彼女は、認定された Business Analysis

ProfessionalTM です。IIBA®と PMI®コミュニティーを横断してビジネス分析職に対する中心的な貢献者であ

り、IIBA®の Business Analysis Body of Knowledge®や、IIBA®やと PMI®のビジネス分析認定試験の開発を

支援しました。

本社／岩崎コンピュータセンター〒550-0023 大阪府大阪市西区千代崎 3 丁目南 2 番 37 号 ICC ビル

TEL.06-6584-0011（代） FAX.06-6584-6497

東京本社〒108-6013 東京都港区港南 2-15-1 品川インターシティＡ棟 12,13Ｆ

TEL.03-6712-1201 FAX.03-6712-1202

千里オフィス〒560-0083 大阪府豊中市新千里西町 1 丁目 2 番 1 号クリエイティブテクノソリューション千里ビル

TEL.06-6831-0531（代） FAX.06-6872-9404

名古屋オフィス〒460-0003 愛知県名古屋市中区錦 1 丁目 17 番 13 号名興ビル

TEL.052-209-9390 FAX.052-209-9391

豊田オフィス〒471-0034 愛知県豊田市小坂本町 1 丁目 5 番地 10 号矢作豊田ビル

TEL.0565-35-6722 FAX.0565-35-6723

http://www.ogis-ri.co.jp/

2015. 6

Copyright 2015, OGIS-RI Co.,Ltd ·...

Documents

Transcript of Copyright 2015, OGIS-RI Co.,Ltd ·...