Object-Oriented Conferece 2024に参加してみました。 なかなかこういうカンファレンスに参加する時間が取れず久々の参加でした。 設計とは、とか、オブジェクト指向とはというそもそも論から、やってみた系の事例紹介まで幅広く取り上げられており、非常に刺激的でした。
本記事は身内で公開用にまとめていたのですが、その機会も無くなったのでここに投下します。 まとめは自分が参加した講演のみです。 一応自分なりにまとめてみたつもりですが、メモとかは結構スライドそのままになってしまっています。 詳細については公開資料の場所がわかったものはURLを載せていますので公開資料を確認してみてください。
OOCとは
Object-Oriented Conference はオブジェクト指向をテーマに、アイデアを共有し、議論を深めるイベント。
- 日時：2024/3/24 10:30-18:30(※前日に前夜祭あり)
- 場所：お茶の水女子大学
オブジェクト指向のリ・オリエンテーション ～歴史を振り返り、AI時代に向きなおる～
- 10:50-11:30 Track A（共2-201）
- スピーカー：羽生田 栄一（株式会社豆蔵）
- 公開資料：
所感
- OOPの5段階の話が印象的だった
- OOPの5段階を自分に当てはめてみると、3段階目で留まっている（というか2段階目もちゃんとできているのかあやしい）
- DDDも気になるけどまずは4段階に進めるようにしたい
メモ
OOPの5段階
- オブジェクトとメッセージ
- 責務を割り当てる
- クラス、継承、ポリモルフィズム（を使っている）
- 意味のあるまとまりをクラスにまとめてないと意味がない
- getter/setterでカプセル化できたことにならない
- リスコフの置換原理...継承クラスは親クラスを置換可能でなければならない...置換できない継承はNG
- 抽象データ型、サブタイピング、インタフェース指向設計、コンポジション、OCP、DbC、SOLID
- 依存反転、イミュータブル、DDD
第三段階は形式的で意味がないので早く次の段階へ
生成AIの不確実性と向き合うためのオブジェクト指向設計
- 11:40〜12:00 Track A（共2-201）
- スピーカー：菊池 琢弥（Algomatic）
- 公開資料：なし
所感
- ユースケースの説明はとても良かった。生成AIというとなんとなくすごいものというイメージしかなかったので、システム化の観点が得られた。
メモ
生成AIのユースケース
- 扱いにくいデータをいい感じに扱える
- 扱いにくいデータ...メインのメニューを集計したいが店ごとに異なる、アイスとアイスクリームで表記が違う
- ファクトチェックが必要
- AAAA
- Automation: 人がやりたくない（心理的にしんどい、危険）、やり切れない（量的に）
- Agent: 人が持ってない知識、スキル
- Advice: 人が責任を持つ作業、人の内省・成長を促す
- Augment: 楽しいこと、リアルタイム性が求められる
生成AIプロダクトの難しいところ
- 技術基盤の進歩が早い
- 遅くて高額なAPI
- 生成AIとの結合度が悩ましい（別のモデルに切り替える必要性が高い）
実践！RDRAを活用した既存システムの仕様変更
- 12:30-12:50 Track C（共2-102）
- スピーカー：今本 光（株式会社ラクス）
- 公開資料：
所感
- RDRAは知っていたが今一どう手を動かしていくかというイメージがついていなかったが、上位を入力に下位にというのは参考になった
- RDRAの採用理由とか適用の事例として参考になった
- どういうケースであれば無理なく適用できそうかイメージアップできた
RDRAをどう生かしたか
- RDRAを利用した理由
- デグレリスクの低減
- 社内の小規模なシステムであった（RDRA自体はかなりカロリーを使う活動だが、社内だし小規模だし適用させやすかった）
- システムリプレースなので下位レイヤから上位にフィードバックしていった
- リバースしてシステムの情報の洗い出し
- ユースケースを整理
- 既存システムの要求をリストアップ（これを変えないようにリプレースや改修する）
- 整合をとりながら下位レイヤを修正
実施してみて
- 既存の処理に無駄なものが見つかり整理できた
- 要求を見直す機会になった
- 小規模でもかなり工数がかかる
- 開発者目線のモデルになりがち
イベントストーミングによるオブジェクトモデリング: オブジェクト指向プログラミングへの適用/開発プロセスの変遷/アーキテクチャの変革
- 13:00-13:40 Track B（共2-101）
- スピーカー：成瀬 允宣（GMOインターネットグループ）
- 公開資料：
所感
- イベントストーミングという設計手法自体は結構使えるような気がする、
- システムの全体像をみんなで共有できるという点は良い
メモ
イベントストーミング
- メインエキスパートと開発チームが協力してドメインの理解を深めるワークショップ手法
- イベントに着目して洗い出しをする
- 効果
- イベントを中心として業務フローを明確化できる
- ドメインの認識齟齬解消
- 全体像が俯瞰できる
CQRS(Command Query Responsibility Segregation)
- 従来のアプリケーション
- データベースには検索のためのデータを格納（登録時のデータが欠損する）
- コマンド（登録）とクエリ（参照）は要件が異なる（従来のアプリケーションでは区別せず一つのアプリ）
- コマンド：整合性が求められる、集約単体に対する処理
- クエリ：処理実行時の高速化が求められる、集約を跨いだ処理
- CQRS
- イベントとクエリを分離、イベントから変換をしてクエリ用のデータを作成する
- Event Sourceing
- イベントをそのままjson形式で格納する
- イベントストーミングのイベントがそのままCQRSのイベントになるため相性が良い
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
- 14:00〜14:40 Track A（共2-201）
- スピーカー：pospome（DMM.com）
- 公開資料：
所感
- よりコーディングを意識した設計力を高める必要がある
- DDDをやるには、設計に軽くフィードバックできるプロセスが必要
メモ
DDDを理解する
- ドメインとは、ソフトウェアを適用する領域
設計能力の壁
- どうすれば満たせるか？
非デザイナーのフロントエンドエンジニアがOOUIを考える
- 15:00-15:20 Track D（共1-301）
- スピーカー：Oyu（DMM.com）
- 公開資料：なし
所感
- OOUIのエッセンスをおさらいできた
- タスク指向でも向いているケースがあり使い分けのイメージができた
メモ
OOUIとタスク指向UIの使い分け
- OOUI: 創造的なUIの作成
- タスク指向UI: 定型的な作業用のUI
- エイブルのUI、初回はタスク指向、二回目はOOUI
- オブジェクト指向UI（OOUI）デザインと、タスク指向UIを掛け合わせたデザインの最適解
- 自由すぎてユーザが何したらいいかわからない場面はタスク指向でもハマるかも（トレーニングとか）
宅配クリーニングサービス「Lenet」開発におけるDDD7年の歩み
- 15:30-15:50Track D（共1-301）
- スピーカー：仲見川 勝人（株式会社ホワイトプラス）
- 公開資料：
所感
- DDDに関する知識やドキュメンテーションを揃えることが重要だと感じる
メモ
DDD導入のためのアプローチ
- 導入時にチームでワークショップを行い境界付けられたコンテキストを抽出した
- ドメイン知識の共有会
- ドメイン駆動設計の読書会
- ユビキタス言語表の管理と命名
- ドメイン駆動設計の定義を揃えるための勉強会
- 仕組み化として、SUDOモデリングを採用
- ドキュメンテーションの整備
- ボトムアップの設計としてアーキテクチャの整備
設計の抽象からAIに代替されない設計力について考える
- 16:00-16:40 Track B（共2-101）
- スピーカー：石橋 隆平（株式会社YESOD）
- 公開資料：
所感
- 設計とはというそもそも論から整理されており参考になった
- AI時代を生き抜くためのヒントが得られた
メモ
- 設計とは、コンテキスト、要求、形、適合の4つが揃ったモノである
- 設計の正解は要求や制約次第である
- AIが人間の仕事を代替する時代が来ている
- 領域特化の人材は価値が下がる（AIが得意な分野なので）
- 横断的領域で調整や意思決定ができる人、要求に関する体系的な知識を持っている（つまり制約をコントロールできる）ことが重要
オブジェクト指向は必要なのか
- 17:00-17:40 Track B（共2-101）
- スピーカー：きしだ なおき（LINE ヤフー）
- 公開資料：
