個人開発とプロダクトマネジメント

はじめに

個人開発の目的は多岐にわたり、その実践者も多様性に富んでいる。職業エンジニアだけではなく、エンジニアを志す者、技術に関心を寄せる学生といった幅広い担い手たちが、「技術を習得したい」「既存製品では実現できないモノを作りたい」「その場のノリで始めたが、いろいろあって続けざるを得なくなった」など、多様な動機をもって個人開発に取り組んでいる。この包括的な多様性が個人開発の真髄であり、魅力の源泉となっている。

つまり個人開発は自由なモノづくりの一形態なのだ。個人開発では、自分のやりたいようにやる自由がある。企業で行っている営利的な活動とは違って金銭的利益を出す必要があるわけではないし、個人でやっているのだから同僚と歩調を合わせる必要もない。どのようにやるのも個人の自由だ。しかし、往々にして完全な自由とは個人で扱うには重すぎるものだ。指針なき自由はやがてその自重で潰れ、モチベーションは灰と化していく。

だからこそ、一定の指針が必要だ。指針には複数の可能性がある*1が、その一つにプロダクトマネジメントの考え方がある。プロダクトマネジメントとは、「人・データ・プロセス・ビジネスシステムを組み合わせて、ライフサイクルを通じてプロダクトやサービスを作り、維持し、進化させていくこと」*2である。自らの目的を明確にし、その目的を達成するために、プロダクトマネジメントの考え方は一定の効果を発揮するだろう。

この記事では、個人開発におけるプロダクトマネジメント活動について書いていく。まずは「プロダクトマネジメントのカタ」と呼ばれる考え方を紹介し、その枠組みの中で具体的に何を実行するか述べていく。個人開発らしく、無料で利用できるツール・手段についても紹介していく。内容は主にメリッサ・ペリの『プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける』に基づいているが、一部自分で付け加えた個所がある。個人開発をどのように行っていくかについては統一的な見解があるわけではなく、この文章で書いたことは筆者が考えている一例に過ぎない。ところどころ「この文章を書いているあなたは実現できていないじゃないか」と言いたくなる箇所があるが、どうか勘弁してほしい。

筆者は、個人開発には自由のフロンティアがあると考えており、その自己研鑽と自己表現の精神を貴んでいる。だが、自由であるがゆえに指針を見つけられず、自分で道を示すこともできず、せっかくの才能を発揮できない個人開発者を見てきた。だからこそ、一定の方針を確立する道しるべとなるプロダクトマネジメントの考え方は、個人開発者にとっては救いになりうると思っている。

「プロダクトのカタ」について

「プロダクトのカタ」は作るべきソリューションを明らかにするプロセスであり、プロダクトを発展させるための手段を検討する際に有益なフレームワークである。プロダクトのカタに沿って方向性を立て、現状を分析し、適切なソリューションを考え、実行することで、プロダクトを発展させることができる。*3。

メリッサ・ペリによるプロダクトのカタ

上記の画像では順番にステップを進めているように見えるが、実際には1, 2, 3のステップは相互に行き来しながら進めることが多い。つまり、現状を分析しながら方向性を決め、次の目標を設定し、「違うな」と思ったらやり直してもう一度方向性を定め、決定した目標を達成するための手段を考える、といった具合である。したがって、以降の記述では「方向性を理解する」「現状を分析する」「次の目標を設定する」のプロセスをひとまとめにし、「プロダクトプロセスのステップを選択する」をその次の段階とする。

プロダクトのカタでは、以下の質問に答えることを目標としている。逆に言えば、以下の質問にすべて答えられればカタがきれいに決まったことになる。

1. 目標は何か?
2. 目標を踏まえて、自分たちは今どこにいるのか?
3. 目標に到達するうえで立ちはだかる最大の問題や障害は何か?
4. どうやってその問題を解決するか?
5. 何が起こると予想されるか?
6. 実際には何が起こったか、そこから何を学んだか?

方向性を理解し、成功指標を設定する

このプロセスでは、「目標は何か」と「自分たちは今どこにいるのか」を把握し、そのうえで「どの程度まで達成したいのか」を設定する。「方向性」とは、具体的にどのような問題を扱えばよいかの指針のこと*4で、具体的には以下のようなものである。

• ユーザーからの投稿数を引き上げる
• 3日連続で訪問するユーザーの数を増やす
• SNSへの投稿数を増やす

方向性を決めるプロセスにおいては、データが重要な役割を果たす。

データから探索する

プロダクトの目標を探索しながら現状を理解する際には、定量的なデータも定性的なデータもどちらも有用だ。「指標」も「ユーザーの声」もうまく利用すれば適切な道しるべになる。基本的な考え方を示しつつ、可能な限り安くデータを収集する方法を書いていく。

「海賊指標」の考え方

指標はうまく利用すればプロダクトの適切な目標設定に役立つ。考え方は複数あるが、個人的には「海賊指標」の考え方がわかりやすいと思う。「海賊指標」とは、アクティベーション、アクイジション、リテンション、リファーラル、レベニューの5つの指標を用いて、ファネル分析の考え方からユーザーの行動を分析するフレームワークである*5。

海賊指標

例えば、広告収益を稼ぐために設置されたユーザー投稿型のサイトを運営する場合、それぞれの概念と具体的なユーザー動作の対応関係は以下のようになるだろう。

• アクイジション：ページビュー数
• アクティベーション：投稿数
• リテンション：3日間毎日ログインしているユーザー数 / 合計ユーザー数
• リファーラル：SNSへのポスト数、ネットプロモータースコア
• レベニュー：広告収益、もしくは有料ユーザー数

後述の方法で収集した数値を海賊指標の考え方に従って配置し、どの部分を改善すればよいのかを考えることができる。

数値を集積する

当然だが、事前に準備していない限り指標を利用することはできない。以下におすすめの手法をリストアップする。Web系の場合であればGoogle Analytics, Google Search Console, 監視ツールをひとまず入れておくのがおすすめで、他はニーズに応じて組むといいと思う。

Google Analytics

• 基本無料
• Web上でのユーザー行動を分析するために使える
• PV数、ユーザーの滞在時間など、基本的な数値は設定不要で収集できる
• ただし、利用規約でユーザーに明示的に利用していることを示す必要がある
• なお、CloudflareなどのCDNにはGoogle Analyticsを（ほぼ）ワンクリックで設定できる機能がある*6

Google Search Console

• 基本無料
• ドメインを所有している必要がある*7
• 検索クエリがわかるため、ユーザーがどのようなワードを検索窓に打ち込んで自分のサイトに流れてきたのかわかる
• 読み込み速度などのサイトパフォーマンスを簡易的に把握できるのも便利

監視ツール

• 具体的にはNew Relic・Sentry・Datadog・Baselimeなど
• New Relicは無料枠が寛大なのでおすすめだが、技術スタックにあったものを選ぶといい
• 400・500番台のエラーが起こっていないかどうか監視し、不具合が発生していないかどうかを統計的に収集できる
• 攻撃（後述）の監視にも有効

自分で組む

• Google Analyticsや監視ツールでのデータ収集が適さない場合、データベースに格納されたデータをOLAP*8に移し、データを加工してダッシュボードで表示する手段がある*9
• OLAPではコストパフォーマンスが圧倒的に高いGoogle BigQuery、BigQuery内部でのデータ加工は無料枠のあるdbt CloudやDataform、ダッシュボードではBigQueryとの相性が良くなおかつ無料のLooker Studioがおすすめ

詳しくは過去に書いたものを読んでほしい

contradiction29.hatenablog.com

定性的に探索する

定量的な手法に加えて、定性的な手法も利用できると役に立つ。以下におすすめの手法をリストアップする。

自分で使う

• 使うだけなら無料
• いわゆる「ドッグフーディング」と呼ばれる行為
• 自分で使わないとわからないことも結構多い

SNSでエゴサする

• Twitter（現X）、Misskeyなどで検索する
• 無料
• 生のユーザーの声が聴ける
• 手軽にできるのでおすすめだが、あまり深い情報は出てこない
• ネガティブな意見も目にすることになるため、気が弱い人は要注意

Discordでコミュニティを作る

• 無料
• 作者ーユーザー間のコミュニケーション経路が作れるのでおすすめ
• 管理にテクニックがいるのに注意。慣れている人にアドバイスをもらったり運営に参加してもらうか、自分で学習する必要がある。
• Slackも一昔前までは選択肢に入ったが、現在では無料プランで90日以上前の投稿が見れなくなったため、実用的ではなくなった

現実世界の友人や仲がいい人に布教する

• たぶん無料*10
• 最も率直なフィードバックをくれる
• 作っているもの次第では友情が深まったり交友関係が広がったりすることもあるが、逆の場合もあり得る（経験談）

方向性を決める

上記の手法で定性的・定量的な側面から現状を把握しつつ、方向性を決めよう。方向性を考えてから定性的・定量的なデータで裏付けを取るのでもいい。個人的には、自分でプロダクトを触ったり、ユーザーから話を聞いたりしながら仮説を考え、数字を利用して裏付けを取るのがスムーズだと思う。

方向性を実現するための手段を選択する*11

方向性が定まったのなら、方向性を実現するための手段を考えよう。

書籍では

方向性を実現するための手段を考える際には、まずは問題を理解し、次にソリューションを探索し、最後にソリューションの構築と最適化を行う。

• 問題の探索：目標に到達するうえで立ちはだかる最大の問題や障害は何かを理解する
• ソリューションの探索：どうやって問題を解決するかを考え、生み出した手段が本当に問題にアプローチできているかを探る
• ソリューションの構築と最適化：問題解決の手法を実装しつつ、計測を通じて目標の達成度合いを測り、最適化していく

「問題の探索」では、ユーザー調査や観察、アンケート、フィードバックなどを利用しつつ、目標に到達するうえで立ちはだかる最大の問題や障害が何かを把握する。この段階をすっ飛ばし、問題を理解できないと、ソリューションが的外れなものになってしまう。

「ソリューションの探索」では、問題を解決する手法を仮説検証する。問題を理解できたとしても、ソリューションが問題にうまくアプローチできるとは限らない。学習を行いながらソリューションを探索することが必要となる。ソリューションが構築できたら、実際に何が起きたかを計測しつつ、学習を通じて最適化をしていく。

なんて書かれているが...

実際には

例：

「ユーザー当たりのページビュー数を引き上げたいんだけど、何が問題なのかよくわからないなぁ。とりあえずトップページの導線が悪いのが原因なのかな？」

「ソリューションは...これでいいのかな。ヨシ！実装！」

～3日後～

「数字を見たけど...あまり効果出てないな...」

こういう感じになる。

効果が出ていないのは問題の探索ができていないからだ。方向性はわかっていても、何がその方向性を妨げているのかを正確に理解できていない。問題の探索をやらなくてはならないのはわかっているが、以下の事情で時間がないがために、うまく探索することができないでいる。

• 本業で時間がない
• 勉強時間に割いているせいで個人開発に時間がさけない
• 個人開発のモチベーションに波がある
• 本業での疲労が蓄積している

問題の探索ができていないため、当然ソリューションの探索もうまくできていない。アンチパターンを踏んでしまっているのが現状である。

おわりに

途中で尻切れトンボになってしまった。自分ができていないことについては書けないから許してほしい。なお、本題からそれてしまう補足的なトピックを補論に書いた。

補論 攻撃への対策

「個人開発のプロダクトだから攻撃を受けない」なんてことはなく、攻撃を受ける可能性があるなら攻撃はされる。データベースに個人情報を保存しないなど、仮に攻撃されても損害が出ないようにしておくだけでは不十分で、より積極的な対応をしない限り、攻撃は防げない。

攻撃を防ぐ、あるいは被害を最小化する際のポイントは、「機械的に対応が可能な攻撃」と「機械的な対応ができない攻撃」に分けることである。例えば、DDoS攻撃は機械的な対応が可能だが、「荒らし」は多くの場合機械的な対応が難しい。

機械的な対応が可能な攻撃

機械的な対応が可能な攻撃としては以下のようなものがある。

• DDoS攻撃
• HTTPポストリクエストフラッド攻撃
• SQLインジェクション、XSS

上記のような攻撃に対しては、以下の対策が有効である。

• サニタイジング、ORMの利用
• Under Attackモードの有効化。VercelやCloudflare(CDN)にはUnder Attackモードがあり、有効化すればDDoS攻撃やHTTPポストリクエストフラッド攻撃を無効化できる。無料で利用可能。
• ReCAPCHA認証の利用。HTTP POSTリクエストに対してトークンを付与し、リクエストを検証する仕組みを作る。Cloudflare Turnstileなら無料で利用可能
• 連投の抑制。レートリミット制限の実施など。

CloudflareのUnder Attackモード

機械的な対応が難しい攻撃

例えば「荒らし行為」は通常の投稿と区別が難しく、事前に検知することは難しい。事前に検知しようとすれば疑陽性率*12が上がってしまい、一般のユーザーの体験を阻害してしまうリスクもある。このような場合、早期に荒らしの効果を無効化する手法が有効である。具体的には：

• 管理用のアプリケーションの作成。投稿の削除やユーザーのブロックを速攻でできるアプリケーションを作り、荒らし行為をなるべく早く無効化する。スマートフォンから操作できる仕組みにしておくと、出先からでも対応できるのでなおよい。
• ログを残す。プロバイダへの問い合わせ用にIPアドレスは保存しておいた方がいい。

仮に荒らしを受けたとしてもネット上で騒いだりしてはならない。大体の荒らしは愉快犯であるため、正面からは相手にせず、一切の痕跡を残さず存在自体をなかったことにする一方で、技術的措置をもって対応し、場合によっては法的措置を取るのを薦めている。実行者に決して名前を与えてはならず、その痕跡はすべて消し去るべきだ。ニュージーランドの首相が銃撃犯に対して行ったのと同じことだ。

www.bbc.com

荒らしに対して正面から対応しようとすれば、真面目な人ほど精神をすり減らしてしまう。技術的な対策を実施して穴をふさぎ、仮に穴を突かれたとしても素早く復旧できる仕組みを作る。場合によってはIPアドレスを保存しプロバイダに問い合わせを行う手段を残す。必要なのは技術的対応と法的な対応であり、絶対に正面から対応してはならない。

注釈

*1:ほかに考えていた指針の候補は「宗教的観念の実装」だが、話題がそれてしまうので割愛する

*2:A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management (ENGLISH), Appendix X4における原文は以下の通り。Product management. Product management is the integration of people, data, processes, and business systems to create, maintain, and evolve a product or service throughout its life cycle.

*3:メリッサ・ペリ『プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける』15章

*4:「プロダクトイニシアティブ」と呼ばれる。本を読んでもよくわからなかったので, https://tamamemo.hatenablog.com/entry/2023/05/27/222530] を参考にさせてもらった

*5:メリッサ・ペリ『プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける』16章より引用

*6:Cloudflare Zarasのこと。Cloudflare(CDN)にはサードパーティー製のツールをワンクリックで搭載できるZarasをはじめとして、DDoS攻撃を受けた際にワンクリックでBotアクセスを弾けるUnder Attackモードが搭載されていたり、セキュリティに関する設定が簡単だったり、無料枠が寛大だったり、多機能な割に使いやすく、なおかつコストパフォーマンスも高いため、CDNの中では最もおすすめできる。

*7:Cloudflareでドメインを取得しているなら、ほぼワンクリックで設定できる。

*8:OLAP：Google BigQueryやSnowflake, Motherdackなど、分析用途に適したデータベースのこと。大量のデータをスキャンするクエリを効率よく処理できる。MySQLやPostgresはOLTPといって、分析用の重たいクエリを投げるとパフォーマンスが低下し、場合によってはアプリケーションが落ちることがあるため、データ量と必要性に応じた使い分けが必要となる

*9:「データエンジニアリング」「アナリティクスエンジニアリング」などの用語で調べるとこの辺りは詳しく出てくる

*10:人によっては友だち料がかかるかもしれない

*11:原著では「プロダクトプロセスのステップを選択する」となっていたが、何のことかわからないので言葉を置き換えてある

*12:疑陽性率：荒らしユーザーではない一般ユーザーを荒らしと判定する割合