Magnolia Tech

いつもコードのことばかり考えている人のために。

2023年買ったもの(技術書以外)

2023年に買ったもの

技術書以外編

技術書編は、こちら

blog.magnolia.tech

WH-1000XM5

特に説明不要なノイズキャンセルヘッドホンの定番。それまで使っていたWH-1000XM3が完全に壊れてノイズキャンセルどころか、謎のノイズが出てしまう症状が出たため買い替え。

Bluetooth接続が圧倒的に早くなったのと、マルチポイント接続により同時に複数の機器と接続できるようになったのは、割と頻繁に接続先を変える自分はとても利便性が上がったので、それだけでも買い換える価値が有った。

ノイズキャンセルの効きも良くなり、地下鉄や飛行機などの、ノイズが多い移動手段が多い人にはぴったりの一台。

5万円を超える価格はオーディオ機器としてみるとちょっと高いけど、音楽鑑賞から、オンラインミーティングまでこれ一台でなんでもできてしまうので、コストパフォーマンスは非常に高い。一時はほんと朝から晩までずっと付けっぱなしで過ごしていた。

MDR-7506

自宅でのオンラインミーティングなどで、独立マイクも用意できるし、ノイズキャンセルが不要な場所ではこちらを使うようにしている。

有線の煩わしさは有るけど、軽いのと、充電を気にせず使える気軽さもいいし、どんな環境でも「とりあえずプラグを刺せば音が出てくる」という安心感は、とにかく安定しておいてほしいオンラインミーティング環境では必須。

これも複数のPCを使い分けることが多いので、その切り替えごとに、操作をしたくない、という観点で有線の安心感を選択。

ソニーのヘッドホンといえば、MDR-CD900STも惹かれたけど、接続がミニプラグの方が直接PCに挿せて便利なので、MDR-7506を選択。

TimeTimer

年齢が上がったせいか、だんだんと集中力の持続時間が落ちてきているなーと感じることが多くなってきたので、見やすいタイマーを導入。

厳密に、ポモドーロテクニックを使っているわけではないですが、15分とか、30分とか、「この決めた時間の間は集中する!」と決めると、それなりに集中力も持続するので、重宝しています。

何のギミックも無く、ただぐるっと手でツマミを回した分だけ時間を測る簡単仕様。

あと、デザインがかわいくて、机の上に置いておきたくなるデザイン。

Lenovo ThinkCentre M75 Tiny

今年だけで2台も買ってしまった。

www.lenovo.com

ここ数年色々なメーカーからミニPCが発売されていて、あまりの価格の安さに採算取れるのかな?と心配になるのだけど、サポート面などでの不安も聞こえてくる。

そのため、ちょっと価格帯は上がるけど、Lenovo純正の複数年サポートが付けられる安心感を優先して選択。

主な使い方は、プリインストールされているWindowsを完全に消去して、Linuxをインストールして、個人の開発環境用。 やっぱりWSLより、素のLinuxが動く環境が有った方が余計な苦労をしないで済むのが楽だし、一台の高スペックPCより、複数台のミドルスペックPCの方がコストパフォーマンスも良い。

Lenovoの場合、Linuxからでもファームウェアアップデートが可能なところもオススメのポイントの一つ。

若干ファンが煩いので、普段はテレビボードの下にしまい込んでリモートアクセスでしか使わないけど、そういう使い方ができるのもミニPCの良いところ。

Keychron Q60

Keychron Q60 QMK Custom Mechanical Keyboard – Keychron | Wireless Mechanical Keyboards for Mac, Windows and Android

Keychronから出ているHHKB完コピメカニカルキーボード。

本家は、HHKB Studioを出したけど、割とギミック多めで、それは特に要らないかも...という人向け。

とにかくシンプルなデザインがイイ!有線専用のQ60は既に終売になっていて、今は無線と、更なる静音化のために構造が見直されたQ60 MAXが現行モデルになっています。

なお、本家より便利なのは、Win-Macの配列変更のスイッチがあるところで、これが有るだけでも日常的にWindows機と、Macを切り替えながら使っている自分にとっては最高の機能です。 本家のディップスイッチ方式はさすがになーと思っていたので

今のところ、キーキャップと、スイッチを交換していて、この組み合わせの打鍵感が過去最高に気に入っているので、当面はこの組み合わせ使っていくと思います。

Keychron Q60 Max QMK/VIA Wireless Custom Mechanical Keyboard – Keychron | Wireless Mechanical Keyboards for Mac, Windows and Android

Kailh Clione Limacina Switch tactile

CHERRY INDUSTRIAL KEYS

Cherry Industrial Keysnovelkeys.com

Kailh Midnight Silent V2 Switch / Tactile

Kailh Clione Limacina Switch tactileの打鍵感は最高なのですが、周りに人が居るような環境だとちょっと使うのを躊躇するくらいの軽快な打鍵音が響いてしまうので、そんな時は、同じKALIHのMidnight Silent V2というスイッチを使っています。

KEEBMAT Premium Felt Edition

キーボードと、トラックパットをまとめてデスクマットの上に置きたいので、KEEBMATのKEEBMAT Premium Felt Editionというのを導入しました。

KEEBMAT™ Premium Felt Edition (incl. Free Coaster!)

KEEBMATは、小型キーボードのサイズにぴったり合わせたキーボードマットが有名ですが、フェルトエディションの一番大きなサイズは、完全にデスクマットとして使える大きさで、お勧めです。

ただし、アイロンが無いと綺麗に平らにならないので気をつけてください。

Lamy2000 4色ボールペン

定番中の定番ですが、定期的に書い直していて、通算3本目を買いました。

どんなにPCやスマホタブレットが進化しても、ボールペンの書き味からくるフィードバックにはまだ敵わないんですよね。


まだまだ買ったものが有った気もしますが、ついにキーボード沼にハマったな……というのが今年の一番のトピックですね


2023/12/30 追記 はてブでコメントいただいたので追記

  • WH-1000XM5のマイク WH-1000XM3を買ってしばらくしてからコロナ禍が始まり、オンラインミーティングの環境がイマイチ揃えられなくてしばらく不便な音声環境が続いていた。でもある日「あれ?これ、もしかしてノイズキャンセル用のマイクで通話もできるのか!」と気づいて以来、WH-1000XM3をミーティング用に使うことで劇的に通話環境が改善されたので、さらに音声用マイクとしての改善が反映されているというのも、WH-1000XM5に決めた理由の一つだった。

    www.sony.jp

  • HHKBライク配列のMacと、Windowsの日本語入力について

    Windowsの方でのローマ字入力と、英字入力の切り替えを「CTRL+Space」に設定しておくところがポイントです。これでWindowsMacで同じキー操作になります。あとは、Spaceキーの横のキーをWindowsモードの時はALTキー、Macモードの時はCommandキー、その更に横をOptキーになるように配列を変更しておけば完璧です。それぞれのOSに適した配置になるので、操作性がキープできます(そもそもWindowsはCTRL、MacはCommandになっているショートカットは慣れましょう、でしかないですが)


2022年版はこちら

blog.magnolia.tech

『実践プロパティベーステスト』の例題をScalaで解いていく その3

『実践プロパティベーステスト』の例題をScalaで解いていくシリーズの第3回目です。

前回は、テストが失敗して、収縮した結果を確認する、という内容でした。

blog.magnolia.tech

今回は第3章に入ります。


初めてプロパティベーステストを書き始めたとき、サンプルコードだけを見て、「なるほどこう書けばいいのか!」と納得して書き始めたものの、すぐにピタっと手が止まりました。それは、「テスティングフレームワークが提供するAPIは分かった、でもそれを使ってどんなテストを書けば、プロパティベーステストになるのか?」...このとっかかりが分かりませんでした。

色々なテストコードの事例を見ながら、実際に自分で書いてみて少しずつ感覚をつかんでいきましたが、やはり何らかのとっかかりが有ると理解が早く進みます。


第3章「プロパティで考える」では、以下の4つの観点でプロパティベーステストを書くときの観点を紹介しています。

  1. モデル化

    テストしたいコードと同じ振る舞いをするコード(たいてい効率が悪い)と、結果を比較する手法です。 ビジネスロジックのような固有の振る舞いをコードに落とすような場合には、モデル化できるものは少ないと思いますが、汎用的なライブラリや、他の言語の実装から移植などでは有効です。

  2. 事例テストを汎化する

    これが一番分かりやすい取り組み方と言えます。通常のユニットテストを書いてみて、そのパターンを元に抽象化を行い、プロパティベーステストとしてまとめていく手法です。例えばリストの要素がゼロの場合、一つの場合、二つの場合...と増やしていったときに、その長さに依存しないような抽象化ができれば、プロパティベースのテストとして実装できます。

    ユニットテストベースのテストを考え、そこから抽象を見出す……という流れが遠回りにも感じられますが、具体的なテストから出発する分、結局これが一番早く、確実な手法と言えます。

  3. 不変条件

    一つのテストですべてをカバーするのではなく、複数のテストを組み合わせて、そのコードの振る舞いの確からしさを総合的に判断するための手法です。それぞれ分解した観点ごとに、不変条件(必ず満たさなければいけない条件)を特定し、それらがすべてテストをパスすれば、コード全体としての確からしさが確認できた、と言えるところからの発想です。

    何をもって不変条件が網羅したか?と考えるのは非常に難しいですが、一つの指標としてテストのカバレッジによる判断は有効であるといえるでしょう。

  4. 対称プロパティ

    JSONライブラリのような、エンコーダと、デコーダがセットで提供され、変換⇒再変換により元の結果に戻れば、その結果の正当性が確認できる、という手法です。

    適用できる場面は限られますが、適用できる場合は確実な方法です。

Scalaへ移植していく

本の中で紹介されていたbiggest関数をScalaに移植します。

package Pbt

object PbtHelper:
  def biggest[A](list: List[A])(using Numeric[A]): A =

    def go[A](l: List[A], m: A)(using Numeric[A]): A =
      val num = summon[Numeric[A]]

      (l, m) match
        case (Nil, i)    => i
        case (h :: t, i) if num.gteq(h, i) => go(t, h)
        case (_ :: t, i) => go(t, i)

    go(list.tail, list.head)

再帰とパターンマッチで書き直すと、割とさっぱりと書けます。 また、特定の型に依存したくなかったので、比較関数を提供するNumericを継承している型に限定して指定できるようにusing Numeric[A]の指定を入れています。ネストされた内部関数にまでusingは効果を及ぼさないので、内部関数の中でも指定しています。

summonはScala3から導入された関数で、usingの引数に型のみを指定した場合に、具体的なインスタンスを取得します。

この辺りの仕組みは、以下の公式ドキュメントに詳しく書かれています。

docs.scala-lang.org

次にテストを書いていきます。エンコードと、デコードは、ちょっと面倒だったので、circeで雑に済ませてしまいました。

import org.scalacheck.Properties
import org.scalacheck.Prop.forAll
import org.scalacheck.Arbitrary.*
import org.scalacheck.Gen.*

import Pbt.*

import io.circe.syntax.*
import io.circe.Json

object PbtTest extends Properties("Pbt Test"):

  property("最大の要素を見つける") =
    forAll(nonEmptyListOf(arbitrary[Int])): (x: List[Int]) =>
      PbtHelper.biggest(x) == modelBiggest(x)

  def modelBiggest(list: List[Int]): Int = list.sorted.last

  property("最後の数を選ぶ") =
    forAll(listOf(arbitrary[Int]), arbitrary[Int]): (list: List[Int], knownLast: Int) =>
      val knownList = list :+ knownLast
      knownLast == knownList.last

  property("ソート済みリストは整列したペアを持つ") =
    forAll(listOf(arbitrary[Int])): (list: List[Int]) =>
      isOrdered(list.sorted)

  def isOrdered(list: List[Int]): Boolean =
    list match
      case h1 :: h2 :: t => (h1 <= h2) && isOrdered(h2 :: t)
      case _ => true // 2要素未満のリスト

  property("ソート済みのリストはサイズを維持する") =
    forAll(listOf(arbitrary[Int])): (list: List[Int]) =>
      list.length == list.sorted.length

  property("何も要素が追加されなかった") =
    forAll(listOf(arbitrary[Int])): (list: List[Int]) =>
      val sorted = list.sorted
      sorted.forall(x => list.contains(x))

  property("何も要素が削除されなかった") =
    forAll(listOf(arbitrary[Int])): (list: List[Int]) =>
      val sorted = list.sorted
      list.forall(x => sorted.contains(x))
 
  property("対称的なエンコードとデコード") =
    forAll: (l: List[Map[String, Int]]) =>
      val encoded = enocde(l)
      l == decode(encoded)

  def enocde(o: List[Map[String, Int]]): Json = o.asJson
  def decode(j: Json): List[Map[String, Int]] = j.as[List[Map[String, Int]]].getOrElse(Nil)

『実践プロパティベーステスト』の例題をScalaで解いていく その2

blog.magnolia.tech

前回に続いて、ScalaCheckによるプロパティベーステストを書いていきます。

失敗するテストを書く

当然すべてのテストが一度で成功することは有りません(一発で完璧なコードが書けるなら、そもそもテスト書かなくてよくなってしまいます)。

ScalaCheckでテストが失敗するとどうなるか見てみます。

まずは、第2章の例に倣って、テストが失敗するコードを書きます。

def biggest[A](list: List[A]): A =
  list.head

必ず先頭の要素を最大として返却しているので、いかにも失敗しそうです。

対応するテストコードを用意します。標準コレクションのsort機能を使ってソートした結果の最後の要素を最大として取り出します。

property("最大の要素を見つける2") =
  forAll(listOf(arbitrary[Int])): (x: List[Int]) =>
    PbtHelper.biggest(x) == modelBiggest(x)

  def modelBiggest(list: List[Int]): Int = list.sorted.last

実行すると、テストが失敗しました。

sbt:pbt> test
failing seed for Pbt Test.最大の要素を見つける is oSzCiQZYscT-yK1oib2eve7Ls7uAmFa3cNYxkn7YJdK=
[info] ! Pbt Test.最大の要素を見つける: Falsified after 7 passed tests.
[info] > ARG_0: List("0", "1")
[info] > ARG_0_ORIGINAL: List("1", "-1", "1773528742")

ARG_0_ORIGINAL: List("1", "-1", "1773528742")が実際に失敗したテストですが、よりシンプルなARG_0: List("0", "1")というパターンが出てくることで失敗した理由がより分かりやすくなっています。これが収縮です。

『実践プロパティベーステスト』の例題をScalaで解いていく その1

今年読んだ技術書のベスト3を選べと言われたら、間違いなく『実践プロパティベーステスト』を取り上げます。

日本では過去に類似の本も出ていないし、これからもプロパティベーステストだけで1冊の本が出版される可能性も限りなく低いことを考えると、さっさと読んでおいた方がいい1冊と言えます。

記載されているサンプルコードをそのまま写経して動かすだけでも学びはあるけど、やはり何らかの変化が有った方がより学びが深まる。

ちょうどこの本に興味を持つきっかけがScala用のプロパティベーステスティングフレームワークであるScalaCheckに興味を持ったタイミングだったこともあって、ScalaCheckベースでサンプルコードを書き直していきながら、調べたこととかをつらつらと書いていきます。

scalacheck.org


プロパティベーステストは、テスト対象のコードが備えるべき特性(プロパティ)の定義と、それを検証するために利用するテストデータの生成を分離することで、コードを書いた人が想定しなかったコードの不具合を特定するためのテスト手法です。

しかし、抽象的な思考が求められる手法のため、プロパティベーステスト用のテスティングフレームワークのサンプルコードだけでは、なかなか実践的なテストコードの書き方を習得するまで至るのは難しく、とにかく他人が書いたテストコードを読むか、自分で書いてみて発見していくしかなかったので、このような本の登場で実践的な書き方が早く身に付けられる道筋ができたのは素晴らしいことです。

ではさっそく始めていきます。


テスト環境の整備

まずはScalaのScalaCheckの実行環境を整備します。

ScalaCheckは、各種Scala用のテスティングフレームワークの中から呼び出して使うこともできますが、ここではScalaCheck自体をテスティングフレームワークとして使い、sbtからtestコマンドでテストが実行される環境を用意します。

テンプレートからのプロジェクト作成

Scalaの新規プロジェクトの作成方法はいくつか有りますが、ここではsbt newコマンドでGiter8形式のテンプレートから作成します。

% sbt new scala/scala3.g8
name [Scala 3 Project Template]: pbt

Template applied in /path/to/./pbt

% cd pbt

テンプレートから作成されたbuild.sbtにはテスティングフレームワークとしてmunitが指定されていますが、これをScalaCheckに置き換えます。

-    libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test
+    libraryDependencies += "org.scalacheck" %% "scalacheck" % "1.17.0" % Test

また、不要なサンプルコードのファイルを削除しておきます。

% rm src/test/scala/MySuite.scala
% rm src/main/scala/Main.scala

sbtは、最新のバージョンが使われるようにリリースされているバージョンを確認して、必要に応じてproject/build.propertiesを書き換えてください。

Releases · sbt/sbt · GitHub

2023年12月27日時点の最新バージョンは、1.9.8です。

最初のプロパティベーステスト

まずは、「1.4 プロパティを実行する」の例にならって必ず成功するテストを例に始めていきます。

(なお、以降のコードは全てScala 3.3以降でサポートされたFewer Braces記法で書かれいるため、従来のScalaのコードとはずいぶん見た目が異なっています)。

src/test/scala/PbtTest.scala

import org.scalacheck.Properties
import org.scalacheck.Prop.forAll
import org.scalacheck.Arbitrary.*

object PbtTest extends Properties("Pbt Test"):

 property("always works") = forAll(arbitrary[AnyVal]): (a: AnyVal) =>
    boolean(a)

  def boolean(v: AnyVal): Boolean = true

上記のコードをテストとしてsbtから実行します。

$ sbt
...(省略)...
sbt:pbt> test
[info] compiling 1 Scala source to /path/to/pbt/target/scala-3.3.1/test-classes ...
[info] + Pbt Test.always works: OK, passed 100 tests.
[info] Passed: Total 1, Failed 0, Errors 0, Passed 1
[success] Total time: 3 s, completed xx xx, xxxx, xx:xx:xx xx

100回のテストに成功し、Pbt Testというテストが成功したことが分かります。

見れば分かるレベルの内容ですが一応解説をしておくと…

  1. Propertiesを継承し、テストオブジェクトを作成

    Propertiesへの引数がそのままテスト全体の名称になります。

  2. 具体的なテスト内容は、propertyで定義

    慣れないとちょっと引っかかる記法ですが、Mapの更新にも使われるupdateメソッドへの糖衣構文と同じです。

    内部実装としては、propertyという変数を経由してPropertySpecifierというクラスのupdateメソッド呼び出しに変換されますが、利用者側では気にする必要はありません。(Map以外で出てくると、ちょっとアレっ?と思う、Scalaの独特な記法だと思っています。)

  3. forAll関数の引数には、ランダムに生成されたテストデータを引数として取り、Boolean型の結果を返すコードブロックを渡します

    標準コレクションでもおなじみのforAll関数は、要素の中に一つでもfalseとなるものがあれば全体をfalseと判定します。つまり、たくさんのテストデータが自動生成された結果、一つでもテストの結果が失敗すればテスト全体が失敗した、とみなされます

    ScalaCheckのプロパティベーステストは、以下の形式で書くことになります。

    forAll(ジェネレータ): (コードブロックへの引数) =>
    ...
    ...
    Booleanを返すコード
    

    最後はBoolean型を返すため、a == bといった、テストの真偽を判定するコードを書く形式になります。

  4. ヘルパー関数として、booleanという関数を用意

    本書のサンプルに従って、ヘルパー関数を用意しました。引数として渡された変数の値に拠らず、必ずtrueを返します...結果としてテストは必ず成功します

    なお、先ほどのコードでは、本書に出てきたあらゆる型のデータを任意に生成してくれるany()のような便利ジェネレータがScalaCheckには無かったので、任意のAnyVal型のデータを生成するようにしていますが、本質的な意味は変わりません。

  5. ジェネレータは省略可

    ScalaCheckはジェネレータは省略可となっています。続くコードブロックの引数の型から型推論可能な場合は、自動的に型に合わせたジェネレータが選ばれます。そのため、先ほどのコード例は、以下のように書き換えることができます。

      property("always works") = forAll: (a: AnyVal) =>
     boolean(a)
    

デフォルトでは100回のテストが実行され、このコードサンプルでは全てのテストが必ず成功します。


とりあえず、テストが通る環境までは作ることができました。

『プロフェッショナル IPv6 第2版』で現代インターネット技術を支える基礎知識のおさらい中

すっかり見えないところで当たり前のように使っているはずなのに今一つ理解が不完全なまま来てしまったのが「IPv6」。家のインターネット環境を一新したときに色々と調べたはずなのに、すっかり忘れてしまったので『プロフェッショナル IPv6 第2版』の紙版を購入して勉強しなおしています。

470ページに渡って、「そもそもIPアドレスとは?」から始まり、IPv6を学ぶために必要な情報が全部詰まっている、ほんと全部入りです。

個人的には、「ip a」コマンドを叩くとアドレスっぽいものが複数出てくるけど、これ何?という疑問が解消したのと、DNS周りの仕組みが分かったので、非常に役に立ちました。

最近は、自宅インターネット環境にフレッツを使っていないのでNTTのNGN固有のIPv6事情には影響されることもないのですが、背景が興味深かったですね。


そしてこの書籍の凄いところは、電子書籍版はなんと無料で読めること。

企業スポンサーや、クラウドファンディングにより実現したそうです。

booth.pm

筆者への応援のため、価格付きのページも用意されています。

professionalipv6.booth.pm


IPv4を分かっていると、何となく分かった気になってしまうIPv6……本当はしっかり理解しないといけないけど、どこから手をつければいいのか分からない……そんな時に、本書は体系的に理解するための最高の書籍で、かつ無料でも読めてしまうので、読まない理由がないです。年末年始のまとまった時間にぜひ読みましょう。

関心の非対称性について

いろいろな設計方法論とか、良いコードを書くためのお作法とか、最近だと書籍もたくさん出ていて、無限に勉強することができるのだけど、勉強ばかりしている訳にもいかず、われわれは目の前の課題を解決するためのコードを書いたり、納品するためのコードを書いたり、なんのために作っているのか分からないプロダクトのコードの断片を指示通りに書かされる日々と向き合っていかないといけない、という現実があるわけで、つまり時間は有限なのです。

という中で、いつも気にしていることと言うか、忘れちゃいけないなーと思っているのは、その方法論が「何の問題を解決しようとしているのか?」というところで。

人の関心は偏在している、人と人の関心の対象には非対称性がある……そんな状況の中で、その関心の方向性を合わせていくために方法論が有って、それは「ほんのちょっと目線をずらしくれるもの」くらいに捉えておくといいんじゃないかなと思っている。

ただ、カリスマみたいな人が上手く全体をまとめてくれて、進むべき道をバシ!っと示してくれる時も有って、それはそれで凄いけど、再現性がある場合とない場合があるからなー。

プロジェクトにおいては、関わる人々がその立場や、価値観は違えど、とりあえず同じ方向を一回は向いておくことが大事なのだけど、勝手に同じ方向を向くことは全体に無くて、「ここが大事ですよー注目ー」と言って、目線を向かせるために権威に頼った方が手っ取り早いときもあって、そんなときに「ほら、この本にこんなやり方が書いてあるよ」っていうやり方が有効な場面ってあるんですよ、万能ではないけどね。

だから、方法論だけを取り上げて、良いとか悪いとか、時代遅れとか、言ってもなーって思った祝日の午後なのです。


まぁ、でも、あひるさんのこのツイートがもっと良い言語化だった。

『技術カンファレンスのマスターガイド:企画から運営までの完全手引き』は、すべてのテックイベントに興味がある人が読むべき1冊です!

技術書典15、あまり内容をチェックしていなかったので、行く予定を入れていなかったのですが、941さんが執筆に参加したカンファレンスの運営本が出品されていて、しかも会場しか紙版は入手できないと分かって、急遽時間を作って現地で入手しました

しかも、事前にページ数を知らないで現地に着いたので、「所謂”薄い本”じゃないの?」とその場で驚愕した、なんと200ページ超え!

11月26日までオンラインで電子書籍版は入手できるそうです、まだ入手していない人は、ハリーアップ!

techbookfest.org


自分でも9年ほど吉祥寺.pmという50人規模の勉強会を定期開催したり、YAPC::Tokyo 2019にスタッフ参加したりと、イベント開催にはそれなりの経験があるほうだと思っています。

kichijojipm.connpass.com

が、ここまで圧巻の物量で、あらゆる要素に対するポイントが網羅されていると、「なるほどなー、これは考えたことも無かった」「これをこう言語化するのかー」とたくさんの学びがありました。言語化、大事ですね。

特に、準備を進めるにあたって起きえるトラブル、当日発生するトラブル事例が充実しているのが、めちゃめちゃ価値ありです。当然、イベントは準備が8割なので、企画を考え、実現に向けてどんなステークホルダーを巻き込むか、当日までにどんな準備をすべきか、ということにページの大半が使われています。1,000人規模のカンファレンス、こんなに考えることがあるのか!と運営に参加していた自分ですら驚いてしまいます。特に、「参加者の受付設計」は小規模なイベントには小規模なりの悩みがあり、大規模なイベントには大規模なりの悩みが有って、なかなか難しいのですが、けっこうイベントの成否の中で受付時の印象って残るものなので大事なので、「そうだよなー」って読んでました。

たとえば、「電源確保」あたりは会場に有るPCの量が多いテックカンファレンスでは必須のチェック項目ですね。

全編にわたって、カンファレンス運営というさまざまな人が関わる営みにおける気遣い、配慮、先回り、感謝が溢れています。これがすぐに真似できるものでもないし、中には100人を超えるようなカンファレンスじゃないと関係ない、といえることも多いですが、感覚的には20人〜30人規模の、「ちょっと一人だと手に余るくらいの規模」のイベントをやる上では絶対にチェックしておいた方がいい内容ばかりだと思います。

最後に、「昨今の事情による著者見解」という一枚の差し込みが有ったのも良くて、最後まで気配りだなーと。


というわけで…

  • カンファレンスをまだやったことないけど、開催に興味がある人 →今すぐゲットして備える!
  • カンファレンス開催に一定の経験が有る人 →今すぐゲットして自分の観点に漏れがないか確認する!
  • カンファレンスに参加経験の有る人 →今すぐゲットして、イベント開催の裏側を知ってより楽しむ準備をする!
  • カンファレンスに参加も開催もしたことが無い人 →とりあえずゲットしておいて未来に備えよう!

ほんと商業出版でも全然通用するレベルですね、絶対に入手できるうちに入手した方がいいですよ!


ちなみに吉祥寺.pmの運営に関するスタイルは、コロナ禍前ですが、以下のようにレポートいただいたことがあります。

kondoyuko.hatenablog.com

こんな形でまとめていただくと自分でも意識せずに運営の工夫をやっていたんだなーと思い出しましたが、運営として工夫すべきところ、気を遣うべきところはありますが、一方でイベント運営自体が本業ではないので、そこはいかに省力化を図っていくか?というのも大事なポイントなんですよね。色々な意味で継続性が有って、燃え尽きないようなやり方、仕組みが大事です。

この本に書かれていることは、めちゃめちゃ参考になりますが、一方で「自分にとっての運営のやり易さ」と、「参加者の満足度」のバランスはきちんと見極めていかないといけないなーとも思いました。