大会通じてのプロダクトマネジメント
こんにちは。ふんどです。
久々にブログを書くので、書き方を忘れてしまったんですが、今回は最近やったLTの内容をまるっとコピペするので特に問題ありません。
なお、この記事はICTアドベントカレンダー2022の1日目の記事です。普通に遅刻なんですが、委員長に拉致られてたのが原因なので仕方ないです。
目次
0. はじめに
この記事で話す内容は基本的に「ミニマムかつ利益を追わないプログラム開発」を通じての経験則になります。
もっと大きな規模で実践する際には、体系的にまとめた本などに目を通すのがおすすめです。
1. プロダクトづくりのゴール
結論から言ってしまうと、プロダクトづくりのゴールは「プロダクトを通じてユーザーが得る価値を最大化すること」だと思っています。
あくまでもプロダクト自体は目的を達成するための手段でしかありません。
ただ逆に言えば、実際にユーザーにとっての価値を生み出しているのはプロダクトであり、我々が直接ユーザーに価値を提供することはできません。
そのため、プロダクト作りをしているといつの間にか「プロダクトを完成させること」が目的になっていたりしますが、基本的にはどのフェーズであってもユーザーの価値を基準とすることに変わりはないと思っています。
2. マネジメントの役割
ではユーザーの価値を最大化するうえでマネジメントが担う役割はどのようなものがあるでしょうか。
私は大きく分けて以下の2つの役割を担っていると思っています。
- 届ける価値とその届け方を決める
- 開発の遅延を防ぐ
それぞれについて少し詳しく話します。
2-1. 届ける価値とその届け方を決める
これはほとんどの場合で「どんな課題をどう解決するか」と言い換えて問題なく、大会などのゼロからプロダクトを作るときでいうアイデア出しにあたります。
機能決めなどもここにあたるでしょう。
ただ、大会などのアイデア出しと違うのは、プロダクトをリリースした後も、置かれている状況に置かれて再考する必要があることです。
状況が変われば必要とされるプロダクトも変わるため、リリース後もどんな価値を提供するかは考えつづける必要があります。
なお、マネジメントは”決定”することが役割であり、価値についてはチーム全体で考えるべき事柄であることも念頭に置いておくべきでしょう。
2-2. 開発の遅延を防ぐ
これについては割と書いてある通りです。
2-1で決めた届ける価値とその届け方を実現するために、開発が遅延しないように進捗管理などを行います。
詳しくは次の章でお話します。
3. 役割を果たすためにやるべきこと
この章では前の章で述べたマネジメントの役割を果たすためにやるべきことについて、それぞれの役割ごとに述べていきます。
3-1. 届ける価値を決める
プロダクトを作り始める際(アイデア出し)は、以下の条件に沿って決めると良いと思います。
- ユーザーの価値になること(より多くの人の課題が解決できる)
- まだ他者によって提供されていない価値であること(同じ解決策をやっている人or会社がいない)
- 手元のリソースで実現可能であること
これらを満たす価値の探し方については言及しませんが、マネージャーとしては1と3を強く意識する必要があるかと思います。
理由としては、2はきちんと調査すれば結論が出るのに対して、1や3は人によって意見が分かれることがあり、その認識の差がプロダクトの差となるからです。
ここは経験を積んでいくと、想定と結果の差が減っていくかと思うので、マネジメントをやりたい人はそういったことを意識しながらやってみると良いかと思います。
また上記は作り始めの話でしたが、前の章で話したようにプロダクトはリリース後も状況に応じて提供する価値を再考する必要があります。
その際には以下の2つを基準にして考えると良いと思います。
- ユーザーが価値を感じ続けているか
- ユーザーが感じている価値と提供しようとしている価値は同じか
1については、提供しているプロダクトが解決しているものが、まだ課題と感じられているかを見定めるための視点です。
リリース時に課題だと感じられていたことでも、時間の経過によって課題だと感じられなくなることがあるため、定期的なチェックが必要だと考えています。
2についてはプロダクトをリリースして利用してくれているユーザーは、本当に自分たちの意図したユーザーであるかを確認するための視点です。
プロダクトをリリースすると、課題感に関わらず機能を必要としているユーザーが利用してくれます。
そうすると、利用しているユーザーの課題感と、提供している側の課題感がずれる可能性が出てきます。
これは実際にリリースしてみて初めて見えることであるため、リリース後にチェックする必要があります。
3-2. 価値の届け方を決める
これは一言で言えばUI/UX設計です。
ここではあまり言及しませんが、マネージャーとしてはチーム全体から意見が出るようにできると良いかと思います。
具体的には意見を述べやすいような心理的安全性を確保したり、定期的にプロダクトへの課題感を募集するなどです。
3-3. 開発の遅延を防ぐ
開発の管理は以下の工程で行うと良いと思います。
- タスクの羅列
- 工数の試算
- 優先順位付け
- リソースの分配
- 進行度のチェック
このやり方では1~4までを実行した後に、5を定期的に実行します。
5を定期的に実行する中で、遅延などの問題が発生したときや、タスクの完了などの区切りの良いタイミングで2から再度実行します。
この時に4からではなく2から再度実行する理由としては、開発の進行度や空いているリソースによって工数や優先順位が変わることがあるからです。
おわりに
以上が私の経験則から見るプロダクトマネジメントです。
言語化できていない部分や、自分があまり納得のいっていない部分などもありますが、いま文章に起こせることは全て書いたつもりです。
読んでくれてありがとうございました。
私の記事は以上となります。
なお、アドカレの次の記事は12/4のぱるふぇさんの記事です。
はま寿司って100種類もメニューあるの？
先にyonaパイセンが記事を出してくれてのでそちらを貼ります
