やらされプロジェクトの真因は「テーマとコンセプトの不在」

着目する問題：
どうしてプロジェクトが「やらされ」になるのか

受託開発プロジェクトを筆頭に、社内新規事業やDXプロジェクトなど、多くの取り組みが「やらされ」になってしまう現場が、実に多い昨今です。

どのプロジェクトも、企画したときや始めたときには、夢も希望もあったはずなのです。しかし、「総論賛成」のあとに浮上するのは、きまって「各論反対」で、あれやこれやと対応をしているうちに問題はこんがらがり始めます。言った、言わない、あの人が気に食わない、そもそもこれってどうなの、ていうかあれってどうなったの、と、諸説紛々しているうちに、だんだん関わるみんなが面倒になり、そっとファイルが閉じられ、脇に置かれていく―――

そんなプロジェクトを、見たことはありませんか。私は、しばしば、見かけてきました。見かけるだけでなく、巻き込まれたり、立て直したり、うまくいったり、いかなかったり、酸いも甘いも、嫌と言うほど、噛み分け続けてきました。

脇に置かれても誰も困らない案件なら、それはそれでいいのですが、特に受託開発プロジェクトの場合は、すでに提出され、承認されてしまった「見積」「計画」「契約」といったものがあって、臭いものに蓋をすることさえも難しい、なんてこともあります。

そうした状況に対して、多くの現場で取られている対処法は「ゴリ押し」です。

とにかくやれ、なんでもいいからやれ、なにかをやれ。
要望は全部リストアップしろ。
要望は全部、開発要件に盛り込め。
文句を言われないように、全部やれ。
面倒な話は、下請けに丸投げしてでもなんでもいい。
とにかく、やれ。

対して、上に政策あれば、下に対策あり。作業者や実行者の側の生存戦略としては、以下のような話もよく見かけます。

わかりました、言われたとおりに、やります。
言われたことはやりますが、言われなかったことは、やりません。
だから、ちゃんと、指示してくださいね。
バグですか？いえいえ、仕様です。
改修ですか？対応したいのはやまやまですが、工数が足りません。

知恵と勇気の助けなく、工夫もしない現場では「声が大きく、権力の強い立場」から「とにかく作業をこなす側」への一方通行的なコミュニケーションしか、起きません。

その構図は、

といった具合です。

このような、コミュニケーションが硬い直列関係にある現場では、価値というものは、生まれません。使いにくい、機能性やユーザーインターフェースの悪い成果物と、それに伴う単なる無駄な労働、時間とお金の無駄遣いが、生まれるだけです。

ちなみに「怒られないために、言われたとおりにやる」は、実は「プロジェクトマネジメント義務の放棄」です。体制図にはPMがいるが、誰もプロジェクトマネジメントしていない、という現場は、意外とよくあります。

それってなんだか、とてももったいない話だなと、思います。

やらされプロジェクトの諸悪の根源は、テーマの不在

どうしてプロジェクトが「やらされ」になるのか。それは、そのプロジェクトが、問われるべきテーマに、依拠していないからです。

種別	典型的なテーマ設定
受託開発	発注側：とにかく作業を自動化して、業務が楽になりたい 受託側：とにかく案件を受注して、経営が楽になりたい
社内新規事業	評価側：とにかくなんでもいいから、一発儲かる事業を作ってほしい　自走してほしい 実行側：とにかくなんでもいいから、やりたいことをやりたい
変革プロジェクト	経営側：とにかく変革して、一発逆転したい 推進側：とにかくなにかをやって、やってる感を出したい

こういうふうにストレートに書いてしまうと、「さすがにウチはそんなにひどくない」と思う人も多いかもしれません。

しかし、そういうふうに思うのは「ホンネ」を「美辞麗句」で装っているからです。

例えば、「生産性向上のために・・・」「多様性を・・・」「DXで・・・」「AIを活用し・・・」「最先端の・・・」「本質的な課題解決を・・・」「ASISとTOBEが・・」といったフレーズによって。それらの修飾語を全部キレイに取り去って「要するに、なにがしたいわけ？」というふうに、ズバッと見たときに浮き上がってくるのが、「ホンネ」です。

ちなみに、これらの「ホンネ」は、否定すべきものでもありません。なにかプロジェクトを始める動機って、そんなものといえば、そんなものです。

例えば、功成り名を遂げたカリスマ的人気ロックバンドも、最初に音楽活動を始めたきっかけは「異性にモテたかったから」ということだったりします。もちろん、みんながみんな、そうとは言いませんが、始めるときの動機は、高尚でなくとも構わないのです。

ただし、売れるバンドになるかならないかは、そこから「自分なりのテーマを立てられるか」に、かかっています。

どうして、いまのミュージックシーンって、▢▢なんだろう。
✕✕な要素を取り入れたら、もっと面白い音楽になるんじゃないか。

実際に、音楽活動に手を染めてみて、そんな問いを手にする日が来たら、「モテたい」という出発点から、踏み出すべき一歩を踏み出した、ということになります。

ビジネスプロジェクトも、まったく同じです。身も蓋もない動機がそのままテーマになってしまっているようでは、「総論賛成」のあとの「各論反対」に始まる諸々の摩擦を突破することは、できません。

動機をテーマに昇華するためには、以下のような思考プロセスを経る必要があります。

段階	内容
動機	とにかく、楽になりたい。 とにかく、成果を出したい。 とにかく、現状を変えたい。
素朴な疑問	楽になる、とは、どういうことか？ なぜ、苦しいのか？ 成果とは、なにか？ やりたいことは、なにか？ 現状とは、どんなふうになっているのか？ 何が問題なのか？ なぜ、変えたいのか？ 本当にみんな、本気で何かを変えたいのか？
徹底的な考察と、 一次情報の収集	実際に、話を聞いてみる。 実際に、データを見てみる。 最善から最悪までのシナリオを、ひと通り、描いてみる。 メッセージを、発してみる。 反応を、確かめる。
そのプロジェクトに固有の テーマへの昇華	本当の、我が社の経営や現場の理想とは「◯◯が✕✕であること」だ。 しかし、実態として、「△△が▢▢」となっている。 それは一体、なぜか？ 矛盾を解く鍵は、どこにあるのか？

ここでいう「◯◯」「✕✕」「△△」「▢▢」が、紋切り型のフレーズや、動機の焼き直しになってしまっているようでは、このプロセスは、失敗です。ロジックが単純に裏返しになっているだけで、情報としての膨らみがないものも、駄目です。流行っていること、よく言われていることや権威的な意見の借用も、いけません。

例えば以下は、情報システムのリプレイスプロジェクトを、あるユーザ企業が、あるベンダ企業に委託する、といった状況をイメージした場合の例です。

このふたつは、似ているようで、違います。

駄目な例の方は、誰に見せても「そりゃまぁ、そうだよな」という内容です。ベンダのセールストークを、発注側がそのまま鵜呑みにして横流ししたときに、ドキュメントに出て来やすいパターンです。お金の話が成り立つんだったら、積極的に反対する話ではない。

しかし、プロジェクトテーマとは、その取り組みのなかで関わるすべての人に提示したときに「そりゃまぁ、そうだよな」といった程度の感想を引き出すようなものではいけません。「そりゃまぁ、そうだよな」という程度のテーマ設定のほうが、異論は出にくいので、話は通りやすいのですが、結局のところ、話を一歩進めて具体化したときに「そんなはずじゃなかった」の大合唱が起きるのは、テーマ設定の甘さゆえなのです。

筋の良いテーマ設定とは、利害も立場も価値観も異なる、すべての関係者に対して、

「言われてみれば、確かに、そうだ」
「言いにくいことを、よく言ってくれた」
「でも、これだけではないかもしれない」
「いずれにしても、これを土台に、もっと話し合いたい」
「解決は難しいが、やっぱり、なんとかしたい」

と、思わせるものです。

こうした実のある議論は、「なぜ、いま、リプレイスなのか？」をベンダ側が適切に問い、それに対して、発注側がきちんと議論をしたときに、出てくるものです。

テーマ（問い）が立ったら、答え（コンセプト）を主張せよ

テーマとは、問題提起です。流行りの言い方をしたら、「問い」です。プロジェクトは、問うことからしか、始まりませんが、同時に、問題提起だけして、解決策や対案を出さないようでは、広げた風呂敷を閉じることも、できません。

ではその解決策とは、いかなる形で提出されるべきなのか。

「～～は、☆☆である」という「命題（コンセプト）」の形で提出されるべきものです。

「手段」しか頭にないせいで「手段」が「目的化」している場合、コンセプトはたいてい、駄目な例のようになります。

良い例は、ユーザ企業のビジネスモデルや成り立ち、哲学やビジョン、ミッションといったものを、きちんと掘り下げた場合の例です。

あくまで一例であり、みんながみんな、同じようなコンセプトになるわけではありません。むしろ、その企業、その場に固有のものでなくてはなりません。

コンセプトは、フレッシュでなくては意味がありません。賛否両論を巻き起こすぐらいの、インパクトがほしいところです。

侃々諤々の議論の果てに

「やっぱりそうだ」
「大変だけど、やんなきゃな」
「自分にできることは、なんだろうか」

と、関係各位に、思わせることができるかどうかが鍵です。

駄目な例の行き着く先は「膨大な要望リスト」と「関係者の全員が、意味もないのに、ひたすらやらされる毎日」です。「自分ごと化しろ」という号令だけが響き、だれも自分ごと化しない、つまらない現場と製品ができあがるだけです。

良い例の行き着く先は「困難な壁はあるが、それを乗り越えるための、知恵が絞る毎日」です。「あれはおれが」「おれはあれを」という、タスクと成果のぶんどり合戦の先に、「大変だったけど、やってよかったな」というエンディングが待っています。

テーマとコンセプトの幸福な関係

受託開発プロジェクトにおいて、もっとも美しいのは、以下の流れです。

①問い合わせや商談のなかで、テーマとコンセプトに「当たり」をつける
②見積検討や企画提案の段階で、仮説としてそれをぶつけ、賛同を得る
③要件定義の過程を通してそれを具体化、詳細化し、方向性が合っていることを確かめる
④実際の設計や開発を行い、見事に欲しかった成果物を手にする

ただ、通常、そんなキレイには行きません。やってみないとわからない、話してみないとわからない、作ってみないとわからない要素が、あまりにも多いからです。ですので、実践的には

①営業活動のなかで、とにかく「テーマ」だけはしっかりと掘り下げる
②見積検討や企画提案の段階では、期待する成果や効果のフェアウェイとOBラインを握る
③要件定義の過程を通して喧々諤々と議論し「これだ！」と双方納得できるコンセプトを見つけていく
④コンセプトを具現化するための、創造的な設計と実装を行う

責任分担の構図としては、以下のような形となるはずです。

「テーマ（問い）」の質が低いようでは、「コンセプト（答え）」の質が高まることは永遠にありません。しかし、解決策や技術論に疎い決裁者や営業側は、うまくテーマを立てることができないことも、ままあります。

ゆえに、鍵を握るのはPMです。

PMは、「良い問いを投げてもらうのを待っている」という姿勢でいては、いけません。むしろ、粗悪な問いをブラッシュアップするために、四方八方から働きかけをしなくてはなりません。

自身の役割を「納品作業の交通整理屋」と自認しているPMがには、そういう動きを取ることは、できません。確かに、そのような職人肌のPMも、いても構いませんが、本当の意味で価値創造をするPMは「テーマとコンセプト」を、出来うる限り良質なもの、あるべきものにするために、通常の責任範囲を逸脱することを、いとわないものです。

テーマは、深く。出来うる限り、深く。
「それ、言っちゃうの！？」というような、爆弾発言を恐れないのが理想です。

コンセプトは、面白く。
「なるほど！」「そこだったか！」「確かに！」という、意外性と納得感があると、人は関心を持ちます。関心が集まると、状況が動きます。

まとめ

本来、プロジェクト活動とは、理想を現実たらしめようという、挑戦です。

しかし、いま現在、多くのビジネスプロジェクトでは「予定調和の納品と請求を目指した、”やってる感”の不毛な見せ合いっこ」が起きているばかりです。

これまでにない、新しいものを生み出し　それを世間に認めさせる、それこそが、プロジェクトです。

しかし、当然ながら、新しいものは、理解されない　歓迎もされません。だから、ほとんどすべての「プロジェクト的な試み」は、失敗する運命にあります。

なぜ、失敗するのか。「正しいことを、教科書通りに、お行儀よく」が、実は、一番失敗しやすいやり方です。

少々やんちゃでも構いません。ぜひ、「テーマとコンセプト」を大事にしていただきたいと、思います。