プロジェクトを失敗させる罠15：制度や習慣をスクラップしない
本日発売の
「プロジェクトを失敗させる55の罠」はその名の通り、「罠についての説明が55セット＋終章」という構成になっている。
罠についての説明は型が決まっている方が読みやすので、
・どんな罠か？
・もう少し詳しく
・なぜこんなことが？
・症状が悪化すると？
・さらに踏み込むと......
・対処法
という構成を踏襲している。
サンプルとして1つ読んでもらうのが手っ取り早いと思うので、（どれでもいいと思うのだが）いまたまたま目についた罠15をブログに掲載しよう。
****************
罠15：制度や習慣をスクラップしない
フェーズ：Business Model（施策立案）
★どんな罠か？
・様々な要請から、新しい制度、新しいルール、新しい商習慣が追加される
・一方で業務改革プロジェクトをやっても、古い制度、ルール、習慣は捨てられない
・だから、どんどん積み上がる
・制度やルールを実行するための業務もシステムもどんどん複雑になっていく。もちろんシステム構築費用はそれにともない高額に
★もう少し詳しく
業務改革の教科書には必ず、「効率化を目指すならば、業務を自動化したり手順を変更するよりも、その業務をなくしてしまうのが1番効果がある」と書いてある。だが長年日本企業で業務改革をやってきて、今あるものをなくすことが、いかに困難かを思い知らされてきた。
商品ラインナップ、サービス体系、人事制度のような、「制度」に近いオフィシャルなものから、サービスする上で顧客へのちょっとした約束ごとのような「慣習」にいたるまで、今やっていることをストップすることは極めて困難だ。
スクラップ&ビルドという言葉があるが、以前一緒に業務改革に取り組んでいた方が「日本企業はビルド&ビルドしかやらないんだよね」と呟いていた。ですよね......。
ある業務改革プロジェクトで問題になったのは、「顧客A社に配送する際は、午前着/午後着の要望を聞く」という慣習だった。他社に配送する際も配送日を決めるが、時刻はいつでもよかった。この様なA社だけの特別待遇は、業務効率化やシステム化の敵である（例えば自動で配車を計画するロジックを作る際の障害となる）。この慣習をやめることにしたのだが、A社の営業担当者から強い反対にあってしまった。
時間をかけて調べた所、
・もちろんA社との契約条件に、この対応は明記されていない
・10年以上前に、A社から午前着/午後着の指定をさせて欲しいという要望があった
・ところがA社に詳しく聞くと、現在は午前でも午後でも構わないことが分かった
・機嫌を損ないたくないため、A社担当の営業はこの話を持ち出すこと自体、避けたいと思っていた
という状況だった。誰の迷惑にならないこのケースですら、習慣をやめるためにはこれほど手間がかかる。A社が少しでも「午前／午後を指定できないと困るんですけど......」と言ったら、やめるのは絶望だ。
ちなみに今回の罠はスクラップがテーマだが、顧客に対して変化を求めることだけでも、および腰になる日本企業が多い。例えば顧客にもデジタル対応を求めるような施策（現在FAXで受け付けている注文をWebに切り替えるなど）はDXの定番だが、なかなか踏み切れない。
顧客のITリテラシーを心配する声が多いが、現在の中堅社員が社会人になった時には会社にパソコンがあったと思うのだが......。こうなると、実際に主要顧客の声を集めて説得するしかない。
社内であっても、人事制度の廃止はかなり困難だ。日本企業では労組との関係で、不利益変更（従業員に不利益となるような制度変更）がかなり難しいからだ。対象者が数人しかいなかったとしても。
この様に業務改革プロジェクトでは毎回、やめることに対して強い抵抗を受ける。そのため、日本企業には新しい制度や慣習が積み上がり、少しでもそれを楽にするために、システムに特別な機能が作られていく。
★なぜこんなことが？
新しい制度／ルールは該当者ゼロからスタートすることが多いので反対されないが、既存制度を廃止する際は不利益を被る該当者（社員や顧客）がいることが多い。これがやめるのが難しい理由だ。
コロナ禍を機に急速に広まったフルリモートワークを思い浮かべて欲しい。制度が作られた際は、静観ないし歓迎する社員が多かった。だが出社の強制という形で制度を廃止した企業では、かなりの反発が起きた。
新しいサービス体系の導入（例えば使い放題プラン1ヶ月〇〇円ポッキリ）なども、同じ構造だ。スタート時点では利用者ゼロなので反対する人はいないが、廃止する場合は顧客からのクレームや離反を意識せざるを得ない。
そして日本企業では、そういった反対を過剰に避ける傾向がある。とにかくコンフリクトを避けるようとするのが日本企業の組織特性だ（「罠19 野蛮さ不足」、「罠49 コンフリクトを避ける」を参照）。
そのため新しい制度を作る際に、既存の制度を廃止せず、二重運用しようとする。もちろん業務は複雑になる。つまり制度は本質的に、始めやすくやめにくいものなのだ。
スクラップの決断ができないことについて、リーダーシップ不足だと書いてある本が多い。だがわたしは、その様な個人資質の問題ではなく、「責任所在が不明確」という組織の問題だと考えている。
商品や習慣をスクラップして、100社ある顧客の中の1社がクレームを言ってきたとしよう。この場合、日本企業ではスクラップを決断した人の失敗と見なされがちだ。
一方で無駄なものをスクラップしないなら、クレームは来ない。その代わりにじわじわとコストが上がり、競争力が徐々にそがれる。この場合は誰も責任を問われない。本来は事業全体の利益に責任を持つ人がいるはずだが、因果関係と責任構造が不明確なため、スクラップしないことの責任は問われにくい。このような力学が働いて、スクラップを異様に避ける組織文化になっているのではないだろうか。
★症状が悪化すると？
ビルド&ビルドを続け、業務が複雑になるデメリットはなんだろうか？
まず人間では到底やれないほど業務が複雑になるのでので、ビジネスロジックを全てシステムに実装するようになる。システムによる効率化は良いことだが、当然システム構築費は上がる。
ITエンジニアは頻繁に「なんでこんなにカネがかかるのか！」と言われるが、「皆さんがひたすらビルド&ビルドを続けるからです」としか言いようがない。他社にない複雑な機能を求めると汎用パッケージを活用できなくなるので、急に値段があがるのですよ......。
そして業務担当者は意識しないが、システムの初期構築費用よりも、保守費の方が複雑さに弱い（複雑になればなるほど、コストが急激な上昇カーブを描く）。複雑なシステムを改修する際は、影響範囲を慎重に調べなければならない。これが高い保守費用や、改修を依頼した際のリードタイムの長さに直結している。
こうして複雑なルールや手順をシステムに実装していくと、ロジックが隠蔽され、その業務の担当者であっても、複雑すぎて把握できなくなる。以前人事領域のプロジェクトで「こんな手当が支給されているなんて、人事部のわたしも知りませんでした。自分も支給対象だったんですけどね」という言葉を聞いたことがある。
制度や慣習が複雑になっても、全てシステムで計算してくれるならば、業務担当者は痛みを感じない。だが、この「業務担当者が、業務の詳細を把握していない」という状態は、後ほど登場する「罠29 要件定義の障壁」という深刻な罠を引き起こす。
「人間がやるよりシステムがやったほうが効率が良い」と思われているが、制度や業務がないのが、一番低コストなことを忘れるべきではない。
★さらに踏み込むと......
この罠では「ビルド&ビルドしかしないプロジェクト」を取り上げているが、通常は新しくビルドを成し遂げたプロジェクトは成功と見なされる。「新しく在宅勤務制度を整えました！」「きめ細かい顧客要望に自動で対応できるようにしました！」といった具合に。
しかし前述のように、こうして新しく作った制度や慣習は、将来スクラップしにくいので、積み上がる。そして確実に企業を蝕む。長い目で見れば、事業を高コスト体質に導くのだから、隠れた失敗プロジェクトなのかもしれない。
販売促進施策では、この構図が特に起きやすい。例えば「期間中に入会した人は、特定の特典をずっと享受できる」みたいなキャンペーンがあったとしよう。これがヒットして多くの入会者を集められたら、企画した人は称賛されるだろう。
だがヒットしようがしまいが、以降ずっと「この人は特典を受けられる人か？」を判断し、対応を変える面倒は残り続ける。キャンペーンは一瞬、非効率さは永続的。だが販促を企画する人はこの面倒を自分で背負う訳では無いので、実感がない。こうして非効率な業務がスクラップされるどころか、次々と増えていってしまう......。
★対処法
「スクラップできない」という罠に対抗するためには、パッケージによるギブス効果が有効だ。ギブス効果とは「このERPパッケージではこれしかできません。だから制度や業務を変えてください」と強制力を働かせること。
例えば「契約のタイミングで価格が決定されている必要があります」だとか「給与の計算方法が変わるので、Flex勤務の対象者にする際は人事発令を出す必要があります」などだ。
制度や習慣をスクラップできない大きな要因は、反発が予想されること。そして決定の責任者になると、その反発を一身に受けなければならないことだ。これは精神的にツラい立場だし、今後のキャリアとしても避けたい。だが「パッケージの制約で、できないんです」という言い訳が立つならば、「お前が決めたんだな」という圧力を随分減らせる。
※「罠17 覚悟なきFit to Standard」で、パッケージが提示する「これがグローバルスタンダードなので、御社も合わせましょう」という方針を掲げることの危うさを説明する。スローガンを掲げて盲目的に進めるのではなく、制度や習慣をスクラップするテコとしてパッケージ制約を使おう、というのがここでの主旨だ。
このようなテクニック論とは別に、反発を恐れるマインドを変える必要もあるだろう。この10年ほどで、海外企業が提供するSaaSを仕事で使うことが増えた（Slackのようなチャットツールや、Zoomのような会議ツールを思い浮かべてください）。
使っていて驚くのは、ユーザーに予告なしで機能やユーザーインターフェイスがどんどん変わることだ。慣れ親しんでいた機能がスクラップされてしまうこともあり、ユーザーとしては反発を覚えることもある。
だがこの様なSaaSベンダーは「既存ユーザーに気を使いすぎると、製品の進化が鈍り、長期的には競争に負けてしまう」という切迫感があるのだろう。不満を持つユーザーが契約を解除する引き金になるかもしれない。でも事業全体の視点からは進化させることは絶対的な正義だと。
顧客の数など、日本企業が置かれている状況とは違う点も多いが、この「眼の前の顧客の不満よりも、事業全体のメリットから判断する」という姿勢を少しは見習ったほうが良いのではないだろうか。蓄積された複雑さによって、ずっと疲弊しているのだから。
最後にもう一つ。先ほど「スクラップの決断ができない理由は、リーダーシップ不足よりも、責任の所在が不明確なこと」と書いた。この考えは揺るがないが、いよいよスクラップを決断した際には、実行に移す段階で、反対派をも従わせるリーダーシップが必要となる。あなたのプロジェクトには、その覚悟が備わったリーダーがいるのだろうか？
※このテーマは「罠25 リーダーシップ不足」で再度掘り下げる。
★関連する罠
罠19「野蛮さ不足」
罠29「要件定義の障壁」
罠49「コンフリクトを避ける」