株式会社Photosynthの@koichi222です。
Akerunというスマートロックのサービスを提供しています。
自分自身の主なロールとしては、Webサービス側のプロダクトマネジメントですが、
ハードウェアとソフトウェアを組み合わせたサービスを生み出す中で、プロダクトマネージャの役割についての学びを書かせていただければと思います。
体験を中心に設計する
Iot製品開発で最も重要なのは、ソフトウェアとハードウェアが組み合わさった時のユーザ体験です。
そして１番のリスクは、この体験の検証が製品開発の１番最後のタイミングで行われることです。仕様書のスペックと、実際の体験は、感じ方に大きなギャップがあります。そのギャップを埋めるためおすすめしたいのは、プロジェクトの初期に体験の検証のためのプロトタイプを作ることです。
体験の検証のためのプロトタイプとは、量産性、コードのメンテナンス性などは無視した、最終的な体験を擬似的に再現することのみを目的としたプロトタイプです。(リーンスタートアップで言う、MVPというと理解しやすいかと思います。)
ハードウェアに関しても、近年プロトタイピングのツールがかなり充実してきたのもあり、プロトタイピングしやすくなっているかと思います。Akerunでも、初期は3DプリンタやBLE Serialを用いたプロトタイプで検証していました。
ハードウェアとソフトウェアの適切な役割分担を考える
Akerunのスマートロックの開閉体験を構成する製品群として、以下があります。
- Akerun本体
- Akerun Remote(3GSIMを搭載したIoTゲートウェイ)
- Akerun スマホアプリ
- Akerun API (サーバサイド)
１つ体験を構成するのにもこれだけの製品群が出てきます。それぞれのレイヤーにどの役割をもたせるか？という設計は、製品づくりの思想が反映される部分で、IoTサービスの設計の醍醐味の１つかと思います。基本的には、変更のかけやすいソフトウェア側(とくにサーバサイド)に役割を寄せる設計が好ましいと考えています。
誰よりも顧客理解をする
iotの製品開発というのは必要な分野が広く、関係者が多くなりがちです。
ex) webエンジニア、モバイルアプリエンジニア(ios、android)、ファームウェアエンジニア、エレキエンジニア、メカエンジニア...
荒っぽい言い方になってしまいますが、専門分野もバックグランドも大きく違うチームを束ねるための共通言語は、顧客のとっての価値しかないです。「なぜそれが必要か」という理由を、顧客価値に遡ってどれだけ説得力をもって語れるかが、チームの推進力に大きく影響します。
根拠なき意思決定を先送りにする
スタートアップの製品開発というのは、得てしてスケジュールへの強いプレッシャーを受けながら製品開発をすることになります。
その際にありがちなのが「十分な検討をしたいが逆算すると検討の時間がないので、えいや、で決めてしまおう。」という仕様や設計の決め打ちです。「実装案を早い段階で１つに決め打ちして開発したほうが、複数の代替案を検討するより早い 」というのは直感的ではあるのですが、こういった精度の低い意思決定が、後に手戻りを生む原因となるということがリーン製品開発の中でも触れられています。(興味ある方はセットベース開発でググッてください。)
ソフトウェアに比べてハードウェアの情報はオープンになっていることが少ないので、ググるだけではなく自分での実験、検証をしないと行けないケースが多く、不十分な情報の中で意思決定を迫られるケースがより顕著に現れます。
トヨタのプロダクトマネージャに相当するチーフエンジニアの言葉(※1)で、
「私の仕事は部下が早過ぎる時期に、根拠の十分でない意思決定することを防ぐこと」というのがあるのですが、このような希望的観測を撲滅し、十分な根拠が揃うまで意思決定を先送りにするのは、PMの大きな役割の一つつかと思います。
よい質問をする
↑の「根拠なき意思決定を先送りにする」とも関わるのですが、エンジニアの適切な意思決定をサポートするために、PMはエンジニアに良い質問をすることが大切です。
具体的には、以下のような質問です。
・なぜこのように動作しているか？
・この問題の原因は何か？
・他にどのような代替案を考えたか？なぜこのような案を採用したか？
・このアイディアに関して誰と相談したか？
・次に何をしようと考えているか？
・それ以外になにをしようと思っているか？
「最もよい解決策を思いつくのはエンジニアである」という考え方はとても大切だと思うのですが、任せっきりすることが責任を果たすことでも無いと考えています。特にチームが小さい時だと、各分野が１人で開発するということもザラなので、完全にその人任せになってしまいます。
個人的にも、上に上げたような簡単な問いかけとディスカッションをすることで、エンジニアの頭の中が整理され議論が前に進んだり、新しいアイディアが出てきたことを何度も経験しています。一歩引いた立場でみると、「そんなことで悩んでるの？」と思うこともよくあります。特にチームが小さいうちは、PMがなるべく具体的なディスカッションにも参加すべきだと考えています。
（ただし、この役割は必ずしもPMが担わなくてもよいとは思います。もう少し大きな組織、チーム内での相互レビューの仕組みなどで担保できるでしょう。）
リリース品質の判断をする
特にハードウェアに置いて、製品をリリースするという判断は非常に大きな判断です。
当たり前ですが、一度世に出すと、変更することができないからです。
開発も終盤になってくると、殆どの人はリリースしたくてしょうがなくなります。
その重圧の中でNoという責任は、プロダクトマネージャーにあります。
「これが顧客の期待に答えているのか？」という点のみに集中して、シビアに判断することが求められます。また、製品が基準を満たしていないと判断した時に、エンジニアに対して、まっとうなフィードバックをする、というのは、エンジニアから信頼を得る上で大切なことだと考えています。
開発プロセスの改善を主導する
身も蓋も無いことを言ってしまいますが、どこだけ事前に学んだところで、はじめから100%のプロダクトマネジメントをするのは不可能です。最初のうちは、高速で黒歴史を積み重ねていくことになると思います。
大切なのは、失敗からきちんと学ぶことで、失敗をチームで分析して、学びにするプロセスを回すことを推進することが重要です。
自分の好きな言葉で「人間は経験からは学べず、経験を分析することで初めて学びとなる」という言葉がありますが、本当にその通りで、PMが振り返り→問題の深掘り→解決策の実行のプロセスを回すことに責任をもち、常に改善し続けている状態を作ることがチームを前に進めると思います。
最後に
以上ほんの一部ではありますが、Akerunの製品開発の中でのプロダクトマネジメントについての学びを書かせていただきました。皆様の参考になれば幸いです。
Photosynthでは、IoT市場で先進的なプロダクト生み出していきたい方を募集しています。特にwebエンジニアの方は 絶賛募集中ですので、興味のある方は一度オフィスに遊びにきてください！
参考文献
- ※ 1リーン製品開発方式