レビュー文化を根づかせることは、多くの組織が抱える永遠の課題です。
しかも、そのチームがエンジニアだけでなく、多職種で構成されているとしたらどうでしょうか。成果物も、SQL や Goole Apps Script のコード、Salesforce の設定、業務ドキュメントなど多岐にわたる。
この環境でレビューを機能させるには、「文化」ではなく「構造」と「スキルの定義」が必要でした。
本セッションでは、チームがゼロからレビュー文化を設計・実装し、非エンジニアを含む多様な職能のメンバーとともに運用可能にしたプロセスを紹介します。
話の中心はコードレビューの技術論ではなく、「レビューを通じて組織がどう変わるか」という組織デザインの話です。

「レビューは品質担保のため」では足りなかった

わたしたちのチームでは、日々のアウトプットが事業運営の中枢を支えています。品質を守ることは単なる「きちんとした設計・コード」を超えて、事業そのものの信頼を守る行為でした。
わたしたちはまず、レビューを「品質の最終防衛線」ではなく、「リスクと知識の共有装置」として位置づけ直しました。
つまりレビューとは、属人化を防ぎ、チームの継続性と透明性を保つための仕組みです。
レビューを “誰かが見る” ではなく、“チームで引き受ける” 行為へと再定義した瞬間、ようやく文化づくりのスタートラインに立てました。

レビューを仕組みに落とし込む

レビュー文化は「がんばってやろう」では定着しません。人によって判断が揺れ、レビューの粒度や責任の範囲がばらつくからです。
そのためわたしたちはまず、「どの成果物をどの粒度で、誰がレビューすべきか」を体系化しました。
レビューの種類は、実施可否、方針、成果物、実行の4段階。
単にコードを読むだけでなく、「そもそもこの業務をやるべきか」「どう設計するか」「どのように実行するか」までレビューを拡張しました。その上で、職能ごとにレビュー観点を明文化しています。
エンジニアは品質と再現性、マネージャーは優先度と工数、事業責任者はリスクと価値のバランス。法務・会計・税務といった専門家はそれぞれの観点でレビューに関与します。
こうした役割の整理によって、「誰がどの段階で判断するか」が明確になり、結果として、属人化のリスクが減少しました。

多様な職能を束ねるための「スキルと期待値の見える化」

しかし、レビューの仕組みが整っただけでは十分ではありません。
チームの中には、エンジニアバックグラウンドを持つ人もいれば、業務設計や分析が得意なメンバー、ドキュメンテーションを中心に支えるメンバーもいる。
職能もバックグラウンドも違う彼らが「レビューにどう関わるべきか」を共有する必要がありました。
そこで導入したのが、スキルレベルと組織の Value をかけ合わせたマッピングです。それぞれの Value ごとに、個人がどのステップにいるのかを可視化できます。

これにより、「どのスキルが不足しているか」「次にどの段階を目指すべきか」を、レビューの中で対話できるようになり、レビューは単なる承認の場ではなく、成長と育成の場へと変わっていくのです。

文化を根づかせる「レビューの設計思想」

レビューを日常の一部にするために、意識した設計思想が三つあります。

一つ目は、レビューの優先度を高く置くこと。
自分のタスクよりもレビューを優先する。
レビュー時間を毎日スケジュールに組み込み、チーム全体でレビューを止めないルールを明確にしました。
レビューはスピードを遅らせるものではなく、スピードを維持するための基盤です。

二つ目は、レビューを「会話」ではなく「仕組み」に落とすこと。
Design Doc のテンプレート、チケットの項目設計、リスクレベルの自動分類など、誰がやっても同じ流れになるよう設計します。
これにより、メンバーの習熟度に左右されず、レビューが安定的に回るようになりました。

三つ目は、レビューを個人の責任からチームの責任に変えること。
「誰がミスしたか」ではなく、「どの段階でリスクを拾えたか」を見る。
レビューの失敗を咎めるのではなく、次の改善サイクルに活かす。
こうして、レビューは「チェック」から「共創」に変わっていきます。

セッションで伝えたいこと

このセッションでは、チームが実際に取り組んだ「レビュー文化の仕組み化」と「スキルの可視化」の設計思想を、実例を交えて紹介します。

• 多職種混在チームでレビューを成立させるための設計と運用のリアル
• レビューを成長・育成の仕組みに変えるスキル階層の考え方

これまでの経験の蓄積から見えた、文化のつくり方を共有したいと思います。

想定する参加者層

• レビュー文化を強化したいエンジニア、EM、SRE、テックリード
• BizOps や事業チームと協働するエンジニア・マネージャー
• 属人化や品質リスクに悩むプロジェクトリーダー

概要

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

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

本セッションでは、そんなマインスイーパを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を開始していると思うので、決め手となるのは本番運用に載せたときのメリットデメリットの話だとおもっていますので、今一度基本に戻ってはいかがでしょうか？っということで話そうと思います。

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

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

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