YouTubeをやりたいと思ったことは、これまでにも何度かあった。
個人開発や生成AIについて、自分が試したことを話す場がほしい。 記事を書き、動画にして、Podcastのように聞ける形にもしたい。 うまくいけば、個人開発の過程そのものを記録しながら、誰かの次の一手にもできる。
考えていることは、いつもそれなりにある。
それでも続かなかった。
YouTubeは、撮影を始める前に決めることが多い。 テーマ、タイトル、構成、画面、話す順番、編集方法を先に考えているうちに、最初の一本が遠くなる。 時間ができた日に始めようとすると、時間ができた日には別の作業が溜まっている。
問題は、話す材料がないことではなかった。 その場で動画にできる形まで、毎回一人で準備しようとしていたことだった。
YouTubeを始める前に、記事を増やすことにした#
そこで、YouTube用のネタを先に動画へしないことにした。
まずは個人開発とAIに関する記事を、書けるときに書く。 記事がいくつか溜まったら、共通する問いや判断を拾い、Podcastのような音声動画やノウハウ動画へ編集する。
この順番なら、動画を作るたびにゼロから考えなくてよい。 記事は検索で読まれる原本になり、動画では複数の記事を一つの問いへ組み直せる。
動画を毎週公開する予定を先に置くと、公開頻度を守ることが目的になりやすい。 記事を原本に置くと、書けた日に前へ進める。
もちろん、記事を書くだけでYouTubeが続くとは限らない。 それでも、動画を撮れなかった日を完全な停止にしないことには意味がある。
過去のメモから、すでにある材料を探した#
最初にやったのは、新しいネタを考えることではなかった。 過去に自分が何を書き、何を作ろうとして、どこで判断を変えたかを調べた。
個人用のvaultには、すでに次のような記録があった。
- noteの分析支援ツール「note Booster」
- 意図、フロー、実装の合意形成を扱う「Spectal」
- Claude Codeを使ったブログ運用
- AIプロダクトの責任境界、記憶、評価、自動化に関する考察
- 個人開発の題材発見と仮説検証
- 記録を記事や動画へ変換するための設計
これらは、YouTubeのために新しく作った素材ではない。 すでに自分が考え、試し、迷った記録である。
ここから、動画のテーマになりそうな問いを抜き出した。
たとえば、「AIでアプリを作る方法」では広すぎる。 一方で、「AIに作らせる前に、個人開発者が決めること」なら、自分の経験から話せる範囲が見える。
「どの技術を選ぶべきか」ではなく、「今回のプロダクトで何を作らないと決めたか」なら、専門家としての正解を装わずに済む。
過去のメモを読み直すと、私が話せるのは完成したプロダクトの機能だけではないと分かった。 要件を決めたこと、AIへの依頼をやり直したこと、公開前に不安になったこと、売れるか分からないまま料金を置いたことも材料になる。
強い人の成功談から、結果ではなく題材の構造を借りる#
過去のメモだけでは、視聴者が何に関心を持つのか分からない。 そこで、個人開発やAI発信をしているチャンネルを調べた。
今回は、bubecode、kojin-product、taishiyade、programming_tutorial_youtubeを対象にした。
再生数の多い動画には、次のような題材があった。
- AI時代の個人開発の流れ
- 題材選びから開発、収益化までの手順
- AIに仕事や開発を任せる実験
- 作っても売れない問題
- 個人開発をやめた理由
- アプリ公開後の売上や導入数
- 開発に使う道具と、その使い方
強い発信者が話す成功談は、そのまま私には転用しにくい。 何十万円、何百万円の売上や、大きな導入数を同じように語れるわけではないからだ。
ただし、題材の構造は借りられる。
「AIに仕事を任せて大きな成果が出た」という動画を、「非エンジニアのPMが、どの単位ならAIに仕事を任せられるか試した」に変える。 「個人開発で大きく稼いだ」という動画を、「個人開発で最初の1円が生まれるまでに、何を確認するか」に変える。 「アプリを作って売れた」という動画を、「作る前に、売れない可能性をどう確かめるか」に変える。
この変換なら、成功者の結果を再現できなくても、自分の一次経験を使える。
再生数は、企画が自分に合うことを証明しない。 それでも、誰かが関心を持った問いを見つける手がかりにはなる。
ネタを思いつきではなく、判断できる形で残す#
調査した動画と過去のメモを、単なるタイトルの一覧にはしなかった。
それぞれのネタに、次の項目を持たせた。
- どの動画や過去の記録から出てきたか
- 自分のどの経験を材料にできるか
- 記事、Podcast風動画、ノウハウ動画のどれに向くか
- まだ足りない一次情報は何か
- 次に試せる小さな行動は何か
たとえば、「AIに作らせる前に、個人開発者が決めること」というネタなら、note BoosterやSpectalで要件と非要件を決めた経験を材料にできる。 「AI開発の費用を投資として見る」なら、モデル利用料、ホスティング費用、自分の時間、失敗した場合の損失を一緒に記録する必要がある。
ネタをこの形にすると、「面白そうだから撮る」から、「この材料が揃ったら記事にする」へ判断が変わる。
撮らない理由も残る。
技術の比較を専門家のように断定する材料がないなら、選定ガイドにはしない。 一方で、自分があるプロダクトを作るときに、なぜその構成を選んだかなら記事にできる。
話せる範囲を狭めることは、ネタを減らすことではなかった。 自分の経験から離れずに済むネタを増やすことだった。
台本を書く前に、質問で材料を集める#
私は、お題を渡されると台本を一気に書けるタイプだと思う。 だから、最初から台本の完成を目指すより、お題を渡すまでの準備を仕組みにするほうが合っている。
今後は、台本を書く前に、私へ次のような質問を投げることにした。
- 今回、実際に何を試したか。
- 試す前はどうなると思っていたか。
- 一番「思っていたのと違う」と感じた場面はどこか。
- そこで何を続け、何をやめたか。
- 数字、画面、ログ、相手の反応など、何が残っているか。
- 今なら、同じことを始める人に最初の一手として何を勧めるか。
この質問は、私にきれいな説明を求めるためのものではない。 台本になる前の、出来事と判断を取り出すためのものだ。
AIに「個人開発について有益な台本を書いて」と頼めば、一般的な説明はすぐに出てくる。 しかし、それだけでは私が話す理由が残らない。
質問への回答に、実際に試したこと、判断が変わった場面、まだ確かめられていないことが含まれていれば、AIはそれをタイトル、結論、構成へ整理できる。 私が守るのは、何を話すかと、どこまで言い切るかである。
記事をどの時点で動画へ変えるか#
記事を書いたら、すぐ動画にするわけではない。
一つの記事にしか出てこない出来事は、その記事のまま残す。 似た問いを扱う記事が三本ほど溜まったら、Podcastのように複数の記事を一つの話へ組み直す。
同じ判断の型を、別のプロダクトで二回以上使ったら、ノウハウ動画にする。
たとえば、次のような流れである。
- note Boosterで、作る機能と作らない機能を決めた。
- Spectalで、意図と実装の認識を揃える方法を考えた。
- ブログ運用で、AIへ任せる処理と自分が確認する処理を分けた。
- 三つの経験から、「AIに作らせる前に非要件を決める」という判断の型を抜き出す。
一回の成功談を大きく見せるより、複数の小さな経験から同じ判断を見つけるほうが、私の発信には合っている。
この仕組みで、まだ解決していないこと#
ここまでの工夫で、YouTubeが続くことが証明されたわけではない。
記事を書くこと自体が目的になれば、動画を先送りする新しい理由になる。 調査と整理を続けても、実際に公開しなければ、発信の問題は解決しない。 再生数の多い題材を選んでも、私の経験として語れなければ、視聴者の信頼にはつながらない。
だから、今回作ったのは成功した運用ではなく、試せる状態である。
まずは記事を数本書く。 その中から一つを選び、質問に答え、台本へ変える。 台本ができたら、音声中心の短い動画として公開する。
そこで初めて、記事を先に積む方法が本当に動画制作の負担を減らすのか分かる。
続けるために、公開頻度を先に約束しない#
YouTubeを続けるために、毎週投稿すると決める方法もある。 私には、それがうまく働かなかった。
頻度を守ることが目的になると、内容よりも締め切りが気になる。 投稿できない週があると、活動全体を止めてしまう。
今は、記事、調査、質問、台本、動画という工程を分けている。 どこまで進んだかを残せば、撮影できない日にも前の工程を進められる。
続けるために必要なのは、毎回やる気を出すことではない。 やる気がない日にも、次の一手だけは残っている状態を作ることだと思う。
この方法も、これから試す。 記事が動画へつながるのか、調査が企画の判断に役立つのか、質問が私の台本を書く速さを活かせるのか。
結果が出たら、また記事にする。 うまくいかなかった場合も、どこで流れが止まったかを記録する。 その記録まで含めて、個人開発とAIを使った発信の素材にしていく。
