ツール導入の失敗はアーキテクチャの不整合によって起こる
ほとんど？が失敗すると言われるツール導入。その原因はググれば沢山出てきます。このnoteでは失敗原因としてあまり触れられていない「アーキテクチャ」という視点で、失敗の原因と対策について考えます。
アーキテクチャとは何か？
この記事の主題は、ツール導入の失敗は、「組織アーキテクチャと、導入しようとしているツールの製品アーキテクチャ間の不整合で起きる」というものです。
アーキテクチャとは、建築学や建築術、構造を意味する言葉です。建築の世界で使われる言葉です。システムの構造を表す「システム・アーキテクチャ」という言葉を耳にすることも多いと思います。私がこの言葉を知ったのは、藤本隆宏先生編著の『ビジネス・アーキテクチャ: 製品・組織・プロセスの戦略的設計』でした。
この書籍では、アーキテクチャを下記のように定義しています。
システムの性質を理解するための概念。
構成要素間の相互依存関係のパターンで記述されるシステムの性質。
この定義はかなり広範なものなので、もう少し狭い定義のものを探すと、国際電気電子工学会 (IEEE) では下記のように定義されています。
「アーキテクチャとは、様々な部品、部品間の繋ぎ方、部品の(使用)環境との関係に組み込まれている(製品)システムの基本構造とそのような基本構造に関する設計・進化(方向)に関する指針である。」
ざっくり一言でいえば、「製品のつくり方の方針、パターン」です。これを製品アーキテクチャといいます。
モジュラー型とインテグラル型アーキテクチャ
アーキテクチャは「モジュラー型」と「インテグラル型」の２種類に大別されます。2種類のアーキテクチャの違いは下図のようになります。
モジュラー型は部品間の設計の 「擦り合わせ」が必要ない製品です。製品やシステムを構成する部品(モジュール)の間のつなぎ方(インターフェース)を事前にルール化しておき、そのルールに従えば、個々の部品を比較的独立して設計開発できるようになります。
一方のインテグラル型は、部品間の相互依存関係を維持し、調整や「擦り合わせ」を繰り返しながら、全体を成立させるようなアーキテクチャです。
2つのアーキテクチャの特徴を比較すると下図のようになります。
アーキテクチャは製品づくり（製造）だけでなく、企業活動にかかわる複数のシステムに適用できます。「流通アーキテクチャ」もあれば「販売アーキテクチャ」もあります。マーケティング、流通、販売、顧客サポートという一連のビジネスプロセスを構成する要素間の関係にまで広げれば「ビジネスアーキテクチャ」になります。
組織のアーキテクチャ
アーキテクチャは組織にも適用できます。製品、流通、販売といったアーキテクチャのもとで、実際に設計や生産、取引などの活動を行うのは人間です。それぞれの仕事・役割があり、協業するシステムがあります。この人間のシステムを「組織アーキテクチャ」といいます。
組織アーキテクチャという以上、モジュラー型とインテグラル型の種類があります。モジュラーとインテグラルのアーキテクチャの特性をふまえ、モジュラー型とインテグラル型の組織にはどんなものがあるだろう？と考えたとき、私が思いついたのが、モジュラー型はルーティンワーク、インテグラル型はプロジェクトといえるのではないか、ということでした。
会社の多くの仕事は、それぞれの部署が独立し、分業で行われています。部分間の調整コストが少なく、相互依存が低くすむようにマニュアルを磨きこんだルーティン業務が各部署＝部分で行われています。
一方、新規事業開発や既存製品のフルモデルチェンジ、看板商品のリブランディングなど、複数部署が横断的に連携する仕事は一般的にプロジェクトの名が冠されることが多いです。
製品づくりにおいては設計、製造、品質保証などの担当者がこまかな品質の擦り合わせを行います。利用規約をゼロからつくる上では法務と営業が売りやすくかつ安心してもらえて問題が起きにくい内容をつくり上げていきます。新しい取引先開拓のなかで売れる業界と売れない業界を見極め、それをマーケティングやPRに連携して発信するメッセージを調整します。部署間の調整・擦り合わせ、コミュニケーションの量はルーティンよりもはるかに多くなります。
ツール導入の失敗は、組織アーキテクチャと導入しようとしているツールの製品アーキテクチャ間の不整合で起きる
ここまで製品アーキテクチャと組織アーキテクチャについて理解してきました。長くなってきたので、あらためて主題を確認します。主題は、ツール導入の失敗は「組織アーキテクチャと、導入しようとしているツールの製品アーキテクチャ間の不整合で起きる」です。
製品と組織のアーキテクチャの特徴を読みながら私が感じたのは、一部署（部門）で利用が完結するツールはモジュラーっぽく、複数部署にまたがって利用されるのはインテグラルっぽいなぁということでした。
例えば、freeeやSmartHRなどのSaas製品は部署完結的で、既存の業務の進め方が大きく変わるのではなく、多くの業務が機械化・自動化され、やらなくていいことが増えてどんどん効率化されていきます。
これに対し、CRMやMA製品はマーケティングやフィールドセールス、インサイドセールスなどに利用部署がまたがります。見込客にスコアをつけ、何点以上になったらこれこれのトークスクリプトで電話をし、アポイントがとれたらヒアリングした情報をシステムに入力して営業が商談しやすいようにする―といった、業務間の擦り合わせを必要とします。このような仕事も定着すればインテグラルからモジュラーに移行していきますが、少なくとも導入当初はインテグラル型組織のような進め方をすることになります。
ここで製品と組織のアーキテクチャの特徴を四象限で整理してみましょう。
freeeのような、利用が一部署で閉じていて、調整や擦り合わせを必要としない製品は左上に入ります。得られる成果としては、構成要素内部での価値の創造や非効率な調整の排除があります。
利用が複数部署にまたがり、調整や擦り合わせを必要とするMAなどの製品は右下に入ります。システム全体での価値の創造、不明確な相互作用や相互依存を効果的、発展的に調整し、より大きな成果を得ることができます。
利用が一部署で閉じていて、調整や擦り合わせを必要とする製品と、利用が複数部署にまたがり、調整や擦り合わせを必要としない製品はパッと思いつきませんが、この両者の組み合わせは得られる効果がない・少ないです。
この製品と組織のアーキテクチャの組み合わせの適合・不適合を先の四象限にプロットすると下図のようになります。
ツールはたいてい既存のルーティン組織 ＝ モジュラーアーキテクチャに導入されるでしょう。
部署完結的な製品が、従来の組織構造を変えることなく導入される分には、ツール導入が失敗するということはあまりないと思います。
失敗するのは右上の象限です。インテグラル的な製品を必要とする仕事は、インテグラル＝プロジェクト組織が使うことで効果を得られます。しかし、組織がルーティン＝モジュラー的な組織のマインドセットでインテグラル的な製品を使おうとしても、うまくいかないのではないでしょうか？
例えば、マーケティング部がMA製品を導入したとして、見込客の行動に応じたスコアリングやメールの自動送信など自部署だけで完結する機能であれば、問題は起きません。調整や擦り合わせの数は少なく、相互依存の度合いも低く済みます。
しかし、上述したようにインサイドセールスや営業も巻き込んでいこうとなると、調整や擦り合わせの量が増えます。今までは機械的にやれていた業務は都度確認を要し、こうした仕事の仕方を非効率と思うようになります。いえ、モジュラー的なマインドセットのままでは、こうした擦り合わせが必要になるという認識すらないまま、擦り合わせは行われず、製品導入の価値を感じることなく、静かに製品が使われなくなり、解約するということもあります。
モジュラー型＝ルーティン的な組織が、モジュラー的なマインドセットのまま、インテグラル型の製品を導入すると失敗する。
これがこのnoteで伝えたかったことです。そして、その対応策は何かというと、ルーティン的な組織及びマインドセットを一時的にプロジェクト型に変えることです。
ツール導入時に、「◯◯プロジェクト」と銘打って組織横断的のプロジェクトチームをつくるというのは、上述の内容にまったくもって適っています。ただ、肝心なのは、チームをつくるだけでは不十分で、マインドセットも変えなくてはいけないということです。
そしてもう一つ大事なことは、モジュラー的な仕事の進め方に慣れてきた人々が、インテグラル型の仕事を進めるために必要な文書（ドキュメント）の作り方や会議の進め方、合意形成の仕方といったお作法や道具を習得した方がいいということです。
ルーティン業務のなかで使ってきたものがそのまま使えるものはあるでしょう。しかし、モジュラー型組織で少ない擦り合わせ、情報のやり取り、少ない認識のズレや齟齬で行ってきた仕事の仕方は、インテグラル型の仕事の仕方には使えません。
こうしたモジュラー型の仕事の仕方に慣れてきた人が、インテグラル型の組織をつくり、プロジェクトを進めていくための道具として「プ譜」があります。プ譜は習得コストが低く、扱いやすいプロジェクトの設計図を書くための道具です。その道具を使った合意形成の仕方や仕事の任せ方などのアクティビティも備えています。
文字量が増えてきたので、プ譜の合意形成方法や活用方法についてもう少し知りたいと思っていただいた方は、下記の関連記事をご覧ください。
未知なる目標に向かっていくプロジェクトを、興して、進めて、振り返っていく力を、子どもと大人に養うべく活動しています。プ譜を使ったワークショップ情報やプロジェクトについてのよもやま話を書いていきます。よろしくお願いします。