オブジェクト指向という考え方がプログラミング言語Simula（Simula I：1962、 Simula67：1967）の影響のもとでAlan Kayによって1970年前後に生まれてから半世紀以上が過ぎた今、その歴史的な功罪を素直な目で振り返り（reflection）たい。そのうえで改めて「オブジェクト指向」という言葉・概念・思いの意味を、プログラミングや設計を踏まえたソフトウェア工学だけでなく、言語・哲学・文化といった観点からも広く見直してみたい。そうすることで新たな気持ちを込めて、「Objectオブジェクト」「Orientation指向」に生成AI・大規模言語モデル時代である現在において意味のある概念としてしっかりと向き直りたい（リ・オリエンテーション）と思う。それは新しい時代のオブジェクト指向の入門（オリエンテーション）にもなっていることを望んでいる。

Algomaticでは、2023年5月に「シゴラクAI」という生成AIを活用した法人向け生産性向上支援サービスをリリースしました。
サービスの根幹となる生成AI技術が日々とてつもない速さで進化していく中で、シゴラクAIでも最新技術のキャッチアップとプロダクトへの取り込みは欠かせません。そんな日々の中で、シゴラクAIのソフトウェア設計も大きく変化を遂げてきました。
その過程において大切にしたこと、設計における考え方、さらには生成AIという技術に対するエンジニアとしての向き合い方、といったテーマについて、増田さん (@masuda220)との対談形式でお話しさせていただきます。

開発チームを超えてドメイン駆動設計(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の実践的な技法

関連し合うデータとロジックをひとまとめにして、1つのモジュールを定義することをカプセル化といいます。

正しくカプセル化すると、関心が分離され、変更に強い構造になります。
ところが上手くカプセル化できなかったり、仕様変更により意図せずカプセル化が破られてしまうことが往々にしてあります。
カプセル化が破られると異なる関心事どうしが混在する構造になり、整合性の維持が困難になったり、変更に弱い構造になってしまいます。

本セッションでは、カプセル化の設計が良くないとどんな凄惨な地獄が待ち受けているかを風刺したクソコード動画、『カプセル化 Mk-II』を上映します。
(参考：クソコード動画『カプセル化』 https://twitter.com/MinoDriven/status/1142926621583663104 )
動画の中で何がマズかったのか、高品質なカプセル化をするにはどう設計すればいいのかについて、「目的論的抽象」という抽象化の観点で解説します。
その他カプセル化する上で考慮が必要な観点や、カプセル化に関するよくある誤解などについてもあわせて解説いたします。

本トークでは、イベントストーミングを活用したオブジェクトモデリングの実践が開発プロセスとアーキテクチャにどのような変革をもたらしたかについて詳しくお話しします。

「どのようなオブジェクトを実装するのか」
この単純な問いに私たち開発者は多くの悩みを抱えています。

イベントストーミングの結果として得られるモデルはこの問いに対する解答の示唆に富んでいます。
その有用性を認め、私たちは過去２年間、組織的にイベントストーミングに取り組んでまいりました。

もちろん、ただイベントストーミングを採用すれば、それですべて片付くといったものではありませんでした。

イベントストーミングの採用は開発プロセスを一変させました。
アーキテクチャの選定基準を変えました。
組織的に取り組むには多大な努力と適応が求められました。

本トークでは実地での経験を基に、イベントストーミングによるモデリングの採用がどのようにプロセスやアーキテクチャの選択肢に影響を及ぼしたのかについて共有します。

◆お話すること
・イベントストーミングの流れと基本要素
・イベントストーミングの図はどのようなオブジェクト指向プログラミングの実装に落とし込まれるのか
・CQRS+ES との親和性
・もともとの開発プロセスがどのように変化したか
・アーキテクチャの選定基準の変化
・ポジティブな影響とネガティブな影響
・プロセス変更などに伴う組織的な痛みとその対症療法

近年目にすることが増えてきた「脅威モデリング」、その目的は脅威を特定しリスク判別するだけではありません。そのプロセスにおいてビジネス上の効果を高めるために重要なポイントとその効果を脅威モデリングの概要とともに解説します。

2016年から仕事で、また2017年からは趣味でもプログラミングをしてきた私にとって、変更しやすいコードというのはずっと憧れでした。
自分の書くコードはとにかく変更しづらくて、ハードウェアと呼称していました。
変更しやすいコードを書きたくてオブジェクト指向に興味を持ちましたし、OOC 2020では道中のアウトプットとしてプロポーザルにも挑戦しています。
2020では採択はされませんでしたが、その後も設計についてのインプットは継続し、オンラインで『ミノ駆動本』や『ちょうぜつ本』の読書会も共同主催してきました。

このインプットが多少は結実し、変更しやすいコードを書くコツがいくつか見えてきています。
このトークでは、過去の私に知の高速道路を提供するように、変更しやすいコードを書くコツを共有していきます。

聞く方のイメージは、変更しやすいコードを書きたいと思っているのになぜか書けない、"わからん殺し"されている状況の方です。
私が食らってきたわからん殺しを共有して、何が起こっているかが見えるきっかけになればと思います。
私が習熟しているPythonでコード例を示しますが、ここで話す内容はPython固有ではなく、他の言語でも当てはまると思います

• シンプルさによる変更しやすさ
  • レゴブロックのイメージ（Clojure）
  • 小さなクラスを組み合わせる
• これが、クラス
  • 入門書で見かける文法説明のクラスとのギャップを埋める
  • データとメソッドをまとめた例
  • 悪しき構造：データクラスに注意（私はよくやってました）
• 小さいは、正義！
  • 単一責任と恣意性
  • 入出力と計算を分ける
  • 作ると使うを分ける（依存性の注入）
• インターフェースという概念
  • インターフェースとは、利用時の関心
  • インターフェースに依存させる（依存性逆転）
• 継承
  • 気軽に継承を使うんじゃねえ、そいつは重税だ
  • 継承より委譲
• いま見えてきていること：変更しやすいコードをチームで書く
  • ソフトウェアは一人で作るのではないという（次の壁への）気付き
  • この発表も次の壁への取り組みの1つかなと思います

筆者は現職の（株）タイミーも含め、数社のスタートアップでサービスの開発に従事してきました。
オブジェクト指向を学び、ドメインをどう抽象化するか考え、実際にコードを書き、同僚とともに知恵を出し合った末に一つの結論にたどり着くのです。

「このコード設計よくないね」

しかし負債を返すためのリファクタリングに当てられる工数は限られています。本当は何日でも設計について悩めるのに数時間で結論を出さなくてはならず、手癖で設計するしかないような現場もあることでしょう。
いい設計はわからないが、痛い目に遭った設計はわかる。そんな自分の経験と設計原則を照らし合わせて一体どうすればよかったのかを検討していきます。

そしてタイミーで辿り着いたよりよい設計のためのプラクティスについてもご紹介いたします。

UXデザイナーから渡されたペルソナやジャーニーマップ、ユーザーストーリーを見て、頭を悩ませたことはありませんか？
または、UIデザインからオブジェクトをリバースエンジニアリングした経験は？

このセッションでは、グループに分かれてペンや付箋を使ってワークを行います。
ワークでは、グループごとに用意されたユーザーストーリーからどのようなオブジェクトがあるのかを見つけ、
オブジェクト同士を関連づけて、システムに登場するオブジェクトを明らかにするとともに、どのようなUXを実現するのかを考えて、
各グループごとにサービスの構想を発表します。

エンジニアもデザイナーも歓迎です！
オブジェクトモデリングとコンセプトメイキングの接続を楽しみましょう！

共同登壇者：
中川孟
どぎー

協力：
りりーのんのん
こばやしめいか
中沢おさむ

参考書籍：
『Object Modeling & Flow Diagramming for Designers: Methods for Designing with Ease and Confidence』
https://www.objectmodelingfordesigners.com/

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

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

【内容（予定）】

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

私がDDDに出会ったのは2014年です。
そのころはDDDの情報も少なく、試行錯誤しながらDDDに向き合ってきました。
思い返すと「DDD理解した」と「DDD分からん」を繰り返してきたように思えます。
今回の発表では私の経験をベースに「なぜDDDが難しいのか」「どうすればできるようになるのか」を設計原則や良いコードの定義を交えて説明しようと思います。

拙著「ちょうぜつソフトウェア設計入門」には、「オブジェクト指向の定義はない」と書かれています。

「オブジェクト指向」という言葉は、その普及とともに、当初意図されていた意味を失い、バラバラの概念に好き勝手に使われるようになってしまいました。さらに時が進むにつれて、私は、オブジェクト指向を自信満々に説明したもの(あるいは強く批判したもの)ほどとんでもない大間違いだという状況を、何度も見ることになりました。入門者にとって、先にオブジェクト指向を理解しようとする道は、もはや罠しかない世の中です。

なぜこんな状況になってしまったのでしょうか。西洋の宗教史と近代化になぞらえて、「オブジェクト指向」という用語がどんな経緯を辿ったのかを探っていきましょう。歴史を知って余計なノイズを取り除くことが、入門からさらに踏み込んでいこうとするみなさんにとって、自分の目で本質を見つけるヒントになるのではないかと思います。

オブジェクト指向設計を理論としては知っていても、実務にどのように応用すれば良いのかピンとこないという方向けに、弁護士ドットコムにおけるオブジェクト指向設計の実例を紹介します。

SOLID原則のうち、以下2つの原則を中心に実例を交えてお話しします。
単一責任の原則(SRP)
依存性逆転の原則(DIP)

読後感
オブジェクト指向設計の概念は理解しているが、実務にどのように落とし込んでいったら良いのか悩んでいるエンジニアの方々。
このセッションは、オブジェクト指向設計の実例を知るとともに、サービス開発にどのようなメリットがあるのかがわかる内容になっています。

「匠Method」はビジネスデザインの企画手法であり、「RDRA」は要件定義に、そして「ICONIX」と「DDD」はオブジェクト指向設計の手法にそれぞれ特化しています。これらの手法を組み合わせて使用することにより、ビジネスアイデアから設計までの過程をトレーサブル（追跡可能）に保ちつつ、システム全体を俯瞰する考え方を実現できます。

本セッションでは、これらの方法論をどのように結びつけ、総合的な思考へと展開するかについて説明します。

オブジェクト指向におけるインターフェースという概念は，アプリケーションやライブラリの実装に欠かせない要素です．しかし，その抽象的な性質から，初めて触れる人にとっては活用方法がイメージしにくいこともあるかもしれません．

本セッションでは，そんなインターフェースを次の３つのカテゴリーに分類してみます:

【レイヤー分離】
アプリケーションの異なるレイヤー間での依存度を下げることで，変更が他の部分に及ぼす影響を局所化し，システム全体の安定性を保つ．

【特性表現】
オブジェクトが持つ特定の「振る舞い」や「能力」にフォーカスし，その表現力を高めることで，オブジェクトの再利用性と明確性を向上させる．

【差替可能性】
異なる実装を容易に切り替えられるようにロジックを抽象化し，それによってシステムの柔軟性と拡張性を高める．

「インターフェース」と一口に言っても，その使い方は多岐にわたります．
具体的な実装例を交えて，それぞれのカテゴリーがどのような場面でどのように活用されるのかを詳しく掘り下げていきます．

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

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

話すこと

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

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

発表資料
https://speakerdeck.com/yuitosato/functional-and-type-safe-ddd-for-oop

ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。

本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。
型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。
さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。

関数型の考えをいれるといってもただ単にHaskellなどに代表される関数型言語を使ってドメイン駆動設計を行うことではありません。
関数型の知識を応用したタイプセーフな考え方やテクニックは小さく導入することが可能です。Javaなどの既存のオブジェクト指向の良さをそのままに明日からプロダクトションコードを改善する手法を紹介します。

1. はじめに
   1-1. 関数型DDDとは？
   1-2. ビジネスロジックを型で表現できると何がいいの？
   1-3. オブジェクト指向と関数型
2. DDDってなんだっけ？
   2-1. モデリングとアーキテクチャ
3. 実践と3つのテクニック
   3-1. モデルの状態を代数的データ型で表現する
   3-2. モデルの状態遷移を型と全域関数で表現する
   3-3. ロジック内のDBアクセスを高階関数で表現する
4. まとめ