実体験から解説! 委託・受託型プロジェクトのよくある問題と対応策

この記事について

着目する問題:
委託・受託型プロジェクトはどうすれば落着するか

 世の中には、制作業というビジネスモデルがあります。目の前のお客さんのために、目の前のお客さんが欲するものを作り上げ、引き渡す、というものです。クライアントワークとも呼ばれます。

 ジャンルは非常に多岐にわたります。家を建てる、とか、業務システムを構築するとか、キャッチコピーを書くとか、イラストを描くとか、マーケティング調査をする、映像作品を作る、ウェブサイトを作る、法務相談に乗って契約書の文面を作成する、などなど、実に様々なものがあります。

 クライアントワークの面白いところは、お客さんの要望や好みが千差万別だ、ということです。
 ものすごくこだわりが強いお客さんもいれば、ものすごくあっさりしたお客さんもいます。プロセスが大事だ、というお客さんもいれば、結果が大事だ、というお客さんもいます。
 予算がたっぷりのお客さんもいれば、そうでないお客さんもいます。成果物の目利きができるお客さんもいれば、そうでないお客さんもいます。急いでいるお客さんもいれば、そうでないお客さんもいます。

 このように、制作業においては、お客さんのあり方は実に多様です。

 実際に、仕事を一緒にしてみる前には、どんなお客さんなのか、わかりません。
 そして、一件落着してしまえば、また別の、新しいお客さんに出会っていきます。

 制作業において、新しいお客さんと出会い、新しいプロジェクトを始めるときには、それまでの経験はゼロリセットされます。毎回毎回、未知なるお客さんの、未知なる要望と出会っていきます。

 制作プロジェクトの世界は、山もあり谷もあり、酸いもあり甘いもあり、実に豊かです。

 今回のテーマは、委託・受託型プロジェクトの進め方です。

ものづくりの世界から得た教訓

 筆者が社会に出てから最初に従事したのは、ものづくりの世界でした。ものづくりのなかでも少々特殊な「試作」の仕事でした。自動車メーカーや家電メーカーが設計した部品データを受け取り、試作品を作って納める、というものです。

 その会社では、当時、世の中に登場したばかりの光造形・粉体造形技術というものを使っていました。いまでいう「3Dプリンタ」というやつです。
 従来は、いわゆる樹脂成形とぃう分野で試作品を作ろうとすると、金型を起こさなければならなかったので、期間として最低数ヶ月はかかるのが当たり前でした。その常識を覆したのが、3次元造形技術でした。これを活用すると、3Dデータさえあれば、ものの数日でモノを作って渡すことができ、とんでもない時間短縮になると、一世風靡していました。

 就職する前は、これはまさに夢の技術であり、世界が変わると衝撃を受け、期待に胸を膨らませ、就職したのでした。しかし、いざ入社してみると、大変に困難な毎日が待っていました。

 確かに、あっという間にモノはできあがる。
 しかし、結構な頻度で、不具合が生じる。

 曲がったり、ねじれたり。寸法が出なかったり。変色したり、割れてしまったり・・・

「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わっていった日々

 ものがうまくできないだけではありません。当時、その技術は非常に高い人気を誇っていました。ゆえに、多くの顧客から、注文が殺到していました。そこで起きのが「順番待ち」でした。
 機械にかけてしまえば、たった数時間で、モノができる。しかし、その機械にかかるまでの順番待ちに、3日も4日も待たされる・・・なんてことも、よくありました。

 高速試作サービスと銘打って、スピードを売りにしているのに、不具合や機械の順番待ちで、そのスピードが発揮できない。なんとも皮肉な状況が、そこにはありました。

 そのような、原理やビジネス構造上の問題の次に「これは、大変だぞ」と思ったのは、コミュニケーションの難しさでした。

 例えば、樹脂の色や種類。プラスチック成形では、原則として、提供する樹脂には、いくつかのバリエーションがあります。この樹脂は、黒、白、ベージュの三色だよ、とか。樹脂の材質にしても、粘りがあって柔らかいものと、硬度があって磨きやすいものがあるよ、とか。
 お客さんからは3Dデータとして「作りたい形状」だけが渡されます。そして、作る側に対して、どの樹脂で、どの色か、どんなふうに仕上げてほしいかといった事細かな仕様については、あまり詳しく語られることはありませんでした。

 などなど、原因や状況は、様々にパターンがあります。

 もちろん、どうしても大事な話があれば、事前にしっかり伝えるのが通常ですし、こちら側にも、コミュニケーションエラーを減らすためのチェックリストや段取りもあったりはします。ですが、なかなかどうして、大事なところに限って抜けたり漏れたりします。
 上流で、必要な情報は全部満たしたつもりでも、いざ実際にモノを作ろうとすると「あれ、これってどうするの?」という指示や指定の不足が出てきたりします。結果として、現場から上がってきた質問をお客さんに中継し、返ってきた返事を伝書鳩して・・・と、ゴーサインが出たあとも、なんだかんだとコミュニケーション必要なことがでてくる。
 ある程度は仕方ないけれども、あまりにも重なってしまうと、お客さんからも、製造側からも、「要領の悪い営業だな」と睨まれてしまいます。

 本当に大事な話なら、作業を止めてでも確認すべき。しかし、実はどっちでもいい、という話もある。試作営業の仕事は、そういうこぼれ球を見極めては、パスを回す、という仕事でした。
 理想像としては、製造側に対しては、完璧にお客さんの要望要求を代弁でき、お客さんに対しては、製造側の確認事項を代弁できる、というものですが、相当なレベルに熟練しなければ、なかなかそこまでは、やれません。

受託制作は、不確実性との戦い

 厄介なのが、試作品ができあがったあとに「確かにオーダー通りの形状はできたけど、欲しかった色じゃない」「使えないわけではないが、使うためには余計な一手間がかかって、面倒くさい」といったようなことが起きた場合です。

 明らかなミスがあったわけでは、ない。決して、不具合とは言い切れない。
 しかし、顧客の欲しかったものではない。期待していたイメージと、ぴったり一致してはいない。

 買い手としては、できれば、作り直して欲しい。しかし、売り手としては、当然ながら、作り直すには、時間もかかるし、材料費だってかかる。

 そういう納品物を受け取るかどうかは、お客さんの胸先三寸に委ねられます。

 買い手がそこでノーを突きつけたら、今度は売り手側にボールが渡ります。その対応いかんで、未来の展開が変わります。

 どのシナリオを選択するかは、自由です。そして、複数の選択肢から、どれかひとつを選ばなければなりません。選択を誤ると、お客さんの機嫌を損ねて、話がこじれるかもしれない。意外とニッコリ笑って、簡単に済むかもしれない。

 試作品の納品の瞬間は、わりとこう、宮本武蔵のような剣豪の果たし合いのような、気合いと呼吸の勝負、というニュアンスがありました。
 もちろん、全部が全部、ということではありませんが、前例が少なくて未知の要素が大きい案件とか、制作工程で色々問題が出てしまったものは、結構ヒリヒリしながら、納品していました。

関係者が増えると、不確実性も増える

 ちなみに、「サービスが、自社では完結しないことも多い」ということも、入社してみて驚いたことのひとつでした。

 造形品を作って終わり、ではなく、そこに塗装をしたり、あるいは仕上げのための治具(寸法を正しく出すための、組付け台のようなもの)を作ったり。あるいは、造形品をマスターとして型を取って、そこからさらにコピーを作ったりもします。
 そうすると、そこでまた時間もコストもかかるのは当然ですが、それだけでなく、その案件全体の元請けとして、外注先の責任も、自分が引き受けなければならないのでした。そうすると、そこでまたコミュニケーションエラーや不具合、遅延が出てきたりします。

 そうすると今度は、相手の作成物を受け取るか受け取らないかという、お客さん側のような対応も迫られます。

 業界知識の浅い新人にとっては、わけのわからない世界です。なにがよくてなにが悪いのか。これをOKするべきか、NGを出すべきか。

 入社した当初の、まだ若かった自分は、外注先のミスや納期遅れは、外注先の責任であり、自分が被る必要はないはずだと思っていたのでした。責任を軽く捉えてイージーな判断をして、案件を失敗してしまい、先輩に呆れられたり怒られたりしたものでした。

 そんなこんなで「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わっていったのを、いまでも懐かしく覚えています。

未熟だった自分に「仕事観」のコペルニクス的転回を与えてくれた、あるお客さんの一言

 当時、担当していたお客さんから、仕事の真髄を教わった言葉に、こんな一言があります。

 そのお客さんは、納期もスケジュールも、予算にも非常に厳しいお客さんでした。連休があったら、休み前の深夜にデータを渡して、休みが明けたら早々にモノが届くのが当然。費用は業界最安値以外は、あり得ない。それが通常営業、当たり前、というお客さんでした。
 社内の製造メンバーにも嫌がられるし、対応してくれる外注先も、簡単には、見つからない。新人営業としては、いかに営業成績になろうとも、仕事が来てほしくないお客さんナンバーワンでした。
 しかし、発注の量が多い。ゆえに、上司からは、絶対に競合に取られてはならぬ、との厳命が下されていました。

 担当になってからしばらくは四苦八苦しながら対応をしていましたが、ある日とうとう我慢ができなくなりました。意を決して、電話口で、できない理由を並べ、どうにか納期を伸ばしてもらえないかと懇願しました。

 そこで放たれた、それはそれは冷たく突き放す一言が「それは、御社の都合でしょう?」の言葉でした。

 あまりに予想外過ぎて、ガーンと衝撃をくらってしまい、なにも言い返すことができませんでした。交渉の余地が、まったくない。そんなことって、あるのか!?という衝撃でした。人間として、そんなことって、あるの??と。

 しかし、こういう瞬間に、何も言い返せないと、その時点で、交渉敗北は決定的です。電話を切ったあとは、また泣きべそをかきながら、手配の奔走を再開したのでした。

 世が世なら、下請けいじめとか、ハラスメントと言われるようなことかもしれません。あまりの理不尽さに、ほとほと困っていましたし、先輩に相談しても助けてくれるわけでもなく。これは、大変な会社に就職してしまったぞ・・・と、思っていました。

 しかし不思議なもので、その理不尽体験こそが、自分にとって、決定的に重要な成長を促してくれたのでした。

「仕様や取引条件を工夫し、QCD(品質・コスト・納期)をバランスさせよ」

 なにに気づいたのかというと、「一見理不尽なオーダーでも、条件や段取りを工夫すれば、別にそんなに手配が難しくもない」ということでした。

 工夫とは例えば、納期が厳しい分、仕上げのレベルを落とさせてもらう、といったようなことです。作業を省いて納期短縮を図れば、自社の現場は助かりますし、納期にも間に合わせやすくなります。
 もちろん、いくら早くても粗悪品を渡したら意味がありません。品質として、重要な部分はきっちりやるが、そうでない部分は、徹底的に、手を抜く。なにが重要なのかを理解するために、お客さんに、試作の目的を聞く。風洞試験なのか、外観を見たいのか、嵌合を確認したいのか。
 数量にしても、最初から全数が欲しいのか、それとも、一個だけ最初に頭出しが間に合えば、そのあとのものは、もう少し待ってもらえるのか。

 その他、外注手配にしても、人気があって、いつも忙しくて混んでいる外注先に特急の仕事をお願いしても、嫌な顔をされるのは、当たり前です。嫌がる相手に、無理やり仕事をさせても、いいものはできません。だったら、仕事が薄くなってしまって、売上が恋しい外注先を探せばいい。

 案件や状況が理不尽なのではない。自分の観察と工夫が足りなかっただけだった。
 丁寧に案件の中身を見て、その目的やお客さんの期待を理解していけば、お互いが満足できる妥協点が見つかる。

 そういうことに、気付いたのでした。

 受託制作プロジェクトというものは、無理な条件をそのまま右から左に横流しして、製造現場にゴリ押しで押し付けてやっても、苦労が多く、益はありません。まずは、お客さんの期待を理解する。そのうえで、最も効率よく進める道を描く。さらには、その仕事を、みんなで喜んでやれるように、条件を調整し、座組みを作る。
 そうしたもろもろの工夫をするのが、自分の役割なのだとわかってからは、仕事を回すのが随分と楽になりました。

 そういうふうに、発想を切り替えることができたのは、ある先輩の、なにげないひとことでした。

 試作営業は、明らかに、かなりハードルの高いプロジェクトマネジメントが求められる世界です。納期も予算もたっぷりで、品質チェックも楽々、外注先だって大喜びで付き合ってくれて、みんな仲良くワッハッハ、なんてことは、まず、ありません。
 どこかで必ず、結構な無理を求められる。そのときに、受注の窓口に立った自分が、あぐらをかいていてはだめで、どうにかこうにか、いろんな条件を調整し、みんなが納得できる形を探っていく。

 一見、あちらを立てればこちらが立たずでも、どこかで誰かが妥協できる余地がある。それを見つければいい。それこそが、プロジェクト進行の極意なのだと、悟ったのでした。

発想の転換をうながしてくれた、先輩の言葉たち

 思い返してみると、当時は先輩のもらした、ふとした一言で、学んだことが多かったなと思います。

 たとえば、不具合という問題に対して目を開かせてくれた言葉が、こちらです。

 どんなに手配を完璧にしたって、ものをつくるという過程で、避けられないのが不具合です。こればかりは、確率的に、絶対に、ゼロにはならない。どうしようもない。

 不具合が起きたときに、100%こちらの責任であった場合、損害は、こちらがかぶらなければなりません。しかし、不具合が結構な頻度で発生する技術を扱っていたので、これが本当に大変でした。
 製造現場が出した不具合なのだから、作り直しをするなりなんなり、工場側が損失をかぶってくれれば、別にこちらは困らないのですが、現場は現場で、大量のオーダーをさばくのに必死です。とにかく、片っ端から仕事を片付けていかないと、終わらない。
 ゆえに、現場のエンジニアや工員の皆さんは、不具合が出たときに「ごめんなさい、直します、間に合わせます」とは、なかなか、言ってくれない。

 こういう言葉も、ナイーブだった新人営業時代、理不尽に思ったものでした。
 完全なる、自分の会社とお客さんの、板挟み。
 間に立つ自分だけが、損をしている気分・・・。

 不具合問題に対する工夫は、制作を進める過程で、「ここにはこういうリスクがありますよ」とか「本当にこれで進めていいですね?」といった、事前承認のくさびを打っておく、ということでした。
 そうすることで、コントロールできないリスク要因であっても、ある程度はリスクヘッジが可能になる、ということを教わったのでした。

 かたやで、その対極にある、こんな言葉もあります。

 これは、過去にないほどの巨大な制作案件でのことでした。考えてみるまでもなく、強度が出るとは思えないし、作れるというイメージが、まったくわかない。「座組み」とか「リスクヘッジ」とか、そんなことを考える以前に、どうしたらいいか、わからない。
 そんな案件の引き合いがあり、当時の部長に営業同行してもらった帰りの車の一言です。

 どうやったら作れるのか、皆目見当もつかないなか、部長はお客さんとの打ち合わせをスラスラと進めていきます。その打ち合わせで伝えたメッセージは、ふたつ。「できる」と「任せてくれ」というシンプルなものでした。

 さすが部長、どうやったら作れるかを、すでに考えてくれていたんですね、地獄に仏です・・・と帰りの車の中で感謝したら、答えは「そんなもん、わからん」とのこと。
 茫然としていたら、極めつけにこの一言とともに、突き放されてしまいました。

 その2ヶ月後には、すったもんだの挙げ句、どうにかこうにか、形を作ることに成功しました。

 丁寧に段取りし、確実に納めていくだけではない。ときには、大きく、リスクを取るから、チャンスを活かすことができる。
 「どうすればできるか」に一点集中して考えることも、大事だという、教訓を与えてくれた一件でした。

ものづくりを通して体得した、制作プロジェクトの理想と現実

 理念的には、制作プロジェクトは、いわゆる「ウォーターフォール」と呼ばれる流れで進めるのが理想です。

 ウォーターフォールの心とは、その成果物を発注・受注するまえに、なにを、なんのために、いつまでに、どうやって作るのか、それはどんな仕様を満たしているべきで、そのためには費用はどの程度かかるのか、また品質を保証するためにはどんな検査やチェックが必要なのか、ということを、事前に明らかにしたうえで、確実に、効率的にものづくりを進めよう、ということです。

 試作営業も、純然たるものづくりであり、その原則から外れることはありません。しかし、とんでもないスピード勝負の世界で、ゆっくり事前に企画検討し、優先順位を確認し、ということが、実質的に不可能なことも多かったのでした。実際問題、作ってみないとわからないことも、実に多いのです。
 やってみて、ときにはトラブルが起きて初めて、お客さんの優先順位が明らかになる、ということもあります。

 試作営業を通して理解したのは、最終的に、帳尻が合えばよい、ということでした。ウォーターフォールの教科書的手順は、理念として理解はしたうえで、むしろそれを柔軟にアレンジすればよい。

 野武士の剣法という感じですが、実務的にプロジェクト進行能力の高い人は、業種や職種に限らず、この感覚を持っている人が多いようです。

ITプロジェクトからの学び

 その後の別の会社の仕事で、ITプロジェクトにも携わる機会がありました。

 いわゆるノーコード、ローコードツールの先駆け的な製品で、プログラミングの知識がない人でも、システムを自由自在にカスタマイズできる、というものでした。我が社の製品を使えば、業務マネジメントが自由自在ですよ、という謳い文句の製品でした。

 その製品の革新性に感激し、喜び勇んで期待して入社してみて、蓋を開けてみたら「お客さんは、ITが好きではない」という現実にぶち当たったのでした。
 すでに導入しているお客さんを回ってみると不満の声ばかり。恨み節に怒りの色が、異様に濃い。
 いざシステムを見てみたら、その理由は、一目瞭然でした。お客さんたちは、ITに詳しいわけでも、スキルがあるわけでもない。彼らがにらめっこしていたのは「一生懸命やっているうちに、わけのわからないカスタマイズを繰り返して、カオスになった業務画面」だったのでした。

 またしても、「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わる日々が始まりました。

 一番最初の仕事は、「導入のやり方を間違えて、ぐちゃぐちゃになってしまった画面を直して回る」という仕事でした。ITの世界でも、ものづくりの世界で学んだプロジェクト哲学が、そのまま役に立ちました。

 といったことです。

 ただし大変だったのが、大規模プロジェクトでした。こればかりは、情報整理や条件調整、といったことでは管理しきれない。そこでとうとう、PMBOK式のマネジメント術を習得しながら、仕事を進めることになったのでした。

 いわゆる、WBSを厳密にする、課題管理をちゃんとやる、定例会議の運営、的確な議事録の配布、テスト計画と実施記録を綿密にする・・・といったものです。

 いろいろな手段を体験するなかで、IT大規模プロジェクトで一番大事だと痛感したのは「コミュニケーションのあり方そのものの、全体的なデザイン」でした。

 どういうことかというと、規模の大きなITプロジェクトは、とにかくやたらめったらと、検討内容や議論が複雑なのです。抽象的な話も多いですし、細かい話も多い。利害対立することも多く、起きている問題も複雑化しやすい。
 すこし油断していると、関係者全員の心があっという間にバラバラになりますし、議論も錯綜しがちです。

 議論を整理整頓して手際よく進めていかないと、「半年間、ただわあわあ言いたいことを言い合っていただけだった」みたいなことにも、なりかねません。
 そうならないためにやったのが、定例会議と分科会の建て付けの整理、各回のアジェンダの整備、適切な参加者への呼びかけや、会議前後の根回し、確認、というものでした。

人材・組織開発の世界ではどうか

 独立後、いわゆる人材・組織開発の世界のプロジェクトに携わることになりました。コンパクトなものだと、研修の依頼をいただいて、プログラムを工夫し、実演する、というようなものです。
 すこし大掛かりなものになりますと、組織風土を変えていこう、とか、業務プロセスを刷新していこう、といったテーマのなかで、コンサルティングや伴走もしながら、長期間関わっていく、というものに発展していったりします。

 この「新しい、お客さんのあり方」を納品するという仕事で、ものづくりの世界と真逆だったのは、品質基準がわからない、ということでした。
 特に、研修のようなサービスの場合、発注者が現場のことをよく知らない、ということが、わりとよくあります。どんな研修をしたら喜ばれるのか、なにがどうなったら合格なのか、発注者ですら、よくわからない。そのなかで、「まぁとにかくやってください」みたいなことが、結構よくあります。

 発注者だけでなく、研修の受講者の皆さんも、客観的かつ公平に、目的を達成できたかどうかは、言えません。
 もちろん、良かったとか悪かったとか、所感を述べてくれることはありますが。アンケートがそのまま検収条件になるかというと、違います。

 それは考えてみれば当たり前で、研修というものは、一時的に講師と受講者が関わり合いを持つことで、なにかしらの変化のきっかけとする、というものです。その変化は、すぐに出てくるものではありませんし、変化が起きたかどうかを観測、評価することも、難しかったりします。
 その変化が、研修によって引き起こされたのか、ということも、検証しようとしても、客観的に示すのは難しいところがあります。

 研修業を始めたときに最も強く悩んだのは、事前にテストもできなければ、真のニーズもわからない、ということでした。当日、受講者の皆さんと顔を合わせてみないと、わからない要素が、あまりにも、多すぎる・・・という。
 ものづくりやITの仕事では、客観的な、なにかしらの現物が目の前にあって、寸法なり動作なりを確認することができました。それが仕様や契約に適合していなければ、改修ができます。
 しかし、教育サービスでは、事前に仕様や要件を詰めることも、提供した成果物の品質や効果を評価することも、難しい。そして、イマイチだったからといって、やり直しがきくものでもない。

 こうした人材・組織開発やコンサルティングのような取り組みは、成果物としての目標を決めて、その制作を目指すという、純粋な委託・受託モデルでは捉えきれない部分もあります。
 それについては、引き続き、製品開発型など、他の類型についてのコラムでも、取り上げていきます。

まとめ:委託・受託型プロジェクトの真髄を、プ譜で表現する

 ものづくり、IT、人材・組織開発と、いろんな業界で経験してきたプロジェクトマネジメントですが、抽象化していくと、そこにはいつも共通する「原理」が流れています。

 題材や状況、取り組みの中身が違っても、「制作」であれば必ず共通する、普遍的真理のようなもの―――

 それを「プ譜」の形で図示したのが、こちらです。

 獲得目標、勝利条件、中間目的の3つは、どんな類の受託プロジェクトでも、そうそうは外さない、定跡的な表現を目指しています。

 まず、獲得目標について。

「甲乙の間で合意した成果物」
 委託・受託プロジェクトでは、なにをつくるのかを、なにはなくとも、合意せよ、ということです。取り組みの最序盤の、この設定の精度が高いか低いかによって、その後の協議や実作業がスムーズにいくのか、道に迷って難航してしまうのかが決まります。

 次に、中間目的について補足します。
「甲の置かれた状況や期待している将来を乙が深く理解している」
「技術・環境・取引条件等の制約を踏まえたうえで、現実的なマイルストンと検収条件が握られる」
「行動計画とあわせて、不測の事態に対する変更管理のルールが運用に乗る」

 具体的なレベルではやはり、いわゆるPMBOK的な計画や契約、ドキュメンテーションの精度が求められますが、それを支えるものとして「甲乙双方の相互理解」というものが欠かせません。そのうえで、現実的なマイルストンや検収条件の握りをする。そういうプロセスを踏んでいかなければ、委託したつもり、受託したつもりで、互いにまったく別々のことを考えているだけのよくわからないプロジェクトができあがってしまいます。
 甲乙双方の相互理解があったうえで、企画趣旨が握られ、予算とスケジュールの見通しがたち、それが計画として具体化されている。というのが、委託・受託プロジェクトの理想です。

 そして、そのうで、変更管理というものが、あり得ることを前提にしておこう、ということです。委託・受託プロジェクトでは、成果物が出来上がったときに初めて、本当に欲しかったものが、具体的に、モノとして具現化されます。ゆえに、初期設定や初期計画にあまりとらわれすぎると、かえってうまくいかなくなります。
 ただし、出たとこ勝負で、なんでもかんでも計画変更、変更、と続いてしまうと、お互いの不信感が溜まります。そうならないための「ルール変更のための、メタルール」を、握っておきましょう、ということです。

 以上の中間目的を実現するための施策については、図中ではシンプルに表現し、並べていますが、以下の表で、もう少し詳しくその心を語ってみます。

項目その心は
ヒアリングやインタビュー受託制作においては、まず、話を聞く。そこからしか始まらない。
ただし、全部が全部、言われて通りにせよ、ということでもない。
大事なのは、相手を知る、ということ。
もちろん、聞かなくても調べればわかることは、調べておくべし。
懇親の場相手の本音を理解しなければ、真の勝利条件にはたどり着けない。
本音はオフィシャルな場では、出てこない。
心を許し、緊張がふっと緩んだ瞬間に、ぽろっと見え隠れするのが本音である。
ラフ検討、見積だいたいいくらで、どれくらいのものを、いつまでに作るのか。
案件の概略が、ある程度の精度で見えて初めて、ゴーサインが出る。
しかし、ゴーサインが出なければ、詳細検討できず、見積の精度は上がらない。
そんな鶏・卵問題を突破するために、ざっくりと複数のシナリオを検討する。
マイルストン、スケジュール検討構想を落とし込むために、業務としての具体案を落とし込む。
ポイントはスケジュールそのものより、マイルストンである。
超えたら戻れない分岐点や、複数の工程の結節点を、考える。
それが、プロジェクトに骨格を与える。
Fit&GAP具体的な成果物は、問題の分析ばかりしていても形が見えない。
創造には、要素の統合というプロセスが欠かせない。
そこで「こういうものでどうですか」というたたき台が必要である。
たたき台をもとに、期待通りの部分とそうじゃない部分を、洗い出す。
要件定義、基本設計「要件」とは、契約が成立するための条件のことである。
「設計」とは、要件を満たす成果物に形を与えることである。
詳細設計、製造上流ではぼんやりしていて見えていなかったディテールに、答えを出す。
テスト&レビュー作ったものが、当初の願いに叶うものだったのかを確認する。
コミュニケーションデザインプロジェクトマネジメントとは、結局のところ、コミュニケーションである。
ただし、そこにはデザインと構造が必要である。
いつ、どんなときに、どんな方法で、連絡を取り合うのか。
コミュニケーションの構造の質が、プロセスと品質に如実に反映される。
各種帳票の整備人間は、忘れる生き物である。
ゆえに、以上の諸々を、言語化し、証跡として残す必要がある。
できるだけ、負担が少なく、実務を邪魔しない帳票を装備しよう。

 プロジェクト全体の流れとしても、概ね、上記の通りの進行になりますが、各マイルストンの内部や、ひとつひとつの部分作業でも、フラクタル状に、似たようなアクションが求められます。
 いつでもすべてのアクションがきっちりみっちりこなせるわけではありません。廟算八要素すなわち、所与の条件や必達目標、想定リスクなど、その現場や状況を適切に理解し、それにあわせて可能なものを、そして必要なものをアレンジしていく、ということが、肝要です。

 依頼者がなにを欲しているのか、受託者の得意や強みはどこなのか。相手に対して、勝手な願望を抱くだけで、それぞれが勝手にシャドーボクシングをしているだけ、というようなプロジェクトは、世の中意外と多いものです。そうなってしまわないための道しるべとして、ご参考になる部分があれば、幸いです。

委託・受託は、あらゆるプロジェクトワークの母型

 委託・受託型プロジェクトは、あらゆるビジネスプロジェクトの母型のようなものです。

 不特定多数のお客さんを相手にする、製品開発の世界。
 製品やサービスだけでなく、お客さんを探す所も含めて始める、事業開発の世界。
 そもそもお客さんがいない、変革の世界。

 それぞれの世界では、それぞれのコツがあります。委託・受託的なものの見方をしていては、そもそも勝負になりません。とはいえかたやで、部分的には委託・受託の世界における考え方や動き方がヒントになったりします。

 よろしければ、それぞれの世界も、ご覧になってみていただけると幸いです。

共創と競争! 製品開発型プロジェクトは「組み合わせ」が鍵

理念とリアルの相克! 事業開発の成否は「テーマとコンセプト」が握る

計画か、即興か! 変革の成就には避けて通れない「矛盾」


この記事の著者

後藤洋平,ポートレート

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

ものづくり、新規事業開発、組織開発、デジタル開発等、横断的な経験をもとに、何を・どこまで・どうやって実現するかが定めづらい、未知なる取り組みの進行手法を考える「プロジェクト工学」の構築に取り組んでいます。

プロジェクト能力開発やPM/PL人材不足問題の解決のために、日々、試行錯誤しながら、活動しています!

著書

・予定通り進まないプロジェクトの進め方(宣伝会議)
・紙1枚に書くだけでうまくいく プロジェクト進行の技術が身につく本(翔泳社)
・“プロジェクト会議”成功の技法 チームづくりから意思疎通・ファシリテーション・トラブル解決まで(翔泳社) 等

提供サービス実績

・現場リーダー層のプロジェクトマネジメント能力や業務課題の現状調査
・カスタマーサクセス、導入コンサルティングの組織、スキル要件整理、プロジェクト標準見直し
・PMO部門責任者の退任にともなう後任探し、引き継ぎのための業務棚卸し支援
・社員育成体系のリニューアルにともなう社内キーパーソンへのインタビュー、問題整理 等

プロジェクトや組織の悩みがあれば、ぜひお寄せください!

プロジェクトの悩みは、ひとりで悩んでいても、なかなか、解決は難しいものです。
利害関係やしがらみがないからこそ、差し上げられるヒントもあります。

ひとこと、お声がけいただければ、ご相談に乗らせていただきますので、お気軽にご連絡をいただけますと幸いです。

    メールの場合: info@gotolab.co.jp まで、ご連絡ください。

    参考

     ゴトーラボでは、プロジェクトの企画書や計画書、MTG資料や議事録から、プロジェクト組織や進行に関する深層課題を読み解き、今後、どのような対策を打つとよいかのヒントを差し上げる、というサービスを提供しています。

     数多くの深層課題に触れてきたなかで、見えてきた知見もございます。特に、SI開発やDXプロジェクト、新規事業などを中心に多くのご相談をお受けしています。

    サービス紹介ページはこちら→ https://www.gotolab.co.jp/pm-skill_assesment/


    この記事もおすすめ

    プロジェクトワークの基本的な世界観

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

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

    「取引」(商談・契約・納品・検収)の一連の流れを「モノ」と「プロセス」の二元的解釈によって読み解く

    要望/要求/要件/仕様/設計の違いについて解説!【テンプレートあり】

    テンプレートや作例も!プロマネスキル向上のヒント集

    ITじゃないプロジェクトも!WBSの書き方再入門【テンプレートあり】

    タスクの無間地獄に落ちないための、課題管理のコツ【テンプレートあり】

    うっかり間違えやすい、「要件定義」の本質的な意味と方法【テンプレートあり】

    SaaS・AI時代のITプロジェクトの鉄則

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

    SaaSを活かすか殺すかは、情報システム企画構想の質が決める【テンプレートあり】

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

    プロジェクトの遅延やトラブルは、「キックオフ」の時点で、すでに始まっている

    AI時代、それはプロジェクトの「マネジメント」でなく「デザイン」の質が問われる時代

    プ譜についての解説

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

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

    プロジェクトの構想の真髄を「定時退社」を題材に考える

    プ譜を用いた振り返りと再構想

    「WBSを書くのが難しい問題」を、徹底的に解剖する

    プロジェクトの類型別攻略定跡

    基本4類型別に解説!プロジェクトの攻略定跡

    実体験から解説! 委託・受託型プロジェクトのよくある問題と対策

    共創と競争! 製品開発型プロジェクトは「組み合わせ」が鍵

    理念とリアルの相克! 事業開発の成否は「テーマとコンセプト」が握る

    計画か、即興か! 変革の成就には避けて通れない「矛盾」

    テーマとコンセプト

    WBSに疲弊しそうになったら、思い出してほしいこと

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

    プロジェクトの企画構想に、輝きを取り戻すための「視点」と「問い」

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

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

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

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

    PM/PL人材の評価・育成の方法を徹底解説【テンプレートあり】

    なぜ、PM研修に効果がでないのか?

    プロジェクト組織におけるPMの役割と、必要な個人の内的資源の話

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

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

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

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

    複雑化した座組みのプロジェクトを救うのは「カリスマ的プロジェクトマネージャ」ではなく「フラットな媒介者」

    シリーズ「地獄化プロジェクトからの脱出」

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

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

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

    趣味的な放談コンテンツ

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

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

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

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

    学びの場のご案内

    個人の方向けに、プロジェクトに関するお悩みやご相談をお受けするための場を運営しています。

    よろしければ、会の概要をご覧ください。