こちら、pyspa Advent Calendar 2019の23日目の記事です。前日の記事は id:kutakutatriangle さんの34のおっさん(当時)が痔ろう手術するハメになって健康大切だと実感した思い出話(前編)でした。
お前誰？
Luminosoという会社でソリューションチームの一員として働いています。業務としては、製品のプロトタイプ開発のような作業が大半です。お客様の要望に応えるために、既存の自社製品だけでは満たせない拡張部分を作っていくのが主な業務になります。
そうした仕事を通して、プロダクトを作るということについて自分なりに考えたことを書いていきます。
できるだけ開発しない
既存の製品・機能でできることがあるのであれば、まずそちらを使うべきでしょう。開発は、既存のプロダクトではユーザのニーズに「応えられない」ことがわかった場合に初めて行うものであり、「応えられるかわからない」ときにやるべきではありません。できないことがわかるまで製品や既存のソリューションについて調べるべきでしょう。
ユーザの言葉を鵜呑みにしてはいけない
ユーザは技術的に何ができて何ができないかはわかりません。それどころか、自分たちが本当にしたいことは何かも把握できていないこともよくあります。「君のところが作ってる車で空を飛びたいんだ。空を飛ぶ機能つけてよ」と言われることを想像してみてください。厄介なのが、「空を飛べるようになるなら君のところの車を買うよ」と契約を盾にした要望で、この状態になると社内の営業チームはプロダクトの開発チームに無理を通してでもその機能をつけようとプッシュしてくるようになります。
この問題に対する有効な解決策は自分ではまだ見つかっていません。予防策としては、以下のようなものがあります。
ユーザのニーズを元にして開発をしなければならない
一方で、ユーザの話を全く聞かないというのも非常に危険です。開発者が思い込みだけで「こういうのが必要だろう」と思って作ったプロダクトや機能は、大抵の場合期待するほどユーザには受け入れられません。プロダクトの話になるとしばしば耳にする忠告なので、そんなこと本当にあるのかなと思っていましたが、現実にそうした事象を目にすると、とてもよくわかります。開発した動機だけを聞くと、それめっちゃクールだよね、確かにそういうの欲しいよね、と錯覚してしまいます。しかし、そうしたプロダクトを実際にユーザに見せても、お金を払ってでも欲しいと思わせられるかどうかは未知数です。
前職Clouderaでは、新製品のリリース時には必ずローンチカスタマーがついていました。これは、単にマーケティング的な効果をもたらすだけでなく、ユーザのニーズに基づいて開発することで、本当に必要とされるプロダクトに特化するということを体現していた証だったと思っています。
ユーザのニーズは(例え実現不可能であるように見えても)バックログにいれて管理しなければならない
「この車で空を飛びたい」のような、一見突拍子もないような意見であっても、そうした意見を眺めているうちに本当の問題や本当の解決策にいきあたる場合があります。特に、複数のユーザからそういう突拍子もない意見がでてきた場合は、その要望を再検討する機会はあってもいいと思います。
そのためには要望の管理が必要です。 GitHub Issues でも JIRA でも Trello でもいいので、とりあえず放り込んでおく、という先は用意しておいた方が後で便利です。
開発は常に保守性を考えなければならない
ソリューションチームにいると、複数のプロダクトを開発していくことは頻繁にありますし、数ヶ月特に保守する必要もなく安定して提供できていたプロダクトに急遽開発要件が生まれるということもあります。また、製品本体や外部ツールのバージョンアップによる非互換性への対応なども必要になります。こういうときに保守性を考慮した開発を行うことで、保守工数を削減するだけでなく、新規開発を素早く行うことができるようになります。
作成したソリューションやツールなどは、あくまで位置づけとしてはプロトタイプというだけであり、実際に製品化されるかどうかは決まっていません。場合によっては長期的に保守する必要があるため、保守性を高めておくことは重要です。
まとめ
ユーザの話を鵜呑みにせず、しかしきちんと話を聞き、その上で保守性を考慮して開発する、というのがこの一年でプロダクト開発について自分が学んだことでした。ごく当たり前のことしか書いておらず、知っている人にとっては目新しい話は何もありませんが、こうした知識を経験として体得できたというのが大きな収穫だったと感じています。
明日は @wozozo です。
