#エアコミケ 閉会に寄せて
全世界的に止まらない新型コロナウイルスの影響を受け、 このゴールデンウィークに開催される予定だったコミックマーケット98は、 史上初の中止となってしまいました。 前回（C97）以前から準備を進めていた中での中止は個人的にもかなり辛いものでした。
全国で同人即売会が次々と中止になっていく中、 同人文化を絶やさないために急遽企画されたのが、 オンライン上でコミケの盛り上がりを再現しようとする「エアコミケ」でした。
そもそもは草の根的なハッシュタグではじまったものに公式が乗っかったというのが発端ですが、 エアコミケ当日に合わせて各同人系販売サイトが販売に力を入れたり、 印刷会社や会場警備の会社*1など意外なところがツイートに参戦したりと、 最終的には参加形態の垣根を越えた一大ムーブメントになったような気がします。
私のエアコミケの過ごし方
リアルで開催されていれば、今回でスタッフ活動10年目の節目でした。 中止発表の段階では既にスタッフ登録済みでしたから、一応立場上はスタッフということになります。 エアコミケにおいてはスタッフとしてツイートすること自体にNGは出ていませんでしたので、 業務に関わること（守秘義務の関わること）や調子に乗りすぎないこと（イベント中止で参加者には迷惑かけてますし）に心がけつつ、 それっぽいことをポツポツとツイートしていました。 私は一個人なのでさほど影響力はありませんが、 各種公式アカウントを動かしていた中の人たちは随分と気を遣ったんじゃないでしょうか？ （時々「それいいの？」というツイートはありましたが……）
おはようございます！本日エアコミケ3日目。外回りのスタッフには雨は大敵ですが、室内から出ないで楽しめるのはいいですね。
— なのなの (@nano2_aloerina) 2020年5月3日
各自エア設営、エア入場待機、もしかしたらエア原稿修羅場？を進めてくださいね。
今日は身だしなみも整えて？みました（装備はC97のものです）#エアコミケ #スタッフ pic.twitter.com/6CXTkli1Lm
個人的にはこれが割とギリな気がする
鯖落ちとかしちゃうと大変なので、行列がないからと一般参加者のみなさんは殺到して無理せず…。#エアコミケ #サークル #頒布販売 https://t.co/7uXuYKKUjL
— C98は中止の代わりに★エアコミケ公式 (@comiket_air) 2020年5月3日
エアコミケ公式さんお疲れさまです（ちなみに初日Boothが本当にアクセス過多になったらしい）
エアコミケの難しさ
表面上は一定程度の成功？と言えそうなエアコミケですが、 冊子版カタログの売れ行きは上々とはいいづらいようで *2 公式アカウントでのツイートが行われています。 また、島の間を歩いて目に付いた気になる本を買うというやり方ができないので、 個人的には評論・情報サークルの中に埋もれた一風変わった本の探索ができなかったのが地味に辛かったです。
これから、どうなる？
現時点ではコロナウイルスの終息は見えていません。 オリンピック・パラリンピックも延期され、他のイベントも含め開催が白紙状態になっています。 これからどうなるかは、誰も分からないのが実情だと思います。
どうなるか分からない実情ですが、 今はこれまでの日常に戻れるように願い、 そのいつかのために同人活動を止めないことに尽きるのかな、と思うのです。
技術書典 応援祭に新刊をご用意できませんでした！
ホントごめんなさい。
技術書典8が昨今の事情により中止となってしまったために、
技術書の頒布機会を潰さないよう運営事務局が生み出したオンライン開催の「技術書典 応援祭」。
技術書典8合わせの新刊ができていれば私も参加していたのですが、
今回いろいろとありまして新刊を落としてしまったため、参加を見送っております。
本記事はその言い訳記事です。
何を出す気だったのか
既刊のElectron + Vue.js本を最新バージョンでアップデート＆内容充実でお送りする予定でした。
すっかりうっかりしてお知らせが遅れたのですが #技術書典 8はスペースを頂くことができました。
— なのなの＠ (@nano2_aloerina) 2019年12月16日
1日目（2/29）です。既刊のElectron本を最新バージョンでアップデート＆内容充実でお送りする予定です。 pic.twitter.com/f2CmpCYUL4
既刊を出してから1年以上が経ち、最新の開発スタイルが随分と変わってきているため、 それに追いつくためのバージョンアップというか、フルスクラッチ書き直しをするつもりでいました。
具体的には環境構築に使用するコマンドラインツールをVue CLI（@vue/cli）ベースで書き直し、
サンプルアプリの題材も見直すことで、
前回触れられなかったトピック（例えば、アプリのビルド詳細やタイマーのあるアプリ、音声の扱い方など）
にも触れられる限り触れる、前回以上にページ数の多い本を作る気でした。
私はこうやって新刊を落としました
ここからはひとりなぜなぜ会による言い訳コーナーです。
これを反面教師にすれば新刊を落とさずに済むかも知れません。
予想外の開催日
これまでの春開催は4月の初旬だったのですが、突然の2月末開催。 実質締切が2ヶ月縮まってしまいました。 それに合わせたスケジュールが引き切れなかったのが結構効いています。
急に忙しくなるスタッフワーク
開催が早まってもプライベートの忙しさがそのままだったら何とか時間は作れるはずだったのですが、
去年の秋に来て突然某有明の案件が忙しくなり始めました。
深くは言えませんが、ちょっとだけ偉くなっちゃって仕事が増えてしまいました。
原稿を書く時間がどんどん持っていかれてしまってます。
（なおこれは現在進行形）
コロナ
スタッフワークも予定通りにいけば良かったのですが、
開催直前になって沸き立つコロナウイルス案件。
2〜3月あたりに予定していたイベントの調整が必要になり、さらに執筆の時間が無くなりました。
こればっかりは自分を恨んでもどうしようも無いんですが......。
（せめてもの救いは印刷を出していなかったこと？）
で、どうするの？
落としてしまったとはいえ、途中まで書いた内容はありますし （推敲していないので内容はボロッボロですが） 出したいという気持ちは残っています。 なので、すぐには無理だとしても一度仕切り直して別のイベント合わせで出したいと考えています。
具体的にいつ、というのは現時点では考えられないのですが、 おおむね1年以内を目標にしたいです。 その頃にはElectronや周辺技術ももっと新しくなってるでしょうし、新しいトピックも追加できそうです。
結論
なのなの先生の次回作にご期待ください！（フラグ）
エンジニアは絵描きもエンジニアリングするのか
2020年の12分の1が終わってしまった今日この頃。
今日のネタは技術的じゃないようで、ちょっと技術的かもしれないおはなしです。
ちょっと変わったエンジニアの集まりに行ってきた
「エンジニア絵描きの会」というconnpassコミュニティのイベントが、 今日開催されました。
勉強会という体こそとっていますが、 実際には情報交換と交流というLTあり雑談会という感じのイベントでした。 主催は技術書典をきっかけに仲良くなった、やぎっちさん（@yagitch）。 ご自身が主催するイベントはこれが初めてだそうです。
エンジニアが絵描きをするとどうなるのか
今回の参加者は技術書典やコミケでのサークル参加経験のある方がほとんどで、 そこそこ創作経験をお持ち*1の方が中心でした。 （1名だけ、つい最近になって本格的に始めたばかりという方もいました）
作業環境はほぼiPad Proにクリスタ（CLIP STUDIO）もしくはProCreateという、 言ってしまえばモダンな環境で作業をされているようでした。 揃いも揃ってiPad Pro出してる光景はちょっと面白かったですが、 腰を据えてアナログというよりは、 デジタルの恩恵を十二分に活用するのがエンジニアらしい？という感じでしょうか。
エンジニアは絵描きもエンジニアリングするのか
勉強会恒例のLTですが、今回は3件ありました。
未経験から5年間描き続けた結果(@yagitch) speakerdeck.com
自己紹介と、環境と、Scrapboxのすすめ / engineer_ekaki self-introduction(@castanea) speakerdeck.com
2019年お絵かきふりかえり+α(@traitam) speakerdeck.com
面白かったのは、 絵を描く際の資料をまとめておくためにWebサービス（Scrapbox）を使う、 自分が絵を描くことに使える時間や使った時間を分析するためにログを残す、 これまでのイラスト上達の過程を（エンジニアがよくやる）ふりかえりで分析する、 など、お絵描きという行為をエンジニア的に捉えているということでした。
私自身、同人作家関係の知人友人は少なくないので、 各人の思う「私はこうやって絵を描いています」という話は多く聞きます。 しかし絵を描くことをエンジニア視点で捉える視座は今回が初めてで、 「エンジニアは絵描きもエンジニアリングする*2んだなぁ」 と思ったものでした。
あと、個人的にはこの使い方も感心しました。
カンバンをこういう使い方する人初めて見た…… #engineer_ekaki pic.twitter.com/zxjiZ2bRPT
— なのなの＠2/29技術書典8う44 (@nano2_aloerina) 2020年2月2日
描きたいもの、描かなきゃならないものをToDoにつっこみ、 描いている⇒描いた、とカンバン方式でタスク管理の如く扱うという裏技。 これはエンジニアしか思いつかないでしょう。
おわりに
エンジニア絵描きという属性は決して珍しい属性ではないようで、 主催のやぎっちさん曰く「私も行きたかった」「もっと早く知っていれば」という人が多いのだそう。 意外と好評だったようなので、第2回の企画も考えているとか。
創作意欲沸いたし、私も意欲がしぼまないうちにお絵描きしよう！（できるとは言ってない）
私とシンカリオンスタンプラリーとの攻防録、あるいはその攻略ポイント
既に20日ほどが経っておりますが、
新年あけましておめでとうございます。
本年も私共々当ブログをよろしくお願い申し上げます。
2018年に放送されたアニメ作品の中に 『新幹線変形ロボ シンカリオン』（以下、長いので「シンカリオン」）という作品があります。 元々はJR東日本のプロパティライセンス事業という 「本業以外でも売れるものを持っておこう」的なIP事業で生まれたもので、 アニメの評判がすこぶる良かったため劇場版が製作され現在大ヒット上映中の作品です。
そんなシンカリオンですが、 アニメの放送中からJR東日本のコラボスタンプラリーが何度か企画・開催されており、 現在はJR東日本仙台支社が企画した第4弾が開催されています。
このスタンプラリーにこれまで私は挑み続けており、先日第4弾も完全制覇で終えてきたところです。
今回はその戦い（？）の記録と、そこから分かった攻略のポイントを備忘録的にまとめてみることにします。
（あくまで参考資料です。確実な完全制覇を保証するものではありません）
これまでのスタンプラリー
先日終えてきた第4弾の話をする前に、軽くこれまでのスタンプラリーについて触れておきます。
第1弾: 2018年11月
記念すべき第1弾は上野東京ライン・湘南新宿ラインを中心とした7か所（7駅）で開催。
各駅が3つのエリアのどれかに分類され、各エリア1駅以上スタンプを集めた状態で景品を交換する優しいスタイルでした。
ただし、この時点から駅ではない鉄道博物館*1にもスタンプがある真のゴールがあるという変化球は存在しており、
コンプリートの難易度は少々高く設定されていたように感じます。
【1/19訂正】第1弾では鉄道博物館にスタンプは無く、特定条件でダブルチャンスの抽選ができるという仕組みでした。
第2弾: 2019年3月
「大宮支部編」と題した第2弾では、突然スタンプ台設置ポイントが24か所と激増。 さらに北端が黒磯（栃木県）、南端が川口（埼玉県）、川越線に武蔵野線、 果ては日光線まで召喚された恐ろしい規模で開催されました。 1時間に1本という日光線と、閉館時間というタイムリミットがある鉄道博物館のスタンプをどう攻略するかがポイントでした。
第3弾: 2019年11月
劇場版公開を記念し、通常のスタンプラリーと謎解きを組み合わせた13か所（13駅）で開催。
3つのエリアのスタンプを規定個数集めるという原点回帰スタイルに戻りつつも、
これまで登場しなかった高崎線と横須賀線（逗子駅）が登場し、大宮を軸とした北側の往復に骨が折れる構成でした。
また、後半からは特定の駅にある謎を解いてスタンプ台紙に仕込まれた謎を解くという謎解きにもチャレンジできる、
1イベントで二度美味しいラリーになっています。
今回の特徴
「in 東北」と題して開催されている（2020年1月現在）第4弾は、 主に次のような特徴からこれまでとは一線を画しています。
開催エリアが東北地方
JR東日本仙台支社の企画ということで、スタンプ台設置ポイントが東北地方の各県に散らばっています。 これまでは最大でも神奈川〜栃木の関東一円で収まるエリアでしたので、かなり大きくなりました。
新幹線改札内に置かれたスタンプ台
一般的なスタンプラリーではスタンプ台の設置場所は改札の外になっているのですが、 今回は全てのスタンプ台が新幹線改札内に設置されています。 従って新幹線に乗車して押すか、入場券でわざわざ改札内に入る必要があります。 *2
シビアな景品交換条件
各県にある景品交換ポイントではアクリルスタンドと景品交換ができるのですが、 その条件が当該駅＋他の景品交換ポイントでのスタンプをスタンプ台紙に押してあることという、 必ず2か所以上回っていないと交換できない少々困った条件になっています。 裏を返せば、景品交換ポイントのうち1か所だけは二度訪れる必要があるということです。
で、結局どうやって攻略するのがいいのか
先日攻略してきた際の経験から、 これからチャレンジしてみようとしている方へのポイントを挙げてみました。
1日で終わらない前提で計画をしておこう
スタンプを押すだけであれば（始発から終電の間に移動し続ければ）全駅制覇は可能かも知れません。 ですが、景品を交換することを考えると1日で終わらせることはほぼ不可能*3です。 最低でも一泊二日の日程は考えた方が良いでしょう。
私がチャレンジした際は1月の3連休をチョイスし、 仙台を基準に北側/南側それぞれで一泊二日の日程とすることで制覇してきました。 仙台を基準点に置いたのはエリア的にだいたい真ん中であることと、 中核都市なので宿が取りやすいことが主な理由です。 それと個人的な理由として知り合いに会える可能性が高い*4こともあります。 別に仙台でなくても、盛岡や福島あたりも（秋田・山形新幹線の分岐地点に当たるので）良いかも知れません。
秋田・山形新幹線に注意
秋田新幹線や山形新幹線は在来線区間を新幹線が走行するミニ新幹線という規格で運用されているため、 地方ローカル線のダイヤ感覚でいないと痛い目に遭います。 山形新幹線に至っては2時間まるまる次の列車が来ない*5時間帯があるため、 1日の始めか終わりにしておくなど気をつけて計画するのが賢明と思われます。
新幹線移動にこだわりすぎない方が良い
特に東北圏以外からチャレンジする人に言えることですが、 スタート地点に到着するまでの移動時間は無駄にできないものです。 新幹線以外の交通手段を選択すると改札内にあるスタンプが押しづらいという難点はありますが、 移動時間を節約することを考えると、高速バス等を利用してショートカットするのも意味のある選択といえます。
今回私のチャレンジでは1日目のスタート地点（秋田駅）までの経路を深夜バスで、 2日目の仙台駅⇒山形駅を高速バスでショートカットすることで、全体として効率よく回ることに成功しました。
まとめ
ある意味「JR東日本仙台支社からの挑戦状」とも言える過酷なスタンプラリーですが、 スタンプラリー終了までまだ1ヶ月あります。 用意周到に計画を立ててチャレンジし、是非完全制覇してみてください。
ちなみに、完全制覇すると各駅で交換したアクリルスタンドを使って遊べるすごろくセットが後日郵送でもらえるらしいです。
やる相手がいない...。
技術書典7を導線から考察する（３）
技術書典7を導線から振り返る考察記事シリーズ、いよいよ最終話（第３話）です。
本シリーズの位置づけや執筆の意図は第１話の記事を
上下階移動についての考察は第２話の記事を
それぞれご覧ください。
観点3. 導線をコントロールする運営スタッフについて
何があったのか
技術書典7ほどの規模となっている同人即売会は、 多くの参加者が大挙して押し寄せる大イベントになります*1。 参加者に対して人数比的に圧倒的不利な状況にありながらも、 運営スタッフは逃げることは許されず、立ち向かっていかなくてはなりません*2。
「目の前で起きている事象」よりも「それに対処する運営スタッフの挙動」に目がいってしまう同業他社的ものの見方が発揮された結果、 導線管理や誘導にあたっていた運営スタッフの対応について、いくつか気がかりな点が確認できました。
1. 列の曲げ方、切り方、変形の仕方についての意思統一が取れていない
サークル参加証を手交されたサークル参加者が、各ホールに入るまでの間に長時間待機を余儀なくされたことについては、 第1話の記事で言及したとおりです。 その際、建物外からガラス扉を通って建物内に入る部分は列が90度曲がる部分だったのですが、 対応するスタッフによって、列を切って列幅を変えずに曲げたり、列を切らず曲げながら列幅を変えたりと一貫性のない対応が行われているように見えました*3。
また、ガラス扉はこれから列に並ぶ参加者も通る経路となっていましたが、 私が並んでいたとき目の前にいたスタッフは待機列をそのまま一本にしようとしており、 危うく導線を完全にふさぎかねない状況になるところでした（さすがに驚いて「導線ふさいじゃうけど大丈夫？」と運営スタッフに言ってしまいましたが...）。
2. 複数列を取り扱うための知識が不足している
もうひとつ、 同一方向に複数の列が並んだ状態*4における列の移動についても気になる部分がありました。 この形で作成された列は動かす向きが同じ方向になるため、ひとつ前の列が完全に動ききるまで動かさないでおき、 ひとつ前の列の最後尾に最前を接続する形で動かす（図の①）か、 1列ずつ空いたスペースへ移動させる（図の②）のが同人即売会でよく使われる手法です。 なぜなら、あまりにも一気に列が移動を行うと列の前後左右が混じってしまい、 せっかく作った列の秩序が崩れやすくなってしまうからです。
ですが、今回においては2階から3階へ移動する際の待機列について 「最初の列が移動して無くなった場所へ、残りの列全体が横へスライドしていく」という移動方法がとられていました。 各人によって荷物の量や移動のしやすさから横移動にはタイミングのズレが出やすいのですが、 それを気にせず一気に横スライドしてしまった結果、一部では各列の境があいまいな状態になっていたことが確認できました。 幸い参加者同士のトラブルになるような混乱はありませんでしたが、内心ヒヤヒヤしていたのを覚えています。
ホント、みんな心優しくて良かった...（他の即売会ならクレームものだった、かも。）禁断の複数列横移動開催中
— なのなの (@nano2_aloerina) 2019年9月22日
民度が高いサークル列だから良いものの、一般入場列でやったら怒られるヤツ#技術書典
推察される背景
なぜこのような状況になったのでしょうか。 大きく考えられるのは次の2点ではないかとみています。
1. スタッフ自体の人員不足
どんなイベントでもスタッフの充足は重要なのですが、 結構ハードルが高いことでもあります*5。 最近では（3日間開催が4日間開催になった）コミックマーケットにおいて、 準備会公式Twitterアカウントが大々的にスタッフ募集を呼びかけたこともありましたし、 技術系即売会として注目度の上がってきた「技術書同人誌博覧会（技書博）」でも、 当日スタッフの募集には難儀しています*6。
技術書典7においては主催のmhidakaさんの考えもあり、 公にする形でスタッフの募集はしていません。 私としてはこの考えを真っ向から否定する気はありませんが（むしろ一理ある）、 このような事情から、先に挙げたコミケや技書博よりもスタッフが集めづらいのではないか、 と推察します*7。
技術書典6に向けて開催されたサークル連絡会での質疑応答より。確かに、一理ある。ひつじさん「現時点ではスタッフのストレッチは意志決定に時間がかかることなので考えておらず、やるとしたらイベント運営会社にサポートしてもらうことくらい。安全性に関わる部分は、仕組みでカバーしたい」 #技術書典
— なのなの (@nano2_aloerina) 2019年1月17日
その前提条件で今回は開催フロアが増え、物理的に面積が増えています。 面積が広がった分、スタッフ一人当たりの活動領域は広がりますし、負担も増えます。 その結果、場所によっては配置が手薄になってしまう場所が出てきてもおかしくはありません。 また、少ない人員で多くの参加者を相手にしなければならない状況も発生しうるでしょう。
2. スタッフのスキル
少ないスタッフでイベントを切り盛りするためには、最終的にはマンパワーに頼らざるを得ないのですが、 同人即売会スタッフに求められるスキルは特殊なものが多く*8、 「カンファレンスや勉強会のスタッフをやっていたから大丈夫」とも言い難いのが実情です。 先の「列の曲げ方、切り方、変形の仕方」や「複数列を取り扱うための知識」というのは天賦の才能でなんとかできるものでもなく、 適切な知識の学習と実現場での実践によって身につくものです。 技術書典のスタッフ（特にコアスタッフ）に同人即売会スタッフ経験者がどの程度いるのかは残念ながら分かりませんが、 イベントが成熟してきた今だからこそ、スタッフ一人ひとりのスキルについても考えた計画が必要なのかもしれません。
とり得る対応は
では、どのような対応がとり得たのでしょうか。
一番の理想はスタッフの数を増やし、個々のスタッフのスキルを上げることなのですが、 どちらも簡単にはいかないものでもあるので、現実的な対応としては会場規模を大きくしすぎないことを挙げたいと思います。 会場規模を大きくしすぎないことで、極力スタッフ配置が手薄にならないようにできますし、 少ないスタッフでもコントロールができる運営規模に抑えこむことができます。 代償として受け入れられるサークルの数が減ってしまいますが、 無理に背伸びしすぎて全体リスクを上げてしまうよりましではないでしょうか。
先日（といってももうだいぶ前になってしまいましたが）の発表にもあったとおり、 次回の技術書典8は開催フロアを1フロアに戻し、その代わりに2日間開催とすることで受け入れサークル総数を維持する選択を取りました。 「会場規模を大きくしすぎない」という観点から見れば、現実的かつ堅実な選択をしたものだと考えています （今まで1日しかやってきてないのに2日連続もスタッフもつの...？という心配は残りますが）。
まとめ
3回にわたり技術書典7を考察してきました（途中思いっきり間隔があいてしまい申し訳ありませんでした）。
イベントの規模が大きくなれば大きくなるほど、それまで些末だった問題点が大きくなってしまうのは避けられないことです。
そんな宿命を抱えつつ継続開催に尽力する運営スタッフのみなさんに感謝と尊敬の気持ちを抱きつつ、
今後もお互いが気持ちよく参加できるイベントとして維持されていくことを強く願って、
本考察シリーズを閉じたいと思います。
*1:大イベントが故に、あのような大きな会場でないと運営ができないという見方もできるでしょう。
*2:過去に主催が開催目前に蒸発した即売会もありましたが...
*3:ちなみに、カーブの内側と外側で移動距離に差が出るため、列を繋げたまま曲げる方が難易度が高いです
*4:このような列を通称「ショットガン」と呼びます。列を動かしたときの動きが似ていませんか？
*5:買い物に行ける時間を削ってまで協力したいと思う人がどのくらいいるのか、という問題
*6:当日スタッフの募集締め切りを延ばしました
*7:そのかわりに警備員の手配など、やれるだけのことはしていると思われます
*8:先述の技書博ガイドブックへの寄稿記事で、この点について少しだけ触れたことがあります
Electron使いがMuonをHello, worldしてみた
世間（というか渋谷）では本来の趣旨を大きく外したハロウィン騒ぎが盛り上がっている（？）今日この頃。
何でも書くブログについに純粋技術記事のネタが降臨です。
時代はWebベースのデスクトップアプリか？
私は過去にElectron*1というデスクトップアプリフレームワークを使ったアプリ開発の実践技術書を、 技術書典で頒布したことがあります。
次回（技術書典8）あたりでこれの改訂増補版を出そうと進んだり戻ったりしているのですが、 最近「ポストElectron」と言えるかも知れないデスクトップアプリフレームワークがあることをTwitterで知りました。
その名を「Muon」というそれを、Hello, worldして雑感をメモってみることにしました。
電子 vs ミュー粒子
Electronが「電子」だからなのか、それに対抗した（？）「ミュー粒子」*2というネーミングっぽいMuon。 Chromiumの代わりにUltralightというWebKitベースのエンジンを使うことで、 メモリ使用量の削減やファイルサイズの削減を狙ったデスクトップアプリフレームワーク*3です。 ElectronがNode.js（＝JavaScript）なのに対し、 MuonはGoで開発されています*4。
GitHubのコミット履歴を追う限りは、できたてホヤホヤの感じがしますね。
なにはともあれ、Hello, worldしてみる
リポジトリに記載のGettingStartedGuideに従って、サンプルプロジェクトを動かしてみます。 なお、実行環境は次の通りです。
$ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G103 $ go version go version go1.13.3 darwin/amd64 $ yarn --version 1.17.3
リポジトリをcloneする
手順に従って、リポジトリをcloneします。
$ git clone https://github.com/ImVexed/muon $ cd muon/examples/create-react-app
サンプルプロジェクトはReactで書かれているようです。 なお私はReactはド素人です（今回はゴリゴリ実装するわけじゃないからセーフ）。
Reactのプロジェクトをビルドする
サンプルプロジェクトをMuonで動かすためには、一度ビルドする必要があるようです。 Yarnを使って依存関係を解決して、ビルドまで実行してみます（この辺はReactのプロジェクトをビルドするのと一緒っぽいですね）。
$ cd public/ $ yarn # もしくは、yarn install $ yarn build
Go用にパッケージング・ビルドする
ガイドによると、ここからGoのパッケージャーでパッケージングしなくてはならないと書かれています。
ここがちょっと分かりづらかったのですが、要はfileb0xというパッケージャーを使えるようにしなさい、ということのようです。
手順としてはgo get github.com/UnnoTed/fileb0xでバイナリをダウンロードし、
ダウンロードされたバイナリがあるディレクトリ*5を環境変数PATHに設定する、
という2つの手順を行います。
その上でひとつ上のcreate-react-appディレクトリに戻り、
$ fileb0x b0x.yml
または
$ go generate
でパッケージング、その後go buildでビルドします。
Ultralightのライブラリを用意する
ここまでで一通りの準備はできているのですが、最後に手動で用意しなくてはならないものがあります。 Chromiumの代わりに使うUltralightのライブラリです。 ガイドには「リンク先からアーカイブをダウンロードして展開、自分でルートディレクトリに配置しなさい」とありますが、 実はリポジトリ内*6にちゃんと用意してあり、 それをそのままコピーして使えばよさそうです（動いたには動いたけどいいのか……？）。
ただしLinuxやMacOSの場合はルートディレクトリに置いただけではダメなようで（ここで長時間罠にはまった）、
環境変数LD_LIBRARY_PATHにライブラリファイルを配置したパスを設定する必要があります（Windowsはこの設定は不要らしいです）。
動かしてみる
いよいよ動かしてみます。
create-react-appディレクトリで、次のコマンドを実行します。
$ go run main.go
上手くいけば、新規ウィンドウが立ち上がってHello, worldに成功します。
気になったこと
事前にビルドしているからか、
run main.goコマンドで起動したときのウィンドウの立ち上がる早さはElectronで開発しているときと比にならないくらい早いですね。
しかしながら、事前ビルドだとホットリロードできないんじゃ……？という疑問もわいてきます。
一応README.mdには「Hot-reloading」がFeaturesとして挙げられているのですが、いまいちその方法が分かりませんでした。
ホットリロードができないとyarn buildとgo generateを毎回実行しなくてはならなくなるので、結構面倒です。
また、まだできたてホヤホヤということもあり不具合も多く （ウィンドウサイズを変えようとしたところフリーズしてしまい強制終了する羽目に）、 実用レベルで使うにはハードルが高そうです。 ほとんどはUltralight自身が未対応になっている部分が影響しているらしいので、 ここは時間が解決してくれるのを待つしかなさそうです。
あと、個人的にはReact以外も使えるのかちょっと気になります。Vue.jsとか。
まとめ
現時点では当然Electronの方に軍配が上がるわけですが、 今後未対応機能が対応されるにつれて、Muon自身の一番のウリとも言える「省メモリ」「省ファイルサイズ」が着目されて、 Electronの良きライバルになるかも知れません。 それを期待しながら首を長くして待ってみる、という感じでしょうね。
開発が進んでできることが増えてきたら、JavaScript - Go間の相互運用なども試してみようと思います。
*2:https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%A5%E3%83%BC%E7%B2%92%E5%AD%90
*3:の割には、質量的にはミュー粒子の方が電子より大きいということはツッコんだら負け？
*4:Goで開発されているとはいいつつも、JavaScriptとの相互運用性をうたってはいるようです
*6:https://github.com/ImVexed/muon/tree/master/ultralight/libs
技術書典7を導線から考察する（２）
お待たせしました。
技術書典7を導線から振り返る考察記事シリーズ、第２話です。
本シリーズの位置づけや執筆の意図、前回の考察は次の記事をどうぞ。
観点2. ホール混雑の偏り
何があったのか
今回の技術書典終了後、多くの方がTwitterや振り返りブログで触れていたのが 「2階・Dホールと3階・Cホールの混雑差」についてでした。 会期中に投稿されたツイートを眺めてみると
という内容が多く確認できました。
この傾向は（ツイート上ですが）閉会直前まで確認され、
3階・Cホールに配置されたサークルから
「思っていたよりも売れ残っている」「被チェック数*3よりも売上数が低い」
という声が聞かれた、とのツイートもありました*4。
これまで技術書典においてあまり見ることの無かった
「爆死」（想定以上に売れ残り在庫過多になってしまった）という言葉が多く飛び交っていたように感じます。
推察される背景
なぜこのような状況になったのでしょうか。
今回の技術書典では、複数ホールでの開催となることから「ホール間移動」が大きな課題になったと思われます。 多くの場合、ホールとホールの間をつなぐ通路は主催者専有物ではない共用エリア（公共エリア）となることから、 「他の利用者に迷惑を極力かけない形で、いかに参加者を誘導するか」 という難題が主催者にはのしかかり、 これをどう解決するかが運営のポイントになってきます*5。
これを解決するために運営事務局が踏み切ったのが次の施策でした。
1. 正面エスカレーターの使用禁止と、階段の一方通行化
ホール正面にあるエスカレーターは他の利用者も利用する可能性が高いと想定したのか、 技術書典参加者は上下階移動にエスカレーターを使うことができませんでした。 その代わりに、2箇所ある小さな階段を一方通行の形で使用する運用にしていました。
これについては「会場側から要請があったためこうせざるを得なかった」可能性も十分にあるのですが*6、 導線管理の観点から考えれば、この運用自体は賢明な判断だったと考えています。 エスカレーターは技術書典に関係しない他の利用者も使いたがる移動手段ですし、速度が一定なので参加者が殺到すると列ができてしまいます。 また、階段を下手に相互運用としてしまうとすれ違いによって通行の難易度は上がりますし、危険度も上がります。 参加者は目的地（サークルスペース）のことで頭がいっぱいですから、流れは極力わかりやすい方がよいのです。
ただし、今回は建物の構造上階段自体が非常に分かりづらいところにあり、 なおかつ会場内での掲示物*7やスタッフの案内が不十分だったために導線が上手く機能していなかったのではないかと推察されます。 「上下階移動をしたくても、正面に見えるエスカレーターは使えないし、それ以外の手段はその場から見えない」 「そもそも他のフロアもあるのかよく分からないまま会場を離脱しそうになってしまう」 そんな参加者もいたようです*8。
公式アカウントによる会期中の「2階⇒3階への移動方法案内」ツイート。ただし、会期中に確認できたのはこのツイートだけで、参加者には辛いと言わざるを得ません。#技術書典 入場後、2階ホールDから3階ホールCへ移動する際は場内出口付近の列までお越しください。一定人数ごとにスタッフが階段で3階へご案内します。https://t.co/0RgAh0Lqyr pic.twitter.com/3AkicF1po0
— 技術書典公式アカウント (@techbookfest) September 22, 2019
2. 2階⇒3階への移動制限
階段の一方通行化に加えて、 2階⇒3階への移動については「一定程度の人数がたまるまで通行を一時停止し、塊単位で階段を通行させる」 という運用（俗に「パケット運用」と呼びます）が行われていました。 （先のツイートを見れば、どのような運用がされていたのかは分かるかと思います）
運営としては3階・Cホールへの混雑集中を予測して、流量調整を行うためにこの施策を導入したのでしょう。 結果として3階の混雑度は押さえ込むことに成功したものの、自由な通行だった2階・Dホールと比べて3階にたどり着く障害となってしまい、 人の動きに明確な差が出てしまいました。 ちなみに、3階⇒2階への移動については特段の流量調整は行われておらず、 もっぱら3階の流量を重点的に抑えたかったのではないか、と推察しています。 というのも、サークルリストを見れば分かりますが、 3階・Cホールは通称「大ボス」と呼ばれている有名サークルがいくつか配置されており、 運営事務局としては相当な混雑を見込んでいたのではないか、と考えられるからです。
とり得る対応は
では、どのような対応がとり得たのでしょうか。
まずは「積極的な導線案内」でしょう。 先の背景でも述べましたが、3階・Cホールへの移動方法が参加者へ十分に伝わっていなかったことは確かで、 これに対処するには事前の案内以上に当日の案内が重要になってきます。 というのも、どのようなイベントでも「当日存在を知ってふらっと来た」という一般参加者は一定程度いるもの*9で、 しかも「カタログに相当するものを入場時の必須条件としない」運用*10にしている場合、運営から当日の導線を案内するものは現地の掲示物や、 スタッフの案内（特にスタッフ自らが声を出すアナウンス）がすべてになってしまいます。 加えて、事前の情報を入手していたとしても、 到着してから一番頼りになるのは現地の掲示物やスタッフの案内なのです*11。
矢印と行き先を書いた紙を壁に貼っておく、導線を示した看板を掲示する、 要所にスタッフを配置して声を出して案内する*12、その他いろいろな方法を組み合わせて、 現地で人が迷わないようにしたり、迷った人を救うことができるようにするのが理想的な対応ではないかと考えます。
もうひとつ、2階⇒3階への移動制限については 「予定に縛られない臨機応変な切替運用」で軽減が望めたのではないかと考えられます。 3階への移動制限を行うにあたり、どのような基準値を設けて運用していたかは当事者ではないため知るよしもありませんが、 日中の時間帯においてはそこまで厳しく制限するほどでもなかったように個人的には感じていました。 むしろ2階・Dホールの混雑を解消するためにも、3階への移動制限は極力限定的にして混雑を分散させるのも一つの選択だったのかなと考えています。 ただし、その塩梅を見極めるのはそれなりの経験を積んだスタッフでないと難しく、 そうなると予定に忠実な運用でも致し方なし、だったのかも知れません*13。
もしくは、待機させる場所を2階では無く3階の待機スペースから使うのも、 とり得る対応としてはあったかと考えられます。 つまり、2階⇒3階への移動は（列の幅は制御するものの）特に制限させず、 3階に上がったところでエリアの混雑を見ながら入場制限を行うスタイルにすれば混雑状況も見通し距離で確認できますし、 より混雑状況に応じた運用ができた可能性があります。 ただし、2階に待機列ができない分余計に3階へのルートが分かりづらくなるので、先に提言しているとおり積極的な案内が必要となりますが。
次回予告
今回も気がついたら5,000字近い読んでて辛い記事になってしまいました。 次回記事では運営スタッフの導線管理や誘導技術（Technic）を観点に考察する予定です。
*1:https://twitter.com/ryo_naka/status/1175609941618352129 や https://twitter.com/dsler/status/1175612524777000960 など。
*2:https://twitter.com/tenntenn/status/1175624202696527872 や https://twitter.com/mofukaburTech/status/1175632395124391936 など。
*3:公式サイトのサークルチェックリストでチェックされた数。技術書典は自分自身のサークルへのチェック数が分かるようになっています。
*4:https://twitter.com/erukiti/status/1175922121614082048 とはいえ、2階・Dホールも両手を挙げて喜べるサークルばかりではなかったようです
*5:コミックマーケットでは東京ビッグサイト全館を借りていなかった頃に公共エリアを専門に担当する「公共地区担当」という部署がつくられ、今でも存在しています。それほど公共エリアの管理は難しいのです。
*6:全館貸し切りでない場合、導線関係については占有や積極利用を禁止されることがままあります。
*7:出入口や配置記号の掲示は見かけたものの、矢印の付いた導線を示す掲示はほとんど無かったように記憶しています。
*8:https://twitter.com/alfe_below/status/1175627810678788096 や https://twitter.com/yamato_hal/status/1175678872286662656 など。
*9:実際のところ、それ以上に「何があるのかよく分からないけど来てしまった」来場者も結構いるのですが、それは会場外の話になるので割愛します。
*10:技術書典の場合、カタログに相当する『技術季報』はあくまで「運営へのお布施」であって、別に買わなくても入場は可能になっています。
*11:混雑した中でわざわざ地図を開くよりも、現地の案内を見た方が早いのは想像に難くないと思います。
*12:スタッフが立っている一番の利点は、自ら声を出して対応できることです。ただその場に立っているだけなら看板と変わりありません。
*13:危ない橋を渡るくらいなら、安全側に倒す方が良いのは当たり前でしょう。
