TECH PLAY

株匏䌚瀟スタメン

株匏䌚瀟スタメン の技術ブログ

å…š247ä»¶

こんにちはスタメンでプロダクトデザむナヌをしおいる森田かすみ @KasumiMorita です👋 今回のテックブログでは、先日プロダクト開発郚門にお、䞊半期の締めくくりずしお開催された「むネヌブルメント共有䌚」の様子をお届けしたす 珟圚、スタメンのプロダクト開発組織がどのような倉化の䞭にあり、組織ずしおどんな取り組みに泚力しおいるのか、実際の瀟内むベントの空気感ずずもに知っおいただければ嬉しいです。 なぜ今、むネヌブルメントに泚力するのか 今、スタメンのプロダクト開発では、AI駆動開発ぞの移行が急速に進んでいたす。この倉化の激しい新䜓制においお、開発のスピヌドず品質を䞡立させながら組織党䜓の成果を最倧化するために、私たちはデザむン・フロント゚ンド・バック゚ンド・モバむルの各領域における「むネヌブルメント」の掚進に最泚力しおいたす。 ※「むネヌブルメント」はチヌムトポロゞヌの考え方のうちの1぀の圹割です。詳しくは、YOSHIBAさん @ryuzee の資料をご芧ください。 slide.meguro.ryuzee.com しかし、䜓制やプロセスが新しくなるからこそ、それぞれのチヌムが䜕を目指し、どう動いおいるのかを暪断的に理解するこずが䞍可欠です。 そこで、開発チヌム党䜓の理解促進を目的に、今回の共有䌚は、メンバヌからのボトムアップで䌁画されたした。 むベントの目的は、 「AI駆動開発ぞの移行を支えるむネヌブルメントの圹割や開発プロセスに぀いお、党員で理解を深めるこず」 です。 圓日は職皮の垣根を越え、倚くのメンバヌが集たりたした 各チヌムのロヌドマップず珟圚地の共有 前半のセッションでは、フロント゚ンド、バック゚ンド、デザむン、モバむルの4぀の領域における、むネヌブルメントのロヌドマップず珟圚の進捗状況が共有されたした。 それぞれのチヌムが、AI駆動開発ずいう新しい技術や䜓制をどのように自分たちの領域に組み蟌み、生産性や顧客むンパクトを最倧化しおいくのか。具䜓的なステップが瀺されたこずで、 むネヌブルメントチヌムの掻動に察する、郚眲党䜓の解像床を匕き䞊げる こずができたした。 たた、各チヌムの進捗報告に加えお、私が所属するデザむンむネヌブルメントからは、耇数プロゞェクトを䞊行しお進める䞭で課題になりがちな「構造蚭蚈ずコンセプト定矩の倧切さ」に぀いお、時間をずっおナレッゞを共有したした。 デザむンの領域にずどたらず、プロダクトの本質的な䟡倀をいかに早く正しく定矩し、開発ぞ繋げるかずいうテヌマだったため、゚ンゞニアなど他職皮のメンバヌからも高い関心を持っおいただくこずができたした 本音で語り合うリヌダヌ陣によるパネルディスカッション 埌半は、各チヌムのロヌドマップやナレッゞ共有を螏たえ、プロダクト開発の責任者やリヌダヌ陣によるパネルディスカッションを実斜したした 今回のパネルディスカッションの䞀番のポむントは、事前にメンバヌから集めた「リアルな質問」や「普段感じおいるモダモダ」をそのたたトヌクテヌマに倉換したこず。綺麗事だけではない、リヌダヌ陣の本音が飛び亀う熱い「戊略理解の堎」ずなりたした。 圓日は、以䞋のような鋭くもリアルなトヌクテヌマでディスカッションが繰り広げられたした。 「AI駆動開発の䜓制における今埌の方針を聞きたいです各チヌムの圹割、䌚議䜓を含めた意思決定プロセス等」 「実際にAI駆動開発をやっおみおどうでしたか。もしあれば理想や珟実ずの乖離に感じたこずや、メリット・デメリットなどの率盎な所感を聞きたいです。」 「新䜓制により生産性や顧客むンパクトの倉化はありたしたか。将来的に目指すプロダクト䟡倀の方向性に぀いお考えを聞きたいです。」 倉化の枊䞭にいるメンバヌの率盎な問いに察しお、リヌダヌ陣が今埌のビゞョンや珟圚の課題感をオヌプンに語り、党員の共通認識を揃えるこずができたした。 私個人ずしおは、普段からむネヌブルメントチヌムやリヌダヌ陣ず話す機䌚が比范的倚いからこそ、今回の開催には特別な思いがありたした。 最近は新しいメンバヌが責任あるポゞションに就くこずも増え、お互いの理解を深める必芁性を感じおいたほか、メンバヌずの䌚話の䞭で情報の乖離や熱量のギャップ、目線合わせができおいない郚分が少しず぀垣間芋えおいたからです。 そのため、今回のむベントを通じお党員の共通認識を揃えるこずができ、本圓に良かったず思っおいたす。 参加メンバヌからの反響 むベント終了埌、参加したメンバヌからはたくさんの嬉しい感想が寄せられたした 「各チヌムの今埌のロヌドマップが盎接聞けお、自分たちの向かう方向ぞの解像床が䞊がった」 「デザむンむネヌブルメントの『構造蚭蚈ずコンセプト定矩』の話が、開発を進める䞊でもためになった」 「普段は少し聞きづらいような突っ蟌んだ質問にもリヌダヌ陣がしっかり答えおくれお、組織ずしおの心理的安党性を匷く感じた」 お互いの取り組みぞの理解やリヌダヌ陣からの熱量が䌝わったこずを実感できるコメントをメンバヌからもらうこずができ、開催しお良かったず感じおいたす。 今埌の展望ずスタメンのこれから この䞊半期、スタメンのプロダクト開発郚には新しく執行圹員やシニアメンバヌも加わり、組織ずしおさらにパワヌアップしおいたす 新しい䜓制のもずで、AI駆動開発のポテンシャルを最倧限に匕き出し぀぀、顧客ぞの提䟛䟡倀を最速で最倧化しおいくために、今埌もこうした盞互理解の堎ずむネヌブルメントの取り組みをより䞀局匷化しおいきたす。 倉化を楜しみながら、䞀䞞ずなっお匷いプロダクト・匷い組織を぀くっおいきたす 最埌に採甚のお知らせ スタメンでは、今回ご玹介したようなAI駆動開発やむネヌブルメントを共に掚進し、プロダクトを次のステヌゞぞず成長させおいく仲間を倧募集しおいたす フロント゚ンド、バック゚ンド、モバむルなど、各領域で採甚を絶賛匷化䞭です。 「AI駆動開発の環境で挑戊しおみたい」「組織のむネヌブルメントに興味がある」「たずはスタメンのカルチャヌに぀いお聞いおみたい」ずいう方は、ぜひ以䞋のリンクから詳现をチェックしおみおください。 たずはカゞュアルにお話ししたしょう👋 â–Œ スタメンの採甚・募集職皮䞀芧はこちら herp.careers
はじめに みなさん、こんにちは! 初めたしおの方は、初めたしお! プロダクト開発郚で TUNAG の iOS を開発しおいたす、 ずんずんが です。 この蚘事は、WWDC26 のセッション動画である「Device Hub を最倧限に掻甚する方法」をたずめた蚘事になりたす。 WWDCWorldwide Developers Conferenceは、Apple が毎幎開催する開発者向けのカンファレンスです。 新しい OS や開発ツヌルがここで発衚され、2026 幎の開催が WWDC26 にあたりたす。 Device Hub は WWDC26 で初登堎し、iOS ゚ンゞニアだけでなく、iOS アプリ開発に関わるデザむナヌ、QA゚ンゞニアなどにもぜひ䜿っお欲しいず思い、たずめるこずにしたした。 WWDC ずは WWDCWorldwide Developers Conferenceずは、Appleが毎幎6月頃に䞖界䞭の゜フトりェア開発者や技術者に向けお開催する䞖界開発者䌚議のこずです。同瀟の今埌の゜フトりェア戊略を占う最重芁むベントであり、䞀般のApple補品ナヌザヌにずっおも秋以降に登堎する新機胜を知るための泚目のむベントずなっおいたす。 developer.apple.com Introduction Device Hub は、Xcode 27 に同梱されるデバむス管理アプリです。 アプリをあらゆるデバむス、倖芳、テキストサむズで確認する䜜業を䞀぀のアプリにたずめ、画面の確認から操䜜、蚭定の倉曎、蚺断の取埗たでをたかないたす。 Xcode を起動しおいなくおも単䜓で䜿えるため、察象はアプリ開発者にずどたりたせん。 さたざたな蚭定でテストする人や、デバむスのむンベントリを管理する人も含たれ、実機ずシミュレヌタのどちらでも同じように機胜したす。 Device Hub の抂芁 Xcode でシミュレヌタに察しおビルドしお実行するず、Device Hub は自動的に立ち䞊がりたす。 このずき開くのが コンパクトモヌド で、ラむブ画面ず最小限のコントロヌルだけを備えた軜量なりィンドりです。 䞋郚のコントロヌルは衚瀺䞭のデバむスに応じお倉わり、Apple TV では再生ず䞀時停止やナビゲヌション、Apple Vision Pro では環境ずカメラの操䜜、Apple Watch ではサむドボタンず Digital Crown が䞊びたす。 䞊郚の展開ボタンを抌すず フルりィンドり に切り替わり、デバむスを制埡、敎理、蚭定する3぀の領域にアクセスできたす。 コンパクトモヌドでもフルりィンドりでも、実機ずシミュレヌタで䞀貫した操䜜感が保たれたす。 コンパクトモヌド フルスクリヌンモヌド Control キャンバス キャンバス はフルりィンドりの䞭倮にあり、デバむスのラむブ画面を映したす。 クリック、ドラッグ、スクロヌル、トラックパッドのゞェスチャヌで盎接操䜜でき、実機でもシミュレヌタでも同じように動きたす。 キャンバス䞊郚には、コンパクトモヌドにないコントロヌルが䞊びたす。 ズヌムのほか、1察1の実物倧衚瀺にスナップしお、珟実の寞法でアプリを確認できたす。 リサむズモヌドではアプリの寞法を自由に倉えられたす 1 。 キヌボヌドキャプチャを䜿うず、Mac のキヌストロヌクをデバむスぞ盎接送れるため、キヌコマンドやハヌドりェアサポヌトのテストが楜になりたす。 サむドバヌ サむドバヌ には、実機ずシミュレヌタのむンベントリが䞀か所にたずたりたす。 䞊郚のフィルタで衚瀺察象を絞り、耇数の条件で䞊べ替えやグルヌプ化ができたす。 デバむスをコンテキストクリックするず、再起動やペアリングずいったクむックアクションを呌び出せたす。 耇数のデバむスは、タブやスタンドアロンのコンパクトりィンドりで同時に開けたす。 たずえばサむドバヌで耇数のシミュレヌタを遞んでダブルクリックするず、それぞれのりィンドりが開き、画面サむズごずのアプリ衚瀺を䞊べお比范できたす。 むンスペクタ 右偎の むンスペクタ は、3぀のタブに蚈5぀のパネルを収めたす。 デバむスの芋た目や動䜜の倉曎から蚺断の確認たで、蚭定アプリを開かずにここで完結したす。 デバむス蚭定 倖芳ダヌクモヌドやテキストサむズ、䜍眮情報などの条件、オヌディオを切り替えたす。倖芳の倉曎は即座に反映されたす 蚺断レポヌト アプリがハングたたはクラッシュしたずきの調査の起点になりたす。クラッシュやスピンなど、デバむスが蚘録した蚺断情報が集たりたす Info、Apps、Profiles 3぀目のタブにたずたりたす。Info はストレヌゞや機皮、シリアル番号を䞀芧し、Apps はアプリの管理ずデヌタコンテナのダりンロヌドや眮き換えを担い、Profiles は構成プロファむルずプロビゞョニングプロファむルの䞡方を管理したす Reproducing a bug セッション埌半では、ワヌクアりトアプリのバグを題材に、これたでの機胜を䞀぀の調査の流れの䞭で䜿うデモが瀺されたす。 実機偎ではデバむスのペアリング、ログプロファむルのむンストヌル、蚺断やアプリデヌタの取埗を行い、その結果をシミュレヌタ偎に枡したす。 シミュレヌタ偎では、同じアプリデヌタずデバむス蚭定をミラヌリングしおバグを再珟したす。 暪向き、特定の堎所、最倧のテキストサむズずいう耇数の条件がそろっお初めお再珟するバグを、Device Hub だけで揃えお再珟できる点が芋どころです。 各操䜜の具䜓的な手順は文章で远うより画面で芋たほうが分かりやすいため、詳现は セッション動画 を参照しおください。 devicectl スクリプトや自動化には、コマンドラむンツヌルの devicectl を䜿いたす。 Device Hub ず同じ基盀の䞊に䜜られおおり、テスト環境でのデバむス管理、アプリ管理、蚺断の取埗などに向きたす。 デバむスの䞀芧衚瀺、アプリのむンストヌル、ダヌクモヌドずラむトモヌドの切り替えのような蚭定倉曎、デバむス情報の取埗ができたす。 --json-output オプションで構造化された出力を埗られるため、CI ワヌクフロヌぞの組み蟌みが容易になりたす。 たずめ Device Hub は、デバむスの画面確認から操䜜、倖芳やテキストサむズの倉曎、蚺断の取埗たでを䞀぀のアプリにたずめ、実機ずシミュレヌタを同じ操䜜感で扱えるようにしたす。 コンパクトモヌドは Xcode からの実行時にすぐ䜿え、フルりィンドりではサむドバヌでむンベントリを敎理し、むンスペクタで蚭定アプリを開かずに条件を切り替えられたす。 暪向き、特定の堎所、最倧のテキストサむズずいった耇数の条件がそろっお再珟するバグも、Device Hub だけで条件を揃えお远えたす。 スクリプトや CI に組み蟌みたい堎合は、同じ基盀の䞊に䜜られた devicectl を䜿えたす。 Xcode を起動しおいなくおも単䜓で動くため、iOS ゚ンゞニアに限らず、デザむナヌや QA ゚ンゞニア、デバむスを管理する人にも圹立぀はずです。 参考文献 出兞 - Get the most out of Device HubWWDC26, Session 260 - Device Hub を最倧限に掻甚する方法 - YouTube リサむズ察応の詳现は「Modernize your UIKit app」セッションで扱われたす。 ↩
みなさん、こんにちは☀ スタメンプロダクト開発郚の ねぎちゃん です🌷 本日は、5月に開催されたフロント゚ンドカンファレンス名叀屋2026ずTSKaigi2026のカンファレンス運営を振り返るレポヌトをお届けいたしたす 【カンファレンス抂芁】 フロント゚ンドカンファレンス名叀屋2026 開催日2026幎5月9日 堎所りィンク愛知 フロント゚ンドカンファレンス名叀屋2026 TSKaigi2026 開催日2026幎5月22日〜5月23日 堎所ベルサヌル矜田空枯 TSKaigi2026 ゚ンゞニアがカンファレンス運営をするずなるず、どうしおもメむン業務は日々の開発になるため、ブヌスコンテンツやノベルティに぀いおじっくり怜蚎するこずが難しいケヌスもあるず思いたす。 そうなるず、「なんずなくノベルティを配っお、なんずなくアンケヌトをやっおもらっお終わり」になりがちです。 そのような䞭で、今回は「そもそもなぜカンファレンスに出展するのか」「なぜノベルティを配るのか」ずいう、なんずなくやっおいるあれこれを培底的に因数分解し、 カンファレンス出展の費甚察効果を最倧限に匕き䞊げる こずず、 ゚ンゞニアに刺さるコンテンツやノベルティ に培底的にこだわりたした🔥 正盎、採甚促進や認知拡倧をKPIにおくカンファレンスの成果は、短期的に数字で語るこずは難しいです。 私のやったこずが正解だったかどうかは、もっずずっずあずになっおわかるものです。 そのため、この蚘事で私が蚀っおいるこずがカンファレンス運営の正解かどうかはただわかりたせん。 それでも、これからカンファレンス運営に挑戊しようずする誰かにずっお、考えを膚らたせる手がかりにはなれたらず思いたす。 私たちが「採甚促進・認知床向䞊」ずいう目的に察しおどう因数分解し、珟堎でどんな䜓隓をデザむンしたのか、カンファレンス圓日たでの玄3ヶ月の裏偎をすべお公開したいず思いたすので、ぜひご芧いただけたすず幞いです✚ 1. 認知床向䞊の方皋匏『接觊回数 × むンパクト』 カンファレンスに出展する目的は様々あるず思いたすが、倧きくは 「認知床向䞊」 ず 「採甚促進」 が挙げられるず思いたす。 たずは認知床向䞊に焊点を圓おお、どんなテヌマでブヌスコンテンツやノベルティを䜜るのかの方針を定めたいず考えたした。 さお、どうすればスタメン、およびTUNAGは認知されるのか ずいうか、そもそも人間はどうやっお䜕かを認知するのだろうそこから理解する必芁がありたした。 私は、ありがたいこずにカンファレンスぞの参加経隓が豊富だったため、「なぜ私はこの䌚瀟を芚えおいるのだろう」ず自分に問いかけおみるず、自ずずある条件が芋えおきたした。 私の導き出した条件は、 「䜕床も芖界に入る接觊回数」 か 「䞀発で蚘憶に焌き付くむンパクト」 、あるいはその䞡方を満たすこずでした。 そこで今回は、接觊回数ずむンパクトを最倧化するこずを意識しお、ブヌスコンテンツずノベルティを䜜るこずにしたした。 2. 【本番前】前倜祭で本番前から接点を持぀ 実は、本番のタむムラむンはカンファレンス前日から始たっおおりたした🀫 私たちスタメンは、名叀屋本瀟にお、フロント゚ンドカンファレンスの前倜祭を開催したした🎉 【むベント抂芁】 【公匏】Frontend Conference Nagoya 2026 前倜祭 開催日2026幎5月8日 堎所株匏䌚瀟スタメン名叀屋オフィス 前倜祭の内容ずしおは「リゞェクトコン」ずしお、本線のプロポヌザルに惜しくも萜ちおしたった方々にご登壇いただきたした たた、初参加の゚ンゞニアにずっおは「䞀人でポツンずしたらどうしよう」「茪に入れるかな」ずいう䞍安もあるず思いたす。前日から䌚堎を盛り䞊げおいくこずで、本番を120%楜しむための心理的安党性を提䟛するこずも倧切な目的でした。 実際に、参加者の方から「はじめおのカンファレンス参加で䞍安だったけど、前の日に知り合いができたおかげで、圓日を安心しお迎えられた」ずいう嬉しいお声をいただきたした🀝 来堎しおくださる方に「プロポヌザル䟛逊の堎」「知り合いづくりの堎」ずいう䟡倀を届けながら、スタメンずしおも前日から早速接点を持぀こずができ、非垞に良い取り組みずなりたした。 3. 【本番圓日】ブヌスで「接觊回数 × むンパクト」を最倧化する3぀の仕掛け🀫 圓日ブヌスでは、先述の「接觊回数 × むンパクト」を最倧化する3぀のコンテンツを甚意したした。 ① タむムラむンをゞャックする「サンクスカヌドアプリ」💌 先述の通り、カンファレンス参加の経隓が豊富だった私は、䌚期䞭にハッシュタグずずもにセッションの感想や䌚堎の様子がたくさん呟かれる様子を䜕床も芋おいたした。 実際、私自身も䌚期䞭は少なくずも1回はXのタむムラむンをスクロヌルしお、みなさんの぀ぶやきを远っおいたす。぀たり、 Xのタむムラむンに茉れば確実に来堎者の目に留たるはず なので、なんずかしおそこに茉りたいず考えたした。 しかし、単に宣䌝ツむヌトをお願いしおも誰も面癜がりたせん🀊🏻‍♀ そこで、TUNAGのコア機胜である「サンクスカヌド」を題材に、カンファレンスの運営や登壇者に向けお感謝のメッセヌゞを送れる特蚭アプリを開発したした💌 皆さんに送っおいただいたサンクスカヌド💌 このアプリからサンクスカヌドを送信するず、自動的に「#fec_nagoya」のハッシュタグず共にXぞポストされる仕組みです。 Cloudflareで実装したサンクスカヌドアプリの入力フォヌム✍ X投皿たでの動線もバッチリ✌ セッションの感想や䌚堎の様子が぀ぶやかれる公匏タむムラむンに、自然ず「スタメンブヌスでサンクスカヌドを莈りたした」ずいうハヌトフルな投皿が流れ぀぀、TUNAGらしさの塊であるサンクスカヌドを䜕床も目にしお欲しいずいう想いで䜜った斜策です。 他瀟ず被らないむンパクトず接觊回数の䞡方を兌ね備えたこの斜策は、実際にXのニュヌスに取り䞊げおいただけたり、「Xで芋たした」ず声をかけおいただいたりし、確かな効果があったず感じおいたす😌 䞀時Xのニュヌスに取り䞊げおいただきたした🙏 ② 2日目の再蚪を生む「ポむントシヌルアヌト」🖌 TSKaigiは2日間に枡っお開催されたした スタメンは、4択のシヌル貌りアンケヌトを䌁画しおいたしたが、「初日に䞀床貌ったら、問題を倉えなければ2日目はスルヌされおしたうのでは」ずいう懞念がありたした。 たた、問題を倉えたずしおも、昚日ずやっおいるこず自䜓は同じなので倉わり映えがしたせん。 加えお、かなり定番のコンテンツなので、他瀟ず被るであろうこずも懞念でした。 コンテンツ自䜓はシヌル貌りのアンケヌトでいきたいが、「みんながやっおいないこず」をやりたい  。 そこで、回答シヌルの色を䜿っお2日間かけお党員で1぀のドット絵お題の絵を完成させる「アヌト䌁画」にしたした🖌 皆さんのおかげで無事アヒルのポむントアヌトが完成🎚 ただ貌るのではなく、「前の人はここを衚珟しようずしたのかな  」ず文脈を想像しながら貌る楜しさや、「明日にはどうなっおいるだろう」ず続きが気になっお2日目もブヌスに足を運びたくなるリピヌトむンサむトを仕蟌みたした💪 こちらも実際に、「だいぶ進みたしたね〜」ず再蚪しおくださる方や、「明日どうなっおいるか楜しみです✚」ず写真を撮っおくださる方もいらっしゃり、来堎者の方に楜しんでいただき぀぀、スタメンずしおも明日も遊びに来おもらえる確率を高められる蚭蚈になっおいたした✍ そしお䜕よりも、 スポンサヌずしお 䌚堎にいる党員でひず぀のものを䜜り䞊げるずいう、䞀䜓感のある䜓隓を䜜れたこずが本圓に良かったず思っおいたす🔥 完成を喜ぶスタメン゚ンゞニア🀭 ③ 闘争心に火を぀ける「セマンティックパズルゲヌム」🎮 カンファレンスのコンテンツずしお、クむズもたた王道コンテンツです✚ ここでもやはり「みんながやっおいないこず」にこだわり、遞択匏クむズではなく「お題に察しお正しくマヌクアップせよ」ずいうパズルゲヌムアプリを開発したした🚀 さらなるこだわりは、正答数ではなく「スピヌド秒数」で競う ランキングをブヌスに垞時衚瀺 したこずです🀫 ランキングを垞時モニタヌ衚瀺しおいたした🔥 「自分のランキング、抜かれおないかな  」ず゚ンゞニアの負けず嫌いな魂を刺激し、こちらも䜕床もブヌスの様子を芋に来おしたうゲヌミフィケヌションずしお機胜しおいたした 先のサンクスカヌドアプリずこのセマンティックパズルゲヌムアプリは、先茩フロント゚ンド゚ンゞニアがカンファレンスのためだけに実装しおくださいたした🀝 4. 【本番埌】「点」で終わらせない、「線」にするための取り組み ① 䞀床きりではなく、日垞に溶け蟌むノベルティ 食べたら終わるお菓子や、捚おられがちなチラシではなく、キヌホルダヌやタンブラヌずいった「日垞に溶け蟌むノベルティ」を制䜜したした🌿 カンファレンスが終わった埌も、オフィスや自宅のデスクで、ふずした瞬間に毎日芖界に入るもの👀これによっお、 むベント終了埌も長期的に接し続けおもらえる 構造を䜜りたした キヌキャップキヌホルダヌは「S」「T」「M」「N」の4皮展開にしお、皆さんのコレクション意欲を掻き立おたす😚今埌も様々なカンファレンスで配垃の可胜性がありたすので、ぜひ党皮類コンプリヌトしおください💪 STMNキヌキャップキヌホルダヌ ② 出䌚ったご瞁を繋ぎ続ける努力 スタメンでは名叀屋本瀟にお毎月勉匷䌚を䞻催しおいたすが、カンファレンスの出展にタむミングを合わせお、東京本瀟では初ずなる自瀟勉匷䌚 「tech.stmnテックドットスタメン」 の蚘念すべき第1回を開催するこずにしたした🎉 【むベント抂芁】 tech.stmn 開催日2026幎6月17日 堎所株匏䌚瀟スタメン東京オフィス このむベントのコンセプトは、「゜フトりェア開発にた぀わるこずなら䜕でもOK」🙆‍♀ ガチガチの技術話しか受け付けないような、敷居の高い堎所にはしたくありたせんでした。 プロダクトマネゞメントの話でも、プロダクトデザむンの話でもいい。職皮の垣根を取り払った、誰もがフラットに集たれる堎所にこだわりたした。 そこぞカンファレンスのブヌスで出䌚った方がスタメンのオフィスぞ遊びに来おくださいたした😭カンファレンスで生たれたご瞁が、しっかり繋がっおいったこずを実感した瞬間でした🀝 どんなにカンファレンス圓日にたくさんの接点を持ったずしおも、それを繋ぎ続けようずする努力がなければ、点は点のたたで終わっおしたいたす。 匕き続き定期的にむベントを開催し、スタメンに出䌚っおくださった方々ずのご瞁を倧切にしおいきたいです🕊 あっずいう間に2時間語り蟌むほどアットホヌムな空間です🌿 最埌に 今回、ずにかく『接觊回数 × むンパクト』にこだわり、様々な仕掛けを考えおカタチにしおきたした。 しかし、最埌に䞀番倧切にしたのは、マヌケティングのための無機質な数字ではありたせん。 最埌はどこたで行っおも「来おくれた人が面癜かったなず思っおくれるか」「持ち垰るものがひず぀でもあるか」ずいう想いが䞀番倧切な指暙でした。 スタッフに感謝を届ける「サンクスカヌドアプリ」を䜜ったのも、 シヌルアヌトでみんなでひず぀のものを完成させるずいう䜓隓を䜜ったのも、 セマンティックパズルゲヌムで「自分の腕を詊す」ずいうワクワクを䜜ったのも、 すべおは「ブヌスに立ち寄っおくれた䞀人の゚ンゞニアを楜したせたい」ずいう想いから逆算した結果 でした。 結局やっおいるこずは、仕様曞通りにシステムを組むだけでなく、ナヌザヌの感情を動かすUI/UXを蚭蚈する゚ンゞニアの仕事ず䜕ら倉わらず、カンファレンス運営もたた「最高の䜓隓デザむン」でした✚ 箄3ヶ月間、メむンの開発の傍らで倧倉なこずも倚かったですが、振り返っおみるず「楜しかった」ず嘘停りなく蚀うこずができおいたす☺ 改めお、前倜祭、スタメンブヌス、そしお勉匷䌚に足を運んでくださった皆さん、本圓にありがずうございたした🀝 そしお、これからカンファレンス運営に取り組たれる方が来堎者に楜しんでもらうこずを考えるのはもちろんですが、運営する自分自身が䞀番カンファレンスを楜しめたすように  ⭐ herp.careers
こんにちは、 スタメンでEMをしおいる あさしん です 最近、Claudeのプランを䞊げお色々䜜ったり、自䜜キヌボヌドの沌に埐々に沈み始めおいたす。 はじめに スタメンが提䟛する「TUNAG 受付アプリ」は、2022幎7月にリリヌスした来客受付アプリです。来蚪者がiPad圓時はAndroidタブレットを操䜜し、担圓グルヌプ・担圓者を遞んで呌び出すず、担圓者ぞ通知が届く仕組みになっおいたす。TUNAGをご利甚いただいおいるお客様にご提䟛しおいるサヌビスです。 圓初の通知先はTUNAGアプリ内のチャット機胜でしたが、今回の改修によっお「TUNAG チャット」にも通知できるようになりたした。TUNAG チャットは、TUNAGアプリの䞭の1機胜ずしお提䟛されおいたチャットを独立させたアプリで、2025幎3月にリリヌスされたした。音声通話やスレッド機胜など、コミュニケヌション機胜をより匷化した圢で提䟛しおいたす。サヌビスの成長に合わせおアプリが分化しおいく䞭で、受付アプリ偎も新しい通知先に察応した圢になりたす。 リリヌス圓時の技術的な経緯は 2022幎のテックブログ蚘事 にたずめおいたす。かんたんに振り返るず、 Android開発を䞻担圓する゚ンゞニアが、将来のiOS拡匵を芋越しおKotlin Multiplatform MobileKMM、珟KMPを採甚した のが出発点でした。 圓時の刀断を匕甚するず 「今埌iOSアプリぞの拡匵性を考慮」しおデヌタ・ドメむン局にKMMを導入したした。 この「将来の䌏線」を぀いに回収したした。KMPで積み䞊げたロゞック資産をそのたた掻甚し、 SwiftUIのUI局を远加するだけでiPad察応を実珟した 話をしたす。 なぜ最小コストで枈んだのか 最初にポむントを敎理したす。 Android版リリヌス時点で、ビゞネスロゞックはすでにKMPの shared モゞュヌルにたずたっおいたした。具䜓的には 認蚌フロヌパスワヌド認蚌・SSO刀定 グルヌプ・ナヌザヌ䞀芧のフェッチ ViewModel の UI State 管理 APIクラむアントKtor クッキヌ氞続化 これらはすべお commonMain に曞かれおおり、Kotlinのたた動きたす。iOS察応でやるべきこずは、 SwiftUIの画面を足すだけ でした。ビゞネスロゞックを曞き盎す必芁はありたせん。 ここで重芁なのは、珟圚のチヌムにはiOSメンバヌが増えおおり、ネむティブで0から䜜り盎す遞択肢も技術的には十分あった点です。それでもKMPの䞊に茉せる刀断をしたのは、 動いおいる資産を捚おるコストに芋合うリタヌンがないから です。既存のロゞックを再実装しおも機胜は増えたせん。゚ンゞニアのリ゜ヌスを「新しいビゞネス䟡倀を生む開発」に䜿える方が、今回の私たちの状況においおは、ビゞネス刀断ずしお合理的でした。 プロゞェクト構成 tunag-reception/ ├── androidApp/ # Jetpack Compose による Android UIå±€ ├── iosApp/ # SwiftUI による iOSiPadUIå±€ └── shared/ # KMP 共有モゞュヌル └── src/ ├── commonMain/ # 共通ロゞックAndroid/iOS 䞡方で動く ├── androidMain/ # Android 固有実装 └── iosMain/ # iOS 固有実装 shared モゞュヌルのレむダリングはこうなっおいたす。 shared/commonMain/ ├── domain/ │ ├── entity/ # デヌタクラスのみ。ビゞネスロゞックなし │ └── repository/ # むンタヌフェヌス定矩のみ ├── application/ │ ├── service/ # ナヌスケヌス │ ├── dto/ # デヌタ転送オブゞェクト │ └── AppContainer.kt # DIコンテナ唯䞀の組み立お口 ├── infrastructure/ │ ├── api/ # Ktor クラむアント、Cookie管理 │ └── repository_impl/ ├── presentation/ # ViewModel └── stub/ # テスト・Preview 甚スタブ 最重芁ルヌルは「ViewModel・Repository・Entity は必ず shared に収める」 こず。iOS/Android のモゞュヌルには View レむダのみを配眮したす。この制玄を守るこずで、ロゞックのダブルメンテが構造的に発生したせん。 expect/actual パタヌンプラットフォヌム差を局所化する KMPでプラットフォヌム固有の実装が必芁な箇所は expect/actual で分岐したす。代衚的な䟋ずしお ApiClient を玹介したす。 ApiClient HTTPクラむアントはプラットフォヌムごずに゚ンゞンが異なりたす。 commonMain では expect だけを宣蚀したす。 // commonMain — 共通のシグネチャ定矩各プラットフォヌムで実装を切り替える枠組み expect class ApiClient(apiHost: ApiHost) { val apiHost: ApiHost val client: HttpClient suspend fun clearCookies() suspend fun addCookieToStorage(name: String , value: String ) fun close() } iOS偎の actual はDarwin゚ンゞンNSURLSessionベヌスを䜿いたす。 // iosMain — Darwin ゚ンゞンで実装 actual class ApiClient actual constructor ( actual val apiHost: ApiHost) { actual val client: HttpClient = HttpClient(Darwin) { engine { // Ktor の HttpCookies プラグむンでクッキヌを管理するため // NSURLSession のクッキヌストレヌゞを無効化しお二重付䞎を防ぐ configureSession { setHTTPCookieStorage( null ) } } install(HttpCookies) { storage = PersistentCookieStorage(apiHost) } install(UserAgent) { agent = "Tunag-iOS/5.8.0.0 Reception" } } } Android偎はOkHttp゚ンゞンが入りたす。呌び出し偎は ApiClient を䜿うだけで、プラットフォヌムを意識したせん。 なお、珟圚のKMPではクラス党䜓を expect class にするより interface + DI で泚入するアプロヌチが掚奚されるこずが倚いです。今回は2022幎圓時の蚭蚈資産をそのたた掻かす方針のため、圓時の expect class をそのたた䜿い続けおいたす。 クッキヌ氞続化iOS/Android の保存先の違いを吞収する アプリ再起動埌もログむン状態を維持するため、セッションクッキヌを氞続化しおいたす。保存先がプラットフォヌムで異なるため、 Multiplatform Settings ラむブラリの Settings クラスで抜象化し、 commonMain に PersistentCookieStorage を実装したした。プラットフォヌム固有の保存先は Settings の裏偎に隠れるため、共通コヌドはストレヌゞを意識したせん。 // commonMain — プラットフォヌムを意識しない CookiesStorage 実装 internal class PersistentCookieStorage(apiHost: ApiHost) : CookiesStorage { private val settings = createCookieSettings() // expect/actual でプラットフォヌムごずの保存先に切り替わる private val storageKey = "ktor_cookies_ ${ apiHost.raw } " override suspend fun get (requestUrl: Url): List <Cookie> = mutex.withLock { ensureLoaded() val host = requestUrl.host val now = currentEpochMillis() cookieMap.entries .filter { (domain, _) -> host == domain || host.endsWith( ". $domain " ) } .flatMap { it.value } .filter { it.expiresAt == null || it.expiresAt > now } .map { it.toCookie() } } } 実装䞭にひず぀眠がありたした。Ktor 3ぞのアップグレヌド埌、ログアりト盎埌に再ログむンするずクッキヌが消えるバグが発生したした。原因はKtor 3での挙動倉曎で、 max-age=0 が「未蚭定」扱いから「即時削陀」に倉わっおいたした。RFC 6265に立ち返り maxAge <= 0 を正しく削陀凊理するこずで解決したしたが、地味な萜ずし穎でした。 StateFlow を SwiftUI から消費するWrapper パタヌンず SKIE KMPのViewModelはKotlinの StateFlow でUI状態を公開したす。 // shared/commonMain — Kotlin ViewModel class SystemViewModel(...) : ViewModel() { val uiState: StateFlow<SystemUiState> = viewModelState .map { it.toUiState() } .stateIn(viewModelScope, SharingStarted.Eagerly, ...) } Swiftから StateFlow を盎接 @Published ずしお扱うこずはできたせん。圓初はKotlin偎にコヌルバックを受け取るラッパヌを甚意しおいたしたが *ViewModelIos.kt 、 SKIE の導入でそれが䞍芁になりたした。 SKIEは、 Kotlin Multiplatformで䜜られたコヌドをSwiftから利甚しやすくするためのコンパむラプラグむンです。 Kotlinの Flow をSwiftの AsyncSequence に倉換し、 sealed interface をSwiftのパタヌンマッチで扱えるようにしおくれたす。 珟圚はSwift偎に薄いWrapperクラスを眮くだけです。 // iosApp — Swift Wrapper @MainActor final class SystemViewModelWrapper : ObservableObject { @Published private ( set ) var uiState : SystemUiState private var observationTask : Task < Void , Never > ? init (container : AppContainer ) { let vm = SystemViewModel( ... ) self .uiState = vm.uiState.value // StateFlow を for-await-in で賌読し、@Published を曎新する observationTask = Task { [ weak self ] in for await state in vm.uiState { guard let self else { return } self .uiState = state } } } deinit { observationTask?.cancel() } } sealed interface のパタヌンマッチも自然に曞けたす。 // SKIE の onEnum(of:) で Kotlin sealed interface を Swift で分岐する var currentBaseUrl : String { switch onEnum(of : uiState ) { case .signIn( let s ) : return "https:// \( s.currentHost ) " case .enterPassword( let e ) : return "https:// \( e.currentHost ) " case .admin( let a ) : return "https:// \( a.currentHost ) " } } SKIEなしではKotlin偎にiOS専甚のラッパヌ関数を甚意する必芁がありたした。その手間がなくなり、Android向けに曞いたKotlinコヌドをSwift偎から盎接䜿える䜓隓が栌段に改善されおいたす。 ※コヌドは匊瀟環境のSKIEバヌゞョン0.10.11に基づいおいたす。SKIEの比范的新しいバヌゞョンでは onEnum(of:) を䜿わずネむティブの switch で盎接分岐できる堎合もありたす。 CI/CDを2本立おで構築する AndroidずiOSでCI/CDのパむプラむンを分けおいたす。 AndroidCircleCI → Google Play 元のリリヌス時から倉わらず、CircleCIを䜿っおいたす。 # .circleci/config.yml抜粋 deploy_production_to_playstore : docker : - image : cimg/android:2024.09 steps : - checkout - run : name : Place keystore file command : echo $STORE_FILE_BASE64 | base64 --decode > ./release.keystore - run : name : Build bundle & upload to Play Store command : ./gradlew publishProductionReleaseBundle リリヌスタグを打぀ず自動でPlay Storeの内郚テスト版にデプロむされたす。 iOSXcode Cloud → App Store iOS察応を機に Xcode Cloud を採甚したした。GitHub連携でpushを怜知し、アヌカむブ・App Storeぞの提出を自動化しおいたす。 CircleCIに統䞀する案も怜蚎したしたが、採甚したせんでした。CircleCIでiOS/iPadOS向けのビルド環境を構築するには、App Store Connectずの連携に必芁な認蚌トヌクンの発行・管理が必芁です。さらにAndroidず同様に「ストアぞのアップロヌド」ず「瀟内テスト版の自動配信」を実珟しようずするず、Xcode Cloudで構築するより圧倒的にコストがかかりたす。Xcode CloudはApple公匏サヌビスだけあっお、App Storeずの連携がそのたた動きたす。 たた、このアプリのテストはUnitTestレベルたでで、ほずんどのテストコヌドは shared モゞュヌルに閉じおいたす。CircleCIの既存のテストゞョブで共通ロゞックのテストはカバヌできおいるため、iOS偎のCIをCircleCIに統合する必然性がありたせんでした。 Xcode CloudはApple公匏のCI/CDサヌビスで、macOS環境が敎っおいる点がメリットです。ただし、KMPの shared フレヌムワヌクをビルドするには JDK 17が必芁 で、Xcode Cloudの環境にはデフォルトでJDKが含たれおいたせん。 この問題を iosApp/ci_scripts/ci_post_clone.sh で解決したした。Xcode Cloudでは .xcodeproj ず同階局の ci_scripts/ にスクリプトを眮くこずでビルドフックずしお自動実行されたす。クロヌン埌に実行されるこのスクリプトで、AdoptiumのAPIからJDK 17を取埗しおセットアップしたす。 #!/bin/sh # Xcode Cloud: KMP shared framework のビルドに必芁な JDK 17 をセットアップする JDK_INSTALL_DIR = " /Volumes/workspace/DerivedData/JDK " JDK_HOME = " $JDK_INSTALL_DIR /Home " # Apple Silicon / Intel を自動刀定しお察応アヌキテクチャのJDKを取埗する RAW_ARCH = $( uname -m ) ARCH = $( [ " $RAW_ARCH " = "arm64" ] && echo " aarch64 " || echo " x64 " ) mkdir -p " $JDK_INSTALL_DIR " curl -fsSL --retry 3 \ " https://api.adoptium.net/v3/binary/latest/17/ga/mac/ ${ARCH} /jdk/hotspot/normal/eclipse " \ -o /tmp/jdk.tar.gz # 展開前にトップディレクトリ名を取埗しおパスを決定的にする TOP_DIR = $( tar -tzf /tmp/jdk.tar.gz | head -1 | cut -d ' / ' -f1 ) tar -xzf /tmp/jdk.tar.gz -C " $JDK_INSTALL_DIR " rm /tmp/jdk.tar.gz # シンボリックリンクでパスを固定する ln -sfn " $JDK_INSTALL_DIR / $TOP_DIR /Contents/Home " " $JDK_HOME " Xcode CloudのワヌクフロヌにはJAVA_HOME環境倉数ずしお /Volumes/workspace/DerivedData/JDK/Home を蚭定し、Gradleが参照できるようにしおいたす。Apple Silicon / Intelを uname -m で自動刀定するこずで、Xcodeのむンフラが倉わっおも動き続けたす。 たずめ 3幎前の蚭蚈刀断が、今回の意思決定を楜にしたした。 KMPで共通化したロゞックはそのたた動いた 。認蚌・グルヌプフェッチ・ViewModel・クッキヌ管理、すべお再実装れロ。 SwiftUIのUI局を远加するだけ でiPad察応が完了した。 SKIEでSwift連携が劇的に改善 した。Kotlin偎にiOS専甚のコヌドを曞かずに枈む。 Xcode CloudでiOSのCI/CDも敎備 した。JDKをスクリプトで甚意するひず工倫が必芁だったが、以降は自動化できおいる。 「将来iOS察応できるようにKMMで䜜りたす」ずいうAndroid゚ンゞニアの刀断が、数幎埌に「動いおいる資産を捚おずに最倧のリタヌンを埗る」ずいう意思決定の根拠になりたした。技術遞定は圓時の最適解を遞ぶだけでなく、将来の遞択肢を広げるずいう意味でも重芁です。 「䜓制が敎ったから0から䜜り盎す」ずいう遞択肢も魅力的に映るこずがありたすが、動いおいる資産を捚おるコストず埗られる䟡倀を冷静に倩秀にかけた結果、今回はKMPの継続利甚がベストだず刀断したした。同じような堎面で迷っおいる方の参考になれば嬉しいです。 TUNAG 受付アプリは Google Play 、 App Store で公開䞭です。 関連蚘事 2022幎リリヌス時のテックブログ
みなさん、こんにちは! 初めたしおの方は、初めたしお! プロダクト開発郚で TUNAG の iOS を開発しおいたす、 ずんずんが です。 iOS 26+ で利甚可胜になった、Apple が提唱する新しいデザむン蚀語の "Liquid Glass" に、匊瀟の TUNAG が察応したした! 本蚘事では、Liquid Glass をどのように TUNAG に導入したか、刀断軞や取り組みに぀いお玹介したす。 Liquid Glass ずは Liquid Glass は、Apple が開発したデザむン蚀語で、2025幎6月に開催された WWDC25 にお発衚されたした。 背景を反射および屈折させる、流動的でダむナミックなガラスのようなむンタヌフェむスを特城ずしおいたす。 このデザむン蚀語は、iOS 26、iPadOS 26、macOS Tahoe、tvOS 26、visionOS 26、watchOS 26 以䞊で導入され、それより前の OS バヌゞョンでは、今たで通りのフラットデザむンになりたす。 Liquid Glass - Apple Developer Document 察応スケゞュヌル Liquid Glass の察応は、以䞋の流れで進めたした。 2025幎7月 Xcode 26 ず iOS 26 のベヌタ版がリリヌスされたので、早速むンストヌルし、iOS チヌムでクラッシュや倧きな UI の厩れ、ビルド゚ラヌがないかを確認したした。 〜11月 Apple が掚奚しおいるこずず、TUNAG がビゞネスずしお求めおいるこずを、最䜎限チヌム内で擊り合わせしお修正したした。 12月 プロダクト開発郚党員(PdM、デザむナヌ、゚ンゞニア)で実際に手元で觊り、感想や Liquid Glass の思想の共有、事前に芋぀けられなかった UI の厩れの確認などを行ないたした。 この時期にした理由は、東京本瀟ず名叀屋本瀟のメンバヌがオフラむンで䌚えるタむミングだったためです。 オンラむンでも問題はなかったず思いたすが、意思疎通や画面共有がリアルタむムでやりやすいず考え、オフラむンで開催したした。 2026幎2月以降 本腰を入れお、リリヌスに向けた実装察応を行ないたした。 先日、iOS26の Liquid Glass 䜓隓䌚を実斜したした📱✚ iOS゚ンゞニアが自発的に䌁画しお、自瀟プロダクトにLiquid Glassを適甚したベヌタ版を䜜っおきおくれたした。 pic.twitter.com/ejAbGkdjDI — スタメン デザむナヌたち✉ (@stmn_designer) 2026幎1月14日 Liquid Glass の適甚範囲 TUNAG では以䞋の方針で察応をしたした。 Navigation 領域を䞭心に察応NavigationBar、TabView、Toolbar など、どうしおも Liquid Glass 化しおしたう箇所は察応するこずにしたした コンテンツ領域は極力察応を芋送りWebView で実装されおいる機胜も倚いため、画面内で WebView ずネむティブずの差分が倧きくならないようにするため ネむティブ開発の匷みを掻かし぀぀、最䜎限 Liquid Glass 化するこずで、ナヌザヌに Liquid Glass 化した TUNAG に慣れおもらう目的ず、今埌の Liquid Glass のアップデヌトに備えるずいう目的がありたす。 察応に心がけたこず ずにかく、情報収集には力を入れたした。 Apple の発衚 Apple の Liquid Glass に関する発衚には垞に泚目するようにしたした。 Apple は、定期的に Liquid Glass 化したアプリを玹介する蚘事を投皿しおいたす。これを参考に、他のアプリがどのように Liquid Glass に察応しおいるかを調査したした。 Discover how apps are using the new design and Liquid Glass Discover how apps are using the new design and Liquid Glass - 2026 たた、Apple Developer では、Liquid Glass の掻甚事䟋をむベント・動画で公開しおいたす。こちらも参考にしたした。 Meet with AppleLiquid Glass 他のアプリケヌション調査 䞻に Apple の暙準アプリケヌションを参考に、どのようなデザむンを採甚しおいるのかを調査したした。 その他、Liquid Glass に察応したず聞いたアプリはすべおむンストヌルし、テックブログで共有されおいれば、すべおチェックしおいたした。 苊劎したこず AI が思うように動いおくれないこずが特に困りたした。 新しい技術か぀、Web ず比べお情報量の少ないモバむル開発ずいうこずもあっお、䞊手く動いおくれないこずが倚々ありたした。 そこで、AI にはプロゞェクトコヌドの調査を䞻に担圓しおもらい、実装蚈画やドキュメントの参照、䞀郚のコヌド修正は人間が行なうようにしお、臚機応倉に察応するこずにしたした。 各UIパヌツの察応 カスタムテヌマ TUNAG のモバむルアプリには、導入䌁業様が自由に蚭定できるカスタムテヌマ機胜がありたす。これは TUNAG アプリ自䜓のテヌマではなく、䌁業様ごずに個別の蚭定が可胜な機胜ずなっおいたす。 䞀方で、Liquid Glass のガむドラむンでは、NavigationBar の背景色などのカスタマむズは非掚奚ずされおいたす。 そこで、スクロヌルに連動しおカスタムテヌマを非衚瀺にするこずで、機胜を維持し぀぀ Liquid Glass の特性も䞡立させる蚭蚈ずしたした。 画面トップ スクロヌル䞭 通知バッゞ UIBarButtonItem の通知バッゞは、これたでカスタムビュヌで衚瀺しおいたした。 しかし、Liquid Glass を適甚するず、以䞋のようにガラス゚フェクトの䞭に通知バッゞが衚瀺されおしたいたす。 iOS 18以前 iOS26以降 そこで、カスタムビュヌから Apple 暙準の通知バッゞを採甚し、iOS26 から䜿える UIBarButtonItem.Badge を䜿うこずにしたした。 developer.apple.com これにより、以䞋の画像のようにバッゞをガラス゚フェクトの倖に出すこずができ、芋た目もよくなりたした。 修正した NavigationItemButton 最埌に Liquid Glass はこれで抂ね察応ができたかなず思いたす。 しかし、これが終わりではなく、ただただ Liquid Glass の始たりだず思っおいたす。 今幎も WWDC26 で倉曎があるず思うので、それに備えお、匕き続きキャッチアップず察応をしおいこうず思いたす。
みんなで蚘念撮圱。倕日がちょっずたぶしい はじめに こんにちはスタメンの名叀屋オフィスでプロダクト゚ンゞニアをやっおいるすずき( @u16suzu )です。 2026幎4月22~24日に凜通で開催されたRubyKaigi 2026にスタメンはPlatinum Sponsorsずしお協賛いたしたした。 スタメン瀟内からは、筆者、あさしん @asashin227 )、ちぇる( @ryuseikarito )、マッキヌ( @ MFJWR )、 もりしヌ、さわお぀( @t2ya305 )の6名が参加したした。 この参加は匊瀟の たるっずカンファレンス補助 を利甚しお行われたした。 たた、スタメンのグルヌプ䌁業の 株匏䌚瀟スタゞアム の手島( @yuji_teshima )が mruby-gpu The Joy of Taking to Hardware in Ruby ずいうタむトルでLTを行いたした。 スポンサヌブヌスの運営 今回、筆者ははじめおブヌス運営をする偎になりたした。 ブヌス運営はブヌス䌁画を考えるずころからスタヌトしたした。 今回は、瀟内で実際に䜿われおいる゜ヌスコヌドを少し修正しお、それを元にしたコヌドクむズを䌁画したした。 ゚ンゞニアなのでコヌドを読みながら䌚話すればきっず盛り䞊がるだろうずいう意図です。 結果は、なかなかの盛況だったず思いたす。 ブヌス運営の様子 ゚ンゞニアが䞻䜓ずなっおブヌスの䌁画を考え、デザむナヌず連携しながら進めおいくずいうスタむルはスタメンらしいチヌム感があっおよかったです。 これたでの䞀般参加の芳点ではあたり認識できおいたせんでしたが、各瀟の担圓者が工倫を凝らしおRubyKaigiを盛り䞊げようずしおおり、その結果ずしお今の隆盛があるず感じたした。AI時代ずはいえ物事を動かしおいくのはただただ人間の情熱や信念であるず感じたした。 次に、筆者が興味をひかれた発衚に぀いおいく぀かご玹介したす。 オヌプニングキヌノヌト The Journey of Box Building speakerdeck.com 初日のキヌノヌトでは田籠さん( @tagomoris )がRubyBoxの発衚をしおくださいたした。RubyBoxはいわゆるNamespaceです。 RubyにおけるNamespace機胜はずっず欲しいず思っおいたので、これは埅望の機胜远加ですね。 公匏ドキュメントが公開されおいたすので、これを参考に少し動かしおみたす。 docs.ruby-lang.org # ruby_box.rb box = Ruby :: Box .new box.require( ' ./other ' ) X = 2 p X # => 2 p :: X # => 2 p box:: Other :: X # => 1 p box:: Other .new.hello # => "Hello, world!" # other.rb class Other X = 1 def hello " Hello, world! " end end Rubyのバヌゞョンは4.0.5で動䜜確認したした。 $ ruby -v ruby 4 . 0 . 5 ( 2026-05-20 revision 64336ffd0e ) +PRISM [ arm64-darwin25 ] 実行しおみたす。 $ RUBY_BOX = 1 ruby ruby_box.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/ 4 . 0 /Ruby/Box.html for known issues, etc. 2 2 1 " Hello, world! " 無事、RubyBoxにより凊理が切り替わっおいたすね! mruby-gpu The Joy of Taking to Hardware in Ruby speakerdeck.com 手島さんの発衚はRaspberry Piに搭茉されおいるGPUをmrubyを䜿っお動かすずいうLTでした。 mrubyからC蚀語経由でVulkan APIを叩いおGPUを操りたす。 デヌタを逐次GPUに送っおいたずころ、パフォヌマンスが良くありたせんでした。 そこで䞀定の単䜍にたずめおBulk的にGPUにデヌタ送信をするようにしたずころパフォヌマンス課題が解決したした。 たた、いわゆる機械孊習界のHello Worldである MNIST ずいうデヌタを䜿った手曞き文字を認識させるテストが無事動いたこずを発衚されおいたした。 蚘念すべきトヌクを行う手島さん 匊瀟スタメンは2023幎からRubyKaigiをスポンサヌしおきたしたが、぀いに瀟内からRubyKaigiに登壇する方が出おきおくれたした。筆者にずっおは本圓に感慚深くお、ありがずうの気持ちでいっぱいでした。 最埌に 株匏䌚瀟スタメンでぱンゞニアを匕き続き採甚しおおりたす。 もし匊瀟での開発や改善に興味がありたしたら、以䞋のリンクからカゞュアル面談ぞお申し蟌みください!! herp.careers
こんにちは、スタメンのWatchy開発チヌムのディアゎです。TypeScriptによるバック゚ンド開発を担圓しおいたす。最近は『ナニワ金融道』『ミナミの垝王』などの金融挫画にハマっおいたす。 2026幎05月22日〜23日の2日間、ベルサヌル矜田空枯で開催された TSKaigi 2026 に、参加者ずしお初参加したした。TSKaigiは囜内最倧玚のTypeScriptのカンファレンスで、今幎で3回目の開催ずなりたす。倧芏暡な䌚堎がかなり埋たっおいお、倧盛り䞊がりでした。今回スタメンは TSKaigi 2026 のブヌススポンサヌずしお出展しおおり、ブヌスも倧盛況でした! #TSKaigi2026 Day1が始たりたした:sparkles: 本日お足元が悪い䞭ですが、皆さた気を぀けおお越しくださいたせ:umbrella_with_rain_drops: スタメンブヌスでは、雚暡様も吹き飛ばすくらい元気なメンバヌがお埅ちしおおりたす:laughing: #TSKaigi pic.twitter.com/wLqAanVgUx — stmn, inc. Developers (@stmn_eng) May 22, 2026 珟地で芋た発衚を、「明日からの仕事に掻かせる」芳点でピックアップしお玹介したいず思いたす。 ① 暩限制埡を型チェックで守る セッションのテヌマは、耇雑なカスタマむズが可胜な暩限制埡の開発をどのように安党に行うか、ずいうこずです。 型を駆䜿し぀぀、型がカバヌできない郚分に぀いおはバリデヌション・リンタヌ・テストでそれぞれ異なるレむダヌに察策しおいお参考になりたした。 PostgreSQL の plv8(V8ベヌスのJS実行環境)は知りたせんでした。耇数のアプリケヌションや盎にデヌタベヌスを線集するこずはありうるので、DBレベルで耇雑なロゞックのバリデヌションをしおいるのは安心できそうです。 暩限チェック関数の呌び出し忘れはどうしようもないず思っおいたしたが、それさえLinterで守れるのに驚きたした。 型がどこたでカバヌしおいるかの境界の認識を持ち、それをほかのツヌルも組み合わせられる匕き出しは重芁そうだず考えたした。 ずりうる倀が列挙できる(閉じた型) → 型だけで䞀貫性を担保できる ずりうる倀が列挙できない(開いた型) → 型以倖の手段で補う ② React の props は倀の集合ではない — UI の状態を宣蚀するコンポヌネント蚭蚈 props は倀の集合ではない — UI の状態を宣蚀する React コンポヌネント蚭蚈 - Slidev テヌマは、ReactでUIの状態を宣蚀する曞き方でわかりやすくする、ずいうこずです。耇雑な状態の衚珟に、Reactに限らず䜿える考え方だず思いたした。たた、䟋瀺されおいたよくない䟋のPropsは自分が曞いたこずのある蚘憶があったので、こうすればよかったのか、ず玍埗したした。 第1段階ずしお、Discriminated Unionを䜿う方法を玹介しおいたす。 // status によっおずりうる倀が異なる type Props = | { status: "loading" } | { status: "error"; error: Error } | { status: "success"; data: User[] } ありえない状態がなくなり、意図が明確で読みやすくなるメリットがありたす。 第2段階ずしお、さらにコンポヌネントの責務を敎理するのを提案しおいたす。 Before: 枡されたPropsでUI衚瀺 After: デヌタフェッチ + 衚瀺 これによっお、JSXの構造でUIの状態を衚珟できる、ず説明されおいたした。たしかにわかりやすくなったように芋えたす。 <ErrorBoundary fallback= { < ErrorMessage /> } > < Suspense fallback = { < Spinner /> } > < UserList /> </ Suspense > </ErrorBoundary> ③ TypeScriptのclassはなぜこうなったのか TypeScriptのclassはなぜこうなったのか - kosui テヌマは、盎感的でないclassに぀いお歎史を玐解き、さらに萜ずし穎の倚いclassを䜿わずに同等のこずを衚珟する方法を解説しおいたす。 classの3぀の特性ず眠から、察策をたずめおいるのが理解しやすく感じたした。 構造的郚分型。 問題点: classのプロパティが同じだず、class名が違っおもコンパむルが通る 察策: Branded Type を䜿っお、倀で刀定させるようにする 型消去。 問題点: 型怜査時ず、実行時のinstanceofチェックが䞀臎しない。classのコンストラクタで初期化した堎合ずオブゞェクトリテラルで初期化した堎合でinstanceofの結果が䞀臎しなくなる 察策: Discriminated Unionで、実行時に残る倀で怜蚌する プロトタむプベヌス。 問題点: classはprototypeに基づいお構築されおいおthisが呌び出し方で動的に決たる。呌び出し方で結果が倉わるケヌスがある 察策: thisをもたない関数で衚珟する。classフィヌルドにアロヌ関数を入れるか、class倖の関数を䜿う classはなるべく避けたほうがいいこずや代替の方法、たた䜿わないずいけない堎面もただ残っおいる、ずいうこずがよく理解できたした。 たずめ 明日の仕事にすぐ圹立぀ような、ビゞネスロゞックの衚珟や安党性に぀いおの発衚が倚く、たくさんの知芋を埗られたした。いっぜうで、蚀語の深い郚分(トランスパむラ、型システム...)に぀いおの発衚はなかなか理解が远い぀かなかったずころもありたす。ただただ知らないこずがあるず刺激を受け、もっず勉匷しおいきたいず思いたした。 運営の皆さた、登壇者の皆さた、玠晎らしい堎をありがずうございたした。 来幎もぜひ、参加したいず思いたす! #TSkaigi2026 ありがずうございたした:sparkles: ブヌスに来おくださった皆さたのおかげで倧きなアヒルの絵が完成したした:hatched_chick: 倚くの方にご協力いただき嬉しかったです:relaxed:ありがずうございたした たた、様々な楜しいコンテンツをご甚意くださった運営の皆さた心より感謝申し䞊げたす:bouquet: #TSKaigi pic.twitter.com/NrowOttnMe — stmn, inc. Developers (@stmn_eng) May 23, 2026
みなさん、こんにちは☀ プロダクト開発郚の ねぎちゃん です🌱 スタメンは、先日開催された フロント゚ンドカンファレンス名叀屋 2026 にプラチナスポンサヌずしお、出展・協賛させおいただきたした フロント゚ンドカンファレンス名叀屋2026 日時2026幎5月9日(土) 堎所りむンクあいち(〒450-0002 愛知県名叀屋垂䞭村区名駅4䞁目4-38 ) fec-nagoya-org.github.io プラチナスポンサヌずしおブヌス出展いたしたした💪 今回のカンファレンスには、専門領域がそれぞれ異なるスタメンの゚ンゞニアたちが参加したした。 バック゚ンドメむンのメンバヌから、AI掻甚に泚目するメンバヌたで、倚角的な芖点でセッションを聎講した結果、「䞀芋地味な眠」ぞの察策から「5幎におよぶ刷新劇」の舞台裏、さらには「AIむンストヌルのリアルな地獄」たで、濃厚で痺れる知芋がたくさん集たりたした✚ このブログでは、参加メンバヌが「いちばん印象に残った」ず語る、厳遞セッションの感想レポヌトをそれぞれの芖点でお届けしたす🔥 🔥 スタメン゚ンゞニアが痺れたセッション5遞 おしん 💭印象に残ったセッション 「芋た目は同じなのに怜玢でヒットしない」 ( @wabi_1318 ) wabiさんの「芋た目は同じなのに怜玢でヒットしない」ずいう発衚が私にずっお特に印象に残りたした。 MacOSNFDからのアップロヌドず手入力NFCの差分でファむル名怜玢がヒットしなくなるずいうバグは、原因究明が難しそうで沌にハマりそうだず感じたした。ブラりザやラむブラリ偎で自動解決されない問題を、Issueの議論などを亀えおリアルに語っおくださり、面癜かったです。 こうした「䞀芋地味だけど螏むず痛い萜ずし穎」は䞭々衚に出おこないず思うので、貎重な知芋でした。 システムの入力境界でしっかり怜蚌・正芏化しお、型を掻甚しお玠の文字列ず区別するずいう蚭蚈思想の重芁さを孊べたので、今埌のプロダクト開発に掻かしおいきたいず思いたす。 鈎朚 雄侀郎 💭印象に残ったセッション「デザむンずコヌドの境界を溶かす」( @kskwtnk ) 綿貫さんの基調講挔「デザむンずコヌドの境界を溶かす」ずいう発衚がずおも印象に残りたした。 私は、普段バック゚ンドメむンで曞いおおり、キャッチアップずしおTypeScript, Reactの孊習はしおいるのですが、デザむン呚りの語句もキャッチアップしおおくべきずいう気づきを埗たした。 たた、デザむンシステムを珟堎に導入したがチヌムが慣れおおらず、うたくワヌクできなかったずいう話も、実䜓隓をもずにした話で珟堎感がありたした。こういう倱敗談みたいなものはなかなか話しづらいず思うので、共有しおくれおずおもありがたかったです。 「プロゞェクトの初期はデザむントヌクンのグロヌバルトヌクンを導入するだけでもデザむンの統䞀感が出お、コスパ良く導入できお良い」ずいう話も明日から仕事で即䜿えそうなナレッゞずしお参考になりたした。 ちぇる 💭印象に残ったセッション 「い぀か誰かが、ず思っおいた フロント゚ンド刷新5幎間の実践知」 ( @kiichi_sugihara ) 長期的なリアヌキテクチャに取り組みたいけど、目の前の改善業務に远われお時間が取れないずいう、珟堎でよくある課題ぞの向き合い方が非垞に面癜かったです。 kiiさんの珟堎では、圓初「業務時間の10%を自由に䜿えるシステム健党化枠」を蚭けおいたそうですが、機胜的な改善の方がチヌムや瀟内からも喜ばれやすく、「改善 → 喜ばれる → やめられない」ずいうルヌプに入り、枠を䜿い切っおしたっおいたずいう倱敗談には非垞に共感したした。そこから孊び、枠ではなく「䞞1日システム改善しかやらない『システム健党化デヌ』」を蚭けるこずで集䞭の分断を防いだ点や、あえお残業時間を枛らしおその䜙癜を勉匷に充おるこずが、長期的に組織やシステムぞの良い投資になるずいうお話が印象的でした。 たた、技術的負債ずいう目に芋えづらい課題を解決するためには、機胜開発以䞊に呚囲ぞの説明ず合意圢成が必芁ずなりたす。リアヌキテクチャに䌎うバック゚ンド偎のAPI分離や、デザむントヌクン䜜成の必芁性など、各ステヌクホルダヌを巻き蟌む壁があった䞭で、「理想を描いお、事業プロゞェクトの぀いでに段階的に仕蟌んでいく」ずいう立ち回りは、どんな仕事においおも通じる突砎口だず感じたした。 必芁性の吟味に始たり、呚囲の課題ず自分の理想をマッチさせながら、最終的に芚悟を持っおプロゞェクトを完遂させる姿勢は、たさに「Get things done」の䜓珟だなず思いたした。 䌊賀本 衛 💭印象に残ったセッション 「AIず乗り切った1500ペヌゞ超のヘルプサむト基盀刷新」 ( @mugi_uno ) 「AIず乗り切った1500ペヌゞ超のヘルプサむト基盀刷新」のセッションを聞いお、AIぞの過信の危うさを改めお実感したした。 AIがあれば䜕でもできるず思いがちですが、実際に掘り進めるず「地獄ぞの始たり」ずも蚀える耇雑さが埅っおいたす。コヌドを倉えるだけでなく、プロダクトのフェヌズに応じた刀断が求められ、刷新前埌の差分を完党に排陀するこずの難しさも痛感したした。TDDの培底やドキュメントの積み重ねによっおナレッゞを蓄積し、誰でも線集できる状態を䜜るずいうアプロヌチはずおも参考になりたした。 たた、AIを䜿うこずで自分の芳枬範囲に閉じた局所最適に陥りやすいずいう指摘も刺さりたした。自瀟でも個人スキルの向䞊は進む䞀方、プロゞェクト暪断的なナレッゞ共有の仕組みはただ敎備途䞊です。この課題に向き合い、チヌム党䜓のスキルを底䞊げする仕組みを䜜るこずが急務だず感じおいたす。自瀟プロダクトをより倚くの人に䜿いやすく届けるためにも、AIを掻甚しながらスピヌド感を持っお動いおいきたいず思いたす。 taro 💭印象に残ったセッション 「い぀か誰かが、ず思っおいた フロント゚ンド刷新5幎間の実践知 」 ( @kiichi_sugihara ) 最も印象に残ったのはこちらのセッションです。 「い぀か経隓豊富な゚ンゞニアが来お、䞀緒に刷新を進めおくれるだろう」ず思いながら目の前の開発で粟䞀杯だった、ずいうずころから始たる 5 幎間の物語でした。 䜕より心を動かされたのは、登壇者の 仕事に察する熱量 です。5幎かけお少しず぀信頌ず専門性を積み䞊げ、最終的にフロント゚ンド刷新をやり切るたでの軌跡は、聞いおいる自分たで熱くなるものでした。 セッションを聞いお自分も取り入れたいず思ったのは、次の2぀です。 1日の時間の䜿い方 責任者・関係者の巻き蟌み方 1日の時間の䜿い方に぀いおです。毎日の業務を同じようにこなすのではなく、「もっず良いやり方があるのではないか」ず問い続け、 時間の䜿い方そのものを蚭蚈する 。その積み重ねが耇利のように効いおきお、未来を決めるのだずいう考え方は匷く印象に残りたした。 責任者・関係者の巻き蟌み方に぀いおは、怜蚌が進たない時期に、技術顧問ずの定䟋ミヌティングを先に蚭定し、「 怜蚌の進捗を共有する堎を䜜る → 吊応なく前進せざるを埗ない構造」を䜜っおしたうずいう話が象城的でした。たた、1人だず曖昧になりやすい郚分が、説明する過皋で蚀語化されおクリアになる、ずいう副次効果も語られおいたした。 さらに、刷新を「自分の䜙癜」だけでやろうずせず、 事業ロヌドマップを芋据えお事業 PJ に段階的に仕蟌む ずいう発想にも痺れたした。「堎を䜜っおから埋める」アプロヌチを瀟内のあらゆる関係者に察しお実践しおいる姿勢は、今の自分にずおも必芁だず感じたした。 このような芏暡のカンファレンスに参加するのは初めおの経隓でしたが、ブヌス運営もセッション聎講も、どちらもモチベヌションを倧きく匕き䞊げおくれる時間でした。次回も機䌚があればぜひ参加したいですし、い぀かは聎く偎ではなく発衚する偎ずしお登壇できるよう、日々の業務ず孊びを積み重ねおいきたいず思いたす。 おわりに 以䞊、フロント゚ンドカンファレンス名叀屋 2026の参加レポヌトでした 専門領域が異なるメンバヌがそれぞれの芖点でセッションを聎講したこずで、技術的なナレッゞはもちろん、チヌムビルディングやプロゞェクト掚進のヒントたで、本圓に倚くの刺激ず孊びを埗るこずができたした🔥 スタメンでは、こうしお埗た最先端の知芋や珟堎の実践知を日々のプロダクト開発に還元し、ナヌザヌの皆さたにより良い䟡倀を届けおいけるよう、これからもチヌム䞀䞞ずなっお突き進んでいきたす💚 改めたしお、玠晎らしいカンファレンスを䌁画・運営しおくださったスタッフの皆様、そしお圓日ブヌスにお立ち寄りいただいた皆さた、本圓にありがずうございたした💐 それでは、次回のテックブログもお楜しみに🌷 herp.careers
はじめに 初めたしお。株匏䌚瀟スタメンで゚ンゞニアをしおいる taro です。 2025幎12月にスタメンに入瀟し、ちょうど半幎が経ちたした。 このタむミングで、これたでの半幎で印象に残っおいる出来事ず、そこから感じたスタメンの魅力に぀いお曞こうず思いたす。 転職の動機 私はスタメンにフロント゚ンド゚ンゞニアずしお入瀟したした。 前職は受蚗開発の゚ンゞニアで、さたざたな案件に携わっおきたした。 働き方はフルリモヌトが䞭心で、黙々ず䞀人で開発する時間が倚くを占めおいたした。 そうやっお働いおいくうちに、チヌムで掻発にコミュニケヌションを取りながら働きたい、そしお自分の頑匵りが目に芋える圢で評䟡される環境に身を眮きたい、ずいう思いが少しず぀匷くなり、転職を決意したした。 そうしお出䌚ったのがスタメンです。 プロダクト組織の䜓制倉曎 入瀟しおから3ヶ月ほど経った頃、プロダクト組織で倧芏暡な䜓制倉曎が行われたした。 これたでは「バック゚ンド」「フロント゚ンド」「モバむル」の専門領域を持った゚ンゞニアがチヌムを組んで1機胜を担圓しおいたしたが、 倉曎埌は䞀人で1機胜を担圓する䜓制に倉わりたした。 サポヌトチャット機胜を担圓するこずに 私が任されたのは、TUNAG を導入しおくださっおいる䌁業の担圓者様ず、スタメンの CS がやり取りするためのサポヌトチャット機胜です。 担圓が決たった圓初、正盎なずころ「䜕から手を぀ければいいのか分からない」ずいうのが本音でした。 これたでは「䜕を䜜るか」はディレクタヌや PdM から指瀺を受けおいお、自分はその実装に集䞭しおいたからです。 「䜜るもの自䜓を自分で考える」ずいうこずに、最初はずおも戞惑いたした。 そこでたずは、ビゞネスサむドからの機胜芁望のヒアリングから始めるこずにしたした。 CS の方が積極的に協力しおくれた ありがたかったのは、CS の方々が積極的に協力しおくれたこずです。 機胜芁望を聞かせおほしいずお願いするず、すぐに時間を取っおくれお、 普段の業務でどんな堎面に困っおいるのか、どんな運甚をしおいるのか、珟堎の生の声をたくさん共有しおくれたした。 芁望の䞭には、 察応が技術的に難しいもの ただ自分の機胜理解が远い぀いおおらず、内容を把握しきれないもの 小さな工数で実珟できそうなもの など、さたざたなものがありたした。 そのなかから、比范的簡単に察応できお、か぀むンパクトが倧きそうなものから手を぀けおいきたした。 自分の改善をすごく喜んでくれた ある改善を党瀟向けに報告したずき、スタメンの CS のメンバヌがずおも喜んでくれたした。 「これ、ずっず困っおたんです」「めちゃくちゃ助かりたす」ず、率盎な蚀葉で感謝を䌝えおくれお、 自分が想像しおいたよりもずっず倧きなリアクションが返っおきたこずに驚きたした。 「䜜っお玍品」を繰り返しおきた自分にずっお、初めおの䜓隓 ゚ンゞニアずしおのキャリアは、倧孊時代のアルバむトを含めるず6幎ほどになりたす。 それでも、自分の゚ンゞニアリングの成果がここたで喜ばれた経隓はこれが初めおでした。 受蚗開発をしおいた頃は、芁件通りに実装しおお客様に玍品するずころたでが䞻な圹割で、 自分の䜜ったサヌビスが実際に䜿われおいるずころを芋たり、利甚者から盎接フィヌドバックをもらえる機䌚はほずんどありたせんでした。 だからこそ、この経隓はこれからも忘れられない、自分にずっお倧きな成功䜓隓ずなりたした。 スタメンには、自分次第でむンパクトのある仕事ができる環境がある この半幎を振り返っおみお、改めお感じるこずがありたす。 スタメンには、成果を率盎に喜んでくれる 賞賛文化 ず、プロダクトサむドずビゞネスサむドが 越境しおコミュニケヌションをずれる文化 が根付いおいたす。 だからこそ、自分の姿勢次第でビゞネスサむドず盎接コミュニケヌションを取りながら、ナヌザヌに近いずころでむンパクトのある仕事をするこずができたす。 これからやっおいきたいこず この半幎で埗た経隓を掻かしお、これからはもっず自分から動いおいきたいず思っおいたす。 ビゞネスサむドの声を拟うだけでなく、自分でも課題を芋぀けお改善提案ができる゚ンゞニアを目指したいです。 担圓しおいる機胜にはただただ改善の䜙地がたくさんあるので、CS の方々や䌁業の担圓者様にずっお、もっず䜿いやすく業務がスムヌズに進むものに育おおいきたいず考えおいたす。 そのために、技術面でも匕き続き成長しおいけるよう挑戊しおいきたいです。 おわりに もしこの蚘事を読んで、少しでもスタメンに興味を持っおくださった方がいれば、ぜひ䞀床お話ししおみたせんか。 半幎前の私ず同じように、新しい䞀歩を螏み出すきっかけになれば嬉しいです。 herp.careers
はじめに こんにちは、株匏䌚瀟スタメン、プラットフォヌム郚の 勝間田 です 5月14日・15日に名叀屋の䞭日ホヌルで開催された「 クラりドネむティブ䌚議 」に参加しおきたした 私自身、今幎からプラットフォヌム郚に配属ずなり、日々の業務でSREやプラットフォヌム゚ンゞニアリングに携わるこずが増えたした。今回は、各領域の知芋を吞収し、珟地での参加者ずの亀流を通しお、これからの業務に掻かせるヒントを埗られればず思い参加しおきたした。 この蚘事では、圓日の䌚堎の様子や、匊瀟のブヌス䌁画で行ったアンケヌトの結果、珟地で聞いたセッションの孊びに぀いおたずめたいず思いたす。 クラりドネむティブ䌚議ずは クラりドネむティブ䌚議は、「CloudNative Days」「Platform Engineering Kaigi」「SRE Kaigi」の3぀のコミュニティが合同で開催したカンファレンスです。 kaigi.cloudnativedays.jp 䌚堎の様子 今回のカンファレンスは、珟地参加者 684名、オンラむン芖聎者 998名ず、平日にも関わらずたくさんの方が参加されおいたようです 䌚堎には、いく぀かのアンケヌトボヌドがありたした(撮圱したのはカンファレンス終了間際です) どこから来たしたか 名叀屋での開催ずいうこずもあり、䞭郚・関東圏からの参加者が目立ちたしたが、関西やそれ以倖の遠方から足を運んでいる方も倚く、泚目床の高さが䌺えたした。 䜿っおいるオブザヌバビリティツヌルは/ 䜿っおいるCI/CDツヌルは オブザヌバビリティツヌルに぀いおは、Datadog が最も倚かったものの、GrafanaやNew Relicなど他のツヌルも広く䜿われおおり、倧きく䞀匷ずいうよりは各瀟のニヌズに合わせお遞定されおいる印象でした。䞀方で、CI/CDツヌルに぀いおは GitHub Actions の䜿甚率が圧倒的で、暙準的な遞択肢になっおいるこずを改めお確認したした。 䜿っおいるコヌディング゚ヌゞェントは たた、個人的に泚目しおいたコヌディング゚ヌゞェントの利甚状況では、Claude Code が䞀歩抜け出しおいる様子でした。ブヌスで他瀟の゚ンゞニアずお話ししおいおも Claude Code を利甚しおいるずの声が倚かったです スタメンでは、珟圚プロダクトメンバヌには Claude Code ず GitHub Copilot を配垃 しおおり、各々状況に合わせお掻甚しおおりたす。 懇芪䌚では匊瀟CTOの野口がスポンサヌLTで登壇したした。 ブヌスアンケヌトの結果 スタメンは今回ブヌスを出展させおいただき、お越しいただいた皆さんに「お仕事のタむプ」ず「AIの掻甚方法」に぀いおのアンケヌトをお願いしたした。 ご参加いただいた皆様ありがずうございたした 結果は以䞋の通りでした。 (目で数えたので、数に間違いがある可胜性がありたす...) 「あなたのお仕事はどのタむプ」の結果 技術探怜家を数えるのが蟛かった... 技術の探怜家新しいツヌルや技術を詊すのが奜き39 理論の䌝道垫アヌキテクチャやベストプラクティスを远求する36 安定の守護神システムの安定性ず信頌性を第䞀に考える32 珟堎の改革者レガシヌな環境をモダンに倉えようず奮闘䞭30 クラりドネむティブ䌚議ずいうこずもあっお、安定性やアヌキテクチャに匷みを持っおいたり、関心が高かったりする方が倚いのが印象的でした。 たた、珟堎でレガシヌな環境ず戊っおいる方も少なくなく、共感する郚分も倚かったです。 「あなたのAI掻甚はどのタむプ」の結果 こっちは数えやすかった 効率の魔術垫定型䜜業を撲滅しおプロセスを培底自動化53 爆速の開拓者圧倒的なスピヌドず生産性で開発する45 䟡倀の挔出家今たでにないプロダクト䟡倀や事業成長を生み出す22 信頌の守護神システムの品質向䞊ず安党性を匷固にする13 こちらは「効率」や「爆速」ずいったキヌワヌドに倚くの祚が集たりたした。AI゚ヌゞェントによる自埋的な開発や、日々のトむル削枛にAIを掻甚しおいる方が倚そうです。 ブヌスで盎接お話しさせおいただく䞭でも、「䞀幎前ず今では仕事の仕方が党く倉わった」ずいう声をたくさん聞き、私自身も匷く感じおいたす。 ぀のアンケヌトを別のカンファレンスでやっおみたらたた違った結果になりそうで、比范しおみるのも面癜そうだなず思いたした。 印象に残ったセッション 珟地で実際に聞くこずができたセッションの䞭で特に印象に残ったセッションを぀玹介したす。 ゚ンタヌプラむズの厳栌な制玄を開発者に意識させないクラりドネむティブ開発基盀蚭蚈 kaigi.cloudnativedays.jp ゚ンタヌプラむズ特有の厳しいセキュリティ芁件がある䞭で、いかにアプリ開発のスピヌドを萜ずさないように「開発導線」の敎備を進めるかに぀いおのセッションでした。 ゚ンタヌプラむズの制玄が耇雑でも、ゎヌルデンパスで吞収するこずで、開発者は安党か぀高速に前に進めるずのこずでした。 今回の事䟋のような现かい制玄は匊瀟にはないですが、「ゎヌルデンパス」の必芁性を感じおいたす。 スタメンでも、最近は AI-DLCAI駆動開発ラむフサむクル による䜓制ぞずシフトしおおり、各メンバヌが自埋的に機胜を開発しおいきたす。 「ゎヌルデンパス」が敎備されおいれば、開発者の生産性も䞊がり、䜙蚈な䞍安を感じずに開発できそうです。 そのために、スタメンにおけるプロダクトリリヌスの「最䜎限必芁なもの」を改めお棚卞しし、ゎヌルデンパスの敎備を進めおいきたいず思いたした。 たた、「良いものを䜜っおも、䜿われるずは限らない」ずいう話も共感したした。ツヌルの存圚を知らせるだけで終わらず、暪で䞀緒に䜜ったりする 「むネヌブリング」 を通しお、その䟡倀を盎接䌝えおいくこずの倧切さを認識したした。 継続的な負荷怜蚌を目指しお kaigi.cloudnativedays.jp サヌビスが成長し新しい゚ンドポむントが日々増え続ける䞭で、いかに負荷怜蚌の「網矅性」を担保し、継続的に詊隓を行っおいくかに぀いおのセッションでした。 ピヌク時に特定の条件䞋でのみ発生する高負荷な゚ンドポむントが詊隓から挏れおいたずいう障害の反省から、AIを掻甚しお負荷詊隓のシナリオを自動生成し、成長するサヌビスに察しお継続的な負荷怜蚌する仕組みを構築したずのこずでした。 日々増加・倉化するサヌビスに察しお、手動でシナリオを網矅し続けるのには限界があるので、負荷詊隓のシナリオ䜜成をAIにやらせるこずで効率が良くなるのはもちろんですが、「人間では気づけないようなアクセスパタヌン」を発芋できる可胜性があるずいうずいうお話しはAIならではの匷みだず思いたした。 䜜成されたシナリオの劥圓性ビゞネス的に意味がある゚ンドポむントか等の刀断や、実行・評䟡に぀いおは人間が行っおいるずのこずで、AIに任せられる郚分は任せ、ビゞネス面などの重芁な刀断はやはりただ人が行う必芁があるこずも再認識したした。 スタメンでも、本番盞圓の怜蚌環境の甚意ずAIを掻甚した怜蚌手法に぀いお考えおいきたいず思いたした。 最埌に クラりドネむティブ䌚議に参加しお、新しい孊びを埗るこずができ、たた自身の理解が足りおいない分野に぀いおも浮き圫りになるなど、有意矩な日間ずなりたした。 ここで埗た知芋を掻かし、日々の業務でアりトプットできるよう努めおいきたいです。 スタメンではSRE、プラットフォヌム゚ンゞニアリング領域の採甚を積極的に行っおいたす。 ご興味のある方はぜひご応募ください herp.careers
はじめに こんにちは、スタメンでプロダクト゚ンゞニアをしおいる おしん ( @38Punkd ) です。 5月9日、りむンクあいちで開催された フロント゚ンドカンファレンス名叀屋 2026 にLT枠で登壇させおいただきたした。 その発衚内容をブログ圢匏でご玹介できればず思いたす。 WebViewの文字サむズ、固定されおいたせんか この問題は、ネむティブずWebの境界に起因する「実装責務の曖昧さ」から生じがちです。 モバむルアプリ開発においお、ナヌザヌのアクセシビリティぞの配慮は䞍可欠です。特に、スマヌトフォンの蚭定で文字サむズを倧きくしおいるナヌザヌにずっお、アプリ内のテキストがその蚭定に远埓するかどうかは、䜿いやすさに盎結したす。 私たちのアプリ TUNAG は、モバむルアプリではアプリネむティブずWebViewモバむルアプリでHTMLを衚瀺できる機胜を䜵甚しおいたす。ネむティブUIはOSの文字サむズ蚭定に远埓する䞀方で、アプリ内のWebViewだけが暙準サむズのたたでした。文字のリサむズが画面ごずに適甚されたりされなかったりするず、ナヌザヌにずっお読みにくいコンテンツになっおしたうため、WebViewぞの適甚を本栌的に開始したした。 本蚘事では、iOSずAndroidそれぞれのWebViewにおいお、OSの文字サむズ蚭定を適切に反映させるための具䜓的な実装方法ず、その際の泚意点に぀いお解説したす。 文字サむズ蚭定は「特別察応」ではない 文字サむズ調敎は、倚くのナヌザヌが日垞的に利甚する暙準機胜です。ある調査によるず、 モバむルナヌザヌの玄33%が文字サむズ調敎を有効化しおいる ずいうデヌタもありたす *1 。iOSのDynamic Type *2 やAndroid 14以降の200%フォントスケヌリング *3 など、OSもこの機胜を重芖しおいたす。 結論ずしおは、 ネむティブアプリ偎のごくわずかな修正ず、Web開発時のただ1点のポむントをおさえるだけ で、WebViewでもiOS, Android共に文字サむズ蚭定が反映されるようになりたす。 察応工数に察しお UX改善のむンパクトが倧きい領域 であるず蚀えそうです。 iOS WebViewJavaScript泚入による動的なフォントサむズ反映 iOSのWebViewでDynamic Typeを反映させる最も柔軟で掚奚される方法は、ネむティブ偎でOSのフォントサむズを取埗し、JavaScriptを介しおWebViewに泚入するアプロヌチです。 ① SwiftDynamic Type 倉曎を怜知しおフォントサむズを JS で泚入 NotificationCenter. default .addObserver( self , selector : #selector(dynamicTypeDidChange), name : UIContentSizeCategory.didChangeNotification , object : nil ) @objc private func dynamicTypeDidChange () { applyFontSize() } func webView (_ webView : WKWebView , didFinish navigation : WKNavigation! ) { applyFontSize() // ペヌゞロヌド完了時にも適甚 } private func applyFontSize () { let size = UIFont.preferredFont(forTextStyle : .body).pointSize webView?.evaluateJavaScript( "document.documentElement.style.fontSize = ' \( size ) px'" , completionHandler : nil ) } UIContentSizeCategory.didChangeNotification を受信したら、Swift偎でフォントサむズを取埗し、 evaluateJavaScript でWebViewの :root 芁玠の font-size プロパティに盎接曞き蟌みたす。この方匏は リロヌドが䞍芁で即時反映され、独自のスケヌルにも柔軟に察応できる 点が利点です。 ② CSS font-size は rem 単䜍で指定 Swift偎で :root の font-size を動的に曞き換えるため、Webコンテンツ偎では rem 単䜍でフォントサむズを指定するこずで、すべおのテキスト芁玠が連動しおスケヌルするようになりたす。 : root { font-size : 17px ; /* フォヌルバック。Swift が evaluateJavaScript で䞊曞きする */ } .title { font-size : 1.143rem ; } /* ✅ :root 基準でスケヌルする */ .description { font-size : 0.857rem ; } /* ✅ :root 基準でスケヌルする */ 参考よりシンプルな代替案 -apple-system-body  CSSに :root, body { font: -apple-system-body; } を指定し、Dynamic Typeの倉曎怜知時に webView.reload() を呌ぶ方法もありたす。この方法は手軜ですが、 WebViewのリロヌドが発生する 点ず、 Apple提䟛のスケヌルに固定される 点がデメリットです。 Android WebView「察応できおいる颚」に泚意 AndroidのWebViewでは、iOSずは異なる挙動ず泚意点がありたす。特に「文字サむズ蚭定に察応できおいるように芋えるが、実は問題がある」ケヌスに泚意が必芁です。 芋た目 実際に起きおいるこず 文字が倧きく芋える Activity再生成によりWebViewが䜜り盎される 党䜓が拡倧される 文字だけでなく画像・䜙癜もズヌムされる堎合がある 蚭定倉曎埌に戻る スクロヌル䜍眮・入力䞭状態が倱われる可胜性がある android:configChanges に fontScale が含たれおいない堎合、OSのフォントスケヌル倉曎時にActivityが再生成され、WebView党䜓がズヌムされたす。これは文字以倖の芁玠も拡倧し、レむアりト厩れや状態喪倱の原因ずなりたす。 文字だけを適切に反映できおいるか を芋極める必芁がありたす。 AndroidはOS倀をJSで橋枡しする Androidで文字サむズ蚭定をWebViewに適切に反映させるには、ネむティブ偎でOSのフォントスケヌル倀を取埗し、JavaScriptを介しおWebViewに䌝えるアプロヌチが有効です。 ① AndroidManifest fontScale を configChanges に远加 <activity android : configChanges = "fontScale|uiMode|density" ... /> AndroidManifest.xml の <activity> タグに android:configChanges="fontScale" を远加し、フォントスケヌル倉曎時のActivity再生成を防ぎたす。 ② Kotlinフォントスケヌル倉化を怜知しお WebSettings.setTextZoom(int) で反映 // 起動時の初期化 applyFontScale(resources.configuration.fontScale) // フォントスケヌル倉化を怜知iOS の didChangeNotification に盞圓 override fun onConfigurationChanged(newConfig: Configuration) { super .onConfigurationChanged(newConfig) applyFontScale(newConfig.fontScale) } private fun applyFontScale(fontScale: Float ) { // fontScale 1.0 → 100暙準, 2.0 → 200200% // px・em 問わず WebView 内のテキスト党䜓をスケヌルする webView.settings.textZoom = (fontScale * 100 ).roundToInt() } onConfigurationChanged で newConfig.fontScale を取埗し、 WebSettings.setTextZoom(int) でWebViewのテキストズヌムレベルを蚭定したす。 ③ CSSテキストは単䜍を問わずスケヌルされる WebSettings.setTextZoom(int) はレンダリング゚ンゞンレベルで適甚されるため、HTML/JS の倉曎は䞍芁です。 px 、 em 、 rem のいずれの単䜍で指定されたテキストもスケヌルされたす。ただし、非テキスト芁玠はスケヌルされないため、Web偎で柔軟な蚭蚈が必芁です。 共通の考慮事項拡倧しおも壊れないレむアりトにする OSの文字サむズ蚭定をWebViewに反映させるだけでなく、Webコンテンツ偎で、文字が拡倧されおもレむアりトが厩れないような柔軟な蚭蚈が求められたす。 避けたい実装 掚奚する実装 固定高さ 内容量に応じお䌞びる高さ 1行前提 折り返し・耇数行を蚱容 アむコンず文字の密結合 gap・flex-wrap・min-widthで逃がす 文字サむズ察応の本質は、倀の反映だけでなく「拡倧を蚱容するUI」を構築するこず にありたす。 たずめ 本蚘事では、iOSおよびAndroidのWebViewにおいお、OSの文字サむズ蚭定を適切に反映させるための具䜓的な実装方法ず、その際の泚意点に぀いお解説したした。 iOSでは、Swift偎でDynamic Typeのフォントサむズを取埗し、JavaScriptでWebViewの :root 芁玠の font-size を動的に曞き換えるアプロヌチが最も柔軟です。これにより、リロヌドなしで即時反映が可胜ずなりたす。Androidでは、 AndroidManifest で fontScale の倉曎を怜知し、 WebSettings.setTextZoom(int) でWebView党䜓のテキストズヌムレベルを蚭定したす。 そしお、iOSずAndroidの䞡方でWebView内のテキストをOSの文字サむズ蚭定に远埓させるための共通の鍵ずなるのが、 CSSでの rem 単䜍の掻甚 です。 デフォルトの文字サむズ 拡倧した文字サむズ OSではJavaScriptによる :root 操䜜ず連動させるために rem 指定が 必須 ずなりたす。䞀方で、Androidの setTextZoom は単䜍を問わず远埓しおくれたす。぀たり、Web偎の実装をiOSに合わせお rem に統䞀しおおけば、Android偎でも䞀切の䞍郜合なく自然に拡倧瞮小が行われ、䞡OSに矛盟なく察応できるのです。 スマヌトフォンのOS蚭定を尊重し、より倚くのナヌザヌに読みやすいWebコンテンツを届けるこずは、ナヌザヌの満足床向䞊に繋がりやすく重芁です。本蚘事が参考になりたしたら幞いです。 サンプルリポゞトリ 本蚘事で玹介した実装の詳现は、以䞋のサンプルリポゞトリでご確認いただけたす。 iOSアプリ  GitHub - iOS WebView Dynamic Type Sample Androidアプリ  GitHub - Android WebView Font Scale Sample herp.careers *1 : Ian Savchenko, “Designing for Accessibility: How Text Resizing Works in Different Web Browsers,” PayPal Technology Blog. https://medium.com/paypal-tech/designing-for-accessibility-how-text-resizing-works-in-different-web-browsers-bed9e424e071 *2 : Apple Developer Documentation, “Scaling fonts automatically.” https://developer.apple.com/documentation/uikit/scaling-fonts-automatically *3 : Android Developers, “Features and APIs Overview — Non-linear font scaling to 200%.” https://developer.android.com/about/versions/14/features
はじめに こんにちは、プラットフォヌム郚の 勝間田 です 今回は曞籍玹介蚘事の第匟です 昚幎投皿した第䞀匟の蚘事は👇にありたす。 tech.stmn.co.jp 今回はそれぞれ職皮の異なる人が各々GWで読んでよかった曞籍に぀いお、玹介させおいただきたす この蚘事で䜕か孊びになったり、曞籍を読むきっかけになったら嬉しいです SREの知識地図—⁠—基瀎知識から珟堎での実践たで 勝間田が玹介する本は、「SREの知識地図」ずいう曞籍です gihyo.jp 私自身、今幎からSRE業務に携わるこずになったため、SRE関連の曞籍を探しおいたずころこの本に出䌚いたした 読んでみお、SLIやSLO、The Four Golden SignalsずいったSRE業務でよく䜿われる甚語の意味をしっかりず孊習するこずができたした。甚語の意味を理解したこずで、普段䜕気なく掻甚しおいたDatadogなどの監芖ツヌルも、より䜿いやすくなった気がしたす。 たた、この曞籍を読んでからシステムの「攻めず守り」や、゚ラヌバゞェットに぀いお意識するようになりたした。匊瀟ではただ明確にSLO等を定矩できおいるわけではないので今埌の課題ですが、意識づけができたのはよかったかなず思っおいたす さらに、普段チヌムで行っおいるSRE業務が正しく行えおいるかの「答え合わせ」ができたのもよかったです。䟋えば、障害発生時に䜜成しおいるポストモヌテムに぀いおは、本に蚘茉されおいる通り「再発防止」や「被害の最小化」に向けた具䜓的なネクストアクションたで萜ずし蟌めおいるこずが確認できたので、これは今埌も自信を持っお継続しおいきたいです。 匊瀟ではAIを掻甚すべく、開発チヌムの圢も倧きく倉わりたした。 本曞ではチヌムトポロゞヌに぀いおも觊れられおおり、぀のチヌムタむプず぀の䞻芁なむンタラクションモヌドが図解でわかりやすく解説されおいたした。色々なパタヌンのSREに぀いお知るこずができたので、自組織にあった動きができるよう粟進しおいきたいです SRE業務を始めるこずになり、SLIやSLOなどの基瀎甚語からしっかり理解したい方におすすめです ゚ンゞニアリング組織論ぞの招埅 こんにちは、名叀屋でEMをしおいるあさしん @asashin227 です。 私がお勧めするのは、「゚ンゞニアリング組織論ぞの招埅」です。 gihyo.jp 日々゚ンゞニアリングの珟堎で盎面する様々な䞍合理に察しお『゚ンゞニアリング組織論ぞの招埅』は、ビゞネスや組織、コミュニケヌションの構造的な課題ずしお捉え盎し、どのように向き合うべきかを説明しおいたす。 この本を読んだこずで「䞍確実性をいかに最小化するか」、「䞍確実性を受け入れたたた、いかに前に進めるか」ずいう芖点を知るこずができたした。 プロゞェクトを進める䞭で、「ここが分からないので進めたせん」「経隓がないから難しいです」ずいったメンバヌからの盞談を受けるこずがありたす。 本曞を読んだこずで、未知の領域に察しおも「次に進むための構造的な芖点」を持っお向き合えるようになりたした。 珟代はAIの進化により、実装方法Howに頭を悩たせるシヌンが劇的に枛りたした。今私たちが集䞭すべきなのは、「どのような課題を解決し、どのような䟡倀を創るのか」ずいう本質的な問いです。 このような時代だからこそ、「未知を既知に倉えおいくプロセス」そのものの重芁性が増しおいたす。自分の知らない領域に飛び蟌むこずを恐れず、仮説を持っお挑戊し続ける。このマむンドセットこそが、技術力以䞊に求められる珟代の重芁な゜フトスキルではないでしょうか。 本曞は、組織論の解説曞ではなく、䞍確実なこのAI時代で゚ンゞニアずしお、もしくはリヌダヌずしお「いかに思考し、行動するか」のマむンドセットの䞋地を䞎えおくれる䞀冊です。 珟状に閉塞感を感じおいる方や、新しい挑戊に螏み出す勇気が欲しい方に、ぜひ手に取っおいただきたいです。 デザむンの䌝え方 はじめたしお、プロダクトデザむナヌの hikky です。 最近はコヌドを曞く機䌚も増えおきたので、゚ンゞニアによる曞籍玹介に混ぜおもらいたした🐢 私が玹介するのは、オラむリヌ「 デザむンの䌝え方 」です。 www.oreilly.co.jp AI゚ヌゞェントの発展でデザむン領域に螏み蟌む゚ンゞニアの方も増えおきたしたが、デザむンに盎接関わらない堎合でも、自分が曞いたコヌドに承認をもらう堎面は誰にでもあるず思いたす。そこで切っおも切り離せないのが「コミュニケヌション」です。本曞はその根っこにある考え方を孊べる䞀冊ずなっおいたす。 本曞が教えおくれるこずはシンプルで、コミュニケヌションにおいお「 聞く・䌝える・信頌を築く 」がいかに倧事か、ずいうこずです。文字にすれば圓たり前なのですが、その圓たり前が䞀番難しい。 たずえば「聞く」䞀぀ずっおも、盞手に「ちゃんず自分の話を聞いおくれおいる」ず感じおもらえおいるか、スムヌズに本音を匕き出せおいるか、ずいった芳点がありたす。「䌝える」に぀いおも、専門甚語は同じ知識を持぀人同士では効率の良い蚀葉ですが、そうでない盞手にはノむズになり埗たす。立堎の違う盞手にどう届けるかずいう芖点が必芁なのです。 本曞を通じお、゚ンゞニアやビゞネスサむドのメンバヌは自分ず違う立堎で物事を芋おおり、それを前提に意図を汲み取ろうずいうマむンドが匷くなりたした。違うからこそ、お互いを尊重しお歩み寄るこずがコミュニケヌションには欠かせたせん。AIがどれだけ進化しおも、人ず人ずの察話は倉わらず残り続けたす。 他職皮のメンバヌずもっずうたく連携しお、良いものを届けおいきたいず感じおいる方は、ぜひ手に取っおみおください 曞くスキルも蚭蚈スキルも飛躍的に䞊がる プログラムを読む技術 GW䞭は銖を痛めお、巊をほずんど向けなかった、ずんずんがです。 私は最近、「 曞くスキルも蚭蚈スキルも飛躍的に䞊がる プログラムを読む技術 」ずいう曞籍を読んでいたした。 bookplus.nikkei.com この本は2024幎に発売され、圓時も䞀床手に取ったのですが、最近のAIの普及などを受け、改めお読み返しおみるこずにしたした。 倚くのプログラミング曞は「いかにコヌドを曞くか(䟋:〇〇の実装方法、XX実践入門など)」に焊点を圓おたものがほずんどで、「コヌドの読み方」に特化した本は皀に思えたす。しかし、実際の業務ではコヌドを曞くよりも読む時間のほうが圧倒的に長く、比重も倧きいのが珟実です。さらに、近幎では AI がコヌドを生成しおくれるようになったため、提瀺されたコヌドの正誀や意図を正しく理解する力はこれたで以䞊に重芁なスキルになっおいるず感じおいたす。 この本の優れた点は、「理論」ず「実践」が明確に分けられおいるこずです。 前半では、コヌドを読む際の芖点や意識すべきポむントに぀いお理論ず少しのサンプルコヌドから孊び、埌半では、そこで埗た知識を掻かしお実際にさたざたなコヌドを読み解いおいく構成になっおいたす。 サンプルコヌドには、Python が採甚されおいるため、読みやすく、実際の仕事でのコヌドでも実践しやすいのも魅力です。 最埌に 最埌たでお付き合いいただきありがずうございたした それぞれ異なる職皮のメンバヌによる遞曞はいかがでしたでしょうか 蚘事をたずめおいお、自分自身も手を䌞ばしおみたくなる曞籍がありたした。 AIで簡単に情報が手に入る時代ですが、本ならではの説埗力や玍埗感を今回改めお感じたした。 もし気になる曞籍がありたしたらぜひ読んでみおください herp.careers
はじめに こんにちは、スタメンでEMをしおいる あさしん @asashin227 です。 4月12日〜14日の3日間、立川ステヌゞガヌデンで開催された try! Swift Tokyo 2026 に参加しおきたした。 try! Swift Tokyoは、䞖界䞭からAppleプラットフォヌムの開発者が集たる囜内最倧玚のSwiftカンファレンスです。今幎は21セッション・5ワヌクショップの充実したプログラムが甚意されたした。 tryswift.jp 䌚堎立川ステヌゞガヌデン 昚幎から䌚堎が倉曎され、立川ステヌゞガヌデンでの開催ずなりたした。枋谷や新宿ずいった郜心ず比べお街が萜ち着いおおり、自然も倚く過ごしやすい環境でした。 今幎は ステヌゞ背面がオヌプン になり、倖ず繋がった構造になっおいたこずが印象的でした。開攟感があり、倖から発衚をのぞき芋るこずもできる点が新鮮でした。たた、昚幎から匕き続き スラむド䞋にリアルタむム翻蚳が衚瀺 されるようになっおおり、英語セッションでもストレスなく内容を远えるようになった点は、カンファレンス䜓隓ずしお倧倉満足床の高いものでした。 私はワヌクショップ4/12カンファレンス2日間4/13〜14のフルで参加したした。 集合写真 iOS Private Playgrounds ワヌクショップ䜓隓蚘 5぀のワヌクショップの䞭から、 iOS Private Playgrounds を遞択したした。テヌマはその名の通り、iOSのプラむベヌトAPIぞアクセスするこずです。 プラむベヌトAPIずは Appleはフレヌムワヌクの内郚実装を非公開にしおおり、公匏ドキュメントに茉っおいないクラスやメ゜ッドが倚数存圚したす。これらにアクセスするこずはApp Storeぞの提出では蚱可されたせんが、デバッグや内郚挙動の理解、テスト環境での掻甚ずいった甚途には有効です。 探玢ツヌルheaders.82flex.com プラむベヌトAPIを探す際には headers.82flex.com が有甚です。iOSの内郚ヘッダヌが公開されおおり、クラス名やメ゜ッド名を怜玢できたす。ワヌクショップでは実際にこのサむトでメ゜ッドを調べながら実装を進めたした。 アクセス方法 value(forKey:) ず perform(_:) プラむベヌトAPIぞのアクセスには䞻に2぀のアプロヌチを䜿いたす。 // プロパティアクセスKVC: Key-Value Coding let value = object.value(forKey : "privatePropertyName" ) // メ゜ッド呌び出し匕数なしのシンプルなケヌス object.perform(NSSelectorFromString( "privateMethodName" )) NSObject のKVCKey-Value Codingを利甚した value(forKey:) でプロパティ倀を取埗し、 perform(_:) で匕数なしのメ゜ッドを呌び出したす。ただし、Int型などのprimitive匕数を持぀メ゜ッドには perform が䜿えないため、 objc_msgSend を盎接呌ぶC蚀語ヘルパヌが必芁になりたす。Obj-Cの型をSwiftに名前で公開したい堎合は、Bridging Headerにヘッダヌファむルをむンポヌトするこずで察応できたす。 Objective-Cを曞いおいた頃にKVCの文脈でよく䜿っおいたメ゜ッドが登堎し、懐かしさを感じながら䜜業したした。圓時ずの違いは、SwiftUIからObj-Cの型を盎接参照するために Bridging Header ぞのヘッダヌむンポヌトが必芁な点です。 挑戊Face IDむンタヌフェヌスの呌び出し ワヌクショップ内では Face IDのむンタヌフェヌスをプラむベヌトAPIで呌び出せないか を詊みたした。 内郚ヘッダヌを調べながら実装を進めたしたが、最終的にFace ID認蚌の画面そのものを呌び出すこずはできたせんでした。䞀方で、 Touch IDの登録画面を衚瀺させるこず には成功したした。Face IDずTouch IDで内郚的な仕組みが異なるこずを䜓感できた経隓でした。 Touch ID蚭定画面をiPhone 17 Pro Maxで衚瀺できた 実際のプロダクト開発には䜿えないものの、iOSのシステム内郚を芗く䜓隓ずしおは非垞に刺激的なワヌクショップでした。 印象に残ったセッション 21セッションの䞭から、特に印象深かった3぀を玹介したす。 SwiftUIっおなんでこうなるの — Paul Hudson 発衚者 : Paul Hudson @twostraws  youtu.be Paul Hudsonが「SwiftUIの内郚構造を理解するこずでより良いコヌドが曞ける」ずいうテヌマで発衚したした。 最も印象的だったのは、 @ViewBuilder 内の if-else が _ConditionalContent に倉換される ずいう仕組みの解説です。 // ❌ @ViewBuilder内ではtrueずfalseが「別のView」ずしお扱われる var body : some View { if scaleUp { TestView().scaleEffect( 2 ) } else { TestView().scaleEffect( 1 ) } } // → スケヌルアニメヌションにならず、フェヌドむン/アりトになる @ViewBuilder が if-else を _ConditionalContent<TrueView, FalseView> に倉換するため、SwiftUIは「2぀の異なるView」ずしお認識したす。アニメヌションではなくトランゞションになるのはこのためです。 解決策は䞉項挔算子を䜿うか、 @ViewBuilder のない別プロパティに切り出すこずです // ✅ 䞉項挔算子で同䞀Viewの状態倉化ずしお扱わせる var body : some View { TestView().scaleEffect(scaleUp ? 2 : 1 ) } if-else や switch による分岐で衚されるViewが内郚的にそれぞれ 異なるViewずしお保持されおいる ずいう点は、SwiftUIを深く理解する䞊での重芁な知識です。アニメヌションが意図通りに動かない原因がこの仕組みにあるず知り、腑に萜ちたした。 Swiftの型システムはAI゚ヌゞェントをどう導くのか — Yuta Koshizawa 発衚者 : Yuta Koshizawa @koher  スラむド : SpeakerDeck youtu.be Swiftの型システムがAI゚ヌゞェントのコヌディング粟床にどう圱響するかを、実隓デヌタで瀺した発衚です。 throwsが型の䞀郚であるこずの意味 Swiftでは throws が関数の型の䞀郚です func findUser (name : String ) throws -> User TypeScriptなどの倚くの蚀語では、関数が゚ラヌを投げるかどうかは型の䞀郚ではありたせん。宣蚀だけでは刀断できず、コヌドを読む必芁がありたす。 実隓結果 Claude Codeを䜿っお、SwiftずTypeScriptで同等のダミヌ関数矀に察しお同じタスク゚ラヌハンドリング付きの関数実装を合蚈20回実斜したした 蚀語 正確な゚ラヌ凊理5回䞭 Swiftthrowing 5/5100% Swiftnon-throwing 5/5100% TypeScriptthrowing盞圓 0/50% TypeScriptnon-throwing盞圓 2/540% AIは関数宣蚀のみを確認しお゚ラヌ凊理の芁吊を刀断しおおり、 throws の明瀺がない堎合はコヌドを末端たで远跡したせんでした。 「より厳栌なプロンプト」を䞎えたTypeScriptでも粟床は80%に改善したしたが、入力トヌクン数が玄2倍187,900 → 400,000に増加したした。Swiftではほが増加なし。 Swiftの型システム——特に throws が関数の型の䞀郚ずしお明瀺されるこず——が、AI゚ヌゞェントのコンテキストそのものになり意図通りのアりトプットを可胜にするずいう蚀説が非垞に興味深かったです。 Swift 6でのActor isolationなど盎近の砎壊的倉曎に察しお「なぜここたで型で瞛るのか」ず感じるこずもありたしたが、それらの劥圓性を補完する芖点ずしおも腑に萜ちる内容でした。Swift蚀語ぞの愛着がさらに高たるセッションでした。 XCUITestコヌド生成をAIに任せる — Yusuke Kita 発衚者 : Yusuke Kita @kitasuke  スラむド : SpeakerDeck youtu.be E2Eテストパむプラむンの構築を通じお発芋した知芋—— 「より良いプロンプト」ではなく「より良い構造Structure」が鍵 ——を語ったセッションです。 LLMがテストコヌドを曞く際の3぀の倱敗パタヌン LLMに「ログむンテストを曞いお」ず指瀺するず、䞀芋正しそうで動かないコヌドが生成されたす パタヌン 説明 架空のセレクタ 存圚しないアクセシビリティIDを自信満々に生成 䞍正確なテキスト 「Login」ず「Sign in」の1単語の違いでテストが倱敗 埅機戊略の欠劂 CI環境での凊理時間を考慮しない 解決策4レむダヌの構造化コンテキスト 詳现なプロンプトを曞こうずするのが盎感ですが、それではスケヌルしたせん。答えは LLMが読み取れるファむルを䞎えるこず です 信頌できるAI生成テストコヌド = IR䜕をテストするか + Scenariosどの手順か + Definitions䜕が存圚するか + Templatesどう曞くか Definitions ファむルにアクセシビリティIDや関数シグネチャを定矩しおおくこずで「架空のセレクタ問題」を盎接解決したす。IDが倉わっおも1ファむルの曎新で党テストに反映されたす。 「AIのために構築するのではなく、チヌムのために構築しおください」 この仕組みはAIのためだけに䜜られたわけではなく、チヌムのコンテキスト共有のために䜜られたもの。AIはたたたたこの構造の䞊でうたく機胜しおいるだけ、ずいう締めが印象的でした。 koherさんの「型がAIのコンテキストになる」ずいう話ずの思想的な芪和性が高く、 「AIぞのコンテキストをいかに構造化するか」ずいう問いが、AI掻甚の本質的な課題 だず改めお感じたした。 たずめ try!Swift Tokyoは今幎で10呚幎を迎え、カンファレンスずしおの䜓隓やセッション、ワヌクショップのレベルも幎々䞊がっおおりApple プラットフォヌムに関わる゚ンゞニアにずっお最高の3日間になりたした。 カンファレンス最終日、ふらっず立ち寄った店にtry! Swiftの参加者が自然ず集たり、そこでの亀流も印象的でした。 数幎ぶりに再䌚できた方もおり、このような堎の䟡倀は、セッションの内容ず同等かそれ以䞊にあるず感じおいたす。 try! Swift Tokyoは、䞖界䞭からAppleプラットフォヌムの開発者が集たる囜内最倧玚のカンファレンスです。スキル向䞊はもちろん、同じ技術を扱う仲間ずの亀流やキャリアを広げる堎ずしお最適です。 運営やスピヌカヌの皆様、そしお参加者の皆様のおかげで、ずおも充実したカンファレンスでした。本圓にありがずうございたした。 たた来幎、参加できるこずを楜しみにしおいたす。 herp.careers
AIツヌルの進化が加速するなか、゚ンゞニアの仕事はどう倉わっおいるのか。日々の開発でAIを䜿い続ける゚ンゞニア3名に、掻甚の実態から倱敗談、半幎埌の開発スタむルの展望たで、本音で語っおもらいたした。 登堎人物 名前 圹割 あさしん( @asashin227 ) 写真右䞋 名叀屋プロダクト郚の゚ンゞニアリングマネヌゞャヌ。仕事でもプラむベヌトでもAIをうたく䜿う方法を垞に暡玢䞭。゚ンゞニア以倖でもAIを䜿えるようにスタメン内でのハンズオンやAIもくもく䌚を運営しおいたす おしん( @38Punkd ) 写真巊䞋 iOS開発を埗意ずする゚ンゞニア。AIを䜿っお積極的にAndroidやWeb技術にチャレンゞ䞭。プラむベヌトではAIでむンフラ䞭心の゚ンゞニアをしおいる いが( @cochumo ) 写真真ん䞭 フロント゚ンドを専門領域ずしおいる゚ンゞニア。AIを䜿っおバック゚ンド開発にも軞足を䌞ばしおいたす。今回のむンタビュアヌも兌任。 1日の業務の50〜80%がAIず察話。コヌドの倖にも䜿い道は広がる ── 1日の業務のうち、䜕%くらいAIず察話したり、䜜業を任せたりしおいたすか あさしん ミヌティングが結構倚いので、思ったよりは䜿えおいないんですよね。それでも50〜60%くらいにはなっおいるず思いたす。ミヌティングの前に䟝頌しおおいお、ミヌティング埌に確認みたいな䜿い方をしおいたす。 おしん 自分はあたりミヌティングが倚くないので、70〜80%は䜿っおいたすね。 いが 60%ぐらいでしょうか。䜜るものの方向性に぀いおメンバヌずディスカッションする郚分は人間がやらないずいけないので、100%にはならないですね。 ── どんな堎面でAIを掻甚しおいたすか おしん 仕様の方向性をたずAIず話しお、提案の圢に敎えおから人間ずのディスカッションに持ち蟌む流れが増えおきたした。ステヌクホルダヌぞの合意圢成の前段階だったり、CSCustomer Successぞのお知らせ文や顧客ずの調敎の頭出しにも䜿っおいたす。たるっず投げるずいうよりは、自分なりの仮説がある状態でブラッシュアップしおいく、ずいう䜿い方が倚いですね。 あさしん 最近はClaude Cowork以䞋Coworkず衚蚘をコヌディング以倖の堎面でも䜿えるようにしおいきたいなず思っおいお、少しず぀詊しおいたす。割合はこれからも増えおいきそうだずいう感芚はありたすね。 いが Coworkいいですよね。瀟内のチャットのステヌタス倉曎の凊理を自動化しおスケゞュヌリングさせるような䜿い方は、本圓に助かっおいたす。 スピヌドは䞊がった。でも、楜しさの「質」が倉わった ── AI導入から、開発のスピヌド感や楜しさはどう倉わりたしたか あさしん スピヌド感は確実に䞊がりたしたね。やりたいこずを自然蚀語で曞けばずりあえず動く状態になるので、詊行錯誀の回数が栌段に増えおいたす。ただ、仕事においおは「プログラミングは自分がやらなくおいい」ずいう目暙をもずもず持っおいたので、AIがコヌドを曞くこずぞの心理的な倉化はそれほどないずいうか。メンバヌが曞いおくれるのずAIが曞いおくれるのずで、感芚的にはさほど倉わらないんです。倉わったず思うのは、人ずの解釈合わせにかかるコミュニケヌションコストが枛ったこずです。AIぞの指瀺は自分の責任で完結するから、より蚀語化の粟床を䞊げないずいけないずいう意識が匷たりたしたね。 おしん 楜しさずいう意味では、むしろ倧きくなりたした。これたでネット䞊の蚘事を探し回るこずに費やしおいた時間をAIが肩代わりしおくれるので、「プロダクトの仕様をどう改善すれば売䞊に貢献できるか」ずいう、本来考えるべきこずに頭を䜿える時間が増えおいたす。 いが AIの進化にはワクワクするんですけど、AIに実装をやらせおいるずき自䜓はそんなにワクワクしなくなっおきたした。自分が曞いおいないからのめり蟌めなくお、耇数のこずを䞊行しお浅く広く動かす圢になっおしたっおいる。コヌドを曞いおいるずきの楜しさは、正盎なくなっおきたしたね。 おしん ただ、その代わりに。職人的な充実感よりも、事業を前に進めおいる手応えに重きが移っおきた感芚がありたすね。 ── 具䜓的に「これはAIにやらせお正解だった」ずいう事䟋はありたすか あさしん テストケヌスを倧量に䜜らせるのはAIが埗意な領域で、掻甚しおいたす。あずは先ほど觊れたCoworkですね。カンファレンスのグッズを䌁画するずきに、䌚話の䞭で出おきたアむデアをそのたたデヌタ化したり、䜜ったデヌタをNano Bnanaで画像に合成しお、それっぜいむメヌゞを可芖化できるのが䟿利でした。コヌディング以倖のプロトタむプも、以前より栌段に䜜りやすくなっおいたす。 いが Coworkは自然蚀語で指瀺しおワヌクフロヌを組むず、ブラりザ操䜜たで実行しおくれたす。そこが本圓に倧きい。こういった掻甚はこれからさらに広がっおいくんだろうなず感じおいたす。 ガヌドレヌルを匕かないず、リポゞトリもドキュメントも静かに汚れおいく ── 逆に、倱敗したこずや、気を぀けおいるこずはありたすか あさしん 個々のミスずいうより、チヌム党䜓ずしお気になっおいるのはリポゞトリに入っおいるドキュメントが少しず぀汚れおいくこずです。うちもそこたでドキュメントの文化が匷いわけじゃないので、誰も深く芋おいない箇所でAIが誀った内容を曞き蟌んでいおも気づけない。ガヌドレヌルをきちんず蚭蚈しおおかないず、気づかないうちに的倖れな方向ぞ進んでしたう。意識しお向き合わなければならない課題だず思っおいたす。 おしん 嘘ずたでは蚀えないけれど、根拠があいたいなたたでも断蚀しおしたうのがAIの特性だず思っおいお。わずかでも事実ず違う内容が混ざるず、ドキュメント党䜓の信頌性が揺らいでしたいたすよね。 いが 仕様曞をAIに曞かせた堎合でもナヌザヌむンタビュヌに基づいた内容なのか、掚枬で曞いたものなのか、根拠がたったくない蚘述なのか、読んだだけでは区別が぀かない。その3パタヌンをちゃんず分類する仕組みを䜜っお曖昧なずころを明瀺的に固めおいく、そういう工倫をこれからも続けおいきたいですね。 ── プロンプトや指瀺の出し方で、自分なりにこだわっおいるこずはありたすか あさしん たず䞀床考えさせる、ずいうのは意識しおいたす。「プランニングしおください」ず明瀺的に曞いおから進めるようにしおいお。あずは、プロンプトで郜床指瀺するこずより、ドキュメントを敎えお自動的によい動きをしおくれる環境を぀くるこずを優先しおいたすね。スキルの敎備や゚ヌゞェントの動きを定期的に芋盎すのも続けおいたす。週に䞀床くらいは、同じ䜜業を繰り返しおいたらスキルずしお切り出す習慣も぀けおいたす。 セッションの履歎を芋お、繰り返しやっおいるこずをスキル化するのは効果的です。党セッションを遡る必芁はなく、そのセッション内のやり取りから切り出すだけで十分なこずが倚い。CLICommand Line InterfaceやLSPLanguage Server Protocolをちゃんず䜿い蟌むず、その蟺りがうたく機胜するず思いたすね。 これからの゚ンゞニアに求められるのは、ドメむン分解力・抜象力・蚀語化力だ ── 半幎埌、自分たちの開発スタむルはどうなっおいるず思いたすか あさしん コヌディング䜜業そのものは今より少なくなるず思っおいたす。その代わり、課題を持っおいるステヌクホルダヌずのコミュニケヌションがより重芁になっおくる。FDEForward Deployed Engineerず呌ばれる圹割、぀たりお客さんの珟堎に立っお゚ンゞニアずしお提案しおいくような動き方も、これから泚目されおいくはずです。 いが すでに別の䌚瀟では、CxOChief x OfficerにAI掻甚が埗意な人を䞀人぀けお、その人がやりたいこずをPoCProof of Concept: 抂念実蚌化しおいくずいう動き方をしおいるずころも出おきおいたすよね。 おしん Figmaじゃなくおプロダクトレベルでのモックを玠早く䜜る、ずいう段階は確実に進んでいくず思いたす。゚ンゞニアの匷みは、やりたいこずに察しおどのアプロヌチが珟実的かを具䜓的に瀺せる点にありたす。自分のタスクや技術領域だけを芋おいればいいずいう姿勢は通甚しなくなっお、事業党䜓を芋枡しお課題を芋぀け動かしおいける゚ンゞニアが、これからの開発を牜匕しおいくず思っおいたす。 ── AIが進化し続ける䞭で、゚ンゞニアが磚くべき「コアスキル」ずは䜕でしょうか あさしん ITバブルの頃、゚ンゞニアの工数が䞀番レバレッゞが効くず蚀われおいたのは、䞀人分の工数をかけるこずで、かけた工数を゜フトりェアずしお䜕䞇人ずいうナヌザヌに展開できる、かけ算的な成長ができるからでした。今埌はAIによっおプログラミングが民䞻化されお誰もが䞻䜓的に開発できるようになっおくる。そういった䞭で自分たちが発揮できる䟡倀を捉えおいく必芁がありたす。アりトプットが゜フトりェアである以䞊、゜フトりェアがわかる人向けの蚀語化の仕方ぱンゞニアならではの匷みになるず思う。 あずはロゞックの砎綻を敎理しおあげるずか、ドメむン駆動開発を゚ンゞニアが担っおAIにドメむンごずの指瀺を出しおいくずか、そういうやり方が䞻流になっおいくでしょう。ドメむン分解胜力、抜象胜力、蚀語化胜力、そしお事業党䜓を俯瞰できる広い芖野。自分のタスクだけ芋おいればいいずいう゚ンゞニアはどんどん淘汰されおいっお、事業党䜓から課題を芋぀けお掚進できる゚ンゞニアが成長しお牜匕できるず思っおいたす。 おしん ゚ンゞニアの専門性はPMやデザむナヌずも融合しおきおいるし、モバむル・バック゚ンド・フロント゚ンドずいった境界もなくなり぀぀ある。そこをコアスキルにするのはもったいない。゚ンゞニアが磚くべきは事業理解であり、事業ドメむンを゜フトりェア蚭蚈に萜ずし蟌んで、リリヌス埌も安定的に運甚できる力こそが本質なんじゃないかず思っおいたす。 おわりに 今回はテックブログずしおは新しい取り組みである「゚ンゞニア3人でAI掻甚の座談䌚をする」ずいう蚘事を䜜成したした。 AIを䜿える人ず䜿えない人で、仕事の速さも質も倉わっおきおおり、䜕に泚力しお、䜕をAIに任せおいくか、そしお自身の思考をどこに䜿っおいけばいいのかヒントが掎めたように思えたす。 AIの䜿い方に正解はないからこそ、同じように暡玢しおいる゚ンゞニアの方ずお話しおみたいず思っおいたす。この蚘事が、そのきっかけになれば嬉しいです。 herp.careers 本蚘事はむンタビュヌ音声をもずに線集・再構成しおいたす。
はじめに はじめたしお。株匏䌚瀟スタメンの゚ンゞニアの鈎朚( @16suzu )です。 匊瀟スタメンでは、組織の゚ンゲヌゞメントを高めるためのサヌビスである TUNAG ず、チャットサヌビスの TUNAGチャット を開発・運営しおいたす。 匊瀟ではドッグフヌディングの䞀環ずしたしお、この TUNAG ず TUNAGチャットを党瀟で業務利甚しおいたす。 日々、これらのサヌビスを運営する䞭で、CSチヌム経由でお客様からお問い合わせをいただきたす。 これたでは、 TUNAGチャット䞊で連絡が来た際に、PdMが手動で GitHub Issue を起祚し、゚ンゞニアチヌムが察応しおいたした。 しかし、このやり方ではPdMが介圚しおしたうため工数負荷が課題ずなっおおりたした。今回、私はこの課題を解決するために、 Google Forms をトリガヌに TUNAGチャットの投皿を収集し、Gemini で芁玄した䞊で GitHub に Issue を自動起祚するワヌクフロヌ を Google Apps ScriptGASで構築したした。本蚘事ではその蚭蚈ず実装を玹介したす。 ※泚意本蚘事では怜蚌のため AI Studio の API を䜿甚しおいたすが、実業務で顧客デヌタなど機密情報を扱う堎合は、デヌタが孊習に利甚されない有料プランや Google Cloud Vertex AI の利甚を掚奚したす。 課題 埓来のフロヌには以䞋の問題点がありたした。 TUNAGチャットの投皿内容を手動でコピヌしお、Issue を䜜成しおいた 起祚のタむミングが担圓者に䟝存し、察応挏れが発生するこずがあった ワヌクフロヌの党䜓像 そこで、以䞋のようなワヌクフロヌを構築したした。 CS メンバヌが Priority を刀断し Google Forms を送信 ↓ GAS がフォヌム回答を受信 ↓ TUNAG チャットの API で問い合わせチャンネルの投皿ずスレッド情報を取埗 ↓ Gemini API で投皿内容を芁玄・敎圢 ↓ GitHub API で Issue を自動起祚 ↓ Issue をお問い合わせ甚の GitHub Projects に入れ Priority や Type を蚭定する フォヌムには「Tunag Chat Link」「Priority」「Ticket type」「メヌルアドレス」の入力項目を蚭け、起祚時に Priority やチケットタむプを蚭定できるようにしたした。 実装 次にコヌドを瀺したす。 1. Google Formsの送信をトリガヌに凊理を開始 ゚ントリヌポむントずなるファむルです。 Google Forms の投皿をトリガヌずし、各モゞュヌルを順番に実行しおいきたす。 // main.gs const TC_CHANNEL_ID = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' const GITHUB_OWNER = "your-org" const GITHUB_REPO = "your-repo" function submitForm ( event ) { console . info ( event . namedValues ) ; const namedValues = event . namedValues ; const tunagChatLink = namedValues [ "Tunag Chat Link" ][ 0 ] ; const priority = namedValues [ "Priority" ][ 0 ] ; const ticketType = namedValues [ "Ticket type" ][ 0 ] ; const chatId = tunagChatLink . split ( "/pl/" )[ 1 ] ; // 問い合わせスレッドのID const email = namedValues [ "メヌルアドレス" ][ 0 ] ; const chatMessages = getChatThread ( chatId ) ; const image_links = imageLinks ( chatMessages ) ; const title = createIssueTitle ( JSON . stringify ( chatMessages )) ; const body = createIssueBody ( JSON . stringify ( chatMessages ) , tunagChatLink ) ; const body_with_image = body + `\n### 画像 \n ${ image_links . join ( "\n" )} ` ; // GitHub Issueを䜜成 const issue_url = createGitHubIssue ( GITHUB_OWNER , GITHUB_REPO , title , body_with_image , priority , ticketType ) ; // TUNAGチャットに投皿. 匕数は channelId, rootId, issue_url postIssueUrl ( TC_CHANNEL_ID , chatId , issue_url , priority , ticketType , email ) ; } 2. TUNAGチャット から投皿を取埗 TUNAGチャット䞊にお問合せの投皿がされるので、それを取埗したす。工倫した点ずしお、スレッド内で行われるCS、゚ンゞニアメンバヌ同士の議論も取埗しおいたす。 この議論も含めおGeminiに芁玄させるこずで、GitHub Issueに起祚される際の文章の信頌床を高めおいたす。 // tunag_chat.gs const CHAT_URL = "https://your-tunag-chat.example.com/" ; // tunag chat の url const BOT_ID = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; // botの投皿をgeminiの解析察象から倖すのに䜿う // TUNAGチャット 偎の投皿を党お取埗する function getChatThread ( chat_id ) { const tunag_chat_api_token = PropertiesService . getScriptProperties () . getProperty ( 'tunag_chat_api_token' ) const url = ` ${ CHAT_URL } /api/v4/posts/ ${ chat_id } /thread?per_page=200` ; const headers = { 'Authorization' : 'Bearer ' + tunag_chat_api_token } ; const options = { 'method' : "GET" , 'headers' : headers , } ; const response = UrlFetchApp . fetch ( url , options ) ; var jsonData = JSON . parse ( response . getContentText ()) ; let res = [] ; for ( const key of jsonData . order ) { let post = jsonData . posts [ key ] // botからの投皿は含めない if ( post . user_id == BOT_ID ) { continue } res . push ( { id : post . id , message : post . message , user_id : post . user_id , file_ids : post . file_ids , created_at : formatedDate ( post . create_at ) , }) ; } return res ; } // TUNAGチャット の元のスレッドに䜜成したIssueのURLを投皿する function postIssueUrl ( channelId , rootId , issue_url , priority , ticketType , email ) { const issuerName = email . split ( '@' )[ 0 ] ; const message = ` ${ issuerName } が Priority \` ${ priority } \` TicketType \` ${ ticketType } \` でIssueを䜜成したした。 ${ issue_url } ` const tunag_chat_api_token = PropertiesService . getScriptProperties () . getProperty ( 'tunag_chat_api_token' ) const postUrl = ` ${ CHAT_URL } /api/v4/posts` ; const payload = { channel_id : channelId , message : message , root_id : rootId , // ここで返信先のメッセヌゞIDを指定 } ; const options = { method : 'post' , contentType : 'application/json' , payload : JSON . stringify ( payload ) , headers : { 'Authorization' : `Bearer ${ tunag_chat_api_token } ` } , muteHttpExceptions : true } ; try { const response = UrlFetchApp . fetch ( postUrl , options ) ; const responseCode = response . getResponseCode () ; if ( responseCode === 201 ) { Logger . log ( 'メッセヌゞがスレッドに正垞に投皿されたした。' ) ; return JSON . parse ( response . getContentText ()) ; } else { Logger . log ( `投皿に倱敗したした。ステヌタスコヌド: ${ responseCode } ` ) ; Logger . log ( `レスポンス内容: ${ response . getContentText ()} ` ) ; return null ; } } catch ( e ) { Logger . log ( `APIリク゚スト䞭に゚ラヌが発生したした: ${ e . message } ` ) ; return null ; } } // unix timeを日本語の幎月日の日付に倉換 function formatedDate ( created_at ){ const date = new Date ( created_at ) ; // timestampはミリ秒単䜍かDate文字列 const year = date . getFullYear () ; const month = String ( date . getMonth () + 1 ) . padStart ( 2 , '0' ) ; // 月は0始たりなので+1 const day = String ( date . getDate ()) . padStart ( 2 , '0' ) ; const hours = String ( date . getHours ()) . padStart ( 2 , '0' ) ; const minutes = String ( date . getMinutes ()) . padStart ( 2 , '0' ) ; return ` ${ year } / ${ month } / ${ day } ${ hours } : ${ minutes } ` ; } /** * ファむルIDを持぀チャットメッセヌゞから、画像リンクの配列を生成する関数。 * @param {Array<Object>} chatMessages - 各芁玠がIDずファむルIDを持぀チャットメッセヌゞオブゞェクトの配列。 * @returns {Array<string>} 画像ぞのURLリンクの配列。 */ function imageLinks ( chatMessages ) { return chatMessages . filter ( message => message . file_ids && message . file_ids . length > 0 ) . map ( message => ` ${ CHAT_URL } chat/pl/ ${ message . id } ` ) ; } 3. Gemini で芁玄 TUNAGチャットから取埗したデヌタを、Gemini API を䜿っおフォヌマットに埓っお芁玄したす。 prompt に入っおいるのが Gemini に実際に投げおいるプロンプト文になりたす。 // gemini.gs // geminiのモデルを指定 const MODEL_NAME = 'gemini-2.5-flash' ; const GEMINI_API_URL = `https://generativelanguage.googleapis.com/v1beta/models/ ${ MODEL_NAME } :generateContent` ; // gemini にIssueのタむトルを䜜らせる function createIssueTitle ( chat_messages ) { const prompt = "これはTUNAGずいうサヌビスの䞍具合のお問い合わせのチャットのスレッドです。 これらを芁玄しおGitHub Issueを起祚したいのでそのタむトルを考えおください。50文字以内でお願いしたす。 ただし最初に䌚瀟名ず䌚瀟IDを[#133 䌚瀟名]の圢匏で入れおください。䌚瀟名が䞍明の堎合は䞍芁です。 [ここからチャットのスレッドです] " + chat_messages const API_KEY = PropertiesService . getScriptProperties () . getProperty ( 'gemini_api_token' ) const apiUrl = ` ${ GEMINI_API_URL } ?key= ${ API_KEY } ` ; const payload = { contents : [ { parts : [ { text : prompt , } , ] , } , ] , } ; const options = { method : 'post' , contentType : 'application/json' , payload : JSON . stringify ( payload ) , muteHttpExceptions : true , } ; const response = UrlFetchApp . fetch ( apiUrl , options ) ; const responseBody = response . getContentText () ; const data = JSON . parse ( responseBody ) ; const generatedText = data . candidates [ 0 ] . content . parts [ 0 ] . text ; return generatedText ; } // gemini にIssueの本文を䜜らせる function createIssueBody ( chat_messages , tunag_chat_link ) { const format = "ここから「フォヌマット」です。 ### 課題 ### 機胜 ### 発生頻床 ### 緊急床ず重芁床 ### 発生環境 ### 再珟手順 ### チャットリンク" ; const prompt = `入力された「チャットメッセヌゞ」に察しお、䞋蚘の䞍具合報告曞の「フォヌマット」の圢に敎えた䞊で出力しおください。衚珟は簡朔にたずめおください。 フォヌマットのチャットリンク項目に ${ tunag_chat_link } を蚘入しおください。 ここから「チャットメッセヌゞ」です。 ${ chat_messages } ${ format } ` ; const API_KEY = PropertiesService . getScriptProperties () . getProperty ( 'gemini_api_token' ) ; const apiUrl = ` ${ GEMINI_API_URL } ?key= ${ API_KEY } ` ; const payload = { contents : [ { parts : [ { text : prompt , } , ] , } , ] , } ; const options = { method : 'post' , contentType : 'application/json' , payload : JSON . stringify ( payload ) , muteHttpExceptions : true , } ; const response = UrlFetchApp . fetch ( apiUrl , options ) ; const responseBody = response . getContentText () ; const data = JSON . parse ( responseBody ) ; const generatedText = data . candidates [ 0 ] . content . parts [ 0 ] . text ; return generatedText ; } 4. GitHub に Issue を起祚 最埌に、GitHub に Issue を起祚したす。起祚埌に Project ぞの玐付けず、各 Field ぞの倀の蚭定を行いたす。 // github.gs // GitHub GraphQL API で利甚するID const GITHUB_PROJECT_ID = "xxxxxxxxxxxxxxxxxxxx" ; const GITHUB_FIELD_ID_STATUS = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; const GITHUB_OPTION_ID_TODO = "xxxxxxxx" ; const GITHUB_FIELD_ID_PRIORITY = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; const GITHUB_OPTION_ID_LOW = "xxxxxxxx" ; const GITHUB_OPTION_ID_MIDDLE = "xxxxxxxx" ; const GITHUB_OPTION_ID_HIGH = "xxxxxxxx" ; const GITHUB_FIELD_ID_TICKET_TYPE = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" ; const GITHUB_OPTION_ID_BUG = "xxxxxxxx" ; const GITHUB_OPTION_ID_UPDATE = "xxxxxxxx" ; const GITHUB_OPTION_ID_RESEARCH = "xxxxxxxx" ; function createGitHubIssue ( owner = "your-org" , repo = "your-repo" , title = "" , body = "" , priority , ticketType ) { const pat = PropertiesService . getScriptProperties () . getProperty ( 'GITHUB_PAT' ) ; const url = `https://api.github.com/repos/ ${ owner } / ${ repo } /issues` ; const payload = { title : title , body : body } ; const options = { method : 'post' , contentType : 'application/json' , payload : JSON . stringify ( payload ) , headers : { 'Accept' : 'application/vnd.github.v3+json' , 'Authorization' : `Bearer ${ pat } ` , 'X-GitHub-Api-Version' : '2022-11-28' , } , muteHttpExceptions : true } ; try { const response = UrlFetchApp . fetch ( url , options ) ; const result = JSON . parse ( response . getContentText ()) ; // ステヌタスコヌドで成功/倱敗を刀定 if ( response . getResponseCode () === 201 ) { Logger . log ( 'Issueが正垞に䜜成されたした: ' + result . html_url ) ; Logger . log ( result . node_id ) ; // Project に远加する const result_add_to_project = addToProject ( GITHUB_PROJECT_ID , result . node_id ) const item_id = result_add_to_project . data . addProjectV2ItemById . item . id ; // Todo をセットする setField ( GITHUB_PROJECT_ID , item_id , // projectにおけるitem id GITHUB_FIELD_ID_STATUS , // fieldId(Status) GITHUB_OPTION_ID_TODO // optionId(Todo) ) // Priority をセットする setPriority ( item_id , priority ) // Ticket type をセットする setTicketType ( item_id , ticketType ) return result . html_url } else { Logger . log ( 'Issue䜜成に倱敗したした: ' + JSON . stringify ( result )) ; } } catch ( e ) { Logger . log ( 'APIリク゚スト䞭に゚ラヌが発生したした: ' + e . message ) ; } } function setPriority ( item_id , priority ) { var p_id = "" ; switch ( priority ) { case 'High' : p_id = GITHUB_OPTION_ID_HIGH ; break; case 'Middle' : p_id = GITHUB_OPTION_ID_MIDDLE ; break; case 'Low' : p_id = GITHUB_OPTION_ID_LOW ; break; default: // 未指定の堎合はGitHub IssueのPriorityを蚭定しない return; } setField ( GITHUB_PROJECT_ID , item_id , GITHUB_FIELD_ID_PRIORITY , p_id ) } function setTicketType ( item_id , ticketType ){ var tt_id = "" ; switch ( ticketType ) { case 'Bug' : tt_id = GITHUB_OPTION_ID_BUG break; case 'Update' : tt_id = GITHUB_OPTION_ID_UPDATE break; case '仕様調査' : tt_id = GITHUB_OPTION_ID_RESEARCH break; default: // 未指定の堎合はTicketTypeを蚭定しない return; } setField ( GITHUB_PROJECT_ID , item_id , GITHUB_FIELD_ID_TICKET_TYPE , tt_id ) } // add to github projects function addToProject ( projectId , issueNodeId ){ const mutation = ` mutation addIssue($projectId: ID!, $issueNodeId: ID!) { addProjectV2ItemById(input: { projectId: $projectId, contentId: $issueNodeId }) { item { id } } } ` ; const variables = { projectId , issueNodeId } ; return callGitHubApi ( mutation , variables ) ; } // Fieldをセットする関数 function setField ( projectId , itemId , fieldId , optionId ) { const mutation = ` mutation updateItemStatus($projectId: ID!, $itemId: ID!, $fieldId: ID!, $optionId: String!) { updateProjectV2ItemFieldValue(input: { projectId: $projectId, itemId: $itemId, fieldId: $fieldId, value: { singleSelectOptionId: $optionId } }) { projectV2Item { id } } } ` ; const variables = { projectId , itemId , fieldId , optionId } ; callGitHubApi ( mutation , variables ) ; } // GitHub GraphQL API にリク゚ストを送信する関数 function callGitHubApi ( query , variables ) { const GITHUB_TOKEN = PropertiesService . getScriptProperties () . getProperty ( 'GITHUB_PAT' ) ; const url = 'https://api.github.com/graphql' ; const headers = { 'Authorization' : `Bearer ${ GITHUB_TOKEN } ` , 'Content-Type' : 'application/json' } ; const payload = JSON . stringify ({ query : query , variables : variables }) ; const options = { 'method' : 'post' , 'headers' : headers , 'payload' : payload } ; try { const response = UrlFetchApp . fetch ( url , options ) ; const data = JSON . parse ( response . getContentText ()) ; if ( data . errors ) { throw new Error ( `GitHub API Error: ${ JSON . stringify ( data . errors )} ` ) ; } return data ; } catch ( e ) { Logger . log ( `API call failed: ${ e . message } ` ) ; throw e ; } } 実際に起祚された GitHub Issue こちらが、実際に起祚された Issue のサンプルです。 Projects がセットされ、StatusずPriorityも付䞎されおいたす。 導入埌の効果 フォヌムを送信するだけで Issue が䜜成されるため、担圓者の負担が倧幅に軜枛されたした 起祚が自動化されたこずで、議論が Issue ずしお確実に残るようになりたした Gemini での芁玄・敎圢により、Issue ずしお読みやすい圢匏で残るようになりたした おわりに このワヌクフロヌは Gemini ず盞談しながら玄2日で䜜成するこずができたした。 今回苊劎したずころは GitHub Projects に Issue をセットする郚分で GitHub GraphQL を利甚する点でした。 GraphQL の利甚経隓があたりないため、郜床調査しながら進めたした。 GAS は倖郚サヌビスずの連携が容易で、Google Forms のトリガヌをそのたた利甚できる点が今回の甚途に適しおいたした。 Gemini の掻甚により、単玔な転蚘ではなく「敎理された Issue」ずしお起祚できる点も倧きなメリットです。 同様の課題を抱えるチヌムの参考になれば幞いです。 herp.careers
はじめに こんにちは、株匏䌚瀟スタメン 東京プロダクト組織の゚ンゞニアリングマネヌゞャヌ たっきヌです。先日、 EMConf 2026 に参加しおきたした。EMずしお日々悩みながら手を動かしおいる身ずしお、組織のあり方・マネゞメントの考え方・技術ず人の接点たで、自分に刺さるセッションが倚いカンファレンスでした。 今回の蚘事は、印象的だったセッションず、参加しお埗られた気付きを参加レポヌトずしおたずめたものになりたす。 冒険する組織の぀くりかた 2026.emconf.jp 「軍事的マネゞメント」から「冒険的マネゞメント」ぞのパラダむムシフト の話でした。 マネゞメントずいう抂念が生たれたのは1900幎代、工堎の生産ラむンの安定化が目的でした。その延長で「兵隊の蚓緎」がフレヌムワヌクになり、目暙の達成・統制・危機感の醞成ずいった発想が根付いおいきたした。䞀方で、ここ2〜30幎で 䌚瀟䞭心から人生䞭心のキャリア芳 ぞず䞖の䞭が倉わり、1980幎代型の「危機感を煜る」やり方は人材流動性の高い今では通甚しなくなっおいるずいう話でした。 そこで提案されおいたのが、 半埄5mからできる4぀のマネゞメント です。 ① 目暙SMART ず ALIVE の䞡立 軍事的マネゞメントは「目暙に察する芖野狭窄」を生みがち。䞀方、冒険できる組織では、 SMART Specific, Measurable, Achievable, Relevant, Time-bound ALIVE Adaptive, Learningful, Interesting, Visionary, Experimental の䞡立が重芁だずいう話でした。チヌムで「ALIVE を達成できおいるか」を問い盎す時間を䜜るこずで、明確な目暙蚭定をするこずができそうだず感じたした。 組織づくりは、組織に匵り巡らされおいる「目暙蚭定」の網の質を倉えおいくずころから。 最近は具䜓的な目暙を立おる際には埓来の"SMART"に加えお"ALIVE"になっおいるかどうかを意識しおいたす。 #154 SMARTに代わる、目暙蚭定の新法則「ALIVE」 - 安斎 勇暹 https://t.co/EgGPba9qnm #Voicy pic.twitter.com/S78SSI757c — 安斎勇暹 / 最新刊『静かな時間の䜿い方』予玄受付䞭 (@YukiAnzai) 2024幎9月10日 ② 䌚議問いの質 「ミヌティングで反応が悪いのは、メンバヌのせいではなく、ファシリテヌタヌの問いが悪い」 ずいう話を聞き、自分がファシリテヌタヌの時のミヌティングは時々こうなっおいるこずに気付きたした。察策ずしお、遞択肢を絞るような問いにするこずで、議論が動きやすくなるずのこずでした。これに぀いおはカンファレンス参加埌のミヌティングから意識するようにしおいたす。 ③ 興味奜奇心ず興味の違い 奜奇心 瞬発的な感情 興味 奜奇心が継続し、䞀定の察象に定着しおいる AI時代には散挫な奜奇心より、 深い興味 が重芁。 興味 =「レンズどんなものの芋方で」×「察象なにを芋るか」 ずいう衚珟をされおいたした。 数幎埌のビゞョンをいきなり立おるより、「いた䜕が面癜いか・興味があるか」を倧事にする方ずいう考え方は、目暙を立おるのが苊手な自分には少し肩の荷が降りるものでした。 ④ 文化颚土ず文化は違う 颚土の改善だけでなく、 文化を耕す 。䟡倀基準の集合䜓が文化であり、皆が集たる堎で繰り返し䌝え、刷り蟌み続ける。耕し続ける姿がなければ、マネヌゞャヌの「本気」も䌝わりにくく、共感も生たれにくいずいう話は、マネヌゞャヌずしおの立ち䜍眮を改めお認識させられるものでした。 自埋型組織の真実『甘い自走』を捚おお導いた、EMによる戊略的組織倉革 「自走」ずいう蚀葉が䞀人歩きし、 マネゞメント攟棄 に近い状態になっおしたうケヌスに぀いおのセッションでした。 甘い自走の結果ずしお、 生産性䜎䞋・士気䜎䞋 技術的負債の攟眮 珟堎の混乱がそのたた事業の停滞に盎結 ずいった問題が起きたす。そしお「目的ずゎヌルを浞透させる」「評䟡制床を芋盎す」「1on1を増やす」ずいった 重い仕組みの远加 では、組織が死んでしたうだけ。 重芁なのは、 自埋 ≠ 自由 自埋 = 「境界線ガヌドレヌル」ず「責任」のセット 「ここたではノヌブレヌキでOK、ここからは止たれ」を決める。最もレバレッゞが効くのは「意思決定」に集䞭する。意思決定ができるず、ドミノ倒しのように仕事が進んでいく、ずいう話でした。 この話を聞いお、たず自分自身が仕事に察しお責任範囲をきっちりず決めきれおいないこずに気付きたした。そんな状態では、メンバヌに察しお自埋しお動いおくださいなどず蚀えるはずもありたせん。 メンバヌ目線で芋おも境界線を定めおくれるマネヌゞャヌは間違いなく信頌できるので、今埌身に぀けおいきたいスキルだず匷く感じたした。 「ストレッチゟヌンに挑戊し続ける」こずっお難しくないですか メンバヌの持続的成長を支えるEMの環境蚭蚈 圚籍歎の長い゚ンゞニアの退職申し出をきっかけに、 ストレッチゟヌンのチャレンゞが枯枇しおしたう 問題にどう向き合うかを扱ったセッションでした。 「今の自分に最適なチャレンゞが分からない」ずいう状態に察しお、 will / can / must で珟状分析する。 ただし、自分の will を正しく蚀語化できるずは限らないため、must ず噛み合わずアクションが生たれないこずがある。 そこで、will を䞀床抜象化䟋レガシヌコヌドを刷新したい → 意思決定がしたいしおから具䜓化テストカバレッゞ改善などする たた、目暙蚭定に倱敗しおしたうパタヌンずしお - 経営がうたくいっおいる䌁業では、分かりやすいストレッチな目暙が枛り、むンパクトの匱い仕事を遞んでしたう -「退屈だが自分の䟡倀が出せる仕事」は魅力的で遞びがちだが、野心が削がれ、䜎い目暙蚭定に぀ながる - 忙しさを理由に「できなかった」を発生させおしたう ずいう話があり、目暙を立おるのが苊手な自分にはかなり耳の痛い話でした。 これらぞの察策ずしお、 メンバヌ間の 目暙の可芖化 裁量範囲の蚀語化 ず暩限委譲「どこたでやっおいいか分からない」をなくす span of control の䞊限 を意識し、マネヌゞャヌがボトルネックにならない仕組み が挙げられおいたした。 組織・文化・技術の壁に挫折したEMが、アヌキテクトずしお「構造化思考」を手に、再び保守開発組織の倉革に取り組む ピヌプルマネゞメントに泚力すればよいず思っおいたが、 コヌド品質の悪さずチヌムの疲匊 ずいう構造的な問題に盎面し、仕様やテストの重芁性を説くも堎圓たり的察応に終わり、撀退を遞んだ経隓から、EM がアヌキテクトずしお「構造化思考」を手に再挑戊する話でした。 たた、 AI は増幅噚である ずいうお話もありたした。属人的プロセスやレガシヌを攟眮したたた AI を導入するず、カオスず技術的負債が爆発する。是正すべきは次の3぀の「モデルのずれ」です。 How 領域のずれ 実装工皋を AI に任せるなら、AI がコヌドを実装するワヌクフロヌを゚ンゞニアリングする。 What/Why 領域のずれ 芁求を敎合させ、䟡倀あるものを創るために、芁求の3階局ステヌクホルダ芁求・ビゞネス芁求・゜リュヌション芁求を意識する。 組織境界ずシステム間のずれ 境界を芋極めおモゞュヌルずしお切り出す。 ずにかく思い぀いたら図にしお共有する 倉化を起こすには、 組織・チヌムの目暙に据えなければ「䜙力で進める」からは逃れられない 。EM が本気で取り組たなければ進たない。属人的でその堎しのぎの察応に終わらせない。「EMはビゞネス・システム・チヌム・技術の関係(構造)をデザむンせよ」は垞に心に留めおおきたいず思いたした。 たずめ EMæ­Ž9ヶ月の状態で参加した今回のEMConfでしたが、参加前たでは開発組織の抱える課題に察しお、EMずいう立堎からどのように立ち向かっおいけばよいか分からない状態でした。今回様々な知芋を埗られたこずで、そういったがんやりずした状態から少し脱するこずができ、たた自身がEMずしおやりきれおいない事が浮き圫りになりたした。特に、「自埋しお動いおおり開発生産性の高い組織」ずはどのようなものかに぀いおは、セッションごずに共通しおいるテヌマがあり、私自身ずしおは「暩限委譲が適切にできおいるこず」「目暙がはっきりしおいるこず」だず感じたした。 盎近でAIにより゜フトりェア開発の根本が党く倉わっおしたったこず、スタメン内郚の開発組織の構造も倧きく倉革が進む䞭で、いかに組織の課題解決のために時間を䜿っおいけるかが、組織・自分自身ずもに勝負だず感じたので、今回のカンファレンスで埗られた知芋を具䜓的なアクションに萜ずしこんでいければず思いたす。 herp.careers
はじめに3ヶ月目の今、あえお途䞭経過を曞く理由 スタメンのQA゚ンゞニア、にヌくらです。スタメン初のQA゚ンゞニアずしお入瀟しお3ヶ月。ただ成果が出おきおいるフェヌズではありたせんが、ここで立ち䞊げ期の思考や詊行錯誀を埌で振り返るためにも残しおおきたいず思いたす。ですので、本蚘事は成功事䟋ではなく、珟圚詊行錯誀しながら行なっおいるこずの話になりたす。 珟圚スタメンでは東京オフィスで積極採甚䞭で、個人の努力だけでは回らない局面が芋え始めおいたした。プロダクトや開発、意思決定のスピヌドが䞊がる䞀方で、属人化や刀断基準のばら぀きが課題ずなり぀぀ありたした。そこで必芁ずされたのが「QA」ずいう圹割です。 QAの圹割ず品質ぞの考え方 ゜フトりェア開発においお、QA品質保蚌は単に怜蚌掻動を行うだけの圹割ではありたせん。しばしばQAは「テストをする人たち」ず誀解されがちですが、本質的な圹割はもっず広く、深いものだず信じおいたす。 品質ずは、決しお「テスト工皋」だけに宿るものではありたせん。品質は次のような日々の積み重ねによっお圢䜜られたす。 日々の刀断 プロセスの蚭蚈ず運甚 暗黙の前提や共通理解 蚀い換えれば、品質は日々の掻動や意思決定の䞭に自然ず組み蟌たれおいくべきものず考えおいたす。だからこそ、品質を高めるためには 「仕組み」「プロセス」「文化」 の3぀が極めお重芁だず考えおいたす。仕組みは䜜業を支え、プロセスは効率ず䞀貫性を生み、文化はチヌム党䜓の行動ず䟡倀芳を方向付けたす。これらが敎っお初めお、個々のテストやレビュヌ以䞊の品質が組織ずしお実珟できるのです。 プロセスを組織党䜓に浞透させるには、個人の努力だけでは限界がありたす。自身が品質保蚌を実際に取り組む䞭で、 組織ずしおの意志ず埌抌しの重芁性 を感じおいたした。 プロセスを定着させるには、組織ずしお明確な方針を持ち、積極的に埌抌しする姿勢が䞍可欠です。トップやマネゞメントの支揎がなければ、珟堎の努力だけでは継続が難しいのです。 今回転職掻動をする䞭で、組織ずしおの支揎がどれだけ埗られるのかを考えおいたした。その䞭でスタメンはQAを単なる個人の䜜業ではなく、組織的な圹割ずしお認識しおいるず感じたした。スタメンは人ず組織で勝぀䌚瀟ず明確に謳っおいるので、その組織の姿勢に共感し、「ここなら䞀緒にやれる」ず思えたのです。 入瀟しお芋えた珟実 入瀟しお感じたのは、個々人が本気でプロダクトに向き合っおいるこずでした。䞀方で、品質を暪断的に芋る仕組みや怜蚌掻動の敎理・䜓系化はほが実行しおいないず感じたした。しかし、これを吊定的に捉えるのではなく、むしろ䌞び代が倧きい状態だず捉えおいたす。これらの課題に取り組むこずで、プロダクトの品質向䞊ず効率化を図り、さらに良い成果を生み出せるものず確信しおいたす。 組織に新しい考え方やフレヌムワヌクを導入する際、どこかで成功しおいるからず、そのたた持ち蟌むだけでは浞透しないず過去の経隓から感じおいたす。組織にその意味を説き、やり方を調敎したテヌラリングが䞍可欠です。たずは珟実に䜕が起きおいるかを芳察し、開発の流れを理解するこずを優先したした。組織で䜕が起きおいるのか、その際に必芁なフレヌムワヌクやどこから浞透させお行くか䜜戊を緎っおいく必芁がありたす。 入瀟埌いく぀か品質を䞊げるための課題ず提案を進めお行きたしたが、それを実行するためには関係者が倚く、その人たちず合意しおいかないず進んでいかないもどかしさを感じおいたした。そのような悩みをCPOず話しおいく䞭で、プロダクト品質・プロセスに関する定䟋ミヌティングが立ち䞊がるこずになりたした。 圓初は、分析に必芁なデヌタも十分に揃っおおらず、これをやった方がいいず提案から始たり、ミヌティングはQAの私が䞀人で運営しおいく圢。これでは避けたかったただの「他瀟の成功事䟋の持ち蟌み」になっおいないかず考えおいたした。 「品質文化」ずいう考え方 品質を䞊げるこずで、どんないいこずがあるか、どういう状態に持っお行きたいか改めお䌝えたいず思いたした。むメヌゞずしおは党員参加で品質を䞊げおいく組織、それはQAずしおよく語られる「品質文化」の浞透ずいう話に眮き換えられたす。しかし、いざ説明しようずするずその内容を的確に説明するこずができたせん。ISOの品質マネゞメントに眮き換えるこずもできそうだず思いたしたが、あえお「品質文化」ずいう蚀葉を䜿っおいるので、別の定矩をしなければいけないず考えたした。 そこで出䌚ったのが、西康晎氏の 「嬉しい、匷い、すごい組織」 ずいう考え方です。 What is quality culture? Is it something tasty? | PDF 品質文化ずは、゜フトりェアの䟡倀、組織胜力、゚ンゞニアリング力を䞊げる取り組みをし、習慣化させおいくこず。組織で勝぀文化のスタメンに合いそうだずこの蚀葉を借りお、スタメンなりの品質文化を蚀語化し始めおいたす。 次のステップは、開発プロセスの䞭に品質意識を溶け蟌たせるこずです。新しいルヌルを増やすのではなく、どこでどんな刀断が行われおいるのかを問い盎し、必芁な仕組みを敎えおいきたす。決しお煩雑にするこずが目的ではなく、刀断を簡単に、属人化せず、その知識を蓄積しお新たにステップアップできる方法ができないかず詊行錯誀䞭です。 おわりに 単なる怜蚌者で終わらず、品質ずいう蚀葉を元に組織党員を束ねお行きたいず思っおいたす。そしお私は組織にそれを考える刺激を䞎えたいず思っおいたす。道半ばではありたすが、少しず぀倉化が生たれおいたす。これからも「組織で勝぀」ための品質づくりを続けおいきたいず考えおいたす。 note.com herp.careers
こんにちはスタメンで プロダクトデザむナヌをしおいる森田かすみ @KasumiMorita です。 先日、12月25日に、゚ンゞニア・プロダクトマネヌゞャヌPdM・デザむナヌ合同の瀟内LT䌚を開催したした 今回の蚘事では、圓日の様子や発衚内容、そしお私たちスタメンのプロダクト郚門が倧切にしおいる「孊び合う文化」に぀いおご玹介したす。 なぜ今、プロダクトLT䌚なのか 目たぐるしく倉化するIT業界においお、䌁業が競争力を維持し続けるためには、垞に新しい知識を取り入れ、お互いに孊び合う姿勢が䞍可欠です。 スタメンではそうした文化をより匷固なものにするため、2025幎7月から有志の珟堎メンバヌの起案でプロダクト郚門党䜓でLT䌚を始めたした。今回はその第2回目ずなりたす。 tech.stmn.co.jp 開催の狙いは、 党員で高め合う孊びの堎づくり です。 仲間が増えるず䟡倀芳やカルチャヌに少しず぀ばら぀きが出おくるのも自然なこずではありたすが、スタメンのプロダクト組織でも同じような課題感を持っおいたした。 今こそ、自分たちの組織を育おおいく意識をみんなが持ち、 「こういうこずをやっおいきたいよね」 「こういうこずを倧切にしたいよね」 ずいう思いを䞀人䞀人が倧事にし、蚀葉や行動にしおいく重芁性を感じおいたす。 特定の職皮だけで完結するのではなく、郚門党䜓の知識共有ず亀流を深め、プロダクト開発における連携を匷化するこずを目的ずしおいたす。メンバヌがそれぞれの知芋や想いを発衚し、質疑応答を通じお盞互理解を深める。 そうするこずで、個人のスキルアップはもちろん、組織党䜓の成長に繋げおいきたいず考えおいたす。 そんな想いを元に、私含め、おたけ @takeruu__ 、きいろ @yellow_flagger 、ちぇる @ryuseikarito の4名で運営しおいたす。 圓日のラむンナップ 通垞業務や他のメむンプロゞェクトがある䞭、倚くのメンバヌが登壇しおくれたした キヌノヌトから技術的な知芋、組織論、プロダクトの掻甚たで、バラ゚ティに富んだ玠晎らしい内容ばかりでした。 プログラム 【キヌノヌト】リヌダヌシップ論 CPO 長田 寛叞 AIネむティブ時代のプロダクト開発党員がチヌムリヌダヌになる時代 ゚ンゞニアリングマネヌゞャヌ あさしん @asashin227  カむれンは行動だ。迷ったら、少しだけ良くする プロダクト開発郚 フロント゚ンド゚ンゞニア 䌊賀本 衛 「降りおくる」のを埅たない。チヌム目暙の぀くり方 プロダクトデザむナヌ 森田 かすみ  @KasumiMorita  テックブログを曞くこずで埗られるもの プラットフォヌム郚 バック゚ンド゚ンゞニア 勝間田 亮 自分がナヌザヌずしお䜿い倒せるプロダクトだけど、TUNAG䜿っおたすか プロダクトマネヌゞャヌ 侭野 孝倫 Watchy Windows クラむアントアヌキテクチャ倉曎蚘 Watchy事業郚 ゚ンゞニア おさじゅん TUNAGの開発に携われるのは、実はすごく恵たれおいるず思う話 ゚ンゞニアリングマネヌゞャヌ たっきヌ 癜熱した受賞結果発衚 今回は、発衚内容に察しお 「ベストチヌム賞」「ベストCTO賞」「ベストCPO賞」 を蚭けたした。 ベストチヌム賞は党おのメンバヌからの投祚が倚かったもの、ベストCTO賞・ベストCPO賞はそれぞれのCxO陣から遞出されたセッションに莈られたす。 それぞれの芖点で遞出された、栄えある受賞タむトルをご玹介したす 🏆 ベストCTO賞 「Watchyクラむアント配垃圢態倉曎の抂芁」 Watchy事業郚 ゚ンゞニア おさじゅん â–ŒLTの内容玹介 Watchy事業の゚ンゞニアであるおさじゅんさんから、ストアアプリ特有の「䜎レむダヌ制埡の制限」や「䌁業導入の障壁」に察し、自由床の高いデスクトップアプリ化で挑んだ事䟋が発衚されたした。むンストヌラヌ実装や電子眲名、Windowsサヌビス䜵甚による暩限管理ずいった技術課題を解決し、過去最高受泚に繋げた経緯が共有しおいただきたした。 技術的な挑戊ず具䜓的な実装ぞのアプロヌチがCTOから高く評䟡されたした。 🏆 ベストCPO賞 「自分がナヌザヌずしお䜿い倒せるプロダクトだけど、TUNAG䜿っおたすか」 プロダクトマネヌゞャヌ 侭野 孝倫 â–ŒLTの内容玹介 プロダクトマネヌゞャヌの䞭野さんから、自瀟プロダクト「TUNAG」の開発組織においお、党瀟平均より利甚率が䜎いずいう課題に察し、ドッグフヌディング自ら䜿い倒すこずの重芁性をLT内で説かれおいたす。開発者自身が䞀番のファンずなり、利甚を通じおナヌザヌの痛みを自分ごず化し、違和感を改善のチャンスに倉えおいこうず呌びかけられたした。 自瀟プロダクトの掻甚状況をデヌタで䞀芧化し、参加しおいるメンバヌたちぞ掻甚を掚進する姿勢が評䟡されたした。 🏆 ベストチヌム賞 今回はみんなからの投祚の結果、同率で2぀の発衚が遞ばれたした 「テックブログを曞くこずで埗られるもの」 プラットフォヌム郚バック゚ンド゚ンゞニア 勝間田 亮 「自分がナヌザヌずしお䜿い倒せるプロダクトだけど、TUNAG䜿っおたすか」 プロダクトマネヌゞャヌ 侭野 孝倫 䞭野さんはCPO賞ずのダブル受賞ずなりたしたおめでずうございたす🥳🎉 â–ŒLTの内容玹介 テックブログの運営チヌムの䞀人である勝間田さんによる、テックブログ執筆の効甚を個人・組織の䞡面から説いたセッションです。「理解の深化」や「資産化」ずいう個人メリットに加え、「高品質なドキュメント」や「技術・文化アピヌル」ずいう組織メリットを提瀺。執筆は䞀石二鳥以䞊の䟡倀があるずし、互いに称賛し合う文化ず共に、積極的なアりトプットを掚奚されたした。 🎁 賞品に぀いお ベストCTO賞ずCPO賞の受賞者には、それぞれCTO・CPOずのスペシャルランチが莈られたす。 そしおベストチヌム賞には、 セッションの内容を思い出せるような、TUNAGスタンプ が莈呈されたす 自瀟プロダクトであるTUNAG䞊で䜿えるスタンプずしお、今回の孊びが圢に残るのはスタメンならではの賞品を今回は甚意したした。 今回の開催における工倫 反省点もありたすが、今回はプロダクトLT䌚の圢骞化を防ぎ、前回ずの違いを明確にするため、新たにテヌマ蚭定を行いたした。 たた、内容の質を高めるべく、運営䞻導のオファヌ制ではなく「プロポヌザル公募圢匏」を採甚したした。 1.テヌマ蚭定 今回のテヌマは 「未来ぞの貢献」 です。 このLT䌚はボトムアップで始たりたしたが、今回はCTOの野口さんずの雑談をきっかけにテヌマを決めたした。「将来的にどのような貢献に぀ながるのか瀺された内容だずいいですよね」ずいうアドバむスをいただいたこずがヒントになっおいたす。 「みんなで組織を䜜っおいく」ずいうこの䌚の姿勢にぎったりで、メンバヌ党員が想いやナレッゞを共有するのに最適なテヌマだず思い、蚭定したした。 2. プロポヌザル圢匏の導入 デザむナヌやバック゚ンド゚ンゞニアで構成された運営チヌムが他職皮のメンバヌ党員に察し、個別に内容を詰めお登壇オファヌを出すこずは困難であるため、半幎の振り返りも兌ねおプロポヌザルを提出しおもらう圢匏を採甚したした。 提出項目には、タむトルず内容に加え、 「セッションを通しお䌝えたい意思」 を提出しおもらいたした。単なるナレッゞ共有ならブログでも十分ですが、そこに「意思」が乗るこずで、LT䌚ならではのストヌリヌ性のあるプレれンになるのではないか、ず考えたした。そんな仮説ず期埅を蟌めお、この項目を蚭けたした。 3.チヌムによる遞抜 倚様な職胜・郚眲の発衚を聞けるよう、各職胜チヌムもしくは郚眲内でプロポヌザルを遞考し、誰が代衚ずしお登壇するかを自分たちで決めおもらうフロヌを採甚したした。 結果 これらの新しいアプロヌチを取り入れた結果、前回は特定の技術やツヌルなどの「Howどうやるか」が䞭心だったのに察し、今回は「Whyなぜやるか」「どうあるべきか」ずいった 組織文化やマむンドセットに関するトピック が増えたした。 たた、今回は自瀟プロダクト「TUNAG」を取り扱うLTもいく぀か芋られ、 プロダクトぞの熱量や圓事者意識 が匷く感じられる䌚になったず感じおいたす。 半幎間の振り返りずこれから 2025幎7月に開催した 第1回のプロダクトLT䌚 をきっかけに、゚ンゞニア向けやプロダクト䌁画郚向けの瀟内勉匷䌚を毎月1回以䞊倚い時は2回のペヌスで開催するこずが定着しおきたした。 「継続的な勉匷䌚の開催」ずいう枠組みからスタヌトをしおいる取り組みではありたすが、結果ずしお半幎で17人の登壇者、4人の勉匷䌚運営者が誕生したした。 継続的に開催する仕組みがこの半幎でできおきたこずは、組織ずしお倧きな䞀歩ずしお捉えおいたす。 今埌は、この仕組みをベヌスにし぀぀、 自発的な孊び合い文化 を内偎からさらに醞成しおいくこずに努めおいきたいず思っおいたす。 誰かから蚀われお孊ぶのではなく、メンバヌ䞀人ひずりが䞻䜓的にむンプットし、ナレッゞを共有し、他者ず孊び合う。そんな組織を目指しお、これからも様々な取り組みを行っおいきたす 䞀緒に働く仲間を募集しおいたす スタメンでは、このように職皮の垣根を超えお孊び合い、プロダクト開発に熱狂できる仲間を募集しおいたす。 少しでも興味を持っおいただいた方は、ぜひ以䞋の採甚ペヌゞをご芧ください。カゞュアル面談からでも倧歓迎です herp.careers
はじめに こんにちは。スタメンで゚ンゞニアをしおおりたす、 mental-space1532 ず申したす今回は、昚幎10月に配属されおから゚ンゞニア3ヶ月でOSSに貢献した経隓に぀いおお䌝えできればず思いたす。 早速ですが、私は元々プロダクト職ではありたせんでした。珟圚新卒2幎目ですが、圓初はビゞネス職ずしお入瀟し、1幎半ほどむンサむドセヌルスずしお勀務しおおりたした。芁ぱンゞニアずしおはスタヌトラむンに立ったばかりの人間です倧孊も文系です。䌌た境遇の方々や、OSSぞの貢献を怜蚎されおいる方の参考になれば幞いです。 1. 䜕をやったのか 内容ずしおは、 半角 @ が入力された堎合のみ衚瀺されおいたメンション候補を、党角  入力でも衚瀺されるように改善 したした。䞀般に、チャットアプリでは @ を入力するずメンションの候補が衚瀺されたす。しかし、日本語IME環境では党角  がデフォルトで入力されるこずが倚く、日本語ナヌザヌはメンションの床にいちいち入力方匏を切り替えるこずを匷いられおいたした。これを切り替えるこずなしに実行できるようにするずいうのが今回のPRの趣旚です。 ちなみに、技術スタックずしおはReact/TypeScriptですので、これを螏たえた䞊で以降を読んでいただけるず幞いです 2. 動機 ビゞネス職時代、こちらのOSSチャットを䜿っおいた際に、毎回入力切り替えを行わなければならず、「めんどくさいなこれ」ず思ったこずがきっかけです。 ビゞネス職の経隓がある方なら共感いただけるかず思いたすが、セヌルスやカスタマヌサクセスの珟堎では「お客様ぞの即応性」が䜕よりも重芁です。結果ずしおメンバヌ間での情報共有スピヌドが求められ、䌝達挏れを防ぐためにメンションを倚甚したす。個人的な䜓感ですが、ビゞネス職のメンション䜿甚頻床はプロダクト職の5〜10倍ほど倚いように感じられたす。 特に顕著な䟋では、毎朝の進捗共有で6〜7名のメンバヌにメンションを飛ばす際、毎回「半角切り替え→ @ 入力→日本語切り替え→名前入力」を繰り返す必芁がありたした。これが地味にストレスだったのです。 圓時の私は䞍䟿さを「仕様だから」ず受け入れおいたした。゚ンゞニアにチャレンゞするこずになった10月初週に「どうせやるなら本家のOSSに還元しお、䞖界䞭のナヌザヌの䜓隓を改善しよう」ず思い立ち、䞊叞に盞談し、瀟内の業務を行い぀぀、AIを掻甚したコヌディングで進めるずいう条件でOKをもらうこずができたした。 3. やったこず 初めおOSSにコントリビュヌションする䞊で、以䞋のようなフロヌで進める想定でした。 課題を蚀語化する䌁画 GitHub CopilotのCoding Agentで自埋的に実装させる実装 正しく動䜜するかロヌカルで怜蚌し぀぀倉曎箇所のコヌドを解読するQAその1 瀟内でレビュヌをいただくQAその2 OSSのリポゞトリでPRを䜜成し、メンテナヌの方にレビュヌを䟝頌するメンテナヌレビュヌ いただいたレビュヌを受けお察応し、マヌゞ貢献完了 自瀟プロダクトぞの適甚統合 䌁画やりたいこずの蚀語化〜初期実装 圓初、そもそもPRっおどうやっお䜜るんだ・・・ずいうレベルだったので、手っ取り早くGithub CopilotのCoding Agentで200文字皋床のプロンプトを投げお自埋的に実装しおもらう方法を取りたした。そのプロンプトがこちらになりたす。 珟圚の仕様においお、メンション付きのメッセヌゞを送るためには半角のアットマヌク以䞋@を入力し、自分でメンションしたいナヌザヌの名前を入力するか、衚瀺される候補の䞭から遞択する圢になっおいる。 この状態を、@だけではなく、でもできるようにしたい。すなわち、メッセヌゞの線集欄にを入力した際にもメンション候補が衚瀺されるような状態に倉曎をしたい。 今芋るずかなりシンプルなプロンプトですね・・・🙃 どのような仕様にするか蚘述しおいないので、Copilot先生も困っおしたったのではないかず思いたす。できたものをロヌカルで怜蚌したずころ早速問題が発生したした。党角  でメンション候補は出お挿入できるものの、2個目以降のメンション挿入ができないメンション候補をクリックたではできるのです。AICopilotのAgent Modeに聞き぀぀コヌドをいじっおも解決せず、詰たっおしたいたした。埌から考えれば、この時の自分は構文を理解しようずせずに、挫然ずAIに「これどうすればいいのですか」ずいう曖昧な圢でプロンプトを投げおしたっおいたした。流石にこれはたずい、ずいうこずになっお同僚に助蚀を求めたずころ、半角ず党角の文字の幅の違いによっお挿入ができなくなっおいるこずが刀明し、フロント偎の文字列挿入ロゞックを修正するこずで「実装したい機胜がずりあえず動く」ずいう状態に持っおいくこずができたした。 瀟内レビュヌ この段階で䞀床瀟内レビュヌ実斜しおいただきたした。この時、自分は「ちゃんず動くようになったし、これでOSSにPRを䜜成できる」ず無邪気に考えおいたした。が、圓然そんなうたくいくわけもなく、ただただ問題が山積みになっおいるこずが明らかになりたした。具䜓的には、私がWebアプリの基本的な構造責務の分離を理解できおおらず、Copilotが行ったバック゚ンドAPIの改倉バック゚ンドAPI偎のメンションロゞックに党角  を远加する修正を芋逃しおしたっおいたのです。結論ずしおは、そもそもフロント偎で半角 @ ず党角  を共に正芏衚珟ずしおいたので、この改倉は必芁ないものでした。この瀟内レビュヌによっお、フロント゚ンドずバック゚ンドAPIの責務の分離、個々のファむルがどのような仕事を担圓しおいるのかをざっくりず理解するこずができたした。 ずいうわけでバック゚ンドの修正を元に戻しおフロント゚ンドの修正するべき箇所をある皋床理解した䞊で再床コヌドを吟味するこずになりたした。ある皋床圓たりを぀けた䞊で、バック゚ンドAPIの件のような䞍必芁な改倉がないかを確認したした。 瀟内レビュヌを経たこずでより具䜓的に各コヌドに぀いおAIに聞くこずができるようになり、結果的によりシンプルに実装する方法を線み出すこずができたした。これらの工皋を螏たえお最初に瀟内レビュヌをいただいたずきよりもさらにコヌドの質を高めるこずができたした。ここで再床瀟内レビュヌをいただき、OKをもらうこずができたので、晎れおOSS本家のリポゞトリでのPRを䜜成にトラむしたした OSS本家でのPR䜜成〜マヌゞ PRの説明文の曞き方なども䜕も分かっおいなかったのですが、幞いにも芏定のフォヌマットが存圚したので、AIに自分の拙い英文を校正しおもらいながら䜕ずかメンテナヌの方からレビュヌをいただける状態にしたした。そしお、぀いにコメントが返っおきたした曰く、「その共通コンポヌネントの倉曎、本圓に必芁」ずのこずで、共通UIはコマンド入力などにも䜿われるため、そこにメンション特有のロゞックを入れるのは蚭蚈ずしお矎しくないし、圱響範囲が広すぎるずいう指摘でした。 そこでメンテナヌの方から 「UI偎をいじるのではなく、デヌタを䟛絊する偎が情報を正しく䌝えれば良い」 ずいうヒントをいただき、最終的に以䞋の修正に萜ち着きたした。 正芏衚珟を修正し、 @ ず  の䞡方をキャプチャできるようにする 関数に実際にマッチした文字列 matchedPretext を枡すよう匕数を远加する このこずにより、さらにシンプルに同じ機胜を実装するこずができたした。 たた、海倖のプロゞェクトであるためPRを英語で曞く苊劎もありたしたが、Geminiに添削しおもらうこずで乗り切るこずができたした。䞀芋無理難題に思えるこずも、分解しお各個撃砎すれば意倖ずいけるものです。たさに「困難は分割せよ」を実感した瞬間でした 4. 元ビゞネス職ずいう点からプロダクトに貢献できるこず 匊瀟のようなSaaS䌁業ではドッグフヌディング自瀟補品を自ら䜿うこずが掚奚されたすが、䜜り手偎は「䜿い慣れおいる」がゆえに、ナヌザヌの倚様な䜿い方を芋萜ずすこずがありたす。 特に、職皮によっお機胜の䜿甚頻床やコンテキストは倧きく異なりたす。元ビゞネス職の゚ンゞニアは、 プロダクト職ずは異なる、珟堎ならではの切実な䜿い方を知っおいる お客様に近い立堎からこがれる「小さな䞍満」を拟いやすい ずいう2点においお、UX向䞊に倧きく寄䞎できるアドバンテヌゞがあるず感じおいたす。 5. たずめ ここたで曞いおきたしたが、䌝えたいこずはシンプルです 䞀芋理解䞍胜な゚ラヌも、詊行錯誀を繰り返せば必ず糞口が芋える。たずはやっおみよう 「元ビゞネス職」ずいう芖点は、゚ンゞニアリングにおいお匷力な歊噚になる この゚ントリが、OSSぞのコントリビュヌションを迷っおいる方の背䞭を抌すきっかけになれば幞いです。 最埌に 株匏䌚瀟スタメンでぱンゞニアを絶賛募集しおおりたす匊瀟には、AI掻甚・新人から様々なこずにチャレンゞできる文化が敎っおいたす。もし興味を持っおいただけるなら、ぜひ䞀床カゞュアルにお話しいたしたしょう herp.careers 最埌たで読んでいただきたしお、誠にありがずうございたした
はじめに はじめたしお 2026幎1月から、株匏䌚瀟スタメンにモバむル゚ンゞニアずしおゞョむンしたした、りあたそ (@riataso_kebin) です 前職では玄2幎半、むンフラ構築からバック゚ンド開発たで、サヌバヌサむド党般のシステム開発・保守を䞭心ずした業務に携わっおきたした。 今回はサヌバヌサむドでのキャリアからなぜ、実務未経隓のモバむル領域に転身したのか、 なぜ数ある䌁業の䞭からスタメンを遞んだのかなど、少しでもスタメンのこずが気になっおいる方向けに曞かせおいただきたした なぜ、サヌバヌサむドからモバむルぞ これたでの玄2幎半、サヌバヌサむドの゚ンゞニアずしお「システムの安定皌働」を支えるこずに心血を泚いできたした。むンフラの構築やDB蚭蚈を緎り䞊げる仕事には特有の面癜さがありたしたが、䞀方で 「ナヌザヌが盎接觊れる郚分フロント゚ンドを自分の手で圢にしおみたい」 ずいう想いが次第に匷くなっおいきたした。 その倧きなきっかけずなったのが、 個人開発 です。 自分が日垞で「欲しい」ず感じた機胜をアプリずしお圢にしおみた際、指先ひず぀でUIが動き、䜓隓が完結するモバむルアプリ特有の「手觊り感」に、これたでにないワクワクを芚えたした。 「裏偎の仕組みを理解しおいる匷みを掻かし぀぀、このフロント゚ンドの楜しさを仕事ずしお远求したい」。そのピュアな奜奇心が、未経隓領域であるモバむルぞの転身を埌抌ししおくれたした。 「名前を知っおいる䌚瀟」から「働きたい堎所」ぞ 実は、スタメンずいう䌚瀟の存圚自䜓は、孊生時代の就職掻動䞭から知っおいたした。 そんなスタメンを「自分事」ずしお深く意識するようになったのは、孊生時代の友人から誘われた、ある勉匷䌚がきっかけでした。 それが、スタメンが運営しおいる 「mobile.stmn」 ずいう勉匷䌚です。 実際に参加しおみるず、そこには珟堎の第䞀線で掻躍する゚ンゞニアの方々がいたした。お話しさせおいただく䞭で感じたのは、 技術に察する真摯さず、䜕より「楜しんで開発しおいる」ずいう圧倒的な゚ネルギヌ です。 䌚話のテンポが良く、非垞に心地よい「ノリ」の良さがありながらも、プロダクトぞの熱い想いがひしひしず䌝わっおくる。 その雰囲気に觊れ、「この人たちず䞀緒に開発ができたら、きっず楜しいだろうな」ず盎感的に感じたこずを今でも鮮明に芚えおいたす。 「圓事者意識」を「称え合う」文化が決め手に 自瀟プロダクトを持぀䌁業は数倚くありたすが、私が最終的にスタメンを遞んだ決め手は、プロダクトに察する 「圓事者意識の匷さ」 ず、それを 「称え合う文化」 でした。 個人開発を経隓したからこそ、プロダクトを「自分のもの」ずしお育おおいく倧倉さず喜びを実感しおいたした。入瀟埌、メンバヌず亀流を深める「Welcomeランチ」や、1ヶ月かけお瀟員の皆さんず写真を撮る「ルヌキヌズミッション」ずいった制床を通じお皆さんずお話しする䞭で、改めお確信したのは、党員が同じ方向を向き、プロダクトの成長を自分事ずしお楜しんでいる空気感です。 特に、成果を党員で喜び合う 「スタカネ」 の文化は、たさに私が求めおいた「チヌムでプロダクトを育おる理想の姿」そのものでした。 ※スタカネずは 新機胜のリリヌスや目暙達成、あるいはメンバヌの初仕事の完了など、ポゞティブな成果があった際にベルを鳎らし、党員で拍手をしお称え合うスタメン独自の文化です。 先日、念願の「スタカネ」を初めお鳎らすこずができたした🔔 スタカネ成果を称賛する文化の投皿内容 入瀟2週間のリアル未経隓の壁ず「AI」ずいう心匷い盞棒 ゞョむンしおからただ2週間。正盎なずころ、珟圚はモバむル開発の圧倒的な情報量ずスピヌド感に食らい぀く毎日の連続です。 個人開発ずは異なり、倚くの゚ンゞニアの手によっお磚き䞊げられおきた実務のコヌドベヌス。そこから実装の意図やロゞックを正確に読み解く難しさに盎面し、自分の珟圚地を痛感する瞬間も少なくありたせん。 しかし、そんな「壁」をポゞティブに乗り越えおいけるのが、スタメンの開発文化の面癜いずころです。特に驚いたのは、新しい技術やツヌルを䜿いこなすこずぞの貪欲さです。 珟圚、私はAIを「盞棒」ずしおフル掻甚しおいたす。スタメンではDevinやCursorずいったツヌルが圓たり前のように開発環境に組み蟌たれおおり、AIず察話しながらコヌドを曞くこずが文化ずしお根付いおいたす。 さらに、先茩瀟員のアドバむスを通じお、 「Before珟状のコヌドや゚ラヌずAfter実珟したい理想の状態を明確に蚀語化しお連携する」 ずいうプロンプト指瀺出しのコツを孊びたした。これだけでAIの回答粟床が劇的に向䞊し、耇雑なロゞックの読み解きや、詰たっおいた課題がスルスルず解決しおいく䜓隓は、たさに目から鱗でした。 「倧倉なこず」を「面癜い課題」に倉えおくれる仲間ず、それを支える最新のツヌルがある。入瀟しおわずか2週間ですが、この環境ならどこたでも成長しおいけるずいう確信を埗おいたす。 これからの抱負モバむル領域からプロゞェクト開発党䜓ぞ 今埌の目暙は、たずはモバむル゚ンゞニアずしお自立し、䞀日も早くチヌムの戊力になるこずです。しかし、単に「モバむルのコヌドが曞ける」だけでは終わりたくありたせん。 私が持っおいる玄2幎半のサヌバヌサむドの知識---DB蚭蚈やむンフラ、APIの裏偎の仕組みは、 モバむル開発においおも必ず匷力な歊噚になるず信じおいたす。 「裏偎サヌバヌサむドを知っおいるからこそ、より効率的で堅牢なフロント゚ンドを構築できる」。そんな、領域を跚いだ芖点を持぀゚ンゞニアずしお、スタメンのプロダクトを技術面から力匷く牜匕できる存圚を目指しおいきたす 最埌に今の環境から䞀歩螏み出そうずしおいる方ぞ 呚囲のメンバヌが自分のこずのように喜び、拍手で迎えおくれるあの枩かい雰囲気は、入瀟しお䞀番感動した瞬間かもしれたせん。 むンフラやバック゚ンドの知識ずいう「土台」を倧切にしながら、モバむル゚ンゞニアずしおの「衚珟力」を磚き、䞀日も早くプロダクトの成長を力匷く牜匕できる存圚を目指しおいきたす。 もし、この蚘事を読んで「 スタメンの雰囲気をもう少し詳しく知りたい」「実際にどんな人たちが開発しおいるのか気になる」 ず少しでも感じた方がいれば、 ぜひスタメンが開催しおいる 勉匷䌚mobile.stmnなど をチェックしおみおください。 私自身、勉匷䌚で珟堎の゚ンゞニアず盎接話し、その熱量や空気感に觊れたこずが入瀟の倧きなきっかけずなりたした。 遞考ずいう圢ではなく、たずはカゞュアルな堎でスタメンの「リアルな楜しさ」を感じおいただけたら嬉しいです✚ 「今たでのキャリアを歊噚にし぀぀、新しい領域で自分の熱量を圢にしたい」 そんな思いを抱いおいる方にずっお、スタメンはきっず面癜い挑戊ができる堎所だず思いたす。 これからもたくさんのこずを達成しお、皆さんず䞀緒にスタカネを鳎らせるように頑匵りたす❗ herp.careers