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

1　受託制作プロジェクトの進め方

今回も、アリスとボブにご登場願いましょう。

プロジェクトワークのもっとも典型的で、代表的なものは、受託制作です。クライアントワークとも呼ばれます。アリスとボブが一緒になって受託制作プロジェクトを進める、ということは、下図の関係性を結ぶ、ということです。

受託制作プロジェクトの進め方の王道は、以下の通りです。

段階	詳細
企画	どんな成果物を得たいか、その企画概要を考える 必要な予算や人員の見通しを立てて、確保する　調達物や委託先を探し手配する
要件定義	成果物の作成内容や手段、完成条件を明確化する （機能や性能、意匠や成果物の構造、構成など）
設計	成果物の具体的な形状、寸法などを具体化する モノの場合：2D図面や3Dモデルなど ITの場合：ワイヤーフレームや画面遷移、DB設計書など コンテンツの場合：ペルソナやシナリオ、絵コンテなど
製造	設計されたものを、実際に手にとって目に見える形にする 材料の手配、調達　使用する機材や機械の段取り、部品の組み立て　など
テスト	製造されたものが、正しく意図通りになっているかを確認する 単体試験：外観・動作確認や官能評価等 負荷試験：耐久性などの確認 受入試験：実際の利用現場で問題がないかの確認
検収	受託者がテスト結果や納品状況を確認し、債務の履行を認めて、対価の支払いを行う

世の中には、実に様々なプロジェクトがありますが、どんなことをするにしても、こうした一連の流れを理解しておいて損はありません。

ウォーターフォール型進行の、実際の現場で起きがちな話

こうした進め方は、一般的には、プロジェクトマネジメント用語で「ウォーターフォール型進行」と呼ばれています。プロジェクトの規模が大きくても小さくても、成果物が機械であってもイラストであっても、IT要素があってもなくても、やっぱりどんなプロジェクトも、クライアントワークとして実施する際には、こうした手順を踏むと、ある程度確実にものごとを進めることができます。

ウォーターフォールは、プロジェクトマネジメントの基本形として広く知られていますが、実際のところは、この理想像を実現しようとしても、なかなかうまくいかない、というケースが多いです。特に、発注側、依頼する側が、その成果物の作り方についてよく理解していない場合は、上流工程でのコミュニケーションに失敗し、中流、下流工程にしわ寄せがいってしまう、ということも多いものです。

一方、受託型のクライアントワークプロジェクトでは、あらかじめ希望納期や予算が設定されていることが、通常です。

ゆえに
「とにかくものづくりを納期に間に合わせよう」
「そのためには、人を遊ばせず、早めに作業に入ってもらいたい」
「完璧な成果物の設計図が描けていなくても、決まった部分についてはさきに設計や製造を進めてしまおう」
というふうに考え、五月雨式に、後工程の作業に手を付けてしまう、というが、よくあります。

こうした進め方で、中盤、終盤がうまくいく、ということは、あんまりありません。しかし、序盤を正しく美しく進めるよりは、終盤の地獄に慣れてしまうことを無意識のうちに選んでしまう人も、多いものです。

それはそれで、ひとつの身の処し方ですが、無理なことは続かないので、やはり、あんまりお勧めはできません。

そうならないための、序盤戦術の究極は「知ること」

プロジェクトの中盤、終盤の地獄を回避するためには、とにかく相手のことを、理解しようという姿勢を持つことが、とても大切です。ただ単に、なんとなく知る、ということではなく、「徹底的に、多角的に、広く、深く知る」ということです。

こうしたことを知るために、ボブはアリスと積極的に、雑談も含めて「話をする」ということが、一番早いです。ただもちろん、互いに忙しい身ですので、限界があります。それを補うために、ネットやSNSで情報を集める、業界研究をしてみる、実際の一次情報を得るなど、工夫をすることも必要です。

2　コンサルティングプロジェクトの進め方

コンサルティングプロジェクトの代表的なものとしては、以下のようなものが挙げられます。

経営コンサルティング	経営者に対する、経営全般の指導、助言、支援
事業戦略コンサルティング	主に事業構造やマーケティングに関する支援
新規事業開発コンサルティング	特に新規事業に特化した支援
ITコンサルティング	SI開発の主に上流工程に関する支援
組織開発コンサルティング	人事評価制度や関係性など、組織のあり方に対する支援

コンサルティングプロジェクトも、クライアントワークの一種ですので、基本的な進め方は、先述の受託制作と同じです。

ただ、少しだけ異なるのは、成果物が明確なモノではない、ということです。コンサルティングでは、調査結果や経営戦略などの「助言」や「指導」、そしてその結果としての「経営的なインパクト」が提供すべき成果となります。

できれば本来は「成果物とはなにか」「そのコンサルティングプロジェクトで満たすべき要件はなにか」ということを、着手する前段階で整理したいところなのですが、プロジェクトを進める中で、次々と変化に見舞われてしまうことも多いものです。

そんな迷走を避けるために、おおきく３通りの進め方があります。

①どんなコンサルティングを行うのかを、あらかじめ、型化、パッケージ化しておき、とにかくそれを提供する

②いわゆる「善良なる管理者の注意義務」を果たすことを前提に、稼働する時間に対する対価を設定し、役務を提供する

③それらの中間的な進め方
（取り組みの冒頭で、一定の成果を設定しつつも、想定外のことが起きることを覚悟し、できるだけ柔軟に対応する）

世の中のコンサルティングファームの多くは、基本的に①のスタイルを取っています。この場合、そのファームのプロジェクトの進め方も含めて標準化されているため、サービス内容とプロジェクトマネジメントの標準形が一体化されたような格好になっています。概ね、先述のウォーターフォール型の進め方がベースになっているかと思います。

逆に、弁護士の先生のように②のスタイルを取るのであれば、成果物を定めたり、プロジェクト計画を立てたりする必要性は薄まります。

個人や中規模コンサルティング会社、あるいは「コンサルティング要素のあるサービス」を行う場合は、③のスタイルを取ることになります。一般的に、コンサル業がサービス過剰になりがちで、その割には顧客満足を高めにくいのは、こうしたところに起因しています。

コンサルティングワークの「手段の目的化」を避けるために

コンサルティングサービスを、提供者の都合で効率よく提供するには、やはり、①のスタイルを取るのが合理的です。しかし、こうした支援活動は「メソッドの押し付け」になってしまうことが多いものです。そうすると、結果的に、「手段の目的化」が起きてしまい、顧客の利益に結びつかなくなってしまいます。
コンサルティングにおいても、前項と全く同じで、まずは顧客の話を聞く、悩みとやりたいこと、それが叶わないやむにやまれぬ事情を理解しようと努める、ということが大事です。そのなかで、いまやるべきこと・いまできることを見出し、握り、実現し、相手を儲けさせる、というふうに考えなければなりません。

そのために、いわゆるオーソドックスなウォーターフォール型マイルストンを、柔軟に組み換えることが、委託者と受託者、双方にとって嬉しい、ということもあったりします。

3　業務改善プロジェクトの進め方

会社の「中の人」が、自分たちの業務を改善する、というタイプのプロジェクトもあります。これは「自分達で、自分達自身を、コンサルティングする」というふうにも言えます。

業務改善プロジェクトに携わる人が、かならず直面してしまう３大問題があります。

2010年代以降、徐々に増えてきたのが、「業務改善とは、自動化、省力化、脱属人化することである。その業務を簡単にするためのITツールを導入すればよい」という考え方です。そんな考え方に呼応するように、世の中には多くの業務管理ソフトウェアが、SaaS型で提供されています。

この分野においても、コンサルティングプロジェクトと同様に「手段の目的化」が起きてしまい、せっかくITツールを入れたとしても、いれることそのものが目的化してしまい、結局うまく活用されなかった、といったことが、多くの現場で起きています。

そのような迷走を避けるためには、業務改善をする前提となる「ビジネスモデル」と「組織構造」、そして「業務モデル」を整理することをお勧めします。

「業務改善が必要だ！」から、いきなり「どんな手段で改善しようか？」と考えるのでは、いけません。

「自分たちのビジネスや業務は、いま、どんな姿なのか」
「事業戦略や会社のビジョンに照らし合わせて、なにをどのように変えたいか」
「改善された場合、自分たちの業務は、どんな姿になっているか」

こうしたことを描くことで、目的・目標・手段・効果測定の具体的な絵姿が、見えてきます。
そんな絵姿が見えてきたら、それを叶える具体的な手段やメソドロジーは、意外と自ずと、見えてくるものです。

4　商品開発プロジェクトの進め方

商品開発プロジェクトとは「すでになんらかの事業組織や、企業間の取引関係が形成され、ある程度、マーケティングや製造納品の座組が形成されているなかで、新たに投入する製品やサービスを生み出すこと」です。

自動車メーカーの車種開発、やゲームメーカーの新タイトル開発、といったものは、まさに日本経済における商品開発の花形です。大企業に限らず、美容サロンの化粧品開発、レストランの新メニュー開発など、様々な事業規模、業種で、日々、取り組まれているのが、まさにこの商品開発プロジェクトです。

商品開発プロジェクトの真のテーマは「マンネリとの戦い」です。なぜなら、商品開発は、すでにビジネススキームが確立されたなかで実行するものなので、全く新たなゼロイチの開発はできません。つまり、既存製品のマイナーチェンジであることが宿命付けられているのです。

顧客も関係会社も、常に新鮮な、新たな価値を求める一方で、大きく現状を変えることは、望んでいません。かといって、ヒット商品の二番煎じ、三番煎じでもいけない。

商品開発の成就の要は「コンセプト」です。

商品開発の、究極の要も「知る」こと

優れたコンセプトを生み出すためにも、「知る」ということが欠かせません。

●製造技術や製造プロセスのこと

●販売プロセスや販売現場のこと

●ユーザーや生活者のこと

製品やサービスを生み出し、販売するための技術は大きく変化していますが、人間の、根本的な欲求や考え方は、そんなに急に変わるものではありません。優れたクリエイターは、過去のことを良く学び、現在に対して、どうアレンジするか、ということを大切にしています。

このあたりのことを学ぶには、例えば以下のような本もお勧めです。

こうした思考を、チームとして共創的に実現していくあり方としては、往年のHONDA「シビック」の開発エピソードは、ひとつ参考になるかもしれません。「プ譜」の形でご紹介します。

5　事業開発の進め方

事業開発も、現代におけるプロジェクトワークの代表的なもののひとつだと言えます。

こちらは、すでに事業を行っている企業が、新たな市場や顧客を求めて新領域に踏み出す、というもので、商品開発プロジェクトよりも変数が増え、自由度が増します。

社内新規事業も、多種多様な問題があり、一家言を持ったコンサルタントも多く、アカデミアにおいても、一大分野を形成しています。2020年頃以降は、大企業のなかでも、アジャイル開発やエフェクチュエーション、デザイン思考、アート思考など、様々な理論が参照され、試行錯誤が続けられています。「両利きの経営」という言葉も、人口に膾炙しています。

プロジェクト進行の専門家、という立場で、この領域に対して物申せることは少ないのですが、ときどき、こうした類の取り組みに協力することもあり、その経験から言えることは「事業開発は、テーマ設定がすべて」ということです。

「なぜ、いま、自分たちは、新規事業に取り組むのか」

「いま、社会が自分たちに対して求める新価値とはなにか」

こうした議論が生煮えなまま、マーケティングプランを練ったり、ビジネスモデルをお絵かきしてみたり、プロジェクトマネジメントのマネごとをしてみたりしても、迷走し、さしたる結果も残さずに終わってしまうだけなので、要注意です。

6　スタートアップ技術革新の進め方

スタートアップ技術革新、とは、科学技術における先端的な事業の種を、社会実装することで、大きく世の中を変えていこう、という話です。IT分野だけでなく、バイオテクノロジーや宇宙開発、新素材開発や教育など、様々な分野で、イノベーション創出の試みが行われています。

実は、こうしたものこそが、まさにプロジェクトと呼ぶべき、本丸中の本丸である、とも言えます。

「イノベーションの方法論」的な話は、アカデミアやビジネス書、あるいはビジネスセミナーなどの世界で、日々、もちきりです。

プロジェクト進行支援家の立場として、しみじみと実感していることは、「イノベーションを起こす人は、方法論に頼らない」ということです。「イノベーションの起こし方」って、まぁ、「宝くじの当て方」みたいなものだと思って、間違いはないかと思います。

もう少し日常レベルの話に引き寄せますと、先端技術の「実証実験」や「概念実証」「PoC」プロジェクトも、盛んに行われるようになりました。こうした話で、ひとつひとつのプロジェクトを成就させる、ということは、実務上の社会的テーマであるとはいえます。

筆者の経験上、PoCを成功させるために必要なのは、ただひとつ。

「その技術、その課題でなければならない理由を、見つけ出す。そのために、他の既存の手段で解決できないかを、徹底的に、探求する」

ということです。

新たに開発した技術を、目の前の課題に適用する際、人はどうしても「どうすれば、その課題にこの技術が活かせるか」を考えてしまう人が多いようです。そのような問いの立て方だと、「現状維持でなにが悪い」という意見を覆せるような、画期的な成果には、結びつきません。

7　変革プロジェクトの進め方

先端的なIT技術や、最新の組織開発理論をもとに、組織のあり方、風土、業務、すべてを、根本的に、ガラッと変革したい、というプロジェクトもまた、現代プロジェクトの一大分野を形成しています。

そうした取り組みを「実行するべきだ」という意見は、多くのメディアに溢れています。そして「成功しました」という自己申告的なニュースも、ちらほらと見かけます。が、実態を確かめると、大山鳴動して鼠一匹だったり、竜頭蛇尾、羊頭狗肉、ということが多いようです。

それもそのはず、本当に変革プロジェクトを成し遂げようと思ったら、ここまで語った1～6のプロジェクト・メソッドを徹底的に身に着け、自家薬籠中のものとし、見返りを求めず、その企業に殉じる覚悟で、一世一代の挑戦に飛び込む必要があるのです。

そんな「時代の申し子」は、育成しようと思って育成できるものではありませんし、採用しようと思って採用できるものでもありません。結果として「変革」を売り文句にしたコンサルファームやITベンダに、思考停止した事業会社がじゃぶじゃぶとお金をつぎ込む、といった図式が形成されているのも、よく見かけます。
そんなあり方は、健全なものではありません。そうした社会に疑問を覚える、という人も多いことかと思います。解決困難な問題ですが、何冊か、参考図書を挙げてみますので、ご参考いただけると幸いです。

8　危機対応の進め方

最後にご紹介するのが、危機対応プロジェクトです。業界構造の突然の転換、スキャンダル、自然災害やパンデミックなど、非連続的な変化にさらされて、否応なくプロジェクト状況に巻き込まれる、ということがあります。

こうした取り組みも、変革プロジェクトと同様に、「こうすればいい」という簡単な型やテンプレートは、存在しません。特に、地域や国家、社会など、大きな枠組みに対して「こうすればいい」を軽々に話すことはできません。

一方で、いち実務家が、企業単位の危機対応に向き合うにあたっては、唯一のヒントをご提供できます。

捨ててこそ、浮かぶ瀬もあれ、ということです。

危機的状況のなかで「あれもこれも」と守りに入っていると、ジリ貧になり、沈没してしまいます。
本当に大切なものはなにか、そして、手放すことできるものはなにか。
本当には必要でないもの、あればよいというものは、潔く諦める、捨てる、ということが必要不可欠です。

実務家にとって重要なもう一点は、「危機」と「変革」は、表裏一体である、ということです。

当たり前ですが、会社が順調なときに、変革プロジェクトを仕掛けても、腹の底では誰も納得しません。どんなに不満があっても、本質的に、人間は、変化を嫌うものだからです。企業にとって、「変革」のチャンスは「危機」のなかにしか、ありません。

「危機」と「変革」というテーマを考えるにあたって、注目すべきクリエイターが二人います。スタジオジブリの鈴木敏夫氏、そしてその長年の盟友である映画監督の押井守氏です。鈴木氏は、まさに危機的状況にあった日本映画界、アニメ界において、変革的な作品作りの体制を生み出し、自社だけでなく、業界や社会に大きな変化をもたらしてきました。押井守監督は、そんな変革を起こす人物が、いかにあるのかを、作品のなかで、描いてきました。

「変革」と「危機対応」。これを考えるに当たり、二人の著作や発信、実績に触れていただくと、ヒントが得られるかと思いますので、お勧め致します。