ポートフォリオサイトを今さら作った

長野に転居し、コミュニティ活動をしなくなったので余った時間でポートフォリオサイトを作っている。

nemumi.dev

名前の由来は特になく、完全に語感で決めている。

技術選定

特にこだわりは無かったので、Astroを使って静的アセットとして生成するようにしている。
ホスティングは Cloudflare に。

AI

前職では AI 利用はあまり活発ではなかったので、勉強も兼ねてがっつり AI で作っている。
Claude は IDE との統合が悪すぎるので Codex の Plus プランを購入した。

新規プロジェクトでのAI導入はかなり大変だ。
AI にコードを生成してもらい、大量に赤を入れ、それをもとに AGENTS.md やガードレールを整備していく・・・
ペライチのサイトではあるが、思ったよりも時間がかかった。

AI は70点のコードをさらっと作れない

SNS ではたまに「AI で70点のコードをさらっと作る」なんて発言をたまに見るが、全然そんなことはない。
AI の書いたコードは動く。要求通りに動く。
ただし、それだけ。
ワークアラウンドな方法で実装され、付け焼き刃な修正が上に乗ることも多い。

例えば日付とタイトルからなるコンポーネントを作ったときに、このようなコードが出てきた。

---  
interface Props {  
  date: string;  
  dateTime: string;  
  title: string;  
}  

const { date, dateTime, title } = Astro.props;  
---  

<time datetime={dateTime}>{date}</time>  
{title}  

もちろん、これでも動く。動くが、これで70点にはならないだろう。
なぜ日付を文字列にするのか、なぜ date と dateTime を別々で受け取るのか、全く謎である。
date に日付以外の文字列を渡すこともできてしまうし、date と dateTime の整合性も取れない。

一方で、こういったコードを Linter や Formatter, AGENTS.md などで制限することも難しい。
今のところ、良いコードを積んでおき、それを参照しながらコードを生成してもらうしかないのかなと思っている。

あと、CSS で absolute を使いまくるのはなんでなんだろうね。
もちろん画面が崩れまくる。

いかにAIの書いたコードを減らすか

現状のポートフォリオサイトはただのリンク集になっているが、リンクの項目を毎回手動で投稿するのは面倒なので、GitHub Actions で RSS からデータを取得して自動で同期を取るようにしている。

この機能ももちろん AI に作ってもらったが、AI が勝手にどんどん要件を追加していき、巨大なコードが生成されてしまった。

  • 各リクエストごとに制限時間を設けつつ、全体の実行時間も管理する
  • 各リクエストはパラレルで実行しつつも、同じサイトに対しては連続でアクセスしないように間隔を設ける
  • リンク先のステータスを確認し、一時的なエラーのように見える場合はアーティファクトに保存して後でリトライする
  • リンクがリダイレクトの場合はリダイレクト先までステータスを追う

明らかにオーバーエンジニアリングである。そもそも僕はそんなに記事書かないし・・・
ということで、このオーバーエンジニアリングを削除することにかなり時間を費やすことになった。
ここについては必須要件と任意要件に分類することで対処するようにしてみた。(AIは勝手に必須要件を追加することはできないルールにしている。)
対処を入れてからの実装がまだ無いので効果は不明だが・・・

良かったこと

ドキュメント類

プロジェクトドキュメントを入れる場所と ADR を入れる場所を最初に用意していったのは良かったように思う。
特に ADR を書いておくと「なんでこうなってるんだっけ?」と AI に質問すれば的確な回答が返ってくるので良い。
一方で、すべての変更に対して ADR を書こうとしてくるので、「プロジェクト全体に関わるものだけ書け」「ADR に仕様を書くな」など工夫する必要があった。

自分のサイトを作れた

なんだかんだで持ってなかったので、作れたのは嬉しい。
いつかはブログ機能も追加していきたいが、まだ道のりは長そう。

Go Conference 2026 で登壇しました & ワークショップで大切にしていること

今年も Go Conference にスタッフとして参加しつつ登壇もしました。
去年は個人での登壇でしたが、今年は Go Connect として登壇しました。
内容は「 TDDを通じてGoらしいテストを体験しよう!」です。

ワークショプで大切にしていること

個人的にワークショップで大切にしているのは、「他の参加者と協働すること」です。

私たちは人生経験上、ほとんどワークショップというものを体験していません。
なのでワークショップと言われてもやり方がわからず、過去に体験したものを真似てしまいます。
そう、学校で散々やった「先生」が前で教えて「生徒」が写経するアレですね。

たしかにスクール形式でも「手を動かす」ということは可能で、セッションと違う体験を参加者に提供できます。
ですが、この形式では「資料さえあれば、休日に家で手を動かせばいいじゃん」になってしまいます。
これは、セッションで資料に書いてある内容を読みあげるだけだと「後で資料見ればいいじゃん」になるのと同じですね。

では、会場にしかないものは何でしょうか?
そう、「自分以外の参加者」です!
そして自分以外の参加者へ関与する体験はセッションでは基本的に提供できません。

僕たちのワークショップではペアプログラミングを導入していて、これが他の参加者への協働に該当します。
ですが、いきなり「はい、ペアプロやりましょう!」と言っても当然うまくいきません。
全く知らない人とペアプロするのは難しいですよね。
なので、なるべく事前に「全く知らない人」から脱却してもらう必要があります。
そのためには雑談や自己紹介を通して、相手のことを知ることが重要です。
ワークショップ内でお互いに自己紹介をする時間を取りつつ、かつ始まる前になるべく雑談してもらうようにしました。

でも、知らない人と雑談するのってハードル高いですよね。
だからこそ「場作り」が重要です。
どうすれば話しやすい空気になるでしょうか。
僕たちは以下のようなことを試してみました。

  • 音楽をかける。無音の空間だと沈黙したときに気まずい。
  • お菓子を用意する。カジュアルな雰囲気を出す。
  • 初手で登壇者から雑談を振る。まわりが沈黙している中でいきなり雑談を始めることは難しい。
  • 雑談推奨であることをスクリーンに出しておく。雑談して良い大義名分を作っておく。

こういった工夫もあってか、ワークショップ内ではみなさん和気あいあいと取り組んでいただけたようでした。
「先生から教わる」よりも「同じ目線の人から教わる」ほうが学習効果は高いし、細かいことも随時相談しながら進められるので安心できるんですよね。

という感じで、僕は「他の参加者と協働すること」を意識してワークショップ作りを行っています。
そもそも、仕事でもみなさんチーム開発をしているはずで、仕事でも協働の部分はとても重要ですよね。
「ひとりで最後までやりきる!」なんていうのは承認欲求を満たす効果は多少あれど、効率面でも、効果面でも、学習面でもさほど良くないことに感づいている方も多いのではないでしょうか。
自分の知識や技術を他メンバーに共有することが全体の効率を上げるし、ひとりで悩むのではなくメンバーに相談して短い時間で良い解決策を見つけるほうが速いですよね。
でも、メンバーも元々は「全く知らない人」なわけなので、相手のことを知ったほうが共有や相談をしやすいのは自明ですね。
どうすれば共有や相談をしやすくできるでしょうか?「何でも相談してねって言ってるのに相談してくれない」なんて話もよく聞く話です。

今回のワークショップを通じて、他の人と一緒に何かを達成することや、どのようにすれば相手のことを知りやすくなるのかを掴むヒントになれば嬉しいです。

Go Conference mini in Sendai 2026 に参加しました

2026/02/21 に開催された Go Conference mini in Sendai 2026 に参加してきたのでそのレポート。
…と言いつつ、ほぼ観光の話。

だいたい時系列順。

地方カンファレンスは当日スタッフをするべし

地方カンファレンスを最高に楽しむにはどうするべきか?それは、当日スタッフをすることである。
当日スタッフはいいぞ。当日スタッフになると交流する機会が増えるのだ。

基本的にカンファレンスでは懇親会しか交流の機会が提供されないが、懇親会はカンファレンスの最後に開催されがちだ。
でもカンファレンス前やカンファレンス中に先に知っている人を増やしておくと、楽しさがグッと増える。
当日スタッフは事前準備や当日の作業を一緒にするので、自然と交流ができるのだ。
アウェイなイベントこそ、当日スタッフをやったほうが良い。

・・・というのを「PHPカンファレンス仙台2019」で気付いてから、なるべく当日スタッフをやるようにしている。
そして、今回も当日スタッフをやらせていただいた。
sendai.go の方は熟練スタッフばかりで、迷うところもほとんどなく、スタッフ業をしやすかった。

先に観光したっていい

当日スタッフも前日準備に参加できるということだったので、前日入りする予定だった。
午後休を使えば間に合うが、何となく全休を取り、午前中を観光に充てた。

先に観光するの、めちゃ良いかもしれない。
カンファレンス後は疲れ果てていることも多く観光する気力が残っていないので、先に観光するとガッツリ楽しむことができる。

実は親の実家が仙台なので、微妙に土地勘がある。
でも親の実家近辺を観光することはなかなかないので、改めて観光できて良かった。
自分が観光したところはここ。

  • 海鮮
    • 駅内の「すし三陸前」にした。そこまで混んでいないところが良い
  • ずんだシェイク
    • めちゃ美味しかった。前に来たときは無かった気がする。
  • 村上屋餅店
    • 店主の体調不良でお休みとのこと。お大事に。
  • こけしのしまぬき
    • 東北と言えばこけし。思ったよりも可愛いグッズが多くてつい買ってしまった。刺さる人には刺さる。
  • ほそやのサンド
    • 日本最古のハンバーガーショップらしい。ミートパティが手作り感があって美味しかった。
  • 朝市
    • 朝ラーに合わせて行ったら朝ラー以外は開店準備中だった・・・

  • 仙台辛味噌ラーメン
    • これも知らなかったので体験。美味しかったけどご当地感はあまり無いかな・・・

先にお土産を買ったっていい

お土産は最後に買う感覚が強かったが、「別に先に買ってもよくないか?」と思い、初日に購入して宅急便で送った。
仙台のお土産は駅ですべて揃うので良い。駅に無いものは藤崎(デパート)に行けばある。
以下のものを買った。

  • 笹かま
    • 酒の肴用。自分はだいたい鐘崎のを買う。色々な味があるので、1つずつ購入した。
  • なすの漬物
    • 現地で食べられなかったのでお土産で買った。これも酒の肴か。
  • 白松がヨーカン
    • 大人数に配るときは最中にするけど、今回は実家に送る用だったので羊羹にしてみた。なぜか宮沢賢治の銀河鉄道の夜とのタイアップ。それは岩手やん。

カンファレンス内

Kitchen Senoue の芋煮、りんごさんの似顔絵など、企画が多くあって良かった。
地方カンファレンスだとだいたいがセッションのみの構成になっていることが多いので、別の企画も実施できるバイタリティがすごい。

スタッフ業も特に大きな問題やバタバタすることも無く、平和に進んだ気がする。
スタッフ宛ての東京土産に「菓匠三全の萩の調の東京限定味」を持っていったところ、現地の方に好評だったので良かった。

スタッフ業をしているときはセッションを集中して聞けないことが多いので、実は1セッションしか聞いてない。
kuroさんの「nilとは何か」だけとても気になっていたので聞いた。たまに見かける内容ではあるものの、改めて理解できて良かった。

また、Go初心者の方の登壇がいくつかあったのもとても良かった。
Go Conference は玄人向けのものが採択されやすい傾向があるように思うので、初心者の「やってみた」系の話は貴重だったりする。

まだまだ人口の少ない界隈だと思っているので、こういう話はもっとたくさん出たほうが良いと思っている。
これは Go Connect でも後押ししたいところ。

東北は酒がうまい

「日本酒と言えば新潟」なんて話も聞くが、個人の好みとしては東北や長野の酒が好きだ。
爽酒よりも薫酒が好きだからかもしれない。

仙台驛政宗、浦霞、伯楽星、宮寒梅、阿部勘あたりを呑んだ。

そして宮寒梅はさらに(PHPの)kuroさんからいただいたので、我が家の冷蔵庫に眠っている。
胃腸を整えたら、笹かま、なす漬けと合わせて呑むんだ・・・

まとめ

ということでGo Conference mini in Sendai 2026は最高だった。

2025年のコミュニティ活動まとめ

2025年はコミュニティ活動をがんばったのでまとめ。

カンファレンス

カンファレンス主催

PHP Sessionless Conference

https://fortee.jp/sessionless-conference-2024

初めてミニカンファレンスの主催をした。
カンファレンスというよりギャザリングやミートアップに近いもので、交流をメインに設計した。セッションみたいに「ただ聞いている」みたいなものではなく、参加者全員が主役として参加できるカンファレンスを目指した。
運営としては反省点が結構あったけど、イベントの成果としては非常に良かったように思う。
みんな朝からずっと話しっぱなしなのに、始発までずっと飲んで話してる人らがいてすごいなと思った。
イベントスタッフの人らからは「コミュニケーションシールカード」が好評だった。

コアスタッフ相当

コアスタッフや事前準備スタッフなど、当日以外もスタッフとして参加したもの。

PHPカンファレンス新潟 2025

https://phpcon.niigata.jp/

このカンファレンスの発生の経緯の都合上、スタッフとして参加。
hamacoさんやtomioさん、ariakiさんなど、カンファレンススタッフ猛者が多くいたのが特徴的だった。
スタッフ業としては本当に色々とあったけど、イベントとしてはある程度、満足のいただけるものができたようで良かった。

Go Conference 2025

https://gocon.jp/2025/

去年から引き続きでコアスタッフとして参加。
ぶっちゃけると、このカンファレンスはちょうどいい感じに手弁当感があって非常に好き。
スタッフとして非常に素晴らしい方々がいっぱいいて、特にluccaさんやbudougumiさんが話を前に進める的確な発言をしていて素敵だった。
そういう人らがある程度安定させてくれて、かつ若手な方々が新しい挑戦をしてくれていたので、非常にバランスの取れたイベントになったのではと思う。

XP祭り2025

https://xpjug.github.io/xp2025.html

去年から続いてスタッフとして参加。
アジャイル系のカンファレンス全般に感じるが、「スタッフが頑張りすぎない」という文化を持っていて非常に素敵だと思う。(言語系カンファレンスは気合と努力で押し通す傾向がある。)
締めるところをしっかり締めれば良いイベントは作れるんだなー!というのを毎年実感してる気がする。
スタッフもスクラムマスターやアジャイルコーチが多いので、話し合いも細かい袋小路に入ったりすることなくスッといくことが多い感じがする。

Go Workshop Conference IN KOBE 2025

https://gwc.gocon.jp/2025/

とても紆余曲折のあるスタッフ業だった・・・
詳しくは書かないけど、スタートアップの苦悩ってこういう感じなんだろうなというのを感じた。
カンファレンススタッフの経験が豊富なメンバーが少なく、性善説前提で話が進むことも多々あり、結構危うい部分もあったかなと思うものの、無事に良いイベントになったようで良かった。
でも、ワークショップが楽しいし身になることがこのイベントで少しは広がったのではないでしょうか。セッションもいいけど、セッションばっかりやってもね・・・もっと色々なカンファレンスでワークショップが取り入れられる世の中になってほしい。

当日スタッフ

コアスタッフではなく当日に参加したもの

PHPカンファレンス 2025

https://phpcon.php.gr.jp/2025/

実は初めてトラック担当をした。台本を運用可能な状態にしたり、シフトを決めたり、当日以外の作業が多く大変だった記憶。

PHPカンファレンス関西 2025

https://2025.kphpug.jp/

deroさんの部下になって音響まわりを担当。音響は大変・・・!!

一般参加

スタッフをせずに参加したもの。

Gopher's Gathering

https://connpass.com/event/329963/

sivchariさんやkaramaruさんと遅くまで飲んだり、はてなの方々にとてもお世話になった記憶。
特にTL上でだけ認知していた今日の三井君さんと初めてご対面できたのが良かった。

PHPerKaigi 2025

https://phperkaigi.jp/2025/

PHPerKaigiは楽しいので毎年参加してるけど、ほとんでセッションを聞いてないかも。知り合いと話したり、思いついたことをコードにしてみることに時間を使ってる気がする。k1LoWさんとちゃんと話したのはここが初めてかも。ナチョス美味しかった。

Kotlin Fest 2025

https://2025.kotlinfest.dev/

「Kotlinなんもわからん勢」として、今年も引き続き参加。Kotlin/WASMに未来がありそうに感じて、AIくんにコード書いてもらって試してた。

TinyGo Conference 2025

https://conf.tinygo-keeb.org/2025/

オープニングをきいて、はんだづけをして、ランチを食べて、はんだづけをして、LTとクロージングをきいて終わった。
TinyGoに見せかけたはんだづけのカンファレンスだった。

開発生産性カンファレンス2025

https://dev-productivity-con.findy-code.io/2025

ケント・ベックにサインもらえたし、ジーン・キムと直接質問できたのでファンサ満足度が高かったものの、スタッフの質はもう少しどうにかならんのか。(サテライト会場で雑談すな)

勉強会

主催

PHP勉強会@東京

計13回実施。(体調不良などで参加できていない回あり)
今年はついに「PHP勉強会@東京in関西」が実現したのが良かった。
他イベントのコラボ、楽しいと思うのでもう少し考えていきたい。

Go Connect

計8回実施。
そろそろワンオペではなく他のスタッフも募集したい。1人でもいいんだけど、1人だと僕の都合で開催できないことが多いので。

PHPer x 日本酒の会

計3回実施。
単発で終わるかなと思ったら意外と四半期に一回やってる。
このイベントは「いかにゆるふわにできるか!!」なので、当日のノリで決めることも結構多い。

一般参加

  • 企業勉強会 計9回
  • Asakusa.go 計1回
  • Funabashi.dev 計1回
  • golang.tokyo 計4回
  • Kyoto.go 計5回
  • PHP Lovers Meetup 計1回
  • PHP勉強会in新潟 計1回
  • 技術倶楽部 計1回
  • 渋谷(桜丘)でもくもく会 計3回
  • もくもく会@池袋 計1回

行きすぎ!!

登壇など

カンファレンス登壇

  • PHPカンファレンス関西 2025(パネルディスカッション)
  • Go Conference 2025(ワークショップ)
  • Go Workshop Conference IN KOBE 2025(ワークショップ)

勉強会など

SpeakerDeckにあがっているもので6件(あげてないものもいっぱいあるはず)

まとめ

今年は頑張りすぎたので、来年はもう少し落ち着かせたい。

ホスピタリティを捨てろ

この記事は 技術イベント・カンファレンス運営のノウハウ(2枚目) Advent Calendar 2025 の記事です。1日目が空いていたので、今さらながら埋めます。

今年は多くのコミュニティイベントにスタッフとして参加しました。また、コロナ禍前からカンファレンススタッフとして細々と活動しています。そうした経験の中で重要だと感じたのはユーザーコミュニティのイベントでは「ホスピタリティを捨てろ」ということです。後述しますが、企業コミュニティではホスピタリティを追い求める戦略は有効に思います。

ホスピタリティとは

いわゆる「おもてなし」というやつです。参加者のことをねぎらい、不便なく快適に過ごせるように、スタッフがあれやこれを行い、参加者に無駄な手間をかけさせないことを指します。

なぜホスピタリティを捨てるべきなのか

いくつかの理由があります。

自分が気持ちよくなっているだけでは?

なぜ多くのスタッフはホスピタリティを持ってカンファレンス運営を行うのでしょうか?
深堀りして内省すると、「自分がそうなりたいから」「親切な人だと思われたいから」「感謝されると気持ちいいから」といった理由にたどり着くように思います。

もちろん、スタッフが気持ちよく作業をできるということはとても重要なことです。ですが、ホスピタリティという言葉とは裏腹に、動機は参加者のことをあまり考えていないことが多いのではないでしょうか。

線を引いて分断する

ホスピタリティを発揮するとどうなるでしょうか?おそらく結果的に、「私はサービスを提供する人です。あなたはサービスを受ける人です。」といったような、わたしとあなたは違う立場ですよという線を意識させる行為になります。

さて、我々エンジニアは線を引くことについて危機感を持たねばなりません。ソフトウェア開発の歴史では

  • 開発と運用を分ける
  • 設計する人と実装する人を分ける
  • ビジネス部門とIT部門を分ける

というようなことを行い、大失敗を繰り返してきました。こういった線を引くことの有害性は徐々に認識されてきています。昨今では、役割の境界を意図的に曖昧にし、価値提供までの一連の流れをワンチームで行うことが一般的です。

では、ホスピタリティを発揮して、サービスを提供する人とサービスを受ける人の間に線を引くのはなぜですか?線を引くことにより、どのような有益性を得られ、どのようなユーザー体験を実現できますか?

専門的なスキルである

世の中の職業には、ホスピタリティを提供する職業があります。例えば高級料理店のホールスタッフや、遊園地のキャストなどが当てはまります。彼らはホスピタリティを発揮することで収入を得ていると言っても過言ではありません。言うなれば、高いホスピタリティの提供とは、エンジニアリングと同じように、専門的なスキルであるということです。ホスピタリティについての知識や豊富な経験なしに、高いホスピタリティを提供することは難しいでしょう。

よって、ホスピタリティに重点を置くのであれば、金銭で解決したほうが良いです。つまり、プロのイベントスタッフに依頼したり、クロークサービスや飲食提供の付いた会場を選定することで、より高いホスピタリティを実現できます。ですが、ユーザーコミュニティでの草の根カンファレンスでは、こういったことに金銭をあまりかけられないのが実情です。ですので、高いホスピタリティを提供するのは、ユーザーコミュニティのカンファレンスよりも、比較的に予算を注ぎ込みやすい企業カンファレンスのほうが得意でしょう。

代わりに求めるものは

では、ホスピタリティを捨てて、我々は何を求めるべきなのでしょう。僕は「一緒にカンファレンスを作り上げる体験」を提供することが重要に思います。

具体的な例を見ていきましょう。

勉強会でよくある光景として、セッションをした後に飲食込みの懇親会を行うことがよくあります。このとき、セッションが終わったタイミングで懇親会の準備が終わっていないことが稀にあります。この場合、どうするべきでしょうか?

ホスピタリティの高いイベントの場合、参加者の手間をかけさせないためにスタッフで懇親会の準備を行います。この間、参加者は準備が終わるのを待つ流れになります。ですが、待つというユーザー体験は得てしてあまり良くないものです。暇ですからね。手間をかけさせないために良くない体験を提供してしまいます。

代わりに、参加者に一緒に準備を手伝ってもらうのはどうでしょうか。参加者に手間をかけさせるわけです。ですが、よく考えてください。「手伝ってください!」と言われて嫌な気持ちになりますか?実際はあまりならないように思います。むしろ、「頼られて嬉しい」と感じる人のほうが多いでしょう。

また、共同作業はコミュニケーションのきっかけとしてとても良く機能します。エンジニアはコミュニケーションが苦手な方が多いです。そして、コミュニケーションが苦手な人にとって「話題を探す」というのは難易度の高いものです。見ず知らずの人を相手にしたときに、話題を必死に考えて「今日はいい天気ですね」と声をかけるよりも、「机の反対側を持ってもらってもいいですか?」と声をかけるほうが圧倒的にラクですよね。そして、一度コミュニケーションを取ってしまえば、再び話しかけることは最初に話しかけるよりも簡単なことが多いです。

また、一緒に何かを成し遂げるという体験は、良い体験になりやすいです。成し遂げる内容が容易だとしてもです。

ホスピタリティの捨て方

では、具体的にどのようにすればホスピタリティを捨てられるでしょうか?
僕自身が主催したミニカンファレンスである PHP Sessionless Conference (以下ピセカ)では以下のようなことを行いました。
これらを行うことによりホスピタリティを捨てられ、全体的にユーザー体験や満足度が高まったように感じます。

当日スタッフチケット

ピセカは有料イベントでしたが、一般参加と同じように当日スタッフチケットを有料で販売しました。

なお、各スタッフのチケットの内容は以下のようになっています。

一般チケット
一般参加者として参加するためのチケットです。

当日スタッフチケット
一般参加者としてだけでなく、カンファレンスの設営や撤収にも携われるお得なチケットです。

やりがい搾取みたいな内容ですね。
このようになるべく一般参加者とスタッフの条件をなるべく揃えることで、参加者とスタッフの間に無意識に線を引くことを低減させています。お金を払うことで、「自分はスタッフでもありつつ、客でもあるんだ」と意識できます。なお、当日スタッフだけでなくコアスタッフも有料にしていました。

スタッフマニュアルへの明記

無意識への働きかけでは効果は薄いので、ちゃんとスタッフマニュアルに明記をすることで意識的にも働きかけました。

以下はスタッフマニュアルからの引用です。

(当日スタッフは設営と撤収をメインとした募集ではありますが)スタッフは参加者から質問がきたりすることもあるかと思います。その際は、以下のマインドセットを持っていただけると嬉しいです。

  • ホスピタリティを捨てる
    • 「おもてなしをする心」はもてなす側ともてなされる側という線を引いてしまうので、家に置いてきてください。
  • 代わりに共創の精神を持つ
    • 参加者と一緒にカンファレンス作り上げることを念頭においてください。

例えば参加者が困っていたときに「代わりにやる」ではなく「一緒にやる」という選択肢を取れると良いと思っています。

背中を見せる

文章だけ書いても普段の行動に呑まれてしまうのが人間なので、率先して自身で行動する必要もあります。例えば

  • 少しでも手が空いているときは率先して参加者に話しかける
    • 参加者と同じように会話をすることで、相手との垣根を減らし、会話をしていい、したほうがいい空気を醸成させる
  • 参加者と一緒に撤収する
    • 机や椅子の片付けは共同作業をしやすいので、司会から参加者にも手伝うように伝える

まとめ

ホスピタリティを捨てるのは、マインドセットを変えることに近いので、簡単なことではありません。
ですが、相手のことを深く考え、思いやると、「何かをやってあげる」という行為はあまり相手に良い体験を与えません。
何かをやってあげるのではなく「一緒に作り上げる」ことを重視すると、スタッフも参加者も幸せになると思います。

duck typing がわからんので調べてまとめる

「Goはダックタイピングだよ」と言われるケースをちょくちょく見かけたものの、本当にそうなの?となっていたので調べた。ここらへん、実はPHPがとても良い例になりそうなので、GoとPHPのコード例を出していきます。

Nominal Typing

まず一番わかりやすいものから。その型であるとするには、「その型だよ」と宣言する必要があるというもの。PHPやJavaが採用している。

例えば、「にゃーんと鳴く」という猫インターフェースを定義する。このとき、ツイッターで「にゃーん」と鳴いているエンジニアおじさんを区別できるのが Nominal Typing 。

PHP は Nominal Typing を採用している。

<?php  

// Iterator型と認識される  
class CharacterIterator implements Iterator  
{  
    // ...  
}  


// Iterator型と認識されない  
class CountIterator  
{  
    // ...  
}  

Go は 後述する Structual Typing を採用しているので、Noming Typing ではない認識。

// Stringer を宣言していないが Stringer である  
type MyULID struct {  
    // ...  
}  

func (u MyULID) String() string {  
    // ...  
}  

structural typing

その型がインターフェースの形をしていれば、そのインターフェースを満たしていると見做すもの。GoやTypeScriptが採用している。

例えば、「にゃーんと鳴く」という猫インターフェースを定義する。このとき、Structural Typing ではツイッターで「にゃーん」と鳴いているエンジニアおじさんも猫であると見做す。

Goは structural typing を採用している。上述のコードを再掲。

// Stringer を宣言していないが Stringer である  
type MyULID struct {  
    // ...  
}  

func (u MyULID) String() string {  
    // ...  
}  

PHP は structural typing は採用していない。以下のコードの MyULID は toInt() を実装しているが、 Intable とは見做されない。

<?php

interface Intable  
{  
    function toInt(): int;  
}  

// MyULID は Intable ではない  
class MyULID  
{  
    // ...  

    public function toInt(): int  
    {  
        // ...  
    }  
}  

function output(Intable $i) {  
    echo $i->toInt();  
}  

$id = new MyULID();  
output($id); // 型エラー  

duck typing

変数や値がそれを呼び出し可能であれば、それを呼び出せるというもの。PHPやRubyが採用している。

例えば、$cat に meow() というメソッドがあれば、meow()を呼び出せるというもの。

PHPは duck typing を採用している。下のコードは mixed 型の変数から meow() を呼び出しているが、meow()が存在していれば実行できるし、存在していなければエラーとなる。だが、少なくとも型チェックは通過する。

<?php

function getMeowable(): mixed  
{  
    // ...  
}  

$meowable = getMeowable();  
$meowable->meow();  

Go は duck typing ではない認識。以下のコードは meowable が Meow() を実装しているにも関わらず、コンパイルエラーとなる。

type Meowable interface {  
    Meow()  
}  

// Cat は Meowable  
type Cat struct{}  

func (c Cat) Meow() {  
    // ...  
}  

func getMeowable() any {  
    return Cat{}  
}  

func main() {  
    meowable := getMeowable()  
    meowable.Meow() // コンパイルエラー  
}  

まとめ

typing PHP Go
nominal o x
structural x o
duck o x

nominal typing であり、 duck typing である PHP が少し異例な気がしてきた。

GoConnect#3 レポート

「Go Connect #3」を10/23に開催しました。

https://gotalk.connpass.com/event/331992/

データ

参加者

概要 人数
申込者数 24人
参加者 17人
キャンセル済み 7人
無断キャンセル 0人

参加率は71%でした。
無断キャンセルが無いことはありがたいですね。

アンケート結果

今回は初めて「普通」と回答された方がいらっしゃいました。
この人にとって楽しいイベントになるように改善していきたいですね 💪

ふりかえり

良かったこと

名札

前回の #2.1 から始めている取り組みですが、名札を準備しました。
おかげで、自己紹介がラクだったのではないかな?と思います。

なお、名札の準備はその日の昼休みが消し飛んだりするくらいには大変です。
ただ、リピーターの方の分は前回のを使いまわして少しでも省力化を図っています。
ということで、自分のためにもリピーターを増やすために頑張っていかねばなりませんね。

最初の飲み会の輪

たまたまなんですが、最初に飲み物が置いてある場所を囲って飲み会の輪ができていたのは良かったですね。
勉強会の最初の「1人でさみしくPCを眺める時間」を撲滅したいと常々思っています。
再現性があるか怪しいので、どうにか再現方法を見つけたいところ。

アフター飲み

convtoさんがお声がけいただいたことで、4人くらいでアフター飲みが開かれました。🍻
とても楽しかったですし、アフター飲みの声掛けが自然と発生するような空気を作り出していきたい。

改善すること

参加人数の伸び悩み

前回の反省を活かして告知を定期的にやっていたんですが、あまり効果は出ず・・・
僕はGoConnectにはもっとポテンシャルがあると思っているので、もっと人数を増やしていきたいところです。
パイ的な話としても、golang.tokyoさんやAsakusa.goさんはわりと参加者確保に成功しているように見えるので、Gopherがいないというよりも、僕の広報力不足なのかなという感じです。
チャネルの洗い出しをするためにも、アンケートに「GoConnectを何で知ったか」を入れるべきかなぁ・・・