こんにちわ。
Marty Cagan著”INSPIRED: How To Create Products Customers Love”の日本語訳をお届けしておりますが、今回は、Part1 人材編の前半の最後の章をお届けします。
第１章でソフトウェア開発組織における主な役割と責任分担が総括され、続く章で、プロダクトマーケティング（第２章）、プロジェクトマネジメント（第３章）、ユーザーエクスペリエンスデザイナー（第４章）について、プロダクトマネジメントとの役割の比較、関係などが語られました。
本５章は、こうした役割分担シリーズの最終章です。ここでは、「製品を定義する」役割のプロダクトマネージャーと「定義された製品を作りあげる」役割のエンジニアの協力関係の大切さが語られています。
どうぞお楽しみください。
なお、次の第６章以降の人材編後半は、こうした役割分担の中で、プロダクトマネージャーに相応しい人材の資質やスキルに始まって、プロダクトマネージャーの組織内での仕事の仕方などについて話は進んでいきます。
＝＝＝＝＝＝＝＝＝＝
第5章 プロダクトマネジメント vs. エンジニアリング
正しい製品を作るのか、それとも、製品を正しく作るのか
すばらしい製品を作り出す条件が、顧客のニーズを正しく掴んだ上で、そのニーズに対して今まさに実現可能な解決策 (ソリューション) を提供することだとすれば、プロダクトマネージャーとエンジニアリングチームの関係が重大な意味を持つことは、たやすく理解できるはずだ。
ソリューションを決めるのはプロダクトマネージャーだが、実際に何ができるかをいちばんよく知っているのはエンジニアリングチームであって、最終的には、エンジニアがソリューションを提供しなければならない。プロダクトマネージャーとしては、エンジニアリングチームとの関係が良好ならば、いい仕事ができることは、すぐにわかるだろう。この関係が悪ければ、延々と不満だらけの日々を過ごすことになる、とだけ言っておく。
いい関係でいるために大事なことを 1つ挙げると、それぞれが対等な仲間であって、どちらかが相手に従属するような関係ではない、と心得ることである。プロダクトマネージャーは、正しい製品を明確に定義し、エンジニアリングチームは、製品を正しく作り上げる。どちらも不可欠である。プロダクトマネージャーは、エンジニアが質の高い製品を作るために必要だと思っていることを自由にやらせるようにしなければいけないし、エンジニアは、プロダクトマネージャーが使い勝手のいい、価値の高い製品を自由に思い描けるように配慮しなければいけない。
どちらも、相手にとっての大きな支えになれる。特に、みんなが買ってくれる製品を見つけ出すために、プロダクトマネージャーにとって、エンジニアは大いに頼りになる。エンジニアという人種は、何が可能であるかをだれよりもよく知っているものだ、ということを忘れないでほしい。
そこで、プロダクトマネージャーがより優れた製品の着想を得るためにエンジニアの助けを借りる方法として、3つほど挙げてみよう。
1. エンジニアをユーザーや客先の前に連れ出すこと。ユーザーが苦労する様子を直接に見ることで多くのことを学べるだけでなく、問題点とその深刻さをもっとよく理解できるようになる。これをヒントにして、もっと優れたアイデアや解決策を思いつくことも多い。この方法は、エンジニアをプロトタイプの検証に連れてくることで、すぐに実行に移せるはずだ。
2. 技術が発展することで何ができるようになったかを探るために、エンジニアの助けを求めること。今使える技術やいずれ使えるようになりそうな技術としてどういうものがあるか、それらが目先の問題の解決にどう役立つか、ブレインストーミングをやる。
3. エンジニアみんな (それが無理なら、主任エンジニアだけでも) あるいはアーキテクトを、製品開発の初めの段階から関与させて、早い段階でそれぞれのアイデアについて必要な費用を見積もっておき、より望ましいソリューションを決めるのに役立てること。プロダクトマネージャーがよく起こす間違いとして、すばらしい製品の定義を思いついて、それをエンジニアリングチームに丸投げしてしまう、というのがある。そのせいで、何をしたいかと何ができるのかをすり合わせるという非常に重要な作業に取りかかるのが遅れて、いろいろな情報をしっかり検討する時間もないまま意思決定をしなければならない状況に陥ってから、慌ててすり合わせをする羽目になる。
同じように、プロダクトマネージャーもまた、エンジニアにとって大いに頼りになる存在である。ここで、エンジニアにいい仕事をしてもらうための方法を 3つ挙げてみる。
1. 製品を必要最小限までそぎ落とすことに集中すること。後でもっと詳しく説明するが、ともかく、プロダクトマネージャーの仕事は、究極の製品を定義することではなく、目的を達成するために必要最小限までそぎ落とされた製品を定義することである。この方法を実行するだけでも、プロダクトマネジメントとエンジニアリングの間の意思疎通と相互作用を根本から改善することができる。
2. いったんエンジニアリングチームが開発を始めてしまったら、極力、それをかき回さないようにすること。かき回す (churn) とは、要件や製品定義を変更することである。かき回さざるを得ないこともあるだろうし、プロダクトマネージャーにもどうにもできないことがあるということぐらい、エンジニアだってわかっている。でも、プロダクトマネージャーの方も、製品開発というのは、自分が思いついた最新のアイデアや最高のアイデアを試す場ではないことを忘れてはならない。
3. 想定していなかった使い方や十分に検討をしていなかった使い方など、実装時には必ず問題が出てくるだろう。これは、最高の製品開発チームですら、当たり前のように起こることだ。だが、実装段階でのプロダクトマネージャーの使命は、問題に立ち向かい、できるだけ素早く答えを出すことであって、その間もずっと、製品を必要最小限までそぎ落とす努力を怠らずに、できるだけ開発業務をかき回さないようにしなければならない。
こうしたことを頭に入れた上で、私はいつも、優秀なエンジニアに対しては、ぜひプロダクトマネジメントに挑戦すべきだと勧めている。そして、どんなに君たちのエンジニアリングがすばらしくても、作る価値のある製品でなければ君たちは力を発揮しようがないんだよ、と言い聞かせている。何を作れるかを知っているだけではなく、何を作るかというもっと大きな問題にも取り組んできたエンジニアの貢献があってこそ、すばらしい製品や企業がたくさん生まれたのだ、ということも指摘しておきたい。エンジニアがプロダクトマネジメントを知ることは、本人にとってキャリアアップのための格好の機会となるだけでなく、製品にとっても (さらには、会社や顧客にとっても) すばらしいことであるはずだ。
コラム１
遠隔地の開発者とうまくやっていくにはどうすればいいか？
最近よくあるのは、プロダクトマネージャーとエンジニアリングチームが別々の場所で働いているという状況だ。これは、何も、インドのエンジニアに外注するような話だけではない。開発チームが別の場所にいるのは、M&A のせいで起こることもあるし、大きい会社であれば、開発者はそもそもプロダクトマネージャーと同じオフィスにいなかったりする。
ただでさえコミュニケーションや作業の難しさはいろいろあるのに、開発者がプロダクトマネージャーの隣にいない場合はそれがもっとひどくなって、時には、離れ離れで開発作業を進めることに対するイライラが極限にまで達するチームが続出することになる。さらに、チームメンバーの中には、コストの節約というそもそもの目的までを公然と批判する人も出てきたりする。
離れたところにいる開発チームといっしょに仕事をすることになった場合には、開発をうまくやり遂げる確率を劇的に上げるためにプロダクトマネージャーができることとして、次の 3つがカギとなる。
1. 開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかっていない (あるいは、コロコロ考えを変える) ために、離れたところで作業しているチームがもがき苦しむことだ。これは、下手くそな騎手の鞭の先っぽにいるようなもので、失敗のもと以外の何物でもない。
第18章「製品仕様はどうあるべきかを考える」で、製品の仕様のベースとして、プロトタイプ (製品の正式版が正確にイメージできる試作品) が重要であることを説明している。なぜ重要かをここですべて繰り返すつもりはない。開発チームが離れている場合は、実際の仕様についてやりとりするにしろ、仕様の変更についてやりとりするにしろ、主なコミュケーションの手段として絶対にプロトタイプを使いたくなるはずだ、とだけ言っておけば、ここでは十分だろう。書き物になっていると、読むのが大変だ。ましてや、それが外国語だったり、それを書いた人が自分のオフィスの近くにいなくてすぐに質問できない状態だったりしたら、書き物だけでどうにかしようというのは、自分からトラブルを望んでいるとしか思えない。
2. 開発チームのみんなが近くにいる場合には、複数の人が原因となる衝突 (たとえば、2人のマネージャーが別々の指示を出す場合) は、普通にしていても目に入るので、すぐ解決できる。開発チームが遠くにいる場合には、頭にくるようなことが寝耳に水で山ほど起こるかもしれない、と覚悟しなければならない。そして、食い違いに気づくまでに、文字通り何ヶ月もかかるだってあるだろう。こういうことになるのは、だいたいは、離れたところにいる開発者たちが、だれが何をどうしろと言っているのか、さまざまな指示をどう解釈すればいいのかなどを、推測しなければならない羽目になるからだ。当然、こういう推測がいつも当たっているとは限らない。本拠地にいるだれかに、遠くにいるチームとのすべての調整を任せることが、どうしても必要になる。すべてのやりとりはこの人を通さなければならないということではないが、エンジニアリングチームが説明や報告をしなければならない相手はだれであるかがあやふやではダメだ、ということである。この調整をやるのは、場合によって、プロジェクトマネージャーだったり、エンジニアリングチームの上の方の人でプロダクトマネージャーの近くにいる人だったりするだろう。
3. 今は、多くの会社で、社内で使える優れたコミュニケーションの仕組みをいろいろと整えている。電子メールやインスタントメッセージのほかに、テレビ会議の技術もものすごくよくなっているし、VoIP のおかげで国際通話料もずいぶん安くなった。そうは言っても、やはり、直接顔を合わせて話せる態勢にできるなら、それに代わるものはない。プロダクトマネージャーは、少なくとも 3ヶ月に一度は、エンジニアリングチームのところに出向いて、彼らとしっかり顔合わせをして、中心となっているアーキテクトやマネージャーと打合せをするべきだ。実際に訪問して直接顔を合わせることで、離れ離れのメンバーとの関係やコミュニケーションはずっとよくなるだろう。コミュニケーションを向上させる他の方法としては、人材交流制度を作って、主な開発者をプロダクトマネージャーのもとに一定の期間派遣する、という手もある。
離れたところに有能な開発チームがいて、そのチームとの間で、私が説明したような関わり方ができるようになると、遠くのチームと仕事するという仕組みをうまく活用できるようになるだろう。特に、インドなどにエンジニアがいるなら、時差を味方につけることもできる。アメリカにいるプロダクトマネージャーが毎朝オフィスに行くと、それまでにインドでやった作業がどこまで進んだかがわかる。そして、日中は (インド側は夜)、作業結果をレビューしたり、検証したり、フィードバックを送り返して過ごす。こうして、すこぶる速いサイクルで作業は進んでいく。
プロトタイプを遠隔地のエンジニアに作らせることもできるが、作業サイクルがかなり速いので (一日何度もやりとりすることになる)、コミュニケーションはもう少ししんどいものになるだろうし、自分の働く時間帯も柔軟にずらす必要も出てくるだろう。
開発チームと離れて仕事をする場合の問題に対処するもう 1つのやり方としては、製品開発チームを丸ごと遠隔地の拠点に置いてしまうというのがある。こういう傾向はつい最近出てきたばかりだが、この動きは強まると思っている。そうは言っても、このやり方については、まだそれほど気にすることもない。遠隔地でエンジニアリングや品質保証を進められるようになるまで、10年はかかっているのである。遠隔地に有能なプロダクトマネージャーやデザイナーまで置けるようにまでには、おそらくあと 10年はかかるだろう。
コラム２
アウトソーシングという手もある
近頃では、私が関わっている会社の大部分で、多かれ少なかれ何らかの業務を外注しているが、その結果は実にまちまちである。外注で問題を抱えてしまう場合、その原因はいくつかある。製品開発のプロセスに問題がある場合や、言語や文化の問題もあるが、いちばんの原因は、外注の動機が間違っていることにあると思う。
みんなをワクワクさせる製品を作ろうとするなら、専門性の高い職種については、コスト削減のためのアウトソーシングはやるべきではない。その製品開発にふさわしい人を集めるためだったらいい。多くの場合、最高のメンバーを集めるには、近場だけではなく、地理的な制約を外して人を探す必要が出てくるだろう。要するに、他の州や外国で働いている人をメンバーにするということだ。
悲しいことに、シリコンバレーでは、今や生活費がかかり過ぎて、採用したい人がいても彼らが生活するのに十分な給料を支払えない。よそから通うにしても、限度がある。結局、いい人材はここではもはや見つからないので、いいチームを作るためには他の場所から探すことになる。
幸いなことに、インド、東欧 (特にチェコ、ハンガリー、ポーランド、スロバキア)、北欧 (特に、オランダ、スウェーデン、ドイツ)、イスラエル、中国、シンガポール、オーストラリア、ニュージーランドといったところは、ソフトウェアの製品開発でずば抜けた能力を持つ人たちをたくさん輩出している。私自身も、ここで挙げた国の全部に優秀な知り合いがいる。私が今まで率いていっしょに仕事をする機会に恵まれた最高のチームの 1つでは、スウェーデン、シリコンバレー、ボストン、インドにメンバーが散らばっていた。そのときは、2000万人以上のユーザーをサポートするインフラを構築したのだが、彼ら 1人1人の才能がなかったら、成功はおぼつかなかっただろう。
MySQLは私が気に入っている会社の一つだが、国や地域の枠を超えて人材を登用するという哲学を長年にわたって実践している。本拠地はシリコンバレーとスウェーデンにあるが、製品開発のチームや経営幹部ですら世界中に散らばっている。彼らは、まさにネットワークでつながっている組織であり、データベースソフトウェアやシステムソフトウェアについての最高の頭脳をどこからでも引っ張り出せるという恩恵を受けている。彼らだって、メンバーが完全に分散してしまっているチームを管理するのは大変だろうが、もし彼らが世界中のどこか一箇所だけに決めて、典型的な拠点集中型の会社を目指していたとしたら、彼らが今までに成し遂げてきたことは不可能であったに違いない。
1980年代に製造業の仕事がシリコンバレーから流出したが、今、これと同じようなことが他の職種でも起こっている。特に顧客サービスや品質保証で目につくが、エンジニアでもちょっと見られる。最近は、プロダクトマネジメントとデザインの機能の他に、アーキテクトと品質保証マネージャーを本社に置き、製品開発チームのその他の機能については、どこかに丸ごと外注するか、世界中に分散してアウトソーシングするのが当たり前になってきている。
大切なのは、チームそのものとその構成メンバーの力量がすべてだ、と認識することだ。多くのマネージャーはこれをよく理解していないようで、同じ職種でも、作業効率には人によって 20倍以上も差があることを知って、愕然としている。実績で選ばれたものすごく優秀な人を 5人集めたチームと、地理的な条件だけが理由で採用された 15人のチームとでは、どっちがいいだろうか。作業効率と比べれば、コストの節約で感じられるメリットなど大きな問題ではない。生活費の高いストックホルムに住む最高レベルのエンジニアに外注しても、結果を考えればお買い得ということもあるのだ。
ソフトウェア製品の開発を左右する要素はまだ他にもあるけれど、すべては、いいチームを作ることから始まると確信している。もしみなさんのチームでアウトソーシングをやろうとするなら、正しい動機でそうしてほしい。できる人を集めてチームに招き入れたいから、というなら結構だ。でも、ほんのちょっとのコストを節約できると思ったから、というだけではダメなのだ。
コラム３
エンジニアリングチームがコードを書き直したいだって！？
「もう新しい機能は作らない！ いったん中止して、コードを書き直すぞ！ 今のコードは滅茶苦茶だし、ユーザーが増えたら耐えられない。脆すぎる。これじゃメンテなんてできないし、動かし続けるのだって無理だ！」 エンジニアリングチームのこんな言葉ほど、プロダクトマネージャーを震撼させるものはない。
こういうことは、これまで多くの会社で起こってきたし、今もだって起きている。eBay では 1999 年にこういう事態が起きて、会社は、実は世の中の人々が思っていた以上にヤバいことになっていた。Friendster では何年か前にこういうことが起こり、MySpace にソーシャルネットワーキングでの優位を奪われてしまった。Netscape では、マイクロソフトとブラウザーの覇権争いをしているときに起こり、結果はみなさんご存じのとおりである。ほとんどの会社は、こういうことが起きると、再起不能になってしまうのが現実である。
会社は、こういう事態に陥ると、だいたいはエンジニアリングチームを悪者にする。でも、私の経験では、あまり言いたくはないが、悪いのはプロダクトマネジメントであることが多い。というのは、こういうことが起きてしまう原因でよ目につくのは、プロダクトマネージャーが、作れそうな機能なら何でもめいっぱいくっつける、というようなことを何年にもわたってエンジニアリングチームにやらせてきたために、彼らをボロボロにしてしまうことだ。結果はといえば、インフラを考えないで酷使すれ、いずれ、ソフトウェアがもはや機能しなくなるときが必ずやって来る。
こうやってコードを書き直している間に、プロダクトマネージャーは、エンジニアたちが顧客の期待するものに向かって突き進むのに待ったをかけざるを得なくなる。みなさんは、コードの書き直しは 2～3ヶ月 (あるいはそれ以下) で済むと思っているかもしれないが、まず間違いなくもっとかかる。そして、顧客がライバル製品の方に行ってしまうのをなすすべもなく見送る羽目になるだろう。そうこうする間に、ライバルは、せっせと製品の改善を続けていたのだから。
まだこんな状況になっていないなら、これからも絶対そうならないように、次のことを試してほしい。エンジニアリングで何かのキャパシティを設定するときは、そのうち一定の割合を予備として空けておくのだ。eBay ではこれをヘッドルーム (頭上の空間) と呼んでいた。急速に成長しているときに出くわすさまざまな問題は、規模やサイズが関係していることが多いので、ヘッドルームとは、天井に頭がぶつかるのを防ごうという考え方である。ユーザーの数やトランザクションの数が増えたり、機能が拡張されたりことを見込んで、予備をとっておくのだ。要は、製品のインフラを会社のニーズに合わせられるようにしておくということだ。
エンジニアリングチームとは、次のような感じで取り決めをしておこう。プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の20% を空けておぃて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でも、この枠を使って手を打っておくのだ。
もしプロジェクトが今まさにひどい状態であるならば、この予備を 30% あるいはそれ以上にしなければならないかもしれない。20% も要らないよ、などと思っているようなチームには、逆に不安を覚える。
現時点で、すでに作業を中断してコードを書き直す状況に陥っている会社は、もしかしたら生き残れないかもしれない。でも、この危機を乗り切るチャンスが与えられるなら、以下のことをやってみてほしい。
ステップ1
エンジニアリングチームが必要だと判断した変更をやるための、現実的な作業スケジュールを組むこと。ほとんどの標準的な開発ブロジェクトでは、経験を積んだエンジニアリングチームであれば、かなり正確な見通しを立てるだろう。コードを書き直す場合を除けば。コードの書き直しのためのスケジュールは、甘い見通しになりがちだが、というのも、実際にコードを書き直した経験のあるチームは滅多にないからだ。この状況では、プロダクトマネージャーは、正しい情報に基づいて判断をしなければならない。だから、現実的な日程に設定されるようにするには、スケジュール上の作業項目の 1つ1つをきっちり検討しなければならないだろう。
ステップ2
コードの書き直しの作業を細かく分けて、少しずつでも製品開発が続けられていることをユーザーにわかってもらえるような形で進める方法があるならば、あらゆる手を尽くしてでも絶対にそうするべきだ。たとえ、コードの書き直しが完全に終わるまでに、9ヶ月ではなく 2年かかることになったとしても、である。ユーザーにわかるように機能を拡張していくことができるならば、それが製品の本来のキャパシティの 25～50% にすぎないとしても、製品が何らかの格好で市場に出ているということがとにかく大事なのである。インターネットのような動きの速い分野では、特にそうだ。
ステップ3
ユーザーに見える機能を提供するための能力が限られている状態なので、適切な機能を残すように注意しよう。機能の定義もきちんとやる必要がある。
eBay は瀕死の状態を経験してからは、二度と危機的な状況に陥ることがないような体制をしっかり整えた。問題が深刻になる前に、さっさとコードの書き直しを始めるようにしたのだ。実際のところ、eBay は、サービスが急成長する中で 3回もコードを書き直して、3回目のときはサイト全体を別のプログラミング言語とアーキテクチャに置き換えた。彼らは、この何百万行もの膨大な量のコードを数年かけて書き直し、同時に、記録的な数の新しい機能も追加した。そして、何よりも、ユーザーに不自由な思いをさせることなく、こうした作業をやってのけたのだ。これは、上空を飛行中にエンジンを修理したという、私が知っている中でもいちばん驚異的な事例である。
こうした事態に対処するのにいちばんいい方法は、そうなる前に手を打つことである。するべき負担はして、ちゃんと20% のヘッドルームを取っておくのを忘れないことだ。まだエンジニアリングチームとこの話をしていないのなら、今日すぐにやろう。
Inspired日本語版 