オブジェクトの広場は株式会社オージス総研グループのエンジニアによる技術発表サイトです

index |
アジャイル

SAFe 4.0 & 4.5の改訂点

第1回:リーン-アジャイルの考え方とSAFeの原則
オージス総研 技術部 アジャイル開発センター
藤井 拓
2018年5月29日

SAFe (Scaled Agile Framework)は、2011年の誕生以来ほぼ毎年のように毎回改訂されているが、本連載では3回 (?)に分けて2016年7月にリリースされたSAFe 4.0と2017年にリリースされたSAFe 4.5の改訂点を概説する。今回は、SAFe 4.0の変更点の概要と変更点の1つであるリーン-アジャイルの考え方とSAFeの原則を紹介する。

SAFe 4.0 の改訂点の概要

Web上で公開されているSAFe 4.0の全体像 [1] のタイトルには「SAFe 4.0: リーンなソフトウェアとシステムエンジニアリング向け」とデカデカと書かれており、一見するとSAFe 4.0の最大のセールスポイントは「システムエンジニアリングへの対応」という印象を受けるだろう。

しかし、実際にはSAFe 4.0の改訂点を全体的に整理すると以下のようになり、「システムエンジニアリングへの対応」だけではない。

  1. リーン-アジャイルの考え方とSAFeの原則
  2. ポートフォリオレベル以外のレベルへのカンバンの導入
  3. リーン-アジャイルなリーダー
  4. システムエンジニアリングへの対応

本記事では、SAFe 1.0の解説書である「アジャイルソフトウェア要求」[2] の読者や、SAFe 3.0 [3] までをご存知だったり、実践されている人を対象としてこれらの人達の関心がもっとも高いと思われる A ~ Cの概要を説明する。

なお、本原稿の執筆時点ではSAFe英語サイト [4] のSAFeはver4.5、SAFe日本語サイトのSAFeはver4.0になっている。以降、SAFe 4.0の各変更点の説明において、その変更点のより詳しい説明を提供しているSAFe日本語サイトのページへのリンクも記すことにする。

リーン-アジャイルの考え方とSAFeの原則

SAFe 3.0までは、「リーンソフトウェアの家」[2], [5]と呼ばれているものが、SAFe 4.0では「リーンの家」と名称が変わった。このリーンの家は、アジャイル宣言 [6] とともにリーン-アジャイルを活用してソフトウェアやシステム製品を開発する組織のメンバーが共有すべき理念である「リーン-アジャイルな考え方」を表すものとして位置付けられている。「リーン-アジャイルな考え方」のより詳しい説明は、SAFe日本語サイトの「リーン-アジャイルな考え方」のページをご参照ください。

図1はSAFe 4.0のリーンの家である。SAFe 4.0のリーンの家は、SAFe 3.0のリーンソフトウェアの家から以下のように変化している。

  • 「イノベーション」という柱が1本増えた
  • 家の中の「プロダクト開発フロー」の原則が無くなった
  • 土台が「上役」ではなく「リーダーシップ」に替わった

「リーンの家

図 1 リーンの家

以降で、まず「イノベーション」の柱が増えた点と「プロダクト開発フロー」の原則が無くなった点を説明する。「リーダーシップ」については、次回の記事で説明する。

「イノベーション」という柱が増えた

「イノベーション」という柱が1本増えたのは、従来「プロダクト開発フロー」[7], [8] で競争力のあるプロダクトを作るための原則が述べられていたものの、それでは「イノベーション」の重要性が明確に示せていなかったことに起因するのではないかと考えられる。「イノベーション」の柱を作ることで、「イノベーション」を生み出すために環境を整備することの重要性やリーンスタートアップで提起されているような仮説の検証結果に基づく方向転換(ピボット)の重要性も併せて示すことができるようになった。

「プロダクト開発フロー」の原則が無くなった

SAFe 3.0の「リーンソフトウェアの家」の家の2本柱の間(家の中)には「プロダクト開発フロー」の原則が据えられていた。SAFe4.0の「リーンの家」では、このプロダクト開発フローの原則が無くなったように一見見える。

SAFe4.0では、プロダクト開発フローは以下の2つの部分に分かれてよりSAFeに一体的に組み込まれている。

  • フローの柱
  • SAFeの原則

フローの柱は、基本的には価値の流れを良くするということであり、そのためには開発体制を長期に渡って存続させたり、品質の作り込みを行ったり、プロダクト開発フローで述べられているように意思決定を分散化する必要があることを表している。フローの柱になることで、価値の流れを良くすることを目指すことが開発組織以外の人達にもより分かりやすくなったと思う。

もう一方のSAFeの原則は、以下のような9つの原則で構成される。

  • #1 - 経済的な視点を取る
  • #2 - システム思考を適用する
  • #3 - 可変性を仮定する。つまり、オプションを持ち続ける
  • #4 - 速く統合された学習サイクルとともにインクリメンタルに構築する
  • #5 - 動作するシステムの客観的な評価に基づくマイルストーン
  • #6 - WIPを可視化して制限し, バッチサイズを減らし, 待ち行列の長さを管理する
  • #7 - リズムを適用し, 分野横断の計画策定で同期する
  • #8 - ナレッジワーカーの内発的なモチベーションを解き放つ
  • #9 - 意思決定を分散する

これらの原則は、プロダクト開発フローだけではなく、システム思考、アジャイル(反復)開発、トヨタ製品開発、モチベーション3.0 [9] の考え方を融合したものになっている。

例えば、#1、 #6、#7、#9はプロダクト開発フローの原則に由来するものである。#6はさらにさかのぼればトヨタ生産方式に由来するが、SAFeではカンバンやバックログの形で取り入れられている。#7のリズムとしては、SAFeでは2週間の反復というチームレベルのリズムに加えて、プログラムレベル以上では8-12週というプログラムインクリメント (PI) というリズムが用いられている。PIの最初にPI計画策定というイベントがあり、ここでプロダクトの重要な利害関係者とプログラムのメンバーが一堂に会して計画策定を行う。プロダクト開発フローのより詳しい説明については、[8] をご参照下さい。

#2は原則の文に書いてあるようにシステム思考に由来する。プロダクトの企画、開発、運用を実行する組織をシステムとして捉え、そのシステムをバリューストリームマッピングなどで可視化して全体最適化するべきだということである。

#3は、トヨタ製品開発のセットベース設計の考え方を取り入れたものである。可変性は、プロダクトの開発途上で仕様、設計、テストに変化しうる部分があることを表している。セットベース設計の考え方は、メカ、エレキ(電子回路)、ソフトウェアなどで構成されるシステム製品において製品の実現方式(設計)としては複数の選択肢(オプション)があり、それらを早急に絞り込まないことでより良い設計上の判断ができるというものである。

#4、#5はアジャイル(反復)開発の基本的な考え方を表したものである。SAFeでは、チームレベルでの統合に加えてプログラムレベルやその上のレベルで定期的に統合して動作するプロダクトを作成する。これらの複数のレベルの統合は、真の進捗を評価し、学習する点で非常に有効である。

#8は、モチベーション3.0に由来する。ソフトウェア開発者は、ナレッジワーカーであり、そのような人たちのモチベーションが高くなるためには自律性、熟達、目的が必要になるということである。

SAFeの原則の意味するところを、個別の原則の文を読むだけで理解するのは難しいだろう。それでも、これらの原則はSAFeの多くのイベント、役割、成果物が生まれた際の拠り所となる考え方を簡潔に表現したものになっている。これらの原則を理解することで、以下のようなことができるようになる。

  • SAFeの適用の際にイベント、役割、成果物を取捨選択する場合、それらのイベント、役割、成果物を抜いたり、変えたりすることでどのような問題が発生しうるかを推測することができる
  • SAFeを実践している段階で生じている問題の根本原因を推測する際のヒントになる

「SAFeの原則」のより詳しい説明は、SAFe日本語サイトの「SAFeの原則」のページをご参照ください。

第 1 回の終わりに

今回の記事では、以下のAを説明した。

  1. リーン-アジャイルの考え方とSAFeの原則
  2. ポートフォリオレベル以外のレベルへのカンバンの導入
  3. リーン-アジャイルなリーダー

次回の記事では、B, Cを説明する予定である。

参考文献

[1] SAFe日本語サイト, https://www.scaledagileframework.com/jp
[2] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014
[3] 藤井拓, SAFe 3.0入門, https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/
[4] SAFe英語サイト, https://www.scaledagileframework.com
[5] 藤井拓, SAFe 3.0入門:第2回「チームを超えたものの必要性とリーン思考」, https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/IntroSAFePart2May2014.html
[6] アジャイル開発宣言, http://agilemanifesto.org/iso/ja/manifesto.html
[7] Donald G. Reinertsen, The Principles of Product Development Flow―Second Generation Lean Product Development, Celeritas Publishing, 2009
[8] 藤井拓, SAFe 3.0入門:第3回「プロダクト開発フロー」, https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/IntroSAFePart3Feb2015.html
[9] ダニエル・ピンク, モチベーション3.0 持続する「やる気!」をいかに引き出すか, 講談社, 2015