開発チームを超えてドメイン駆動設計(DDD)を実践する難しさを感じたことはありませんか？

プロダクト開発当初からDDDに取り組むと、Bizやドメインエキスパートの協力が得やすく戦略的なDDDが実践しやすいです。
しかし既存プロダクトにDDDを導入しようとすると、多くは戦術的DDDの実践に留まり、戦略的DDDまで到達することは困難に思えます。

後者のような後天的なDDDにおいて、開発チームが戦略的なプラクティスまで実践するには、高いハードルを飛び越える跳躍力が必要になると考えています。

本セッションでは、戦略的なDDDを後天的に実践するため取り組んだエピソードと共に、戦略的なDDDによって得られる効能についてお話します。

主なトピック

• 戦略的DDDの実践はなぜ難しいのか
• 戦略的DDDに必要な跳躍力とは何か
• どうやって跳躍力を身に付けるか

既存システムの理解と改善において、RDRA（リレーションシップ駆動要求分析）を活用することで要求分析や仕様変更をより効果的に行うことができます。
このセッションでは、RDRAを効果的に活用して、既存システムのリバースエンジニアリングおよび仕様変更を実践した際のプロセスを説明します。

RDRAの活用法に焦点を当て、要求と関係性を明確にし、システムの内部構造を可視化し、その情報を仕様変更プロセスに活かした具体的なケーススタディを紹介します。
RDRAを通じてリバースエンジニアリングと仕様変更の成功への道を切り拓きましょう。

プログラミングを学んでそれなりにプログラムが書けるようになった人でも、オブジェクト指向を学んでいると頭を悩ませることが多いように思います。

「何をクラスとして定義したらいいの？」
「どうしてクラスを定義する必要があるの？」
「プログラミングの話なのに、なんで動物の話が出てくるの？」
「クラスがたい焼きの型でインスタンスがたい焼きなのね、ふーん？」
「SOLID原則とかDDDとか言われてもよく分からないんですが？」

このセッションでは、どうしてそういった悩みが生まれてくるのか、そして、どうやったら解消できるのかについて、自分の考えを話したいと思います。

概要

オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。
コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。
これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。

しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。
「clean architecture 達人に学ぶソフトウェアの構造と設計」においても、建築家の建築設計とソフトウェアの設計は同じようなものだと示されています。

そこで、本セッションでは、現実世界に潜むSOLID原則を紹介し、SOLID原則を具象と抽象の両側面から解説します。
具象と抽象の行き来によりOOP初学者の理解を促進することを目的としています。
（人間の脳は具体的で具象的な情報を処理しやすい特性があります。そのため、具象的な例や視覚的な要素が組み込まれた話は、抽象的な概念をより身近で理解しやすいものに変換され、学習効果を高めることができます。この人間の脳の特性を逆手に取ったセッションです！）

私自身、OOPに魅了されてからまだ日が浅いですが、その浅さからくる理解の難しさは未だに鮮明に記憶に残っています。
最新の実体験をもとに、SOLID原則への理解に苦しむ初学者に寄り添い、初学者がより理解しやすいセッションを提供したいと考えています。

想定する聞き手

• SOLID原則をいつどこで何のために使うのかわからないという方
• OOPに興味のある学生・新卒・若手エンジニア

話さないこと

• SOLID原則の厳密な定義や誕生背景
• GoFのデザインパターンやClean Architecture等のOOPの実践的な技法

ドメイン駆動設計において、
ビジネス要件を整理し、設計・開発につなげるには、ユースケース図やドメインモデル図を作成することが多いと思います。
加えて、サービス・プロダクトを継続的に育てていくには、関連するモデリングも一緒に育てていくことが不可欠になります。

今回のセッションでは、チームでのサービス開発において、
モデリング（特にユースケース図、ドメインモデル図）を育てていく際に
考えていることと実践していくうえでの気づきや学びについて、お話していきます。

【内容（予定）】

• 前提・背景について（チームや当初の状態など）
• 育てていく中で気をつけたポイントと考えたこと
• 実践を通して得られた気づき、学びについて
• 今後の課題や挑戦すること

「デプロイ頻度」は開発生産性を測る重要な指標の一つです。
2、3ヶ月程度かかる大きめの機能開発で、機能をまるっと作ってからリリースしようとすると、このデプロイ頻度が落ちてしまう経験をした方は多いのではないでしょうか？
このようなとき、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークでは、私のこれまでの反省を活かし、大きめの機能開発でもデプロイ頻度が高い状態を維持した事例を紹介します！皆さんの日々のチーム開発に取り入れられるよう、具体的なテクニックについて順を追って説明します。

話すこと

• 細かくデプロイするために必要な設計の工夫
• タスクを分割するには、インタフェースだけ先に実装してデプロイしよう
• テストコードが先に書いてあると安心して実装できる

新卒入社して2、3年後ぐらいで出来ることが増え、大きな機能開発も任されるようになったとき、設計をどのようにすればいいか分からない、大きい変更のタスク分割が難しいと悩むことがあると思います。
このトークではその悩みを解決するヒントを見つけられる(かもしれない)のでぜひ聞きに来てください！

概要

非デザイナーのWebフロントエンドエンジニアが、「オブジェクト指向UIデザイン──使いやすいソフトウェアの原理」を読んで、OOUIについて考えてみます。
本書籍では、UIデザインにおいてオブジェクト（もの、名詞）を中心に据えるアプローチが、従来のタスク（やること、動詞）指向よりも画面数が減り、作業効率が向上するという「銀の弾丸」的な効果をもたらすとされています。
このセッションでは、書籍中で取り上げられている「ワークアウト(実践演習)」の18の課題に実際に取り組んでみて、オブジェクト指向UIデザインの設計手法がWeb開発のプロセスにおいてどのような効果をもたらすのか、非デザイナー視点での考察をお話したいと思います。

想定する聞き手

・UI/UXデザインの専門家ではないが、ユーザーにとって使いやすいUIを追求したいと考えているエンジニア
・様々な視点から、Web開発の効率化・ユーザビリティ品質の向上のたのアプローチを学びたいと考えているエンジニア
・手を動かしながらOOUIの理論を身につけたいと考えているエンジニア

本発表では、PharmaXというスタートアップでの２年半にわたるプロダクト開発の実経験を基に、ストーリー仕立てでソフトウェアアーキテクチャの運用についてお話しします。

特にソフトウェアを取り巻く環境や人材の変化に柔軟に対応するための
・ソフトウェアアーキテクチャ定義
・ソフトウェアアーキテクチャ維持・更新機構
・ソフトウェアアーキテクチャ運用指針
の重要性に焦点を当てます。

アウトライン：
〜Ruby on Railsへのレイヤー化アーキテクチャ導入〜
・序章：コアドメインのリアーキテクチャ
・PART１：PMF前のスタートアップでのアーキテクチャ運用
・PART２：束の間の安定期とチーム縮小
・PART３：チーム再編
・PART４：サマリー

発表内容：
序章：コアドメインのリアーキテクチャ
かれこれ2年半前、当時数名のまだ小さなエンジニア組織でRuby on Railsにクリーンアーキテクチャをベースとしたレイヤー化アーキテクチャを導入する意思決定しました。
そんな中、アーキテクチャ設計者が道半ばで退職してしまいます。
残されたメンバーでリアーキテクチャとコアドメインのリプレイスをやり切りましたがここから戦いの日々が始まります、、、

PART１：PMF前のスタートアップでのアーキテクチャ運用
素早い仮説・検証、数々の新規要件の追加により運用課題が噴出しました。
実際の運用課題を例に、ソフトウェアアーキテクチャ定義の重要性についてお話しします。

PART２：束の間の安定期とチーム縮小
運用歴の長いエンジニアが増え、プロダクトがある程度安定化してきます。
アーキテクチャルールの見直しとリファクタリング計画が立ち始め、改善サイクルを回せる目処が立ってきたかに思えました。
そんな矢先、、新規事業立ち上げのためのチーム縮小が起こり、私と新卒エンジニアの２名体制になります。
PART１でのソフトウェアアーキテクチャ定義の重要性に加え、ソフトウェアアーキテクチャ維持・更新機構の重要性について失敗例をもとにお話しします。

PART３：チーム再編
事業が拡大し、チーム再編期を迎えます。
この章ではチームメンバーの入れ替わりを見越したソフトウェアアーキテクチャ運用指針の重要性について実例を元にお話しします。

概要

CSSをうまく扱うための考えとして、オブジェクト指向CSS（OOCSS）という言葉が2009年に提唱され、それに影響を受けた考え方や方法論などが数多く登場しました。それから10年以上経過したいま、そもそもOOCSSはどんな問題を解決すべく登場し、ここ10年でどのような変遷があり、今どのようなアプローチが取られているのかというところを整理していければと思います。

お話する内容

このセッションではCSS設計論に関して「OOCSSが叶えたかったこと」を中心に、現在までのCSS設計のプラクティスを歴史をなぞる形で整理していきます。その上で今現在ではどのような設計論があり、今後どのようなものが登場していくのかというところを私なりにご紹介できればと思います。

話す内容としては以下の内容を考えています。

• OOCSSが登場した背景とOOCSSのオブジェクト指向エッセンス
• OOCSS登場以降に登場した命名規則とCSS設計アプローチ
• CSS in JSとユーティリティファーストのCSS
• 近年使われるようになるであろう@scopeとCSS設計

想定する聞き手と持ち帰ってもらうもの

想定する聞き手としては普段フロントエンド専門とされていない方や、フロントエンド設計をしなければいけないバックエンドなどの別ジャンルのエンジニアの方を想定しています。このセッションを聴くことで「オブジェクト指向の考え方がCSS設計にどのように取り入れられてきたか」という歴史とトレンドを知ってもらい、Webアプリケーション開発での「CSSをどう扱っていくか」を考える手助けの一つとしていただければと思っています。

レバテックは現在、フリーランス・派遣・就転職、新卒の各領域を軸に様々なサービス・事業を展開しています。

これらシステムで共通となるルールがいくつか存在しています。
例えば、「メールアドレス」「電話番号」「生年月日」などのValidationであったり、振る舞いに関するルールです。

レバテックではこれらのルールを各システムが保持しており、ルールの分散とルールの不一致により、何件ものシステム障害を起こしていました。
このシステム障害の原因として、ルールの分散とルールの不一致もあるが、共通ルールが存在しておらず、どのルールが正なのかもわからず、システム障害を恒久的に防ぐことが難しくなっていました。

そこで、レバテックにおける共通ドメインライブラリとしてドメインオブジェクトや値オブジェクトを管理するライブラリを作成し、共通ルールをライブラリとして実現しました。
このライブラリはNPMのプライベートパッケージとして作成し、TypeScriptで記述されたドキュメント生成ツールであるtypedocを活用して、社内共通ルールを一元管理できるようにしたものです。

これにより障害発生を大きく削減することができ、また、今まで暗黙知になっていた共通ルールもこのライブラリにどんどん実装され、たくさんのドメイン知識を貯めることができました。
本セッションではこのライブラリ作成に至った経緯、ライブラリの概要、現在の活用状況、今後の活用についてお話しさせていただきます。

システム開発の現場では、問題領域（ドメイン）における概念やルールを特徴づけて、モデルとして表現します。
しかし、本当に問題解決に役立つモデルを設計・実装するのは難しく、ドメイン知識をほとんど持たないドメインモデル貧血症と呼ばれる状態に陥っているものや、逆に複数の文脈の知識を持ちすぎて肥大化した Fat Model まで、その実態は様々です。

今回は EC サイトのシステムを題材に、実際の開発現場で遭遇する具体的な課題について考察していきます。
そして生成 AI を活用してコードを書くことを前提に、開発を進める過程で陥りがちな戦術的プログラミングを紹介します。

最後にドメイン・ファーストの考え方で設計を見直し、どのような変化があるのかを説明します。

現在私のチームでは、オブジェクト指向をベースにした設計、理解容易性、命名、コードスタイル、機能要件、ドキュメント、テストといった7つの観点でコードレビューを行っています。さらに、チームのレビューコメントを分析・類型化することにより技術力を可視化し、育成やオンボーディングへのアプローチを行っています。

具体的なコードレビューの手法は、レビューガイドラインとしてドキュメント化されており、そこには具体的なケースなども記載されています。また、このガイドラインにはレビューの技術的観点だけでなく、レビューにおけるレビュアーとレビュイーの姿勢も記載されており、より円滑にコードレビューができるためのTIPSを言語化しています。

このセッションでは、オブジェクト指向をベースにしたコードレビューガイドラインについて紹介します。また、レビューコメントの類型化やAIを活用したレビュー手法を通じて、技術力の可視化と向上を促進する実践的なアプローチを紹介します。参加者は、効果的なコードレビュー戦略を学び、チームの技術力向上に即座に活用できる具体的な戦略を得ることができるでしょう。