一言でまとめると

動画インタビュー編集の楽しさと苦しみ

ハイライト

• 初期読者から章立てについて有益なフィードバックをもらえた。
• インタビュー動画の編集には苦労したが、書き起こしの作成は楽しかった。
• フリーランスのブログ編集サービスを宣伝する計画が、予想以上にうまくいった。

目標の成績表

毎月のはじめに、その月に達成したい目標を立てています。結果は以下のとおりです。

これまで話したことのない読者20人にパーソナライズしたメールを送る

• 結果: 代わりに章に関するアンケートを実施することにした
• 評価: 対象外

数人の読者と話す中で、この段階ではすべての読者を対象にした広範なアンケートを実施する方がより良い戦略だと気づきました。

Refactoring Englishの新しい章を公開する

• 結果: 「Get to the Point」を公開した
• 評価: A

ようやく導入についての章を書き終えました。これまでで一番書くのが難しい章でした。というのも、導入は私自身が文章を書く中で最も苦手とする部分だからです。つまり、この章は導入についての章であると同時に、自分がどのように導入を書いているかをリバースエンジニアリングする試みでもありました。

この章には予算を大幅にオーバーしてしまいました。当初はわずか6時間で完成させる予定でしたが、結局19時間もかかりました。

残りのマーケティングタスクを完了する

• 結果: インタビューは編集し終えたが、CTA（行動喚起）は未着手
• 評価: B+

大きな未完了タスクだったインタビューの編集は終えました。ただ、本のウェブサイトのデザインを、無料メーリングリストへの登録ではなくアーリーアクセスの購入を促す形に修正する作業には、まだ手が回っていません。

Refactoring Englishの指標

先月は、本に関する指標は健全だと思っていました。人気の新規投稿がないにもかかわらず、ウェブサイトの訪問者数も収益も増加していたからです。

その後、指標用のグラフを追加したところ、違ったパターンが見えてきました。本の収益は、ウェブサイトへの訪問者数と密接に連動しているようです。7月には人気の投稿がなかったと思っていましたが、8月に本のウェブサイトに何も投稿しなかった途端、指標は急落しました。

ここから得た教訓は、やはりウェブサイトに新しいコンテンツを継続的に公開しなければ、新しい読者、特にお金を払って本を買ってくれる読者を見つけ続けることはできないということです。

章立てに関する読者フィードバックの解釈

読者との個別の会話では、どの章が役に立つと感じるかは人によって大きくばらついていました。そこで、読者が最も関心を持っている章を知るには、アンケートを取った方が良いと感じました。

以前メーリングリストでフィードバックを求めた際には数件しか返信がなかったので、今回も回答率は低いだろうと予想していました。しかし驚いたことに、読者はこのアンケートにははるかに積極的で、2週間で133件もの回答が集まりました。

回答の詳細な分析を本のウェブサイトで公開しています。

• 章立てに関する読者フィードバック

簡単にまとめると、有益なフィードバックが得られ、それをもとに章の順序を入れ替え、読者に不評だった章の切り口を変えることにしました。

過去のフィードバック依頼と比べて回答率が大きく違ったのも興味深い点でした。これまではサンプル章を送った後にフィードバックを求めていましたが、その違いは読者にお願いする作業量の差にあると思います。今回のアンケートは数分で終わりますが、章へのフィードバックとなると、30分かけて章を読んで考えなければならず、アンケートを受け取ったタイミングではその準備ができていないのかもしれません。

30分の動画インタビュー編集の意外な難しさ

2024年7月、ブログ講座であるHit the Front Page of Hacker Newsをリニューアルする一環として、Adam Gordon Bell氏とのインタビューを収録しました。結局、育児休暇に入る前に講座を完成させることができず、リニューアルは無期限に棚上げすることになりました。

そのせいで、このインタビューについては気まずい状況に置かれました。Adam氏はわざわざ時間を割いて協力してくれたのに、まったく公開しないのは申し訳ないと感じたのです。

Refactoring Englishのアーリーアクセスの提供を始めたとき、このインタビューを公開する良いタイミングだと思いました。インタビューを気に入ってくれた人が、本にも興味を持ってくれるかもしれないと考えたからです。

ずっと先延ばしにしているタスクで、「こんなに長く放置しているなんて馬鹿げている。腰を据えてやれば1時間で終わるのに、ずっと頭の中で抱え込んでいるだけだ」と思うようなものがありますよね。私はこのインタビューもきっとそうだろうと思っていました。

しかし、実際はそうではありませんでした。

音ズレという疫病の再来

インタビューの収録にはRiversideというサービスを使いました。通話後、Riversideは通話の両端それぞれの動画ファイルと、会話を統合して同期したバージョンを生成します。当時は動画が正常に動作することをざっと確認しただけで、じっくり見ることはしませんでした。

統合されたバージョンをそのままYouTubeにアップすれば終わりだと思っていました。もし中断や長い脱線があればカットするかもしれませんが、動画はほぼ完成しているはずだと考えていました。

収録から1年後、ようやく腰を据えて動画をじっくり見てみると、音声と映像がズレていることに気づきました。映像で口が動くよりも先に声が聞こえてくるのです。

まあ、問題ない。FFmpegで動画を再処理して音声を少しズラせばいいだろうと思いました。

ところが、そうはいきませんでした。会話の両端で音ズレの量が違っていたのです。Adam氏側は約425ms、私の側は約150msズレていました。つまり、元の統合前のそれぞれの動画に戻り、そこでズレを修正してから、自分で再び統合しなければならなかったのです。

使えるオープンソースの動画編集ソフトを探して

以前は動画編集といえばAdobe Premiereを定番として使っていましたが、昨年Linuxに乗り換えたため、Premiereは使えなくなりました。そもそも、もはや企業としてのAdobeにはうんざりしています。

そこで、昨年の夏から習得していた動画編集ソフトのShotcutで編集を始めました。Shotcutで動画を並べて表示する方法を理解するだけでも時間がかかりましたが、最終的にはズームとクロップのフィルターを組み合わせてなんとか形にしました。

Shotcutで編集していると、比較的新しいハイスペックなデスクトップを使っているにもかかわらず、2本の1080p動画を統合する処理に負けて再生がひどくカクつきました。そのため、実際の音声を確認するには動画を書き出すしかありませんでした。しかもShotcutは動画の一部だけを書き出す機能に対応していないため、毎回30分全体を書き出す必要があり、それだけで数時間かかっていました。余談ですが、後になってShotcutでは編集中の再生解像度を下げてパフォーマンスを向上させられることに気づきました。

書き出した後に気づいたのですが、クリップを分割するたびにShotcutが大きなポップノイズを挿入していました。分割した位置で実際に何もカットしなくても発生します。1つの連続したクリップを隣接する2つのクリップに分割しただけで、ポップノイズというアーティファクトが生じてしまうのです。

このポップノイズはShotcutの既知の問題だと知り、信じられませんでした。分割するたびに耳障りなノイズが入るようでは、誰がまともに動画編集できるというのでしょうか。しかし、多くのコメントではどの動画・音声編集ツールにも同じ問題があると言われていました。

はぁ！？

私は他のツールで何百ものメディアファイルを編集してきましたが、クリップを分割しただけでポップノイズが入ったことなど一度もありません。

Linux用の他のオープンソース動画編集ツールも試してみました。Kdenliveは編集を始めて数分でクラッシュしました。Flowbladeはまったく起動しませんでしたが、最終的に回避策を見つけました。FlowbladeはShotcutをよりシンプルにしたような印象だったので、Flowbladeで編集をやり直し、再び動画を並べて表示する方法を模索することになりました。

Flowbladeで1時間ほど編集した後、動画を書き出してみると、またしてもポップノイズが発生しました。Flowbladeにも同様のバグがあり、その説明はDan Dennedy氏の解説に基づくものでした。彼はなんとShotcutの作者です。そしてFlowbladeはShotcutと同じメディアフレームワークであるMLTの上に構築されているようでした。つまり、まったく同じバグに逆戻りしたわけです。

ともかく、この編集冒険譚はすでに長くて退屈なので、結論だけ先に言うと、最終的には動画の音声サンプリングレートを44.1 kHzから48 kHzに変換することでポップノイズを回避しました。これでアーティファクトは消えましたが、なぜそうなるのかはわかりません。

他にも動画編集中にたくさんのバグに遭遇しましたが、ここで語るにはあまりにも退屈なので省略します。

動画編集で得た教訓

• できる限りの前処理はFFmpegスクリプトで行う。
• 後で前処理を微調整する必要が生じた場合に備えて、FFmpegスクリプトは保存しておく。
  • もう前処理をやり直す必要はないと確信していても、スクリプトは保存しておく。できればバージョン管理下に。
• FFmpegスクリプトが意図どおりに動いているか、極端な値でテストして確認する。
  • 音ズレを200msズラして補正してみたが、まだズレたままだった。次に300ms、それでもズレ、400msでもダメ。最終的に2000msまで飛ばしてみて、200msの補正と2000msの補正がまったく同じに聞こえたことで、スクリプトにバグがあると気づいた。
• 適切な設定がわからないときは、FFmpegで複数のバージョンを生成するスクリプトを書き、選択肢を比較する。
  • 自分の側の会話から背景ノイズを除去するさまざまな手法を試すために、この方法を使った。
• 音声サンプリングレートが44.1 kHzだと編集時に問題が起きるらしい。
  • 前処理でレートを48 kHzに変換したらポップノイズは解消した。
  • 理由はまったくわからない。
• 編集の早い段階で動画を書き出して、最終的な出力を確認する。
• 動画・音声の編集フィルターはクリップ単位ではなくトラック単位で適用する。
  • 最初は1つの巨大なクリップだけでも、編集を始めれば独立したフィルター設定を持つ数十のクリップに分かれる。
  • フィルターの設定を間違えたと気づいたとき、すべてのクリップでやり直す羽目になる。

インタビューの書き起こしを楽しみすぎた話

Adam Gordon Bell氏との動画を編集し終えたら、それで終わりのはずですよね。あれだけ時間をかけて編集したのだから、早く公開して終わりにしたいと思うはずです。

ところが、そうはなりませんでした！

動画の編集が終わると、次は書き起こしにこだわり始める番でした。ただ、この作業は実際に楽しかったのです。

オンラインで目にするインタビューの書き起こしはどれも、デザイナーが「60年前のタイプライターで打たれた法廷の書き起こしを、そのままの楽しさとインタラクティブ性でウェブに持ってこよう」と考えたかのように感じます。

おいおい！ タイプライターではできないことを、ウェブでやってみようじゃないか。

そこで、whisper-ctranslate2で初期の書き起こしを生成し、それを正確で、インタラクティブで、読んでいて楽しいものにするために多くの時間を費やしました。

• 会話のそれぞれの話者は色分けされた吹き出しで表示されるので、誰が話しているかが一目でわかります。
• 各吹き出しには小さな再生ボタンのアイコンがあります。アイコンをクリックするとページが動画の位置までスクロールし、書き起こしのその箇所から再生が始まります。
• お気に入りの引用を抜き出してコールアウトとして配置しました。
• 議論の構造がわかるように見出しを追加しました。
• 書き起こしエラーを修正するためにテキストを確認しました。

金曜日にメーリングリストの登録者へ新しい章を送ったばかりなので、まだ動画は公開していません。今週末（2025-09-12）までに本のブログで公開される予定です。

Tyler Cipriani氏をHacker Newsの1位に押し上げる

計画が、期待以上にうまくいくこともあります。

実際の書き手にフィードバックをすることは本の執筆にも役立つので、他のインディー開発者ブロガー向けにフリーランスで編集の仕事をしています。編集サービスを紹介するページで編集サンプルを載せたかったのですが、有料クライアントの一人に、すでにお金を払ってもらった仕事を自分の宣伝に使わせてほしいと頼むのは気が引けました。

そこで、無料で投稿を編集させてもらう代わりに、編集ノートを公開し、編集者としてクレジットしてもらえる人を探すことにしました。

欲張った目標としては、その記事がHacker NewsやLobsters、redditといった、私の本の潜在的な読者が集まる場所で注目を集めることでした。読者が記事の最後まで読んで「Edited by Refactoring English」と目にすれば、「おっ、これは何だろう？」と思ってくれるかもしれません。

また、過去のクライアントを指して「この人は私に依頼し、その記事はあなたが成功したいと思っている場所で成果を出しました」と言えれば、将来のクライアントに対しても良いアピールになります。

数ヶ月前、Tyler Cipriani氏からブログの高レベルなレビューを依頼されました。彼は結果に満足してくれたようだったので、この無料編集のアイデアを持ちかけたところ、快諾してくれました。

私はTyler氏と彼の記事「The future of large files in Git is Git.」について数回にわたってフィードバックを行いました。一緒に作業するのは楽しく、本のための良いアイデアも得られました。

おまけの目標は、その投稿がHacker Newsのフロントページに載ることでしたが、結果はそれを上回り、Hacker Newsで1位、Lobstersやredditでも1位を獲得しました。

二人にとって最大の学びの一つは、文章をターゲット読者に合わせることの重要性でした。Tyler氏の記事の初期のドラフトでは、読者が大容量ファイルを管理するためのGit拡張であるGit LFSに精通していることを前提としていました。

私は、平均的なGitユーザーは記事の内容をすべて理解できるほどGit LFSをよく知っているわけではないと指摘しました。Tyler氏は、大容量ファイルを扱ったことのある平均的なGitユーザーならGit LFSを知っているはずだと感じ、反論してきました。

読者が彼の記事が想定しているほどGit LFSを知らないことを納得してもらうために、私自身のGit LFSに関する知識と経験をリストアップしました。

• gitリポジトリに大きなファイルがある場合や、バイナリデータを頻繁に更新する場合は、git LFSを使うべきだとされている
• 私はgit LFSを使ったことがない
  • Git LFSを使っているオープンソースプロジェクトに1〜2件関わったことはあるかもしれないが、LFSの部分には一切触れていない
• 各種forge（ホスティングサービス）のサイズ制限が何なのかは知らないが、上限に達したらforge側から警告が来るだろうし、そのときに対処すればいいと思っている
  • gitリポジトリに5MBを超えるファイルを置きたいと思ったら、なんとか回避する方法を探し始める
• Git LFSはどのforgeでも使える、forgeに依存しない機能だと思っていた
• Git LFSは10年以上の歴史を持つ、成熟して安定した技術だと思っていた
• 一度使い始めたらリポジトリがGit LFSに縛られるということを知らなかった
• gitで大容量ファイルを保存する方法には興味があるし、HNやLobstersでその話題を見かけたらクリックするだろうが、gitリポジトリにどうしても大容量ファイルを置きたいという状況に直面しない限り、自分から積極的に考えて解決しようとする問題ではない

Tyler氏は、このリストが自分にとって「なるほど」という瞬間だったと言いました。それまでは読者がGit LFSを知っているという確信からフィードバックに抵抗があったのですが、私のリストを見て、読者が表面的にはGit LFSやその用途を知っていたとしても、仕組みまでは知らないかもしれないと気づいたのです。

Tyler氏の気づきで面白かったのは、私のリストを彼自身でも書けたはずだということです。彼はターゲット読者が何を知っているかについて同じ予測を持っていましたが、読者が技術を「知っている」とはどういうことかを、もう一歩深く考える必要があったのです。

サイドプロジェクト

Hacker News Observerを時系列データベースに移行して500倍高速化

ここ数年、「時系列データベース」という言葉を耳にしてきましたが、それが何をするものなのか、通常のリレーショナルデータベースとどう違うのかが理解できていませんでした。昨年もGrafanaと互換性のあるものが必要で、サイドプロジェクトでInfluxDBを使ったことさえあります。それでも、なぜそれが「時系列」データベースなのか、なぜ単にSQLiteではダメなのかがわからないままでした。

最近、別の開発者と話していたとき、彼がデータの異なるビュー、例えば秒単位の粒度と日単位の粒度のために時系列データベースを使っていると言いました。それ以上の説明はなかったのですが、私の中で電球がパッと灯り、「ああ！ 時系列データベースってそういうためのものなのか！」と思ったのです。

Hacker News Observerは、Hacker Newsを毎分クエリし、過去数週間のすべてのストーリーのupvote数、コメント数、ランクを記録するサイドプロジェクトです。いずれはもっと深く掘り下げて面白いパターンを見つけたいと思っていますが、今のところはフロントページの合計upvote数やコメント数のような高レベルな集計を見ているだけです。

当初はデータベースにSQLiteを使っていて、上のグラフの描画には2分かかっていました。1日に何千ものストーリーがあり、各ストーリーに何千ものスナップショットがあり、さらに各スナップショットから上位30件（フロントページ）を抽出し、それを時間ごとのバケットにまとめなければならないことを考えれば、それも当然です。SQLiteには毎分のデータを時間単位のビューに集計するための特別な機能がないため、非常にコストの高いクエリが大量に発生していました。

時系列データベースのイメージがつかめたので、SQLiteに似た時系列データベースの選択肢をLLMに尋ねたところ、DuckDBを勧められました。そしてLLMにデータベースをSQLiteからDuckDBへ移行させました。その移行だけで、グラフの読み込み時間は2分から250ミリ秒に短縮され、約500倍の高速化になりました。

なるほど、これが時系列データベースの使い道ということなのでしょう。

Gleam Chat Log Parserで古いログを少しずつ処理

チャットログパーサーのプロジェクトは少ししか進みませんでした。離席メッセージを含むログや、Windowsスタイルの改行（\r\n）を含むログに対応しました。奇妙なことに、Erlang（そしてGleamでも）では\r\nが1文字としてカウントされるため、しばらくハマってしまいました。

まとめ

何ができたか？

• Refactoring Englishの「Get to the Point」の章を公開した。
• 「Give Your Spouse the Gift of a Couple’s Email Domain」を公開した
• コマンドラインからAirGradientの大気質モニターをフラッシュするチュートリアルを公開した。
• 「Reader Feedback about my Chapter List」を公開した
• 日中の集中を守るためにLeechBlock NGの使用を再開した。
  • 今回はうまく機能している！ メモリリークにも悩まされておらず、仕事中にSNSへ流れてしまうのを防いでくれている。

学んだこと

• 動画編集ではより規律正しく進める
• インタビュー動画の編集は退屈だが、書き起こしの編集やスタイリングは楽しい。
• 30分かかる作業より数分で済む作業の方が、1桁多くフィードバックしてくれる。

来月の目標

• Refactoring Englishのウェブサイトに新しい読者を引きつける何かを公開する。
• Refactoring Englishの新しい章を公開する。
• これまで話したことのない読者20人にパーソナライズしたメールを送る。