追加の質問です。 うちの組織では「エンジニアは開発に集中、デザイナーはデザインに集中」という前提があり、それ以外の業務をすべてPMが担う形になっています。 リリースは1〜2週間に1度のペースで、常に仕様書を先回りで準備しておかないと開発の手が止まってしまう状況です。 セールス側も「毎回リリースがある」ことを前提に顧客コミュニケーションをしており、開発サイクルを止めづらい空気があります。 質問1 軸が定まりきっていないことは自覚しており、まずそこを明確にすることに時間を使うべきだと理解しました。 ただ、そのためにいったん開発を止める（＝リリースを止める）ことは現実的でしょうか？ もし止めるとしたら、エンジニアだけでなくセールスやマーケにも説明が必要になりますが、「軸を定めることの重要性」をどう伝えれば理解してもらえるでしょうか？ 質問2 「他の人を巻き込む力が必要」という点もまさにだと感じています。 とはいえ社内では「PMがやって然るべき」と思われている業務が多く、他の人に振ることが難しいのが現状です。 上司もPdM出身ではないため、PMの仕事範囲を誤解している節があります。 こうした状況で、巻き込みや役割の再設計を進めるにはどんなアプローチが現実的でしょうか？

質問1 完全停止は難しいと思いますが、止め方の戦略をどう考えるかです。リリースを小さく保ち、その間に未来を考えるというのがよいのではと思います。つまり、ストレートフォワードな開発アイテムだけを取り揃えて、ある程度PM不在でもできるようなリリースで時間を稼ぐスプリントがあってもよいのでは、と。 あわせて、今は周囲が「機能=価値」と思っている段階だと推察しますので、学習も価値提供であるという文脈でいかに立ち止まることを正当化できるか、というのが次に超えるべきハードルだと思います。 質問2 他人を動かすよりもまず他人の仕事の構造を変える必要があるかもしれません。おそらく「業務を振る 」に強い抵抗がある環境だと思いますが、「判断を分担する」から始めてはどうでしょうか？ たとえばユーザー課題の特定はセールスやCS、UIトレードオフ判断はデザイナーとそれぞれ分担できると思います。分担するところから始めて徐々に分担の割合を増やし、結果的に業務そのものも自然と渡せる状態というのが理想です。PMが意思決定のボトルネックになる状態は誰も望んでいないはずなので、結構周囲の抵抗は少ない状態で進められるのではと思います。 あとは、上司の立場でいうとたとえ特定の部下がやるべき仕事だと思っていても他のメンバーにその仕事を振る瞬間があります。それは、その部下が業務過多である時です。まずは日々の緊急度の高いタスクに追われて優先度の高いことができていないという現状をベースに、しっかり上司と話し合ってください。最悪の場合は優先度の高い業務のほうを他の人に回されますが、まぁそれもプロダクトの成長のためにはトータルで見ると悪くないと思います。