- ECのAPI開発におけるPM
- Golangエンジニア
- コンサルティング営業
- Other occupations (1)
- Development
- Business
はじめに
はじめまして。GMO メイクショップの高橋です。プロダクトオーナーとして次世代ECの開発に携わっています。
わたしはカスタマーサポートとしてmakeshopに入社し、その後、開発チームとの橋渡し役をやりながら次世代管理画面のプロダクトオーナーとしてプロジェクトに参加をしています。
開発出身ではないため、システム開発のイロハなど勉強中の箇所も多く様々な場所でチームメンバーに支えてもらいながら日々を過ごしています。
エンジニア出身ではなくプロダクトオーナーになる方も多くいると思いますので、わたしの経験・大切にしていることを残していこうと思います。
プロダクトオーナーは決めるのが仕事
プロダクトオーナーとは?どのような仕事?
などは様々な記事が見つかると思うので、そのあたりは割愛して重要だと思う点を備忘録として残します。
わたしが担当しているプロジェクトは旧管理画面のリプレイスです。そのため、決めることも少ない、、わけではなく決めなくてはいけない動きはたくさんあります。正直、わからないことも多くどちらが正解、どちらも正解だと思うことが多々あります。
迷うことばかりでいろんな方に相談したいですが、相談相手も仕事があり、かつ、確認ばかりしていると決定が遅くなり、その分開発も遅くなります。それが積もれば全体のスピードにも影響していきます。
質問には早く答えられるよう、その場で出来る限り考えます。質問を投げかけてくれたメンバーに話をその場ですぐに聞くようにします。質問をした瞬間がその出来事に関心を持っている瞬間だからです。そこで、決められることはその場でなるべく決めて次に進みます。確認を後回しにすると、関心が質問したメンバーもわたしも記憶が曖昧になり、再確認に倍の時間を使ってしまいます。
出来ることはなるべくその場で考え、操作できるものは操作して想像を膨らまし素早い決断を意識します。
「あったらいいな」か「なくてはならない」か
物事を決める時はなるべくストーリーを考えます。
この操作・この動作はどのような場面で利用するか、利用用途を考えて以下の情報をまず洗い出します。
- よく利用されるか
- 利用しない人は混乱しないか
- 他にも類似している操作はないか
- 動きは統一されているか
- 「あったらいいな」か「なくてはならない」か
よく出会うのは「あったらいいな」と「なくてはならない」ことに出会います。「あったらいいな」な要望もたくさんいただきます。「あったらいいな」を作ったら使われないケースもよく見かけます。
きっと使ってくれるはず、あったらきっと便利に使ってくれると思う。という判断で作ってしまい、その後何のために利用されているかわからないものをたくさん見てきました。作ることより捨てることのほうが遥かに難しく、また、対応も難しくなるので「あったらいいな」は慎重に検討するようにします。
時には間違えます
いろいろ考えて、最適だと思って作くりましたが、その後にいろんな人の目を通して様々なご意見をいただきます。その中で「こういう使い方もあった」なども伺います。その流れでデザインや仕様を変更し追加開発したりもします。
でも、それはあたり前でいろんな人の意見をうかがい様々なフィードバックをもらってからの方が要求・要望が鮮明になります。ある程度のところは方針を決めて悩んでも先に進みフィードバック後に改修をおこなった方が結果いいものが、より要求に近いものを提供できます。
いろんな意見と情報を共有し早い決断で次に進める。時には間違えてもより良い形の次の1手を進めていく。その姿勢が大切だとわたしは思います。
早いカイゼンには実際に手を動かし開発する開発メンバーとのコミュニケーションが重要です。わたしはいつも協力し課題に挑戦してくれるチームメンバーを誇りに思うとと同時に「HRT」(「Humility(謙虚)」「Respect(尊敬)」「Trust(信頼)」を大切にしています。
終わりに
わたしが大切にしていることを残してみました。
プロダクトオーナーの仕事は自分だけでは仕事になりません。実際に開発を進めるチームメンバーの仕事があるからこそ成立するお仕事です。何よりもチームメンバーとのコミュニケーションと相互理解が大切だと思います。これからプロダクトオーナーとして仕事を始める方、すでに活躍されている人で参考になっていれば幸いです。
◆ 他のBlogはこちらから⇒ https://tech.makeshop.co.jp/ ◆
ご応募お待ちしています!