Solution Context

コンテキストはキーである。そこからあらゆるのことに対する理解が生まれる。

- Kenneth Noland

ソリューションコンテキストの概要

ソリューションコンテキストでは、対象のソリューションが置かれる環境の重要な側面と、使用、インストール、運用、サポート、さらにはマーケティングやパッケージ化や販売に対する影響を明らかにする。価値を納品するにはソリューションコンテキストの理解が欠かせない。開発の優先順位や、システム能力、フィーチャー、非機能要求に影響があるし、DevOpsなどのソリューションレベルの職務にとって重要な点が決まるからである。

ソリューションコンテキストは、ソリューションを開発する組織の制御が及ばない要因によって決まることが多い。ソリューションとコンテキストとの結合度は、一般に、環境との相互作用(この相互作用は社内、サプライヤー、顧客の組織の境界をまたがることも多い)と柔軟性の間の微妙なバランスを取るという、アーキテクチャー上およびビジネス上の課題を表す。

詳細

システム構築者が自分自身のためにシステムを構築することはほとんどない。他の人々のためである。つまり、システム構築者は、通常、配置したり使用したりするコンテキストを制御することはできないし、よく理解していることもない。逆に、システムは開発されたのとは異なる環境に出荷され、そこで配置、インストール、保守される。社内ITシステムの場合ですら、新しく開発されたシステムは、通常、IT保守運用チームによって管理される。その本番環境は、多くの理由で開発環境とは異なる。どちらの場合でも、ソリューションの効果を上げるにはソリューションコンテキストを無視できない。これはプロセスにとってのリスクとなる。コンテキストの理解が必要になるからである。

価値のストリームソリューションおよびソリューション意図とソリューションコンテキストを理解し、その間の整合を取るには、顧客という利害関係者と常に対話し続ける必要がある。顧客はビジョンを理解し、ソリューションコンテキストについての必要な意思決定権を持っている。図1に示すように、協調が必須である。必要な協調の度合いは、ソリューションと環境との結合度によって大きく異なる。

Figure 1. Solution intent and solution context inform each other
図1. ソリューション意図とソリューションコンテキストは互いに情報をやり取りする

確実にこの連携を行えるよう、顧客はできるだけ頻繁にPI計画前/後ミーティングやソリューションデモに参加するべきである。また、顧客はソリューションを自分たちのコンテキストと定期的に統合する必要もある。この対話と統合の規則正しいリズムによって、正しい前提に基づいたソリューションインクリメントの構築が可能になり、顧客の環境内で結果の検証を行うことができる。どちらの側も、最善の経済的成果を得られるようコンテキストを適応させるための役割を担う(経済的枠組みを参照)。

ソリューション意図に対するソリューションコンテキストの影響

顧客のコンテキストをもとに、ソリューションの意図に記述される要求と制約の設計/実装に関する判断がなされる。このコンテキスト要求の多くは交渉の余地がなく、含めておかなければソリューションが使いものにならない。このような要求は、ソリューションの意図の「固定」の分類に入れられる。ソリューションコンテキストの多くの部分は、非機能要求(NFR)として現れる。これはソリューション インクリメントの完了の定義の一部に含める必要がある。

ソリューションコンテキストには、ソリューションの意図で対処しなければならない固有の内容が規定されることもある。複数のシステムからなる階層的なシステムでは、システムの意図も階層的な依存関係を持つ(ソリューションの意図の「複数のシステムからなるシステムの意図」のセクションを参照)。システムコンテキストには、顧客がシステムを使ってコンプライアンスや認証などの目標を満たすには、システム構築者のシステムの意図をどう組織化、パッケージ化、統合しなければならないかが定義される。

「固定」と「進化中」のソリューションコンテキスト

ソリューションコンテキストの一部は確立された顧客の環境であり、ソリューションをただ「そこにはめ込む」必要がある(「システムはこのように動いているのだから、ここにはめ込んでくれ」)。この場合、ソリューションコンテキストの要求はすべて、ソリューションの意図によってソリューションに押しつけられる。

しかし、多くの場合、新しいソリューションを導入するには顧客の配置環境を進化させる必要が生じる。そのとき、システム構築者はこれらの変更を管理するのに積極的な役割を果たす。システム環境と配置環境の両方を進化させて共通の状態にしなければならないからである。この場合、固定と変動に分けて検討し、複数の実現可能なソリューションコンテキストを用意して選択肢を維持することが(ソリューションの意図の「変動のソリューション意図から固定のソリューション意図への移行」のセクションを参照)、リスクを管理するのに役立つ。単純に言うと、変動が大きく進化するソリューションコンテキストほど、継続的な協調が必要になる。

ソリューションコンテキストの種類

システム構築者は、ソリューションコンテキストを使って、システムをどうパッケージ化し、最終的な運用環境にどう配置するかを理解する。ソリューションコンテキストの例として、次のようなものが考えられる。

  • 複数システムからなるシステム(航空機の一部として含まれるアビオニクスシステムなど)、プロダクトスイート(オフィススイートの一部として含まれるワードプロセッサなど)
  • IT配置環境(ソリューションを配置する先のクラウド環境など)

他のコンテキストも考えられるし、それらが組み合わさることもあ

複数のシステムからなるシステムのソリューションコンテキスト

複数のシステムからなる大規模なシステムにおいて、ソリューションサプライヤーと顧客との関係は独特であり、図2に示すように滝のように連なっている。

Figure 2. Solution Contexts Wrap in System of Systems
図2. 複数のシステムからなるシステムにおけるソリューションコンテキスト

サプライチェーン内の各組織は、作成したソリューションを顧客のコンテキストに納品する(ソリューションのパッケージ化、配置、統合の方法はそのコンテキストによって決まっている)。受け取った顧客はさらに、自分の顧客のコンテキストにソリューションを提供する。その繰り返しである。たとえば図2の例では、カーナビシステムのサプライヤーは、まず情報娯楽サプライヤーのコンテキストで、次に自動車メーカーのコンテキストで、最終的には消費者のコンテキストで働く。これらのコンテキストすべてがソリューションの実現性に影響するため、システム構築者は価値チェーンの最初から最後まで全体を知っておく必要がある。

IT配置環境のソリューションコンテキスト

社内向けのソフトウェアソリューションを開発するなら顧客も社内の人であるかもしれないが、ソリューションを本番環境に納品するにはやはりコンテキストが必要である。配置時には、図3に示すように、特有のインタフェース、配置されているOS、ファイアウォール、他のアプリケーションのAPI、ホストを用意するかクラウドインフラを使用するか、などを考慮しなければならない。

図3. 社内向けIT配置のソリューションコンテキスト

この例では、新規CRMシステムには、必要なインタフェースを反映するほか、アプリケーションをどうパッケージ化し、最終環境にどうリリースし、どこで動かし、どう管理するかを反映する必要がある。

ソリューションコンテキストにはポートフォリオレベルの検討事項が含まれる

最後にもう1点考慮しなければならないことがある。一般に、システム構築者の大きな目標を達成するには、企業のプロダクトやサービスを連携させなければならない。つまり、ほとんどのソリューションは、単独で動作するのではなく、ポートフォリオレベルにも関係する。そのため、(通常はポートフォリオエピックという形で)新たに生じてくる取り組みによっても、ソリューションの意図が変化し、ソリューションの開発や配置も影響を受ける

社内に置かれて稼働するシステムでは、多くの場合、他のソリューションとの相互運用性も必要になり、ソリューションコンテキストがさらに拡大する。たとえば、大きな運用の価値のストリーム(価値のストリームのページを参照)では、たいてい、複数の開発の価値のストリームで作成されたソリューションを使用する。その様子を図4に示す。

図4. 複数のソリューションが協調して運用の価値のストリーム全体をサポートする

このような従属的ソリューションが互いに協調、統合して、運用の価値のストリームに対してシームレスなエンドツーエンドのソリューションを提供する。

継続的に協調することで配置可能性を確保する

ソリューションがそのコンテキストで正しく動作することを保証するには、継続的なフィードバックが欠かせない。ソリューション構築者には、作成したソリューションが配置先の環境で正しく動くかどうかのフィードバックが必要である(DevOps)を参照)。リズムベースの開発では、複数のシステムからなるシステムの価値のストリーム全体を頻繁に統合して、最上位のコンテキストで確約されたマイルストーンリリースに向けての進捗をデモする。次のような協調を継続的に行うことで、最終的な顧客のコンテキストにソリューションを確実に配置できるようになる。

結果として、システム構築者と顧客組織内のさまざまな役割との間に、協調が必要な箇所が数多く生じる。SAFeのいくつかの役割は、顧客側の対応する役割の人と一緒に、その責任を負う。その様子を図5に示す。

Figure 5. System builder role collaboration with Customer roles
図5. システム構築者側の役割と顧客側の役割の協調

このように顧客とシステム構築者が効果的に協調することで、システムが顧客のニーズを顧客のコンテキストで満たすことを保証できる。


Last update: 4 November 2015