この記事について
あらゆるプロジェクトには個性があり、絶対にこうすればうまくいく、というものは、ありません。一方で、プロジェクトにはある程度の類型化や経験則、パターンがあるのも事実です。
このシリーズでは、委託・受託型、製品開発型、事業開発型、変革型の４つの類型に対して、進行にあたっての定跡を解説します。
今回は、製品開発型プロジェクトは、なにを、どこからどう始めるとよいのか、なにがどうなれば成功するのかを、過去の筆者自身の出版経験、ITコンサルティング、人材・組織開発での「思い出の言葉やエピソード」から、解説します。
もくじ
1 着目する問題：製品開発型プロジェクトはどうすれば成功するか
2 自動車業界のエポック的事例から抽出する、攻略定跡
3 筆者自身の出版経験を紹介
4 ITコンサルティングや人材・組織開発の現場で思うこと
5 まとめ
着目する問題：
製品開発型プロジェクトはどうすれば成功するか
世の中には、製品開発という取り組みがあります。なにかしらの製品なりサービスなりを企画し、規格大量生産を行う、というものです。一品一様でものを作るのではなく、あらかじめ定めた製品仕様や設計書の通りに、製造プロセスや流通プロセスも整えておいたうえで、商品を生産し、販売していけば、生産活動というものは、効率化の恩恵を受けることができます。
具体的な製品開発プロジェクトの題材の例を挙げると、日本では、自動車の新車種開発、といったものは、長らくこの分野の代表選手を務めてきたものでした。
その他にも、本の出版やレトルト食品、家電や家具、楽器、はたまた音楽、映画、さらには製薬や服飾などなど、実に多岐にわたります。
製品という形で大量生産、大量販売が実現すると、事業者には大きな利益が約束され、消費者にとっても、安い値段で価値あるものが手に入る、という状況が生まれます。特に出版なんかの分野でいえば、ベストセラーを出してしまえば、出版社は本を刷るのはお金を刷るようなものだ、と、よく言われます。
製品開発プロジェクトが成立する前提としては、ある程度のインフラや設備がすでに整っている、ということが重要です。自動車業界なら、完成車メーカーがあり、その傘下の一次サプライヤがあり、さらにその部品を作るメーカーがあり、さらにその部品メーカーを支える工作メーカーや金型メーカーがあり・・・といった具合に、業界エコシステムが存在しています。
かたやで、受益者側にも、運転免許試験場があり、道路や信号が整備されていて・・・と、自動車を利用するための状況が整っています。そのような、全体的な世界が整っているうえで、新たなモデル、新たな機種を生み出していく、ということが、製品開発プロジェクトです。
製品開発プロジェクトは、成功したら世の中にも認められ、お金も入り、従業員や関連企業にもいい顔ができてワッハッハですが、需要を読み間違えて在庫の山を築いてしまうと、投資したお金は戻ってこないし、倉庫代からなにから、支出だけが続いてしまいます。
今回は、そんな製品開発プロジェクトで、関係者のみんなで一緒に幸せになることが、どうすればできるのか、ということを考えます。
自動車業界のエポック的事例から抽出する、攻略定跡
ちなみに、筆者自身は、製品開発の分野で、巨大なヤマを当てて巨額の売上利益を作った経験は、ありません。ですので、結論から言えば、この分野についていわゆる「成功者の経験談」的なものを語ることは、できません。
とはいえ、いくつかの実体験はありますし、プロジェクト進行に関する研究やコンサルティングの活動は積み重ねてきたところもありますので、立場としては、実践者と研究者のハーフ&ハーフ、といったところです。
そんなわけで、今回は、攻略定跡そのものを図示するところから、始めたく思います。
これは、ホンダのシビック開発プロジェクトの責任者をなさった方の講演録をベースとしながら、筆者自身の探究活動を経て得られた知見を加味して作成したものです。
参考図書：共創とは何か
上田 完次【編著】
黒田 あゆみ【コーディネーター】
培風館（2004/12発売）
本書に「共創のマネージメントー企業における実践」の一節が収録されており、当時の本田技研共創フォーラム事務局長である吉田恵吾氏の講演内容が収録されている。製品開発の骨法が実体験から生々しく語られる本書は、隠れた必読書。
本書が語る製品開発の本質は、それが実に共創的である、ということです。
プロジェクトリーダーの強力なリーダーシップは必要ですが、とはいえトップダウンで支配的に組織運営してもダメ。さりとて、自由放免で好き勝手にやらせて「なんちゃってボトムアップ」でやっても、うまくいかない。
それぞれの専門的知識と、それぞれの利害をかかえたチームメンバーから、知恵を引き出し、それをひとつの成果物として結晶化させる、それが製品開発の本質だと、本書は語ります。そのためにはまず、無理難題を設定せよ、と説きます。そして、予算やスケジュールをたっぷり与えるのではなく、むしろ枯渇状況を生み出して、そのなかで四苦八苦させよといいます。
組織のありかたとしては、ドライにスマートに、効率的に分業するのではなく、すべての関係者の役割をオーバーラップさせて、全員がすべてに関与し、つねにワイガヤと双方向的なコミュニケーションを生み出すべきであるとしています。
製品開発における「共創」の本質
もしかしたら、商品企画やヒット商品と聞くと、誰か一人のリーダーやカリスマ的デザイナーの画期的アイデアから、世の中をあっと驚かせる新しいものが飛び出す、というイメージがあるかもしれませんが、それは幻想に過ぎません。
なぜなら、製品が世の中で価値を発揮するためには、そもそも、受益者の側に、それを受け入れ、活かすだけの感性が必要だからです。製品は、製品それ自体のなかに、独立して価値があるのではなく、使われて、活かされて、そこで初めて、価値が生まれます。製品開発プロジェクトの成功には、作り手と受益者の双方向的な関係性が欠かせません。
また「作り手」と一言で言っても、それは実に多様な立場、役割の人たちの重層的な関係性が存在しています。自動車であれば、エンジン屋がいて、内装屋がいて、フレーム屋がいて・・・ということです。それぞれの立場の人は、それぞれの経済圏を持っていて、その製品開発プロジェクトだけに100%コミットするわけではありません。日頃から抱えているルーチンワークもあれば、別のプロジェクトもあります。そのなかで、労力の一部を貸している、という関係性にあります。
様々な利害を抱え、異なる思惑を抱える関係者同士を、どうにかつなぎ合わせ、ひとつの成果物に導いていく、ということが、製品開発プロジェクトの本質です。
筆者自身の出版経験を紹介
私自身の実体験のお話からしてみますと、自分自身が主体者として製品開発をしてきた取り組みとして、例えば書籍の商業出版プロジェクトがあります。超絶的な大ヒット、大ベストセラーとはいきませんが、この出版不況の世の中で、万を数える増刷は、実現してきました。
過去、5冊の出版経験があり、そのなかで、期待されなかったけど増刷に至った本もあれば、期待されたけど初刷で終わってしまった本もあります。
例えば、最初の本である「予定通り進まないプロジェクトの進め方」は、スキマ企画もスキマ企画でした。その年度内に、たまたま枠があまっていて、もし原稿が間に合うなら出しましょうか、というぐらいのスタートでした。
内容の原案そのものはありましたが、たった2ヶ月ぐらいで、慌てて書いたものなので、完成度としても、決して高いものではありませんでした。しかし、あにはからんや、主に口コミで売り伸ばし、出版後数年の間は、その出版社の売れ筋トップ層に入り続けたのでした。
それに味をしめて、これぞと思ってだした続編が、あまり振るわず・・・なんてことも、ありました。
それらの経験から思ったのは「これなら売れる！」という事前のマーケティングリサーチや、企画者の敏腕な嗅覚があって、売れるべくして売れる、ということでは、ないのだなぁということです。
売れるという現象の背景には、作り手陣の、内部的な共鳴やシンクロがあり、それが世の中の問題意識と響き合ったときに、大きく売れる。そういうことではないかと思います。
ただし、全部が全部、時代精神のシンクロニシティの神秘、みたいなことでできているわけでもありません。製品開発プロジェクトでは、流通事業者の影響が大きく、本なら取次や書店、自動車ならディーラー、映画なら配給や映画館など、売り手が売りたいと思うかどうかで、売れるかどうかが、大きく、変わります。また、それにあたって大きな宣伝を打てるかどうかも、売れ筋を左右します。
ITコンサルティングや人材・組織開発の現場で思うこと
筆者自身の経験で、製品開発型の取り組みのひとつに、あるSaaSベンダで、顧客向けのコンサルティングサービスを立ち上げた経験があります。
ある明確に定まった顧客層にめがけて、ある程度標準化された導入・改善サービスを提供した、というものです。
自動車や本のように、モノとして完全に同一のパッケージを量産して売り出す、というものではありませんが、これもこれで、製品開発型プロジェクトの一種だといえます。
もうひとつが「委託・受託篇」でも取り上げた、人材・組織開発です。
コンサルティングや研修サービスは、多くの場合、ベースとなるサービスフレームワークやコンテンツがまず提供者側にあって、それを、ここの顧客に対してアレンジしたり、カスタマイズしながら、提供していく、というものです。
この種の取り組みを、提供者側の効率性に振り切って組み立てていくと、完全に定型化したものを、毎回繰り返し同じように実演していく、というものになります。世の中でコンサルティング会社として大きく成功した企業は、必ずそのような「絶対のフレームワーク」を持っていて、従業員にはそれを教え込み、どこでも誰でも再現させる、ということをしています。
筆者の個人的な感覚として、それは本当に価値なのか？という疑問をいつも抱えています。戦略コンサルにしろITコンサルにしろ、いまの世の中に、コンサルティングという機能はある種、不可欠なものになっていて、多くの事業会社から頼られてもいますが、同時に、現場側として「コンサルなんか、結局、意味なんかない」という感覚が、根強くあるのも事実です。
まとめ
IT/デジタル産業が大きく発展した今日においては、モノの大量生産、大量販売というだけで完結する事業よりも、モノにサービスが掛け合わさった、ダイナミックな製品開発プロジェクトが主流となっています。
本来、価値というものが共創的、双方向的なものだという観点からすると、それは自然な方向性の発展ではありますが、モノの量産とサービスの量産では、後者のほうが難易度がはるかに高い。そこが、現代ビジネス社会の悩みとなっています。
サービスと名のつく商売においては、常に、売り手は標準化とスケールアップを求め、かたやで、買い手は特別対応、個別最適を求めます。それをどの水準で実現するか、ということがサービスデザインの究極の骨法なのだろうと思います。
それがどんなものかというと、標準化された個別のアイテムを客が自由自在に組み合わせて自分にぴったりの最高のメニューにする、ということになるが唯一の最適解であるはずです。
ふと考えてみると、それは飲食業においては、とうの昔からありとあらゆるジャンルにおいて実現されてきた、ということにも思い当たります。
同じようなことを、例えばITの世界やろうとすると、なかなかうまくいかない。それがなぜかを考えると、共創のためには、売り手と買い手の双方に高いリテラシが求められる、という問題があります。
最近、飲食業DX、なんて言葉もよく聞きますが飲食業がITを取り入れるよりもむしろ、IT業界が飲食業に学ぶほうが、有益なヒントが得られるかもしれない。そんなことも考えてしまう、今日このごろです。
この記事の著者
プロジェクト進行支援家
後藤洋平
1982年生まれ、東京大学工学部システム創成学科卒。
ものづくり、新規事業開発、組織開発、デジタル開発等、横断的な経験をもとに、何を・どこまで・どうやって実現するかが定めづらい、未知なる取り組みの進行手法を考える「プロジェクト工学」の構築に取り組んでいます。
著書に「予定通り進まないプロジェクトの進め方（宣伝会議）」「”プロジェクト会議” 成功の技法（翔泳社）」等。
プロジェクトの進捗や人材育成に壁を感じていませんか？
もし、少しでも『あるかも』と感じたら、一度、悩みを話してみませんか。
プロジェクトの悩みは、ひとりで悩んでいても、なかなか、解決は難しいものです。
利害関係やしがらみがないからこそ、差し上げられるヒントもあります。
ひとこと、お声がけいただければ、ご相談に乗らせていただきますので、お気軽にどうぞ。
メールの場合： info@gotolab.co.jp まで、ご連絡ください。
SNSの場合：以下宛に、コンタクトいただけますと幸いです。
Facebook https://www.facebook.com/gotoYohei
LinkedIn https://www.linkedin.com/in/%E6%B4%8B%E5%B9%B3-%E5%BE%8C%E8%97%A4-2159a925b/
たとえば：
プロジェクト能力の第三者評価が、お悩みの解決につながるかもしれません
ゴトーラボでは、プロジェクトの企画書や計画書、MTG資料や議事録から、プロジェクト組織や進行に関する深層課題を読み解き、今後、どのような対策を打つとよいかのヒントを差し上げる、というサービスを提供しています。
短期間、低コストの分析で、ヒアリングやインタビューの手間もかけずに、大きなヒントが得られたとの喜びの声をいただいております。
数多くの深層課題に触れてきたなかで、見えてきた知見もございます。もし、SI開発やDXプロジェクト、新規事業などで、進捗が思わしくない、どんな課題に優先して着手すればいいのか、ヒントが欲しい、というお悩みがあれば、きっとお役に立てるかと存じます。
サービス紹介ページはこちら→ https://www.gotolab.co.jp/pm-skill_assesment/
この記事もおすすめ
プロジェクトワークの基本的な世界観
「プロジェクトの進め方」は１つじゃない！８つのタイプ別に考える推進アプローチ
受託/商品開発/事業開発/変革など、プロジェクトの進め方と勘どころをタイプ別に解説！
「取引」（商談・契約・納品・検収）の一連の流れを「モノ」と「プロセス」の二元的解釈によって読み解く
要望/要求/要件/仕様/設計の違いについて解説！【テンプレートあり】
テンプレートや作例も！プロマネスキル向上のヒント集
ITじゃないプロジェクトも！WBSの書き方再入門【テンプレートあり】
タスクの無間地獄に落ちないための、課題管理のコツ【テンプレートあり】
うっかり間違えやすい、「要件定義」の本質的な意味と方法【テンプレートあり】
SaaS・AI時代のITプロジェクトの鉄則
ITサービスの導入成功に必要な「プレ・キックオフ・コミュニケーション」のご紹介
SaaSを活かすか殺すかは、情報システム企画構想の質が決める【テンプレートあり】
究極の手戻り対策：作業後の「やっぱ、ここ、こうして」問題はどうするとよいか
プロジェクトの遅延やトラブルは、「キックオフ」の時点で、すでに始まっている
AI時代、それはプロジェクトの「マネジメント」でなく「デザイン」の質が問われる時代
プ譜についての解説
プロジェクトの類型別攻略定跡
実体験から解説！ 委託・受託型プロジェクトのよくある問題と対策
テーマとコンセプト
プロジェクトの企画構想に、輝きを取り戻すための「視点」と「問い」
プロジェクト進行能力を、組織的に底上げする
社員のプロジェクト進行スキルを、組織的に底上げしていくための処方箋
3つのお悩みカテゴリでわかる！PM、PL人材の層を厚くするための、打開のヒント
PM/PL人材の評価・育成の方法を徹底解説【テンプレートあり】
プロジェクト組織におけるPMの役割と、必要な個人の内的資源の話
「プロマネスキル」と「社会人基礎力」の違いを本気で考えてみる！
「PMやPMOに、コストをかける意味って、ほんとにあるの？」という素朴な疑問への答
複雑化した座組みのプロジェクトを救うのは「カリスマ的プロジェクトマネージャ」ではなく「フラットな媒介者」
シリーズ「地獄化プロジェクトからの脱出」
年商10億円の伸び悩み問題を「組織的プロジェクト進行能力」の視点で考える
趣味的な放談コンテンツ
少年漫画の金字塔「HUNTER×HUNTER」は、プロジェクト的思考のヒントのパラダイス
「イノベーション」を、プロジェクト工学的に定義する～例えば誰よりも美味しい「すし」を食べさせたかったら～
時代小説「あきない世傳 金と銀」は、プロジェクトの知恵の宝庫！
学びの場のご案内
個人の方向けに、プロジェクトに関するお悩みやご相談をお受けするための場を運営しています。
よろしければ、会の概要をご覧ください。
