はじめに — 「ダメなものはダメな気がしている」と口に出した日
個人開発で複数のサービスを並行して動かしているけれど、どれも無風状態が続いている。その違和感を抱えながらも、「公開しているサービスは多い方がいい」「いつかは伸びるかもしれない」と自分に言い聞かせて、決断を先送りにしている。そんな状態に心当たりはないでしょうか。
私もそうでした。
2026 年 4 月、ちょうどそういう状態に行き詰まっていたある朝、Claude Code に向けて自分の嗅覚を口に出してみました。「ダメなものはダメな気がしている」と。
返ってきた答えは「その嗅覚は正しい」でした。
この一言を起点に、その日のうちにサービスポートフォリオ戦略のドキュメントを書き、撤退判断こそ PdM の仕事だという発想の転換を済ませ、その副産物として 自分のキャリア軸そのものを発見する ことになりました。
この記事では、Zeronova（呑名 健造）が経験した「太い幹を見つけた瞬間」の思考プロセスと、AI 協業がその発見にどう寄与したかを共有します。個人開発で複数サービスを抱えて迷っている方、キャリア軸の言語化に悩んでいる方の参考になれば幸いです。
8 つのサービスを並行運用していた状態
その時点で私が抱えていたサービスは 8 つでした。
- ZERONOVA LAB（このサイト）
- BestFitNavi（フィットネスメディア、ロリポップ相乗りでゼロコスト）
- IdeaSpool（アイデア管理 PWA）
- Wakulier（時間管理ツール）
- CancelNavi（サブスク解約ガイド）
- ZERONOVA LAB MCP Server（AI エージェント向け Web 検査ツール群）
- 自治会 DX（共同代表として運営する自治会業務デジタル化）
- BandBridge（ミュージシャンマッチング、共同開発）
数だけ並べると賑やかですが、実態としてユーザーが見えているのは、自治会 DX（住民世帯）、BestFitNavi（被リンク 723 サイト・自然流入・お問い合わせが継続）、ZERONOVA LAB（流入とお問い合わせが継続、Journal / Focus Blog で発信中）の 3 つ。他は静かに動いているだけです。「複数サービス並行運用の認知負荷が、目の前にユーザーがいる自治会DXの伸びを削っている」というのが、自分の嗅覚が訴えていたことでした。
devlog にはこう書きました。
複数サービス並行運用の認知負荷が、目の前にユーザーがいる自治会DXの伸びを削っていた
頭では分かっていたけれど、決断を先送りにしていた。「動いているサービスがある」こと自体が個人開発者としての E-E-A-T になっているはずだ、という思い込みもありました。
AI に「専門家として」意見を求める
そこで Claude Code に向けて、専門家視点での意見を求めました。重要だったのは「壁打ち」のスタンスではなく、「専門家としてのレビュー」を依頼したことです。
判断軸は最初から決めず、4 軸を提案してもらいました。
- トラフィック — 流入はあるか
- コスト — 維持コストはどれくらいか
- 成長余地 — 改善で伸ばせる見込みはあるか
- 戦略的価値 — ポートフォリオ全体で見たときの位置づけは
この 4 軸で 8 サービスを評価していくと、自然と「強化」「維持」「クローズ予定」の 3 群に分かれていきました。最終的に着地した方針はこうでした。
- 強化: 自治会 DX（342 世帯の自治会で実証実験がスタート）、BestFitNavi（被リンク・流入・お問い合わせが継続）、ZERONOVA LAB（Journal / Focus Blog の記事執筆で常時投資中）
- 維持: BandBridge（共同開発・現在は自治会DXにリソース集中）、IdeaSpool、MCP Server
- クローズ予定: Wakulier、CancelNavi（リリース後無風、改善見込みなし）
注目すべきは BestFitNavi の扱いでした。当初、Claude Code は「凍結（LP 化）」を提案してきました。トラフィックの絶対値だけ見ると頭打ち、という根拠です。
ですが、私は重要な情報を後から伝えました。「BestFitNavi はロリポップ相乗りでゼロコスト、DR24、被リンク 723 サイト、しかも自然流入とお問い合わせが今も継続している」と。すると Claude Code の提案は段階的に変わっていきました。コストゼロ + 被リンク資産で「凍結」から「維持」へ。さらに「ユーザーの実在シグナル（お問い合わせと自然流入）がある」ことを踏まえて「維持」から「強化」へ、最終的に格上げされました。
このやり取りで気づいたのは、AI 壁打ちの精度は「情報の出し方」で大きく変わる、ということです。情報を出し惜しみすると、AI は限られた前提で合理的に判断し、結果として現実と乖離した提案になる。これは AI の限界というより、私の側の問題でした。
「凍結」「維持」「強化」の違いを明文化する
BestFitNavi の判断修正は、副産物として「凍結」「維持」「強化」の違いを明文化するきっかけになりました。
- 凍結: 積み上げ資産が惜しいけれど維持コストが負担になっている、コスト削減策
- 維持: そもそもコストが問題にならない、塩漬けでも価値が残るオプション
- 強化: 目の前にユーザーが実在していて、投資すれば伸びる手応えがあるもの
BestFitNavi は最初、中段（維持）だと思っていました。ロリポップ相乗りなら追加コストはゼロ。被リンク 723 サイトという資産は、何もしなくても腐らない。「無料で持てるオプション」として塩漬けで十分だと。
ですが、判断軸を細かく見直していくと、お問い合わせや自然流入というユーザーの実在シグナルがある以上、塩漬けは機会損失だと気づきました。判断軸に「ユーザーが実在するか」を加えると、最上段（強化）に格上げするのが正しい判断でした。
このサイクルで気づいたのは、情報を出し惜しみせず議論できる関係と、ドキュメント化のサイクルが、いい意思決定プロセスを生む ということでした。
撤退判断こそ PdM の仕事
ここまでで、ポートフォリオの整理自体は完了していました。Wakulier と CancelNavi はクローズ予定、他は維持または強化。
ただ、もう一歩踏み込んだ気づきがありました。「撤退判断は失点ではない」ということです。
devlog にはこう残しています。
撤退判断は失点ではなく、PMとして一番大事な判断 「諦めない」ことではなく「リソースを正しく配分する」ことがPMの仕事 撤退記事を書けばそれ自体がE-E-A-T資産になる、という発想の転換
E-E-A-T（Experience / Expertise / Authoritativeness / Trust）の Experience には、運用経験だけでなく 撤退判断の経験 も含まれます。失敗を晒せること自体が信頼性の証明になる、という観点に立てば、撤退記事を書くことは資産化作業そのものです。
「動いているサービスがある」ことが資産だ、という最初の思い込みは、実は逆でした。動かないサービスを動かし続けることが、本来書けるはずの「撤退と学び」の記事を奪っている。
クローズ手順も標準化することにしました。撤退記事、301 リダイレクト、予告ポスト、技術的クリーンアップ、の 4 点セット。これを docs/service-portfolio-strategy.md に書き残し、四半期に 1 回の棚卸しサイクルとして運用に組み込みました。
副産物として「太い幹」が見えた
ここからが、この記事の本題です。
ポートフォリオ戦略のドキュメントを書き終えた直後、もう一つ別の戦略文書を書く必要があると気づきました。Claude Code とのやり取りの中で、こんな話が出てきたからです。
「自治会DXのユーザーの大半はシニア層です。一方で、本業はシニア向け BtoC オンラインプラットフォームで CRM やナーチャリング基盤を構築しています。この 2 つが同じ軸で動いているのは偶然ではなく、戦略的に活用できる資産では？」
頭の中で何かが繋がりました。
それまで私は「本業は本業、個人開発は個人開発」と分けて考えていました。本業では PdM としてシニア向けのプロダクトを動かし、個人開発では Claude Code と一緒に色々作っている。この 2 つは別の活動で、別のスキルセットを使うものだと。
ですが、Claude Code が提示した視点はこうでした。両方とも「シニア向けインターネットサービス」という同じ幹に通じている。
そして、その幹にすでに証跡が積み上がっていることに気づきました。
- 自治会DX の高齢者 UX 実装記録 — 文字サイズ・タップ領域・コントラスト・認知負荷など、シニア向け UI で避けるべきパターンを、すでに数十本の devlog と技術記事として残している
- 本業の経験 — シニア向け BtoC プラットフォームで PdM として動かしてきた実務知見
これらは別々の活動で積み上げてきたものでしたが、「シニア向けインターネットサービス」という幹からすれば、すべて同じ枝の話 でした。
「AI ネイティブ × シニア UX × 実装まで自走する PdM」の交差点
幹が見えた直後、Claude Code とその交差点の希少性について議論しました。
- AI ネイティブ という軸を掲げている人は多い
- シニア UX を専門にしている人もいる（アクセシビリティの専門家など）
- 実装まで自走する PdM も探せばいる
ですが、この 3 つの交差点に立っている人 は、検索しても見当たりませんでした。AI ネイティブ × シニア UX、AI ネイティブ × 実装自走 PdM、までは部分集合の人がいる。でも 3 つ全部となると、無人地帯に近い。
これは E-E-A-T を構築するうえで、ものすごく有利なポジションでした。Google が見ているのは「このトピックでこの人を権威として扱えるか」です。トピックの選び方が「あまりに広い」だと埋もれ、「あまりに狭い」だと需要がない。「狭いけれど需要のある交差点」が一番強い。
この発見の重要なポイントは、意図的に交差点を作ったわけではない ということです。気づいたら既にそこに立っていた。本業の経験、自治会 DX の運営、Claude Code との協業、そのすべてが偶然「シニア向けインターネットサービス × AI 協業」の方向を向いていた。
devlog の体験・感情メモに、こう残しています。
本業と自治会DXの共通項が「シニア向けインターネットサービス」だと言語化できた瞬間、これまで散らばっていた点が一本の幹に繋がる感覚があった。ポートフォリオ戦略の策定がトリガーで、副産物として自分のキャリア軸そのものが見えた
「気づいたら既にやっていた」という後付けではない軸を発見できたのは、地に足のついた実感がある。E-E-A-T を「狙って取りに行く」のではなく「既にあるものを言語化する」という順序の正しさを実感
L2 — AI との対話で軸が浮き上がる瞬間
このときの Claude Code とのやり取りで、軸の発見につながった一連の対話があります。一部を再構成して紹介します。
Zeronova（中略：8 サービスの評価。BestFitNavi の判断修正）
ZeronovaZeronovaZeronovaZeronovaこの対話の後、私はそのまま docs/identity/senior-ux-strategy.md という別の戦略文書を書き始めていました。最初に書こうとしていたサービスポートフォリオ戦略の文書がトリガーになって、その日のうちに自分のキャリア軸の戦略文書まで完成した、という流れです。
「狙って取りに行く」のではなく「既にあるものを言語化する」
この体験を通じて、E-E-A-T を構築するうえで最も大事な発想の転換は、順序 だと思うようになりました。
よくある E-E-A-T の組み立て方は、「Google が評価しそうな専門領域を選び、その方向にコンテンツを積み上げる」というものです。これは外側から見れば合理的に見えますが、実際にやってみると無理が出やすい。専門性は「持っている」ことが条件で、「これから持ちにいく」ものとは違うからです。
順序を逆にすると、こうなります。
- これまでに積み上げてきたものを棚卸しする
- その中で、自分の中で繋がっていなかったものが、外から見ると繋がっている軸を探す
- その軸を言語化して、コンテンツの方向性として宣言する
3 のステップが「既にあるものを言語化する」作業です。私の場合、本業（シニア向け BtoC プラットフォームの PdM）と個人開発（自治会 DX、らくらくフォン対応の技術記事、AI 協業の発信）が、外から見ると「シニア向けインターネットサービス × AI ネイティブ × 実装自走 PdM」という同じ軸を向いていた。これに気づいたのが「太い幹を見つけた瞬間」でした。
この順序で組み立てた E-E-A-T は、地に足がついています。「狙って取りに行く」アプローチだと、専門性が後から付いてくる前提で書くことになり、書いている本人が一番不安です。「既にあるものを言語化する」アプローチだと、書いている内容が経験そのものなので、迷いがありません。
戦略文書化の副次効果
この体験で気づいたもう一つの学びは、ドキュメント化が共同開発時代に効いてくる ということでした。
個人開発で 1 人で動いていた時代には、ポートフォリオ戦略やキャリア軸の戦略を文書化する必要は感じていませんでした。頭の中にあれば動ける。
でも、2026 年に入ってから自治会 DX と BandBridge は共同開発になりました。共同開発者のベテラン SE さんに「Zeronova のポートフォリオ全体観」を 1 ページで伝えられる素材があるかどうかは、コミュニケーション速度を大きく左右します。
ドキュメント化の副次効果はもう一つあります。3 ヶ月後の自分が同じ基準で判断できる ことです。感情やサンクコストに引きずられない仕組みを残しておくことで、未来の自分への手紙になる。四半期に 1 回の棚卸しサイクルを docs/operations-calendar.md に組み込んだのは、この「未来の自分への手紙」を運用に落とすためでした。
まとめ — 太い幹を見つけるためのチェックリスト
最後に、この体験から抽出した「太い幹を見つけるためのチェックリスト」を共有します。これからキャリア軸の言語化に取り組む方の参考になれば幸いです。
- ポートフォリオの整理から始める — 抱えているもの全部を 4 軸（トラフィック・コスト・成長余地・戦略的価値）で評価する
- AI には「専門家として」意見を求める — 「壁打ち」ではなく「専門家レビュー」というスタンスで、情報を出し惜しみせず議論する
- 撤退判断を失点と捉えない — 撤退記事こそ E-E-A-T 資産になる
- 本業と個人開発の共通項を探す — 「シニア向けインターネットサービス」のように、抽象度を一段上げると幹が見える
- 既にある証跡を棚卸しする — 過去の記事・devlog・実務経験を、新しい幹の文脈で再解釈する
- 交差点の希少性を測る — 3 軸の交差点に立っている人が他にいなければ、それは E-E-A-T 戦略上の空白地帯
- 戦略文書として書き残す — 3 ヶ月後の自分が同じ基準で判断できる形にする
「ダメなものはダメな気がしている」と口に出した朝から、その日のうちに 3 つの戦略文書（サービスポートフォリオ戦略、シニア UX 戦略、本名統合戦略）を書ききったときの感覚は、いまだに残っています。
それぞれが独立しているように見えて、実は「自分は何者か」という同じ問いに別角度から答える作業だった。締めくくりにキャリア軸まで踏み込めたのは、午前の議論の自然な帰結だったと思います。
太い幹は、新しく植えるものではなく、すでにそこにあったものを認識する作業の中で見えてくるのかもしれません。
関連記事
Zeronova（呑名 健造）
PdM / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。