Educational Products: Month 2

Michael Lynch

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

原文は Michael Lynch により に公開されました。 このブログを購読する

一言サマリー

動画収録のワークフローを改善する

ハイライト

  • コース動画の収録を楽にするテクニックをいくつか学んだ。
  • Merchant of Recordサービスは不要だと判断した。
  • htmxをウェブアプリケーション開発の標準ツールキットに組み込んだ。

目標の達成度

毎月のはじめに、その月に達成したいことを宣言している。結果は次のとおりだ。

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

  • 結果: 1レッスンの大部分を収録
  • 評価: D

動画収録にどれだけ時間がかかるかすっかり忘れていた!収録以外の作業量も過小評価していた。ほとんどの週は収録する時間がまったく取れなかったが、今はようやくリズムをつかんできた。

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

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

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

妻の出産までにコースを完成させられない可能性もあるし、赤ちゃんが生まれたら数か月は育休を取りたい。休暇中に「残りの教材を届けなければ」という負い目を感じたくないので、予約販売の代わりにウェイティングリストを用意することにした。

動画収録の改善

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

卓上三脚を導入する

動画収録には、モニターの上に置いているRazer Kiyoのウェブカメラを使っている。問題は、カメラを適切な高さに合わせるのに手間がかかることだった。

収録にはRazer Kiyoのウェブカメラを使っている。

普段はデスクトップモニターの中心がだいたい目の高さに来るようにしている。しかしモニターが目の高さにある状態で、その上にウェブカメラを置くと、カメラは私を上から見下ろすアングルになってしまう。

良いアングルを得るために、モニターアームや机の高さを調整してカメラを目の高さに合わせていた。しかし、そのたびにモニターを動かすのは収録の大きな摩擦になっていたし、収録ごとにまったく同じカメラ位置を再現することもできなかった。

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

収録を始めるたびに机やモニターを動かさなくて済むよう、卓上三脚を購入した。

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

三脚があるおかげで、収録したいときは机の上に三脚とカメラをポンと置くだけで、すぐに正しい位置にセットできる。摩擦の削減という点で大きな収穫だったし、毎回あれこれ高さをいじらずに普段のデスク環境のまま収録できるのも快適だ。

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

ウェブカメラをモニター上部に設置した場合(左)と、モニター前面の卓上三脚に設置した場合(右)。三脚の方がカメラを直接見やすくなる。

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

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

今はできるだけ多くの機材をつなぎっぱなしにして、すぐに収録できる状態にしている。マイクは接続したまま机の上に置き、ウェブカメラも三脚にセットしたままにして、すぐに机に置けるようにしている。

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

コースのリサーチの一環として、Aaron Francis氏のスクリーンキャスト講座を視聴した。彼の講座はライブコーディングが中心だが、自分のコースにも応用できる内容が十分にあり、買う価値はあった。

Aaron氏の講座自体も役に立ったが、最もためになった学びのいくつかは、彼が口にしたことではなく、彼がコースをどうパッケージ化しているかを見たことから得られたものだった。

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

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枚買うことにした。

映像の一貫性を保つため、同じTシャツを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があること自体、追加の取引手数料を払わせるための恐怖を煽る手法だと感じている

99%のSaaSはMoRを正当化するのに必要なMRRに到達しない

7桁のMRRを突破した残り1%は、税金の納付を管理するために社内で人を雇えばいいだけだし、MoRのブランドが入った請求書で顧客を混乱させる必要もない

会計士に確認したところ、ほとんどの州では、デジタル商品で売上税が発生する最低閾値は州によって年間約10万ドルまたは100件の取引だという。

カリフォルニアやニューヨークのような人口の多い州では、最低ラインは50万ドルだ。もし十分な数の州で閾値を超えて売上税の支払いが面倒になるような段階に達したとしても、そのときには売上から得た数十万ドルで会計士を雇えばいい。

これまではMerchant of Record機能を目当てにGumroadでの販売を考えていた。しかしGumroadは10%の手数料を取り、しかもそれに決済手数料は含まれていない。

地元であるマサチューセッツ州以外で売上税の閾値に達する可能性が極めて低いことを考えると、Gumroad以外でコースを販売して10%を節約できるということだ。

サイドプロジェクト

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

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

例として、私の映画レビュー用ウェブアプリScreenJournalにあるフォームを見てみよう。

ScreenJournalウェブアプリにあるシンプルなHTMLフォーム。

ユーザーがフォームを送信すると、結果は2つしかない。

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

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

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

htmxの機能をより軽量にするために、上のScreenJournalのフォームに適用した私なりに少し調整したhtmxパターンがこちらだ。

<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というCSSクラスを持つ要素を無効化し、ユーザーが同じリクエストを二重送信できないようにする。

余談だが、htmxのドキュメントではhx-disabled-elt="this"でフォーム全体を無効化できるように読めるが、どうも動作しない。回避策として、フォーム内のすべてのinputにマッチするセレクタを使わざるを得なかった。

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-targethx-target-errorのターゲットを埋める際に、(inner HTMLやouter HTMLを置き換えるのではなく)ターゲット要素のtextContentを置き換えるようにhtmxに指示する。

結果は次のとおりだ。開発サーバーを調整して、応答まで2秒待つようにし、1回おきにエラーメッセージで失敗するようにしてある。

ScreenJournalの通知管理画面

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

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

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

まとめ

何ができたか?

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

学んだこと

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

来月の目標

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

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント