アーキテクチャの弊害? モジュラリティの罠とは?

2021年9月1日水曜日

Architecture

本記事では、モジュラリティの罠、インテグリティの罠について紹介します。

アイキャッチ

製品アーキテクチャ

製品を形作る部品や、部品間の接続・連携方式の設計。
これに加え、どの製造工程で製品機能を製造するか、また、製造工程間の接続・連携方式の設計など、製品製造時全体の設計思想を製品アーキテクチャと言います。

特徴としては、製品の部品や、部品間の接続・連携のみが対象でなく、製品の製造工程の設計も対象となっている点です。製造業において、設計と製造は異なる部門が担当していることも多いと思いますが、これら2部門が連携して初めて製品としてのアーキテクチャは形になるということが定義からも見て取れます。

製品アーキテクチャは大別して2つの種類が存在します。
独立性の高い部品を組み合わせるモジュラー型と、独立性が低い部品を擦り合わせるインテグラル型の2種類に分類されます。

以降では、モジュラー型、インテグラル型について紹介します。

モジュラー型

モジュラー型は、一つの部品が一つの機能を構成しています。
各部品の独立性が高く、部品が有する機能が明瞭です。また接続・連携方式が明瞭で業界によっては標準化されている場合すらあります。

そのため、このタイプの製品は部品の組み合わせによって製品が構成されています。代表例に、パソコンがあります。自作パソコンをイメージして頂くとわかりやすいと思います。

自作パソコンを作る様子

HDDや、マザーボードなど各部品が独立しており、別のメーカーの部品を組み合わせてもパソコンを組み上がります。

HDDはメーカーAから、マザーボードはメーカーBからと違うメーカーから部品を購入しても、一つのデスクトップPCという製品を実現できます。

これはHDDや、マザーボードの接続・連携方式が標準化されており、さまざまなメーカから独立して部品が販売されているからこそ実現できています。

インテグラル型

このタイプの製品は、多くの部品が多くの機能を構成している点が特徴です。
どの機能が、どの部品によって構成されているかの境界があいまいで、各部品の独立性は低い傾向にあります。このため、機能と部品は、多対多の関係性で構成されます。

インテグラル型の製品は部品の擦り合わせによって製品が展開されます。
代表例は、自動車や小型家電が挙げられます。

冷蔵庫

メーカーAの冷蔵庫に、メーカーBの基盤を導入するようなケースはなかなか見受けられないと思います。

このタイプの製品は、複数の部品を複雑に擦り合わせて、複数の機能を構成し、製品を形成します。部品の独立性が下がる一方で、緊密な連携によって、製品全体のコストの削減やパフォーマンスなどの性能を追求できます。

モジュラリティの罠、インテグリティの罠

一般に製品アーキテクチャと組織構造は同じ形を取る傾向があると言われています。
モジュラー型製品を製造する組織では水平分業型組織に、
インテグラル型製品を製造する組織では垂直統合型組織となり
それぞれ異なる特徴を持つ製品の製造に適した組織構造となっていきます。

組織構造の模式図

そしてこの製品アーキテクチャに組織構造が同型化することによって
技術革新への対応が困難になることがモジュラリティの罠・インテグリティの罠と言います。

モジュラー型製品のため水平分業型組織である場合、
技術革新によりインテグラル化へシフトした場合、困難に直面します。
この状態をモジュラリティの罠といいます。

例えば、先ほどのパソコンを例に考えてみます。
パソコンを製造しているメーカーは、さまざまな他社から部品を調達しコアとなる部品のみ自社製造し、部品の組み合わせることによりパソコンを製造します。この時メーカーはモジュラー型の製造に適した組織構造を取っています。

この時、インテグラル型の革新的なパソコンが他社から販売されたとき、メーカーは同等以上の製品の製造が求められます。しかし、モジュラー型に適して構成された組織構造や、組織風土、人員の考え方を急速にインテグラル型に移行していくことは至難です。

こうしてインテグラル型への適応に時間を要してしまうため罠にかかったと表現されます。

対して、インテグラル型製品のため垂直統合型組織である場合、
モジュラー型へ業界が移行した場合、困難に直面し、インテグリティの罠に陥ることになります。

罠に陥らないために

なかなか個人で解決することが難しい問題ではありますが、
組織構造を迅速に組み替えられる組織風土であることは一つ重要であると思われます。

モジュラー化、インテグラル化へのシフトに対して迅速に適応し罠に陥ることを避けることが可能となるためです。

但し、言うは易く行うは難しです。組織構造の改変は当然のごとく反発を招きます。
アーキテクトの視点としては、パラダイムシフトが起こり得ることを想定して設計することが、でき得る最大限かもしれません。アーキテクトは往々にして技術だけではなく、ビジネス面や、組織風土を考慮する必要に迫られます。それはこれらの要素によってアーキテクチャの何を重要視するかが変わるためです。

一方で攻めの姿勢としては自社が、新たなシフトを起こしていくということも考えられます。新たなシフトを定期的に起こせば、競合がモジュラー型製品に適当し始めた頃にインテグラル化のシフトを起こすことにより競合を自発的にモジュラリティの罠に陥れることが可能となります。

まとめ

本記事では、モジュラリティの罠、インテグリティの罠について紹介しました。

1個人には無縁の話に思えるかもしれません。
しかし、エンジニアの方がビジネスの視点を持つことは非常に重要だと思います。
ミクロでは、組織でやりたい開発をスムーズに進めるための説得材料として
マクロでは、自分の開発した技術が広く世の中の方に使ってもらうための判断材料として幅白い視点を持っておきたいものです。

AIで副業ならココから!

まずは無料会員登録

プロフィール

メーカーで研究開発を行う現役エンジニア
組み込み機器開発や機会学習モデル開発に従事しています

本ブログでは最新AI技術を中心にソースコード付きでご紹介します


Twitter

カテゴリ

このブログを検索

ブログ アーカイブ

TeDokology