製品開発におけるビジネスモデルの違いと変化

従来、特に大企業の基幹システムはウォーターフォール型の受託開発が一般的でした。しかし、近年ではグローバル化によってベストプラクティスが確立し、SAPのERPようなパッケージソリューションが一般的になってきています。

このようなソフトウェア開発におけるビジネスモデルの変化が、ハードウェア開発においても同様に起きているようです。ソフトウェア・ハードウェアのビジネスモデルの共通項に着目して掘り下げていきます。

## 受託開発 vs 自社開発
ソフトウェア・ハードウェア問わず、製品開発のビジネスモデルは大きく**受託開発**と**自社（パッケージ）開発**の2種類に分けることができます。端的に言えばオーダーメイド or 既製品です。

まずは比較のため、CopilotにPlantUMLで両方のビジネスプロセスを書いてもらいます。
### 受託開発
プロンプト
```
ソフトウェア及びハードウェア製品の一般的な受託開発プロセスをPlantUMLのアクティビティ図で可能な限り抽象的な表現で受注するところから記述してください
```
結果
```
start
:受注;
:要件定義;
:設計;
:実装;
:テスト;
:納品;
stop
 ```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3931939/fea04663-202d-b344-428d-07135d7b8dde.png)

受託開発は受注ベースで顧客の要件を定義し、設計を進めて納品するビジネスモデルです。

### 自社開発

自社開発では自社主導でニーズを分析し、創出したアイデアをベースに製品開発を進るビジネスモデルです。

今回はプロンプトをちょっと捻って、受注時の顧客に合わせたコンフィグレーションプロセスを組み込んでもらうように頼んでみます。
```
ソフトウェアまたはハードウェア製品の自社開発プロセスをPlantUMLのアクティビティ図で可能な限り抽象的な表現で記述してください。
リリース後、受注をしたら、顧客固有の要求があればそれに合わせたコンフィグレーションを行って納品します。
```
結果。"納品"が分岐の両方に出てしまったので、そこだけ直しました。概ね想像通りかと思います。
```
start
:アイデアの創出;
:要件定義;
:設計;
:実装;
:テスト;
:リリース;
:受注;
if (顧客固有の要求あり?) then (yes)
  :コンフィグレーション;
  :テスト;
else (no)
endif
  :納品;
stop
 ```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3931939/27d59ae7-c005-5d79-970d-3b3e198a08e1.png)

## ソフトウェアにおける受託開発 vs 自社開発
一般論としてソフトウェアはコピーが容易なので、同じものを売れば売るほど利益が増加します。
受託開発はローリスクですが、顧客に合わせて一品一葉であるため、前述のメリットを享受できず、一般的にパッケージ製品に比べて利益率が低くなります。

例えば国内SIerの粗利率は
- NEC　2022年3月期で **29.4%**
- 野村総研　2022年3月期で **35.3%**

国内パッケージベンダーの粗利率は
- オービック　2022年3月時点で **76.0%**
- サイボウズ　2022年12月時点で **91.2%**

## ハードウェアにおける受託開発 vs 自社開発

ハードウェア産業では少し様相が異なります。
例えば受託開発中心のビジネスモデルである東京エレクトロンの粗利率は2022年3月期で **45.5%** ですが、自社開発の白物家電が主力製品であるパナソニックは2023年3月期が **27.0%** です。
ハードウェアは複製（＝量産）するために材料・工場・在庫など、様々なコスト要因があるため、ソフトウェアのように売れば売るほど儲かるとは言い切れません。
とはいえ、儲からないとも限りません。ファブレス（工場を持っていないメーカー）ではありますが、自社開発で在庫を持つキーエンスの粗利率は2022年9月期が **82.0%** です。


### ETO vs CTO
また、ハードウェア開発（＝製造業）ではこのようなビジネスモデルの違いに対して、ETO,CTO,MTSという用語を使います。[^1]
厳密にはニュアンスが異なるかもしれませんが、受託開発・自社開発との関係は以下であると言うことができます。
- 受託開発≒Engineering-to-Order(ETO)
    - 受託開発は受注後の設計開発という意味の **Engineering-to-Order(ETO)** とほぼ等しい
- 自社開発≒Configuring-toOrder(CTO)またはMake-to-Stock(MTS)
    - **コンフィグレーションを伴う自社開発** は受注後のコンフィグレーションという意味の **Configuring-toOrder(CTO)** とほぼ等しい
    - **コンフィグレーションを伴わない自社開発** はいわゆる「吊るし」の製品と言うことができ、 **Make-to-Stock(MTS)** とほぼ等しい


今回は共通項を探るために、この用語をソフトウェアにも適用してみます。
| |受託開発 / ETO|自社開発 / CTO|自社開発 / MTS|
|:--|:--|:--|:--|
|ソフトウェア|大企業の基幹システムなど|業務システムパッケージなど|コンシューマアプリなど|
|ハードウェア|装置メーカー・自動車サプライヤなど|自動車・業務用PCなど|電子機器・白物家電など|

ソフトウェアにおいては前項でご紹介した通り、率先して受託開発をビジネスモデルに選ぶメリットは低いです。
ご存知の通り、近年ではSAPのような基幹システムのパッケージソリューションが現れ、従来は個別開発するしかないと思っていた大企業の基幹システムを最小限のカスタマイズで導入できるようになり、個別の要求ベースのここでいうETO的な基幹システム開発は過度な自前主義として批判されるようになりました。
[なぜオープン・イノベーション－自前主義からの脱却が必要となっているのか - 総務省](https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r01/html/nd123210.html)


## ハードウェア開発はCTOを目指さなくていいのか

ハードウェア開発においてETO（≒受託開発）にデメリットがないわけではありません。
例えば一つの案件に時間がかかる、顧客都合の仕様変更などで現場が混沌としがちで、属人的で効率化が難しいなどの課題があり、根本的にビジネスを拡大しづらい構造です。

しかし、ETOがCTO（≒自社開発）のビジネスモデルにシフトすることは、簡単ではありません。
ETOは顧客の工場のレイアウト、作りたいモノ、取り付けたい製品など、そもそも顧客特有のハードウェアとすり合わせるビジネスモデルであるためです。

## モジュラーデザインでCTOシフト

そこで期待されているのが、モジュラーデザインというコンセプトです。

これまでの実績などを利用して標準化したモジュールを設計しておき、受注時に顧客の要求に合わせてモジュールをコンフィグレーションすることで、ETO的なカスタマイズを最小限に収めるという考え方です。
よく「レゴのように組み合わせる[^2]」と言われます。

ソフトウェアにおいても、例えばSAPのERPパッケージは機能別にモジュールという括りで分割することにより顧客が標準適用しやすくなっており、これと同様のアプローチと言えます。

代表的なETOの一つである工作機械メーカーのファナックはモジュラーデザインでCTOシフトに成功した企業の一つです。
[ロボット新商品：モジュール型走行軸 - 新商品紹介 - ファナック株式会社](https://www.fanuc.co.jp/ja/product/new_product/2024/202405_robot_modularrtus.html)

このようなCTOシフトしたETOは、カスタマイズのあるCTOということで、 **CTO+** や **CTO+E** などと呼ばれます。[^3]
もちろん、CTOシフトしたETOだけではなく、カスタマイズビジネスを手掛けるCTOもまたCTO+Eです。トラックメーカーなどがそれにあたり、Scaniaはモジュラーデザインにおいて先進的な企業です。
[Our Modular System - Scania Group](https://www.scania.com/modular-system.html)


では、CopilotにCTO+Eプロセスを書いてもらいます。脚注[^3]のCTO+の記事を参考にしてもらおうと思います。
スイムレーンを追加するようにも頼んでみました。
```
https://bdfexperts.de/en/our-fokus/configuration-management-as-a-path-from-eto-to-cto-246
上記ページを参考にソフトウェアまたはハードウェア製品のCTO+プロセスをPlantUMLのアクティビティ図で可能な限り抽象的な表現で記述してください。
スイムレーンも追加してください。標準設計はプラットフォーム、カスタマイズはセールスが対応します。
```
結果
```
|プラットフォーム|
start
:標準製品の設計;
:標準製品の実装;
:標準製品のテスト;
:標準製品のリリース;
|セールス|
:受注;
if (顧客固有の要求あり?) then (yes)
  :カスタマイズ設計;
  :カスタマイズ実装;
  :カスタマイズテスト;
  :カスタマイズリリース;
endif

:納品;
stop
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3931939/a6423e03-4e55-c13b-712a-e0ec07ce7b44.png)


標準モジュールの設計と受注ベースのカスタマイズを分けてプロセスを出してくれました。
たたき台としては悪くなさそうですが、実際はプラットフォームとセールスプロセスは並行しつつ、セールスは最新の標準製品を利用し、プラットフォームはセールスからのフィードバックを受けて標準製品を更新しますので、もう少し手を加える必要かもしれません。カスタマイズとコンフィグレーションの違いもプロセス化したいですね。
このあたりはまた別の機会でやってみようと思います。

## まとめ
ソフトウェアではSAPなどが、ハードウェアではファナックなどが、モジュラーコンセプトを用いてETOからCTO+にシフトし、業界に破壊的イノベーションをもたらしました。

また自動車などのCTO業界では、高級車を中心に純正でありながら顧客固有のカスタマイズが増加しているようです。
[ロールスロイスやランボルギーニの超カスタマイズ車、富裕層が熱視線](https://www.cnn.co.jp/business/35217687.html)
これも一つのCTO+Eアプローチと言えそうです。

昨今のトレンドでは、グローバル化によって苛烈なコスト競争をしつつも消費者からはパーソナライズを求められます。モジュラーデザインを活用したCTO+Eアプローチによって、標準適用する部分と顧客がカスタマイズしたい部分を区別して対応し、最小限の労力で顧客満足度を高めることが期待できます。


[^1]: [ETO vs CTO - virtual+digital](http://virtual-digital.com/eto-vs-cto/)

[^2]: [モジュラーデザイン●「レゴ」のように組み合わせ多様な製品を生む | 日経クロステック（xTECH）](https://xtech.nikkei.com/atcl/nxt/column/18/01618/00003/)

[^3]: [Configuration Management - BDF EXPERTS](https://bdfexperts.de/en/our-fokus/configuration-management-as-a-path-from-eto-to-cto-246)