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

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

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

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

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

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

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

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

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

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

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

その構図は、

といった具合です。

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

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

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

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

どうしてプロジェクトが「やらされ」になるのか。

それは、そのプロジェクトが、問われるべきテーマのうえに、成り立っていないからです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と、思わせるものです。

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

ちなみに「今回の成果物の何がどうなったら、役に立てるのか」という最後の問いの中身として、適切な内容が語られ、文書化されたら、その瞬間こそ「要件定義」が成就します。その成就にあたっては「コンセプト」を建てる、ということが避けて通れません。

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

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

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

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

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

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

良い例は、ユーザ企業のビジネスモデルや成り立ち、哲学やビジョン、ミッションといったものを、きちんと掘り下げた場合の例です。内容については、あくまで一例であり、みんながみんな、同じようなコンセプトになるわけではありません。あくまで、一例です。

やる作業そのものは、「駄目な例」の設定と、さほど変わらないかもしれません。しかし、「なんのために」がシャープに、明確になります。そうすると、

「本質的に、やらなくていいので、やらないこと」
「難しいが、制約条件のなかで知恵も絞ってやるべきこと」
「制約条件のそもそもを問い直し、新たな資源を調達してでも、やるべきこと」

の見分けがつきやすくなります。

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

侃々諤々の議論の果てに

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

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

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

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

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

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

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

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

いや、これでもまだまだ美しすぎですね。

①営業活動のなかで、駄目なテーマ設定が握られる
②見積検討や企画提案の段階で、駄目なコンセプトが握られる
③要件定義をモヤモヤしながらもなんとか誤魔化し、進める
④開発に入って矛盾が露出し、テーマの問い直し、コンセプトの建て直しをする

実際のところ、①～③の段階で、正しく問うことをしているつもりで、できていない、ということも多いものです。どんなプロジェクトも、④の段階で問い直し、建て直しのチャンスが残されている、とも言えます。

ここで、問い直し、建て直しを諦めたり、その勇気を持てない場合に「やらされプロジェクト」が出来上がります。

テーマとコンセプトの責任分担の構図としては、以下のような形となるはずです。

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

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

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

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

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

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

まとめ

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

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

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

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

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