Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節
エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。
というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング(実装)」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。
エンジニアは製品を正しく作る
エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。
エンジニアとしてこの動きは自然だと思うし、正しく作られていない製品をリリースすることは結果的にユーザー体験を損なうので、職業上必要な振る舞いでもある(そして製品を「正しく」作るのはとても難しい)。
この場合に「正しい製品」の方を引き受けて開発チームを引っ張るのがプロダクトマネージャの仕事で、「正しく作る」方のエンジニアとバランスを取ることが必要、というのが本書(特に5章)の趣旨である*1。
コードを書きながら「正しい製品」を作るには
しかしここで自分が気になるのは、プロダクトマネージャーがエンジニアも兼ねていて、実装もしている場合はどうするのかということだ。というのは今の自分がそういう立場だからなのだけど、所謂プレイングマネージャがこのバランスをどう取るのかということに関心がある。
突然自分語りになるけれど、自分が意識しているのは以下のことである(意識しているだけで、できていると言うつもりはないです…)。
- コードを書き始めるとバイアスがかかることを認識する
- コードを書く前の時間を大切にする
- 客観的な意見を求める
コードを書き始めるとバイアスがかかることを認識する
私がエンジニアとして働き始めたころに学んだ教訓は、客観的な判断は、コードの1行目を書くまでしかできないということだった。その後のすべての決断は感情的になる。
Hard Things 「第3章 直感を信じる」より
自分もコードを書き始めると思考がどんどん保守的な方に向くという経験を何度もしたので、このバイアスをできるだけ把握したいと常々思っている。実装期間には気分転換に散歩に行ったり、ランニングをしたりして冷静に振り返る時間を設けたりしているけど、うまく行っているかはよくわからない。
コードを書く前の時間を大切にする
そういった経緯から、実装に入る前の調査、ブレスト、ユーザーインタビュー、ペーパープロトタイピングといった段階を重視するようになった(要するにデザイン思考的なメソッドを勉強した)。自分は例えプロトタイプでもコードを書いてしまうとバイアスが入ってしまう方なので、コードを書かない助走期間というのをできるだけ確保するようにしている*2。
客観的な意見を求める
自分からお願いして、事業責任者と毎週の1 on 1ミーティングを設定して、そこで意見を求めるようにしている。特に自分が今取り組んでいることをペンディングして別のことやるという判断をするときは、大抵1 on 1がきっかけになっている。要するに自分のマネジメントを手伝ってもらっているのだけど、実装に入っている段階ではこの時間が大変ありがたい。
おわりに
自分はエンジニアが「正しい製品」を作ることは可能だと信じているけれど、実装者が両立させるのが難しい仕事であるのは事実だと思う。
プレイングマネージャーに固執しているわけではないけれど、正しい製品を作りたいし、コードを書くのも楽しいし、両方うまいことやりたいという、シンプルな(そしてたぶん欲張りな)欲求を持っている。
追記
ここまで書いてきて何だけど、もちろん実装を通して着想が得られることはよくあると思う。しかしそのときにそれが「正しい製品」のためのものなのかを判断できるのか。今まで書いたコードを捨てる決断を自分でできるのか。そう考え出すと、やはり一度実装を始めると自分でフェーズを巻き戻すのは難しいように思う。
追記2
この文章を社内で見てもらったところ、エンジニアの先輩から同じようなことを感じてきたという意見を頂いた。先輩はプロダクトマネジメントと実装を両方やるときは、日や週を分けて対応するようにしているとのこと。
そうした意見から、このバイアスとの戦いはエンジニアがプロダクトマネージャーになるための成長痛なのかもしれないと思うようになった。バイアスとうまく付き合う方法を見つけた人が、コードを書くプロダクトマネージャーとして残っていくのだろうか。