Iasa 日本支部 理事 塩田 宏治
CITA-A, TOGAF®, DASSM®, SAFe®5 SPC, CBAP®, PgMP®
アジャイルのアプローチが普及してきていることは、ITに関わる方であれば多くの方がご存知かと思います。ただアジャイルという言葉で紹介される内容が、１０人以下の１チームによるソフトウェア開発をどう迅速にデリバリーして価値を実現するのかという議論が中心となってきました。こうしたデリバリー中心の議論に対し、エンタープライズ視点から考えているエンタープライズ・アーキテクチャのコミュニティや、ビジネスの視点から考えているビジネスアナリシスのコミュニティなどでは、ビジネスまたは組織のアジリティが重要であるという視点から多くの議論がなされてきています。アジャイル・コミュニティにおいても、エンタープライズ・アジャイルの考え方が広がりつつあり、Disciplined Agile®やScaled Agile Framework (SAFe®)などのフレームワークが、徐々に日本においても関心を呼び始めています。こうしたエンタープライズ・アジャイルのフレームワークもビジネスアジリティを中心的なコンセプトに据えており、“アジャイル“の関心が、手段であるデリバリーから、目的であるビジネス（営利、非営利を問わない）にフォーカスを移しつつあることは意義あることだと考えられます。今回は、ビジネスアジリティという視点を踏まえ、ビジネスアーキテクチャとエンタープライズ・アジャイルの接点について考察したいと思います。
Iasaが提供しているBTABoK（ITABoK）は、エンタープライズ・アーキテクチャについて多くの知見を提供しており、ビジネスアーキテクチャも専門領域として解説されています。以下の図は、ビジネスアーキテクチャを深堀したBIZBOK®(Business Architecture Body of Knowledge)のモデルで、ビジネスアーキテクチャのコア要素を、ケイパビリティ、バリューストリーム、情報、組織と定義しています。コア要素も変化を伴いますが、例えばプロダクト、業務を実際に遂行するビジネスプロセス、施策であるイニシアチブやプロジェクト、さらには戦略と比べても、比較的安定したビジネスの構造として定義されています。
参照：https://en.wikipedia.org/wiki/Business_architecture
この４つの要素の中でも、非常に重要な役割を果たすのがケイパビリティです。ケイパビリティは、ビジネスが何をするか(What)を示すものであり、“特定の目的や結果を達成するために、企業が所有、交換できる特定の能力（ability）やキャパシティ（capacity）”とされています。ケイパビリティと等しく重要な要素であるバリューストリームは、“組織がステークホルダ、またはある一連のビジネス活動の状況におけるステークホルダに対して、どのように価値を達成するかを視覚的に示すもの”と定義されています。例えば、資材調達者というステークホルダに対し、資材が調達されるというバリュープロポジションを提供するために必要なEnd-to-Endのバリューストリーム・ステージの流れがデザインされます。情報や組織なども非常に重要ですが、本日はケイパビリティとバリューストリームを中心に扱うことにします。
バリューストリーム
エンタープライズ・アジャイルでもバリューストリームは重要なコンセプトとして登場し、エンタープライズ・アジャイルを導入するには、組織がどのようなバリューストリームで構成されているかということを発見するためのワークショップを行います。これは、機能組織単位ではなく、バリューストリーム単位に企業運営することが、ビジネスアジリティにつながると考えているからです。しかしながら、エンタープライズ・アジャイルのフレームワークはビジネスアジリティへのフォーカスを標ぼうしつつも、ソフトウェア・デリバリーに関する議論がまだまだ中心でDevelopment Valuestreamに焦点があたっており、Operational Valuestreamの議論は不十分です。組織としてのビジネスアジリティを達成するには、OperationもDevelopmentもどちらのバリューストリームもアジリティを実現する必要があります。
Operationalなバリューストリームにおけるビジネスアジリティに必要な考え方は、“ビジネスアジリティ・マニフェスト”(https://busagilitymanifesto.org/10-translations/23-bam-japanese)にも示されています。関心ある方はご覧いただければと思います。
ケイパビリティ
バリューストリームが“どのように”するかを示しているのに対し、ケイパビリティは“何”をするか、できるかを示しています。バリューストリームの中の各ステージは、ケイパビリティによって機能します。ケイパビリティは部門などの組織に依存せず、組織全体でユニークに定義されるべきものであり、バリューストリームや組織などを超えて呼び出されるものになります。例えば製品を調達するバリューストリームにおいて、“アカウントと協議する”=>“契約を受け取る”=>“適格性を検証する”=>“契約を最終化する”などのバリューストリーム・ステージが想定されます。一方、関連するケイパビリティとして、“契約管理”といったレベル１のケイパビリティの中に、“契約ニーズ決定”、“契約適格性決定”、“契約リスク決定”、“契約条項決定”、“契約価格決定”などのレベル２ケイパビリティが含まれることでしょう。“適格性を検証する”というバリューストリーム・ステージは、“契約適格性決定”および“契約リスク決定”という２つのケイパビリティが発揮されることによって初めて業務として適正に遂行されます。また逆に、“契約適格性決定”ケイパビリティは、“適格性を検証する”ステージだけでなく、“契約を受け取る”ステージを遂行する際にも、受け取る時点での初期検証をするタスクを実施するために必要となるケイパビリティでしょう。つまりビジネスを“賢く”遂行するためには、活動の順番が決まっているだけではだめであり、その活動を実行する能力が何であるかを議論する必要があることを意味しています。
このようなケイパビリティの考え方は、様々なフレームワークでも触れられています。TOGAF®ではCapability-based planningという考え方が強調されています。PMI®のプログラムマネジメント標準では、プロジェクトが生み出すものは所産（result）ですが、プログラムは能力（Ability）とベネフィットを生み出すことをマネジメントすると定義されています。プログラムレベルが、戦略やビジネスで実現したいこととITシステムなどのソリューションで実現することを、間でつなぎ整合を担保する重要な役割となっています。重要なことは、ビジネス戦略を実現するためには、どのようなソリューションが必要かをすぐに考えるのではなく、どのようなビジネスモデルやビジネスケイパビリティが必要かをまず定義する必要があるということです。ビジネス組織は、デジタルやITソリューションそのものが欲しいわけではなく、ビジネス組織が抱えるビジネス課題を解決したいと考えています。そのビジネス課題を解決できるかどうかを判断するには、ビジネスや業務レベルでどのような能力が必要となるかを考える必要があります。なぜならば、ITソリューションが、ビジネス組織が手に入れたいビジネスケイパビリティを100%実現できる場合は、ITソリューションがあたかもビジネス課題をダイレクトに解決するように見えますが、常にそうではありません。ITソリューションでは必要なケイパビリティが十分には獲得できない場合は、ビジネス組織はITではない別のビジネスソリューションも導入し、それによって手に入れたいビジネスケイパビリティ全体を実現するからです。私たちがビジネスの課題を解決しビジネスの価値を生み出すことに焦点を当てるのであれば、どのようなソリューションを提供するかだけを考えるのでは不十分なことが分かると思います。
こうして考えてくると、ケイパビリティとソリューションにおける機能との間に関係があることが認識できます。ソリューションを開発するエンジニアには、機能そのものだけでなく、その機能の“Why”を意味するどのようなケイパビリティを開発しようとしているのかを理解することが求められます。
従来のビジネスとITの関係は、ITはビジネスの写像またはビジネスのイネーブラーであるといった見方でした。これは、あたかもビジネス（例えば業務プロセス）とITシステムが別々にあり、ITシステムは業務プロセスを実行するための道具であるという見方です。そこから、業務プロセスや要求を考える人はビジネス組織の人で、ITシステムを作るのはIT部門の人という無意識の境界が生み出されています。こうした状況に対し、最近のビジネス環境の変化を受けて、ITがイネーブラーではなくビジネスそのものになってきたという言い方も時々耳にします。ITやデジタル技術を用いてソリューションを提供する人のミッションが、ソリューションを作ることではなく、顧客やビジネス組織の人と協働してビジネスを作りビジネスの問題解決を提供することだとするのであれば、技術でどのようなケイパビリティを作ることができ、ケイパビリティの集合としてのビジネスそのものの姿（モデル、アーキテクチャ）についての議論に、エンジニアも参加していく必要があることを意味しています。
一方エンタープライズ・アジャイルのフレームワークでは、ケイパビリティはどのように描かれているでしょうか。SAFe®を例にとれば、ポートフォリオレベルでイニシアチブに相当するエピックを定義し、Agile Release Trainというプログラムレベルのバーチャル組織でフィーチャーを主に扱い、チームレベルでユーザーストーリーを主に扱います。１つのAgile Release Trainでは扱えない大規模なソリューション・デリバリーを行うケースに対し、Large solution configurationという特定の全体像（Big Picture）が描かれており、そのレベルの粒度の要求をケイパビリティと呼び、エピックとフィーチャーの間のレベルとして位置づけられています（https://www.scaledagileframework.com/features-and-capabilities/）。SAFe®の中ではフィーチャーとケイパビリティはセットで説明されていることから、粒度は異なるが同様なものとして定義されていると解釈でき、定義としてはフィーチャーはステークホルダー・ニーズを満たすサービス、ケイパビリティはフィーチャーよりもハイレベルなソリューションの振舞いとされています。つまりSAFe®におけるケイパビリティはソリューションレベルの要求事項として議論されており、ビジネスケイパビリティという視点ではないと言えます。エンタープライズ・アジャイル・コミュニティにおいても、プロダクトマネジメント/プロダクトオーナーがステークホルダと協業して要求をディスカバリーする領域およびアーキテクチャ領域にさらに目を向け、よりビジネスの目線に立ちながらビジネスアナリシスやビジネスアーキテクチャ等の知識体系との融合を深めていくことが有効と考えます。
ビジネスアーキテクチャとエンタープライズ・アジャイル
アーキテクチャは、技術やソリューションといった実装レベルと比べると、比較的安定した構造を保ちます。アジャイルの強みが柔軟に迅速に環境変化に対応するといっても、やみくもに変更を部分最適に行っていては、ビジネスや組織全体として最適な状態は作れません。つまりアーキテクチャのマネジメントの上に、それぞれのアジャイル開発が動いていなければ、全体最適な形でビジネス価値を生み出せません。さらに、最適な形でビジネス価値を生むためには、ITのアーキテクチャを見ていても不十分であり、ビジネスアーキテクチャをデザインしマネジメントする必要があります。
ビジネスアーキテクチャについて考えると、ビジネスケイパビリティ・マップのようなケイパビリティの構造は頻繁には変わりません。ビジネスがすでに立ち上がり、既存ビジネスの深化を行うフェーズでは、ケイパビリティの構造はあまり変わらない一方で、各ケイパビリティの詳細な構成（またはさらにブレイクダウンされたケイパビリティ）がビジネスニーズに応じて変更が求められ、そのケイパビリティの変更に対する実装としてのソリューションへの機能要求が、フィーチャーといった形で展開されます。一方、DXの文脈で見られるような大きなビジネスモデル、組織やプロセスの非連続のトランスフォーメーションを目指す場合は、アーキテクチャそのものが大きく影響を受けることになります。例えば３Dプリンタの導入によって、今まで後方の工場においてリペアパーツを需要予測に基づき生産し、それをビジネスの前線に近い倉庫や店舗に配送して在庫を持つサプライチェーンモデルから、当該部品のオーダが来てからビジネスの前線の３Dプリンタで短リードタイムで生産を行うことで、無在庫でのオペレーションを行うモデルの可能性が出てきます。この場合、顧客経験と価値を大きく変える可能性があるだけでなく、企業におけるビジネスケイパビリティもバリューストリームも、大きく変更を伴います。リペアパーツの需要予測ケイパビリティの重要性は大きく低下し、オーダに応じて即時に単品生産し出荷するケイパビリティを新たに構築する必要があります。そしてこれは、３Dプリンタという破壊的テクノロジーが新たに生み出すことが可能なビジネスケイパビリティの可能性について、技術サイドから連想するものです。
こうして考えると、DXに代表されるような大きなビジネス変革のケースにおいては、アジャイルデリバリーのレベルでの検討（例えば、どのようなフィーチャーが必要か）の前に、ビジネスアーキテクチャレベルで、As-IsからTo-Beのアーキテクチャにどう変更するのかのデザインが行われることが先であることがお分かりになると思います。また、企画構想段階で迅速に意思決定を組織が行うには、現在のビジネスアーキテクチャに対し、新しい施策のアイデアがどのようなインパクトをケイパビリティ等に与えるかの影響分析が迅速に行える必要があります。新しい施策のアイデアに対し、その業務プロセスへの影響や既存システムへの影響がすぐには分からず、調査をするのに多くの工数と時間をかける必要があった経験をしたことがある人は少なくないはずです。
ビジネスアジリティを高めたいのであれば、Development ValuestreamだけでなくOperational Valuestreamにも目を向ける必要があるとともに、ソリューションの前にビジネスアーキテクチャを構想することに、一層私たちのフォーカスをあてていく必要があると考えています。そして、エンタープライズ・アジャイル等のアジャイル知識体系と、ビジネスアーキテクチャやビジネスアナリシスの知識体系が一層連携し融合することで、一層ビジネスアジリティを実現するためのフレームワークとして包括的な知見が提供できるのではないかと考えます。
Comments