Product Manager について

まだ世にないサービスの開発はエンジニアドリブンなので、Singularity Society/ブートキャンプで求められる Product Manager (PM) についてのイメージをシェアします。

PMの仕事は資料作りをするのではない

• Singularity Society/ブートキャンプ内で立派な資料は不要です
• モックでも良いので、動いてユーザ体験をできるデモを完成させることが最も重要な仕事です
• アイデアだけには価値はありません。アイデアを実現することにこそ価値があります

PMの役割と仕事の進め方

ともかくプロジェクトを進める、スケジュールを守るのがPMの仕事です

• 期限内に、ユーザが使える最小限の機能を実装し終えます（実際に機能を実装するのはエンジニアですが、進捗をコントロールします）
  • そのためには前もって動く状態にし、ドックフード（開発チームやブートキャンプ参加者で実際にサービスを利用する）して、フィードバックを得て改良、期限内に少なくとも通常ケースではバグのない状態にします
  • これらを円滑に進めるためのスケジュールを立てます。
• プロジェクトを進めるには、エンジニアが最大限バリューを出せるようにします
• サービスのアイデア、UI案、ペルソナ、ユーザ体験など、サービスを実装する上で必要なアイデアを素早く考えます
  • 議論を引っ張ることでエンジニアの能力を最大限に活かします
• エンジニアが技術的に困難という部分は、別のアイデアで実現できるように考えます
• MVPに必要な機能を選別し、不要なものは作らないように導きます
  • スケジュール内で現実的に作れるものを調整する

エンジニアの生産性を上げる

• どうやったらエンジニアのモチベーションを上げられるかを考え実行します
• 良い仕事をしたエンジニアを褒める。心の底から喜びます
• デモを見せてもらい、自らもデモを走らせます
  • 「エンジニアの仕事を喜んで待っている人、素直に喜んでくれる人」になります
  • 世界でいちばん最初のユーザーになる。テスターに負けずに、バグを先に見つける人になります

実装フェーズになって重要なこと

• まず、やらないことを決める
• 残った中でやることを決めてプライオリティを決める
• 期限、機能、予算のトレードオフ。何が最重要か決めて、目的に沿ってトリアージする。
• サービス、プロダクトの解像度を上げる。解像度が低いと判断できない
• 開発のボトルネックを取り除く。人、予算、機能、その他。前に進めるための障害物を前もって回避することがとても重要
• 多くの人の意見は聞かない。そのサービスを心から使いたいと思う人の意見は重要ですが、多くの人は場当たり的な意見をいうだけです。プロトタイプやサービスが存在するにもかかわらず、それを使わない意見を言う人は害悪です。現状も使っていて、さらにお金を払ってでも使いたい！！という人の話が最も重要です。

情報伝達

• 情報はテキストや簡単な絵で、相互に意思疎通できる程度にします
• 立派な資料は不要です。資料を作る時間があれば考える時間に使います
• チームのメンバーに合わせて、Slackで進めるか、Zoomも活用するかを決めていきます
• 実装が始まると、エンジニアが足りないと思うリソースの確保や雑用全般を受け持ちます
  • チケット管理、QA（テスト）、デザインアセットの確保（簡単なグラフィックパーツやアイコンなど）
  • Slackの議論で出た仕様をdocumentとしてまとめます
  • QAの手順書を作成します
  • ユーザ向けや投資家向けの資料を作ります
  • ユーザ向けのFAQなどのドキュメント整理します
  • サービスの背景をdocument化してメディアに出します

チケット管理

カンバンを利用する

• カンバンview (ボード）を使い、一覧で状況がわかるようにします
• Idea, ToDo, In Progress, QA, Doneが最小構成です
• 状況に合わせて担当者を正しくアサインします

チケットの粒度

• 数日で実装できるくらいの粒度で起票します
  • 大きい、曖昧な粒度のチケットは、議論が不十分です
  • 大きなタスクは分解してチケット化します
• ひとつひとつのToDoが多すぎるとエンジニアの手が動かなくなるので、タスク管理に注意します

チケットの優先度

• カラムの上にあるチケットが優先度 “高” です
• チケット内のプルダウンからカラムを変更すると優先度と異なる位置になることがあるので定期的に確認します
  ※ ドラッグ & ドロップではこのような事象は起きないと思います

チケットの動かし方

• PMは、1日に1回は必ずチケットの状態を確認し、間違っている状態や進んでないものがないかを確かめます
• PMは、エンジニアがチケットをみれば実装に必要な情報がわかるようにします
  • Slack上で議論し、決まったことはチケットに記載します
  • チケット上で議論し、決まったことも含めてチケットに記載します
    チケットの親を更新するか、最新スレッドに全ての情報を記載するかのルールはチームごとに決めます
• チケットに記載され、実装したものは仕様やマニュアルのdocumentへ反映することも忘れずに行います

出典
https://github.com/SingularitySociety/societys_statement/blob/main/development/pm.md