「現場と企画の乖離」がプロジェクトを失敗させる、あるいは没となった章を丸ごと載せる試み

1年くらい前から
「プロジェクトを失敗させる50の罠
～あるいは失敗パターンを知り、プロジェクトを成功に導く方法～」
という本を書いている。もちろんタイトルは仮題だけど。

今は33章を書いているので、折り返し地点は過ぎている。でも仕上げに時間がかかるから、きっと年内に出版できれば上出来、という感じだろう。

執筆については何度かこのブログでも書いているが、これまで触れていなかったこととして、「効率度外視」という話がある。

書いてみないと分からない、という性質がかなり強く、手を動かしていると何を書くべきなのか、どう書くべきなのかがようやく見えてくる。だから事前に概要を固め、あとはその通りに作業する、という通常の仕事でやっているワークスタイルが通用しない。だから僕は「アジャイル型執筆」という方法を推奨している。
（ちなみに50の罠、という仮題だが、何個になるかは書いてみないと分からない）

あと「効率を無視して資源を投入しないと良い本が書けない」という事情もあるため、どれくらいの工数が必要かは、事前には分からない。他の仕事では「90%を100%に上げるために膨大な時間を使うよりは、さっさと出荷しろ」が正しいことが多いのだが、本は最後の10%のクオリティが勝負なんじゃないか？とも思う。
だから僕は普段の仕事（ブログを含め）とは全く仕事のモードをかえ、効率度外視で本を書いている。
　
　
先日は日曜日に会社に行き、1章を書き上げた。そして会社の巨大スクリーンでサッカーを見て、ひいきのチームのパフォーマンスに憮然としながら、その日書いた章を読み返した。そしてまるっと没にすることに決めた。効率が悪いというより、生産性ゼロの日曜日。
　
しかし没原稿をブログに流用することで成仏させることはできる、と思い直した。
本に載せるクオリティには達していなくても、無料であれば読む人もいるだろうし、誰かの役にたつこともあるだろう。浦和が弱いという事実は覆せないが、没原稿は再利用できる。
　
プロジェクトを失敗させる罠について、だいたい同じ構成で書いている。実際に失敗する前にこういう話をたくさん読みたい、という人がいたら、いずれ出版される本を買ってください。
ちなみに、本に乗っている文章は、以下の点でこのブログよりも優れています。

・少なくともこれよりはクオリティが高い（だからこれが没になった）
・ほとんどの章はこれよりも具体的、実践的（この章はちょっと人間関係に偏った内容なので。だから没になった）
　
　
******************
罠33：現場と企画の乖離
******************
フェーズ：Scope
カテゴリ：チームビルディング
　
★どんな罠か？
•プロジェクトに協力してもらおうと説明会を開くが、白けたムードで質問もない
•親しい同僚から聞き出すと「経営企画がまたなんかやってる」「またシステム変わって使いづらくなるの」という本音が
•協力がないとうまくいかないので、拝み倒してミーティングに参加して「いただく」
•現場からそっぽを向かれて、いったい誰のために、そして何のためにやっているプロジェクトなのだろうか・・
　
　
★もう少し詳しく
大企業では「プロジェクトの実行主体≠主な業務担当者、主なユーザー」という構図のプロジェクトが多い。プロジェクトの実行主体は経営企画やIT企画など、プロジェクトをやることが仕事の人々。後者は工場でモノを作ったり、倉庫で出荷するなどの現場仕事をしている人々。
　
しかもこの2つの立場はたいてい、かなり違うバックグラウンドの人々で構成されている。前者は本社採用、中途入社多め、親会社からの出向者多め、または社外のコンサルタント。後者は地域採用、生え抜き社員、非大卒・・といった具合に。
　
このような立場の違い、バックグラウンドの違いがあるので、前者の人々がプロジェクトを始めると「アイツラが、また俺らの仕事にケチを付けてなんかやるらしいぞ」という構図になりがちだ。こうなると、たとえ変革の方向性が経営的に妥当であったとしても、うまくいかない。人間はそんなに合理的ではないので。
　
現場と企画が乖離していると、どのように困るだろうか。
•プロジェクトの打ち合わせには、受け身的な参加（呼ばれたから来ましたけど？）
•業務やシステムの将来像は現場としては困ることが多いので、打ち合わせの度に指摘し、議論が前に進まない
•それをプロジェクト側は「現場からの抵抗」と受け取る
•結局、現場はいまの業務を変えない。新しいシステムを使わない（前章参照）

現場の人々に悪意があるというよりは、現場での自分の責任を果たすために、良かれと思った結果である。だがプロジェクトを推進している側としては、非協力的な態度に困り果てる。
　
　
★なぜこんなことが？
なぜここまで感情的にこじれているのだろうか。
そもそも企画部門は「未来に向けた正しさ」を語り、現場は「現在のリアリティ」を握っているのだから、向いている方向がある程度ズレていても仕方ない。だがひどいケースだと、プロジェクトの説明を始める前から喧嘩腰の人もいる。つまり変革の内容ではなく、変革自体にうんざりしているのだ。これはおそらく、前回のプロジェクトが「やり散らかし系」だったためだろう。
•DXなど、立派なお題目はあるが内容が乏しいプロジェクトに巻き込まれた（1章「やることだけ決まっている」参照）
•業務をパッケージに合わせろ、などと無理難題を強引に言ってくる（18章「Fit to Standard信仰」
•大騒ぎして役に立たないシステムを作っただけ（前章「組織受入態勢の軽視」参照）

など、これまで説明してきた罠のしわ寄せが現場に押し付けられてきた。だから「本社の奴らが企画する"プロジェクト"に気をつけろ」というマインドになっていても、不思議はない。
経営者を含めてプロジェクトを企画する多くの人が理解していないのだが、現場の変革マインドは有限資源だ。何度も変革をぶち上げていると「またか」「どうせ」と思われる。現業を抱えている人は忙しいのだ。そうして変革プロジェクトに協力しなくなり、やればやるほどプロジェクト成功率が下がる。負のスパイラルだ。
　
現場にそっぽ向かれるもう一つの原因は、プロジェクト推進者達が変革をやること自体を目的に活動しているのが、透けて見えることだ。特に「DX推進室」「BPR推進室」と名付けられた組織は、当然ながら変革することが組織のミッションとなる。一方で現場部門の人々は目の前の仕事をより効果的にするために日々頑張っているので、微妙なギャップが生まれてしまう。
　
現場部門が現業で忙しく、プロジェクトを企画部門からのメンバーのみで構成してしまう場合、この乖離はさらに広がる。各部門からも参加するのだが、専業ではなく片手間、ボランティアで参加の参加になると、どうしても「主体的にプロジェクトをやる」ではなく「お客様として、聞かれたことにこたえるだけの参加」になってしまう。（19章「メンバーが皆ひとごと」参照）
　
これら「立場の違い」「参加度合いの違い」が存在しているため、そもそも乖離が生まれやすい状況なのだが、肝心の変革の中身についても意見が合わないことが多い。

企画「全社的な観点からすると、〇〇をなんとしてでも変えないと」という切迫感
現場「我々が日々の仕事で本当に困っていることではない」「やるべきことが沢山あるが、それは優先順位が高くない」というシラケ

という構図だ。
変革自体が目的の部署があり、全社最適と部分最適が食い違い、「ウチらvsあいつら」という構図になりやすい。これらは結局、大企業病の一病態である。
　
　
★さらに踏み込むと・・
表立った対立をしていないのに、企画と現場が乖離していることもある。あるプロジェクトで課題分析をした結果、「顧客から要望されると決められた納期を無理やり短縮する行為（納期短縮）」が業務効率を著しく落としていることが分かった。そのため①基本的には納期短縮は行わない、②やむを得ず納期短縮を行う場合は、別料金をいただく、というルールを設定することになった。別料金を請求するためのルールを設定し、システム機能も実装した。
　
だが1年後に再調査したところ、以前とほとんど変わらない件数の納期短縮が発生していたし、別料金もほとんど請求していなかった。この事例もプロジェクトチームと現場の乖離と言えるだろう。

プロジェクトチーム：利益を損なっている課題を解決するために、正しい料金体系を導入。これにより納期短縮の件数が減るか、売上向上のどちらかを得られる、という正論。
営業：「沢山売ること」を唯一のゴールとして活動している。納期短縮は大口顧客から依頼されることが多く、その商談をとるためにも、大口顧客との付き合いのためにも、断るわけにはいかない。それを理由とした値上げなんてとんでもない。

つまり「プロジェクトが目指す、全社目線でのきれいごと」と「現場が目指す、売上という絶対的なKPI」が乖離している状況だ。
他にも、貸し倒れを防止するために与信チェック機能をシステムに組み込んだところ、それをくぐり抜ける裏技が横行してしまったこともある。しかもやっている方はその裏技を全く悪いと思っていなかった。まるで「Excelをこう使うと便利ですよ」みたいな感じで、営業活動に欠かせないノウハウとして広まっていたのだ。
　

　
★症状が悪化すると？
プロジェクトの方針に対して、現場の人々が本当にナンセンスだと思うのであれば、「こんな無駄なプロジェクトに金を使うな」と真っ向から怒る義務があるはずだ。そういうプロジェクトももちろんある。そうなるとプロジェクト側としては大変だが、そう言ってくれればちゃんと議論ができる。
　
だが実際には「またなんかやり始めたな」と冷ややかにスルーすることが多い。大企業の場合は財布を共有している意識は希薄で、「全社の金を無駄に使うな」という感覚よりは「あっちの部門の金をつかってやってることだし」となりやすい。
　
そして残念ながらプロジェクトは失敗しやすいので、現場がそっぽを向いているうちに、勝手に頓挫する可能性が強い。だから真っ向から喧嘩するよりは、やり過ごした方が賢い対処なのだ・・。
　
　
★対処法
現場と企画が乖離している、というと「現場の巻き込みが足りない。もっと巻き込もう」という話になりがちだ。わたしもそういう話をしたことは何度もある。だが最近は「企画が現場を巻き込む」という構図自体が、無理がある気がしている。
　
そうではなく、最初から現場主体でプロジェクトを起こし、企画しなければならないのだ。その場合の企画部門の役割は変革のプロとして、進め方をリードすること。あくまで主体は業務を担当する部門でなければ、変革プロジェクトはうまくいかないのではないだろうか。
　
具体的には、
•プロジェクトオーナーは業務部門の管掌役員が望ましい
•プロジェクトマネージャーは業務部門から出すべき（たとえシステム構築プロジェクトであっても）
•プロジェクトルームは業務部門の隣に設置
•もし業務部門が本腰入れず、お客様気分でのプロジェクト参加が抜けないならば、プロジェクト中断
•プロジェクト方針は業務部門のトップが率先して宣言する
•その上で「全社最適を追求するために、この部門はどう変わるべきか？」を徹底して議論するところから始める
•（先の納期短縮の事例のように）プロジェクト方針に背く行為には、業務部門のトップから指導
といった具合だ。これくらいの姿勢で臨まなければ、現場と企画の乖離は防げない。
　
　
★関連する罠
10章「業務メンバー不足」
19章「メンバーが皆ひとごと」
25章「業務部門とIT部門の相互不信」

※「プロジェクトを失敗させる50の罠」を早く読みたい！という方がもしいたら、何らかの方法でこのブログをシェアしていただければ、白川のやる気がアップして出版が早まります。お願いします！