概要

ソフトウェア設計を学び始めたとき、設計原則として「責務を分けよう」「疎結合にしよう」と言われても、実際にどのような設計・実装をすればよいのか、具体的なイメージが湧きづらいと感じたことはありませんか？本セッションは、マインスイーパという身近なゲームを題材に、具体的な設計とコードを通じて、これらの設計原則への解像度を高める体験を提供します。

マインスイーパには、セルやその状態、ボード（座標平面）、プレイヤー操作、難易度など様々な概念が存在し、設計を思考しながら学ぶ題材として適切なゲームであると考えています。セルの開封のように単純なロジックに見えても、「セルは状態を持つのか？」「セルは座標平面に依存するのか？」「セルからその近傍のセルを隠蔽するべきなのか？」など考慮点が多く、設計次第でコードの拡張性や可読性が大きく変わります。

本セッションでは、そんなマインスイーパをRubyによる純粋なオブジェクト指向で設計していきたいと思います。主な設計トピックは下記の通りです。

• 責務の境界線を定義し、情報隠蔽をする
• 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す

これから設計を学びたい初学者や、日々の業務で「なんとなく設計している」中級者に向けて、責務と疎結合への解像度を高め、もう一歩深く設計を理解するヒントを持ち帰れるセッションを目指します。

詳細

対象とするターゲット

• 初学者
  • AIに設計を任せ切ってしまっている方
  • 設計の指針を持てていない方
  • 設計の技術書籍を読んで学んだが、あまりピンと来ていない方
• 中級者
  • 設計の技術書籍を読んで学んだが、より実践的に学びたい方
  • Ruby on Railsなどのフレームワークに従っての設計はできるが、そのレールからはみ出た設計に自信のない方
  • GoFのデザインパターンなどを学んだが、暗記になってしまいその本質が掴めていない方

トーク構成

• マインスイーパとは(3min)
  • ルール
• ER図の全体像(2min)
  • クラス図
• セル(3-4min)
  • 責務の境界線を定義し、情報隠蔽をする
    • 座標平面に依存する？
    • 状態を露出させる？
• セルの近傍(4min)
  • 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• グリッド(3min)
  • 二次元配列を隠蔽する
• グリッドのファクトリ(3min)
  • シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す
    • 複雑なロジックは隠蔽し、シンプルなインターフェースでグリッドを作成するインターフェース
    • シンプルファクトリパターン
• マインスイーパークラス(3min)
  • 多数のモジュールを利用するメインモジュール
• テスト容易性(3min)

このトークの意義

昨今のAI時代において、私は初学者がAIに取って代わられないために重要なのは「設計」であると考えています。 しかし同時に、初学者がその設計力を育む経験を得づらい環境に置かれていることを危惧しています。

インターフェースを定める「設計」と、その実体である「実装」を比較したとき、事業へのインパクトがより大きいのは明らかに「設計」です。実装は情報が適切に隠蔽され、副作用がなければ容易に差し替え可能ですが、設計は他のモジュールにも波及し、システム全体の構造を左右します。

しかし近年、AIネイティブ世代の初学者が、この重要な「設計」までもAIに全面的に委ねてしまう傾向があると感じています。答えが定まらない中でも試行錯誤し、概念を言語化しながら思考を深める、そうした経験を経ずに、AIに舵を預けてしまっているのです。

私はその原因を、初学者が「設計のポイント」や「思考の取っかかり」を持たないことにあると考えています。

本トークは、そうした初学者の方々に対し、設計を自ら考え始めるための“思考の種”を提供するものです。設計入門の資料は数多くありますが、本トークでは具体的な事例と思考プロセスの両面から、より実践的に「設計」を掘り下げます。

【テーマ】
・ Amazon Simple Email Service（以下「Amazon SES」）でのメール受信についての話

【想定する参加者層】
・ Amazon Web Service（AWS）を扱っている方（主に業務で）
・ Amazon SESを扱った経験、およびAmazon SESでのメール受信の経験は不問です。（経験がない方でも十分理解できる内容となっています）

【トーク概要】
AWSでメールを扱う際にAmazon Simple Email Service（以下「Amazon SES」）を使用することが多いと思います。
「メール送信は経験があるが、受信についてはなかなか扱うことが少ない」という方もいるかもしれませんが、2023年に東京リージョンでもAmazon SESがメール受信に対応したことで、これからAmazon SESでのメール受信に対応するケースも増えてくると思います。

そして受信メールはAmazon SNS/AWS Lambda/Amazon S3で扱えるのですが、これらサービスごとの仕様・制約が大きく異なっており、ビジネスアプリなどで受信メールを扱うのはなかなか一筋縄ではいかないのも事実です。

そこでこのセッションでは、実際に私がAmazon SESでのメール受信をビジネスアプリに組み込んだ経験から
・ Amazon SESでのメールの受信方法
・ Amazon SNS/AWS Lambda/Amazon S3それぞれで受信メールを扱う際の注意点
・どういうケースでどの手法を選択するのが良いのか

などについてお話したいと思います。

【セッションゴール】
・ Amazon SESについて、「受信メールの受信方法」および「受信メールを扱うサービスごとの仕様・制約」を理解できるようになる
・ ビジネスアプリにAmazon SESでのメール受信を組み込む際に「どういう点に気を付けた上で、どういうケースでどの手法を選択するのかが良いか」がある程度理解できるようになる

テーマ

Monorepoによるパッケージ境界と依存の再設計

想定する参加者層

フロントエンドのMonorepo移行を検討している中級者

トーク概要

複数のサービスを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？
本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合を起点に進めたリアーキテクトを紹介します。
パッケージの責務境界を見直し、共通コンポーネントと依存関係を整理することで、開発体験を改善しました。
Monorepoへの統合プロセスとツール選定から、責務分離を軸にしたアーキテクチャ再設計の手法まで、実践的なヒントをお届けします！

みなさん、アウトプットしてますか？ブログ執筆やカンファレンス登壇など、エンジニアにはアウトプットの機会が他の業種に比べて多くあると思います。情報は発信する人の周りに集まる、という言葉もあるように、アウトプットをすることによる良い効果は多く存在します。

とはいえ、世の中の全エンジニアがアウトプットをすべきかと言われると、それはまた違うと思います。他人に強いられてやるものではないし、好きじゃないと続かない行為だと思います。しかし、ハマる人には超ハマります。

私は今までで約100本のブログ記事の執筆と14回の登壇をしてきました。アウトプットに対する私のモチベーションとアウトプットがもたらす良い効果についてお話しします。

生成AIがテストを自動作成し始めた際、実装＝テストで実装され潜在的不具合を含んだまま、とりあえずテストが存在するみたいな状況が多くなってきたのではないでしょうか？
今一度単体テスト/結合テストについて考えて、生成AIが成果を発揮するための方法を一緒に考えましょう。

UIライブラリは入れ替わりが早い一方で導入後はコンポーネント構造やテーマ設計・CSSトークン・A11y実装などがライブラリ側で固定化されやすく、結果としてロックインが生じやすいです。
本セッションではその前提を踏まえつつ、いま shadcn-ui をどのように評価し、ロックイン等のリスクと向き合うべきなのかを考えます。

発表内容

• UIライブラリのこれまで、選定基準など
• shadcn-uiを選ぶ理由と評価ポイント
  • コピー所有でロックイン低減、RadixベースのA11y、他ライブラリとの親和性
• 現場で見えた限界と対処
  • classNameによる意図せぬ拡張、改修時のルールの整備

メンテナンスされ続けるStorybook運用を目標に、設計と運用の要点を共有します。
Coding Agentに「作成・更新・整理」といった負荷の高い作業を委ね、速度と品質の両立をねらう取り組みを紹介します。
本テーマは実装の細部ではなく、意思決定の拠り所となる原則にフォーカスします。

発表内容

• AIに委ねる範囲・人が握る範囲の定義（境界設計・責務分離）
• 実装ガイドラインのガードレール設計
  • ファイル配置・命名、Storyの分割設計、バリエーションの整理、Controlの方針
• 小さく導入してから段階的に適用領域を拡大する進め方
• 運用コストの削減、変更の見通しとレビュー品質の維持、チームの開発速度確保

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

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

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

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