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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●これまでの前例から「いつもどおりでいいよ」というつもりで詳細な指示を省略している
●そもそもお客さんが光造形試作が初めてのことで、バリエーションがあると想像もしていない
●とりあえず、なんでもいいからおまかせ
●実は絶対に譲れないこだわりポイントがあるけれど、言い忘れた
●当たり前のことだと思っていたから、あえて伝えるという発想がなかった
●通常、お客さんから指定するような話が、先方側の知識や経験が不足していたために抜けてしまった

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

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

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

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

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

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

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

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

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

●「いやいや、細かく指定しなかったお客さんのせいでもありますよね」と粘る。
●「ごめんなさい！受け取ってください！」と、理屈抜きで拝み倒す。
●「急いで作り直します！」と持ち帰る。
●「今回は泣きますが、次の案件ではちょっと価格を乗せさせてくださいね」と持ちかける。
●「わかりました、今回は修正します。が、今後はおたくの仕事はお断りします」と強気に出る。
●「二度とこういうことがないように、工程を改善したいので、ご一緒に今後について話しましょう」と歩み寄る。

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

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

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

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

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

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

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

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

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

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

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

「それは、御社のご都合でしょう」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「客、おれら、外注。みんなが喜ぶ案件が、いい案件なんだ。」

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

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

　ちなみに、そうした学びや気付きのなかで、筆者が実現した最大のウルトラCは「いつも納期とボリュームとコストが厳しい顧客（メーカーの開発部門）からの案件の外注先として、いつも品質に厳しい別の顧客（試作屋）を活用する」というものでした。
　これは当時、先輩営業も含めて、誰も発想したことのないアイデアでしたが、自分も楽、顧客も喜ぶ非常に円満な座組みとなりました。いつも怒られてばかりだったのに、このときは焼き肉までご馳走になりました。

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

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

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

「不具合やトラブルは、必ずどこかで、起きるもんだ。問題が起きたときに、交渉できる土俵を作っておけ」

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

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

　「これ・・・なんとか、うまいこと言って、納めてきてくれない？」
　「納期、伸ばせないかなぁ」
　「そこを交渉するのが、営業の仕事でしょう！」

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

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

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

「どうやって納品するかって？そんなものは、受注してから考えるんだよ！」

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

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

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

「お前が考えるんだよ！」

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

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

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

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

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

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

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

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

●なにはともあれ、お客さんが、なにを欲しているのかを理解する
●欲するものを、最短で作り上げるための段取りを考える
●予算や納期の兼ね合いで、難しいところがある場合には、バランスを調整する
●どうしても手のかかる、大変な仕事には、十分な資源を張る
●できる限り、その仕事をすることを喜んでくれる人を座組みに引き入れる
●リスク要因は先に提示しておき、トラブルが起きても適切に扱えるようにする
●ひとつひとつの作業がちゃんと回っているのか、現場に入って時々ちゃんと確かめる
●コミュニケーションの齟齬がないように、やってほしいことは丁寧に伝える

　といったことです。

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

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

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

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

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

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

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

　この「新しい、お客さんのあり方を納品する」という仕事で、ものづくりの世界と真逆だったのは、品質基準がわからない、ということでした。
　特に、研修のようなサービスの場合、発注者が現場のことをよく知らない、ということが、わりとよくあります。特に、大組織の人事部門の管掌する研修プログラムのような場であるときに、顕著にそんなことがあるのですが、どんな研修をしたら喜ばれるのか、なにがどうなったら成功なのか、発注者ですら、よくわからない、そのなかで、「まぁとにかくやってください」みたいなことが、結構よくあります。

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

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

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

　しかし、教育サービスでは、事前に仕様や要件を詰めることも、提供した成果物の品質や効果を評価することも、難しい。そして、イマイチだったからといって、やり直しがきくものでもない。

　こうした矛盾を解く鍵は、人材・組織開発やコンサルティングのような取り組みは、成果物としての目標を決めて、その制作を目指すという、純粋な委託・受託モデルでは捉えきれないのだ、ということを理解することにあります。
　教育サービスは、発注窓口に対しては委託・受託型でありながらも、受益者である受講者に対しては、製品開発型の取り組みである、というふうに考えることで、対処方法は見えてきます。その詳細については、ご興味のある方は、以下のリンク先をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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