どうもばやしです。
最近「プロとしてリスペクトする」という言葉が仕事でのコラボレーションを妨げているかもなと思ったので考えていきます。
プロ同士の仕事
例えばWebシステムを作るときのことを考えます。 プロダクトマネージャーとデザイナーとエンジニアである自分の三人で作っていきましょう。 プロダクトマネージャーは、プロとして最も顧客価値を追求すべく要件を定義します。
「この画面ではこんなことができること」
「このボタンを押した際はこういう画面に遷移すること」
隙がない完璧な要件です。 デザイナーはプロダクトマネージャーが提示してきた要件をすべて受け入れつつ、顧客の体験が良いデザインを追求します。 そして自分はエンジニアとしてデザイナーが考えてきたデザインやプロダクトマネージャーが提示した要件をすべて満たす実装を作ります。 出てきた要件は既存のシステムのデータ構造では実現しづらいです。またデザインもこれまでにないコンポーネントなので結構時間がかかりそう。でもプロダクトマネージャーやデザイナーが出してきた要件やデザインはそれぞれがプロとして最高のものを作ってきてくれたものなので、自分もプロとして破綻なく既存のシステムに組み込みましょう。 ただどう考えても時間はかかるので、そこはちゃんとネゴっておきましょう。
プロダクトマネージャーに◯ヶ月くらいかかりそうです、って伝えたらちょっと顔が引きつってましたが、プロダクトマネージャーも自分のことをプロとして信頼してくれているので、納期を短く設定するようなことはされませんでした。 あとは完璧なものを作っていくだけです、よーしやってくぞ！
ってこういうのよくありません？
こんな感じに出来ないかなという話
プロダクトマネージャーは顧客価値を追求します。でも顧客がどんな人でこのプロダクトをどう使っていて今追ってるKPIや最近のプロダクト周りでの困り事はデザイナーもエンジニアである自分もちゃんと把握しています。 その上で次に開発したいものをプロダクトマネージャーが出してきました。困り事を解決するためのさっと考えた素案は伝えてくれましたが、どうせ色々変わるのでそこはあんまり時間を掛けません。どんな困り事があるかとかがメインです。 デザイナーとエンジニアはそれぞれが自分の専門領域に基づいてどう解消出来るかを考えて話し合います。プロダクトマネージャーもその話合いに参加します。
「こういう機能にしたいなら、こんな画面にすると良さそう。ここにこんなボタンを配置して」
「そのコンポーネントは新しく実装することになるので、結構時間かかっちゃうかも。例えばこの画面にあるこのコンポーネントで代用できないかな」
「この機能の売りは◯◯だから、ここだけはこだわりたいな。時間かかってもここを譲ると出しても意味ない機能になっちゃいそう」
こうしてプロダクトマネージャーとデザイナーとエンジニアがそれぞれの専門領域を共有しながら、全体で最もコスパの良い機能を決められましたとさ、めでたしめでたし。
プロであることと相互不可侵は違う気がする
プロダクトマネージャーが要件考える時も、デザイナーがデザインする時も、エンジニアが実現手法を考える時も、色んな選択肢があってその中で自分の閉じられた領域でトレードオフを踏まえてベターな選択をしてると思います。 そうして出てきた決定は熟考を重ねられたものですし、相手が専門知識を動員して出してきたものなので、もちろん自分が素人目線で否定して良いものではないです。ただ、相手をプロとして尊重するがゆえに、その決定に対して調整をすること自体が失礼と思って丸呑みしてしまうことをやっちゃいがちだよなーと感じてます。ロールが別れた他人同士になると、途端に結論以外の情報をやり取りしなくなるのはもったいなくないですか？
トレードオフを踏まえる領域を全体に広げて、全員でベターな選択をするようにしたいなと思いました。 そのためには相手の領域への理解が結構必要かなと思うのですが、それは学んでいくしかないかなと思ってます。
みたいな話（全然ディティールは違うけど）をPdMにしたら、休み明けに「みんなで仕様を揉む会」というものが設定されてました。まだ固まっていない仕様を持ってきてエンジニアやデザイナー含めてみんなでわいわいする会だそうです。ありがたいですね。
以上です。
