[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

Cloud Penguins

Flying penguins in the cloud.

終わった勉強会は、きっちりと畳もう

もう半年も前のことだが、ひとつの勉強会を畳んだ。

PaaS勉強会というもので、2011年に始まって13年ほど続けた勉強会だ。

paas.connpass.com

これほどまでの期間続けた勉強会を、何故クローズすることになったのか。

先に書いておくと、モメたなどのネガティブな理由でクローズしたわけではない。なんならクローズする必要もなく、ずっと箱を残しておく選択肢もあった。にも関わらず、あえてクローズするという選択肢を取ったのは、きちんとクローズする意識を持った方が何かとメリットが多いのではないかと考えたからだ。

どういう勉強会だったのか

PaaS勉強会がどういう勉強会だったのか、せっかくなので軽くまとめておきたい。

PaaS勉強会は、その名の通りPaaS(Platform as a Service)に関する勉強会だ。元々はオープンソースのPaaSであったCloud Foundryのソースコードを読むという「Cloud Foundry輪読会」として2011年に発足した。

togetter.com

当時はPaaSの黎明期で、HerokuやGoogle App Engineなどの商用プラットフォームだけでなく、Cloud FoundryやOpenShiftなどのオープンソース実装も生まれつつあった。その後、paas.jpというドメインが偶然にも取れてしまったことをきっかけに、PaaS関連技術について幅広く取り扱うPaaS勉強会と改名した。

参加者数は10人から20人程度とそれほど規模が大きい勉強会ではなかったが、2014年の9月に日本で初めてKubernetesを取り上げて以降は注目されることも増え、100人を超える回も出てきた。

www.publickey1.jp

活動の収束

しかし2018年頃、PaaSの要素技術であったコンテナのほうに注目が集まるようになってからは、主催・参加者ともに興味の先が変わってきた。

技術面においてもKubernetesのような広く支持されるプラットフォームが登場したこと、使う側も必要な機能についての解像度が上がってきたことから、従来のPaaSのようなOpinionatedな仕組みよりも、柔軟にカスタマイズできるBuilding Blockのほうが好まれるようになってきた。

技術の推移は最終回の資料にまとめてあるので興味のある方は読んでいただきたい。

speakerdeck.com

このような興味や技術面の変化により、勉強会の開催頻度もだんだんと落ちていった。そしてコロナ禍でオンライン回を何度か行ったもののかつての盛り上がりを取り戻すことはできず、自分の中での優先順位も下がっていった。

活動が落ちた勉強会をどうするべきか

このような経緯を辿る勉強会は特に珍しくないだろう。特にデータはないが、世の中の9割5分の勉強会はだんだんと開催頻度が落ちて、過去の存在になっていく。

だが、多くの勉強会は「終わった」わけではない。「誰もやらなくなった」状態なのだ。

終わりを宣言しないので、単に長期休止中なのか、開催スパンが変更になったのか、それとも本当に誰も関与しない状態なのか、外からは判断が付かない状態なわけだ。

終わらせないことによる弊害

自分は2023年から、Platform Engineering Meetupという勉強会を開催している。PaaSに代わって現在注目を浴びている技術分野だ。ハイブリッド形式で開催しており、毎回数百人を集める人気の勉強会となっている。

こちらのほうに力を割きつつも、関連カテゴリであるPaaS勉強会のことをふと思い出すこともあった。そして、何となく思ったのが「この勉強会を放置することが何らしかの弊害をもたらしてはいないだろうか?」ということだ。

PaaS勉強会を放置していること対して特に苦情は上がっていなかったし、おそらく誰も気にとめていないだろう。弊害なんてのもおそらく大げさすぎる表現だ。

でも、世の中は広い。もしかすると自分以外の人がイベントをやりたいと考えている可能性はゼロとはいえない。もしそうなったとき、やるのかやらないのか分からない箱のが残り続けていることが、邪魔になったりはしないだろうか。

誤解されないように書いておくが、誰がどんな勉強会をやろうとも自由だ。仮にアクティブな勉強会があったとしても、気にせず内容が被るイベントやっていい。誰もそれを邪魔する権限は持ってない。商標を取るなんてナンセンスなことをするやつが居ない限りは

そうはいっても、やはり内容が被るイベントが存在すると遠慮してしまうところはあるだろう。そうなると、放置している箱がマイナスの影響を及ぼしているということになる。

また、主催者としても、ことあるごとに思い出しては「そういえばあの勉強会どうするかな・・・でもネタも無いし、今は無理かな・・・」なんて考えて、再び心の中に押し込む。微々たる物ではあるが、ムダに脳のリソースを使っているわけだ。

じゃあ、スッパリと終わらせよう。

終わらせるためにやったこと

終わらせるために、次のようなことをやった。

関係者への共有

この勉強会はそれほどしっかりした運用体制ではなく、自分の気分で開催してきたことが多かった。が、自分と近しい人たちにコアメンバーとして参加してもらい、運営を助けてもらっていた。

そういった人たちに勉強会を終わらせる旨を話し、了承をもらった。 Inactiveであっても、無用なトラブルを避けるために話は通しておいた方がいいだろう。

最終回の企画

13年も続けてきた勉強会なので、いきなり「この勉強会は終了しました、もう開催されるとこはありません」と告知を出すのは寂しい。

なので、最終回として、これまでの歴史を振り返る回を実施した。自分としても当時のことを思い出しながら、どういう想いでイベントをやってきたのか再確認することができてとても良かった。

paas.connpass.com

残すものと残さないものを決める

終了した後、残すものと残さないものを決めた。

残したもの

  • Connpassのグループ
    • これまでの開催の歴史が残っているのがConnpassグループだ。いつどういうイベントが行われ、誰が登壇したのかがここに記録されている。過去回の情報が将来の誰かを救うかもしれないし、過去の歴史まで消してしまう必要はないと思い、こちらは残すことにした。
    • Connpassグループ側に、活動終了した旨を記載した
  • YouTubeチャンネル
    • コロナ後に作ったチャンネルだが、オンライン開催回のアーカイブが残っている。こちらも、もしかすると誰かの役に立つ可能性があるので残すことにした

残さないもの

  • Slack workspace
  • Google Group

コミュニケーションの場を消してしまうのは勇気が要るが、思い切って消してしまうのが良いと思う。もともと無償版Slackだったので過去の会話は残っておらず、それほど支障はなかった。

もし消えてしまっては困る情報がある場合は、他の場所に書きだしておくのがいいだろう。

まとめ

ということで、勉強会を畳んだ話をした。

畳むのも、残すのも、主催者の好きにして良いと思う。

が、意図して残しているのではなく、単に忘れているだけであれば、明示的に畳んだ方が自分も周りもスッキリするかもしれないよ、というのが本記事で話したかった点だ。

MOONGIFT社によるDevRel商標登録問題について、異議申立を行った話

タイトルの通り、「DevRel」の商標MOONGIFT社によって出願され、登録されてしまった問題について、異議申立を行った。

異議番号 :異議2024-900263

DevRel商標登録問題とは

DevRelという単語については、昨年末にも色々物議を醸したことをご存じ方も多いだろう。その件については941さんの記事が詳しいのでリンク先を参照してほしい。

blog.kushii.net

本記事ではDevRelの定義については論じない。個人的には狭義のDevRel(エンジニア採用や技術広報を主目的としない) にやや賛成の立場だが、さまざまな意見があって良いと思う。

しかし、件の議論の中で気になったのは、異なる定義を唱える人間に対してまるで人格否定にまで繋がりかねない非難が行われる点、また「フリーライド」というような、誰かの所有物であるかのような表現が行われるケースがあったことだ。結果として、今や「名前を言ってはいけないあの単語」として扱う人が出てくる始末だ。

DevRelの解説動画で、その定義について正しく触れているのにも関わらずフリーライドと非難する始末である(なので、おそらく動画の中身すら見ずに批判している)

動画はこちら。3:30付近を見ていただきたいが、正しく解説しているように思う。(というか、PIVOTによるダイジェストの切り抜き方が悪い)

これはとても健全な議論とは言えないし、そもそも海外で生まれた役職や活動に関する単語なのに、なぜ自分の所有物のように話すのだろう。

そこで判明したのが、DevRelという単語の商標出願だった。 https://www.j-platpat.inpit.go.jp/c1801/TR/JP-2023-103843/40/ja 2023年の9月15日に出願され、2024年の10月11日に登録となってしまっている。

正確には、かつて一度登録され、それが失効した後再度出願され、登録されたという流れだ。

昨年はもくもく会が商標出願されたり、数年前はゆっくり茶番劇が商標登録されるなど話題になったが、DevRelに関しても同じ状況となってしまった。

何が問題なのか

よくある商標ゴロと異なる点は、MOONGIFT社はDevRelという考え方の普及に貢献しているという点だ。これに対して異を唱える人はいないだろう。

だからといって商標を取るに値するかというと、それはまた別の話だろう。そもそも同社が生み出した単語では無い。これが許されてしまうのであれば、海外の新しい技術用語や分野に対して紹介するブログを書いて手当たり次第に商標を取るということがまかり通ってしまう。

例えば自分はPlatform Engineering という技術分野について早い段階から情報発信やイベントを主催を行ってきたが、じゃあこれで商標を取る資格があるかというと全くそうは思わない。仮に通ったとしても、それは誰も得をしない結果となることは明白である。

この件に関して異を唱えるポストを行ったところ、全く要領を得ない回答が返ってきた。なんだこれは

商標不正登録に対するものか

ゆっくり茶番劇のような、不正な商標登録を防ぐ為に取得した可能性はないだろうか。

これに関しては、実際にDevRelの名の付くコミュニティを作ろうとしたところクレームを付けられたという情報があるため、そのような善の目的ではなさそうだ。

他にもいくつかの事例を聞いているが、もし同様の事例に当たったことがある方はブコメやXで教えてほしい。

DevRel Guildというコミュニティが2023年の9月に立ち上がったが、これは商標が切れていた時期だ。これは推測に過ぎないが、現行の商標が出願されたのはこのコミュニティ発足の数日後ということもあり、同類のコミュニティを潰すために再出願された可能性もある。

そもそも不正登録に対抗する目的であれば、オープンソース商標のようにその目的と運用方法について明示する必要があると思うが、そのような動きは見られない。

opensource.jp

同社はそのままDevRelという名前のサービスを展開している。このサービスを守るため、また同社が直接関与するイベントやコミュニティでコントロールするための商標であると考えられる。

考えられる影響

商標登録されたのは次の商品役務だ。(長いので読み飛ばして構わない)

【第9類】
電子応用機械器具及びその部品,アプリケーションソフトウェア,業務用テレビゲーム機用プログラム,電子出版物,コンピュータソフトウェア用アプリケーション(電気通信回線を通じてダウンロードにより販売されるもの),電子計算機用プログラム,携帯情報端末,録画済みビデオディスク及びビデオテープ,インターネットを利用して受信し及び保存することができる音楽ファイル,インターネットを利用して受信し及び保存することができる画像ファイル,家庭用テレビゲーム機用プログラム,携帯用液晶画面ゲーム機用のプログラムを記憶させた電子回路及びCD-ROM
【第41類】
翻訳,賞の企画・運営又は開催及びこれらに関する情報の提供,セミナー・シンポジウム・会議・講演会・研修会・研究会の企画・手配・運営・開催及びこれらに関する情報の提供,資格検定試験の企画・運営又は実施,オンラインによる映画・画像・映像の提供,資格の認定及び資格の付与,映像の上映,表彰式の企画・運営又は開催,通訳,オンラインによる音楽の提供(ダウンロードできないものに限る。),教育・文化・娯楽・スポーツ用ビデオの制作(映画・放送番組・広告用のものを除く。),セミナーの企画・運営又は開催,映画の上映・制作又は配給,オンラインによるゲームの提供,娯楽分野における情報の提供,技芸・スポーツ又は知識の教授,興行の企画・運営又は開催(映画・演芸・演劇・音楽の演奏の興行及びスポーツ・競馬・競輪・競艇・小型自動車競走の興行に関するものを除く。),娯楽の提供
【第42類】
アプリケーションソフトウェアの貸与,コンピュータソフトウェアの開発の分野に関する情報の提供,ウェブサイトの作成又は保守,コンピュータソフトウェアのバージョンアップに関する情報の提供,技術的課題の研究,ウェブサーバーの貸与,コンピュータ技術に関する助言,電子データの保存用記憶領域の貸与,検索エンジンの提供,電子計算機用プログラムの提供,電子計算機の貸与,機械・装置若しくは器具(これらの部品を含む。)又はこれらの機械等により構成される設備の設計,受託による新製品の研究開発,デザインの考案,科学に関する研究,オンラインによるアプリケーションソフトウェアの提供(SaaS),クラウドコンピューティングを介した仮想コンピュータシステムの提供,電子計算機のプログラムの設計・作成又は保守
【第45類】
個人のニーズに合わせて手配や情報提供などを行うコンシェルジュの役務,ファッション情報の提供,結婚又は交際を希望する者へのパートナーの紹介,法律的事項に関する研究,著作権の利用に関する契約の代理又は媒介,オンラインによるソーシャルネットワーキングサービスの提供

セミナー・シンポジウム・会議・講演会・研修会・研究会の企画・手配・運営・開催及びこれらに関する情報の提供 などは勉強会の開催など、コミュニティの活動にも影響がありそうだ。

なお審査の過程で、一度これは一般名称であると拒絶されている。その結果、次の内容については権利化を断念している。

【第16類】
印刷物,出版物,書籍,文房具類

【第35類】
企業の広告及び広報活動の企画・代行,商品・役務の買い手及び売り手のためのオンライン市場の提供,データ処理(事務処理),市場調査又は分析,商品の販売に関する情報の提供,事業の管理,ウェブサイトの検索結果の最適化,文書又は磁気テープのファイリング,経営の診断又は経営に関する助言,商業又は広告用ウェブのインデックスの作成,マーケティング,広告文の作成,書類の複製,税務書類の作成,広告業,広告用具の貸与,消費者のための商品及び役務の選択における助言と情報の提供,事業に関する情報の提供,コンピュータデータベースへの情報編集,トレーディングスタンプの発行,財務書類の作成,広告場所の貸与,求人情報の提供,職業のあっせん,人材募集,輸出入に関する事務の代理又は代行,競売の運営,新聞記事情報の提供,商業又は広告のための展示会の企画・運営

【第41類】
動画の制作,図書の貸与,図書及び記録の供覧,書籍の制作,文章の執筆,放送番組の制作,電子出版物の提供,インターネットを利用して行う映像の提供,録音又は録画済み記録媒体の複製

印刷物、出版物や企業の広告及び広報活動の企画が制約されてしまうのはかなり影響が大きいと考えられるため、いくらかはマシだったと言えよう。

とはいえ、現在の登録されている商品役務についても健全なコミュニティ運営を行っていくためには影響は免れない。

この問題を受け、部署名や役職名からDevRelを外す事例もありそうだ。そのまま名前を使い続けても直ちに問題は出ないと思うが、法務に確認してみるのが良いだろう。直ちに問題がなくてもリスクがあるのならば無用なトラブルを避けるためにDevRelの名を避けるという判断があってもおかしくはないと思う。

なぜ異議申立を行ったか

自分は普段Product Evangelistとして、自社プロダクトをSREや開発者に対して情報発信を行う仕事に就いている。これは定義としてはDevRelに合致していると思うが、自身のことをDevRelであると紹介することはあまり無い。それは、この商標問題もあるし、かつてとあるDevRelからユーザーとしてとても不快な経験をさせられたというネガティブな想いもあるからだ。

にも関わらず、何故このような異議申立を行ったかというと、これまで技術コミュニティに育てられたという想いと、今ではいくつかのコミュニティを主催する立場から、一部の企業の横暴により健全なコミュニティが阻害されるという現状がとても許容できるものではないからだ。ましてや自分の関与するカテゴリで起きているのだから、とても我慢できるものではなかった。

このまま異議申立期間が過ぎて手に負えなくなってから後悔するよりは、まずは今自分がやれることをやろうと考え、今回の申立に至った。

しかし商標の異議申し立てが認められ、取り消しに成功する可能性は極めて低い。データによると数%の確率でしかないようだ。

仮に上手くいかなかったとしても、この問題が周知され、技術用語に関する商標の在り方が議論されることには価値があると考えている。今回の件を通じて、技術コミュニティがより良い方向に向かっていく一助になれば良いなと思う。

クラウドファンディングについて

本異議申し立てに関しては、弁理士法人に依頼を行った。弁理士法人への支払いとして税込で330,000円、異議申し立てにかかる費用として35,000円(3000円 + 4区分 x 8,000円)の、計365,000円の費用が発生した。

この費用に関しては全額自己負担でも良いかなと考えていたが、有り難いことに何名からカンパをしたいという申し出をいただいた。

そこで、クラウドファンディングを通じて支援を受け付けることにした。準備が出来次第ここにリンクを掲載するので、支援したいという方はそちらからお願いしたい。

テックカンファレンスに参加する理由は「なんとなく」や「ただ楽しいから」で良い

こういう記事があった。

zenn.dev

自分は2019年から2023年までCloudNative Daysという国内最大のクラウドネイティブ技術カンファレンスのCo-chairを務めていたり、今年はPlatform Engineering Kaigi 2024というカンファレンスの代表をしている。最近ではカンファレンスやミートアップをやっていくための一般社団法人クラウドネイティブイノベーターズ協会を立ち上げたり、タダ飯おじさんと対決したりと、コミュニティ作りに対しては思い入れが強いほうだと自負している。

そんななかで目にしたのが冒頭の記事だ。 記事の大意としては「カンファレンスに参加するのであれば、目的意識を持った方が得られるものが多い」という話であり、それ自体は特に否定するものではない。ただし、その説明に使われている理由や、タイトルに使われている「なんとなく」や「ただ楽しいから」というモチベーションに対する疑義というのが、少なくとも主催者側の想いとは異なっているのではないかなと感じた。

結論から言うと、カンファレンスに参加する目的は「なんとなく」や「ただ楽しいから」で良いし、一分一秒を無駄にしないという考え方も不要。気軽に参加するべきだ。

全ては「なんとなく」から始まる

自分が初めて技術カンファレンスに参加したのは15年くらい前。RubyKaigi2009だったと思うが、当時まだ駆け出しのエンジニアだった自分は、話されている内容の2割か3割程度しか理解出来なかったと思う。それでも、日本中からたくさんのエンジニアが集まって一つの技術カテゴリについて熱く語っている様子に圧倒された記憶がある。

はじめてカンファレンスに参加する人の多くは「なんとなく興味があるから」で参加し、そして圧倒されて帰っていく。でも、それがいいのだ。

はじめからしっかりとした目的意識を持てる人なんてほとんど居ない。目的意識というものは、あらかじめ対象カテゴリに対して体系的に理解出来る素地があり、それを自分事に変換して捉えられるだけの経験があってはじめて生まれるものだ。 そもそも技術カンファレンスは、その体系的な知識や他者の生きた経験を学べる場なのだから、参加する前は目的意識がなくて当然なのだ。

まずは「なんとなく」で全然OK。気軽に飛び込んできて欲しい。むしろカンファレンス主催者としてはそういう人こそウェルカム。

そして雰囲気に圧倒されるといい。そうすると「なんとなく」自分の課題感や短期的に目指すべきところが見えてくる。とはいえ1回や2回参加しただけではまだ輪郭がぼやけているかもしれないが、気にしなくて良い。それはそういうものだ。なんとなくの参加を繰り返していくと、だんだんハッキリとしてくる。

元記事でも紹介されているこちらの記事が興味深いが、個人的にはこの自分事に変換して捉える能力というのは、意識よりもシンプルに「場数」だと考えている。より効率を上げるための「工夫」はあるが、何よりもまずは場数が大事。

soudai.hatenablog.com

場数を増やすにもっとも効くモチベーションは「楽しいから」という感覚だ。カンファレンスに参加して「楽しい」と思える能力は、ただそれだけで価値がある。楽しいと感じたのであれば、あとは細かなことは気にせず、その感覚を忘れずに繰り返していくことをお勧めしたい。

コスパ、タイパでは測りづらい「社会資本」という考え方

カンファレンスに参加することで得られるものは技術知識だけではない。人とのネットワークといった「社会資本」も、得られるものとして重要だ。

ネットワークとか社会資本って言うとお堅い感じがして嫌だなと思うのであれば、「気が合う仲間づくり」くらいに考えて差し支えない。そこで得られた仲間は、数年、数十年、もしかすると一生において大切なものになるかもしれない。

じゃあこういった仲間が1回カンファレンスに参加するだけで出来るかというと、それは難しい。世の中には一発で友達作れちゃうコミュ強も存在するが、多くの人はそうじゃない。2回参加すると「あの人前も居た気がするな」となり、3,4回目になると「ちょっと声かけてみようかな」となってはじめてコミュニケーションが取れるようになる。

なので、カンファレンス主催者はそのあたりも考慮して場を設計する。まずはソロでも楽しめるコンテンツ作りをして、次も来て貰えるようにする。次に、ネットワーキングのための懇親会を用意して話せるようにしたり、ランダムにグループを組ませて交流を作るワークショップを用意したりと、あらゆる工夫をこなすのだ。

そのためには、とにかくハードルを下げまくって、いろんな人に来て欲しいと思っている。「なんとなく」の参加大歓迎。「ただ楽しいから」のリピーター大歓迎。そういった人たちを繋げて、モチベートして、お互いに成長してもらう。それが主催としての醍醐味だ。

そもそも、こういうコミュニケーションをコスパやタイパで測ることは難しい。信頼関係の醸成というのは、単に時間やお金だけの問題ではないからだ。

ビジネスの場における信頼関係の醸成のために、よくゴルフや会食などが用いられる。日本に限らず世界中で活用されている手法で非常に効果があるものだが、じゃあそこにゴルフ1ラウンドあたりのコストパフォーマンスが・・・なんて考える人はいない。そうではなく、普段の活動含めて全体的な取り組みとして信頼関係を築いて、最終的にはお互いにプラスになっていくのである。

なので、カンファレンスに参加するのに1分1秒も無駄にしないといった考え方は、ややToo Muchなのではないか。カンファレンス参加や普段の情報発信を含めて、トータルでプラスになっていればそれでいいという、軽い考えのほうがよい。

友達づきあいでも、SNSでも、合コンでもそうだが、人が関わる場でコスパ・タイパを重視しすぎるのは疲れのもと。ガツガツいくと、かえって上手くいかないものだ。

上でも述べたように、人付き合いでも知識の吸収でも、大事なのは「場数」。そのためには、疲れを減らして長く継続するサステナビリティが重要だ。そういう観点でも、「なんとなく」「楽しいから」程度のゆるい参加で良いと思うのだ。

そもそも主催はコスパ・タイパ最悪。だが、それがいい

実はこの記事は、大阪に向かう新幹線の中で書いている。Platform Engineering Meetupを大阪で開催するために、30kg近い配信機材を転がしながら新幹線乗り込んだのだ。

platformengineering.connpass.com

なんとか仕事に都合をつけて、数時間という移動時間を費やして、無料のミートアップの開催のために遠征をしている。コスパ・タイパでいうと最悪だ。というかマイナスだし。

じゃあ何故そこまでして主催をするのか。もちろんPlatform Engineeringという考え方を広めていきたいという想いはある。でも、それだけではない、マグマのようなこの突き動かされるようなモチベーションはどこから来ているかというと、これまた「なんとなく」であり「楽しいから」だ。

正直なんで地方でやるの?と言われたとき、合理的な説明はできない。「でもなんか、知らない土地でやるのも楽しいじゃん?」「たこ焼き、お好み焼き食べたいじゃん?」本気でこんなもんである。

東京でのカンファレンス開催も一緒。ものすごく多くの時間を費やしているし、地味な事務作業だってやらないといけないし、イベントに関係ないモメ事にも対処しないといけない。実行委員同士の関係性が悪くなったりだとか、ごく稀ではあるが痴情のもつれが起きたりもする。だって人間だもの、仕方が無い。でも、そういうのにもちゃんと対処しないと、良いイベントはできない。

このコスパ・タイパ最悪な取り組みを、何年にもわたって続けられるモチベーション。それは全て「なんとなく」であり「楽しいから」。

ただまあ、この十数年を振り返って、トータルで見たときに自分が損をしているかというと全くそうは思わない。大きなイベントをやってきた経験、人を楽しませる企画をした経験、人を率いた経験、人から向けられる評価というのは、今の自分において圧倒的な強みとなっているし、心のそこからやって良かったと思っている。

個々の取り組みのコスパを考え始めると、おそらくこれは続られなかっただろうと思う。また、偉大な先人たちが開催してくれたイベントに参加できたからこそ、ここに至れたのだ。

こういった経験があるからこそ、イベントに参加する人には「なんとなく」であり「楽しいから」だけでいいから来て欲しいなって思う。

ということで、ちょうど大阪についたので今回はこの辺で。

追記

あ、ひとつ大事なことを忘れていた。

軽い感じでカンファレンスに来てほしいけど、セッション中に寝たりとかスマホゲーするのは駄目です。それは単純に登壇者に対する無礼なので。

眠たければどこか他の場所で仮眠するか、家に帰って寝よう。

ゲームは家でやろう。

2023年のふりかえり。Platform Engineeringから法人設立から転職まで

12月に入った頃から、今年は盛りだくさんな1年だったしちゃんと振り返らないとな、と意識はしていた。でも意識しているだけではやはり何も進まないもので、結局大晦日になってしまった。

さすがにこのまま年を越してしまうと、今後一生2023年を振り返ることはないだろうと思うので、急いで書き始めたのがこのエントリーだ。

全体を通じて

1983年生まれの自分は今年で40歳になった。誕生日のときに書いたエントリーでは「手を広げていたらキリがないから活動を収束させていかないとなぁ」的なことを書いたのだが、その後半年でどうなったかというと収束するどころかさらに広がってしまっていよいよ手が回らなくなってしまった。来年こそはやること絞る。絞らないと死ぬ。

登壇

今年はとにかく色々喋ったしいろいろ書いたなという1年だった。

パブリックイベントでの登壇: 10回 プライベート(非公開)な登壇: 5回 メディアでの記事執筆: 5本

登壇回数や聴講者数、書いた文字数でいうと過去一番だったと思う。もちろん準備にかかる時間も。

大変ではあったけど、その分得られたものも多かった。

ピザ職人見習いはじめた

以前から買いたいなと思っていたピザ窯。都内某所にピザ窯を設置するのに最適な場所を発見してしまい、そこに導入したのがENROのピザ窯。

enro.jp

自分で生地から作ったピザを、薪で350度まで加熱した窯で一気に焼く。これが最高に良い体験で、今年買って良かったモノNo1だった。

結局気に入りすぎて、自宅用にガスタイプの窯を買ったほどである。

ピザ作りもなかなか奥が深く、イーストの種類で生地の伸びも食感も大きく違うし、もちろん粉や水でも変わってくる。理想のピザ生地を目指して生地をこね続ける日々だ。もしITで食っていけなくなったらピザ職人で生きていこうか。

Platform Engineering Meetup

充実した1年になったなぁというのはやはりこのイベントの存在がでかい。

platformengineering.connpass.com

40歳になりました記事の方でも書いたが、Platform Engineeringで説かれている内容は、自分が過去10年間取り組んできたものとほぼイコールだ。人生の1/4を捧げてきたものが世の中の脚光を浴び始めたとしたら、そりゃ本気で波にのっかるしかないよね。

今年は3月に第1回を開催した後、12月までに6回のミートアップを開催した。ほぼ2ヶ月に1回ペース。Connpass登録者も2000人を超え、かなりの人気勉強会になったと言って良いだろう。来年も継続して開催していくほか、夏にはカンファレンスも予定しているので引き続き忙しくなりそうだ

一般社団法人クラウドネイティブイノベーターズ協会

Platform Engineering Meetupが思っていたより数倍大きなイベントとなったので、これは早々に体制を作っていかなければいけないと思い作ったのが一般社団法人クラウドネイティブイノベーターズ協会である。法人としてイベントの下支えを行っていくほか、クラウドネイティブ技術の普及の為に人材育成やハイブリッド開催の支援などを行っていく。

www.cnia.io

CloudNative Days Fukuoka 2023

4年ぶりの開催となったのがCNDF2023だ。チェアはudzuraさんtransnanoさんにお任せしていたため、自分は一スタッフとしての参加となった。

地方開催を復活させたいというのはここ数年CNDのチェアを担う中でずっと思っていたことだった。クラウドネイティブ技術が必要とされるのは東京の企業に限った話ではない。クラウドネイティブ思考という考えに立てば、ありとあらゆる企業にとって有用なものだ。であれば、イベントも東京でやっているだけではだめだ。

atmarkit.itmedia.co.jp

であれば、活気に溢れ次の世代を引っ張ってくれそうな土地でまずは復活イベントをやるのがよいだろう。そこで選んだのが、福岡だった。

イベントは想定通りの盛り上がりを見せ、今後の地方開催にも弾みがつきそうな内容となってとてもよかった。

転職

正直今年の夏頃までは転職することになるだろうなんて全く思って無かったわけだが・・・退職ブログにも書いたように、HashiCorpとしても大きな動きがあったほか、エントリーには書いていないアレコレも色々あったのだ。

このままHashiCorpで仕事し続けて良いのかどうか迷っていたタイミングでやってきたのが、PagerDutyのProduct Evangelist職の募集だった。PagerDutyは以前より注目していた会社だったし、自分の今後の方向性としてEvangelistというポジションもひとつ面白いんじゃないかと。そう思い応募してみたところ、最終的に無事オファーを頂けたという流れだった。

入社して1ヶ月半が過ぎ、そろそろプロダクトも組織の状態も色々見えてきたところだ。来年からはPagerDutyや、それに関連するインシデント管理周りで登壇したり情報発信することが増えてくるだろうと思う。

CloudNative Days Tokyo 2023

一スタッフとして参加したのがCloudNative Days Tokyo 2023だ・・・と言いたかったところだが、自分がCo-chairを退任する話を中途半端に終わらせていたり引継ぎも曖昧なままだったので、やるなら最後までやり切ってほしいとお願いされて今回もCo-Chairとしての立場で参加することとなった。

今回のイベントでは現地参加者数が去年より2倍以上増えるなど、世の中の変化を感じられる内容となった。増えた現地参加者に増えたスタッフ、より成長し高度になるクラウドネイティブ技術ということで、2019年依頼の盛り上がりになったように思う。

クロージングではChairのバトンを@taisuke_bigbaby に引継ぎ、5年に渡る自分のCNDTチェアとしての仕事は終了となった。来年以降はまた一スタッフとして運営を支える形になると思う。

その他

正直いろいろありすぎて忘れているものも多いのだが、総じて良い年だったなと思う。今年が前厄で来年が本厄?らしいが、あまり厄感はないまま追えることができた。来年も今年以上にいい年になると良いな。

ボランティアメンバーで大規模カンファレンスの高度なハイブリッド配信を行うためにやったこと

技術カンファレンス Advent Calendar 2023の7日目!

今回は、大規模な技術カンファレンスでボランティアスタッフの力でハイブリッドイベントを行えるようになった、これまでの過程を書いてみたいと思う。

ハイブリッドイベントを続ける理由

以前、ハイブリッドイベントを続ける理由についてのエントリーを書いた。そこそこ反響があり、関心の高さを感じた。

jaco.udcp.info

このエントリーでもしたためたように、自分が関与しているイベントではハイブリッド配信に並々ならぬ力を注いでいる。きっかけはコロナ禍でオンライン配信を余儀なくされたことだが、それによってもたらされた正の面として、住んでいる地域や自身の都合によらず、様々な場所から自由にイベントに参加できるようになった。ほぼ制限なく、以前のようにIn-personのイベントに参加できるようになった現在だが、全てを巻き戻してしまって良い面までなくなってしまうのは勿体ない。 オンサイトとオンライン、両方のいいとこ取りをするのがこれからのスタンダードであると強く信じている。

どうやってハイブリッド配信できるようになったか

とはいえ、ハイブリッドの開催は相当に大変だ。

何故大変か知りたい人は是非とも前述のエントリーを読んでいただきたいが、今回は自分が関わっているCloudNative Daysがどうやってこの大変な取り組みをやれるようになったのか、その経緯と取り組みについて紹介したい。

つまり、このエントリーを読み終わると、明日からあなたのイベントも簡単にハイブリッド配信できるノウハウが手に入r





そんなものはない (画像略





正直明日からいきなりハイブリッドを自力でやろうっていうのは難易度が高すぎる。我々も色々挑戦し、なんとか省力化できないか試みたものの、これさえやれば完璧という答えにはたどり着いていない。なので、今回は明日から実践できるノウハウではなく、「どういう背景のもとでこうなったのか」という点について解説したい。

また、ハイブリッドのうちオンサイト参加側のオペレーションについてはあえて省いている。残り半分のオンライン配信向けの試行錯誤についてのみ解説している点にご留意いただきたい。

CloudNative Days Tokyo 2020 - 業者任せの配信

まず2020年。CNDT2020では、自分たちもオンライン配信に挑戦してはいたものの、6トラックに渡る大規模カンファレンスをやり切るほどの力や知識はなかった。そこで、専門業者にお願いして開催することになった。その分実行委員に時間の余裕があったので、それそれで良かったのだが。 配信会場の様子をコンテンツにした動画が以下。

www.youtube.com

専門業者に依頼しただけあってイベントも無事終えることができたのだが、どうしても自分たちのコントロール出来ない領域が多くなるのが気がかりだった。たとえば突発的な企画もできないし、ちょっとした遊び要素をいれるのも難しかった。自分たちのイベントなのに、自分たちではなにも出来ないというもどかしさを感じるものになった。

CloudNative Days Online 2021 Spring - 自前配信初挑戦

そして開催したのがCNDO2021。これは「どうせコロナ禍なら、今しか出来ないイベントをやろう」と考えて開催したカンファレンスだ。コンセプトは「誰もが登壇できるカンファレンス」。CFPはなく、応募したら全員が登壇出来る形にしてみたのだ。登壇時間も5分から40分の間で自由に選ぶことができる。

今考えるとよくやったなこんな企画。タイムテーブルも、時間スロットみたいなのはなく完全にバラバラのタイミングでセッションが始まったり終わったりする。しかも7トラック平行。

こんなトンチキな企画を受け入れてくれる専門業者はあるはずもなかった。予算の制限もあり、であれば自分たちで配信まで含めてやり切るしかない。こうして発足したのが、CloudNative Daysのbroadcastチーム ”EMTEC" だ。 現在もリーダーを務める @kameneko が中心になって仕組み作りをしていった。

”Cloud Native” を冠する以上、クラウドの力とソフトウェアで仕組みを作り上げたい。そう考え、AWS上にGPU付きインスタンスをトラック数分ならべ、そこに対して遠隔地から複数人でVNCやWebSocketでOBSをコントロールしてVimeoに配信する。そういう仕組みを作り上げて、イベントを完遂した。

CI/CD Conference 2021 - 安定したオンラインイベント

次に開催したのがこのイベント。確か4トラック平行だったかな? この会は登壇・視聴ともにオンラインのみの純粋オンラインイベントだったので、StreamYardを使って配信をやりきった。当時はそれほどユーザーが多くなかったように思うが、今となってはスタンダードな仕組みだ。特段のトラブルもなく、実に平和にイベントを終わらせることができた。ちょっと物足りなかったけど

CloudNative Days Tokyo 2021 / Observability Conference 2022 - 挑戦と挫折

だいぶ配信技術について知識がついてきた我々が次に挑戦したのが、NDIだ。Network Device Interfaceという、ネットワークを経由して映像と音声を伝送できる技術である。普段から業務でインフラに触れるメンバーが多い我々からすると、伝送距離の稼げないHDMIや機器が高額になりやすいSDIに比べて、汎用的なEthernetで環境が組めるNDIはとても魅力的に映った。

CloudNative Days Tokyo 2021では、都内の某スタジオをレンタルし、登壇者はスタジオかリモートかで登壇出来るようにした。6部屋借りた登壇部屋からNDIで転送されてくる映像を中央のコントロールルームから打ち上げるという構成を組んだのだ。

rental.pandastudio.tv

しかしこれは大失敗に終わった。肝心のNDIが異常なほど不安定となり、映像がブツブツ切れるわ音声との同期が激しくズレるわで、イベントが成り立たないほどの荒れ具合となってしまった。

結果としてスタジオに頭をさげてSDIの機器をかき集めていただき、NDIの部分をすべてSDIに置き換えることでなんとかイベントを完遂させることができた。

続くObservability Conference 2022でもNDIに再挑戦したがやはり不安定さが発生してしまい、予め用意していた光HDMIのバックアップ経路を利用することでリカバリーをした。

インフラエンジニアが使い慣れているEthernetで完璧なプロダクション環境を組むという夢は実現できないまま終わったのである。

このままだとNDIが悪いように聞こえてしまうが、悪いのは我々の知識不足だ。今思うと、トラフィック量がまともに見積もれていなかったのだ。Catalystのスイッチを2台置いて捌いていたのだが、今改めて計算するとそりゃー無理だよというくらいの雑な設計だった。

あとNetgearがNDIに向けたスイッチを出しているので、こういうものの導入も考えたほうが良い。

10917_NDI | NETGEAR

CloudNative Security Conference 2022 / CloudNative Days Tokyo 2022 - Remote Production 2.0

NDIで大失敗をした我々は、改めてアーキテクチャを見直した。かつて取り組んだRemote Productionの仕組みをより洗練させ、安定性と省力化を図ることにした。

さくらのクラウド上に、GPUを積んだ高火力インスタンスを作成しそこにOBSを設置。WebSocket経由で操作するかつての仕組みを復活させた。また、Internet-facingな場所にNginx-rtmp拡張を入れたingestサーバーを作成した。 現地登壇の場合は現地から映像と音声をRTMPで打ち上げ。リモート登壇の場合はStreamYardからRTMPで打ち上げることによって、リモートであっても現地であっても同じようなオペレーションでスイッチングを行えるようにしたのだ。

ユーザーへの配信はAWSのIVSやElemental Media Live, Media Packageを利用。これらの環境の構成はTerraformからほぼ全自動で行えるようにし、IVS/Elemental Mediaの操作はAPIで行えるようにした。

WebSocket経由のOBSコントロールも cndctl というCLIを作成して、コマンドラインで行えるようにした。

後にはNginx-rtmpの代わりにSRSを投入するなど細かなブラッシュアップも行い、トラック数に依存しないスケーラブルな仕組みを構築することができた。

こうして、クラウドネイティブ技術を活用したスケーラブルな配信構成が完成したのである。 ・・・とはならなかった

実際のところは、オペレーションをしてから視聴者に届くまでに30秒から50秒ほどの遅延が発生したことによりオペレーションが非常に困難になったり、エンコーダーの種類によっては大幅な音声の遅れが発生する(NVENCだと死ぬけどQuick Sync VideoだとOKみたいな)など、H264の深いところまで理解していないと解決出来なさそうなトラブルが多発。直前の徹夜に近いワークアラウンドの模索でなんとかイベントは開催できたものの、一部の登壇者のアーカイブ公開が遅れるなどの影響が出た。そして何よりも疲れた

CI/CD Conference 2023 / CloudNative Days Fukuoka 2023 / CloudNative Days Tokyo 2023 - 結局は物理

2年間、クラウド技術とソフトウェア、ネットワークの知識を駆使して低コストでスケーラブルな配信環境を目指した我々。2023年現在ではどうなったかというと・・・

めちゃくちゃ物理。

いろんな技術を試して、いろんな構成を試みて、いろんなオペレーションを実施した結果、結局のところ最も安定して質の良い配信ができるのは、出来る限り物理機材に構成を寄せることだという考えに落ち着いてしまった。

「やっぱりなんだかんだで物理が最強だよ」 

配信を始めて以降、たくさんの人の仕事を見てきたが、こういう意見を持つプロが多かった。だが、オンプレのサーバーがクラウドになり、フィーチャーフォンがスマホになり、ソフトウェアの力によって大きく価値が変化する様を目の当たりにしてきた自分たちからは、「本当にそうなのか? 過去の慣習に囚われているだけなのでは?」 との気持ちが拭えず、自分たちならばソフトウェアでどうにか出来るんじゃないかと思っていたこの2年。

自分たちで手を動かした結果「少なくとも2023年現在においては物理機材が最強」という結論に至った。

もちろんソフトウェアのほうが柔軟性が高かったり、ケーブルを減らしシンプルな構成が可能だったりというメリットはある。しかし、最も重要視すべき安定性や質という観点では、どうやっても物理機材を超えることはできない。

また、思ったよりもハードウェアが着実に進化しているという点も、自分たちが考えを変える一因となった。

最近のCloudNative Daysは、ローランドのVR-6HDというビデオスイッチャーをコアに据えているのだが、これは今年出たばかりの機材だ。1台でビデオスイッチャーにも、オーディオミキサーにも、エンコーダーにもなる全部入り機器で、ほぼこれ1台で完結してしまう。

proav.roland.com

決して安い機材ではないのだが、これによりもたらされる効果は絶大。個人で購入し、CloudNative DaysだけでなくPlatform Engineering Meetupでもこれを使った構成を組むようになった。

なので、当面はこの機材を中心としたイベント設計を行っていくつもりだ。

クラウドの活用やソフトウェアでの運用も諦めたわけではない。たとえば、VR-6HDのコントロールはBitfocus CompanionのVR-6HD向けプラグインを自分たちで用意し、StreamDeckのボタンでスイッチングを行えるようにしたり、OBSの操作と同時に自動化して現地配信から幕間動画への切り替えをスムーズに、ワンボタンで行えるようにしたりしている。

幕間動画も、これまではAfterEffectsでトラック数分作成していたが今回からはReactで作られたWebアプリを作成し、それをOBSのブラウザソースで読み込むことで幕間動画として機能するような仕組みも開発した。

それ以外の補助システムも、AWS、さくらのクラウド、NextCloud、HashiCorp Vault、Tailscaleなどを活用して自動化、効率化を図っている。

ブラッシュアップできる余地はたくさん残されており、今後も積極的に改善していく予定だ。

どういう人たちがやっているのか

CNDO2021で初めて配信を行った時、チームメンバーは仕組みを作るコアメンバーは3人だった。本番はスイッチングを行うボランティアをトラック数分募るという形だった。

その後しばらくは3人から4人のコアメンバーという状態が続いたが、CNDT2022ごろから徐々に増え始め、現在は10人を超えるチームになっている。

リーダーの@kamenekoや、ライブ配信に関する情報を積極的に発信されている松井さん、学生時代にCNDOのスイッチングボランティアとして参加してそのままコアメンバーになったGakuくん、クリエイティブ能力が高く、お絵かきからデザインまで出来るTanayan、CNDだけでなくSRE NEXTやPFEMなどさまざまなカンファレンスで活躍しているBuzzさん、自鯖系YouTuberでもあるうんちゃま。実務能力最強tsukamanや本番の作業に無類のパワーを発揮してくれるcapsmalt、革新的な幕間システムのベースを作り上げてくれたKawamuraさん、今回からジョインしてくれたShuzoNさん。 あとは何でも手を出しすぎて首が回らなくなってきている自分。

稼働のかけ具合は人によって異なるものの、とてもスキルが高くバラエティ豊かなチームになってきていると感じる。

今後どうしたいか

今後は、自分たちが得たノウハウを積極的に外部に提供して、配信を担える人材を増やしていきたい。

おなじく技術系カンファレンスの配信に力を注がれていて、密かに尊敬していた東雲さんMaryさんと話したときも同じ課題感を持たれていたが、需要に対して如何せんやれる人材が不足している。

どうしても機材のコストや知識面で最初のハードルが高い。ハードルが高いのでなかなか人が増えないという状況だ。最初のハードルを越えるには、たとえば我々EMTECチームに勉強がてら参加してもらうとか、EMTECチームが他のイベントの配信を後方支援してスキルトランスファーするなどして、仕組みに触れることのできる機会を提供していく必要があるのではないかと考えている。

今年設立した、一般社団法人クラウドネイティブイノベーターズ協会 (※EMTECチームの資金的な下支えもしている) の活動としてもハイブリッドイベントの支援を考えており、様々な形で協力が出来るのではないかと考えている。

もしイベントの配信に興味がある、あるいはハイブリッドイベントをやりたいが敷居が高く困っているという方がいれば、ご相談いただきたい。

2023年のPlatform Engineeringを振り返る

Platform Engineering Advent Calendarの1日目! 今日は、この1年のPlatform Engineeringについて振り返る会。

ちなみにAdventCalendar、まだスカスカなのでネタがある方は是非参加を! qiita.com

Platform Engineering Meetup

まずは日本国内の動向ということで、Platform Engineering Meetupの話から。

3月から始めたこのミートアップも、来週で第6回目になる。ここまで高頻度に開催することになるとは思っていなかったのだけど、それだけ需要が多くて驚き。

第1回

記念すべき第1回。場所はAPコミュニケーションズのオフィス。初回から参加者が550人とものすごい規模のミートアップに。

platformengineering.connpass.com

このイベントはPublickeyや@ITでも記事として取り上げていただいた。

「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは(前編)。Platform Engineering Meetup #1 - Publickey

「Platform Engineering」は何を解決するのか? 誰が何をするものなのか?:サイバーエージェントのグループインフラ部門はパブリッククラウドとの戦いに - @IT

第2回

第2回はさくらインターネットのオフィスで開催。

platformengineering.connpass.com

参加登録者数は驚きの700人超え。この段階でConnpassの登録者数は1000人を超えていた。

第3回

プラットフォームが必要なのは東京の会社だけじゃない!との想いから、他の地域でも開催することを目指した。

第3回は名古屋。株式会社スタメンのオフィスをお借りして開催。

platformengineering.connpass.com

第4回

第4回は福岡で開催。CNDF2023との共催という形をとった。

platformengineering.connpass.com

第5回

第5回は東京に戻り、VMwareのオフィスを借りて開催。会場参加が100人を超え、懇親会も大賑わいだった。

platformengineering.connpass.com

第6回

2023年最後の開催は、docomo R&D OPEN LAB ODAIBAをお借りして開催する予定だ。

platformengineering.connpass.com

もともとは自分一人で始めたミートアップだったが、初回の申込者数の勢いをみて早々に一人での運用は無理だと悟った。そこで、Twitterで運営メンバーを募集したところ、たくさんの方から協力したいとの連絡をいただき、そこからチームとしての運営がスタートした。あのとき手伝ってくれる人がいなければここまでのミートアップにはならなかったと思うので、本当に感謝しかない。

一般社団法人クラウドネイティブイノベーターズ協会の発足

また、 それでも僕らがイベントのライブ配信を続ける理由 - Cloud Penguins にも書いたが、アフターコロナの時代ではハイブリッドでのイベント開催が本当に重要だと思っている。しかし、この規模のミートアップを任意団体でハイブリッド開催するのは、金銭的な面での困難に直面するだろうと考えた。

そこで設立したのが、一般社団法人クラウドネイティブイノベーターズ協会だ。

www.cnia.io

Platform Engineering Meetupの開催のほか、コミュニティの支援やセミナーなどを行っていきたいと考えている。近々大きな取り組みについて発表する予定だ。

Platform Engineering全体の動向

世界的にもPlatform Engineeringが一気に盛り上がったなと感じる1年だった。

2022年のGartner 先進テクノロジのハイプサイクルにPlatform Engineeringが登場したことが、日本における注目度の向上に影響を及ぼした。じゃあ2023年はどうなったかというと、Platform Engineeringの表現の代わりにInternal Developer Portalが入っていた。

www.gartner.com

また、11月に発表された2024年の先端テクノロジートップ10の中にもPlatform Engineeringが登場。AIネタで過半数が占められる中、かなり目立つ形で取り上げられることになった。

www.gartner.co.jp

PlatformCon 2023

6月にはPlatformCon 2023が開催。

platformcon.com

とんでもないセッション数で全部見るのは大変なので、Platform Engineering Meetup第3回の亀崎さん、tanayanさんのrecapを参考にするのが良い

www.youtube.com

CNCF

Platform Engineeringの定義はplatformengineering.orgのものだったりgartnerのものだったりと定まらないのが現状だが、今年に入ってCNCFから2本のホワイトペーパーが発行された。今後は、これら2本の定義を中心に語っていくのが良いと思う。

Platforms White paper

tag-app-delivery.cncf.io

Platform Engineering Maturity Model

tag-app-delivery.cncf.io

大手クラウドベンダーにおけるPlatform Engineering

大きな流れになっていることもあって、各ベンダーが新機能やブログで流れに乗ろうとしている。

cloud.google.com

learn.microsoft.com

docs.aws.amazon.com

最近出たAzure Deployment Environmentsも、これはかなりPlatform Engineeringを意識してるなぁというサービス。

learn.microsoft.com

名前が紛らわしすぎてググラビリティの低いRadiusも、プラットフォームに適度な抽象化を与えうる存在として注目している。

azure.microsoft.com

2024年はどうなる?

っていう話を、12/20にする予定なので興味のある人は是非参加してみてほしい

forkwell.connpass.com

PagerDutyにProduct Evangelistとして入社しました

インシデント対応プラットフォームとして知られるPagerDutyに、Product Evangelistとして入社した。

www.pagerduty.co.jp

▲マスコットのペイジーくん

Evangelistを仕事にするよ

コミュニティ活動で知り合った人からは、「お、ついに本職になるんだね」と、あまり違和感なく受け入れられるんじゃないかなと思っている。むしろ、「今まではDevRelじゃなかったのか」とまで思われるかもしれない。そう、これまではPre-sales Engineerだったし、それより前はProfessional Serviceだったので本業におけるコミュニティ活動はあくまでもボランティアだったのだ。

逆に、自分と付き合いが長い人からすると「え、DevRel? おまえDevRelにはならないって言ってなかったっけ?」と驚かれるんじゃないかと思う。そう、自分はDevRelにはならねぇ!と公言していた時期もあったのだ。

テクノロジーを人に伝えるということ

なんだかんだで社会人生活も長くなってしまったのだが、十数年やってきて自分自身が何に対して情熱を注げるかというのが分かってきた。結局のところ、自分は「テクノロジーが大好き」であり、「よいテクノロジーがあるのならば、是非それを人に紹介して、その人が幸せになってほしい」というのがモチベーションの根源なんだなと。

そのモチベーションを仕事につなげる方法は複数のアプローチがある。

Professional Serviceのときは、テクノロジーを導入してくれたお客さんにガッツリと入り込んで、単にプロダクトを入れるだけではなくそれを使うチームから育てていくことで、価値を最大限に生かせるようにするという仕事をしていた。自分が分かりやすく伝えれば伝えるほどお客さんの理解も高まり、テクノロジーを生かす敷居が低くなり価値が生まれやすくなる。 自分はそういう技術を伝えるプレゼンが得意だと自負しているのだが、それはこのあたりの経験が生きている。この仕事は今でも自分にマッチした天職だと思っている。

前職ではPre-sales engineerだったが、これもまた違ったテクノロジーを伝える仕事のひとつだ。プロダクトを正しく、かつ魅力的に伝えないとそもそも買ってもらえない。最終的には買ってもらうというのが自分の評価になるのだが、それを成し遂げるためには、まずはプロダクトを語る。それも、単に機能を説明するだけでなくてそれが組織にどのような効果をもたらすのか。直接的なものから間接的なものまで、幅広くアピールするのが重要だ。

これも自分のスキルが生かせる仕事であり楽しかったのだが、最終的な評価は どれだけお客さんが幸せになったか ではなく どれだけ売り上げに貢献したか で下される。どれだけお客さんがプロダクトによって幸せになったかは副次的なものであり、そこにジレンマを感じることもあった。

じゃあEvangelistはどうかというと、 どれだけテクノロジーを伝えたか=自分の評価 となるポジションなので、その点においてはうってつけのポジションだといえる。

じゃあなぜDevRelにはならないと公言していたのか

シンプルな話、 かつてDevRel関連で嫌な思いをしたから の1点に尽きる。結構前の話なので掘り返しはしないのだけど、ユーザーへのリスペクトが欠ける対応をされたので、ああいうのはちょっとなぁ・・・となってDevRelを敬遠するようになったのだった。

ただ、それから数年。CloudNative DaysやPaaSJP、Platform Engineering Meetupなどのイベントを自分で主催し、さまざまなDevRel職の方と接する機会が増えてきた。結果として、「あのときはどうも例外に当たっただけで、ほとんどのDevRelの方は真剣にユーザーと向き合っている」ということが分かってきた。

最近ではかわまたさんを中心にDevRel Guildというコミュニティが発足し、活発な情報交換がなされている。

自分も本業の傍ら技術広報的な役割を担うことも増えていたことから、じゃあこれをメインの仕事にしてもいいんじゃないか?と思い始めたタイミングで今回の採用の話が転がりこんできたという流れだ。

入ってみてどうだったか

まだ2日しか経っていないので、プロダクトについてはこれから数週間かけてしっかりとキャッチアップしていく。ただ、現段階で確実にいえることは「本当に面白いプロダクトだな」ということ。

自分もそうだったし世の中からの見え方もそうだと思うが、PagerDutyとは「障害があったら叩き起こしにくるやつ」という認識をされている。それは間違っていないし、プロダクトの中心はそういったIncident Responseの機能だ。

だが、今はそれだけではない。AIによって賢くフィルタリングしてくれる機能、自動で背景情報を提供してくれる機能、イベントに応じて処理を自動化する機能など、めっちゃ便利な機能がたくさんある。

www.pagerduty.co.jp

ポストモーテムを自動で作成してくれる機能まである。自分が現場でプラットフォームを運用しているときに、これがあったらどれだけ楽になったことか・・・

support.pagerduty.com

他にも活用できたら素晴らしい機能がたくさんあるようで、何はともあれまずは自分で触ってみて学習していかないとなと。自分に課されたミッションは、こういった機能を 自分の言葉で 発信していくこと。できるだけ早く役に立つ話ができるよう務めたいと思う。