Educational Products: Month 2

2024-08-07

Michael Lynch

教育プロダクト：2ヶ月目

一言サマリー

動画収録のワークフローを改善しました。

ハイライト

コース用の動画収録を楽にするテクニックをいくつか学びました。
Merchant of Recordサービスは使わなくてよいと判断しました。
Webアプリケーション制作の定番ツールとしてhtmxを取り入れました。

目標の達成度

毎月のはじめに、その月に達成したいことを宣言しています。目標に対してどれだけできたか振り返ります。

コースから4レッスン分の公開可能な収録を終える

結果：1レッスンの大部分を収録しました
評価：D

動画収録にどれだけ時間がかかるか、すっかり忘れていました。しかも、収録以外の作業量も甘く見積もっていました。ほとんどの週で収録の時間をまったく取れませんでしたが、ようやく収録のリズムをつかめてきました。

1時間収録して使える映像は5〜10分程度で、90〜120分も収録するとへとへとになります。集中できた週には45分のレッスンを1本まるまる収録できました。ライブコースの講義が終わったので、これからはもう少しペースを上げられそうです。

新バージョンのコースの販売を開始する

結果：部分的なコースを販売する代わりにウェイトリストを実施しました
評価：評価なし

新コースの販売は見送ることにしました。当初は、新バージョンを早期アクセスとして割引価格で提供しつつ、完成するまでは2020年収録の旧版を提供するつもりでした。しかし、この形をきれいにパッケージするのが難しいと気づきました。

妻の出産までにコースを完成させられない可能性もありますし、子どもが生まれたら数ヶ月は育休を取る予定です。育休中に「購入済みの残りの教材を届けなければならない」というプレッシャーを感じたくありません。そこで、事前予約の代わりにウェイトリストを用意することにしました。

動画収録の改善

コース用の動画を収録する際、収録を中断させたり、そもそも収録を始められなくしたりする要因がたくさんあります。収録をより素早く始められるように、そして中断されにくくなるように、収録までの摩擦を減らす取り組みを進めてきました。

卓上三脚を導入する

動画収録にはRazer Kiyoというウェブカメラを使っていて、普段はモニターの上に載せています。問題は、カメラをちょうどよい高さに合わせるのに手間がかかることです。

普段、デスクトップモニターの中央がだいたい目線の高さに来るようにしています。そうすると、モニターの上に載せたウェブカメラは、どうしても私を見下ろすアングルになってしまいます。

ちょうどよいアングルを得るために、モニターアームや机の高さを調整して、カメラが目線の高さに来るようにしていました。しかし、そのたびにモニターを動かすのは収録までの摩擦が大きく、しかも毎回まったく同じカメラ位置を再現することができませんでした。

この問題は、小さな卓上三脚であるSmallRig VT-20で解決しました。

収録中は、自分とモニターの間に三脚を置いています。机の上で脚が来る位置にマスキングテープで印を付けて、毎回同じ位置を再現できるようにしています。

三脚があるおかげで、収録したいときは机の上に三脚とカメラを置くだけで、一瞬で正しい位置が決まります。摩擦を減らすという意味で大きな前進ですし、毎回あれこれ高さをいじることなく、普段のデスク環境のまま収録できるのも快適です。

唯一の欠点は、三脚がスライドの視界を少し遮ることですが、収録する頃にはスライドの内容を覚えているので問題ありません。

ウェブカメラをモニターの上に載せた場合（左）と、モニターの前の卓上三脚に載せた場合（右）の比較。三脚を使うとカメラに直接視線を向けやすくなります。

収録機材をつなぎっぱなしにする

以前は、収録と収録の間にウェブカメラを引き出しにしまい、マイクとアームは別の部屋に置いていました。そのため、収録のたびに最初の5分は機材を集めて机にセッティングするだけで終わっていました。

今は、できるだけ機材をつないだまま、すぐに収録できる状態にしています。マイクは机の上に接続したまま置いておき、ウェブカメラも三脚に取り付けたまま、すぐに机に置けるようにしています。

チャプター単位で収録する

コースのリサーチの一環として、Aaron Francis氏の動画講座（screencasting course）を視聴しました。彼の講座はライブコーディングが中心ですが、私のコースにも応用できる内容が十分にあり、購入する価値がありました。

Aaron氏の講座自体も役に立ちましたが、最も学びになったことの中には、彼が言葉として語ったことではなく、講座のパッケージの仕方から得たものもありました。

私のコースの初版は、30〜60分のレッスンが7本という構成でした。Aaron氏のレッスンも1本あたりの長さは同じくらいですが、彼は各レッスンを数分程度の短いチャプターに分割しています。

Aaron Francis氏は自身のレッスンを短いチャプターに分割しており、各チャプターは数分程度です。

受講生の立場から見ても、短いチャプター形式は気になる部分だけをつまみ見できるので気に入っています。

作り手としても、40分の大きな動画を1本作るより、4分の動画を10本収録・編集する方がずっと楽です。また、40分の動画を半分編集した状態で抱えるより、5本のチャプターが100％完成している方が気持ちの上でもずっと前向きでいられます。

レッスンを順序に依存しない作りにする

2020年にコースを収録したときは、どの動画も「パート2、Hacker Newsを理解するへようこそ」といった形で始め、「次の動画では、書くテーマの選び方について話します」で締めていました。

新しい収録ではレッスンをチャプターに分けたことで、当然ながら動画の本数が増えました。編集の段階で順番を入れ替えたり動画を削除したりすると、番号や関連付けを正しく保つためにイントロやアウトロを大量に撮り直すことになります。

Aaron Francis氏の講座を見て、彼は動画の中で順序を一切示していないことに気づきました。そこで私も、動画からレッスン番号をなくし、順序に言及しないことにしました。別のレッスンにある内容に触れるときは、「後の動画で」とは言わず、「詳しくはFooの動画で話しています」という言い方にしています。

同じシャツを3枚買う

Aaron Francis氏の講座で紹介されていたコツの一つに、すべてのレッスンで見た目を一貫させるというものがあります。彼はすべての動画で無地の黒いTシャツを着ていて、いい工夫だなと思いました。

当初は、収録のたびに着替えるためのシャツを1枚用意し、収録が終わったら脱ぐようにしていました。普段シャツを着るときは、寝る前に洗濯に出すまで約14時間着ているので、同じシャツで1時間の収録を14回くらいはできるはずだと考えていました。

しかし、シャツの臭いに関する私の想定は間違っていました。わずか3回の収録で、シャツがなんだか気持ち悪く感じられるようになったのです。

そこで、同じシャツを3枚買うことにしました。

普段着ているのと同じ、シンプルなネイビーのBonobosのTシャツです。3枚あれば、2枚を洗濯に出していても少なくとも1枚は手元に残るはずです。

ライブコースで生まれたマジックモーメント

ブログ講座のライブ版は全6回の講義を終えました。教えること自体とても楽しかったのですが、特に印象に残った瞬間が2つあります。

ゲストスピーカーを招く

コースの第1回講義の準備をしていたとき、Adam Gordon Bell氏がTwitterで勤め先からレイオフされたと発表しているのを見かけました。Adam氏は、私のお気に入りのソフトウェアポッドキャストの一つであるCoRecursiveのホストです。彼自身ブロガーでもあり、前職では最も人気のあったブログ記事を手がけていました。

Adam氏は2020年に同じコースを教えたときのパイロット受講生の一人でした。急に予定が空いたと知り、特別ゲストとしてQ&Aに参加しないかと声をかけたところ、快く引き受けてくれて翌週参加してくれることになりました。

タイミングが驚くほど絶妙でした。彼が私のコース「Hit the Front Page of Hacker News」のビデオ通話に参加したまさにそのとき、Adam氏はPowerShellの主任アーキテクトであるJeffrey Snover氏へのインタビューでHacker Newsの1位を獲得したばかりだったのです。

個人的にも、Adam氏の文章をたくさん読んできたので、舞台裏をのぞくように彼のアプローチや、年を重ねる中でどう調整してきたかを聞けたのはとても面白かったです。

受講生からも、はっきりとした熱気を感じました。正直、この盛り上がりには驚きました。まだ2回目の授業だったので、「やっと気分転換だ」といった雰囲気ではなかったはずです。私なりの解釈では、受講生はみな私のことは知っていましたが、Adam氏のことは知らない人もいたため、実績のある別の人がコースの概念を自身の視点で語るのが新鮮に映ったのだと思います。

実際の投稿のライブ解剖

コースの途中で、受講生が自分の文章を共有し、私たちがフィードバックする演習ができないかという要望がありました。3名の受講生が記事や下書きを共有してくれて、私たちが講評したところ、もっとやってほしいという声が上がりました。

次の授業では希望者を募りましたが、共有できるものを用意している人はいませんでした。そこで、Hacker Newsを開いて記事を1本選び、その長所と短所を分解してみることにしました。それ自体は楽しかったのですが、選んだのはフロントページの記事だったため、すでに成功しているものばかりでした。そこでクラスからは、まだ結果の分からない新着投稿を選んでみてはどうかという提案がありました。

新着投稿の講評を始めてから、授業が本当に生き生きとしてきました。成功した投稿を見て「なぜうまくいったか」を後付けで説明するのは簡単ですが、結果が分からない投稿を見てパフォーマンスを予測する方がずっと難しいからです。しかも、見知らぬ人の投稿を非公開の場で扱うので、著者を傷つける心配や、細かすぎる指摘をためらう必要もなく、思ったことを率直に言えました。

新着投稿を読み上げるようになってから、クラスの反応も増え、より引き込まれている様子でした。コース中にはネガティブな例もいくつか見せていましたが、つまらない導入や構成の悪さといった理由で、人がリアルタイムに記事への興味を失っていく様子を目の当たりにするのは興味深かったのだと思います。

このマジックモーメントをどう活かすか

授業でのマジックモーメントがあるたびに、どうすればこうした瞬間をもっと増やし、最終的なコースに組み込めるかを考えました。

ライブのグループQ&Aを再現可能にするのは、8人の持ち回りサイドキックを抱えたYouTubeチャンネルでも作らない限り難しいでしょう。ただ、それに近い形として、私の好きな書き手への1対1のビデオインタビューなら十分実現可能だと思います。

専門家へのインタビューは、偶然ではなく、Aaron Francis氏が自身のコースを宣伝するために使っている手法でもあります。

Aaron Francis氏は、SQLiteに関する今後のコースへの関心を高めるため、SQLite分野の専門家とのロングインタビューを公開しています。

一方、ライブ解剖の方は簡単に再現できます。今すぐカメラを回して、Hacker Newsの投稿を読みながら頭に浮かんだことをそのまま収録すればよいのです。それが面白いものになるかは分かりませんが、すぐに手軽に試せるアイデアではあります。

Merchant of Recordは詐欺なのか？

先週、Merchant of Recordに対応している数少ない決済プロセッサの一つであるLemonSqueezyが、Stripeに買収されたと発表しました。そのHacker Newsのスレッドで、あるコメントが目に留まりました。

MoRを利用すること自体、余計な手数料を払わせるための恐怖を煽る手段だと思う
SaaSの99％は、MoRを正当化できるだけのMRRに到達しない
7桁のMRRを突破した1％は、税金の納付管理のために社内で人を雇えばよく、MoRのブランドが入った請求書で顧客を混乱させる必要もない

会計士に確認したところ、ほとんどの米国の州で、デジタル商品に対して売上税が発生する最低ラインは、州にもよりますが年間で約10万ドルか100件の取引程度だということでした。

カリフォルニアやニューヨークのような人口の多い州では、最低ラインは50万ドルです。もし多くの州で下限を超えて売上税の支払いが面倒になるほど売れるようになったら、そのときは売上として得ている数十万ドルで会計士を雇えばよいのです。

私はMerchant of Recordの機能を目当てに、Gumroadで販売する予定でした。しかしGumroadは10％の手数料を取り、しかもそれとは別に決済手数料もかかります。

マサチューセッツ州という自分の拠点以外の州で売上税の基準を超える可能性は極めて低いことを考えると、Gumroad以外でコースを販売して10％を節約できるということになります。

サイドプロジェクト

htmxフォームで自分好みのパターンを見つける

前回の振り返りで、htmxを使い始めて気に入っているものの、エラー処理がぎこちないと感じていることを書きました。

例として、私が作っている映画レビュー用WebアプリScreenJournalにあるフォームを紹介します。

ユーザーがフォームを送信すると、結果は次の2つしかありません。

設定が正常に保存された。
リクエストの処理中にエラーが発生した。

htmxの慣用的なやり方では、ユーザーがフォームを送信すると、サーバーがフォーム全体のHTMLを返します。その中にはユーザーが送信した値が再入力された状態で、成功またはエラーのメッセージが追加されています。

私は、htmxが推奨するフォームのパターンはぎこちなく、バグを招きやすいと感じています。ブラウザ側ではすでにフォームが正しく入力されているのに、なぜサーバーが全体を返して再描画させる必要があるのでしょうか。新たに必要な情報は成功メッセージかエラーメッセージだけなのですから、それだけを送ればよいのではないでしょうか。

そこで、htmxの機能をより軽量に使うために、上記のScreenJournalのフォームに適用した私なりのアレンジを紹介します。

<form
  hx-put="/account/notifications"
  hx-clear="#result-success, #result-error"
  hx-disabled-elt="input, .btn"
  hx-target="#result-success"
  hx-target-error="#result-error"
  hx-swap="textContent"
>
  <label for="new-reviews-checkbox">
    Email me when users post reviews
  </label>
 <input
    type="checkbox"
    id="new-reviews-checkbox"
    name="new-reviews"
  />

  <label for="all-comments-checkbox">
    Email me when users add comments
  </label>
  <input
    type="checkbox"
    id="all-comments-checkbox"
    name="all-comments"
  />

  <button value="Save">Save</button>

  <div role="status">
    <span>Loading...</span>
  </div>
</form>
<div id="result-success" role="alert"></div>
<div id="result-error" role="alert"></div>

大事な処理は<form>タグに集約されているので、一つずつ説明します。

hx-put="/account/notifications"

ユーザーがフォームを送信すると、サーバー上の/account/notificationsルートへHTTP PUTリクエストを送ります。

hx-clear="#result-success, #result-error"

ユーザーがフォームを送信したときに、IDがresult-successまたはresult-errorの要素の中身をクリアします。

この属性はhtmx本体のものではなく、私が自作したclear-before-sendというカスタム拡張のものです。CSSルールの.alert:empty { display: none }と組み合わせて、alertクラスを持つ<div>が空のときは非表示にするようにしています。

hx-disabled-elt="input, .btn"

HTTPリクエストの間、すべての<input>タグと.btnクラスを持つ要素を無効化し、ユーザーが同じリクエストを二重送信できないようにします。

補足ですが、htmxのドキュメントではhx-disabled-elt="this"でフォーム全体が無効化されるように読めますが、実際にはうまく動きませんでした。そのため、回避策としてフォーム内のすべての入力欄にマッチするセレクタを使っています。

hx-target="#result-success"

サーバーが200番台のステータスコードで応答した場合、レスポンスの本文をIDがresult-successの要素に入れます。

hx-target-error="#result-error"

サーバーが200番台以外のステータスコードで応答した場合、レスポンスの本文をIDがresult-errorの要素に入れます。

この属性はhtmxのコアライブラリではなく、response-targetsというhtmx拡張のものです。

hx-swap="textContent"

hx-targetやhx-target-errorのターゲットに内容を入れるとき、htmxは内部／外部HTMLの置換ではなく、ターゲット要素のtextContentを置き換えるようにします。

実際の動きは次のとおりです。開発サーバーを調整して2秒待ってから応答するようにし、1回おきにエラーメッセージで失敗するようにしています。

ScreenJournalの通知管理画面です

注目してほしい点は次のとおりです。

リクエストが実行中の間、htmxがフォームを無効化すること。
ユーザーが再度「Save」をクリックした瞬間に、前の成功／エラーメッセージが消えること。
成功メッセージとエラーメッセージでスタイルが異なること。

このように、フォームごとにカスタムJavaScriptを書かなくても、かなりの機能を実現できています。本来はこうしたありふれた機能のためにサードパーティのライブラリを必要とせず、HTML自体がこう進化してくれていればよかったのにと思いますが、htmxがその隙間を埋めてくれているのは嬉しいことです。

まとめ

今月やったこと

このブログを通じてIs It Ketoを2,000ドルで売却しました。
ブログに関するライブコースの講義を完了しました。
初めてのhtmx拡張を作成しました。
コース用のマーケティングツール「Personal Best」を作成しました。

学んだこと

動画収録のプロセスから摩擦を取り除く機会を探すこと。
才能あるブロガーへのインタビューやブログ投稿の解剖を公開することでコースを宣伝できること。
米国の多くのインディー創業者はおそらくMerchant of Recordを必要としないこと。

来月の目標

コースの収録を完了する。
コースの販売を開始する。