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

この記事について

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

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

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

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

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

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

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

ユーザー企業

ベンダ企業

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

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

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

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

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

種別典型的なテーマ設定
受託開発発注側:とにかく作業を自動化して、業務が楽になりたい

受託側:とにかく案件を受注して、経営が楽になりたい
社内新規事業評価側:とにかくなんでもいいから、一発儲かる事業を作ってほしい

実行側:とにかくなんでもいいから、やりたいことをやりたい
変革プロジェクト経営側:とにかく変革して、一発逆転したい

推進側:とにかくなにかをやって、やってる感を出したい

 こういうふうにストレートに書いてしまうと、「さすがにウチはそんなにひどくない」と思う人も多いかもしれません。しかし、そういうふうに思うのは「ホンネ」を「美辞麗句」で装っているからです。

 「生産性向上のために・・・」 「多様性が・・・」 「DXで・・・」 「AIを活用し・・・」
 「最先端の・・・」 「本質的な課題解決を・・・」 「ASISとTOBEが・・」

 こうした修飾語を全部キレイに取り去って「要するに、なにがしたいわけ?」というふうに、ズバッと見たときに浮き上がってくるのが、「ホンネ」です。もちろん、これらの「ホンネ」は、否定すべきものでもありません。プロジェクトを始める動機って、そんなものといえば、そんなものです。

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

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

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

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

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

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

よくある例

良い例

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

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

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

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

 と、思わせるものです。

 こうした実のある議論は、「なぜ、いま、その成果物が、必要なのか?」をベンダ側が適切に問い、それに対して真っ当な議論がなされた場合に、出てくるものです。「今回の成果物の何がどうなったら、役に立てるのか」という最後の問いの中身として、適切な内容が語られ、文書化されたら、その瞬間こそ「要件定義」が成就します。

 その成就にあたっては「コンセプト」を建てる、ということが避けて通れません。

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

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

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

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

よくある例

良い例

 「手段」しか頭にないせいで「手段」が「目的化」している場合、コンセプトはたいてい、よくある例のようになります。そこから行き着く先は「膨大な要望リスト」と「関係者の全員が、意味もないのに、ひたすらやらされる毎日」です。「自分ごと化しろ」という号令だけが響き、だれも自分ごと化しない、つまらない現場と製品ができあがるだけです。

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

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

 そうすると、

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

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

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

 侃々諤々の議論の果てに

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

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

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

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

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

 いや、これでもまだまだ美しすぎ、かもしれません。

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

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

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

「テーマ」に責任を持つ

「コンセプト」に責任を持つ

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

 ここで、鍵を握るのはPMです。

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

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

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

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

まとめ

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

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

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

 なぜ、失敗するのか。「正しいことを、教科書通りに、お行儀よく」が、実は、一番失敗しやすいやり方です。少々やんちゃでも構いません。ぜひ、「テーマとコンセプト」を大事にしていただきたいと、思います。


ご紹介

学びの場のご案内

プロジェクトに関するお悩みやご相談を解決する、学びのコミュニティを運営しています。
よろしければ、会の概要をご覧ください。

この記事もおすすめ

プ譜についての解説

プ譜のテンプレートと、書き方のワンポイントアドバイス!

プ譜を書くメリットを、ズバリ解説します!

プロジェクト進行能力を、組織的に底上げする

社員のプロジェクト進行スキルを、組織的に底上げしていくための処方箋

「プロジェクトの進め方」は1つじゃない!8つのタイプ別に考える推進アプローチ

「プロマネスキル」と「社会人基礎力」の違いを本気で考えてみる!

3つのお悩みカテゴリでわかる!PM、PL人材の層を厚くするための、打開のヒント

プロジェクト組織におけるPMの役割と、それを可能とする個人の内的資源の話

PM/PL育成における「アサイン」戦略

PM/PjM/PdM/PL/PMOの違いを解説!

「PMやPMOに、コストをかける意味って、ほんとにあるの?」という素朴な疑問への答

要望/要求/要件/仕様/設計の違いについて解説!

プロジェクト業務のワンポイントアドバイス

ITサービスの導入成功に必要な「プレ・キックオフ・コミュニケーション」のご紹介

受託/商品開発/事業開発/変革など、プロジェクトの進め方と勘どころをタイプ別に解説!

究極の手戻り対策:作業後の「やっぱ、ここ、こうして」問題はどうするとよいか

プロジェクト進行に効く「動詞」講座

「地獄化プロジェクトからの脱出」初期三部作

年商10億円の伸び悩み問題を「組織的プロジェクト進行能力」の視点で考える

地獄化プロジェクトを脱出する

プロジェクトの智慧を、東洋哲学・医学・文学に学ぶ

「地獄化プロジェクトからの脱出」語り直し

SaaSを活かすか殺すかは、情報システム企画構想の質が決める

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

趣味的な放談コンテンツ

将棋用語は、プロジェクトワークのヒントの宝庫!

「イノベーション」を、プロジェクト工学的に定義する~例えば誰よりも美味しい「すし」を食べさせたかったら~

少年漫画の金字塔「HUNTER×HUNTER」は、プロジェクト的思考のヒントのパラダイス

時代小説「あきない世傳 金と銀」は、プロジェクトの知恵の宝庫!

この記事の著者

後藤洋平,ポートレート

プロジェクト進行支援家
後藤洋平

1982年生まれ、東京大学工学部システム創成学科卒。

ものづくり、新規事業開発、組織開発、デジタル開発等、横断的な経験をもとに、何を・どこまで・どうやって実現するかが定めづらい、未知なる取り組みの進行手法を考える「プロジェクト工学」の構築に取り組んでいます。
著書に「予定通り進まないプロジェクトの進め方(宣伝会議)」「”プロジェクト会議” 成功の技法(翔泳社)」等。