日時：2014/05/20 (火) 19:30 - 21:30
場所：株式会社オージス総研

所感

日本では一般的にアジャイルは小チームの開発にしか利用できないという認識で多い。
関連区などが多いエンタープライズ開発には向かないと思われているが、アジャイルを大規模開発プロジェクトにも取り入れるべく、拡張を行ったのが、Scaled Agile Framework (SAFe)とDisciplined Agile Delivery（DAD）になる。
双方は拡張の方向性が異なっている。

SAFe：企業の階層に沿った拡張。管理職や執行役員を含めたアジャイル開発のモデルを提供する
DAD：時間軸に沿った拡張。プロジェクトの意思決定ポイントを明確化し、「方向付け」、「構築」、「移行」の3フェーズに分けて考える。

どちらも百名以上が参加するようなプロジェクトや経営層まで含めて大規模アジャイル開発のエッセンスを適用するためのアプローチを提供する。
フレームワークのため、段階的、部分的な利用をすることができる。
特にDADのほうは豊富な200近い戦略やゴールなどが用意されている。どちらのフレームワークもWebのフォローが充実しており、まず少し目を通してから、いずれかの書籍を購入しようと思う。

Scaled Agile Framework.com
http://scaledagileframework.com/

「ディシプリンド・アジャイル・デリバリー – エンタープライズアジャイル開発への実践ガイド」日本語版公式サイト
http://disciplinedagiledelivery.jp/

以下、セミナーのメモ。

「機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe)のご紹介」

藤井拓氏

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

日本ではアジャイル開発は小規模じゃなければ使えないという印象
それは否だが、アジャイル開発ならばステークホルダーの関与を無視して良いのか？
システムとしても中規模システムや大規模システムを対象にしなければいけない。

知識創造企業のコンテキスト
次の２つが必要とされる。SAFeはこれを提供する。

戦略と実現性の兼ね合いを取る中間管理職（リーダー）の存在
組織の枠を超えた団結や相互作用

SAFeとは企業規模でリーンとアジャイルのプラクティスを適用するための実証され、公開されたフレームワーク

Scaled Agile Framework(SAFe)の紹介

SAFe自体は新規性があるものではない。
リーン思考やプロダクト開発フロー、アジャイルを組み合わせたもの。

SAFeの構成要素

要求プラクティス
リーン
プロダクト開発フロー
など

リーン思考が必要な手段をSAFeはフレームワークとして提供する。
リーダーシップを土台に人々に対する敬意、開発フロー、改善を用いてゴール（価値）を提供する

価値の納品までのサイクル
価値を高め、サイクルタイムを減らす！

プロダクト開発フロー

第２世代のリーンプロダクト開発手法と呼ばれる。

チームによるソフトウェア開発は待ち行列でモデル化できる。

到着感覚のばらつき
バッチサイズとそのばらつき
チームの稼働率。

どうやって要求やインプットの待ち行列の処理時間を短くできるか。
製造は到着した順に処理できる。
ソフトウェア開発の場合は待ち行列の項目の順番を変えることで、経済的効果を左右できる可能性がある。

より早くお金を生む
1つのフィーチャーの市場価値は時間推移と共に価値が減少していく。
それを考慮して開発を行うべきである。
待ち行列モデルでは時間推移による価値の変動を考慮して順番を決めるべきだ

SAFeの階層構造

SAFeは企業の階層に合わせ、3層のレベルに分かれる。
企業や事業部全体が一体となって開発を進めることを提唱し、アジャイル開発を企業や事業部レベルでの適用するためのフレームワークとなっている。

ポートフォリオ

経営陣や事業部長などを戦略的な投資判断に基づいてプロダクトやシステムの企画を行う。

投資テーマ、エピックをポートフォリオカンバンシステムで管理する。

プログラムレベル

企画を実現するために複数チームでプログラム（複数チームで構成される大規模プロジェクト）を編成し、プロダクトの開発計画を立案、開発し、リリースする。

プロダクト管理者がリードする形でプログラムを編成し、開発を行う。
ビジョンとフィーチャーの定義　　
エピックを実装するという判断がくだされたら上記を定義する
アジャイルリリース列車
複数のチームがシステムを構成するフィーチャを実装していく。
３サイクルごとにPSIを行う

チーム

通常のアジャイルとほぼ同様。プログラムレベルにおいてチームが分担した要求をアジャイル開発により5-9名程度で開発を行う。
プロダクトオーナのもと、複数のスクラム/アジャイルマスターおよびアジャイルチームが存在する。

年に一回程度で、ポートフォリオからプログラム、チームへとベクトルをあわせる。

まとめ

リーダーシップが大事。

組み込み（農機具メーカ）からオンライン証券会社まで幅広く利用している。

大規模プロジェクトを成功させるための一般的な枠組みとは？
ユーザーストーリーで全てをまかなえるわけではない。
アジャイルチームだけでなくアジャイルプログラムで考える

要求
ユーザーストーリーかユースケースなのか
プロジェクト管理
スクラムの良さを損なわない複数チームの間の連携方法
アーキテクチャー
開発中だけではなく、ある程度先行して考えるべき。
チームを超えた広がり
関心ごとの異なる人達でどう共有するか

プログラムレベルでSAFeを見ると複雑に思えるが、スクラムの素直な拡張と捉えれば理解しやすい。
アジャイルを一気に導入すべきか、一歩ずつ導入するべきかは各企業にゆだねられる。

SAFe（Scaled A gile Framework）の参考リンク

scaledagileframework.com
http://scaledagileframework.com/

オージス総研：大規模アジャイル開発フレームワークScaled Agile Framework （SAFe）
http://www.ogis-ri.co.jp/solution/1210904_6793.html

#「「ん？してみると、『これまでのアジャイルは現実解ではない』とでも？」」

藤井智弘氏

Enterprise and/or Agile

「そもそも」論が多すぎて思考停止をしているのではないか？
バリバリのの日本企業の中でどうやってアジャイルするのか？

アジャイルの現実

日本の企業でアジャイルを行おうとすると、抵抗を受けることが多い。以下のようなメンタリティが企業の中には存在する。

会社のガバナンスに現場は従うべき。
（ユーザーが入ると調整がめんどくさくなるから）開発チームでできる範囲でやる
現状の業務よりもITシステム絡みで時間を取られすぎてしまうのを嫌がるエンドユーザー
ビジネスプロセス全体を見直すなんて予算ないから、出来る範囲で
そんなに自動化したら、社内失業になっちゃう
ウォーターホールで失敗してもまだ説明できるがアジャイルで失敗すると説明できない。

DADとは

DADとは、プロジェクトの意思決定ポイントを明確化し、時間軸にそってスクラムを拡張したフレームワークである。
プロジェクトのフェーズを 「方向付け」、 「構築」、 **「移行」**の3フェーズに分けて考える。

方向付けフェーズ：ステークホルダーの合意形成フェーズ
構築フェーズ：従来のアジャイル運営に則る
移行フェーズ：リリース後の環境移行、エンドユーザー教育など

DADが現実的だと思う２つの理由

Why, HowをWhat, Whichに変えている。
部分導入が可能など、ロードマップ的な意識がある。実際に企業内で段階的に導入するのに向いている

DADは読みたいところだけを読める。
ゴールの実現手段としての戦略
DADはゴール指向ベース。それぞれのフェーズにゴールが設けられている。
ゴール（What)に向かうための７つのプロセス、６０のプラクティス、３７の戦略、比較表１９５の戦略がある。（Whichとしての選択肢を複数選べる）

ビジョンの戦略比較、イテレーション機関の戦略比較などの利点、欠点、考慮事項を表にした多彩にある。
DADはフレームワークなので、チームの成熟度合いや開発状況にあったプラクティスが選択できる。

また、アジャイルに消極的、否定的な人を前提として話が進んでいる。
大企業ではアジャイルをビジョンとして掲げてもいきなりは導入できない。
段階的にステージ、成熟度を進める術が書いてある。

否定的な人たちに対しても計画的に、段階的にアジャイルを導入できるのがDADの魅力である。

また、文中の戦略表で現状と目指すべき姿のギャップが明確になる。
成熟度をあげるためのステップをデザインしやすくなるため、適切な期待値を設定できる。

DADの本はサンプル集のようなアプローチで、今のビジネスにアジャイルを導入することでどう貢献できるのか、そこに向かうロードマップを描くことができる。

DAD(Disciplined Agile Delivery)の参考リンク

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド
http://www.seshop.com/product/detail/15816/

第2回　ディシプリンド・アジャイル・デリバリーというお作法
http://codezine.jp/article/detail/6474