セットベースの設計

品質は、作品がそれ自体の中に代案を取り込み、使いこなす深さによって決まる。─テオドール・アドルノ
バラツキを認め、複数の選択肢を残す─SAFeの第3原則

セットベースの設計の概要

システム開発は、未確定事項を減らして知識へと変換し続けるプロセスであるといえる。最初にシステムをどれだけうまく定義し設計したとしても、実際の顧客のニーズや技術の選択はどちらも未確定なので、システムをどう実装する必要があるかの認識は、現実を反映して変えていかなければならない。

ポイントベースの設計(具体的で詳細な要求およびシステム設計をプロセスの早い段階で確約するというプロセス)では、システム開発者は、その後に得られる経験に基づいたデータを利用することができない。そのデータはシステム開発が進まないと手に入らないからである。選択した設計がうまく機能しないと気付くのがプロセスのずっと遅い時点まで遅れるため、すんなりと正常な状態に戻すのは不可能である。

セットベースの設計とは、開発サイクルの中でもっと長い期間、要求や設計の複数の選択肢を残すというプラクティスである。締め切りが近づいてきてから、経験に基づくデータを使用して、最終的な設計の選択肢を絞り込む。この方法では、遅くまでバラツキを認め、複数の選択肢を残すことができるため、最終的に選んだものに早くから拘束されることなく、最大限に柔軟なアプローチを取ることができる。

詳細

ポイントベースの設計では、一連の要求と1つの設計戦略をプロセスの初期に確約する。その結果、たいていは後になって締め切りが迫ってから多大な再作業が必要になる発見がなされ、やっつけ仕事で対処したり、品質を妥協したり、酷い場合にはプログラムの確約や締め切りを守れないことになる。これは、従来の線形(ウォーターフォール)の要求→設計→実装→テストというアプローチでシステムを開発するときの大きな問題の1つであり、そのプロセスで常に費用やスケジュールが超過している主な理由の1つでもある。

セットベースの設計(SBD)では、開発サイクルの中で長い期間、設計の選択肢を複数残しておく。セットベースの設計は、リーンプロダクト開発で経済効率を向上するための重要なプラクティスであり、参考文献[1]および[2]で詳しく説明されている。図1は、セットベースとポイントベースの設計方法の概念的な違いを示したものである。

図1.  ポイントベースの設計では事前に設計を確約する。 セットベースの設計では複数の選択肢を長い期間残す。

セットベースの設計と固定スケジュールのプログラム

セットベースの設計は、固定されたスケジュールを確実に守らなければならないプログラムでは特に効果的である。結局のところ、スケジュールは動かせないのだから、複数の設計の選択肢を用意しておくのは当然である。これは比較的信頼性の高いいくつかの設計の選択肢が、必ずしもシステム開発者が望むレベルの革新やパフォーマンス向上につながらない場合でも、同じである。しかし、締め切りがどうしても動かせない場合、チームはスケジュール内でできる限りのことをしなければならない。

セットベースの設計で経済効率を達成する

もちろん、複数の設計の選択肢を維持するにもコストがかかる。これは複数の選択肢を開発・保守するためのコストで、そのほとんどがモデルや紙ベースのものであっても必要になる。(注:Reinertsen[3]は、複数の設計の選択肢を維持することに関しても最適化のU字曲線を作成することができ、曲線上の最適な数値が1になることもあると指摘している。)しかし、革新や変動の度合いが高い場合や、締め切りが動かせない場合(「この穀物用コンバインは1月に工場から出荷しなければならない」)には、セットベースの設計が最善の方法となる。この場合、設計効率は次のようないくつかの要因で決まる。

  • 柔軟性─幅広い設計の選択肢をできるだけ長く残す。
  • コスト─モデリング、シミュレーション、プロトタイプ作成によって複数の選択肢を残すコストを最小限に抑える。
  • 速度─設計の代替案を早期から頻繁に検証することで学習を促進する。

この効率を達成するためのいくつかの推奨プラクティスを以下で紹介する。

設計ではなくインタフェースと要求を仕様化する

複雑なシステムはサブシステムとコンポーネント要素から構築され、それらが協調してシステムの結果を作り出す。要素の結合度のレベルはさまざまだが、要素が結果をどうやって達成するかではなく、パフォーマンス要求とインタフェースを仕様化する方が、設計の柔軟性を向上できる。このように関心事を高いレベルに抽象化することで、設計の選択肢の幅が広がる。1つの要素をさまざまに設計したそれぞれが、既定のインタフェースを満たせる可能性があるからである。

たとえば、あるチームが、既存のモデルよりもずっと高いパフォーマンスの要求される、新しいCNC旋盤を開発しているとする。動作速度を向上させるための仕様が、特定のコンポーネントに影響を与える。設計の選択肢として、アナログサーボ制御モーターやステッピングモーターが挙がるだろう。ステッピングモーターなら、製造コストは下げられるが、パフォーマンス要求を満たせないかもしれない。設計プロセスのある程度の期間、両方の選択肢を維持することで、正しい経済的トレードオフを行うことができる。

さらに、インタフェースを指定すると、素早い統合された学習サイクルでインクリメンタルに構築しやすくなる。旋盤の例では、インタフェースの合意が取れると、それぞれの種類のコンポーネントを付けた冶具を使い、設計の他の要素は変えずに、プロトタイプ旋盤をテストすることができる。

モデリング、シミュレーション、プロトタイプ作成

モデリング、シミュレーション、プロトタイプ作成のプロセスによって、経験に基づくシステム検証を早期に行うことができる。また、これらは、一部の設計の選択肢を排除し、他のものを検証するための、早期の学習ポイントにもなる。モデルベースシステムエンジニアリングは、規律ある、包括的で厳密な、モデリング方法である。これらの手法をシステムのもっともリスクの高そうな部分に適用する。それによって、長い期間、設計の選択肢を維持するためのコストを、大幅に減らすことができる。

頻繁な統合ポイント

開発期間のうち、新しい設計が行われている間は、未確定事項が多く、本当の知識は少ない。未確定事項を解決する唯一の方法は、システムコンポーネントを早期から頻繁に統合して設計をテストすることである。SAFeにおけるその統合ポイントの一部は、2週間固定のリズムで実施されるシステムデモと、通常はもっと長いプログラムインクリメント(PI)のリズムで実施されるソリューションデモに合わせて行われる。実際、このように頻繁に統合しなければ、SBDプラクティスの結果として間違った安心感が芽生えてしまい、リスクを増大させることになりかねない。必要なパフォーマンス要求を実際に満たせるものが設計案の中にないかもしれないからである。頻繁な統合を行うことで、新しい知識から経験に基いて学習することが可能になり、システムが進化するのに伴って選択肢が減っていく。その様子を図2に示す。

図2.  頻繁な統合は設計の選択肢を絞り込む重要な学習ポイントとなる

システム開発の取り組みにサプライヤーが参加する場合には、頻繁なシステム統合はさらに重要になる。インタフェースを注意深く定義したとしても、統合をたまにしかしなければ、予想外のことを発見するのが遅れ、時間やリソースが足りず間近に迫った締め切りまでに対応できないことになりがちである。

適応型の計画策定

明示的かつ定期的に行われる計画ミーティングは、さまざまな設計の選択肢を評価し、セットベース思考を直接サポートする機会となる。PI計画では、PIの全体的な意図を定義し、検討対象の設計の選択肢に適用される制約と要求を調整する。反復計画はもっと戦術的な役割であり、価値のインクリメントを頻繁に統合してレビューすることにより学習が進むと、それに合わせてチームがPI実行内で調整を行うことができる。

セットベースの設計の経済的トレードオフ

設計の選択肢ごとに経済的な意味合いが異なるため、セットベースの設計を理解するには、システムのマクロ経済的な目標と利点を理解する必要がある。これを検討する1つの方法は、選択肢をスペクトル上に並べ、そこで特定の「重み」を各選択肢に関連付ける方法である。

経済的に重要な指標には、開発コスト、製造コスト、パフォーマンスと信頼性、サポートのコスト、開発時間、技術的リスクなどがある。そのような指標を使用すると、どの設計の選択肢を使用すると利益が大きくなるかを明らかにしやすい。たとえば先ほどの旋盤の例では、さまざまな種類やブランドのモーターの正確さと、製造のコストとのトレードオフによって、図3に示すように大きな違いが生まれる。

図3.  経済指標(コスト)とパフォーマンス要求(許容誤差)のトレードオフ曲線は、セットベースの設計の選択肢から選択するための指針となる

まとめると、具体的で詳細な設計に対して事前に確約しても、経験に基づく証拠が表れたときにそれが生き残ることはほとんどない。経済的トレードオフを正しく理解していると、広い目でシステムを見る適応型のアプローチとしてセットベースの設計を使用でき、経済的に優れた選択を行ったり既存の制約にうまく適応したりすることが可能になる。


 

Learn More

[1] Ward, Allen, and Durward Sobek.Lean Process and Product Development.Second edition.Lean Enterprise Institute, Inc., 2014.

[2] Oosterwal, Dantar.The Lean Machine.Amacom, 2010.

[3] Reinertsen, Don.Principles of Product Development Flow.Celeritas Publishing, 2009.

 

 

Last update:11 November 2015