
この記事について
あらゆるプロジェクトには個性があり、絶対にこうすればうまくいく、というものは、ありません。一方で、プロジェクトにはある程度の類型化や経験則、パターンがあるのも事実です。
このシリーズでは、委託・受託型、製品開発型、事業開発型、変革型の4つの類型に対して、進行にあたっての定跡を解説します。
今回は、委託・受託型プロジェクトは、なにを、どこからどう始めるとよいのか、なにがどうなれば一件落着にするのかを、筆者自身のものづくり業、IT業、人材開発業での「思い出の言葉やエピソード」から、解説します。
もくじ
1 着目する問題:委託・受託型プロジェクトはどうすれば落着するか
2 ものづくりの世界から得た教訓
3 ITプロジェクトからの学び
4 人材・組織開発の世界ではどうか
5 まとめ:委託・受託型プロジェクトの真髄を、プ譜で表現する
着目する問題:
委託・受託型プロジェクトはどうすれば落着するか
世の中には、制作業というビジネスモデルがあります。目の前のお客さんのために、目の前のお客さんが欲するものを作り上げ、引き渡す、というものです。
ジャンルは非常に多岐にわたります。家を建てる、とか、業務システムを構築するとか、キャッチコピーを書くとか、イラストを描くとか、マーケティング調査をする、映像作品を作る、などなど、実に様々なものがあります。
制作業の面白いところは、お客さんの要望や好みが千差万別だ、ということです。ものすごくこだわりが強いお客さんもいれば、ものすごくあっさりしたお客さんもいます。
プロセスが大事だ、というお客さんもいれば、結果が大事だ、というお客さんもいます。予算がたっぷりのお客さんもいれば、そうでないお客さんもいます。成果物の目利きができるお客さんもいれば、そうでないお客さんもいます。急いでいるお客さんもいれば、そうでないお客さんもいます。
このように、制作業においては、お客さんのあり方は実に多様です。
と同時に、どんなお客さんにも共通することも、あります。
それは、実際に、仕事を一緒にしてみる前には、どんなお客さんなのか、わからない、ということです。
そして、一件落着してしまえば、また別の、新しいお客さんに出会っていく、ということです。
制作業において、新しいお客さんと出会い、新しいプロジェクトを始めるときには、それまでの経験はゼロリセットされてしまいます。毎回毎回、未知なるお客さんの、未知なる要望と出会っていきます。
制作プロジェクトの世界は、山もあり谷もあり、酸いもあり甘いもあり、実に豊かです。
今回のテーマは、委託・受託型プロジェクトの進め方です。
ものづくりの世界から得た教訓
筆者が社会に出てから最初に従事したのは、ものづくりの世界でした。ものづくりのなかでも少々特殊な「試作」の仕事でした。自動車メーカーや家電メーカーが設計した部品データを受け取り、試作品を作って納める、というものです。
その会社では、当時、世の中に登場したばかりの光造形・粉体造形技術というものを使っていました。いまでいう「3Dプリンタ」というやつです。
従来は、いわゆる樹脂成形とぃう分野で試作品を作ろうとすると、金型を起こさなければならなかったので、期間として最低数ヶ月はかかるのが当たり前でした。その常識を覆したのが、3次元造形技術でした。これを活用すると、3Dデータさえあれば、ものの数日でモノを作って渡すことができ、とんでもない時間短縮になると、一世風靡していました。
就職する前は、とんでもない夢の技術で、これを使えば世界が変わると衝撃を受け、期待に胸を膨らませ、勇んで就職したのでした。しかし、いざ入社してみると、大変に困難な毎日が待っていたのでした。
「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わっていった日々
確かに、あっという間にモノはできあがる。
しかし、結構な頻度で、不具合が生じる。曲がったり、ねじれたり。寸法が出なかったり。変色したり、割れてしまったり・・・
ものがうまくできないだけではありません。当時、その技術は非常に高い人気を誇っていました。ゆえに、多くの顧客から、注文が殺到していました。そこで起きのが「順番待ち」でした。機械にかけてしまえば、たった数時間で、モノができる。しかし、その機械にかかるまでの順番待ちに、3日も4日も待たされる・・・なんてことも、よくありました。
高速試作サービスと銘打って、スピードを売りにしているのに、機械の順番待ちで、そのスピードが殺されてしまう。なんとも皮肉な状況が、そこにはありました。
また、これも入社してみて驚いたのが、「サービスが、自社では完結しないことも多い」ということでした。
造形品を作って終わり、ではなく、そこに塗装をしたり、あるいは仕上げのための治具(組付け台のようなものです)を作ったり。あるいは、造形品をマスターとして型を取って、そこからさらにコピーを作ったりもします。
そうすると、そこでまた時間もコストもかかるのは当然ですが、それだけでなく、その案件全体の元請けとして、外注先の責任も、自分が引き受けなければならないのでした。そうすると、そこでまたコミュニケーションエラーや不具合、遅延が出てきたりします。
入社した当初の、まだ若かった自分は、外注先のミスや納期遅れは、外注先の責任であり、自分が被る必要はないはずだと思っていたのでした。責任を軽く捉えて進行させ、案件を失敗してしまい、先輩に呆れられたり怒られたりしたものでした。
そんなこんなで「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わっていったのを、いまでも懐かしく覚えています。
未熟だった自分に「仕事観」のコペルニクス的転回を与えてくれた、あるお客さんの一言
当時、担当していたお客さんから、仕事の真髄を教わった言葉に、こんな一言があります。
「それは、御社のご都合でしょう」
そのお客さんは、納期もスケジュールも、予算にも非常に厳しいお客さんでした。連休があったら、休み前の深夜にデータを渡して、休みが明けたら早々にモノが届くのが当然、といったところが通常営業、というお客さんでした。
社内の製造メンバーにも嫌がられるし、対応してくれる外注先も、簡単には、見つからない。新人営業としては、いかに営業成績になろうとも、仕事が来てほしくないお客さんナンバーワンでした。
しかし、発注の量が多い。ゆえに、上司からは、絶対に競合には渡すな、との厳命が下されていました。
担当になってからしばらくは四苦八苦しながら対応をしていましたが、ある日とうとう我慢ができなくなりました。意を決して、電話口で、できない理由を並べ、どうにか納期を伸ばしてもらえないかと懇願しました。
そこで放たれた、それはそれは冷たく突き放す一言が「それは、御社の都合でしょう?」の言葉でした。
あまりに予想外過ぎて、ガーンと衝撃をくらってしまい、なにも言い返すことができませんでした。交渉の余地が、まったくない。そんなことって、あるのか!?という衝撃でした。人間として、そんなことって、あるの??と。
しかし、こういう瞬間に、何も言い返せないと、その時点で、交渉敗北は決定的です。電話を切ったあとは、また泣きべそをかきながら、手配の奔走を再開したのでした。
世が世なら、下請けいじめとか、ハラスメントと言われるようなことかもしれません。あまりの理不尽さに、ほとほと困っていましたし、先輩に相談しても助けてくれるわけでもなく。これは、大変な会社に就職してしまったぞ・・・と、思っていました。
しかし不思議なもので、その理不尽体験こそが、自分にとって、決定的に重要な成長を促してくれたのでした。
なにに気づいたのかというと、「一見理不尽なオーダーでも、条件や段取りを工夫すれば、別にそんなに手配が難しくもないぞ」ということでした。
工夫とは例えば、納期が厳しい分、仕上げのレベルを落とさせてもらう、といったようなことです。作業を省いて納期短縮を図れば、自社の現場は助かりますし、納期にも間に合います。
もちろん、いくら早くても粗悪品を渡したら意味がありません。品質として、重要な部分はきっちりやるが、そうでない部分は、徹底的に、手を抜く。なにが重要なのかを理解するために、お客さんに、試作の目的を聞く。風洞試験なのか、外観を見たいのか、嵌合なのか。
納品にしても、最初から全数が欲しいのか、それとも、一個だけ最初に頭出しが間に合えば、そのあとのものは、もう少し待ってもらえるのか。
その他、外注手配にしても、人気があって、いつも忙しくて混んでいる外注先に特急の仕事をお願いしても、嫌な顔をされるのは、当たり前です。嫌がる相手に、無理やり仕事をさせても、いいものはできません。だったら、仕事が薄くなってしまって、売上が恋しい外注先を探せばいい。
案件や状況が理不尽なのではない。自分の観察と工夫が足りなかっただけだった。
丁寧に仕事の中身を見ていけば、お互いが満足できる妥協点が見つかる。
そういうことに、気付いたのでした。
受託制作プロジェクトというものは、無理な条件をそのまま右から左に横流しして、製造現場にゴリ押しで押し付けてやっても、苦労が多く、益はありません。まずは、お客さんの期待を理解する。そのうえで、最も効率よく進める道を描く。さらには、その仕事を、みんなで喜んでやれるように、条件を調整し、座組みを作る。
そうしたもろもろの工夫をするのが、自分の役割なのだとわかってからは、仕事を回すのが随分と楽になりました。
そういうふうに、発想を切り替えることができたのは、ある先輩の、なにげないひとことでした。
「客、おれら、外注。みんなが喜ぶ案件が、いい案件なんだ。」
試作営業は、明らかに、かなりハードルの高いプロジェクトマネジメントが求められる世界です。納期も予算もたっぷりで、品質チェックも楽々、外注先だって大喜びで付き合ってくれて、みんな仲良くワッハッハ、なんてことは、まず、ありません。
どこかで必ず、結構な無理を求められる。そのときに、受注の窓口に立った自分が、あぐらをかいていてはだめで、どうにかこうにか、いろんな条件を調整し、みんなが納得できる形を探っていく。
一見、あちらを立てればこちらが立たずでも、どこかで誰かが妥協できる余地がある。それを見つければいい。それこそが、プロジェクト進行の極意なのだと、悟ったのでした。
発想の転換をうながしてくれた、先輩の言葉たち
思い返してみると、当時は先輩のもらした、ふとした一言で、学んだことが多かったなと思います。
たとえば、不具合という問題に対して目を開かせてくれた言葉が、こちらです。
「不具合は、必ずどこかで、起きるもんだ。大事なのは、問題が起きたときに、交渉できる土俵を作っておくことだ」
どんなに手配を完璧にしたって、ものをつくるという過程で、避けられないのが不具合です。こればかりは、確率的に、絶対に、ゼロにはならない。どうしようもない。
不具合が起きたときに、100%こちらの責任であった場合、損害は、こちらがかぶらなければなりません。しかし、不具合が結構な頻度で発生する技術を扱っていたので、これが本当に大変でした。
製造現場が出した不具合なのだから、作り直しをするなりなんなり、工場側が損失をかぶってくれれば、別にこちらは困らないのですが、現場は現場で、大量のオーダーをさばくのに必死です。
しかし、現場のエンジニアや工員の皆さんは、不具合が出たときに「ごめんなさい、直します、間に合わせます」とは、なかなか、言ってくれない。
「これ・・・なんとか、うまいこと言って、お客さんに、納めてくれない?」
「納期、伸ばせないかなぁ」
「いやいや、そこを交渉するのが、営業の仕事でしょう!」
こういう言葉も、ナイーブだった新人営業時代、理不尽に思ったものでした。
完全なる、自分の会社とお客さんの、板挟み。
間に立つ自分だけが、損をしている気分・・・。
不具合問題に対する工夫は、制作を進める過程で、「ここにはこういうリスクがありますよ」とか「本当にこれで進めていいですね?」といった、事前承認のくさびを打っておく、ということでした。
そうすることで、コントロールできないリスク要因であっても、ある程度はリスクヘッジが可能になる、ということを教わったのでした。
かたやで、その対極にある、こんな言葉もあります。
「どうやって納品するかって?そんなものは、受注してから考えるんだよ!」
これは、過去にないほどの巨大な制作案件でのことでした。考えてみるまでもなく、強度が出るとは思えないし、作れるというイメージが、まったくわかない。「座組み」とか「リスクヘッジ」とか、そんなことを考える以前に、どうしたらいいか、わからない。
そんな案件の引き合いがあり、当時の部長に営業同行してもらった帰りの車の一言です。
どうやったら作れるのか、皆目見当もつかないなか、部長はお客さんとの打ち合わせをスラスラと進めていきます。その打ち合わせで伝えたメッセージは、ふたつ。「できる」と「任せてくれ」というシンプルなものでした。
さすが部長、どうやったら作れるかを、すでに考えてくれていたんですね、地獄に仏です・・・と帰りの車の中で感謝したら、答えは「そんなもん、わからん」とのこと。
茫然としていたら、極めつけに、「お前が考えるんだよ!」と突き放されてしまいました。
その2ヶ月後には、すったもんだの挙げ句、どうにかこうにか、形を作ることに成功しました。
丁寧に段取りし、確実に納めていくだけではない。ときには、大きく、リスクを取るから、チャンスを活かすことができる。
「どうすればできるか」に一点集中して考えることも、大事だという、教訓を与えてくれた一件でした。
ITプロジェクトからの学び
その後の別の会社の仕事で、ITプロジェクトにも携わる機会がありました。
いわゆるノーコード、ローコードツールの先駆け的な製品で、プログラミングの知識がない人でも、システムを自由自在にカスタマイズできる、というものでした。我が社の製品を使えば、業務マネジメントが自由自在ですよ、という謳い文句の製品でした。
その製品の革新性に感激し、喜び勇んで期待して入社してみて、蓋を開けてみたら「お客さんは、ITが好きではない」という現実にぶち当たったのでした。
すでに導入しているお客さんを回ってみると不満の声ばかり。恨み節に怒りの色が、異様に濃い。
いざシステムを見てみたら、その理由は、一目瞭然でした。お客さんたちは、ITに詳しいわけでも、スキルがあるわけでもない。彼らがにらめっこしていたのは「一生懸命やっているうちに、わけのわからないカスタマイズを繰り返して、カオスになった業務画面」だったのでした。
またしても、「夢のようだと思った新技術」が、あっという間に「困難な現実」にすり替わる日々が始まりました。
一番最初の仕事は、「導入のやり方を間違えて、ぐちゃぐちゃになってしまった画面を直して回る」という仕事でした。ITの世界でも、ものづくりの世界で学んだプロジェクト哲学が、そのまま役に立ちました。
●なにはともあれ、お客さんが、なにを欲しているのかを理解する
●欲するものを、最短で作り上げるための段取りを考える
●予算や納期の兼ね合いで、難しいところがある場合には、バランスを調整する
●どうしても手のかかる、大変な仕事には、十分な資源を張る
●できる限り、その仕事をすることを喜んでくれる人を座組みに引き入れる
●リスク要因は先に提示しておき、トラブルが起きても適切に扱えるようにする
●ひとつひとつの作業がちゃんと回っているのか、現場に入って時々ちゃんと確かめる
●コミュニケーションの齟齬がないように、やってほしいことは丁寧に伝える
といったことです。
ただし大変だったのが、大規模プロジェクトでした。こればかりは、情報整理や条件調整、といったことでは管理しきれない。そこでとうとう、PMBOK式のマネジメント術を習得しながら、仕事を進めることになったのでした。
いわゆる、WBSを厳密にする、課題管理をちゃんとやる、定例会議の運営、的確な議事録の配布、テスト計画と実施記録を綿密にする・・・といったものです。
いろいろな手段を体験するなかで、IT大規模プロジェクトで一番大事だと痛感したのは「コミュニケーションデザイン」でした。
どういうことかというと、規模の大きなITプロジェクトは、とにかくやたらめったらと、検討内容や議論が複雑なのです。抽象的な話も多いですし、細かい話も多い。利害対立することも多く、起きている問題も複雑化しやすい。
すこし油断していると、関係者全員の心があっという間にバラバラになりますし、議論も錯綜しがちです。
議論を整理整頓して手際よく進めていかないと、「半年間、ただわあわあ言いたいことを言い合っていただけだった」みたいなことにも、なりかねません。
そうならないためにやったのが、定例会議と分科会の建て付けの整理、各回のアジェンダの整備、適切な参加者への呼びかけや、会議前後の根回し、確認、というものでした。
人材・組織開発の世界ではどうか
独立後、いわゆる人材・組織開発の世界のプロジェクトに携わることになりました。コンパクトなものだと、研修の依頼をいただいて、プログラムを工夫し、実演する、というようなものです。
すこし大掛かりなものですと、組織風土を変えていこう、とか、業務プロセスを刷新していこう、といったテーマのなかで、コンサルティングや伴走もしながら、長期間関わっていく、というものに発展していったりします。
ここで、ものづくりの世界と真逆だったのは、品質基準がよくわからない、ということでした。特に、研修のようなサービスの場合、発注者が現場のことをよく知らない、ということがしばしばあります。どんな研修をしたら喜ばれるのか、なにがどうなったら合格なのか、よくわからないなかで、とにかくやる、みたいなことが、結構よくあります。
発注者だけでなく、研修の受講者の皆さんも、良かったとか悪かったとか、所感を述べてくれることはありますが、客観的かつ公平に、目的を達成できたかどうかは、言えません。
それは考えてみれば当たり前で、研修というものは、一時的に講師と受講者が関わり合いを持つことで、なにかしらの変化のきっかけとする、というものです。その変化は、すぐに出てくるものではありませんし、変化が起きたかどうかを観測、評価することも、難しかったりします。
その変化が、研修によって引き起こされたのか、ということも、検証しようとしても、客観的に示すのは難しいところがあります。
研修業を始めたときに最も強く悩んだのは、事前にテストもできなければ、真のニーズもわからない、ということでした。当日、受講者の皆さんと顔を合わせてみないと、わからない要素が、あまりにも、多すぎる・・・という。
ものづくりやITの仕事では、客観的な、なにかしらの現物が目の前にあって、寸法なり動作なりを確認することができました。しかし、教育サービスでは、事前に仕様や要件を詰めることも、提供した成果物の品質や効果を評価することも、難しい。
とはいえ、そのように姿かたちが見えにくい取り組みといえども、当事者の体感として、これはうまくいったぞとか、今回は残念だけど、ちょっと違ってしまったなという、実感を持つこともあります。
うまくいったぞと思えるときには、必ず、クライアントと提供側の相互理解ができていた、というところが背景にあります。また、限られた情報のなかで、テーマ設定や教育手段を正しく選択できていた、というところもあり、そのためのコミュニケーションや、実施までの段取り、マイルストンの設定の仕方には、ものづくりやITプロジェクトと、共通するものがあるのは確かです。
一方で、こうした人材・組織開発やコンサルティングのような取り組みは、成果物としての目標を決めて、その制作を目指すという、純粋な委託・受託モデルでは捉えきれない部分もあります。それについては、引き続き、他の類型についてのコラムでも、取り上げていきたく思います。
まとめ:委託・受託型プロジェクトの真髄を、プ譜で表現する
ものづくり、IT、人材開発と、いろんな業界で経験してきたプロジェクトマネジメントですが、抽象化していくと、そこにはいつも共通する「原理」が流れています。
題材や状況、取り組みの中身が違っても、制作プロジェクトであれば必ず共通する、普遍的真理のようなもの―――
それを図示したのが、こちらです。

獲得目標、勝利条件、中間目的の3つは、どんな類の受託プロジェクトでも、そうそうは外さない、定跡的な表現を目指しています。
まず、獲得目標について。委託・受託プロジェクトでは、なにをつくるのかを、なにはなくとも、合意せよ、ということです。取り組みの最序盤の、この設定の精度が高いか低いかによって、その後の協議や実作業がスムーズにいくのか、道に迷って難航してしまうのかが決まります。
次に、中間目的について補足しますと、具体的なレベルではやはり、いわゆるPMBOK的な計画や契約、ドキュメンテーションの精度が求められますが、それを支えるものとして「甲乙双方の相互理解」というものが欠かせません。
依頼者がなにを欲しているのか、受託者の得意や強みはどこなのか。相手に対して、勝手な願望を抱くだけで、それぞれが勝手にシャドーボクシングをしているだけ、というようなプロジェクトは、世の中意外と多いものです。
そして最後に、変更管理というものが、あり得ることを前提にしておこう、ということです。委託・受託プロジェクトでは、成果物が出来上がったときに初めて、本当に欲しかったものが、具体的に、モノとして具現化されます。ゆえに、初期設定や初期計画にあまりとらわれすぎると、かえってうまくいかなくなります。
そのような中間目的を実現するための施策については、代表的なものをシンプルに表現し、並べていますが、ポイントは、所与の条件や必達目標、想定リスクなど、その現場や状況にあわせて可能なものを、そして必要なものをアレンジしていく、ということが、肝要です。
以上、委託・受託型の制作プロジェクトで、ときに道に迷いそうになったら、ご参考としていただけると幸いです。
この記事の著者

プロジェクト進行支援家
後藤洋平
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/
この記事もおすすめ
プロジェクトワークの基本的な世界観
「プロジェクトの進め方」は1つじゃない!8つのタイプ別に考える推進アプローチ
受託/商品開発/事業開発/変革など、プロジェクトの進め方と勘どころをタイプ別に解説!
「取引」(商談・契約・納品・検収)の一連の流れを「モノ」と「プロセス」の二元的解釈によって読み解く
要望/要求/要件/仕様/設計の違いについて解説!【テンプレートあり】
テンプレートや作例も!プロマネスキル向上のヒント集
ITじゃないプロジェクトも!WBSの書き方再入門【テンプレートあり】
タスクの無間地獄に落ちないための、課題管理のコツ【テンプレートあり】
うっかり間違えやすい、「要件定義」の本質的な意味と方法【テンプレートあり】
SaaS・AI時代のITプロジェクトの鉄則
ITサービスの導入成功に必要な「プレ・キックオフ・コミュニケーション」のご紹介
SaaSを活かすか殺すかは、情報システム企画構想の質が決める【テンプレートあり】
究極の手戻り対策:作業後の「やっぱ、ここ、こうして」問題はどうするとよいか
プロジェクトの遅延やトラブルは、「キックオフ」の時点で、すでに始まっている
AI時代、それはプロジェクトの「マネジメント」でなく「デザイン」の質が問われる時代
プ譜についての解説
プロジェクトの類型別攻略定跡
実体験から解説! 委託・受託型プロジェクトのよくある問題と対策
テーマとコンセプト
プロジェクトの企画構想に、輝きを取り戻すための「視点」と「問い」
プロジェクト進行能力を、組織的に底上げする
社員のプロジェクト進行スキルを、組織的に底上げしていくための処方箋
3つのお悩みカテゴリでわかる!PM、PL人材の層を厚くするための、打開のヒント
PM/PL人材の評価・育成の方法を徹底解説【テンプレートあり】
プロジェクト組織におけるPMの役割と、必要な個人の内的資源の話
「プロマネスキル」と「社会人基礎力」の違いを本気で考えてみる!
「PMやPMOに、コストをかける意味って、ほんとにあるの?」という素朴な疑問への答
複雑化した座組みのプロジェクトを救うのは「カリスマ的プロジェクトマネージャ」ではなく「フラットな媒介者」
シリーズ「地獄化プロジェクトからの脱出」
年商10億円の伸び悩み問題を「組織的プロジェクト進行能力」の視点で考える
趣味的な放談コンテンツ
少年漫画の金字塔「HUNTER×HUNTER」は、プロジェクト的思考のヒントのパラダイス
