開発者が「No」と言ったときに尋ねるべき4つの質問

• 開発者がNoと言ったときにどう対応するかは、プロダクトマネージャーとして主導権を発揮し、目標を達成するうえで役立つ
• 技術的な理由で、提示された期限内に機能を実装できないと言われた場合でも、適切な質問によって状況を打開できる

1. 機能を構築するうえで、別の技術的な解決策はありますか？

• 機能を構築する方法は複数あり、最初に試す方法が常に最適とは限らない
• 開発者は最新技術を使って優れた機能を作りたいと考えがちだが、それはシンプルさを最適化する代わりに過剰なエンジニアリングにつながることがある
• 特定の技術スタックを持つ開発者は、自分の知識の範囲外にあるよりシンプルな解決策に気づかないこともある
• そのため、エンジニアが技術的な解決策についてより創造的に考えられるよう促すのがよい
• 私が一緒に働いた最高のプロダクトマネージャーの中には、技術環境に関する十分な技術的洞察と知識を持ち、エンジニアが既成概念にとらわれずに考えられるような示唆に富む質問を投げかけられる人がいた

2. この制約条件のもとで解決策を提示しなければならないとしたら、どうしますか？

• あなたが提案した解決策に開発者が問題を指摘してきたら、彼ら自身の解決策を尋ねてみる
• 開発者は創造性と革新の宝庫であり、よりシンプルなバージョンの機能がないかを尋ねることで、創造的に考える機会を与えられる
• 問題の核心を理解すれば、開発者は創造的に考え、プロジェクトの制約内で機能する解決策を見つけ出せる

3. この機能について段階的なアプローチを検討できますか？

• 技術的な複雑さを理由に機能の実装が難しいと言われたときは、プロジェクトを段階ごとに分けて、異なるリリース日に設定できるかを尋ねる
• 一度に壮大なビジョンを提供したくなる誘惑はあるが、段階的なアプローチのほうがより反復的で、具体的な成果をより早く提供できる
• 優先順位は変わる可能性があり、段階的なアプローチなら、次に追加すべき機能を開発者と調整できる

4. この作業を可能にするために、どんな障害を取り除いたり解決したりできますか？

• これはリソースに基づく異議への質問であり、開発者が限られたリソース（例: 時間や利用可能な開発者）を理由に挙げる場合、彼らの時間を確保するために積極的に作業を減らす
• 可能な方法: 作業を完全に削除する、開発者を必要としない作業を自分が引き受ける、他チームや第三者とのコミュニケーションを担当する、プロセスを担ってレガシー機能を廃止することで作業をしやすくする

結論

• 開発者の「できない」という言葉に対して「さらに押す」ことに不快感があるかもしれないが、それによってより多くの敬意を得られることもある
• エンジニアが反対する理由をもう少し深く掘り下げ、その理由を把握し、反対意見を一つずつ取り除いていく必要がある
• これらの質問は、エンジニアが特定の機能を実装する際に直面しうる固有の難しさや制約を認識しているからこそ、いずれも良い質問である
• また、チームやプロジェクトを助けるために、自ら袖をまくって面倒な作業を引き受けたり、要件やスケジュールに合わせて調整したりするなど、自分の役割を進んで果たす意思を明確に示すことでもある

[sirotan]

結局はどう調整するかにかかっているんですね
良い内容をありがとうございます
上の内容をもとに聞いてみれば、本当にただやりたくなくて「No」と言っているだけなのはすぐに見分けられそうです

[ddaemiri]

私がPM/POとして、プロジェクトで事業部門とIT部門の調整役をするときに役立った方法論が2つあります。
もちろん前提として、事業部門もIT部門も「話が通じる」ことが必要です。
1つ目は、段階的に進めること。
2つ目は、規模を縮小すること。
この2つです。
事業部門でもIT部門でも、プロジェクトを進めるうえで最大の悩みは「期間」です。
期間は決まっているのに、その期間内ではボリュームをこなせなさそうなことがいちばん多いですよね。
こういうときは「段階的」に進めます。phase1、2、3…のように順次スケジュールを組むのです。最も重要な機能をphase1に、そこまで重要でないものをphase2に……という形です。
ただ、こうやって段階的にできないプロジェクト、つまり一発で公開しなければならないものは、
規模を「期間」に合わせて縮小する必要があります。phase 1、2、3に入るもののうち、「本当に必要な機能」以外は削るべきです。
この2つの方法論であれば、「話が通じる事業部門／IT部門」ならたいてい同意してくれます。
プロジェクトが頓挫して、それぞれが自分の上司に怒られるよりはましですから……。
はぁ。
みなさん、頑張ってください^^

PS:
最後にもうひと味あるのですが。
上の2つの方法を使っても、開発者が難色を示すことは多いです。
そういうとき、
「プロジェクト期間の中ほどで一度チェックしましょう。その時点でさらに期間が必要そうなら、私が責任を持って期間延長します」
と言うと、開発者の表情が和らぐことが多いです。
そして実際に中盤あたりでチェックすると、追加の期間が必要ないケースが95%でした。
それに、開発者はコーディングを始めると意外とすぐ進むことが多いんですよね。

[exit55]

開発者と調整しなければならない立場の人間として、こういう会話ができる開発者と一緒に働きたいですね。ひとまず「できない」と言う開発者にしか会ったことがなくて、残念です。あれこれなだめたり尋ねたりしてみると、本人が知らない方法があったケースがほとんどなんですよね……

[abhidhamma]

wwwwwww 胸が痛いですね..

[bbulbum]

エンジニアなら、"NO"と言う前に自分自身に問いかけるべき質問。

[neidn]

私自身に対しても、本当に良い問いかけだと思います

[evenn33111]

エンジニアである前に人ですからね。エンジニアとしての習慣的な No が問題だという点には同意しますが、PM/PO 側がああいう質問を持っていれば大きな助けになると思います。