プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける を読み終えました。
本書には、現代におけるプロダクトの作り方の正解のひとつが書かれています。実際、本書の内容を私の顧客と一緒に実践したところすぐに大きな成果がありました。不確定なプロダクトのゴールが機能を開発する前に明らかになりました。
私のように Ruby を使っている SIer や業務委託の開発者にこの本を読んでほしいと思いました。(あくまでも個人の感想です)。
Google広告
私は SIer として顧客が希望するプロダクト(ソフトウェア)を主に Ruby を使って作っています。
設計・開発・テスト・リリースなど様々な場面で、いろいろな違和感を感じることがありました。
それは次のようなものです。
- 誰がなんのために使うのかわからない機能を作っている
- 仕様に従って作っているがこのUIは使いにくい
- デザインを刷新するとのことだが以前よりも使いにくい
- Railsの標準的な機能では実現できない機能を要望されている
これまでの私は、顧客に対して、または開発リーダーに対して「なぜその機能が必要なのですか？」と質問するよりも、機能の開発・リリースを優先することが多かったように思います。
その理由の一つは SIer からすればプロダクトが成功するかどうかは報酬に直接影響しないからです。お客様が希望される機能を作って渡すことができれば報酬が得られるのです。
その結果、前述した違和感はお客様の問題だと、他人事のように考えてしまうことがありました。
でも、本書の内容を顧客と一緒に実践し、 なぜその機能が必要なのかを顧客と開発者の両方が同じレベルで理解した上で開発を進める と、
- 開発者自身でいくつかの判断ができること
- なによりモチベーションを維持できること
- その結果、不安が少なくなり、楽しんで開発することができること
がわかりました。私にとってこれらのことは大事なことです。
しかしながら、私の経験上、なぜその機能が必要なのかを開発者が深く理解していることが大事だということを顧客や開発リーダーは知りません。顧客や開発リーダーは適切な機能とその挙動を仕様書やIssueにまとめて、開発者に作業をお願いすれば適切な機能が出来上がると思っています。そのような開発経験が続けば、当然、開発者もそういうものだと思い込んでいるでしょう。でもそうじゃないんです。
だから、私のほうが行動して、顧客や開発リーダーにお願いして、なぜその機能が必要なのかを教えてもらう必要があるのです。
そこで本書の出番です。
本書には、顧客が希望する現代におけるプロダクトが成功するための事例や方法が書かれています。
それらを紹介するとともに、作っているプロダクトに適した方法を実践するのです。
特に Netflix の事例と プロダクトのカタ - iki-iki というやり方が気に入っています。
すると、自然に、なぜその機能が必要なのかを顧客や開発リーダーが私に説明するようになるし、私も説明を求めるようになります。なぜなら、プロダクトが成功するために必要なことだからです。
ということで、興味を持たれた方はぜひ本書を読んでみてください。Rubyを使っているすべての開発者におすすめの書籍です。
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける