組み込み開発のチームトポロジーゲーム

この記事の要約

組み込み開発のアーキテクチャはサプライチェーンで決定する。サプライチェーンを直接コントロールするのは難しいのでより高次のデザインを用いて、アーキテクチャを改善する。サプライチェーンのプレイヤーはゲームのルールを理解すべきであるという結論。

チームトポロジーの考え方

本の紹介

• https://pub.jmam.co.jp/book/b593881.html

いい本なので買いましょう。この記事はこの本の内容をベースに論を展開します。内容的にはWebの技術の話が多く、組み込みエンジニアにはかなり難しい内容です。

本の内容はソフトウェアエンジニア以外にも適用可能で、かなり議論が偏っている印象を受けますが、恐らく今後議論が拡大されていくと思われます。何らかの成果物があるチームに関しては同様の議論は成立しているんじゃないかなあ。

インタラクションモード

この本の内容のうち、チームタイプについては組み込み開発では本質ではないので割愛します。重要なのはチーム間でどう連携を取るかっていうインタラクションです。この話は後でまた議論します。

• コラボレーションモード
  • 他のチームに他のチームが食い込む連携
  • 密結合
• X-as-a-Serviceモード
  • APIやサービスを介する連携
  • 疎結合
• ファシリテーションモード
  • 他のチームをテクノロジーその他で先導する連携

コンウェイの法則

アーキテクチャは組織と同じ構造になるというのがコンウェイの法則です。これは単なる現象なのですが、望ましいアーキテクチャから正しい組織を設計しようというのが逆コンウェイの法則です。

コンウェイの法則をより道具としてアグレッシブに使うため、本記事ではより進んだコンウェイの法則の「道具化」を行います。まずコンウェイの法則を下記のような定理とみまします。

• コンウェイの法則は「組織をアーキテクチャへの写像」と定義する
• 逆コンウェイの法則は「アーキテクチャを組織への写像」と定義する
• 組織をコンウェイの法則で写像、それに逆コンウェイの法則で写像すると元の組織に戻る
• アーキテクチャ<->組織の写像は構造を保存する

こうすることで組織に対する論理的な議論が簡単になりました。

以上から下記のような定理を導き出せます。こういう定理を考えるだけでも新しい議論のテーマにはなりそうです。

• 「テクノロジーを最優先とした組織」の場合、以下が成り立つ
  • アーキテクチャと同じ論理的議論が組織にも適用可能である
  • SWE以外でも組織からアーキテクチャが理解できる
  • SWE以外のチームもコンウェイの法則は関係する
  • 組織デザインはアーキテクトがやるべきである
  • 最新のアーキテクチャを組織に適用することでパラダイムシフトが発生する

組織には様々な力学が働くので、アーキテクチャ的に最適な組織が組織として最適とは限らない、という点が重要です。ということは組織で開発する以上、最適なアーキテクチャで開発されることはほとんどないって話になりますけど。

組み込み開発のサプライチェーン

まあ、自分がサプライチェーンの話を書くのもどうかと思う部分もありますが、ネットには良い解説記事はたくさんあるので調べてみてください。あとでも書きますが組み込みエンジニアでサプライチェーンを意識していないのはかなり問題があります。アーキテクチャについて何も考えてないってのとイコールですからね。

サプライチェーンは大雑把には以下のようなイメージです。このようにひとつの製品を複数の企業で開発、製造、販売をします。

• MCUを作る半導体メーカーがある
• MCUをつかったECUを作るサプライヤーがある
• ECUを使って車両を作る車両メーカーがある
• 車両を販売する代理店がある

企業とはチームオブチームス、サプライチェーンとはチームオブ企業です。なのでサプライチェーンも製品全体から見たチームの階層の一部です。とは言え資本をまたぐので下の階層のチームとは力学がかなり変わるんですけどね。

とにかくまあ、コンウェイの法則によりサプライチェーンで製品のアーキテクチャが決まるって話がしたいだけです。

組み込み開発のサプライヤー

まあここは誰が主役のサプライチェーンなのかって話はあるのですが、自分はあえて語られにくいサプライヤー視点でのチームトポロジーを考えてみます。この記事はサプライヤーがいかにゲームのルールを理解するかって話ですしね。完成品の話はしたい人がしてください。

組み込み製品のサプライヤーの場合、インタラクションモードが重要です。これで製品のアーキテクチャが決まってしまうため、ここの意識で部品の採用可否に差が出るはずです。

コラボレーション型サプライヤー

• このタイプなら垂直統合モデルが最強の方法
• コンプリケイテッドサブシステムチームとして働く
  • 完成品メーカーにサプライヤーが食い込んで開発
  • モノリスな製品の開発

X-as-a-Service型サプライヤー

• 小さな労力で大きなシェアをとる最強の方法
• X-as-a-Serviceから直接製品は作れない
  • 製品向けモジュールを開発するチームが必要

ファシリテーション型サプライヤー

• 最新のテクノロジーを提供しファシリテートする
  • メーカーの研究所なんかは実質これになってる
  • 最近は半導体メーカーが目指している
  • 半導体メーカーが中堅企業の研究所の代行
• イネイブリングチームとして働く
  • 最新テクノロジーの開発キットを提供
  • 実際にはイネイブリングチームは商社の場合も

より高次なデザイン

ここで完成品メーカーの人が「そうか製品のアーキテクチャを改善するにはサプライチェーンを改善するのか」なんてことは「思わない」。みんなサプライチェーンを自由にコントロールする力持ちたいですよね。持てないけど。

まあ、そういうのをパワーでどうにかしようとしている企業様が存在することは存じておりますが、まあもうちょっとうまくやる前提なのがここから先の話です。

サプライチェーン、アーキテクチャを直接コントロールできない以上、より上位の概念を持ち込んでコントロールする必要があります。そこでチームの側面でGAFAが発明した方法が「エコシステム」であり、アーキテクチャの側面で発明されたのがDDD、クリーンアーキテクチャが代表する「メタアーキテクチャ」なわけです。

自分はこのエコシステム、メタアーキテクチャを総称してメタデザインと呼んでいます。

世界はすでに「抽象の抽象」まで進んでいます。エキスパートしか理解できない世界、想像するだけでワクワクしますよね。

ゲームのルール

メタデザインの話は非常に高次かつ抽象的すぎて意味がわからないので具体的に議論します。それからゲームのルールを学んでこの記事を終わります。

Androidのエコシステム

AndroidスマートフォンではGoogleがエコシステムと呼ばれるメタデザインを行いました。プラットフォームビジネス、どこで儲けるかはプラットフォーマーごとに違うのでiPhoneとはぜんぜん違うのに注意してください。

Googleは以下のようなAndroidエコシステムを作りました。

• スマホ/Android OS
  • GoogleはHWメーカーがスマートフォンを作れるようにAndroid OSを開発
  • HWメーカーはスマートフォンを作るために独自のサプライチェーンを構築
• APPマーケット
  • GoogleはAndroidのためにAPPマーケットを作った
  • GooglePlayのことです
  • アプリケーション、結構儲かるんですよねえ
  • ここでもアプリケーションメーカーが独自のサプライチェーンを構築
  • 過去日本のメーカーもAPPマーケットを作ろうとしたことがあった
• クラウド/Webサービス
  • Androidのための基本的なWebサービスはGoogle製です
  • ここの部分も相当3rdパーティに開放しているのでGoogle様心が広い

このようにまあ、Googleはそれぞれのサプライチェーンには手を付けてないですが、それぞれの企業がうまいことやっていい感じに進化しているわけです。繰り返しますがAppleはぜんぜん違うっぽいです。

こんな感じでメタデザインでサプライチェーン、アーキテクチャを制御するのがGoogleのやり方っぽいです。かなりの独自分析ですが。

IoT製品のサプライチェーン

IoT製品の開発におけるサプライチェーンについて説明します。

はっきり言ってアーキテクチャ的に最適とはいえないんですよね。これが。理由はサプラーチェーンには別の力学が働くからです。

サプライチェーンでは領土争い、製造競争が激しいので一歩間違えると退場させられます。チーム同士仲良く、とはいかないところが難しいところです。

• 完成品メーカーはアプリケーションを支配している
  • 完成品の魅力と直結するので直接アプリケーションを密結合で制御する
  • HWの新機能は即座にアプリケーションに反映
  • アーキテクチャ的には望ましくない
• 半導体メーカーがOSのサポート
  • 部品を採用してもらうため最新のテクノロジーをソリューションで提供
  • BSPと呼ばれるドライバ類は半導体メーカーが用意
  • 正直製品開発する側としてはめっちゃ助かる
• IaaS
  • OSまで手を突っ込んでるのがアレ
  • GoogleはAndroid、Fuchsia
  • AmadonはFreeRTOS
  • マイクロソフトはWindows、ThreadX

サプライチェーンの制御の反転

ここまで説明して「おっきな会社がデザインしているゲームのルールはわかった。でも我々末端には関係ないよね」と思う人も多いかも知れないのですが、実は関係があります。ゲームのプレイヤーである以上、ゲームのルールを知っているかどうかは、生死に直結します。

ここではメタデザインで生まれるゲームの一つである、「制御の反転」について説明します。

制御の反転とはインターフェイスを定義して他のレイヤーはそれを参照することでレイヤーの依存関係を反転するアーキテクチャ上のテクニックです。これによりクリーンアーキテクチャでは常に依存関係を下位レイヤーから上位レイヤーに限定することに成功しています。

• https://ja.wikipedia.org/wiki/%E5%88%B6%E5%BE%A1%E3%81%AE%E5%8F%8D%E8%BB%A2
• https://qiita.com/kmt_t/items/e05f6195410e9b91350b

これをサプライチェーンにあてはめると、「仕様を握っている方に依存する」という話になります。アーキテクチャ的には仕様は上位側（車載で言えば車両メーカーに近い方）が握るのが正しい、ということになります。

これで終わり...とは限らないんですよね、これが。サプライチェーンの世界では仕様を握っている方が力を持ちます。これがこのゲームで非常に重要な点です。

安易に他人に仕様を握らせてはいけない、ここがゲームのルールです。サプライヤーとしては仕様をTierが上の会社に握られると他の会社に同じ製品が売れません。そうなると力関係は完全にTierが上の方が握ることになります。車両メーカーが非常に強い力を持っている車載では、車両メーカーが仕様を握ってますし、家電の場合は半導体メーカー側のほうが仕様を握っている場合があります。

正しいアーキテクチャを志向してTierの上の方に仕様を握らせるのか、それとも他の会社にも売るために仕様は自分が握るのか。この選択は状況によります。

「制御の反転の反転」は現実的にありえます。