各社の技術広報が明かす「RubyKaigiスポンサーの裏話」運営ノウハウやコミュニティへの想いに登壇したのでイベントレポートを書いている。

タイトルの通りです、登壇してきました。

moneyforward.connpass.com

登壇して人心地ついたなーと思ってたんですが、思った以上に参加者の方が前日以降にぐぐぐぅ〜っと増えてびっくりしました。 それだけだとブログを書こうと思えなかったんですが、Twitterでの反応やコメントなどがあって「あ。意外とみんな関心や悩みの共感ポイントがあるんだな〜」って感じたのでこの記事を書いてます。

登壇資料はこちらです。

まとめ記事速報を弊社メンバーが書いてくれたのでよければこちらもどうぞ。

zenn.dev

とりあえず終わったあとの感想

いやー元々は技術広報がメインになるイベントって誰得なんだろう?と思っていたので、参加も登壇も全然OKだけどなにを求められてるんだろうなー?が今回のイベント登壇で一番悩んだポイントでした。 結果、ANDPAD鳩さんが割とナレッジよりの発表をされたり、iCARE荻野さんが採用にフォーカス、クックパッド緑川さんがエンジニアの参加についてだったのでエモめな内容に振り切って

「なぜRubyKaigiのスポンサーをしてるんですか?」

に答えられるようなものにしようと考えました。

各社、感じている課題は共通しているんだけど表現方法が違っていたり、それぞれが見ている視点は違うんだけど求めている方向性や意味は同じだなと感じられてよかったです。

Twitterやアンケートの初速も聞いているところによると悪くないので一安心でした。

イベントを開催して感じたこと

最近は技術広報やDevRelというラベルがついたからか、こういった知見や経験を学ぶ場がエンジニアのコミュニティから徐々に広報や人事の領域に越境しているようになったなぁと感じています。 アンケートの速報段階ですがいわゆる非エンジニア職の方の回答がおよそ20〜25%ほどあったようです。 詳細は後日イベントレポートがでる……と思うんだけど自分が担当じゃないのでわからない。まぁ多分イベントレポートは出すんじゃないかな…ということでそちらにおまかせしようと思います。

開催して思ったのは

「正解ではなく、自分が間違っていないことを確かめたい」

なのかなと思いました。 技術広報のような仕事を非エンジニア職の方がやるときに「果たしてこれでいいのだろうか?」という不安があるのだと思います。

そういった人にとって今回のイベントは参考になるナレッジよりも「自分たちが目指そうとする方向性の正しさ」を補強する、という意味で自信を持ってもらえたのかもしれないなと思いました。

もしかすると今回参加した方々が求めるもの、参加している会社は「技術をアウトプットすることが文化になっている企業・組織」なので期待したものではなかった可能性はあるかなと思いつつ、 そこはすでにいろんな方が通ってきた道でもあり、ブログや登壇などである程度ナレッジがあると思うのでそれほど情報面、知識面では困らないのかなと思ってます。

昨年の技術広報アドベントカレンダーもあるので知らなかったという方は見てみるのもいいかなーと思います。 25記事あるので毎日1記事読んでも25日楽しめます。

qiita.com

登壇したときの最後に「並走することが大事、意識している」と言ったと思うんですが、並走はただのHowで成し遂げたいアウトカムはメンバーが自信を持ってくれることです。 このあたりはクックパッド緑川さんの発表でも似た表現があったと思います。

個人的には技術広報という立場での登壇で積極的に発信するつもりは実はあまりなくて、ぼくは他社で技術広報をされている方よりも出遅れていると思ってるので学習して成長していった先で登壇という形につながるといいかなーと思ってます。 なんですが、まあ今回背景の部分にフォーカスしようと考えたのは技術広報は「定性と定量の両方を考えなくてはいけない」からだと考えています。

技術広報だから、というと語弊があるんですが、結局マネジメント職も技術広報も「実際に手を動かしものごとを成し遂げるのは他のメンバー」なわけです。 そうすると必ず「なぜやるのか?」と「やった効果はどうなのか?」が必要になります。

これらはどちらが欠けても駄目なんですが、後者のほうは比較的マーケティングや人事の方は意識しやすいのではないかと思います。 逆に背景や想いといったエンジニア文化、ハッカー文化特有のノリや雰囲気、空気感というのはなかなか理解されないものがあります。

一番手っ取り早いのは体験してもらうことなのかな?と思うんですが、こういったエモめな話はあまり人前でしにくいんじゃないかなと思ったのでせっかく登壇するなら他の人がやりにくい、やらないことにチャレンジしてみようかなと思い、今回の登壇と相成りました。

多分具体的なナレッジのほうがわかりやすいし、バズリやすいのかなと思うんですがエンジニアでない人にとってはこういった背景をどう設計するのか?なにを感じればいいのか?という情報に飢えてるんじゃないかと思ってます。 もしですね、その予測が当たっていれば何かの参考にしてもらえると嬉しいです。

ひとまず終わった状態のなぐり書きでこのブログを書いているので、荒らがあると思うんですがまあこういうものもたまにはいいかなと思って書いています。

RubyKaigiの準備は各社これから徐々にヒートアップしていくと思います。 そういったタイミングで今回のイベントが開催できたということは1つ参考になる事例紹介としてよかったのかもしれません。

コロナ禍になって、オフラインイベントを知らない若いエンジニアの方もだいぶ増えたと聞きます。 前夜祭でコミュニティへと入ってもらう障壁を下げて、後夜祭で楽しんだこと、わからなかったこと、次回どうするのかといったRubyKaigiの体験を次に繋げる施策なんかができるといいなーと思ってます。

コミュニケーションの濃度は「経験 > 会話 > 文字」ではないかなと思っててい、これにプラスして量である「単純接触回数」が含まれ、コミュニケーションの質を形成するんじゃないかなーと思ってます。 ぼくはRubyKaigiの運営とは全く関係がないんですが、できるだけいろんな方に経験を、そして会話をしてもらいたいと考えています。

なんかあったら所属企業が違ってもいいんでTwitterで雑に連絡してもらえればなーと思います。 (こういうときに知らない人との窓口になるMeetyがあると便利だったんだぁ……)

2022年に買ってよかったベストバイ

ようやくお仕事のアウトプット的なものをすべて吐き出しきったので備忘録として書いておきます。

1位 メガネ くもり止めクロス 約600回繰り返し使える 曇り止め 拭くだけで 曇らない メガネ拭き マイクロファイバー素材 24時間効果持続 曇り防止 ゴーグル/サングラス/カメラレンズ対応

これは社内で「これ気になってるんですよね〜」と言ってる人がいたので買ってみたシリーズ。 購入したのは夏なんだけど、普段通勤に自転車を使っているので会社近くの駐輪場から会社までの間で息があがってる状態でマスクをしているとメガネが曇ってつらい…という現象に遭遇してました。 メガネを買い替えるかどうするか悩んでいたんですが、こちらのアイテムを知って購入した…という流れです。 メガネ拭きとして考えるとそこそこにお値段がしますが、曇らなくなることを考えると全然ありだなと思って購入。

現在購入から半年経って、さすがに曇りやすくはなりましたがそれでも800円前後で半年曇らなくなることを考えると俄然優秀という気持ちです。 今年のベストバイ1位は間違いなくこれ。

ラーメン食べてても曇らないので、ちょっとイラッとするんだよな…って人は試してほしい。

2位 アルゼンチン代表22 ユニフォーム(Home/Away)

デザイン的にはアウェイユニフォームのほうがスキなんですが実に36年ぶりにワールドカップ優勝した記念でもあり、これを来てアルゼンチン戦は全て応援していたのでとってもメモリアルなお気持ち。 他にいうことはない。

shop.adidas.jp

shop.adidas.jp

3位 Style AthleteⅡ

同僚から勧められて購入。 弊社は週イチ出社なんですがリモートワークだとぼくは本当に出歩かない性分でずっと椅子(KOKUYOのBezelを使用)の上にいます。 その結果、腰痛が慢性的になってしまい鈍痛がしたり、直ったりを繰り返してました。 上記のような話をした際に同僚からおすすめされたのがこれ。

www.mtgec.jp

座り始めはまあまあ腰が痛くなったんだけどこれは「長時間座んな」って書いてるのにさっそく6時間くらい座ってしまったせい。 お尻や腰が適度に圧迫されて痛いなーって思ったら立ち上がる事が増えたので個人的に半強制的に動かされてる感があってよい。 痛みも頑張れば無視できなくはない…くらい。

せっかくなので使ってるオフィスチェアも勧めておく…が椅子は本当に体格によって合う合わないがあるのでフィッティングしてから検討してほしい。 国産メーカーなので日本人体型に合いやすいんじゃないかとは思う。

www.kokuyo-furniture.co.jp

最後にせっかくなので昨日社内イベントで登壇した資料をあげておく。 ではまた、2023年にお会いしましょう。ばーい!!!

Kyoto.rb Meetup 20221203 〜Kyoto.rbをリブートしたら我々が欲しかったのはこれだ!となった話し〜

先日、およそ1年ぶりにKyoto.rbの活動を再開しました。 それもオフライン限定で……。

kyotorb.doorkeeper.jp

オフラインでのコミュニティイベントを主催するのは久々(およそ3年ぶり)で諸々のお作法を忘れていました。 イベントの最後におこなったふりかえりでも「以前は○○をやっていた」「これは○○したほうが良さそう」といった過去にやっていたことの失伝っぷりが露呈しました。 ふりかえりの内容は全てKyoto.rbのScrapboxで公開しているので興味がある方はどうぞ。

scrapbox.io

当初は弊社マネーフォワード京都開発拠点の名物(?)である「京の間」という和室の会議室で行おうと考えてました。 事前に社内メンバーから「座布団やクッションをクリーニングに出してるけど大丈夫?」と聞いていたのですが、「まあなんとかなるだろ」と軽く考えて準備していました。

……が、イベント開始までの30分ほどでお尻が痛くなってきたので断念しました。硬めの畳なので思いの外痛かったです、座布団は偉大。 

和室会議室で準備していたけどお尻が痛すぎてやめた

急遽、京の間からその手前にあるリフレッシュエリアでの開催に切り替えて準備をしました。 結論からいうと少人数での開催だったこともあり、かつてのKyoto.rbが大事にしてきたコミュニティとメンバーの近い距離感を再現することができました。 (事前にメンバーに「写真取ってもいい?顔出しNGの人いる?」と聞いたら全員OKだったのでモザイク無しで写真撮ってます。)

ディスカッション テーマをみんなで考えてるときの図。

半数近くが初参加なメンバーによるイベントだったので、どうなるかなーと開始直後は思っていましたが始まってみるとそんなことは杞憂だと思うほど盛り上がりました。

フリーダムな感じでわいわいしている図

個人的にファインプレーだったなと思うのがコロナ禍前の「話したい・議論したいテーマを出し合い、投票したものについて関心があるメンバーで議論する」スタイルを踏襲したことです。 これによって初心者の方でもROM専にならずに済みますし、中上級者もわからないことを別のメンバーに質問したり、その場でCHANGELOGを眺めながらあーだこーだいいながら楽しんでいました。

そして、自分が最近RubyRailsの情報をキャッチアップできていなかったこともあり、Ruby関連の知識でサポートしてくれるといいな…と思って社内SlackでRubyコミッターの pocke さんに参加を打診したところ、快く引き受けてくれたり、はてなonk さんに諸々手助けしてもらうことでイベントとして満足度の高いものになったのではないかと思います。 コミュニティらしく互助の精神で、イベントに参加してもらえたので主催する側としてとても満足行くイベントになりました。

ディスカッション テーマを出し合った図

最後に先程出したKPTでイベントをふりかえり、終了。希望者のみで懇親会にいく…という形で締めました。

マネーフォワード京都開発拠点の廊下。普段は暖簾があるけどクリーニング中というレア状態。

懇親会はこちらのお店に5名ほどで半個室で予約し、お酒を飲みながら「さっき聞けなかったんだけど〜」といった形でイベントの延長線や普段なかなか知ることのできない他社の雰囲気、RubyKaigi 2022の雰囲気や(行けなかったのでとても羨ましい!!!)次回RubyKaigi 2023に出すプロポーザルを考える勉強会を開きたい……などなど雑多な会話を繰り広げました。

r.gnavi.co.jp

特に印象的だったのはオンラインイベントが当たり前の世の中になって、失われてしまったオフラインの良さやオフラインイベントでの交流を楽しむ方法を知らないエンジニアにどう楽しんでもらうか?といった話をしたり、聞けたのがとても良かったです。

思ったよりも遠方(大阪の方が何名もいた)から遊びに来てくれたメンバーがいたり、競合他社のfreeeのエンジニアの方やフリーランスの方、異業種転職をされた方などさまざまな方が参加してRubyの技術的な話ができたのがとても楽しかったです。

俺たちはこういう会話、雑談に飢えていたのだ!!!

となったのでこれからは毎月何かしらの形で開催していこうと心に誓う luccafort なのであった。

……ということでできるだけ毎月定期的に開催しようと考えて今後は新生Kyoto.rbとして活動を再開していこうと思います。 幸い、Kyoto.goの活動は他のオーガナイザーに引き継げたので来年はもう少しRubyコミュニティが関西で活性化するお手伝いができると嬉しいなと思ってます。

とりあえず話していた内容としてぼくがいま共同オーガナイザーで権限があまりない状態なので、過去のものを引き継いだりメインオーガナイザーに昇格したり諸々の手続きを並行する形で会の活動を今後もやっていけるといいなーと思ってます。 あとは他の関西圏のRubyコミュニティに参加したことがないので一度どこかのコミュニティにお邪魔したいと思ってます。

というわけで、Kyoto.rb 20221203 のイベントレポートでした。 どんな感じでやってるの?と少しでも興味を持った方がいたらぜひご参加ください!みんなの参加を待ってるぜ!!!

ばーい!!!!!!!

[追記] 懇親会で「RubyKaigiにプロポーザル出さないの?出そうよ!」と id:onk に言われたのでRubyKaigi 2023のプロポーザルが募集開始したら出してみようと思ってます。

[追記2] イベント懇親会後に「俺、この懇親会が終わったらアルゼンチンvsオーストラリアみるんだ……」とフラグを立てていましたが無事起きて、メッシとフリアン・アルヴァレスの勇姿をフルタイムで楽しんだことをご報告します。 試合後はさすがに寝直した。


www.youtube.com

Kyoto.goのオーガナイザーを2023年1月を持って退任します。

TL;DR

タイトルが結論。 Kyoto.goのオーガナイザーはやめるけどいまの会社やKyoto.go以外の活動をする…ということではないです。

なんで退任するの?

Kyoto.goは2020年1月に発足した、比較的若いコミュニティです。 ぼくが発起人となって、さまざまな方にご協力いただいたり参加していただいたことでいまなお続くコミュニティへと進化してきました。

kyotogo.connpass.com

元々ぼくはあまりコミュニティ運営やマネジメントの能力があるわけではない中で始めたので発足当初から自分がいつか退任することを想定していました。 ただ、退任するにしてもコミュニティは継続してほしいとも考えていたので、できる限りの意思決定のログを残すようにしていました。

1年目はコロナ禍というコミュニティどころか社会全体が激動の年となりました。 2年目はGo Conference 2021 Autumnの運営メンバーにKyoto.goとUmeda.goの関西Goコミュニティ共催という形で関わらせてもらいました。 3年目となる今年は運営としてではなく、登壇者としてKyoto.goのメンバー全員がGo Conferenceに登壇することができました。

そうして4年目が見え始めたときに自分がいつまでもオーガナイザーをするのはいいことなんだろうか?という心の奥底にあった疑問が浮上します。 この件に関してはぼくが知る限りとてもスムーズにコミュニティの継承をしていたお二人、そーだい@初代ALFikkitangヒアリングと相談をさせてもらいました。

www.ikkitang1211.site

相談した結果は耳が痛いものからこれはできている、というものまでさまざまでした。 そして、誰かに相談することで自分がなぜコミュニティを引き継ぎたいか?という思いを言語化、自己認識することができました。

  • 3年目という1つの区切りであること。
  • 学生の街京都という特性をもっと活かしたいこと。
  • 世代交代を促すことでコミュニティとしての寿命を伸ばしたいこと。

その他にも大小様々な理由はありますが、大きくはこの3つが影響しています。

今後のKyoto.goはどうなるの?

来年1月からは共同オーガナイザーだった @ujiさんがメインオーガナイザーに昇格します。 そのサポート役として引き続き@yebis0942さんにお願いをしています。 そして、最後にぼくことluccafortがオーガナイザーを退く、ということを計画しています。

とはいえ、Kyoto.goはちょいちょいぼくが寝坊したり体調崩したりでお二人に代役や主催をお願いしていました。 その関係もあり、引き継ぎ自体は概ねスムーズにおこなえていると感じていますし、そういったフィードバックももらっています。

残り日数としては3ヶ月を切ってしまいましたが、仕組みや作業的な部分は普段から一緒にイベントを開催していたので問題ないでしょう。 では、なにが課題になるかというとコミュニティ自身の軸やなんとなくぼくが「Kyoto.goはこうありたい」と考えていたことを言語化し、お二人に伝える必要があります。 このコミュニティではなにを大事にし、なにをやらないのか。 そういった、エモーショナルな部分を引き継いでもらうことで次にバトンを渡すときに「Kyoto.goはこれを大事にするコミュニティなんだ」といえるようにしたいと考えています。

一例としてコミュニティで定義することがあるかわかりませんがMission/Vision/Valueを定義してみました。 まだ草稿段階でこれからまだまだ変わる可能性はありますが、ひとまずこういうことを大事に思っている…と書き出してみたつもりです。

scrapbox.io

ぼく自身はオーガナイザーからは外れますが、いままであまりできていなかったイベントの告知や参加レポートをブログに書くなど、Kyoto.goの情報発信をもっとやっていきたいなと考えています。

まとめ

タイトルの通り、Kyoto.goというコミュニティを立ち上げ、およそ3年ほど運営してきました。 コロナ禍など想定外の事態にも見舞われましたが、それでもここまで継続することができたのは参加してくれた皆さんと支えてくれたujiさん、yebisさんのお二人の力によるところが大きいです。 創設当初は3年も続くとは考えていませんでしたが、毎月なにかしらのイベントを開催することができ、そこに参加してくれる人がいる。

そしてなによりもコミュニティを立ち上げたときの目的だった「ふらっと来たときに技術の話で盛り上がれる場」としてのコミュニティに成長してくれたのではないかと思います。 来年からはオーガナイザーが変わることで、有形無形を問わずなにか変化が生まれるのではないかと思います。

そうなるといいという期待とそうしていくぞという気合の両方がある状態です。 失敗したらどうしよう?とは微塵も感じられていないのはKyoto.goが大事にしてきた文化の一つ、Fearless Changeが身について来たのかもしれないです。

ということで来年から世代交代したKyoto.goになります。 いろいろとご不満な点も出るかと思いますが、その際は率直なコメントをいただけると嬉しいです。

不毛な議論からも学びはある、でもやっぱり不毛なので生産性を高める行為に従事しましょう。

TL;DR

自転車置き場の議論は不毛なのでやめましょう!のお気持ちで Twitter に投稿したら逆に不毛な議論を生んでしまい、日本の生産性を微減させる結果となってしまいました。
ぼくはやめろって言ってるんです!!!!!…というお気持ちが相手に届くことはないので数日はこの通知で死ぬほどダルいお気持ちになるでしょう。

結論

t-wadaせんせいがもう結論述べてるのでこれに沿ったメッセージを残しましょう。

Q.E.D.

雑記

個人的に結論はもうt-wada御大が書いてくれてるのでそれ見ましょう…でいいと思ってるんですが一点だけ学びがあったので久しぶりに雑にブログに残しておこうと思います。
それが以下の投稿です。

みんな擬似コードレベルでコメント書いてほしい。

と以下のURLを紹介されていて気になったので見てみたところ、「あ。これ意識せずにやってるわ。擬似コードというのか」と気づきがありました。

liginc.co.jp

ぼく自身もなにかコードを書くときは頭の中でざっくり出来上がっている処理をコメントでまず書き出してから実装をしています。
日本語で説明できないことをコードで表現することはできない…というのもあるのですが書いてるうちに条件分岐や参照先、参照元が意識されることで問題に気づけるというメリットもあります。
このあたりの詳しい解説は引用されていたブログに書かれているのでそちらにおまかせしようと思います。

普段何気なく実践している手法にちゃんとした名前がついている、それを知ることが出来たのは良い体験でした。
(ただここで書かれているレベルのコメントは実装時は役に立つが、半年後の調査にはなにも寄与しないコメントなので個人的には不要だと考えます。)

というわけで、結論は不毛な議論はやめて生産性を高める仕事をしましょう!という流れからも学びが得られたという教訓でした。

コメント書く書かないはお好きにどうぞ!
ただコンテキストがズレてずっと空中戦してるのははっきりと無駄なのでやめていこうな!

プロポーザルのすゝめ

TL;DR

gocon.jp

Go Conference 2022 Springが4月23日に開催され、無事終了しました。
大規模カンファレンスで初めて登壇したこと、そしてその際にプロポーザルを提出するにあたりいろいろ得た知識や知見を残そうと考えました。
このブログをみて「あ、これなら自分でも登壇できるかもしれない。プロポーザルを出してみようかな?」と思うひとが1名でも増えると嬉しいです。

プロポーザルを出すきっかけ

まずプロポーザルを出そうと思ったきっかけについてです。

実はきっかけ自体はさほど気負ったことではなく、Kyoto.goを曲がりなりにも2年ほど立ち上げから運営まで行ってきたのでなにかコミュニティの話をしようかな?と思い立ったのが原点です。

コミュニティ運営者は星の数ほどいますが、Kyoto.goを運営した経験はぼくと運営メンバーの @uji さん、@yebis0942さんにしか話せないと考えたからです。

kyotogo.connpass.com

twitter.com

twitter.com

仮にカンファレンス側の登壇基準に満たなければプロポーザルが未採択になるだけで、カンファレンスのクオリティーコントロールは運営メンバーのお仕事だと考え、気軽に投稿しようと考えていました。

プロポーザルの投稿に対する心理的ハードルが下がったのはGo Conference 2021 Autumnで運営メンバーを経験したことが大きかったです。 長々と登壇までの苦悩と苦労を語っても仕方がないので、「いつかは登壇してみたい」と思うかたに向けて、プロポーザルを出すときに注意するとよい点と登壇資料を作る際に学んだことをお伝えしようと思います。

gocon.jp

プロポーザルのすゝめ

ぼくが長々と書くまでもなく、素晴らしい先人たちがすでに記事を書いてくれていますね。 まずは、こちらを読みましょう。 (カンファレンス運営者がプロポーザルについてブログを書いている場合は一読しておくといいですよ!)

medium.com

ymotongpoo.hatenablog.com

これら2つの記事には共通点があります。

それはカンファレンス主催者がカンファレンスの登壇者になにを望むのか?どういう価値を参加者に届けたいと考えているか?ということです。 カンファレンスによって求めることは異なりますが、おおよそ同じ到達点にたどり着くのではないかと思います。

  • 対象技術固有であること。
  • 専門性の高い知識・経験であること。
  • 既存の内容ではなく、独自性・革新性があること。

上記3つの要素に加えて

  • 登壇者本人が参加者に伝えたい価値はなにか?
  • それをなぜこのテックカンファレンスで登壇するのか?

これら2つの要素を掛け合わせたものを運営者は登壇者に求めます。 全てが揃っている必要性はありませんが、どれ一つもマッチしない場合はプロポーザルの内容を考え直したほうがいいでしょう。

Go Conference 2022 Springでの事例を元に解説

今回のGo Conference 2022 Springでぼくが登壇したセッションでいうと

  • 対象技術固有であること。

Kyoto.goの話なのでGoコミュニティ固有の事象。

  • 専門性の高い知識・経験であること。

Go言語そのものではないが、Goコミュニティ運営者のニッチな経験と知識であること。 (正直このあたりは理論武装としては弱かったと思います。)

  • 既存の内容ではなく、独自性・革新性があること。

コロナ禍の中で生まれたコミュニティが成長した軌跡の話なので新規性がある。 またコミュニティがコロナ禍で休止していくなか、歩みを止めずにいるノウハウなのでGoコミュニティにとって価値がある。

……という要素を盛り込んで作ったプロポーザルを作成していました。 実際に作成したプロポーザルはこちらです。

www.papercall.io

あとは採択されるかどうかを運営スタッフに託しました。 ぼく自身もGoConの運営スタッフの一員ではありますが、自分のプロポーザルに対する採択、投票に関しては棄権しています。 当たり前のことですね。

これらの運営者が登壇者に書いてほしい情報がきちんとプロポーザルに含まれることで、採択率は大きく変わります。 受かるためにプロポーザルで嘘をついてはいけませんが(そんなことしたら次回以降出入り禁止になっちゃう)、 自分が登壇することの価値やその意義を正しく伝えるにはカンファレンス運営者が思い描く登壇してほしいイメージと自身が登壇することの価値や意義を近づける必要があります。

自身の主張を捻じ曲げて運営者におもねりなさい、ということではなくお互いの期待値をすり合わせて、参加者の価値を最大化することが重要ということです。 カンファレンスの目指すべき理想像がわからない場合は運営チームにメールで問い合わせてもいいですし、あるいは裏技的ですがカンファレンスの運営スタッフになればこれらの情報は自然と知ることができます。 まあほとんどのカンファレンスは「どういう価値を提供したいのか?」が書かれているので、その価値にマッチする登壇内容を考えるだけで大丈夫なはずです。

このあたりはサイモン・シネックのStart with whyが参考になるんじゃないかと思います。

www.ted.com

もちろん、これらの対応を行っても採択されない可能性はあります。 例えば、Go 最新バージョンで導入された機能についての解説などは非常にネタかぶりしやすいです。 同じテーマやネタであった場合、両方が採択されることはまれでしょう。 運営者は出来るだけ多くの、よりたくさんの知見を参加者に届けたいと考えるため、重複したものはより運営者が近しいと感じるものを優先することになります。

情報は重複しやすくなってしまいます、あなただけの経験が付与された知識は誰も真似のできないオリジナルコンテンツになります。 ぜひ、あなたにしか話すことができないセッションを次回Go Conferenceで聞けるのを楽しみにしています。

実引数、仮引数。ParameterとArgument

TL;DR

発端はこれ。

これを正しい、間違っているという気はなくて、自分は逆に覚えていたので言語によって呼び方が違うのか? そもそもParameterとArgumentの違いってなんだろう?コンピューターサイエンスの世界では明確に区別しているのだろうか?と気になったので雑に調べたメモを残しておく。

調べたメモその1

2016年に書かれたブログ。 タイトルがズバリ知りたい内容だったので一読してみた。

hhsprings.pinoko.jp

なるほどなるほど〜と読んでいて、あ、これが正解じゃない?となったのが次の一文。

parameter は、もともとは数学での「媒介変数、助変数」。仮置きする変数、なのよね。

数学的にParameterと表記する際はどうやら仮置する変数として使われる、とのこと。 この出典元については記載がなかったが、体感と一致しておりなんとなく納得感があった。 が、さすがに学術的な裏付けではないのでもう少しだけ調べてみることにした。

調べたメモその2

次に見つけたのが京都産業大学の仮引数と実引数というページ。(どうでもいいけどいつまでHTTPなんだろう?と気になった) 対象言語はC言語だが、

プログラミング用語に,仮引数(parameter)と実引数(argument)という言葉がある.それについて解説する

とズバリな内容を記載してくれている。

www.cc.kyoto-su.ac.jp

仮引数とは関数定義時に使用される引数のことである。 実引数とはその関数を実際に使用するときに関数に引き渡される引数のことである

とあるので、仮引数はParameter、実引数がArgumentであると述べられている。 さすがに最高学府が公開している内容が誤っているわけではなかろうと考えたため、この時点で調査を終了とした。

まとめ

実引数はArgument、仮引数はParameterが言語に関わらずコンピューターサイエンス的には正しそうだと理解をした。 ちょっとした疑問だったがクイズを問いてるような感覚で楽しかったのでログとしてこの場に残す。 もし間違っていたら指摘してほしい、かなり雑に調べてふむふむと納得した内容なので正直自信はない。