Solution Intent

バラツキを認め、複数の選択肢を保つ

– SAFe原則の第3原則

ソリューションの意図の概要

大規模ソフトウェアやサイバーフィジカルシステムの構築は、今日の業界においてもっとも複雑で困難な試みである。システム構築者は、「構築中のこれは厳密に何なのか」や「どのように構築するのか」を常に確認しておかなければならない。どちらの問いに関しても、十分でタイミングのよい知識と意思決定が必要である。さらに、この2つの問いは互いに関連している。経済的/技術的に実現可能な方法でどのように構築するかをシステム構築者が理解していないのであれば、何を構築するかをどのようにの視点で見直す必要があるかもしれない。たとえば、現在の技術、システム能力とチームの処理能力、顧客のコンテキストと必要な時間枠および経済的枠組みとの整合などである。

SAFeでは、この重要な知識プールをソリューションの意図と呼び、構築対象のソリューションに関する現在および今後進化していく要求、設計、意図(大きな枠組みでの目的)の基本認識として使用する。システム構築者はまた、システムの認識の一部はソリューションで行わなければならないか既に行ったことについての固定された交渉の余地のない要求であることと、別の一部は変動し、今後実際にどうであるかが判明したらさらに議論や調査を実施しなければならないことを分かっている。この違いを理解し舵を取ること、変動を許容してスケジュールの先の方まで進めるようにすることは、大規模ソリューション開発におけるアジャイルさを解き放つための鍵となる。
このページでは、もう1つ非常に重要な点についても取り上げる。これまで、クリティカルな大規模ソリューションの構築者はアジャイル手法を避けてきた。システム設計やドキュメントを明らかに軽く扱っているからである。リーン-アジャイル開発を世界最大級にクリティカルなシステムの構築に適用できるよう拡張する方法も、このページで扱う。

ソリューションの意図の詳細

失敗したときのコストが高すぎて受け入れられないようなシステムを構築している場合、システムの振る舞いをより厳密に定義し検証する必要があるため、アジャイルを導入するための障壁が大きくなる。多くの実務者はアジャイル宣言[1]の「包括的なドキュメントよりも動くソフトウェア」という価値の声明に共感しているが、これは両方を必要としている企業にとって矛盾する優先順位になりかねない。

複雑で信頼性の高いソリューションを作成するには、大量の技術情報が必要であり、作り出されもする。ソリューションの意図された振る舞いは、この情報の多くに反映される。たとえば、フィーチャーとシステム能力ストーリー非機能要求、システムアーキテクチャー、ドメインレベルのモデルと設計(電気的、機械的なものなど)、インタフェース、顧客による仕様、テストとテスト結果、追跡可能性などである。その他の関連情報として、システムについての重要な意思決定や調査結果なども記録される。これには、業界調査の情報や、実験の結果、設計判断の根拠などが含まれる。多くの場合、必要があるまたは規則で決まっているなどの理由で、この情報を公式文書に含めなければならない。

ソリューションの意図について

ソリューションの意図は、システム構築者が何を構築しているか、どのように構築するかを格納、管理、伝達するための、非常に重要な知識リポジトリである。これは以下のようなさまざまな目的に役立つ。

  • ソリューションの意図された振る舞いと実際の振る舞いの両方についての真実が含まれた唯一の情報源となる。
  • 要求、設計、システムアーキテクチャーについての意思決定を記録し伝達する。
  • 今後の調査や分析の作業をやりやすくする。
  • 顧客とシステム構築者とサプライヤーを共通の目的に向けて連携させる。
  • コンプライアンスや契約上の義務をサポートする。

図1には、ソリューションの意図の複合的な性質が表れている。

  • 現在と将来の状態。複雑なシステムの構築者は、常に2つのことを知っておく必要がある。現在のシステムが今厳密に何を行っているかと、将来の状態に向けてどのような変更を行おうとしているかの2つである。
  • 仕様と設計とテスト。現在と将来の両方の状態に関する知識は、ソリューション構築者に都合のいいものであればどのような形式で記録しても構わないが、そこには、仕様(システムの振る舞いを文書として定義したもの)、設計、テストという3つの主要要素が含まれる。

人命にかかわるシステムや、ミッションクリティカルなシステム、ドキュメントの規制基準が適用されているシステムなどを構築する場合、システムが意図したとおりに動くことを保証するには、追跡可能性という手段が役立つ。追跡可能性によって、ソリューションの意図の要素どうしが、また、ソリューションの意図と完全なシステムの振る舞いを実現するシステムコンポーネントとが結び付けられる。(注:リーン-アジャイル開発で高保証システムを構築する方法の詳細は、ガイダンスのページのホワイトペーパー『Agile Development in High-Assurance and Regulated Environments』(高保証規制環境でのアジャイル開発)を参照のこと。)図1にこの概念を示す。

 

Figure 1. Anatomy of Solution Intent
図1. ソリューションの意図の構造

 

ソリューションの意図の具体的な要素は、文書やスプレッドシートやホワイトボードセッションから公式の要求、モデリングツールまで、さまざまな形式で実現できる(これについては モデルベースシステムエンジニアリングで説明している)。しかし、ソリューションの意図はソリューションを構築するという目的に対する手段でしかないため、ソリューションの意図を記述する方法は、十分なものでなければならないが、不必要なオーバーヘッドや無駄が生じてはならない(後の十分性についてのセクションを参照)。

ソリューションの意図の動的な性質

従来、ソリューションの意図の代わりとなっていたのは、主に、固定された一連の要求であり、これは、顧客によって事前に定義されて多くの場合ソリューション構築者に押しつけられるか、システム構築者が定義していた。実際、「要求」という用語自体がウォーターフォール的な思考を暗示しており、要求はすべて事前に識別する必要があるという前提が含まれている。

SAFeの第3原則 – バラツキを認め、複数の選択肢を残すでは、要求や設計を事前にしっかりと定義しすぎると結果的に成功する確率が落ちるという証拠について述べている。

そのため、別のアプローチ、つまり既知の事柄を理解できるようサポートし、未知の事柄は開発途中で現れてくることを許容するというアプローチが必要である。つまり、ソリューションの意図は、作成したきりずっと凍結させておく記述ではなく、開発プロセス全体をサポートし、その過程で進化していくものでなければならない。その様子を図2に示す。

Figure 1. Solution intent evolves with, and supports, all the steps in solution development
図2. ソリューションの意図はソリューション開発のすべてのステップをサポートしつつ進化する

固定と変動のソリューションの意図

先に述べたように、システム構築者はさまざまな目的でソリューションの意図を使用する。しかし、そのどれも、「一点だけを見たソリューション」の仕様を事前に完全に作り上げる理由にはならない。そのように早期に意思決定をしてしまうと、経済的に優れた代替案の調査が制限されるし、無駄や再作業につながることも多い[2]。これに対処するため、SAFeでは固定と変動というソリューションの意図の2つの要素について記述し、一般に適用可能な、最適な経済的利点を生み出す要求/設計哲学をサポートしている。

固定の意図は既知の事柄を表す。交渉の余地がないものの場合もあれば、開発途中で現れたものの場合もある。例を挙げると、パフォーマンス仕様(「ペースメーカーの波形は次のようでなければならない」など)や、標準準拠の必要性(「PCI準拠クレジットカードのすべての要件を満たすこと」)、ソリューションの特徴となる中核システム能力(「バハアドベンチャーライドは定員大人4名である」)などがある。

変動の意図は、ニーズを満たすことができる要求や設計の代替案について、システム構築者が経済的トレードオフを自由に調査できる要素を表す。それが確立すると、新しい知識はいずれ固定された要求となる(「ライドの車両の乗客最大積載量は400kgである」など)。その場合でも、変更の余地はできるだけ長く残しておくべきである(「現在の設計では350kgをサポートしている。顧客と検討したい。」など)。

ソリューションの意図の作成

システム知識を作り上げるための、SAFeのリーン-アジャイルな方法は、従来のウォーターフォールの方法とは異なっている。図3に、創発的な方法でソリューションの意図を作成する際の成果物とプロセスを示す。

図3. ソリューションの意図の作成

ソリューションの意図は、意図するソリューションの目的と主要システム能力を高いレベルで記述したビジョンと、非常に重要な非機能要求から始まる。この知識と、後で作成されるロードマップおよび重要なマイルストーンは、チームが最初のPI計画を立ててそれを実行するための十分な指針となり得る。フィーチャーと、システム能力、ストーリーイネイブラーを使って、ソリューションの振る舞いをさらに詳しく定義し実現する。

複雑であったり規制の厳しい環境では、ソリューションの意図のドキュメントに十分な投資をする必要がある。コンプライアンス上のニーズから、標準に基づいた仕様やその他の技術仕様を作成する必要があるかもしれない。調査や意思決定の結果を記録しなければならないこともある。承認済みの要求にソリューションが沿っているかを分析し、有効であることを確認し、デモを行うことができるよう、追跡可能性が必須になっている場合もある。この場合、ソリューションの意図の一部の要素は公式文書として作成される。リーンの考え方では、このドキュメントは、事前の指示書というよりも、結果をまとめて編集したものである。

ソリューションの意図に基づいた協調

プロダクトおよびソリューション管理は、通常はソリューションアーキテクトおよびシステムエンジニアリングチームや顧客と協力して、システムの分解、インタフェース、さまざまなサブシステムやシステム能力への要求の割り当てなど、最上位のシステム全体にかかわる意思決定を行う責任を持つことが多い。また、ソリューションエンジニアも、ソリューションの意図の組織構造を確立し、さらには分析やコンプライアンスのニーズをサポートできるようさまざまな種類の情報をどこで管理するかを決めることがある。

ソリューションの意図は価値のストリームレベルで記述されるが、そのシステム能力やサブシステムを作成してソリューションの意図に大きな貢献をするのはARTである。図4に、顧客、プロダクトおよびソリューション管理、ARTが協力してソリューションの意図を実現していく様子を示す。ここでは、プログラムと価値のストリームのバックログを操作することで、今後の振る舞いをARTという構成要素に割り当てている。

Figure 4. The collaboration that develops system intent
図4. ソリューションの意図を開発する協調体制

ソリューション管理やソリューションアーキテクト/エンジニアリングは、多くの場合、一部のソリューション意図の要求を、ソリューションのシステム能力やサブシステムを構築するARTに直接委譲する。ARTからも、ソリューションレベルの意思決定に対してフィードバックを返したり、ソリューションエンジニアに問題やアイデアを知らせたりする。そしてさらに、顧客の ソリューションコンテキストがソリューションの意図に重大な影響を及ぼす。

変動のソリューション意図から固定のソリューション意図への移行

ソリューションを構築して配置するには、多くの場合、システム構築者はいずれ、システムが正確に何をするかを知り、厳密にそれだけを行っていることを検証する必要がある。つまり、最終的な構築の時点では、要求はすべて固定されていなければならない。変動から固定へ移行するプロセスでは、選択肢を調査し、経済的枠組みの中で可能な限り長く変更の余地を残す。このとき、セットベース設計のプラクティスとイネイブラーが役立つ。どちらも未確定事項を解決し、リスクを軽減することを意図したものである。また同時に、各チームは現在の理解をもとにシステムを構築する。そして知識が増えるに従って新しいフィーチャーを実装する。この様子を図5に示す。

Figure 4. Moving from variable to fixed solution intent
図5. 変動のソリューション意図から固定のソリューション意図への移行

固定の知識はゼロから始まるわけではない。図5の左端の時点でさえ多くのことが分かっている。システム構築者がシステムを構築するのはそのための専門技術があるからであり、これまでのシステムの要素を再利用することができる。その後、開発の過程で、反復やプログラムインクリメントソリューションデモによってシステムに何ができるかが示されると、より多くの事柄が既知になる。このようにして、変動の意図が徐々に固定になり、システムが何を行うか、何を行う必要があるかについての確かな知識が現れる。

複数のシステムからなるシステムの意図

システムのソリューションの意図は必ずしも独立しているとは限らない。多くのソリューションは、複数のシステムからなる上位システムの一部に含まれるシステムである。その場合、他のシステムやサプライヤーからシステム構築者に、独自の知識や開発を加速させるソリューション要素がもたらされる。たとえばサプライヤーは、彼らの担当するサブシステムやシステム能力について、別個の独立した要求や設計やその他の仕様を持っていることが多い。サプライヤーの視点から見ると、それが彼らのソリューションの意図である。そのため、最終的な(最上位の)ソリューションの意図には、決定内容を伝えたり、調査を促進したり、構築者を連携させたり、コンプライアンスをサポートしたりするために必要な、関連サプライヤーの知識や情報が含まれる。その結果、図6に示すように、システム階層を上下に移動する要求や設計の意思決定の連鎖ができあがる。

Figure 5. Solution Intent Hierarchy
図6. ソリューションの意図の階層構造

最小限かつ十分なドキュメント

ソリューションの意図は、目的に対する手段、つまり、システム構築者を導き、決定内容を伝達し、コンプライアンスをデモするための手段である。ソリューションの意図の内容、組織、ドキュメント戦略の計画は、まずこの目的を念頭に置いて開始する。しかし、多ければいいというものではない。リーン-アジャイルコミュニティーでは、要求、設計、アーキテクチャーのドキュメントに関して、軽量にしておくことを推奨している[5]。ベストプラクティスには次のようなものがある。

ドキュメントよりもモデルを優先する。絶え間なく変化する環境では、ドキュメント中心の方法でソリューションの意図を整理し管理することは困難である。適切に使用すれば、モデルの方が、ソリューションの意図の管理を保守が容易な方法で行うことができる。これについてはモデルベースシステムエンジニアリングで詳しく説明する。

ソリューションの意図は協調である。革新を独占することはできないし、ソリューションの意図はプロダクト/ソリューション管理者やアーキテクトやエンジニアだけの領域ではない。多くのチームメンバーがソリューションの意図の情報の作成、フィードバック、洗練に参加する。

選択肢を残す。意思決定を局所的関心事に委ねる。意思決定はできるだけ遅くに行う。 適用型のアプローチで要求および設計を行う場合、経済的に実現可能である限りは見込みのある選択肢を残す。セットベース設計のプラクティスを使用すると、早すぎる段階で設計や要求を確約することを避けられる。

ドキュメントは1箇所にだけ置く。要求や設計の意思決定の記録は1箇所にだけ置いて、真実が含まれた唯一の情報源とし、全員が見られる記録のリポジトリとして使用する。

高いレベルを保つ。できるだけ抽象度の高いレベルで伝達する。必要以上に詳細にしない。受け入れ可能な振る舞いに幅を持たせる。ソリューションの振る舞いを具体性ではなく意図で記述する。要求と設計の意思決定権を非中央集権化する。

単純にしておく。必要なことだけを記録する。ソリューションの意図は、プロダクトを構築してコンプライアンスと契約上の義務を果たすという目的に対する手段である。少ない方がよい。


さらに知りたい場合

[1] アジャイル宣言 Agilemanifesto.org。

[2] Ward, Allen and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.(邦訳:トヨタが実践する価値創造の確かな進め方 リーン製品開発方式、日刊工業新聞社、2014)

[3] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[4] Leffingwell, Dean and Don Widrig. Managing Software Requirements: A Use Case Approach. Addison-Wesley, 2003.

[5] Ambler, Scott. “Agile Architecture: Strategies for Scaling Agile Development.” Agile Modeling, 2012. http://agilemodeling.com/essays/agileArchitecture.htm.

Last update: 10 December 2015