体験、web3ハッカソン！〜ハッカソンで経験したプロダクトマネジメントの難しさ
先日、国内最大規模のweb3ハッカソン「東京web3ハッカソン」が開催され、PM DAOメンバーからもエンジニアとしてYokinist(@yokinist)さん、PMとしてHayakawa(@kzkhykw1991)さんがエントリーしました。
1ヶ月という短い間で、チームビルディングからプロダクトリリースまでを行い、そこでの学びをお伝えしていきたいと思います。
TLDR (要約)
ハッカソンにおけるプロダクトマネジメント業務の詳細・振り返りを共有します。読者の方に、ケーススタディのような形で、プロダクトマネジメントについて共有していきます。
ハッカソンにおけるプロダクトマネジメントと仕事で求められるプロダクトマネジメントは必ずしもイコールではない
プロダクトマネジメントを経験する場としてPM DAOもハッカソンのPM版ような場を創っていきたい。一緒に創る仲間募集しています！
👀 そもそもWeb3ハッカソンって？
デベロッパーの方にお馴染みの、ハッカソン。今回は、kinjo(@illshin)さんがリードするAkindo(@akindo_io) の”web2からweb3のトランジション”を目的としたweb3の技術に触れ、実装まで行えるプロダクト開発イベント「東京Web3ハッカソン」に参加しました。
PM DAOチームは約1ヶ月間の準備期間でDePod - Decentralized Podcast Platformを開発しリリースしました！詳細はこちら：DePod - Decentralized Podcast Platform
残念ながら入賞はできませんでしたが、ハッカソン期間中の活動の中で得た、プロダクトマネジメントのあれこれをお伝えします！
🚀 実際に何をしたの？
まず初めに、”ハッカソンにおけるPMとして求められている役割・責任を明確”にしました。
Product Schoolの記事によると、
課題やプロダクト開発に対する共通認識を持つ結束したチームを創ること
顧客の課題を理解しストーリーを通してプロダクトを審査員の評価を得ること
がハッカソンにおけるPMとしての務めだということがわかります。この指針を元に実際に以下のプロセスで開発を進めました。
実際の流れ
Phase 1: チームビルディング
エンジニアやデザイナーをSNSやDiscord内で探し、チームとしてのストラテジーやビジョンを作り、プロダクト開発に向けた環境基盤を整えます。
Phase 2: ディスカバー
チーム内で何を創るかをアイデアを出し、プロトタイプのデザインをしていきます。
今回は「音楽xNFT」という領域はあえて決め内で行い、事前に4名の想定ユーザーに対して簡易的なユーザーインタビューを行い、想定している課題がありそうかどうかを調査しました。
今回のトピックであったWeb3の技術やNFTをどうプロダクトに反映していくのか、何の課題を解決していくのかをディスカッションし内容を決めていきます。(今回はこのフェーズに最も時間と労力を割きました)
Phase 3: プロダクト開発
実際に動くものを作っていく段階です。どの課題を解決するのか、その中でも何をMVPとするのか、機能として何を実装するのか、等々優先順位を付けてプロダクトに落とし込んでいきます。レビューやユーザーインタビューを通し、最終形へのラストスパートをかけていきます。
Phase 4: ゴール
プロダクトデモやマーケティングコンテンツを制作しプロダクトの仕上げに入ります。
(実際には、Githubのリポジトリとデモビデオを提出)
外部サポーターの力も借り、プロモーションビデオも制作 (Special thanks to talos#4061)
💡ハッカソンでの学び：ハッカソンでのPM力 ≠ 従来求められるPM力
今回の一番の学びは、ハッカソンでの求められるプロダクトマネジメントは、従来求められるプロダクトマネジメントとは異なる、という点です。
大きく三点、①チーム・②構造・③目的での違いがありました。
①物理的/心理面でのチーム内の障壁(時間×距離)
まず参加メンバー全員が本業があり、ハッカソンの開発にかけられるのはせいぜい週5時間ほど。この限られたリソースの中で、完成度の高いものを1ヶ月で作り上げるのは至難の技です。 また時間的なリソースに加え、初対面のメンバーと非同期でコミュニケーションを進めることへの大変さも痛感しました。
🗣 参加メンバーの声
”積極的にメンバー同士のコミュニケーションに関与すべきだったが、各人にタスクや意思疎通の頻度を任せてた部分があった”
”今までのハッカソンはリアルで会って開発していたが、今回はオンラインでのやり取りだったので早い段階からメンバーを巻き込む場を設けて開発を進めるべきだった”
②組織的な構造での障壁
スクラムマスター(プロセスを着実に進めていく進行役/エンジニアリングをリードする人)が存在しないことや、意思決定をする際のファクター(誰のために作って、誰から評価を受けるのか)が曖昧、といった組織構造上生じる壁がありました。
通常の会社のようなKPIや規約、雇用契約が存在しないため、人によってコミット量やモチベーションにばらつきもあります。ハッカソンではそういった部分の”前提”の違いを痛感しました。
③目的の相違
そして、今回PMとしての違いを大きく感じた理由の一つが、クライテリアの違いです。Web3ハッカソンは、Technicality / Originality / Practicality / Usability / WOW factorの五つが審査基準となっています。一方で、実際のビジネスでプロダクトマネジメントをする際、解決する課題の複雑さやオリジナリティー、wow! ファクターは必ずしも必要ではありません。使われているプロダクトとハッカソンで評価されるプロダクトはイコールではないという学びもありました。
また、“Web3に関係する技術を使って”といった前提がある場合、ソリューション(手段)から課題を考えるという本来とは逆方向でのアプローチになってしまい、PMとしてのジレンマも感じました。
エンジニアとしては、Web3に関する特定の技術を使わなきゃいけないという制約があり、技術への理解がないとアイデアが練られないといった部分で難しさがありました。
🎯もしやり直せるなら？？
今後やるなら顧客と市場を知ることによりリソースを割きたいと思います。特に、審査員を含む"今回のハッカソン"という市場におけるユーザーリサーチに時間を使います。実際に入賞したチームのいくつかは、事前に10人近くのユーザーリサーチを行っており、ここで勝敗が分かれたと思っています。冒頭で述べた、PMに求めらている”selling the judge”のアプローチで、早い段階から意見を取り入れることが改善の鍵だと感じています。
💬 PM DAOメンバーからの質問
Q1. リソースが限られている開発だからこそ、逆に削ぎ落とす点はありますか？
✅ 納得感も大事だが、スピード重視の場合はアイデア段階で指針を決めておき、期待値が一緒の状態で人を集めます。今回チームを集める段階では、音楽×NFTというざっくりとしたエリアだけを示して募集したが、目的を示さずに集めたことで創るものを決める際にまとまりづらかった。スピードを重視する場合は、目的を明確にし、”〇〇作ります！作れる人〜！作りたい人〜！”という形で募集をするのもいいと思います。
Q2. スケジュール遅延があった中、最終的にはどうやって締めまで間に合わせたのですか？
✅ PMとして徹底した点は二点
①エンジニアの環境を整える
リリース直前はエンジニア頼りになるので、それ以前の環境、コンテキストを整える必要がある。実際の会社でのPM業務でもリリース直前には極力連絡をしない、MTGを入れないといったコーディングに集中できる環境を作ります。
②最終的な意思決定(要件を落とす作業)
期日に間に合わせるために、優先順位の低いものを削ぎ落としていきました。実際のPMの仕事でも状況に合わせて優先順位が低い要件を落とすという意思決定が必要になります。最初にロードマップで決めたことを”やらない”という選択をするのもPMの仕事。
Q3. Q2で仰った”削ぎ落とす作業”でのプライオリティはどう判断するのですか？
✅ プロダクトを考える際に作るロジックツリーというものがあります。一つの課題を因数分解し、それぞれ深堀した要因に対する解決策をジョブ理論を用いて定義化します。実際は重みづけとしてユーザーリサーチの結果を加えます。
そして、そこで出した優先順位の高いジョブを元に作る・作らないの判断をしていきます。プロダクトの解決すべき課題の優先順位が決まるとその課題を解決するソリューションの優先順位、そしてそのソリューションに対して作る機能の優先順位といった順で優先度をつけていくことができます。
Q4. チーム内での経験値での差はありましたか？(資料を拝見すると)本格的なPMアプローチで開発を進めていますがチーム内でのコミュニケーションはどうされていたのですか？
✅ ジョブ理論やフレームワークといった思考法はメンバーにはできるだけ共有せず、PMの言語ではなく、相手(エンジニアやデザイナー)の言語でコミュニティケーションをとるように気を付けていました。全体像をまとめた資料やPRDを共有しメンバー全員の共通言語を作ることで合意形成につなげていました。
Q5. 課題の洗い出し〜要件定義〜言語化までどれくらいの期間で行いましたか？
✅ 一週間半、1日3・4時間、大体20時間かけましたかね。一回で作り切るものではないので、土台を作り毎週のミーティングでフィードバックを貰いながら磨きをかけていきましたね。
💎サマリー
ハッカソンにおけるプロダクトマネジメントと現実のビジネスで求められているプロダクトマネジメントは必ずしも一緒ではない、というインサイトを元に実際には何が異なるのか、次ハッカソンに出場するならどこを改善するか、などを振り返りました。
一方で、プロダクトマネジメントを経験する場としてハッカソンは有意義な環境なので、プロダクトマネジメントのためのハッカソンがあったらどうだろう？というアイデアも生まれました。
前述の評価項目とは異なる基準や、コーディングをあえて禁止にしたプロトタイプ作成など、PMならではの成果物を求めたハッカソンがあると面白い、かつ実践的にPMの学習ができる環境になると思います。
今後、PM DAO内でもPM経験ができる環境を整えていきたいと思いますので、ご興味ある方はぜひご参加ください！
Content writer: ソウザ (@_souzaipan_)
この記事が気に入ったらサポートをしてみませんか？