アーキテクチャル・イノベーション

よく知っている部品を使っていても、その接続や配置を変えると、製品全体の振る舞いは変わります。
アーキテクチャルイノベーションは、構成要素の基本となる設計原理を保ちつつ、要素同士のつながり方を変えるイノベーションです。
HendersonとClarkの1990年の論文は、部品についての知識と、部品を統合する知識を分け、この変化に既存企業が対応しにくい理由を論じています。

ここで保つのは、部品の設計原理です。
寸法や性能の調整まで一切しない、同一の部品を並べ替えるだけ、と限定すると、変化を狭く捉えすぎます。
どの要素を一つの部品として扱うかを決めたうえで、要素の原理と関係を分けて確認します。

ソフトウェアの処理構成に当てはめる

考え方をソフトウェアに当てはめる仮の例として、帳票を読み取るサービスを考えます。
従来は、画像の補正、文字認識、項目の照合を一つの処理として順番に実行していました。
これを、各処理を別々に動かし、データを受け渡す構成へ変えるとします。
それぞれの処理の基本方式を維持していても、処理間の関係が変わります。

新しい構成では、必要な処理だけを増やして実行したり、失敗した処理から再開したりする設計を検討できます。
一方、途中のデータをいつ確定するか、同じ帳票を二度処理したときにどう扱うか、結果をどの順序で利用者に示すかを決め直す必要があります。
各処理が単独で正しく動くという試験だけでは、サービス全体の正しさを確認できません。

部品の知識を統合する仕事

この例で、画像処理の担当者と照合処理の担当者が、それぞれ従来の試験だけを実施したら、受け渡しの問題が残る可能性があります。
両者が扱うデータの意味や、失敗した場合の責任範囲まで一緒に確認する必要があります。
既存の部門分担に沿って作業を割り当てるだけでは、変更した関係を誰も検証しない状態になり得ます。

設計レビューでは、部品の一覧に加えて、次の内容を確認するとよいでしょう。

  • 変更前後で、情報や制御がどこからどこへ渡るか。
  • ある要素の遅延や失敗が、ほかの要素にどう影響するか。
  • 全体を通した試験を誰が実施し、結果を判断するか。

この整理は、新技術の採用に比べて変更が小さく見える企画でも、統合と検証に時間が必要な理由を説明する助けになります。

ほかの分類との違い

HendersonとClarkの分類では、要素の設計原理を変え、つながり方を保つ変更はモジュラーイノベーション、両方を変える変更はラディカルイノベーションです。
ただし、内部構成を変えたという理由だけで、顧客の便益や事業の成功が確定するわけではありません。
帳票の例なら、処理時間、結果の正確さ、障害からの復旧、運用費用を比較して、構成変更の効果を確かめます。

関連する記事：製品アーキテクチャ、製品イノベーション、漸進的改善。