このコラムは、株式会社エル・ティー・エスのLTSコラムとして2019年4月から連載を開始した記事を移設したものです。
当コラムの最新の内容は、書籍『Business Agility これからの企業に求められる「変化に適応する力」（プレジデント社、2021年1月19日）』でご紹介しております。
ライター
“要求”を示すアーキテクチャビルディングブロック
前回のコラムで説明したように、アーキテクチャを構成している要素（部品）を「ビルディングブロック」と言います。カタカナ用語でとっつき難い言葉ですが、アーキテクチャの観点からビジネスアジリティを語る際にその核となる大切な言葉です。ビルディングブロックには二つの種類がありますが、その一つが「アーキテクチャビルディングブロック（以降ABB）」です。ABBの最もわかりやすい例は「業務」です。企業は「給与計算」とか「月次決算」といった、さまざまな業務で構成されています。以下の図はLTSの業務（プロセス）の一覧でプロセスマップと呼んでいる図です。ここには約130の業務がブロックとして識別されています。私がかつて関わったネット通販会社はお客様に商品を届けるために必要な基幹業務だけで500ほどの業務がありましたが、これはこのネット通販会社のアーキテクチャが500の “ブロック”で構成されていることを意味しています。
ここで表現されている一つ一つの業務は、より細かい要求事項の集合体です。例えば「給与計算はこのような順序（手順）で実行しなければならない」といったプロセスに関する要求、「消費税率は10％で計算しなければならない」といったルールに関する要求、「従業員情報は規程により定められた従業員コードで管理されなければいけない」といった情報に関する要求、「業務では従業員情報や支払給与額といった情報から構成される給与計算結果を生成しなければならない」といったアウトプットに関する要求などなど、さまざまな要求が寄り集まって一つの業務を構成していることになります。厳密に言えばABBとはこの一つ一つの“要求”を指します。ただ、より実用的に考えるのであれば要求の塊としての“業務”を一つのブロックとして認識することでもおおむね間違ってはいないでしょう。一つの業務が持つさまざまな要求事項の観点はおおよそ以下のようなものになります。
何かしらのビジネスのニーズ、例えばコストを削減したいといった業務課題や新しい事業の展開といった機会（チャンス）への対応のために、埋め込まれた要求が変化する業務があれば、それは交換しなければいけないブロック（＝変革対象の業務）だということになります。システム開発やデジタルツールの導入を含む企業の業務変革活動の実態は、実はこのブロックの交換作業です。
このようなアーキテクチャをブロックの集合体として見る視点を持っていると、現行業務を速やかに把握できるだけでなく、新たな業務の設計（改善・変革）能力も劇的に向上します。結局のところ、業務変革をうまく進められないのは変えるべき箇所を特定し、戦略やビジネスモデルに基づいた適切なブロックへの交換ができないために起こるからです。
業務遂行のための“道具”であるソリューションビルディングブロック
ここまで説明したABBの他にビルディングブロックにはもう一つの種類があります。これが「ソリューションビルディングブロック（以降SBB）」です。SBBは一言でいえば業務遂行のための“道具”です。もともとビルディングブロックという考え方は「エンタープライズアーキテクチャ」と言われるIT管理の方法論からきています。ですからSBBでいうところの“ソリューション”とはもっぱらIT関連のソリューション、例えばソフトウェア、サーバ、ネットワークといったものを指します。しかし、よくよく考えれば企業活動を支える“ソリューション”はIT関連に限りません。工場機械や建物、文具、オフィス家具にいたるまで業務上の要求（ABB）を実行するために必要な“道具”はすべてSBBと考えてもあながち間違いではないでしょう。その実態が要求（ルールやプロセス）という概念的な存在であるABBに対して、何か実態を伴うビルディングブロックがSBBと言えます。アーキテクチャ視点で考える企業活動とは「ABBに記載された要求を、人や組織が、SBBを使って遂行することでお客様に製品やサービスを提供している」という見え方になります。
戦略、アーキテクチャ、そしてビルディングブロックを車に例えると、戦略は車の企画書にあたります。どのようなユーザーを対象にしたどのような特徴をもった車なのか、外見や内装のデザインはどのようなものか、何が訴求ポイントなのか、想定されるコストや販売価格はいくらなのかといったことが説明されています。しかし車には設計図が必要です。華やかで読みやすく書かれた企画書に比べると設計図は地味で複雑ですが、これがなくては車を作り上げることはできません。設計図で大切なのは完全性と正確性になります。一つの車を組み上げるために最低限必要な全ての要素を、間違いなく記述しなければなりません。この設計図に基づいて部品を製造し、組み上げることで一つの車が完成します。ビジネスにおいては、設計図に示される車の構造がアーキテクチャであり、部品がビルディングブロックにあたります。
第3回の戦略の回で、戦略は考えすぎて立ち止まるくらいなら前に進む一方で、ビジネスプロセス（今回からアーキテクチャと言っていますが）への落とし込みは必ずしも手を抜くことができないと説明しました。企画書は多少、“えいや”でも先に進めます。むしろ企画書レベルで「ああだこうだ」と議論をしていても適切な市場投入タイミングを逃してしまうリスクもあります。しかし、設計書はいい加減では先に進めません。戦略は完全性よりも迅速さを重視する一方で、アーキテクチャは完全性が大切になります。しかし完全性の裏で迅速さを犠牲にしないためには、ビルディングブロックの普段から管理をしっかり行うことがポイントになります。
ブロック間のつなぎ目の分離・結合をしやすくする
企業をブロックとして捉えて変革することは、さながらおもちゃのブロックを組み替えて別の物体にするようなものです。写真は私の息子のLEGOですが、玩具のブロックはブロックの組み合わせを変えることで、同じ部品のセットから異なる物体を作ることができます。例えば以下の図だと、ほぼ同じ部品から二つのトラックを作ることが出来ます（この製品はLEGOの“CREATER”というシリーズの一つで、この場合ほぼ同じブロックのセットから三つの異なるトラックを作ることができます）。LEGOで作られた物体が柔軟にその姿を変えることが出来る理由の一つは、もちろん作り上げた物体が「分離可能な細かいブロックで出来ていること」で、ビジネスに当てはめるのであればここまで説明したようにビルディングブロックが識別され、その関係が理解されていることになります。
その一方で、物体が柔軟にその姿を変えることができるためには、もう一つ大切なことがあります。それが「各ブロックのつなぎ目の仕様（つまりインターフェース）が統一されていること」ことです。いくらこのトラックがブロックでできていても、交換対象のブロックがLEGOと全く仕様の違う他社のブロックであれば結合することができません。ビジネスに当てはめると「社内で活用しているソリューションや手法が同じ技術標準で構成されている」「顧客や製品といったマスタ情報の仕様が統一されていて、どのような業務でも同じ情報を活用できる」といったことになります。この結合の仕様を合わせる行為がいわゆる「標準化」です。部品である業務や設備を変える際に、すぐに交換した業務や設備と結合できる仕様になっていなくては変化への迅速性は落ちてしまいます。
実際には多くの企業でこれができておらず問題を引き起こしています。例えば業務毎にお客様コードが違い、システム間でうまく情報がつながらない構造になっていたり、同じ業務に従事する担当者間でも細かい業務手順が異なっており、後任の担当者に上手く業務を引き継げなかったりというようにです。さながらブロックの凹凸の大きさが違うため、ブロックの間のつなぎ目を人が加工してつなげているのです。このような状態では、ブロックを簡単に交換することは出来ないですし、ブロックを交換することでむしろ効率性が落ちてしまうことも考えられます。
結合性を意識しながら、自社を構成しているブロックを管理できれば、いざ変革という時に各ブロックを迅速に他のものと交換していくことができます。このような、ある種の“哲学”とも言える視点がアーキテクチャ視点から見るアジリティの根幹にはあります。プラモデルは、たとえば飛行機とか船といったように特定の姿しか作り上げることが出来ません。しかも、一度組み上げたプラモデルは分離することはできません。思い込みで間違った部品をくっつけてしまうと、分離して組み立てなおすのは大変です（私はこれで何度も泣いたことがあります）。多くの企業は自社を、分解不能で、特定の姿しか表現できないプラモデルとして認識しています。これを分解可能で、柔軟に姿を変えられるブロックの集合体だと認識を変えることができれば、環境変化の速い市場でも迅速に対応することが可能になるのです。
