ソリューションおよびシステムアーキテクト/エンジニアリング

工学は素晴らしい職業だ。想像の産物が、科学の助けを得て、紙の上の計画として現れる。それから、石や金属やエネルギーで実現される。それが人の住む家へ持ち帰られる。すると、生活水準が上がり、生活が快適になる。その過程を見守る喜びこそが技師の大きな特権である。

─ハーバート・フーヴァー(1874-1964)

システムおよびソリューションアーキテクト/エンジニアリングの概要

SAFeのシステムおよびソリューション「アーキテクト/エンジニアリング」のアイコンは、それぞれシステムとソリューションの、アーキテクチャーおよびエンジニアリング設計全体の技術面に責任を持つ、個人またはチームを表す。

アーキテクト/エンジニアリングは、ソリューション開発を本当の意味で「システム的な目で見る」、分野横断的なチームである。高いレベルの機能要求および非機能要求の定義に参加し、技術的トレードオフを分析し、主要なコンポーネントとサブシステムを決定し、それらの間のインタフェースとコラボレーションを定義する。ソリューションコンテキストを理解し、チーム、顧客、サプライヤーと協力して顧客の環境における使用適合性を確保する。

アーキテクト/エンジニアリングは、ソリューション管理およびプロダクト管理と協力して、使命、ビジョン、ロードマップを達成できるよう技術的に共通の方向へチームの足並みを揃えるという、重要な役割を果たす。

当然ながら、大規模ソリューション開発の複雑さを理解したリーン-アジャイルなリーダーであり、リーンおよびアジャイルのプラクティスを適用して複雑さに対処する。

詳細

アーキテクト/エンジニアリングは、開発中のソリューションの共通の技術およびアーキテクチャーのビジョンに向けて、価値のストリームおよびアジャイルリリース列車の足並みを揃える。システムとサブシステムの定義に参加し、技術面の想定事項を検証し、代替案を評価する。ソリューションの技術面やアーキテクチャー面を広い視野で見たビューを提供し、伝え、進化させることで、ソリューション開発をサポートする。

アーキテクト/エンジニアリングチームは、プログラムレベル価値のストリームレベルの両方に存在する。システムアーキテクト/エンジニアリングは、主にアジャイルリリース列車のコンテキストで仕事をする。アジャイルチームと協力して、そのARTが担当するサブシステムやシステム能力の部分に関して技術的に補佐する。ソリューションアーキテクト/エンジニアリングチームは、ソリューション全体のアーキテクチャーシステム能力を進化させるための技術的指導を行う。

どちらも、技術インフラを定義してコンポーネントやサブシステムに分解し、サブシステム間およびソリューションとソリューションコンテキストの間のインタフェースを定義できるよう、ビジネスの利害関係者、チーム、顧客サプライヤー、サードパーティ利害関係者と緊密に協力する必要がある。

ソリューションアーキテクチャーの全体像を提示すると同時に、価値を実装する人に権限を委譲してローカルでの意思決定を任せることで、価値のフローを加速し経済効果を向上する。

責任

アーキテクトおよびシステムエンジニアリングチームはリーン-アジャイルなリーダーであり、通常は以下の責任を負う。

SAFeの役割の原点

システムアーキテクトの役割

アーキテクトという役割は、ソフトウェア開発では一般的であり、SAFeでもプログラムレベルとポートフォリオレベルの欠かせない役割の1つとして含められている。また、アーキテクトという役割は、多くの場合、ソフトウェアの領域にとどまらず、技術的に多様でさまざまなプラットフォームを対象とするマルチドメインのソリューション環境で価値納品を可能にするという責任も負わされる。そのため、SAFeではこの役割をきわめて広い視点でとらえている。

システムエンジニアリングの役割

しかし、サイバーフィジカルシステムを構築している企業には、システムエンジニアリング(ソリューション開発のシステムエンジニアリング部分を実施する人のグループ)も必要である。このチームは、通常、ソフトウェア要素だけではなく、ハードウェア、電気/電子、機械、水力、光学など複数の分野や、複雑なソリューションのその他の側面を網羅する。INCOSE[1]ではシステムエンジニアリングを次のように定義している。

「…システムの成功を実現するための複数の分野にまたがるアプローチ/手段。開発サイクルの早期に顧客のニーズと必要な機能を定義し、要求を文書化し、その後、運用、パフォーマンス、テスト、製造、コストとスケジュール、トレーニングとサポート、廃棄など、あらゆる問題を考慮しながら設計の合成とシステム検証を進める。システムエンジニアリングは、すべての分野および専門技能のグループを統合して1つのチーム作業にまとめ、概念から生産、運用へと進む構造化された開発プロセスを形成する。また、ユーザーのニーズを満たす質の高いプロダクトを提供するという目的を念頭に置いて、すべての顧客のビジネスと技術両方のニーズを考慮する。」

さらにリーンなアプローチ

ソフトウェアアーキテクチャーおよびシステムエンジニアリングの役割を抜きにして、複雑なソリューションの構築方法を語るのは、明らかに不可能である。ただし、当然ながら、重要な注意点がある。両方でよく使われている従来型の手法は、フェーズゲート、「ぴったりの」ソリューション、BUFD(大量に事前に設計する)のようなアプローチに強く引き寄せられている。これは、a)大きなシステムなので構築にどう取り組むべきかを誰かが知っていなければならないこと、b)ステージゲートのウォーターフォールモデルは当時利用できた最善のモデルであったことを考えると、無理もないことである。

ただし、「SAFeのリーン-アジャイルの原則」で詳しく説明しているように、このアプローチではプロダクト開発フローをサポートできず、最善の経済的成果が得られない。SAFeでは、ソフトウェアアーキテクチャーおよびシステムエンジニアリングを、継続的なプロダクト開発フローを可能にする職務だと捉えている。リーン-アジャイルの考え方において、これらの職務が重点的に取り組むのは、分野横断的に頻繁に協力すること、素早いフィードバックに基づいた学習サイクルによってインクリメンタルにシステムを構築すること、プロダクト開発プロセスにつきものの変動を理解し利用すること、制御を分散することである。

意思決定を分散する

設計の意思決定は、影響力、緊急性、発生頻度がそれぞれ大きく異なる。つまり、意思決定を中央集権化するか分散するかを、バランスを取りながら組み合わせなければならない(SAFeの第9原則)。「意思決定を分散する」という基本ルールは、緊急性が低く、影響が長期にわたり、スケールメリットが大きい意思決定のみを中央集権化することを意味する。その他はすべて分散する。

これは、システム設計においては次のことを意味する。

  • 一部の規模の大きいアーキテクチャーに関する意思決定は中央集権化するべきである。これには、主要なシステム意図・サブシステム・インタフェースの定義、サブシステムへの機能の割り当て、共通プラットフォームの選択、ソリューションレベルの非機能要求の定義、重複の排除などが含まれる。
  • しかし、それ以外、つまりほとんどの設計上の意思決定は、アジャイルチームへと委譲される。このバランスは、創発的設計とインテンショナルアーキテクチャーのプラクティスを組み合わせて適用することで達成できる(アジャイルアーキテクチャーを参照)。

これをサポートするために、頻繁な協調(非公式で継続的に直接会って議論する形でもよいし、もっと定期的にPI計画で行ってもよい)、システムデモとソリューションデモ、検査と適応のワークショップ、仕様ワークショップを実施する。

どの場合でも、アーキテクト/エンジニアリングは、リーン-アジャイルなリーダーの特徴を発揮し、次のようなことを行う。

  1. 意思決定において、エンジニアや対象分野の専門家と協力し、権限を与える。
  2. 設計関連の分野でチームメンバーを教育し、技術の専門技能コミュニティーを指導する。
  3. リーン-アジャイルの原則をシステム設計へ適用する模範を示す。

経験に基づくアプローチ

さらに、ソリューション開発プログラムを成功させられるかどうかは、経験に基づく証拠から学んだ事柄を組織が受け入れられるかどうかにかかっている。このパラダイムは、論理的に判断したけれども検証されていない仮説と実装戦略に基づいて作成された詳細な設計を早期に確約するという、従来の考え方に反する可能性がある。その場合、設計に反する証拠が現れると、設計の担当者はそれを個人的な侮辱とみなし、証拠ではなく設計を擁護する傾向を見せることがある。

リーン-アジャイルのアーキテクト/エンジニアリングの考え方は、設計に問題があるのなら、それは設計の問題であり、その設計を作成した人の問題ではない、という固い信念に基づいている。これから何を新しく学習するかを予想できる人はいない。結局は研究開発なのだから。誰もが一緒に学習する。この信念は、次のようなことでさらに育成することができる。

  • 事実をベースとしたガバナンス。頻繁に統合し客観的な証拠を得ることで、この事実を取り出すことができる。
  • セットベースのエンジニアリング。1つのアイデアを早期に選択するのではなく、問題を解決しうる多様なソリューションを検討する。
  • 学習マイルストーン。技術とビジネス両方の仮設を検証することを具体的な目的として、計画し実施する。
  • 経済的意思決定の重視。システムアーキテクチャーのシステム能力と経済的成果の間のトレードオフを、ビジネスの利害関係者と協力して継続的に行う。

さらに知りたい場合

[1] International Council on Systems Engineering.What Is Systems Engineering? http://www.incose.org/AboutSE/WhatIsSE.

[2] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011.(邦訳:(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014))

Last update:2 November 2015