トーク

エンジニアは技術的負債、レガシーコードの刷新、そしてリポジトリの統合といった、避けては通れない大規模なリファクタリング課題に直面します。

私はMOSHというクリエイター向けプラットフォームの開発において、8年近く運用されてきた（自らが積み上げた）負債「旧リポジトリ」の撲滅という大きな挑戦に直面しました。

膨大なコード量、複雑に絡み合った依存関係、そして不足したドキュメント。
従来の手法では数年かかると思われた作業を、AI（Claude + Cursor）とのペアプログラミングによって約100日で完遂しました。

この取り組みを通じて、「AIは単なる補助ツールではなく、最高のペアプログラミングパートナーであり、心の友である」という確信を得ました。

本セッションでは、AIの活用術ではなく、私がなぜ「旧リポジトリからもう逃げない」と決めたのか。

AIという存在がそれを可能にしてくれたわけですが、なぜその意思決定をすることができたのか。

10年近く前のコードに対する私の恐怖をどう変えたのか。

実コードと実データ、そして率直な失敗談を交えて語ります。

レガシーコードから目を背けてきたエンジニア、技術的負債の返済を諦めかけているチーム、そしてAIが開発組織の意思決定をどう変えるのか知りたいリーダーにとって、明日からの判断基準を変える内容を提供します。

エンジニアは新規技術の採用や組織課題など、さまざまな問題に直面します。

私は LINE API を利用した新規プロダクト開発や技術組織の拡大に伴う課題に直面した際、LINE Developers Community や EM Oasis といったコミュニティに参加することで活路を見出してきました。
そして、活動は課題解決に留まらず、現在は LINE API Expert としての初学者支援や EM Oasis の運営という形で、コミュニティへ貢献する活動へと繋がっています。

これらの経験は、「コミュニティがエンジニアの成長と課題解決に極めて有効である」という確信を与えてくれました。

本セッションでは、この実体験に基づき、以下の実践的なプロセスと技術を解説します。

• 課題発生から解決の糸口を見つけるまでのプロセス
• コミュニティ内で信頼を得て、より深い情報を得るための技術
• インプットをアウトプットに繋げ、自身の専門性を確立する方法

私がなぜ技術的な課題に直面した際にコミュニティに参加をするのか、私はなぜ課題が解決した今でもコミュニティ活動を続けているのか、LINE API Expert や EM Oasis 運営の活動を通して何を感じているのか、実体験を元にコミュニティ活動の素晴らしさを語りたいと考えています！

技術コミュニティへの参加を検討している方、また既に参加しているがより効果的に活用したい方にとって、具体的な行動指針となる内容を提供します。

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

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

主な内容

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

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

技術スタック選定

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

冪等性設計の技術判断

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

聴講者が得られる価値

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