SAFe (Scaled Agile Framework) [1]の 構造やプラクティスは、プロダクト開発フローという強力なプロダクト開発を実現するための原則集と整合するように考案されています。それにも関わらず、SAFeの解説本である「アジャイルソフトウェア要求」[2]はプロダクト開発フロー本を読んでいることを前提に執筆されているようでプロダクト開発フローに関する説明はかなり省略されています。本記事では、SAFeを理解する助けとなるよう「アジャイルソフトウェア要求」の説明よりもやや詳しくプロダクト開発フローを説明します。
1. プロダクト開発フローとは
プロダクト開発フローは、Donald Reinertsen氏が “The Principles of Product Development Flow―Second Generation Lean Product Development” [3] という書籍( 以降「プロダクト開発フロー本」と呼ぶ )で記述したリーンなプロダクト開発を実現するための原則集です。この書籍では、前回説明したサイクルタイムに加えて経済性を重視すること、アジャイル開発のような一定のリズムでの開発や早いフィードバックを得ることが強力なプロダクト開発には必要だと述べています。言い換えれば、プロダクト開発フローは経済性を中心にリーンとアジャイル開発の融合による強力なプロダクト開発を実現するための原則を提示しているのです。
2. プロダクト開発フローの8つのテーマ
プロダクト開発フロー本では、プロダクト開発の現在の通説を信じることで以下のような12箇の重要な問題点が生まれると述べています。
- 経済性を正しく定量化することの失敗
- 待ち行列に対する無知
- 効率性への信奉
- バラツキに対する敵意
- 従うことへの信奉
- 大きなバッチサイズの利用
- リズムの過少な利用
- 待ち行列ではなくスケジュールの管理
- 仕掛かり作業(WIP)制限の不在
- 柔軟性のなさ
- 経済的ではないフローの制御
- 中央に集中された制御
これらの問題点で言及されている待ち行列などの言葉の意味は本記事の後の部分で説明します。また、これらの問題点の多くの意味は本記事で後述する 8 つのテーマの裏返しになっているのでここでは説明を省略します。
これらの問題点がプロダクトの開発にどのような影響を及ぼすかは、先の箇条書きを見ても想像しづらいので、筆者の言葉で補足すると以下のようになります。
- プロダクトの市場への投入が遅れてビジネス機会を逃す
- プロダクトの方向性の誤りによる損失が膨らんだり、より大きな売り上げ/利益を上げる可能性を失う
- 戦略的な狙いとは整合しなかったり、市場競争力がないプロダクトができる
ここで述べているプロダクトはシステムやサービスと読み替えることが可能で、その場合「市場への投入」は「稼働」、「市場競争力がない」は「業務に役立たない」と読み替えればよいでしょう。
プロダクト開発フロー本では、プロダクト開発フローの175箇の原則が如何にこれらの問題点を解決するかということを以下の8つのテーマに沿って説明しています。
- 経済性
- 品質、生産性等の指標ではなく、経済性を一次的な指標に用いるべきである。また、経済性を高めるという観点でプロダクトの機能を作る順番を決めるべきである。
- 待ち行列
- プロダクトの開発は待ち行列でモデル化できるので、そのモデルで性質を理解すべきである。
- バラツキ
- リスクを恐れてバラツキをすべて抑えると、製品としての魅力が失われるのでリスクを取る必要がある。
- バッチサイズ
- バッチサイズを減らすことでプロダクトが得られるまでの期間（サイクル時間）を短縮するとともに、サイクル時間のバラツキを減らすことができる
- 仕掛かり作業(WIP)制限
- 仕掛かり作業の数を制限することで、開発の流れ（フロー）を良くすることができる。
- リズム、同期、フローの制御
- 分割して並行に作業を行う場合、作業結果の統合による遅れを減らすために頻繁に同期した方がよい。また、一定のリズムでプロダクトを作ることでその評価時期を予め計画することができる。
- 早いフィードバック
- フィードバックを得ることでプロダクトの方向性が正しいかが分かる。早いフィードバックを得ることで、損失を減らしたり、より良い成果を得られる可能性を高められる。
- 分散された制御
- 刻々と変化する情勢において競争に勝つためには、戦略的なレベルでは大きな方向性や終了状態を示すにとどめ、専門性や素早さが必要な判断は戦術レベルに委譲すべきである。
これら8つのテーマを構成される原則を適用することで、期待される効果は以下のとおりです。
- より良い経済性
- プロダクトをタイムリーに市場への投入することで、ビジネス機会を逃さない
- プロダクトの方向性の間違いによる損失を減らし、方向性の正しさを強化することで売り上げ/利益を増大する
- 異なるスキルの連携による戦略のより良い実現
- 戦略的な狙いと戦術レベルの素早い専門的な判断のシナジー効果で、市場競争力のあるプロダクトを作る
SAFeがプロダクト開発フローのテーマや原則と整合するように考案されたのは、SAFeもこれらのプロダクト開発フローの効果を実現することを狙っているからです。
以降で「待ち行列理論」、「経済性」、「同期」を中心にこれらのテーマに登場する概念を少し詳しく説明します。
3. プロダクト開発フローを構成する概念
3.1.待ち行列理論
待ち行列理論とは、特定の処理の手前で処理待ちの項目が滞留する状況を考え、その状況が安定した場合の処理待ちの項目の平均の待ち時間を求めるための理論です。図 1は、待ち行列を図示したものです。
この図の左側から処理対象の項目が到着し、それはいったん複数の線で区切られた箱（処理待ちの列）に項目として追加されます。右側の箱は処理を表しますが、処理に空きができると処理は処理待ちの列から項目を取りだし順次処理を行い、処理結果を右手に出力します。項目が処理待ちの列に入ってから処理結果として出力されるまでの時間の平均が平均の待ち時間となります。
このような待ち行列の具体例としては、ファーストフード等の店舗で商品を注文するためにレジの前に並んだ顧客の注文に対応する処理を挙げることができます。
処理待ちの項目がランダムに到着する場合、平均の待ち時間は以下のようなリトルの法則で求めることができます。
ここで、処理の部分に「ソフトウェア開発（あるいはプロダクト開発）」を当てはめ、待ち行列を「要求の一覧」を当てはめると待ち行列でソフトウェア開発やプロダクト開発をモデル化できます。さらに、リーン開発で述べた「注文から価値の納品までに要する時間（サイクル時間）」は平均の待ち時間に相当します。以降の説明では、待ち行列を「要求の一覧」、処理を「チーム単位でのソフトウェア開発」として説明します。
リトルの法則からは、「平均の待ち時間」を短縮するためには「待ち行列の長さ」を短くしたり、「処理の平均スループット」を向上させればよいことが分かります。しかし、それらに加えて「平均の待ち時間」を短縮するために以下のような選択肢があります。
- 待ち行列の長さを短くする
- 処理の平均スループットを向上させる
- バッチサイズを小さくする
- 仕掛かり作業数を制限する
ここで、バッチサイズとは待ち行列中の 1 つの要求の大きさであり、仕掛かり作業数とは待ち行列の処理で並行に実行する作業の数のことです。
一般的に、開発チーム自身の正味の生産性（スループット）を大きく変えることは難しいので「平均の待ち時間」を短縮するための手段としては A, C, D が用いられます。
まず A については既に述べたようにリトルの法則から「平均の待ち時間」を減らす効果があることが分かります。
次に C の影響を説明します。バッチサイズが大きいと、その処理に要する時間は増えます。例えば、ウォーターフォール開発は「要求の大きな塊（＝バッチ）」が１つ入力される待ち行列としてモデル化できます。そのような場合には、バッチサイズが大きいためにそれらを開発し、納品するまでの待ち時間が長くなり、納品されたものが本当にニーズに合致しているかを確認するタイミングが遅れます。それに対して、アジャイル開発のように同じ要求を分割してバッチサイズを小さくすることで、それらを納品するまでの待ち時間を減らし、より速くフィードバックをことができます。つまり、バッチサイズを減らすことでより早くフィードバックを得ることができるのです。
最後に D の影響を説明します。仕掛かり作業数が多いと異なる作業間での切り替えのためのオーバーヘッドが生じるために同じ作業を順番に行うよりもサイクル時間が長くなります。そのため、納品までの待ち時間を短縮するためには仕掛かり作業の数に制限を設けることが有効です。このような制限は仕掛かり作業( WIP：Work In Process )の制限と呼ばれ、ソフトウェア開発におけるカンバンで積極的に活用されています。
3.2. 経済性
ハードウェアの製造工程とソフトウェアの比重が大きいプロダクトの開発は両方とも前述した待ち行列でモデル化することができます。しかし、それらの両者の待ち行列にはいくつかの違いがあります。以下がそのような違いの例です。
- 待ち行列中の項目が入れ替え可能か
- バラツキに対する考え方
前者は、「ハードウェアの製造工程では一般的に先入れ先出し(FIFO)で処理が行われる」のに対して「ソフトウェアの開発では開発する要求の順番を変更することが可能」という違いです。つまり、ソフトウェアの開発の場合には待ち行列中の要求の各々に対する期待されるビジネス上の恩恵を予測し、その予測に基づいて経済的により高い成果がより早く得られるように開発する要求の順番を変更することができるということです。さらに、プロダクト開発フローでは要求の順番を考える際に、「遅延のコスト ( CoD: Cost of Delay )」を考慮すべきだとしています。「遅延のコスト」は、プロダクトの価値の継時的な減少を意味します。
後者は、「ハードウェアの製造工程ではバラツキを減らすことを重視する」が「ソフトウェアではバラツキはプロダクトの差別化要素になりうるので、バラツキの排除だけを目指さない方がよい」ということです。プロダクト開発フローでは、前述したバッチサイズ等のバラツキだけではなく、世に先駆けて作るユニークな機能や自社で今まで使ったことが無い新たな開発技術やプラットホーム等の適用などもバラツキと位置付けています。後者のバラツキは、不確定性やリスクを伴いますが、それらの不確定性やリスクを管理しなければ競争力のあるプロダクトを作れません。そのような不確定性やリスクの管理方法としては、小さなステップで仮説が正しいかを検証したり、リスクの評価や対応を行い、それらの結果により軌道修正をすることが有効です。まとめると、小さなステップで仮説が正しいかを検証したり、リスクの評価や対応を行い、それらの結果により軌道修正をすることにより、世に先駆けて作るユニークな機能を開発したり、自社で今まで使ったことが無い新たな開発技術やプラットホーム等を適用しようということです。
3.2. 同期
次に、複数のチームで分担してプロダクトを作る場合の各チームの開発結果の統合について考えます。このような複数チームによる開発は図 2に示されるように複数の待ち行列が合流するものとしてモデル化できます。
このような場合に、各チームの開発結果を開発終盤でのみ統合するとしばしば以下のような2つのことが起きます。
- チーム毎のサイクル時間のバラツキが累積し、各チームが要求を開発し終えるまでの期間に大きなバラツキが生じる
- 一番遅れたチームの開発結果が得られた時点から各チームの開発結果を統合しはじめるが、問題が多数顕在化し、統合に時間がかかる
これらの結果として、プロダクトの評価のタイミングや市場への投入が遅れます。このような問題を解決する方法として有効なものは、チームの開発成果を開発終盤だけではなく、プロダクトの開発途上でチームの開発結果を統合するという方法です。そのためには、開発チームが一定の周期で開発結果を出し、それらの開発結果を統合する必要があります。プロダクト開発フローでは、一定の周期をリズム、開発途上でのチームの開発結果の統合を同期と呼びます。このようなバラツキの累積を減らし、統合時期の予見性を高めるためには一定のリズムで各チームが開発し、その開発結果を頻繁に同期することが有効だということです。
第 3 回の終わりに
今回は、プロダクト開発フローが以下のような2つの効果を狙い、そのために以下のような8つのテーマに沿った原則を提案していることを説明しました。
- 効果
- より良い経済性
- 異なるスキルの連携による戦略のより良い実現
- 原則のテーマ
- 経済性
- 待ち行列
- バラツキ
- バッチサイズ
- 仕掛かり作業(WIP)制限
- リズム、同期、フローの制御
- 早いフィードバック
- 分散された制御
次回以降の記事で、プロダクト開発フローの原則を具体化したSAFeの概要を説明したいと思います。
参考文献
- [1] SAFe日本語サイト, https://www.scaledagileframework.com/jp/
- [2] Dean Leffingwell, アジャイルソフトウェア要求―チーム、プログラム、企業のためのリーンな要求プラクティス, 翔泳社, 2014
- [3] Donald G. Reinertsen, The Principles of Product Development Flow―Second Generation Lean Product Development, Celeritas Publishing, 2009