プロポーザル

YoY300%成長のクリエイター向けオールインワンプラットフォームの成長に伴い、複数プロダクトでの通知機能共通化が急務となりました。
メール・LINE・アプリ内通知を統一基盤として提供しつつ、将来の事業拡大を見据えた拡張性と、ミッションクリティカルな通知の確実な配信を両立する必要がありました。

本セッションでは最終的なインフラ・アーキテクチャ構成を共有したのち、その設計の過程でどのような制約や判断軸の中で候補として上がった技術について触れてなぜそれを採用しなかったのかという生々しい設計のリアル話をお伝えるすることが出来ます。
作成した成果物やその結果を伝えるセッションではなく、そこに至る技術的な判断や思考をみなさんに共有して今後の設計に役立つようなものにしたいと考えております！

主な内容

マルチプロダクト戦略での基盤設計思想

• なぜ通知を共通化したのか、将来を見据えた設計判断
• 今後様々なプロダクトが利用することを考慮した責務の分離とインターフェイスの設計についてどう考えたか

技術スタック選定

• StepFunctions vs SQS/SNS vs Fluent での可用性・柔軟性・一覧性との比較
• DynamoDB vs RDS vs Redis - 冪等性におけるデータストアの検討
• TypeScript統一による認知負荷軽減の判断

冪等性設計の技術判断

• DynamoDB条件付き書き込みによる排他制御の選択理由

聴講者が得られる価値

• マルチプロダクト環境での共通基盤設計における技術選定の判断基準
• 高可用性システムでの冪等性実装における具体的な技術選択肢と評価軸
• 将来の拡張性と現在の要件のバランスを取る設計判断の考え方

PoC段階では新技術を使って、楽しいですが本番運用するにはPoCとは違って考えることがたくさんあります。
AI関連の話が乱雑になっていてたくさんの会社でPoCを開始していると思うので、決め手となるのは本番運用に載せたときのメリットデメリットの話だとおもっていますので、今一度基本に戻ってはいかがでしょうか？っということで話そうと思います。

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■こんな人におすすめ
・企業内でGitHub導入・統合・再編をリードするDevOps／プラットフォーム担当
・既存GitHub資産を落とさず移行したい技術責任者・PM
・Copilot導入を見据え、まず基盤とガバナンスを整えたい方

■前提知識
・GitHub Enterpriseの基本概念（Org／Repo／Teams／Policies）の基礎理解（薄くでOK）
・IaCやCI/CDの一般知識があると理解が早い（なくても可）

■持ち帰れること
・「計画 → 解析 → 検証 → 本番」の実務フレーム＆チェックリスト
・GEI／Migration Analyzer／gh-repo-statsの使いどころと限界
・“移せないもの”の代表例と代替策（再作成・自動化・割り切りの判断）
・EMU移行時のセキュリティ／ガバナンス観点（ID、監査、ポリシー）の勘所

■発表者プロフィール（短）
外資系コンサルのDevOpsエンジニア／マネージャー。GitHub Stars。GitHub Enterprise／EMUの導入・統合・運用、Copilot展開、監査ログ連携やセキュリティ統制の実装支援に従事。

『薬屋のひとりごと』（以下「薬屋」）に出てくる主人公・猫猫（まおまお）の問題解決の進め方をヒントに、システム障害対応を分かりやすく整理したものです。

薬屋は、薬の知識を持つ少女が後宮で起きる毒や病の理由を探る物語です。やっていることは「状態を観察→原因候補を考える→確かめる→再発を防ぐ」で、これはまさにシステム障害対応と同じ流れです。
猫猫のやり方に当てはめてシステム障害を解決に導く流れを楽しく学んでいきましょう。

なお、原著作物のストーリーや独自文章などに配慮して特定のシーンは扱いません。アニメなどを視聴した前提での話とさせていただきます。

ITエンジニアとしてのキャリアは、技術スキルだけでなく「どんな選択をするか」によって大きく形が変わっていきます。
どの技術を学ぶか、どんなコミュニティに飛び込むか、そしてチャンスが目の前に来たときに一歩踏み出すかどうか。
その一つひとつの選択が、自分のキャリアを作り上げていきます。

私は、Microsoft技術との出会いをきっかけにキャリアが大きく動き出しました。
コミュニティでの学びや仲間との交流が新たな視野を開き、Microsoft MVPを受賞することで次の扉が開きました。
そこからさらに挑戦を続け、現在はアバナード株式会社でDirectorという立場に至っています。

このセッションでは、私がどのように選択を重ね、どのような失敗や葛藤を経てチャンスを掴んできたのかを、リアルな体験談としてお伝えします。
いつもは.NETやMS技術系のテーマでしたが、今年は自身のふりかえりをかねてソフトスキル系のお話をさせていただこうかと思います。
エンジニアとして成長の道を模索している方、次のキャリアステップを考えている方に、キャリアを切り拓くための「勇気」と「ヒント」を持ち帰っていただければと思います。

BuriKaigi 2025では「2024年のWebフロントエンドのふりかえりと2025年」について話しました。
https://www.docswell.com/s/sakito/Z82RGP-burikaigi2025

話の中では、2025年のフロントエンドはどうなっていきそうかの推測もしていました。

今回は2024年の推測が当たっていたのか、2025年を振り返りつつ話をします。
そして、2026年のフロントエンドがどうなっていくのかも考察していきます。

■テーマ
バグバッシュを「品質保証」「学習」「共通理解」を同時に生む場として用意し、開発者がリリース対象機能を必ず自分の手で操作してから出す運用を紹介します。
不具合発見に留めず、多職種が操作を共有しながら触ることで、仕様意図・前提のズレをその場で解消し、プロダクト理解とチームの合意形成を加速させます。

■想定する参加者層
初心者向け

■トーク概要
バグバッシュ（Bug Bash）とは、プロダクトの品質向上のため、職種を問わずチームメンバーが集合して、指定期間内に意図的にバグ（不具合）を見つけ出すイベントです
本LTは、バグバッシュを「品質保証」「学習」「共通理解」を同時に生むイベントとして定義します。
開発者・プロダクトオーナーなど異なる役割が一堂に会し、実際にプロダクトを発話しながら操作することで、仕様意図や前提のズレをその場で解消し、個人に依存しない検出力と“使われ方”の相互学習を生み出します。
さらに、開発メンバーがリリース対象機能を必ず自分の手で操作してから出す運用をリリースゲートとして組み込みます。
これにより当事者意識とUX理解が開発プロセスに定着し、「納得して出す」文化が醸成されます。
鰤が群れで回遊して身を太らせるように、プロダクトも群れ（多職種）と手触り（ハンズオン）で育つ。
その設計と運営の要点と実践内容を共有します。
「プロダクトを育てる」ことに真正面から向き合うチームに向けた実践です。

ローコードやノーコードサービスが台頭して久しい昨今、組織によっては、様々なローコードやノーコードのサービスが統制なく使われているといった現状も存在します。
そんな折、
「どちらがいいのか？」「どちらかに寄せるべきなのか？」
と、聞かれることがよくあります。

ここでは、Microsoft 365 を主軸に活用しつつも、Power Platform と kintone が混在する組織の中で、どういう構成であれば最適な組み合わせとなりうるのか、ロールプレイング的なセッションとして、デモを交えながら解説していきます。

デモの内容

Power Apps with AI Builder x kintone で
極力オペレーションを減らした 在庫管理システム
https://x.com/Rinatamu_ITDR/status/1982679540712505828
など

※本内容は Cybozu Day 2025 で軽くお見せする内容をもっと深堀した内容となっています。
※本内容は業務担当者や開発者、DX推進者など幅広い層に見ていただける内容です。