意思決定と変革者
人類は、9割の人間がリスクを回避したから、現在まで生存している。そして、人類の1割の人間が挑んだから、今の文化や技術がある。
そんな話を耳にしたことがあります。全員が未開の地に踏み出していれば、集団としての生存確率は大きく下がったでしょう。一方で、誰も踏み出さなければ、環境の変化に適応できず、いずれ淘汰されていたはずです。
結果として人類は、「多くが守り、少数が挑む」、そんな構造の中で生き延び、広がってきたのだと言えます。この構造は、組織の意思決定を取り巻く力学、特にERP導入プロジェクトで起きることとよく似ています。
本稿では、意思決定がうまく機能しなくなる場面と、変革者の気づきが感情を伴うやり取りによって遮断されてしまう構造、そしてそれをどう扱えば前に進められるのかを考えます。
プロジェクトで起きる多数決
ERP導入プロジェクトでは、“Factに基づく”ことを重視し、現場の声を大切にします。その延長として、「関係者全員で決める」という姿勢が取られることも少なくありません。ただ、全員で決めようとする限り、意思決定は安全な方向に寄りやすい傾向があります。これは一人ひとりの性格の問題というより、会議の構造から自然に生まれるものです。
ここで言う安全な方向とは、多くの場合「今の仕事の延長」を指します。ERP導入の現場では、この傾向が非常に分かりやすい形で現れます。
議論の出発点は、たいてい「今の仕事の仕方」です。Factに基づこうとすると、誰もが共通して話せるのは現行業務になります。業務を実際に担っている方の説明は具体的で、資料や実例も揃っているため、説得力を持ちます。その結果、議論の中心は自然に「今、どうしているか」「どこが大変か」に置かれていきます。
さらに、全員が集まる場では、異論が出にくくなります。現行業務への問いかけは、相手の仕事そのものを否定するように受け取られやすく、言い回しにも気を遣うことになります。そのため、異論があったとしても、“みんながいる場では言いづらい”という空気が働き、表に出にくくなります。
こうした条件が重なることで、議論は「今の仕事の仕方」から始まり、いつの間にか「ERPに実装すべき要求事項」へと姿を変えていきます。
「今の発注書の備考欄は…だから100文字入力できること」
「この例外処理は…だから必要」
「承認ルートは…だから変えられない」
この結果、Fit to Standardからは少しずつ遠ざかっていきます。一方で、これからどう変わるのかという姿は、はっきりしないままです。こうした光景は、ERP導入の現場では決して珍しいものではありません。
少数での議論
一方で、限られたメンバーで議論をすると、別の問いが生まれます。
「この作業の目的は何か」
「この承認は、本当に必要なのか」
「この例外を標準化できないか」
少数だと、意見をあげやすいのです。発言の正しさを競うというより、前提を並べ、目的を揃え、判断軸を作っていける。結果として、変革的な話が前に進みます。ERP導入が「今のやり方の移植」ではなく、「これからの運用を設計する作業」になっていくのは、こうした場での議論が機能したときです。
現場を巻き込むと起きる“反応”
ただし、その結論をそのまま現場に持ち込んでしまうと、その業務を担っている担当者からすると、否定されたように感じられるかもしれません。問いが間違っているというより、立っている前提が異なるからです。担当者の視点は、今日・明日の業務をどう成立させるかに置かれています。一方で、問いを投げかけている側の視点は、業務の目的や構造そのものを問い直すところにあります。
「それは正論だと思う」
「そこまで言うなら、自分でやってみてほしい」
これらは、問いに答える前に出てしまう反応です。言い換えると、論点を扱う“対応”というより、「理屈としては分かる。しかし今の条件では成立しない」という感覚が、思わず言葉として出てしまった“反応”です。
そして、このすれ違いが解消されないまま議論が続くと、やり取りは次第にエスカレーションしていきます。そのときに出てくるのが、次の言葉です。
「現場をわかっていない」
こうなるともう議論にならないでしょう。変革者の提案や確認に答える代わりに、「現場をわかっていない」という立場の指摘で一刀両断できてしまうからです。論点が「何が正しいか」から「誰の立場で語っているか」にすり替わった瞬間、目的や構造をどう設計するかという議論は、そこで止まってしまいます。
変革者の存在
「目的や構造」を基点に話をする人は、プロジェクトにとってとても重要な役割を担います。この人は、会議の空気に合わせて論点を曖昧にするのではなく、Factと因果で整理し、業務全体と将来の運用を見据えながら判断しようとします。「なぜこの手順なのか」「この判断は何を決めるためのものか」と問いを立て、結論を先送りしない。そうした自分なりの判断軸を持ち、必要な局面では意志をもって言い切る姿勢です。
本投稿では、このように目的ベースで物事を捉え、構造として考え続ける役割を担う人を「変革者」と呼びます。
問題は、この変革者の問いが、現場を巻き込む段階で「それはあなたの意見ですよね」と個人の主張として受け取られてしまう点にあります。問いの内容ではなく、「誰が言ったか」「どう言ったか」に焦点が移ると、せっかく前に進んでいた論点が止まり、変革者本人が消耗していきます。
目的ベースで考えるこの人を、どうすればプロジェクトの中で活かせるのか。そのための仕組みを用意できているかどうかが、変革を前に進められるかを左右します。
変革者が価値を出せるメカニズム
ERP導入プロジェクトでは、チェンジマネジメントが重要な役割を果たします。焦点になるのは、変革者が安心して問いを投げかけられる状態を、プロジェクトとして用意できているかどうかです。そして、変革者の投げかけが個人の主張として処理されるのではなく、メンバーに受け入れられ、議論として扱われるためのメカニズムが重要になります。
前のパートで触れた通り、現場の議論と、変える前提の議論は、役割も機能も異なります。これを同じ場で扱うと噛み合わなくなる。だからこそ、問いの扱い方をプロジェクトとして整理しておく必要があります。
まず置くべきなのは、共通の前提です。
「これは改革プロジェクトである」
この前提が共有されると、問いの位置づけを正当化できます。変革者の発言は、個人の意見として扱われてしまうことなく、プロジェクトとして検証すべき論点として議題に上がるようになります。いわゆる「正論だ」で片付けられてしまう状態から、「確かめて決める」状態へ、議論の土台が移っていきます。
そして、論点として扱われた問いは、最終的に二つに分けて整理されます。ひとつは意思決定であり、もうひとつは、その意思決定を現場で成り立たせるためのMoSCoWの受入基準です。
ここで言う意思決定とは、「これで決まり」と宣言することではありません。業務をどの方向へ変えていくのかを定め、その判断が繰り返し使われるための基準を置くことです。その際に拠り所になるのが、どの程度の頻度で発生するのか、そして起きたときに業務や統制へどれほど影響を与えるのか、という視点です。
例えば、生産計画の立案において、Excelへの出力をやめる、という判断をしたとします。これは、「計画はERP上で作り、ERP上で確定させる」という方向性を定める意思決定です。Excelを使うか使わないかという操作の話ではなく、計画を個人のファイルではなく、共通の仕組みの中で扱う、という前提を置くことに意味があります。
一方でMoSCoWの受入基準とは、その基準に従って業務を回すために必要な準備や段取りのことです。生産計画の例で言えば、計画を確認・修正する担当者がERPの画面上で必要な情報を一通り確認できること、日々の微調整が発生した際にも「とりあえずExcelで直す」必要がなくなる操作手順が用意されていること、計画変更の履歴や理由が後から追えること、月次や週次の報告に必要な数字がERPからそのまま取り出せること、といった点が受入基準になります。
これらは、Excel出力をやめるかどうかを決める話ではありません。決めた方向を現場で止めずに回すために、確認しておくべき基準です。検証や実践を通じて確かめながら、運用に耐える形へと整えていきます。
ここで注意することは、MoSCoWの受入基準を先に考えてしまうと、判断の軸が「現場で運用できるかどうか」に引き寄せられ、業務の方向性そのものを決めきれなくなる点です。先に意思決定で方向を定め、その後に成立条件を詰める。この順番を守ることで、変革者の問いは対立の火種ではなく、改革を前に進めるための論点として機能します。
眠っていた価値が現れる
このメカニズムは、これまで社内の評価軸に乗ってこなかった視点を、自然と前に出す働きを持っています。日常業務では、その問いが扱われる場がなかったとしても、業務の構造に違和感を持ち続け、「このままで良いのだろうか」と考えてきた人は、どの組織にもいます。そうした問いがプロジェクトの議論として扱われるようになることで、組織の中に眠っていた力が、ようやく実際の仕事の中で活かされる状態になります。
1割の変革のための問いや議題が、9割のメンバーにとっても納得できる形で扱われる。そのためのメカニズムが組織に定着することで、ERP導入プロジェクトが終わった後も、変革を続けられる組織へと成長を遂げることでしょう。
