YAPC::Fukuokaに主にスポンサーとして参加しました #yapcjapan

行ってきたぜ福岡！

去年（函館）は前夜祭トークに呼んでいただいたものの、残念ながらリモートでの登壇となったため、現地へは1年空いての参加となりました。

今年もプロポーザルは出しましたが残念ながら落ちてしまったので*1、スポンサーとしての関わりが主となりました。

今回、YAPCとしても初となる企画「初日のLTテーマを企画できる＆表彰できる」というスポンサーをやらせていただきました。当日、あらためてスポンサー案内資料をよくよく読んでいたら「表彰パートを含めて5分ほど持ち時間があります」との文字が。それってLTってコト…！？

慌ててスタッフの皆さんに投影可能か確認を取り、ウオオと資料を用意し、諸々のロジを整理し、ドタバタと発表に流れ込んだのでした。

f:id:ar_tama:20251124214051p:image

今回は皆さんの前で喋る機会はないと思っていたので、なんだか嬉しかったです*2。

余談ですが、ベストスピーカー賞でれもんさん、ベストLT賞でtoku_bassさんなど、古くからYAPCでお世話になっているみなさんがスポンサーとして壇上に上がる様子は言い知れぬ感慨深さがありました。

翌日はinaoの部屋こと踊り場にキャトられたり（ありがとうございました！）、コーヒーブースで油を売ったりもしましたが、基本的にはスポンサーブースにいました。

ブースへは皆さんひっきりなしに遊びにきていただいて、感謝感謝でした*3！短い時間でしたが、タイムテーブルに載っていたり、導線がよかったり、幕間の時間が15分と長かったりすることによってたくさんの方に来ていただけたと感じます。ありがたや。

ジェンダーギャップについても触れておく

YAPCにおいて長くこの話題を公には口にしてこなかったんですが、例年より女性エンジニアの参加者比率が若干高まったように感じます。YAPCというエンジニアのお祭りを、認知してもらえる・面白そうと思ってもらえるようなコミュニティに徐々になってきたということでもあるのかな。実行委員長のびきニキさんのおかげかもしれないですね。本当に嬉しいです！

ただ、やはり比率が低いことによる諸問題はまだあって……たとえば初対面の方に「はじめまして！へぇ〜エンジニアさんなんですね！全然見えないですね！」と言われまして、大変悲しかったです。これは私に対しても、エンジニアという職業に対しても明確に差別的な発言です。私は（これも悲しいことに）慣れてしまっているので「それは本当にだめです」とお伝えしましたが、これが初参加の方に向けられていたかもしれない未来を考えると、ゾッとします。

これは発言したご本人の問題というよりは、厳然と存在するジェンダーギャップという構造が生んだ無意識の加害なので、やはり構造を変えていかないといけないなと。来年はきっとキャパも大きいので、何か私が手伝えることがあるといいな、と思っています。

そして、2度目のビッグサイト

Asiaの終わりをボランティアスタッフとして見届けて、JapanのコアスタッフとしてYAPC::Hokkaidoから始まるシリーズを再始動させて*4、karupaneruraさんたちに後を託した身として、「YAPCをまたビッグサイトでやる」はもうとんでもなくエモい意味を持ちます。これまで関わってくれた全ての皆さまにあらためて感謝を！

それでは皆さん、また来年お会いしましょう。さーて、次はどんなプロポーザルを出そうかな！

*1:Backlog World 2025にて転生を遂げました。スライドはこちら

*2:YAPC名物、八木さんにもお写真撮ってもらえたし

*3:#あらたまいくおの感想を寄せてくださった方も！嬉しい…！

*4:https://tamamemo.hatenablog.com/entry/2016/12/19/022126

YAPC::HiroshimaとYAYAPC::HiroshimaでトークとLTをしました #yapcjapan #yayapc

2024/02/10に行われたYAPC::Hiroshimaにて、 "エンジニアリングマネージャーのための「ぼうけんのしょ」" というタイトルでトークをしました。
マネジメントに携わる方々だけでなく、「チームでいいもの作って届けたい」と考える皆さんにとってのセーブポイント、あるいは旅のしおりとなるような内容を目指したつもりです。

speakerdeck.com

残念ながら2年連続のベストスピーカー賞…とはなりませんでしたが、既にたくさんの方にスライドを見ていただけているようです。嬉しい！FBもお待ちしています。
最初は「エンジニアリング組織論への招待」の内容も加えつつ、より経営に近い内容も盛り込もうとしていたのですが、20分枠だとさすがに難しく、現場を起点とした直接マネジメントに近い領域にフォーカスして構成しました。

自分の行動が次の誰かのきっかけになる、ということ

2024ベストスピーカー賞の三谷さんが受賞コメントで、私の去年のトークでYAPCを認知したこと、次の開催が地元だというのでご参加されたことをお話しされていました。また懇親会ではaerealさんが「あえてテックに振らない話題をプロポーザルに出してみようと思えたのは、去年のあらたまさんのトークとそれを受け入れるYAPCの土壌を見たから」とお伝えくださって、どちらもめちゃくちゃ嬉しかったです！！！！*1

YAPC::Kyoto 2023からもご縁をつないできたようです
YAYAPCのLT資料から抜粋。2023年から更にご縁を繋ぐことができて嬉しい

今回は懇親会があったこともあり、そのほかにもご感想・FBをたくさんの方から直接いただけて本当に感謝です。やっぱりオフライン登壇＋懇親会は最高ですね！
しかしまあ、「誰かのトークが聴いた人の人生をちょっと変える」はわりと聞く話ではありますが*2、自分がそれを言っていただく立場になろうとは。エンジニアなりたてのころは想像すらしていませんでした。

blog.yapcjapan.org

トークの話

スピーカーもベストスピーカー賞への投票権がもらえると嬉しいですね。マコピーさんのWebauthnのトークに投票したかったです。カンファレンスといえばライブコーディング！Perlを知らない方も多い中で、言語の解説や小話も挟みながらパスキー認証を実装していく手際の鮮やかさたるや。前日の👇も最高でした。


公募トークのうち特に印象に残っているのはnishimotzさんのWebアクセシビリティの話、ohbaryeさんの冪等性の話、koba04さんのキャリアの話です。どちらもこのタイミングで聴けてよかったと強く思う内容でした。素敵なトークをありがとうございました！

YAPCはロールモデル不在時代の「ロールモデル集め」の場になるかも

2010年代前半までのYAPCは、miyagawaさんを始めとした強烈な光のようなハッカーがたくさんいて、それに憧れる・きっかけをもらう人たちがいて、という構図が今よりは濃くあったと思います。翻って今のYAPCは、（表現が難しいのですが）いい意味で等身大というか、フラットというか*3。「Perl以外の話題もあるんだ、なんか面白そう」と初めて来てくれる方がたくさんいたり、いろんな人のいろんなトークを「いいな」と思って取り入れて明日に活かす（≒ロールモデルとする）ような、そんな楽しみ方が前面に出てきたような気が、個人的にはしています。
言語にとらわれすぎないカンファレンスとなったことで、YAPCは志向も世代も多様なハッカーが集まる稀有な場となっています*4。芯は残しつつ未来に向かってどんどん変容していくこのジオパークのような素敵なコミュニティを、微力ながら支える一助であり続けたいと強く思います。

YAYAPCのYAはヤバいのYA

オフライン限定の、訓練された大人のためのカンファレンス、それがYAYAPC……！

こういう会でした。最高でした。次は参加料取ってやりましょう（kobakenさんありがとうございました）。
そして会場に着くやいなやmyfinderさんから「タイムテーブル間違えちゃってLT枠が余ってるんだけどどう？」と棚ぼた的に枠をゲットしたので、急遽社内向けLTから抜粋してお話ししました。会社という船をみんなで前に進めるために必要なのは越境力！セクショナリズムは 暴力 越境で解決だ！

speakerdeck.com

大井町.pmのお二人（とxtetsujiさん）の企画も光ってました。ご準備大変だったと思いますが、LT審査員という栄えある（？）役回りもいただけて楽しい限りでした。

さいごに

ありがとう、ありがとう、ありがとう！

なによりLayerXの皆と来られたことが最高によかった。オフラインカンファレンス初参加の同僚もいたんですが、しっかり楽しんでくれたようですごく嬉しかったです。ノベルティを作ってくれた敏腕デザイナーのpommesさんにも感謝！

さーて、次はどんなプロポーザルを出そうかな！

*1:若干ニュアンスが違うかも。各位patches welcome!

*2:私もYAPCがきっかけで人生が二転三転している

*3:エンジニアキャリアが若い方にとってはmiyagawaさんはrebuildの人だし、naoyaさんは一休の人だし

*4:特に今年は学生時代からお世話になってきた先輩方、一緒に切磋琢磨してきた同世代の皆、CTO時代のつながり、LayerXの同僚と、あらゆる世界線が繋がってしまいエモ死ぬかと思った

「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」の用語を整理してみた

というわけで、自分の理解の整理のためにも、各概念をまとめ直してみました。

出典：「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」

本そのものの要約はこちらが詳しかったので、ご参考ください。 note.com

前提：価値交換システム

顧客にプロダクトやサービスを提供する（アウトプット）
↓
アウトプットが顧客の抱える要望や課題を解決する
↓
それに見合ったお金がビジネス側に返ってくる（アウトカム）

つまり、顧客が価値を認める（＝アウトカムが得られる）のは、自分たちの問題が解決したり、要望やニーズが満たされたときだけ

ビルドトラップ

  • 組織がアウトカムではなくアウトプットで成功を計測しようとして行き詰まっている状況
    • アウトカム…実際に生み出された（顧客に届いた）価値
    • アウトプット…機能の開発・リリース
    • ビルドトラップが起きるのは
      • アウトプットは顧客・顧客の求めるものへの理解なく出せるから
      • 戦略を「計画」として考えてしまうから

logmi.jp

主なアンチパターン

  • セールス主導
  • ビジョナリー主導
  • テクノロジー主導

戦略

  • 優れた戦略とは、意思決定を助けるフレームワークのこと
    • （詳細な）計画ではない
    • 単なる機能の列挙ではない
  • 「現在のコンテキストとの整合性を保ちながら、現在の能力の制約のもとで、望ましいアウトカムを達成するための行動を可能にする、実行可能な意思決定のフレームワーク」（The Art of Action）
  • 組織全体で語られるストーリーを相互に結びつけ、特定の時間枠における目的とアウトカムを説明するもの
  • 周りにストーリーを伝えて、足並みを揃える必要がある
    • 足並みを揃える＝組織（チーム）のサイズに適切なレベルの目標と、自律的に行動するために活動範囲を規定する（＝狭める）こと
    • マネジメントで言うところの「上意下達／翻訳」に該当

戦略の4つの粒度とその展開

★…誰が主導すべきか

ビジョン（企業単位）★CEO

5~10年でどうなりたいか、顧客にとっての価値、マーケットでのポジション、ビジネスがどうなっているか

戦略的意図（企業単位）★CEO, CxO

  • ≒ビジネス目標
  • ビジョンを実現する上で、立ちはだかっているビジネス上の課題は何か
    • 問いかけ「現在の状況を踏まえて、ビジョンを実現するために自分たちができる一番重要なことは何か？」
  • 価値検討フレームワークを活用して、 1個に絞る
    • 多すぎると「薄く塗ったピーナッツバター」＝全部が手薄になる

価値検討フレームワーク

例：Netflixは「ストリーミングをリードする」が戦略的意図だった
※ コンテンツを増やしたり、専用デバイスを作ったりしたのも、全てこの戦略的意図から派生したもの

プロダクトビジョン

  • 戦略的意図を達成するための価値提案
    • つまり、ユーザーに何を提供するのか
    • 戦略的意図とプロダクトイニシアティブをつなげる存在
      • プロダクトイニシアティブを考えるにあたって立ち返る場所として定義しておけるとよさそう
    • Amazonはプレスリリースを実際に書いて、これを簡潔な文章にまとめるというのをやっている

プロダクトイニシアティブ（プロダクト単位）★PdM

  • プロダクトの観点で課題に取り組むには、どんな問題を扱えばよいかの指針
    • ≒ビジネスの目標を達成するために、ユーザーや顧客のどんな問題を解決するべきか

オプション（プロダクト単位）★PdM, Des, Eng

  • 問題を解決して目標を達成する別の方法はないか
  • 「コンテンツの拡充により新規ユーザーの獲得・既存ユーザーのリテンションを向上する」がプロダクトイニシアティブのとき、それに対して最適な打ち手は何かを探索＝検証する
    • 供給者から自発的にコンテンツが増える働きかけをするのか、仕組みを作るのか
    • ユーザーからのFBが返りやすい仕組みを作るのか、FBまでのリードタイムを短くするのか
    • 新しい供給者を増やす働きかけをするのか

プロダクトのカタ

以下の1~4を、具体度を上げながらぐるぐる回してフェーズを進めていくイメージ

note.com

  • PdMはまず、企業のビジョン・戦略的意図を理解（または一緒に作るなど）して、プロダクトイニシアティブを立てるのを目標とする（1~3）
  • 1つのイニシアティブにつき複数のオプションが存在する場合は、それぞれが生むアウトカムがイニシアティブの達成にどれだけ近づいているかを測れるようにする必要がある
    • つまり、成功の指標を更に短い時間軸の中で計測できるものに分割する必要がある

フェーズと進め方

フェーズごとに以下の質問を自らに投げかけて、ぐるぐる回す

  1. 目標は何か？
  2. 目標を踏まえて、自分たちは今どこにいるのか？
  3. 目標に到達する上で立ちはだかる最大の問題や障害は何か？→どうやってその問題を解決するか？
  4. 何が怒ると予想されるか？（＝仮説）
  5. 実際には何が起こったか、そこから何を学んだか？

方向性の探索

  • アウトカムが生まれること＝ビジネス目標が達成されることなので、どちらともの健全性を測るための指標を定義する必要がある
    • AARRRとかHEARTとか

問題の探索

  • オプションとプロダクトイニシアティブを行ったり来たりして、解くべき問題を定める
  • ここまでがダブルダイヤモンドの左側

ソリューションの探索

  • 「問題」の解決策の検証
  • オプションが最適であることを、最短で導き出す

ソリューションの最適化

  • 最適なオプションを磨き込み、機能化する
  • ここで「作るべき機能とそのスコープ」が定まり、
  • 届けた価値をユーザーが享受し、
  • プロダクトイニシアティブの達成に一歩近づく

phperkaigiで完成度の低いLTをしてきたよ #phperkaigi

今回もうっかりCFPの締め切りを逃してしまったので*1、LTソンには顔を出そうかなと思っていたところ、トラックCでサイボウズさんの「完成度低いの歓迎LT大会」の公募版が開催されるとのことで、面白全部で飛び入りして喋ってきました。


fortee.jp

個人的にも「発表のハードルを下げる」のってめちゃくちゃ大事だと思っていて、私たちも「小話会」＝「ネタがあってもなくてもトピックをひねり出して持ち寄る会」を週1でやっています。
登壇経験のない・少ないメンバーも多いので、自分が率先して（ノー準備で）臨むことで、会社の外への「最初の一歩」のハードルを下げられたらいいな、みたいなことを考えていました。

  • Cake.jp（サービス）の宣伝
  • #EMゆるミートアップやってます
  • ところでsupabaseはいいぞ

の3点をおしながきに、ブラウザタブを切り替えながら雑に話しました。

またトークは、うずらさんものが個人的ベストでした*2。
「保守性の高いコードを書くこと」って間違いなく必要なスキルなんですが、「ただ書くこと」から認知のアップデートを4-5回繰り返さないとたどり着けない境地だと感じていて、そこに至るまでは（多少過激だし過剰ではあれど）「配列を捨てろ」くらいのことを言ってしまうのも手だよな〜と感じながら聴いていました。
（なお当社のコードベースにも同じような課題感があり、それを言語レベルで統制してくれることを求めてサーバーサイドKotlinへの移管という選択肢を取ったという経緯があります）
fortee.jp

リアル懇親会を開催いただけたのもよかったです。スタッフの皆さま、感染症対策など大変だったかと思います、ありがとうございます。こうしてまたみんなでワイワイできる日が来たことが大変うれしいですね。
初めましての方とも、他言語のコミュニティでお見かけしたお久しぶりな方ともたくさんお話しできてよい時間となりました。
そーだいさんとは次回広島で再度刃を交えたいと思います*3。

また来年！

*1:小桜さんに読み上げられたい人生だった

*2:YAPCで近況を伺ったりもしていたので、なおさら直面している課題の様子がありありと思い描けたというのもあり

*3:スレチ

YAPC::Kyoto 2023でベストトーク賞をいただきました #yapcjapan

なんと4年ぶりのYAPC！超楽しかったです！！！！！
あまり多くトークを観られなかった（後日動画で追っかけます！）のですが、渡部さんの障害対応・訓練のお話は明日から早速使えるネタをたくさんいただけて大変勉強になりました。またCloudflareなどまだ自分がプロダクションで採用したことがない技術の話がたくさん聴けたのも有り難かったです。

話したこと

私も採択いただき、かつての自分の葛藤を下敷きに、職業エンジニアのキャリアの軸について考察する…といった構成でお話ししてきました。

speakerdeck.com

なおトークではこの資料の5倍くらいのスピーカーノートを元に喋っていましたw 動画が上がったらそちらもぜひご笑覧ください。
実はこのテーマで応募すること自体も、それこそ「技術ネタでもないのに…」などと最後まで逡巡していたんですが、そういった葛藤も、技術的な挑戦についても、全部ひっくるめてお話しすることで、何かしら持って帰っていただけるものがあるんじゃないか、と腹をくくってエイヤしたという流れがありました。

という覚悟で臨んでたんですが、本当にたくさんの方に来ていただけて感無量でした。
エンジニアとしてのキャリア形成に悩む若手〜中堅の方にいくばくかヒントのお裾分けができたようで*1、エイヤしてよかったですね。

と思っていたら、クロージングでまさかの展開に

全く予期していなかったのでめちゃくちゃ動転してしまったw ありがとうございます、win開発やっていきます*2。
自分のキャリアは常にPerlコミュニティと共にあった*3ので、折々で助けてくださった皆さんにお礼を伝えられたこと、また新しい風を吹かせてくれるであろう皆さんに少なからずバトンをお渡しできたかもしれないことを大変嬉しく思っています。

会場でもスピーカーディナーでも、ご挨拶したかったのに叶わなかった方がたくさんおりまして…！次回！広島で絶対会いましょうね！！！絶対だよ！！！

さいごに

最高の会でした！久々だし初の試みは多いしでマジで本当に大変であろうことには想像に難くないんですが…、延期！と言い張り続けてくれたパピさん・あずまさんを筆頭に、コアスタッフ・ボランティアの皆さんのおかげで実現したお祭りだと思います。改めてお礼を言わせてください。

追記

私と一緒に開発組織を作ってくれる仲間を大募集しています！めちゃんこ人が足りなくて困っています😇ぜひお気軽にお声掛けください！！

*1:実際に感想をいただきました。嬉しすぎる……

*2:多分初手でLinux入れるけど！

*3:YAPCきっかけで就職先を決めた、YAPC::Japanを立ち上げた、等々

YAPC::Kyoto 2023で話します！　そしてチケットを今すぐに購入しましょう！！

YAPC::Kyoto 2023の採択トークが決まったようですね。面白そうなトークが沢山あってすごいですね。

blog.yapcjapan.org

私のトークも採択されました。ありがてぇ！

こういう話をします。

YAPC::Asiaで憧れたハッカー集団の末席に、新卒という形で頭から飛び込んだのが約10年前。YAPCを始めとした様々な技術コミュニティにお世話になり、時にはスタッフや運営・スピーカーとして貢献しながら、少しずつ歩を進めてきました。
キャリアとしては事業会社のエンジニア・リードエンジニアを経て、現在はCTOとしてエンジニアリングだけでない様々なロールを担っていますが、これまでのキャリア選択の傍らには常に「ハッカー」への憧れがありました。
いつしかそれが自分への呪縛となっていたこと、そして様々な葛藤と試行錯誤を経て、ようやくそれから解き放たれつつあることに、最近気づきつつあります。
エンジニアとして、時にはロールを変えながらサバイブする皆さんに。またかつての悩める自分に、ちょっとしたヒントをおすそ分けできるようなトークにしたいと考えています。

ええと、はい、某年のキーノートへのアンサーソング的なヤツです。
テック方面はお歴々にお任せして、キャリア的な話に振ってみました。

このトークの応募に至るまでにも様々な葛藤があったのですが…w、採択いただけたということで気を引き締めて、皆さんにちょっとでもなにかを持って帰っていただけるようなトークにできたらと思います。ｶﾞﾝﾊﾞﾘﾏｽ

チケットを買ってくれ

それはそうとして、そんなYAPC::Kyoto 2023ですがチケット販売が今月1月の31日までとなっています。

passmarket.yahoo.co.jp

今月中にチケットを買わないと参加ができないのです！　今、まさにこの瞬間、すぐに買いましょう！！！！！
豪華ノベルティがついてくる個人スポンサーチケットは残席わずかとのこと！！

買いましたか？買いましたね。それでは会場でお会いいたしましょう！

yapcjapan.org

オマージュ元
uzulla.hateblo.jp

tailwind触ってみたメモ

個人のプロジェクトで採用できそうな機運があったので、ためしにNext.jsのサンプルページをtailwindに書き換えるのをやってみた。
絶対値指定を避けているので若干差分は出たけど、それなりの再現が叶えられたのと、書き味も悪くなくていい感じ。最低限のデザインシステム（ルールもしくはレール）に乗っかれている感覚がある。

感想
  • 間違っても「css知らなくても書ける」なんてことはない
    • 慣れるまでは、一回付加したいcssを列挙→クラス名に変換→適用というステップが必要
    • チートシートに首っ引き必至だけど、頻出cssは大抵の場合そんなに多くないし、すぐ慣れそう
  • これまでclassに付加していた「意味のまとまり」が消えるので、CSS Moduleで表現していた領域・責務がコンポーネント側に寄るような印象を受けた
    • 「しっかりコンポーネント分割してtsxの可読性を保とう」という意識がはたらきやすい
      • applyを積極的に使っていくよりはコンポーネントを分割するほうが本質的な気がした
    • 一方で、集団で開発するときはきちんと足並みを揃えられるかが導入可否のポイントになりそう
      • tsx（html）を書く人がcssも書けるとは限らない…という状況もありそう
  • 薄いし共存・カスタマイズもできるので、既存のcssからページベースで移行するユースケースにも適用できそう
    • 独自にルールを作り込む必要は少ないけど、特に最初は前述の責務の切り分けを念頭に置いてプロトタイプできるとよさそう
  • 余談：vscodeのIntelliSence extensionべんり
before
before
after
after
diff

あえてコンポーネント分割などはしていないので、特にcardのところが冗長になっている

diff
参考

baigie.me

blog.uhy.ooo

webty.jp