コミットメッセージをClaudeに書かせるgit aicommit
そういうコマンドがあるわけではありません。
以下のような git alias を .gitconfig に設定すると git aicommit で Claude にコミットメッセージを書かせられるというだけです。
[alias]
aicommit = "!f() { COMMITMSG=$(claude -p 'Generate ONLY a one-line Git commit message in English, using imperative mood, summarizing what was changed and why, based strictly on the contents of `git diff --cached`. Do not add explanation or a body. Output only the commit summary line.'); git commit -m \"$COMMITMSG\" -e; }; f"
Claude が考えたメッセージが入った状態でエディタが上がってくるので、人間が加筆とか修正とかしてコミットするといいと思います。
Vibe Codingと人間の成長あるいは単に最近思ったこと
まずはじめに、あまり有益なことが書いてある種類の文章ではない。時間が惜しい境遇の人はこれを読むのを後回しにすべきだろう。書きたくて書いており、読ませるためには書いていない。
タイトルに Vibe Coding ないしは AI っぽい語句を並べた記事を書くこと自体に若干の抵抗感というか、後ろめたさというか、欲に抗えない自分への自己嫌悪感のようなものがあるのだが、まぁでもみなさんもタイトルに釣られて記事を開いたでしょ、ということでバーボン。
今回は、Vibe Coding で生産性が上がったとかできることが増えたとか、効率化のためにやっていることは何かとか、そういう話ではない。やっていることは特に変わりないのだが、Coding Agent という道具と向き合うことで既にあるものの捉え方が変わった、そういう話をしたい。実際のところ、私はあまり Coding Agent を活用できていない。仕事では多少使わないともはや職務怠慢だなと思って利用を試みているが、趣味では Copilot による補完すら使わないことも多いくらいである。
さて、Coding Agent によってソフトウェア開発の比較的簡単なタスクは既に人間のものではなくなり、ジュニアエンジニアがステップアップするための仕事が奪われる、あるいは既に奪われているのではないかと考えたことがある。当時はそれを単に悲観的に捉えていて、これからのソフトウェアエンジニアの成長機会はいったいどこからやってくるのだろうと未来を憂えていた。
私は新卒で入った会社で（もう8年も前か……）様々なコードに出会った。当時自分に飯を食わせてくれていた*1コードを悪く言いたくはないのだが、まぁいろんな背景と経緯を持ち、その時点で見ればまったく適切でないような、そういったコードに溢れていた。しかしそれらは新人の私にとっては悪いことばかりではなく、どういったコードを書くと何が起こるのかという因果を否が応でも知らしめてくれるよい教材であった。自分で書かずとも因果のカタログがそこにある、価値はつまりそこである。
ひとりだけで書いていると、因果のパターンをそう多くは学べない。書き手がひとりだとパターンが偏るからというのもあるが、いかんせん足りていないのは試行回数の方である。ひとりでできる試行回数はたかが知れているし、そもそもジュニアなエンジニアのコーディング速度は十分に遅いのである。新卒当時で既にプログラミング歴自体は20年弱ほどあった私であるが、そういった事情でソフトウェア設計に活かせるほどの見識はまるでなかった。設計と聞いてあのタマネギのような図に行き当たることしかできないくらいの、そういう未熟さである（これは比喩だけど）。
ところで LLM のコーディング速度は極めて速い。最終的な成果物にたどり着くまでの時間でいえば私の人力とまだ大差無いという負け惜しみはありつつ、生成1回あたりの時間はとても短い。一方である程度の試行錯誤が必要であり、一発で完璧な生成物が出てくることは稀である。2025年現在、どうにかこの往復回数を減らし、ターンキーで最終成果物が得られるようにと多くの人類が四苦八苦している。しかし翻ってみるとこれはよいことである。プロンプトという「因」を与え、極めて高速に中途半端な「果」が得られる。これこそがジュニアエンジニアの成長に寄与するものであり、post-LLM era の学習方法に他ならない。ふと客観的に見てみるとあまり特別なことは言っていない。既に現代のジュニアエンジニアはそのようにしてソフトウェア設計に活かせる見識を（自覚の有無に関わらず）ジワジワ溜めているのだろう。単に AI に疎い旧世代の人間が遠回りをして当たり前の見方に到達しただけである。読者の時間を浪費できて私は嬉しい。
みなさんの予想に反して（？）私は新しいモノへの適応が遅い方であるので、Coding Agent についても時間をかけてゆっくり適応していくのだと思う。思い返してみると、私が素の JavaScript を捨てて TypeScript に乗り換えたのは TypeScript 2.0 がリリースされてからのことだった。そのときついでにメインのエディタも VS Code に乗り換えたのだが、それまでは Emacs をメインで使っていた。Emacs と js2-mode を使えば十分に JavaScript を書けていた、あるいは書けていると勘違いしていた。TypeScript に乗り換えてからはより速くより良いコードが書けるように……というわけでもなく、書くコードの雰囲気が変わった。素の JavaScript を堅牢に書くためにはメタプロを駆使して EDSL を定義し、その EDSL を用いてロジックを小さく書くというのが基本の戦略だった。ロジックをベタでダラダラと書いていると一貫性を保ちづらいので、ある種のルールを enforce するために EDSL を定義してその範囲内で実装するというのが当然のテクニックだったように思う。オレオレフレームワークみたいなものなので初めて読む人にとっては最悪であり、これは主に書く人向けの仕組みである。TypeScript を書くようになってからはそういったことはあまりやらなくなった。EDSL というアイデア自体が無益だというわけではないが、それを型検査の代替とすることは不要になったのである。EDSL には、EDSL の価値がもっとちゃんと活きる使い方がある。
これもまた多くの人が言っており既に苔むした主張であるのだが、Coding Agent によるソフトウェア開発は今までの開発体験の延長線上ではなく、ちょっと別のパラレルワールドの開発体験としての発展をしていると思う。言ってしまえば従来の開発効率の改善手法、抽象化・再利用・なんちゃらかんちゃら、というのは人間がコードを書くことを前提にしたアイデアであって、型検査のない JavaScript で一貫性のあるコードを書くために ESDL を導入することと同様に局所解だった可能性がある。Coding Agent によるソフトウェア開発はその局所解から脱出し、新たな勾配を降る助けになるだろう。
「AI はゲームチェンジャーだから」というエクスキューズにかこつけて、今まで大切だと説いていたことをある日突然ポンと投げ捨てて別のことを言う、そういう都合のいいアンラーンをこれからも続けていきたい。
*1:多くの日本人に飯を食わせていたプロダクトの可能性もある
総括2024
年末。KOBA789 です。
南米出張から戻ったあとちっとも時差ボケが治らず、自律神経を単振動させていたらもう年が明けそうです。それに限らず本年もさまざまなことがありました。
2023はこちら: diary.hatenablog.jp
年初
1月。2024年は配信2連チャンで幕を開けました。いずれも好評で、というか宮乃やみさんとやらせてもらったRust の所有権とライフタイムを解説する方はやたらと好評で、アーカイブについたコメントの数に驚いたりしました。まったくありがたいことです。結局2024年の YouTuber 活動は年始のこれがピークになってしまいましたが。
仕事の方では、念願のデータ利活用でビジネスすっぞという部が立ち上がり、そこへ異動となりました。私は個人のお金を稼ぐことにあまり興味はありませんが、お金をいただけるような価値を事業で創造するのは、稼いだお金でより大きなことができるようになっていくので大好きです。というわけで、よりビジネス寄りの所属への異動を希望していたのでした。が、そんなにスッと仕事の引き継ぎができるわけもなく、同僚のサポートも得ながら3ヶ月くらいかけて異動した気がします。このとき、某氏の「南米とか興味ある？」という言葉に曖昧に肯定的な返事をしたことが、私の2024年の動向を決定づけることになります。
それまで組込み Rust を書くことが多かった仕事とはうってかわって、異動先ではウェブフロントの TypeScript を書いたり Terraform HCL を書いたりといった感じで技術的にはどこか懐かしさがありました。まぁそれぞれを書く分量の割合が逆転したというだけで、それまで TypeScript を全然書いていなかったわけでも、それ以降組込み Rust を書かなくなったわけでもないんですが。
3月にはスペースワンのカイロス1号の打ち上げ……とは関係なく、打ち上げ予定の前の週に串本に遊びに行きました。単に本州最南端を取りたかったというだけですね。青森やら鹿児島やらで長距離運転に慣れてしまった私としては土日で行くには近すぎました。現地で時間が余り気味になってしまったので、和歌山の内陸側の地図をもう少し読み込んでおくべきだったと後悔しています。本命の本州最南端の碑はあんまり印象に残っていません。交通アクセスが良すぎて最果て感がないこと、近くにバスツアー客向けの寂れた観光施設があって雰囲気が台無し、なども印象の薄さの一助になっていると思います。
そんな旅の帰りに寄った PA で開かれていた、レンタル落ち CD のワゴンセールでレアグルーヴを発見。「水の都の護神」のサントラはプレミアが付いており、1万5千円くらいで取引されています。たしか1万円弱くらいで入手したはず。これに収録されている「謎の少女、再び（迷宮）」がいい曲なんですよねぇ。最南端の碑よりこっちのほうが印象に残ってます。
春
仕事の方はぼちぼちというか、体制が変わったので引き継ぎやら立ち上げやらであんまり成果らしい成果がなくもどかしい時期でした。でもここに（全然完璧ではないにせよ）時間をかけたからその後の調子がよかったのだ、と思いたい。言い訳かも。
ゴールデンウィーク翌週、ふと砂丘というやつが見たくなり、鳥取に行きました。串本が近すぎた反省を活かし、もし時間が余っても島根まで足を伸ばせば調整できるだろうという算段です。鳥取砂丘は一部ではがっかりスポットとか言われることもあるらしいですが、私にとってはまったくそんなことはなく、一面砂まみれの景色と、大量の砂に足を取られて歩いて丘に登るのも大変という体験はとても新鮮でした。砂丘の見学は太陽がピークアウトする前に追えてしまい、時間が余るかもという私の予感が見事的中したため、スイスポを海岸線に沿って西へ走らせることにしました。
観光地化されているお社にちょくちょく挨拶をして回りつつ、私は出雲大社……の裏手にある日御碕灯台に向かいました。ここから見える夕陽が綺麗だというので、是非この目で拝んでみたいと思っていたのです。水面に沈む陽の光は前評判通り美しく、満足して帰ろうとする私は灯台の駐車場でヒッチハイクを見つけました。その2人組みはちょっといいカメラも持っていた（SONY の PXW とかか？）ので、もしや YouTuber か何かだろうかと思って声を掛けてみると、なんと CBC テレビのロケでした。聞けば地名しりとりという企画で日本中を旅~させられている~しているらしく、日の入りを見に来たら終バスを逃したとのことでした。山の上で終バスを逃した人を麓まで送るのは人生で2度目です*1。麓の駅までの車内ではながつさんとお互いの旅の思い出で大いに盛り上がりました。別れ際に番組のステッカーをいただきました。番組ステッカーっていいですよね。小学生時代におに魂シールに憧れていたからでしょうか。なお、この模様は（ローカルなテレビ局とはいえ）バッチリ地上波と YouTube で放映されたみたいです。
思えば、日御碕までの道中で「因幡の白兎」の神話が有名な白兎神社に立ち寄っていました。縁結びの神様でありますが特段相手というのもいない始末でしたので、もしこの旅で何か愉快な縁があれば、とお祈りをしていたのでした。まさか即日とは思いませんでしたが、本場恐るべし、なのでしょうか。帰りがけにお礼参りをして帰路に就きました。
夏
年初に言っていた南米の話がジワジワ現実味を帯びてきて、というか私を南米に連れて行く準備を周囲が着々と進めてくれていて、あとは黄熱病のワクチンさえ打てば行けるとなってしまったのがこの頃。2023年末の時点では海外で仕事する気なんて更々無く、この時点では海外経験も僅か1回という状態でした。よもや2回目の海外が地球の裏側になろうとは。
こうして日本の夏、南半球の南米では冬（？）に初めて南米に渡ることになりました。わかりやすく南米と書いていますが、「南米」って「アジア」くらいの広さがある言葉なわけで、正確にはパラグアイのアルゼンチン側の国境近くと、ブラジルのベレン、マナウスあたりに行きました*2。この出張の目的は様々で、挨拶回りだったりデータ集めだったり学会参加だったりしました。しかし振り返ってみると、その地に人工衛星の潜在的な需要があると感じられたことが何よりの収穫だったように思います。これは本当に行かないとわからないかも。
さて、その旅路はどうだったのかというと、まず行きの飛行機の機内食で出されたパイナップルで舌の裏を切って英語はおろか日本語すら満足に話せなくなり、ブラジルで泊まったホテルで焚かれていた殺虫剤で鼻水が止まらなくなり持っていったティッシュを使い果たしたりと、しょーもないところで大苦戦を強いられました。ブラジルのドラッグストアで陳列棚に出されていない虫刺されの薬をどうにかこうにかコミュニケーションして買ったのはいい経験だったかもしれません（ブラジルはポルトガル語圏なので町中では英語が通じない）。そんなこんなで不慮の事故によるデバフはありつつも、現地のみなさんには軒並み暖かく迎えていただいて、いずれの土地でも料理は美味しく（口は痛かったけど）、トータルでは無事に帰って来られたということになると思います。仕事の自己評価の方はまぁ、次回に期待という感じでしたが……。
南米から帰ると日本の夏は粗方終わっていて、真夏の最も暑い時期を南半球でやりすごした形となりました。ベレンはほぼ赤道直下なので季節関係なく暑かったけど。
秋
仕事の方では、宇宙科学技術連合講演会という宇宙系の学会で発表をしました。この学会は初参加だったのですが、これがなかなか（いい意味で）無茶苦茶な学会で、近年の宇宙産業の急速な発展に呼応してその規模を拡大しつつも、未だに宇宙系の発表をオールジャンルで受け止め続けており、スーツ・ジーパン・学生・エンジニア・サイエンティストが一堂に介しているという異様な光景が広がっていました。
プライベートではYAPC 函館に行ったり、高校の同級生と伊豆に遊びに行ったりしていました。今でも一緒に遊べる~アホな~高校時代の友人がいるというのは嬉しいことだなぁと思いつつ、かれこれ10年以上経つけど何も変わってなさすぎて安心したり心配になったり複雑な気分です。自分も心配される側であるという自覚はあります。そんな友人達も多忙は多忙で、なんならうち一人は日本海側に住んでてこっちに出てくるのも容易でないという事情もあり、なかなか予定の共通部分が取れずにいたのですが、10月の三連休は皆偶然予定が空いており、かくして伊豆旅行の運びと相成りました。
冬
南米2。この回ではパラグアイにのみ行きました。夏の回では不意のデバフを食らいすぎてあまりバリュー出せなかったし、個人的に今度こそはという気持ちで挑みました。フィールドワークが多かった前回と違って、普通に議論やコミュニケーションの多い仕事ではありましたが、パイナップルによる事故はなく2回目故の余裕があったので多少のバリューは出せたような気がします。自分の詳しくないドメイン（異国の農業）に関して慣れない言語で質問して理解するプロセスはシンプルに脳が疲れる。それでも相手方の職員の方達がスペイン語と英語を通訳してくれるのでなんとかなっています。これなかったらどうなってたんだマジで……。
せっかく行くんだから空気をたくさん吸っとくのが大事というか、この国のことはググってもなんもわからんので現地にいるうちにちゃんと見て回っておきたいよねということで近くの山（丘？）へ。標高は350mくらいで日本の基準では低山ですが、頂上付近が急に切り立っていて岩場になっており、低いながらも楽しい登山でした。
来年に向けて
金・時間・体力・気力のうち一番足らないのは時間ですがそれはどうにもならないので、時間→体力→気力という連鎖でジリー・プアー（徐々に不利）になるのを避けるべく2025年は体力を付けていきたいですね。そういえば2024年の目標はもはや覚えていません。
2025年の KOBA789 にもご期待ください。
「なぜベストを尽くしたのか」への憧れ
これは VTuber・Vクリエイター Advent Calendar 2024 - Adventar の19日目の記事です。大遅刻。
Channel 78.9 という YouTube チャンネルでたまーに長時間の配信をやっている。内容はプログラミングとかコンピュータサイエンスとか、そういう感じだ。 www.youtube.com
配信頻度のごく低い私が、何を楽しみにして活動をやっているのか、ということについて書こうと思う。普段、自分のモチベーションや活動の裏側については動画や配信内ではあまり言及しないように、いわゆる舞台裏を明かさないようにしている。そうしている理由もこの記事の内容とちょっと関係があるのだけれど、いい機会だと思って筆を執ってみる。
「なぜベストを尽くしたのか」
「なぜベストを尽くしたのか」とは、ニコニコ動画で（やや）ポピュラーなタグの一つである。その意味について、ニコニコ大百科を引用すると以下の通り。
世の中には暇つぶし・気分転換など普通はベストを尽くさないもの、ベストを尽くす必然性が無いものが多数存在する。
しかし、そんなどうでもいいことに真摯な姿勢を貫く人がいる。
一説によれば人間は情熱の生物で、どうしようもないことにもベストを尽くさずにはいられないらしく、ニコニコ動画でもたまにそういうベストを尽くしてしまった人に遭遇する時がある。そんな時視聴者は様々な感情を持って本タグを付けるのである。
なぜベストを尽くしたのかとは (ナゼベストヲツクシタノカとは) [単語記事] - ニコニコ大百科
つまり、愛すべき無駄な頑張りを労うため、あるいはそれを称えるために使われるタグである。
私とニコニコ技術部
ところで、私はニコニコ動画とその文化が好きだ。15年前と比べるとだいぶ様々な印象を持たれるようになったニコニコ動画だが、今でも最もよく見ている動画サイトに違いない。私自身は YouTube で活動しているにもかかわらず、だ。
今でもほぼ毎日見ているニコニコ動画だが、やはり最も熱心に見ていたのは中学生の頃だったように思う。来る日も来る日もランキングとお気に入りのタグを追い、新着動画をチェックしていた。
当然、ボカロ曲なども追いかけていた*1のだが、一番追いかけていたのはニコニコ技術部のタグだった。ニコニコ技術部タグは、高い技術を応用したいわゆる「やってみた」動画に付けられるタグだ。今思えば、あれらの投稿者は当時の高専生だったり大学生だったり、あるいはプロの技術者だったりしたのだろう。
ニコニコ技術部の動画の魅力は、その技術力の高さだけではなかった。技術だけでなく、ユーモアに溢れた動画がたくさんあった。むしろ、ユーモアのために技術を惜しみなく使う姿勢があった。自分自身が多少技術に理解があるからこそ、その動画で行われていることがどれほど高度なことなのかがわかった。バカげたことにあまりに高度な技術が投入されていること自体がおもしろかった。ケーキをチェーンソーで切るのはエンジニアリングとしては不適切だが、ユーモアとしては適切である*2。
技術がユーモアを生めるという事実は衝撃的で、それらの動画に私は夢中になっていた。
趣味だからこそベストを尽くす
仕事においては、全力を尽くすことが常に合理的だとは限らない、というのはまぁ多少反論はあるだろうけれど比較的受け入れられる意見だと思う。飽きても疲れてもある程度続けなければならない仕事では、その瞬間のパフォーマンスと未来のパフォーマンスでバランスを取らねばならないから、全力を出すことは長いスパンでの最適にならないことがある。短距離走とマラソンは違う、というやつだ。
しかし、後先考えずベストを尽くして、自分がどこまでできるのか知りたいと思うことがある。あるいはどこまでできるのかを示したいということがある。私がこの活動をしている理由のひとつは、それらの欲求を満たすためだ。
この活動をしているのは完全に趣味のためだ。つまり、あらゆる経済的合理性を無視していいってことだ。経済的合理性を無視しているから、収支は機材や資料の購入でずっと赤字だ。土日を潰して準備をしているけれど自分の時間単価を考えたら大赤字だ。
それでも、というか、それだからおもしろいのだと思っている。経済的合理性のあるコンテンツでは、経済的不合理のおもしろさは出せない。赤掘ってる人間からしか出せないユーモアがある。少なくとも私はそう信じている。
たまに、準備にコストかけててすごいですねと言われることがある。嬉しい言葉だ。でも、私の場合はほとんどコストをかけることそれ自体が目的なのでそれは当たり前なのだ。いいコンテンツを届けるために努力をしているのとはちょっと違う。無駄なコストを投下してみたいからこの活動をしているのだ。
2025年に向けて
配信頻度が低いのは、一発が高コストだからなのではなく、単にネタ切れだからだ。以上の話から理解いただけたと思うが、ネタがあるのならもっとコストを投下したい、配信をしたいと思っている。しかしネタが切れているのでそうもいかないという状況だ。
こればかりは私のセンスの問題でもあるので一朝一夕で改善することではないが、引き続き気長に待っていただければと思う。
函館に行ってきた
別に隠す理由があるわけではないし、X を見ればどこに行っていたかなんて丸わかりなのだけれど、下記のようなツイ……ポストを見かけたので敢えて伏せて（？）書いてみるかと思って書いてみます。対戦よろしくお願いします。
#yapcjapan ブログ, 見つけたものはマジで全部見ていますので... 君のブログも絶対に見つけて読むぞ.........
— PAPI𝕏 (微笑みデブ) (@__papix__) October 7, 2024
私と名前を出さないあのカンファレンスとの関係
恥ずかしながら、あのカンファレンスに参加したのは今回が初めてでした。もちろん存在自体はもはや思い出せないくらい昔から知っていたのだけれど、開催情報をずっと見落とし続けており、開催当日に Twitter（当時）に流れてきた楽しそうな写真を、みんな美味そうなもの食いやがって許せんなんで誰も教えてくれなかったんだと指くわえて見て悔しい思いをしてきました。
では今回はなぜ参加できたのかというと、これは今回のベストスピーカー*1でもある id:tomo_ari (osyoyu) のおかげによるところが大きいです。彼とは同じチームで毎年 ISUCON に出場しており、どうしても Ruby で優勝するぞという合理性のない目標を掲げて一緒に闘っている仲です。そして Ruby で勝つためには正しくパフォーマンス計測ができなきゃいかんということで、彼は pf2 という Ruby のプロファイラを開発しています。
ところが我々の ISUCON チームは仲が悪い[要出典]ことで知られており、直前の練習と本番以外で顔を合わせることはほとんどありません。そのため pf2 の開発状況はチームメイト間であっても共有されておらず、果たしてその年の大会で使えるのか、そのプロファイラで分析して何がわかったのかなどは長らく謎に包まれたままでした。
そんな中、ぼちぼち今年こそはなんとしても勝ちたい*2と思った私は、pf2 はどうなっているんだ、Ruby は遅いのか、100万円は獲れるのか、というようなことを問いただすべく彼のポストを漁りました。するとちょうど例のカンファレンスでそれに関する発表をするとの予告があり、かくしてようやく、私はチケット販売期間中に例のカンファレンスの存在を知ることができたわけです。チームへの情報共有を疎かにするのは悪いことばかりではないという学びがありますね。
私とはこだて未来大学
私がはこだて未来大学を訪れるのはこれが2度目です。1度目は6年ほど前、私がまだ前職にいたときでした。はこだて未来大学の学生を対象に集中講義（のようなもの。単位は出ません）をやっていいよと言われたので、当時まだマイナー言語枠だった Rust のハンズオンをやるべく訪れたのでした。C言語の講義の内容を初めて理解できたとか、低レイヤおもしろそうだとかといった反応をいただけてホクホクで帰ったような記憶がありますが、だいぶ昔のことなので都合の良い記憶が捏造されているかもしれません。
函館名物ラッキーピエロのチャイニーズチキンバーガーを初めて食べたのもそのときです。丸一日の講義ですから学生含めてお昼ご飯の用意が必要だったのですが、休日なので食堂などは使えません。困って未来大の学生さんに相談したところ、それならと教えてもらったのがラッピでした。というかラッピ以外ありえんだろみたいなテンションで言われたような気がします。当日も、お昼ご飯はラッピ？とかいうの用意しました、という案内に多くの学生が喜んでおり、当時ラッピの偉大さを微塵も知らなかった私はそんな大げさなと思っていたのですが、食べてみて確信しました。たしかに美味い。それ以来、年一くらいで食べに行っている気がします。
なんか未来大というか半分くらいラッピの話ですが、はこだて未来大学という地に再び遊びに行けるのはとても嬉しかったです。
スポンサーブースを回る
思い起こすと、今までいろいろなカンファレンスに参加してきましたが、セッションを聞くだけでスポンサーブースは回らないということがほとんどだったように思います。毎回登壇者として行くので、スライド作成に追われてて余裕がないとか、ロビーに突っ立ってると絡まれるのでそれで時間が溶けるとか、そういうことになりがちでした。
今回は友人の発表を聞くために行ったのでとても余裕がありました。スライド作成に追われないカンファレンス参加がこれほど気楽なものだとは思いませんでした。気楽さを体験して初めて、登壇者って大変なんだなと思いました。登壇者には懇親会では発表の感想を伝えたりして労ってあげましょう。登壇者のみなさんは猛烈なプレッシャーを乗り越えて懇親会に到達しています。
それはともかく、時間がたくさんあったので、今回はスポンサーブースをじっくり回ることにしました。そもそも、参加の目的の半分は「外の風にあたる」ことでした。pf2 の発表を聞くのももちろん大事でしたが、前日にスライド作成を手伝ったりでほとんど内容を知ってしまったのでそちらばかりに意識を向け過ぎる必要もなくなっていたのです。
私は、今はいわゆるウェブ業界*3から離れ、人工衛星スタートアップで働いています。そのため、今のウェブ業界にどういう企業があるのか、どういうビジネスをしているのかという事情にかなり疎くなっていました。業界は違えど、ソフトウェアエンジニアの活躍場所としては並列です。つまり、自分の未来の転職先である可能性があると同時に、今人材を取り合うライバルでもあるわけです。知らないわけにはいかないのです。
やや打算的な書き方になってしまいましたが、まぁそんなに深くは考えていなくて、私の狭い視野と拙い想像力では、ウェブ技術は EC サイトと UGC サービスしか作れないように感じてしまう（失礼）ので、他のみなさんは一体どんなビジネスに技術を使っているのかに興味があったということです。
今回は、私の知らない会社がたくさんブースを出展していました。私にとってとても嬉しいことでした。とりあえず社名を知らないブースに行って会社紹介の紙ペラをもらい、会社の概要や創業のきっかけ、お金を払ってくれるお客さんはどんな人・会社なのか、エンジニアリングのおもしろさはどこか、などを聞いてまわりました。私の全然知らないドメインでビジネスチャンスを見つけ、そこの課題を技術で解決している人たちの話を聞くのはとても新鮮な体験でした。ブースを回るごとに新しいことを教えてもらいました。事業ドメインのおもしろさだけを語る勉強会があったら行きたいかもしれません。
概ね各社共通しているなと思ったのは、そのドメインに詳しい人が創業しているということです。そんなの当たり前だ、と思うかもしれませんが、テックカンパニーはドメイン知識だけでは成立せず技術も必要です。しかし IT 技術はどんな分野とも隣接しているわけではありません。昔から距離の近かった金融や EC などはともかく、ヘルステックや不動産といった領域にも IT 技術が深く応用されるようになったのは、IT 技術がより広い範囲の人々に行き渡った結果だと思います。その結果、あるドメインエキスパートがたまたま IT 技術を持ち合わせているという確率が高まり、おもしろいビジネスが発生しやすくなっているのだと感じます。
あこがれとふるさと
私が参加に失敗しつづけていたからというのもありますが、このカンファレンスやこのカンファレンスに登壇している人々は以前から私のあこがれでした。私自身は Perl を書きませんが、Perl を書いている・書いていた先輩たちこそ、20年前、私がプログラミングを始めたときに憧れたハッカーの姿なのです。記号だらけのよくわからないコードを書き、伝わらないジョークを飛ばし、そういう仲間と酒を飲む、それが私にはクールでした。
いくらかの参加者とはそれぞれ別の場所で会ったことがありました。そのせいか、このカンファレンスに参加したのは今回が初だったのに、すごく懐かしい感じがしました。そうか、会に参加こそしていなかったけれど、いつの間にか自分はこの文化の中にいたんだな、そう思ったのでした。
初めて来るのにふるさと、そんな不思議な体験でした。
関係ない画像
OBS Studioの配信画面レイアウトのベストプラクティス
OBS Studio は現代の配信者にとって必須なソフトウェアです。かつては XSplit などのお世話になったこともありましたが、とくに YouTube Live や Twitch で活動している現代のアマチュア配信者のほとんどは OBS Studio を用いていると思います。かくいう私もそのような配信者のうちの1人で、Rust で Z80 を動かしたりリードソロモンを教わってゼロから実装したりする配信をしています（隙あらば宣伝）: #ch789 / KOBA789 - YouTube
そんな OBS Studio ですが、配信画面のレイアウトを整えるのは至難の業であることが知られています。GUI の操作が難しいからでもありますが、レイアウトを司る「変換」という機能の仕様が難解なのが主因だと思います。日本語訳がわかりづらいこともその難解さに拍車をかけています。たとえば「変換」は "Trasnform" の訳なんですが、これはさすがに伝わらんと思います。他のアプリケーションに倣うと「変形」とかでしょうか。
この記事では「変換」の詳細な仕様については説明しません。言葉で説明したところでそれぞれの機能がプリミティブすぎて結局どのように使えばいいのかわからないからです。かわりにこの記事では、具体的にどのような設定にすべきかを紹介します。
基本の設定
シーンにソースを追加したらまずは「変換の編集」を開いてください。いきなりマウスで大きさを変えると不幸が始まります。うっかり大きさを変えた場合は「変換をリセット」で戻してから以下の設定をしてください。
以下の設定をした後ならマウスで動かしても大丈夫です。わかってきたら基本以外の設定をいろいろ試すとよいですが、まずは下記の設定から始めるのが安全だと思います。
位置
そのままでよい。
座標を直接打ち込んで調整したいときはここに入力する。
回転
0.00° にする。
回転が入るとややこしくなるのでこの記事では扱わない。
大きさ
絶対に変えない。
大きさを直接打ち込んで調整したいときは後述の「バウンディングボックスのサイズ」を変更する。
位置揃え
「左上」でよい。
回転したいときは他の値にするがややこしくなるのでこの記事では扱わない。
バウンディングボックスの種類（超大事）
「境界の内側に合わせる」に設定する。この設定が一番大事。
この設定だと縦横比を歪められないが、縦横比を歪めたいケースはほとんどないのでこの記事では扱わない。うっかり縦横比が歪んでダサくなるほうがよっぽど不幸である。
バウンディングボックス内の配置
「中央」でよい。
それ以外でも悪いことは起きない。それぞれの効果が気になる人は試してみよう。
バウンディングボックスのサイズ
そのままでよい。
大きさを直接打ち込んで調整したいときはここに入力する。
バウンディングボックスにクロップ
この記事通りの設定では ON でも OFF でも同じ。
ややこしくなるのでこの記事では詳細を扱わない。
クロップ
よくわからなければ全部 0 でいい。入力データの端に映したくない部分や余計な部分がある場合にここで削れる。詳細は割愛するけどお好みで。
細かいことが気になる人向け
いきなり画面上でマウスを使って大きさを変えてはいけない理由
「バウンディングボックスの種類」が「境界なし」のままマウスでサイズを変えると、「バウンディングボックスのサイズ」ではなく「大きさ」が変わるからです。
「大きさ」を変えてはならない理由
これを理解するには、シーン上のソースの大きさを OBS がどのように計算しているかを知らねばなりません。
「バウンディングボックスの種類」が「境界なし」のときのシーン上の大きさは次の式で計算しています（クロップなどを無視しています）。
width = scaleX * sourceWidth height = scaleY * sourceHeight
ここで、sourceWidth, sourceHeight はそれぞれ入力データの横幅と縦幅です。たとえばキャプチャカードデバイスが 1920x1080 で映像を取り込んでいれば、これらはそれぞれ sourceWidth = 1920, sourceHeight = 1080 となります。左辺の width, height はそれぞれ実際にシーン上で表示される大きさの縦幅と横幅です。
シーン上で表示される大きさは scaleX, scaleY という係数が乗されて決まるので、シーン上に表示される大きさを直接的に決めることはできません。
では「変換の編集」の「大きさ」を変更するとなにが起きているのでしょうか。実は width, height が変更されるかわりに、scaleX, scaleY が変更されます。つまり、狙った width, height になるように scaleX, scaleY が逆算されて保存されるのです。
これは入力データの大きさが変化したときに意図しない挙動を生み出します。例えば、シーンに背景画像を置いてそれをあとで差し替えるといったケースを考えてみます。
まず、シーンに「画像」ソースを追加し、背景画像を置きます。この画像ファイルの解像度は 3840x2160(4K) だったとします。つまり sourceWidth = 3840, sourceHeight = 2160 です。
しかし画像が大きすぎてシーンからはみ出してしまうので、あなたはマウスで大きさを調整してシーンサイズ 1920x1080(Full HD) ぴったりになるようにします。このとき、「バウンディングボックスの種類」は「境界なし」のままなので、内部パラメータ scaleX, scaleY が変更され、それぞれ 0.5 になります。
次にあなたはやはり別の背景画像に差し替えようと思い立ち、ソースのプロパティを変更して別の画像ファイルを読み込みます。この画像ファイルの解像度は 1920x1080(Full HD) だったとします。つまり sourceWidth = 1920, sourceHeight = 1080 に変わったわけです。
するとどうでしょう。シーン全体を覆うように配置されていた「画像」ソースは半分のサイズに縮んでしまい、960x540 の大きさになってしまいます。sourceWidth, sourceHeight が変わってしまったために、シーン上の大きさである width, height の値もそれに引きずられて変わってしまったのです。入力データの大きさが変わっても内部パラメータ scaleX, scaleY は調整されないので、入力データを変えるとシーン上の大きさが変わってしまうことがあるのです。
同様の現象はキャプチャカード等でゲームの画面を取り込んでいるときにも発生することがあります。ゲームが出力する画面解像度が変化すると、それに影響されてシーンのレイアウトが崩れてしまうのです。
