【感想】大吉祥寺.pm 2026 #kichijojipm に参加して「テックカンファレンス三大ステークホルダーの文化人類学」のお話をして、感じた事、考えた事、そして"大吉祥寺エフェクト"

大井町で開催の大吉祥寺.pm 2026に前夜祭・本編あわせて大いに楽しませていただきました。

kichijojipm.connpass.com

kichijojipm.connpass.com

自分の発表について

bash0c7official.fanbox.cc

Problem vs. Usの構図は常にリファレンスとして自分の中にもってまして、

https://www.slideshare.net/slideshow/project-facilitation-at-kanazawarb/17908886#74

すれ違いやコンフリクトを感じる時って、一緒にみるべきコトではなく、相手を見てしまっているのではないかと思っていて、その気配をカンファレンスという場を成り立たせる営みからときに感じ取っていたのでした。

それとともに、それぞれが無意識に信じているゲームのルールがあって、それぞれのルール自体は論理的に整合が取れている「正しい」もの。そうだからこそ、それぞれ違ったルールを見ていることに気がつかない。

それらを解きほぐすと個別課題は対話しつつ、総合的には上々なエコシステムを発展させられると信じています。

「日常がまず頑張りどころ」

こんなことをしなくても、エンジニア採用広報業務としてテクニカルに「成果」を出すメソッドはあるかもしれません。

しかし、ファンダメンタルな技術的組織競争力をつけるには日々の積み重ねでコミュニティーの一員として支え、支えられるを繰り返すことが遠回りにみえて近道と信じています。

何らかお手伝いできればとも思いますので、X: @bash0C7、BlueSky: bash0c7.bsky.socialなどでコンタクトいただければと思います。まずはご相談からお気軽に。

また、コミュニティーやカンファレンス側のスポンサー担当スタッフ業ももしマッチしそうであれば、ご相談くださいませ。

「コミュニティとは誰か。もちろん、あなたのことだ」

magazine.rubyist.net

今回はセッションの語り口として、運営とか登壇者とか、そういうロールで話をしましたが、実際のところは、運営という人もスポンサーという人もいなくて、運営のだれそれさん、スポンサー社のだれそれさんという個人なんですよね。

なので、個別事案についてはコミュニティーの一員同士の人と人として対話としていくのがいいと思います。人と人は対話ができるわけですからね。コラボレーションですからね。

セッションをきいて感じた事、考えた事

久々にX postを多くしていたので、そこからピックアップして補足を書き添えておきます。

#kichijojipm いや〜"わかりません"の怖さはいつもあるなあ。最近は「おしえてください🤝」って言い回しにしてる。

— bash (@bash0C7) 2026年7月25日

"こんな事もわからないの？"って言われちゃわないかなっていう気持ちわかります。とはいえその想像にメゲて黙ってるとかわかったふりとかはさらに辛いので、わたしなりの工夫として教えを乞う言いまわしをしています。

いい資料があれば示されるだろうし、説明もいただけるだろう。そして実はわかってませんでしたという人も助かる。お得です。

#kichijojipm タイムリープ社の幕間スライドのインパクトすごい

— bash (@bash0C7) 2026年7月25日

スポンサーをする場合、他のスポンサーと比べて自社をどのように参加者から思って欲しいかというのが大事なテーマになってきます。

きっと記憶に留めさせたいという思いがあってこういう方向性にしたんだろうなと推測しました。

#kichijojipm 正統的周辺参加、わかるー！

— bash (@bash0C7) 2026年7月25日

コミュニティー活動だけでなく、チームでの属人性解消でも正統的周辺参加は活用できて、SECIモデルでの暗黙知-暗黙知の伝え方のひとつと思ってます。 属人性解消というと言語化するという活動が選ばれることが多いとおもってて、これはもちろん必要なものの、振る舞いの中での本当に大事なことはそう易々と言葉にできないものです。

#kichijojipm 2018年スタートで9年目になるんだ。2018年ってこないだと思ってた...

— bash (@bash0C7) 2026年7月25日

今は今で今からやるのはどうしようかなと思っていても、過去も過去で同様のことを思っていたはず。もし2018年にそれをはじめていればそうかもう9年目という年月を重ねられたんだという事実に慄いたのでした。

#kichijojipm 初手アウトプットはAIでシフトレフトしたので、理解を作る道筋は大きく変わったのは感じます

— bash (@bash0C7) 2026年7月25日

今までは理解が初手のアウトプットの制約でしたが、今は自分の理解を超えた初手のアウトプットがでてきます。それゆえ理解してから作るのではなく、作ってから動かしつつ解体しつつ学ぶという、シフトレフトと順序の逆転があるなと感じたのです。

なおリリースとなると、自分の理解が制約になるのはかわらないわけですが、AIでわたしの理解が直接上がるわけではなし、脳みそに刺激を与え続けるほかないのです。

#kichijojipm 間に合いますかじゃなく、間に合わせんだよというのわかる。いや、ほんと、左寄せるはほんとそれ。

— bash (@bash0C7) 2026年7月25日

パーキンソンの法則に囚われたこの世の中。

www.murc.jp

結局時間あれば時間の分だけ使ってしまうので、「やる」ことによって実現にアプローチかけるのがはやいと思っています。別に、アレを倒してしまっても構わんのだろう?の気持ちでもあります。

そもそも見積もりなんて机上の空論。実際にやってみて乖離をみて、ではどうするかという話で、大変納得度が高かったです。

#kichijojipm この徳目はテック界隈の職業的なクラフトマンシップになってる気がするんだよなー

— bash (@bash0C7) 2026年7月25日

主従のような雇用から変わってきた今ですが、忠義というのは今もあると思ってます。 どこに忠義をおいてるかというと、わたしにとって一番には職業倫理・クラフトマンシップにあるのではと思ってて、この本を買い直したところでした。

ソフトウェア職人気質: 人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series 別巻 7)

#kichijojipm いまのこのへんの界隈の雇用流動性ってかつてのストライキに似た効果にもなってる？

— bash (@bash0C7) 2026年7月25日

ストライキというのに直接は縁がないんですが、雇用流動性が高まっているのは色々思うところはありつつ、いわゆる労使関係の健全化のひとつとして作用してる部分もあるのかなと思ったのでした。地位保全を選ぶも、距離をとることも、オプションあるのはありがたいですね。

大吉祥寺エフェクト

kaigieffectという言葉がありまして、

#rubykaigi やRegional RubyKaigiへ参加したことが何か(転職や勉強会の参加、新しい人たちとの関わり合いとか)のきっかけになった!という方は #kaigieffect をつけてtweetしていただけるとありがたいです http://t.co/QFUXnEq

— Koji Shimada (@snoozer05) 2011年7月14日

これは様々なきっかけであるよね、そういうのを増やしていきたいよねという話を懇親会でしまして、自分なりのことを書き記しておきます。

今回の大吉祥寺.pm 2026を経てのこととして、抽象的なんですが、自分自身に刺激を得て、何かを生み出して、発信してを繰り返していこうという思いを強化しました。とくに刺激のところですね、新しいことに触れていく機会をつかんで面白がることがどうもこの先大事だなという思いをしたので、とにかくやってみるをしようと思いました。

実機なしプレビュー対応の PicoRuby 版 Badger 2040 e-ink名札を作った

e-ink を搭載したバッジ型デバイス「Badger 2040」。以前、これをプリインストールのOSではなくPicoRubyで動かせるようにした話をまとめました。

retrospective.hatenadiary.com

今回は、先だってPicoRubyにこのデバイスで使われているe-inkコントローラー UC8151 のドライバーmrbgemが組み込まれたので、自分好みのデザインで名札を描画し、ボタンでパターンを切り替えられるようにしました。さらに、開発を劇的にスムーズにするため、「実機を使わず、Mac上で完全に同じ見た目のプレビューができる仕組み」も作り込んだのでご紹介します。

主な特徴は以下の通りです。

1. Macだけでレイアウトを完全プレビューできる
2. 最大3つのデザインパターン（A, B, Cボタンに対応）を切り替え可能*
3. 電子ペーパーの特性を活かした「普段は電源オフ」運用

アプローチ

このシステムは、以下の4つのアプローチで実現しています。

マイコン上と同じ方式をMacで使った高精度プレビュー

Mac上で実機と全く同じ128×296ピクセルのプレビュー画像（PNG）を書き出せます。

FemtoRubyと一式をMac向けにビルドして動かしています。そして、実機と同じCコードでメモリ上のフレームバッファにだけ描画し、SPI転送は行わずにそのVRAMバッファの生データを取り出してPNGに変換するということをしています。

ボタンa・b・cに対応した3パターンの切り替え

Badger 2040の左側にある物理ボタン（A, B, C）に、最大3つのデザインパターンを紐付けられます。

profiles/ 配下に以下のようにファイルを置くだけで、対応するボタンのハンドラがビルド時に自動生成される仕組みです。

profiles/
pattern_a.rb ← ボタンaに対応
pattern_b.rb ← ボタンbに対応
pattern_c.rb ← ボタンcに対応

なお存在しない場合は何もしません。

e-inkならではの「電源ON/OFF」設計

e-inkなので一度描画すれば、電源を切っても表示が残り続けるという特性があります。そのため、電源を入れるときは書き換えだけです。

不用意にe-inkを消さないように、電源ケーブル(USBケーブル)挿して通電したのち、ボタンをおしたら画面初期化と描画を走らせるという動きになります。描画が終わったらケーブル抜くだけ。

お試しください

github.com

matz/spinelでビルドしたネイティブライブラリをiOSのPicoRuby（R2P2-darwin）で動かしてベンチマークをとった話

matzが開発しているRubyのAOTコンパイラ「spinel」をPicoRubyで利用する試みの続きです。

retrospective.hatenadiary.com

R2P2-darwin という舞台

今回はiPhoneでの動作に挑戦しています。

R2P2-darwinは、PicoRubyをAppleのプラットフォーム（iOS / macOS / watchOS）で動かすためのプロジェクトです。今回触ったのはその中にあるREPLのサンプルで、SwiftUIで実装された「PicoRubyRunner」というアプリです。テキストで渡したRubyのコードを実行時にコンパイルして走らせる、小さなREPLとなっています。

なぜ iPhone かというと ESP32 では書き込みの時間がかかって大変だったからです。

何を AOT 化したか

対象にしたのは bench_tick というカーネル関数1つです。線形合同法で乱数を回し、指数移動平均をかける……といった処理をまとめて行っています。

def bench_tick(seed, n)
  s = seed & 0x7FFF
  y1 = 0; y2 = 0; ema = 0; sum = 0; i = 0
  while i < n
    s = (s * 75 + 74) & 0x7FFF
    x = s - 16384
    ema = ema + ((x - ema) >> 1)
    y = ((31000 * y1 - 15500 * y2) >> 14) + (ema >> 2)
    y = 32767 if y > 32767
    y = -32767 if y < -32767
    y2 = y1; y1 = y
    sum = ((sum * 31) ^ (y & 0x7FFF)) & 0x7FFF
    i += 1
  end
  (sum << 15) | s
end

型定義は前回と同様にRBS頼りです。トップレベルのメソッドは Object のインスタンスメソッドになるため、class Object の配下に記述します。

class Object
  def bench_tick: (Integer, Integer) -> Integer
end

前回ESP32でAOT化した対象は、手元の電子楽器の実処理そのものでした（距離の平滑化と加速度の差分を行う3つの関数）。あの時は1回あたりの処理がマイクロ秒単位と非常に短く、メインループのボトルネックはToFセンサーや加速度センサーの読み取り（二桁ミリ秒単位）のほうにありました。そのため、AOT化しても処理速度の差が誤差に埋もれてしまっていました。

今回は逆に「計算が支配的である状況」を作りたかったため、内側の while ループでネイティブ側の計算量をしっかり稼げるコードを対象にしました。n の値を大きくするほど、VMのメソッド呼び出し1回あたりに含まれる計算量が増えていく作りです。

仕組み

全体の流れはESP32のときと同様です。

bench_tick.rb + bench_tick.rbs
  ↓ spinel                 … 型推論して C を生成
bench_tick_gen.c + シンボルマップ
  ↓ suppify                … main を静的関数に改名し、公開関数と init を生やす
libbench_tick.a + bench_tick.h
  ↓ suppify -t picoruby    … VM 向けラッパーと gem の枠組みを生成
picoruby-bench_tick/（mrbgem）
  ↓ R2P2-darwin のビルド（xcodegen + rake + xcodebuild）
PicoRubyRunner.app

spinelが生成したコンパイル済みの実行可能ファイルを、suppifyを使って呼び出し可能なアーカイブへと組み替え、そこからPicoRubyのmrbgemを生成するという手順です。suppifyの詳細については以下の記事を参照してください。

retrospective.hatenadiary.com

計測

REPLのシード側で、インタプリタ版の bench_tick_rb をRubyで定義し、ネイティブ版の bench_tick と同じ入力で突き合わせます。まず整合性（parity）を確認した上で、1回の呼び出しでどれだけ計算させるか（内側ループの回数 n）を 1 / 8 / 64 / 512 / 4096 と変化させていきました。なお、内側ループが回る総数はどの n でも同じにしてあるため、n が小さいほど全体の呼び出し回数が増えるようになっています。

確かめたいことは、AOT化の恩恵としてVMのディスパッチや引数検査といったオーバーヘッドがどの程度重たいかということでした。１呼び出しで内部のループがたくさん回るように、今回だとnの数字を大きくすると、高速化効果が大きく出ることを期待しました。

iPhone 16e（iPhone17,5 / A18）の実機で計測した速度は以下の通りです。

n	interp(s)	aot(s)	speedup
1	0.2879	0.2639	1.1x
8	0.2099	0.0334	6.3x
64	0.171	0.0081	21.1x
512	0.1667	0.0037	44.5x
4096	0.1739	0.0035	50.0x

期待にそった成果になりました。

n=1 では、AOT版もインタプリタ版も処理時間はほぼ同じです。このとき両者とも約104万回メソッドを呼び出しており、呼び出しのオーバーヘッドがAOTでもインタプリタでも同様にかかってくるということでした。

振り返り

前回の記事は「計算が支配的なら戦えるはず」という期待で締めくくっていました。今回は題材を計算支配的な方向へと寄せることで、iPhoneの実機で50倍という具体的な数字を確認することができました。

繰り返しのほとんどない処理ではAOT化の導入による複雑さの増加があるのですが、内部ループで反復するような処理がある場合は非常に有効な高速化手段になります。「使いどころさえ見極めればかなり戦える」という確信が、前回よりもいっそう深まりました。