キッド✈️氏、はじめてのプロダクトオーナーを務め、学ぶ。

こんにちは、キッド✈️です。

これはGAOGAO Advent Calendar 2019の7日目の記事です。

ふと、プログラミングを初めてから、どれくらい経ったのかを振り返ってみたら、2年半弱でした。

スクール卒業して、エンジニアインターンを初めた時に書いた、このブログがもはや懐かしくなってきました。

onukichi.hatenadiary.jp

さて、そんなエンジニア3年目の僕ですが、今年11月より、とある会社の新規サービスのプロダクトオーナー（以下、PO）をさせていただくことになりました。

僕はPOとして、0からサービス開発に携わるのははじめての経験でした。

はじめてPOを務めて、学んだことがたくさんあったので、年末にまとめようと思います。

学び

(1)POが注力すべきなのは環境づくり

今回の新規サービス開発のチームメンバーは、僕含めて3人でした。その中では、僕が一番開発経験があったために、当初は「僕がほとんどのコードを書くぞ！」ぐらいの意気込みでしたが、実際はその逆でした。

最初こそ、僕もがっつりコードを書いていたのですが、途中から「これ僕ががっつり開発するより、他の2人が気持ちよく開発できる環境（色んな面の環境）作った方が、開発がうまく進むのでは？」と気づきました。

そこからは開発のメインは2人のエンジニアに託し、僕は主に以下のことをやっていました。

・先々の開発タスクの見積もりやスケジュール調整

・詰まってそうならフォローアップ

・プルリクエストのレビュー（途中まで全て自分一人で回してた）

・ビジネスチームとの連携

(2)当初の仕様からガラッと変わるのは仕方ない

今回は2ヶ月間で新規サービスを作る、というかなりタイトなスケジュールでした。そんな中でも開発していく中で、「やっぱりこの機能の仕様を変更したい」という要望が出てきてしまうのは仕方ないことです。なんせスタートアップなので。

なので、開発チームとして大切にしていたのは、「作り込みすぎないこと」でした。

機能ごとにがっつり作りこむのではなく、最初は薄く作って、徐々に確認しながら肉付けをしていき、濃くしていきました。

(3)毎日フォーマットで進捗共有する

今回は3人ともリモートで作業する、リモートチームでした（チームメンバーの1人とは、以前から友達でした）。

結論、リモートチームでも特段問題がなく開発を進めていくことができました。

ミーティングは主にzoomで、このようなスケジュールで行なっていました。

・毎日16時に15分ほどのプチ進捗共有ミーティング

・毎週金曜16時に40分ほどの定例ミーティング

ミーティングで話した議題は以下です。

・各々が、フォーマットに沿った方向をする

フォーマットはこちら

1. What I did (着手したこと)
2. What I will do (これから着手すること)
3. Blocking issues (何か困っているところ・課題があれば共有)

tejitakさんのこちらのnoteを参考にしています。

note.com

また僕が1年ほど、リモートチームの経験があったことも、今回リモートチームをうまく運営できたのかもしれません。

(4)結局はメンバーのオーナーシップ

はじめてのプロダクトオーナー経験でしたが、プロジェクトが上手くいくかどうかは、結局のところ人です。結論、それ。笑

僕が何かしたとかは微々たるものであって、今回はチームメンバーが最強すぎて、開発が回りました。本当に。感謝。ありがとう！cảm ơn！

僕以外の2人のエンジニアのおかげでなんとかプロジェクトがうまく進みました。

僕がいちいち指示しなくても、気を使って色々やってくれたり、自分たちで楽しんで作業回せたり、たくさん提案してくれたりと。

チームメンバーが、オーナーシップの化身でした。結局のところ、こんなタイトなスケジュールの中うまくいったのは、一緒に働いたエンジニア皆がオーナーシップを持っていたからだと思います。

失敗したこと

失敗も学びです。特に以下の3つは失敗だったなと思っています。

(1)もう少し機能を絞ればよかった

一番失敗したのは、これ。

それでも、開発を始める前は、めちゃくちゃ機能を絞ったつもりだったのですが、もっと絞れたなと反省しています。

例えばですが、Saasを作るとなった際に、最初から複数の顧客と契約する設計を目指すのではなく、最初はまずは1社が使えるレベルで作る的なイメージです。

最初から複数の顧客と契約する場合、やれ請求書機能や、決済機能やら必要になります。

でも、そのSaasのコアな機能（セールスポイント）って絶対そこじゃないですよね？

何が言いたいかと言いますと、まずはセールスポイントになる機能だけをサクッと作って、それを実際に顧客に試して意見をもらうべきだったなと。

1顧客だけなら請求書などはマニュアルでいいし、なんなら無料トライアルもできるわけで。結局、そのセールスポイントのニーズが確かじゃないうちは、サブ機能は作りたくないわけです。

POとして、そこに気づけなかったのは非常に反省しています。今後の開発に生かす！

(2)開発に着手する前に想定ユーザーの声を聞いておけばよかった

これも(1)の続きですが、作る前になんとなくのニーズは分かっていたものの、生の声は全く聞けていませんでした。少なくとも僕は。

開発が進んでから、ユーザーの声を聞いて、やっぱりこうしたほうがいいと言うように、開発する機能が変わったりが多かったです。反省！

(3)開発チーム以外にも、頻繁に進捗共有を行えばよかった

今回、開発メンバー3人でタイトなスケジュールで開発を行いました。ただそのサービスを営業したり、運営したりするのは僕ら3人だけではありません。会社全体として、そのサービスに懸けています。

最低週一は、会社全体に向けて進捗共有すべきだったと反省しています。

まとめ

はじめてのPO経験して、個人的な評価は60点です。

チームメンバーのおかげで、及第点は突破できたため、この点数にしています。今後も開発は続くので、失敗したことを意識して頑張っていこうと思います。

みなさま良いお年を！