"Inspired日本語版第5章 プロダクトマネジメント vs. エンジニアリング"より
プロダクトマネージャーがより優れた製品の着想を得るためにエンジニアの助けを借りる3つの方法
1. エンジニアをユーザーや客先の前に連れ出すこと。ユーザーが苦労する様子を直接に見ることで多くのことを学べるだけでなく、問題点とその深刻さをもっとよ く理解できるようになる。これをヒントにして、もっと優れたアイデアや解決策を思いつくことも多い。この方法は、エンジニアをプロトタイプの検証に連れて くることで、すぐに実行に移せるはずだ。
2. 技術が発展することで何ができるようになったかを探るために、エンジニアの助けを求めること。今使える技術やいずれ使えるようになりそうな技術としてどういうものがあるか、それらが目先の問題の解決にどう役立つか、ブレインストーミングをやる。
3. エンジニアみんな (それが無理なら、主任エンジニアだけでも) あるいはアーキテクトを、製品開発の初めの段階から関与させて、早い段階でそれぞれのアイデアについて必要な費用を見積もっておき、より望ましいソリュー ションを決めるのに役立てること。プロダクトマネージャーがよく起こす間違いとして、すばらしい製品の定義を思いついて、それをエンジニアリングチームに 丸投げしてしまう、というのがある。そのせいで、何をしたいかと何ができるのかをすり合わせるという非常に重要な作業に取りかかるのが遅れて、いろいろな 情報をしっかり検討する時間もないまま意思決定をしなければならない状況に陥ってから、慌ててすり合わせをする羽目になる。
離れたところにいる開発チームといっしょに仕事をすることになった場合には、開発をうまくやり遂げる確率を劇的に上げるためにプロダクトマネージャーができる 3つのこと
1. 開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり 完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかってい ない (あるいは、コロコロ考えを変える) ために、離れたところで作業しているチームがもがき苦しむことだ。
2. 開発チームのみんなが近くにいる場合には、複数の人が原因となる衝突 (たとえば、2人のマネージャーが別々の指示を出す場合) は、普通にしていても目に入るので、すぐ解決できる。開発チームが遠くにいる場合には、頭にくるようなことが寝耳に水で山ほど起こるかもしれない、と覚悟 しなければならない。そして、食い違いに気づくまでに、文字通り何ヶ月もかかるだってあるだろう。こういうことになるのは、だいたいは、離れたところにい る開発者たちが、だれが何をどうしろと言っているのか、さまざまな指示をどう解釈すればいいのかなどを、推測しなければならない羽目になるからだ。当然、 こういう推測がいつも当たっているとは限らない。本拠地にいるだれかに、遠くにいるチームとのすべての調整を任せることが、どうしても必要になる。すべて のやりとりはこの人を通さなければならないということではないが、エンジニアリングチームが説明や報告をしなければならない相手はだれであるかがあやふや ではダメだ、ということである。この調整をやるのは、場合によって、プロジェクトマネージャーだったり、エンジニアリングチームの上の方の人でプロダクト マネージャーの近くにいる人だったりするだろう。
3. 今は、多くの会社で、社内で使える優れたコミュニケーションの仕組みをいろいろと整えている。電子メールやインスタントメッセージのほかに、テレビ会議の 技術もものすごくよくなっているし、VoIP のおかげで国際通話料もずいぶん安くなった。そうは言っても、やはり、直接顔を合わせて話せる態勢にできるなら、それに代わるものはない。プロダクトマ ネージャーは、少なくとも 3ヶ月に一度は、エンジニアリングチームのところに出向いて、彼らとしっかり顔合わせをして、中心となっているアーキテクトやマネージャーと打合せをする べきだ。実際に訪問して直接顔を合わせることで、離れ離れのメンバーとの関係やコミュニケーションはずっとよくなるだろう。コミュニケーションを向上させ る他の方法としては、人材交流制度を作って、主な開発者をプロダクトマネージャーのもとに一定の期間派遣する、という手もある。
