製造業はなぜ機能別組織に固執するのか？IT業界との対比で見えたDXの壁

なぜ製造業は機能別組織に固執するのか。
IT業界との対比から、DXを阻む専門性の壁と組織変革の鍵を解き明したい。
考えたことをラフなメモ書き。

【参考】
すり合わせの優位性は健在か？日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実: プログラマの思索

PLMツールとは部品表の構成管理ツールでありGitHubである: プログラマの思索

いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化する

図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon

システムズエンジニアリングに基づく製品開発の実践的アプローチ

システムズエンジニアリングの探求 | ジョン・ホルト, Jon Holt, 伊藤 侑太郎, 河野 文昭 |本 | 通販 | Amazon

システムズエンジニアリングハンドブック 第５版 | デイビッド・D・ウォルデン, 西村秀和 |本 | 通販 | Amazon

実践に活かす モデルベースシステムズエンジニアリングの基礎 | 西村 秀和, 西村 秀和, 河野 文昭 |本 | 通販 | Amazon

5つの問題解決パターンから学ぶ実践メソッド BOM(部品表)再構築の技術 | 三河 進 |本 | 通販 | Amazon

BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか: プログラマの思索

【1】自動車、半導体、機械装置などの製造業の業界を見てくると、IT業界とは違った景色が見えてくる。
僕が違和感を持つ点は、製造業はなぜ、機能別組織にあんなにこだわるのか？

【2】IT業界であれば、最近はアジャイル開発に向いた組織構造にするのが当たり前だ。
技術革新のスピードが速く、環境変化が速すぎるために、組織構造も従来のWF型開発ではやりづらい。
大規模なソフトウェア開発案件であっても、要件定義に時間をかけるとしても、裏側では、プロトタイプ検証やインフラ環境構築などの並行開発もやっている。

特に最近は、ローコード開発のプラットフォームが揃ってきたので、1億円くらいの開発案件であったとしても、機能を細分化して、今週に要件定義をやったら来週にはプロトタイプを見せる、という開発サイクルで段階リリースしていく手法も多く見られるようになった。

発注したユーザにとっても、自分たちの要件が翌週には形が見えるので、自分たちの現場に特化した画面や機能であるか検証しやすいメリットがある。
開発チームにとっても、ビッグバンリリース後に捌ききれない問合せや障害が多発するよりも、ユーザから早めにフィードバックをもらって手戻りを無くす方が心理的にも楽だし、開発のリズムも整えやすい。

つまり、IT業界ではアジャイル開発が主流になった理由として、アジャイルという開発プロセスがかなり確立してきたこと、さらには、ローコード開発プラットフォームが充実してアジャイル開発を実践できる開発基盤が揃ってきたこと、があるためだろうと考える。

よって、従来のWF型開発のように、インフラ層・DB層・ミドルウェア層・フレームワーク層・アプリ層・UI層のように機能別に特化した組織構造では、アジャイル開発が非常にやりにくい。
部門間のコミュニケーションロスが多すぎる。
よって、アジャイル開発に特化した組織構造にするには、ストリームアイランドチームのように、アプリ層を中心に一つのサービスやサブシステムを作る単位でインフラ層からUI層までをカバーする組織構造のほうがやりやすい。

DevOpsの考え方、クラウドが普及したことにより、技術的にもシステム運用やアプリ開発が一体化した開発プロセスも一般的になってきた。

すなわち、IT業界では機能別組織はアジャイルではなく、縦に一気通貫する事業部型組織に近いストリームアイランドチームが主流だろうと考える。

【3】では、製造業であっても、環境変化や技術革新がこれだけ速いのに、なぜ、製造業は機能別組織にこだわるのか？

製造業にいる人達も、自分たちがタコツボになりやすい傾向を既に知っている。
彼らに聞けば、環境変化や技術革新のリスクを、彼らもよく分かっている。
彼ら自身、機能別組織の欠点は知っている。
しかし、そこから彼らは抜け出せない環境にある。
それはなぜか？

【4】製造業では未だに機能別組織がはびこっている理由は、根深い特性があると考える。

理由は、設計・製造・営業に特化した方が専門知識を蓄積しやすく、効率化しやすい特性が強すぎるからだろうと考える。

たとえば、自動車であれば、たとえEVや自動運転が主流になったとしても、ボディ・エンジン・ブレーキ・サスペンション・タイヤなどのハードウェア部品が必要であり、それらの各部品の仕様や特性には深い専門知識が必要だ。

半導体製造でも、スマホやAIデータセンターに特化したチップを設計して、シリコンの原材料から微細加工したICチップを切り出して大量製造するには、数兆円規模に特化した設備や機械装置、原材料が必要だ。
半導体の各工程に特化した専門知識が必要になる。

つまり、製造業では、各機能に特化した専門知識のレベルが深いこと、さらには歴史も長いことにより、専門化した機能別組織の方が仕事しやすい傾向がある。
機能別組織の方が、専門性を発揮しやすい一方、設計や製造の現場で試行錯誤したノウハウを蓄積することにより、ナレッジを組織が維持管理しやすい。

製造業は、専門性に特化することで、業務を局所最適化しまくって、生産性を上げる方向に向いている。

【5】では機能別組織の弱点は、何があるだろうか？

1つ目は、機能を担当する部署間でコミュニケーションが数多く発生し、コントロールが難しくなる点だろう。
各機能ごとに専門家集団がいるので、他の専門家には言葉や意図が通用しづらい。
その分、無駄なコミュニケーションコストが積み重なりやすい。

おそらく、日本の製造業はすり合わせが上手い、と言っていた理由は、専門家集団同士のコミュニケーションを以心伝心でやれたからではないだろうか。
そんなことを考えると、日本の製造業は、すり合わせという行為をきちんとエンジニアリングできていたのだろうか、と疑ってみたくなる。

【6】2つ目は、機能別組織に特化した製造業の企業は、顧客ニーズを拾いきれず、市場ニーズの変化に弱い点があるだろう。

なぜならば、機能別組織では、営業・設計・製造の部門だけでなく、各部門内の各工程の部署は、自分たちの業務の局所最適化しか考えていないので、製品を利用する顧客までイメージが及んでいないからだ。
これだけ環境変化が速い時代では、顧客ニーズがコロコロ変わるのに、そのニーズを随時反映していくプロセスが機能別組織には取り込みにくいのだ。

特に、各工程の作業担当者は、自分たちの業務を終わらせることしか頭にない。
せいぜい、製品出荷時までしか頭にない。
すると、出荷したらおしまい、という考えになりやすい。

実際、出荷後の保守サービスを担当する部門が製造業の会社では作られていないケースが多い。
いわゆるカスタマーサクセスを担当する部門がないのだ。
だから、保守サービスのノウハウを蓄積したり、出荷後の製品を利用した顧客ニーズを拾い取る業務を担当する部門がないのだ。

一方、特にSaaSを中心とするIT企業では、ユーザのニーズを吸い取る部署があるのが普通だ。
また、サブスクリプションのビジネスモデルが多いので、利用ユーザのニーズに敏感になりやすい傾向があるから、そこからノウハウを蓄積するプロセスも確立しているだろう。

どうしても製造業は硬いビジネスモデルになりやすい傾向がある。

【7】しかし、Software is eating the worldの時代では、製造業も設計資産のデジタル化や、ITを使ったビジネスプロセス改革程度では不十分だ。
機能別組織から脱却して、顧客ニーズを吸い取ってフィードバックループを回すような組織へ変革すべきだろう。
それが、製造業のDX変革で目指すべき形になるだろうと考えている。