株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。2024年9月17日に吉祥寺.pm36で登壇をする際にイベントソーシングに関するアンケートを実施しましたが、この記事でその集計を公開します。
アンケートの詳細については以下の記事で説明しました。よろしければご覧ください。
またアンケート第２弾では良い点と悪い点についてアンケート結果をまとめています。
この記事では、成功のために必要と思われることについてまとめます。
イベントソーシングを行うチームが成功するための鍵はなんだと思われますか？
質問：イベントソーシングを行うチームが成功するための鍵はなんだと思われますか？知識？コンピュータサイエンス？気合い？チームワーク？その他？
まとめ：成功の鍵
成功の鍵 イベントソーシング経験者の声
新たなコンセプトを学びたい、学習いとわないなどがある程度求められる気がします。慣れてこればちーむの生産性はすごく上がるので数人はガッツリ勉強してリードできる人がいた方が成功率は高いかもしれない - tomohisa
まず、CQSを理解すること。その上で、オブジェクトモデルであるドメインオブジェクト（集約）とデータモデルであるリードモデルの考え方を身につけること。リポジトリは閲覧のために使わないこと、などのいくつかの重要な原則を理解して実践すること。 - かとじゅん
"やったことある人がチームにいる、チーム外にいて助けを求めやすい環境。
妥協が多くなってきたらイベントソーシングをやめる決断を早めにする。
lightbendのドキュメントを一通り読んでakkaでサンプルを作って理想を想像してから自分のコードを書く - 群馬の民"
"知識などももちろんありますが、まずはチャレンジし続ける気合い(一歩踏み出して見るだけです)、ということにしておきますw
失敗を気にせずまずはやってみましょう！
ネット上にいる人たちにいつでも疑問を投げてみてください - ytake"
技術的探求心、やる気、先駆者の知恵 - なるせ（nrslib）
要件におけるイベントソーシングの必要性、重要性をチームメンバー全員が納得していること？それがあれば、教育コストがかかっても乗り越えられると思います。 - 社内のマネージャー
正しい知識と経験？好奇心だけだと失敗しそう・・ - kazu_kichi_67
運用時の備え？イメージですが運用が大変そう - よだ
"明確なコンテキスト境界とドメインモデリング、そしてこれらの設計がエンジニアだけでなくビジネスレイヤーのドメインエキスパートにも完全に同意されていること。
しっかりCQRS＋ESを理解した人によるアーキテクチャ構築と確実なコードレビューを含むイネーブルメントプロセス。
イベントソーシングとイベントストリーミングを絶対に混同しない、させないこと。 - 夕暮おこは"
ドメインの理解 - LDDDはいいぞ
全部！と言いたいところですが、一つ選ぶのであればCQRS/ESはここが素敵なんだと言う(これが気合いかも)ことだと思います。 - かきあげせいろ
あえてイベントソーシングを採用する価値を明確にすること。ROI に見合う理由を皆がわかっていること。 - @memetics10
知識と気合（どんな複雑性が待っているか分からなくても試してプロコン評価できる） - (匿名)
"イベントソーシングは道具なので、これを使って何を成し遂げたいのかはチームの認識合わせておくこと。
データ検索周りがスタートソーシングよりデータ増えて遅くなりがちなので、線引きや、性能への対策 - しょーだい"
知識そのものも必要だが「これまで触ったことのない技術を受け入れる」「実地で試してみる」マインドのほうが大事 - (匿名)
知識と規模(小規模なドメインでやっても旨味があまり無い) - (匿名)
既存実装をとにかく徹底的に調査すること。実装の技術的な背景をきちんと理解すること。 - たかさん
学習能力（新しく不確実なことに好奇心、探求心、向上心を持って取り組む姿勢） - masuda220
フロー効率を意識できるかどうか。一手一手着実に実装できれば手堅い。 - (匿名)
成功の鍵 イベントソーシング未経験者の声
"メリットをチームで共有することと、導入後も改善を続けられる仕組みやマインドを保つことが重要かと思います。
あとは導入をリードする人が、信念を持ってチームに浸透させることですかね。 - (匿名)"
全部。強いてあげるなら、知識？ - shimabox
メンバー全員の素振り - @shotanue
実例のコードやハンズオン資料など。 - (匿名)
実際に業務での経験がないため想像になってしまいますが、いかにソフトウェア工学を尊重した開発を根付かせることができるかだと考えます。少なくとも予測型の開発プロセスでの成功は難しいでしょうし、チームの成長に投資する文化がなければ破綻するでしょう。適応型の漸進反復的なプロセスでチームファーストな開発を要するのではないかと考えます。 - (匿名)
実際の業務上のイベントをイメージしながら設計することだと思います。 - 非匿名希望
トレードオフ分析。目的意識。 - (匿名)
知識 - (匿名)
メンタルモデルの共有 - (匿名)
実験 - (匿名)
分散コンピューティングに関する基本的な知識、(少なくとも私が業務で関わるプロジェクトでは利用経験がないので)それを導入する気持ちが強いメンバーのリーダーシップ。最適なフレームワークの存在。 - @piyorinpa
要求を上手くコントロールする調整力 - Magnolia.K
チームのモチベーション - しがあきとし
技術感度と技術力の高いエンジニアでチームを構成する - ひろた
write heavyなシステムではそこまでメリットが活かせないので、read heavyあるいは多様なデータ表現が必要なシステムでの採用が効果的。そこの導入目的を明確にすること - ＠ryuke
"i
知識はかなり要求されると思います。現状実装方針を縛れる?ようなフレームワークを知らないため、実装者とレビュワーのリテラシ次第では簡単な崩壊するんじゃないかと思ってしまいます。
あと、予算もかなり見積もったほうがいいと思いますので、事前に決裁者とも話したほうがいいと思います。 - u-na-gi"
適切な事業目的と課題の理解 - (匿名)
まとめ
新たな技術に対するチャレンジ精神が多くの方のご意見に出ていたのに納得しました。学習の為の壁と技術面での壁と両方ありそうですが、それを解決すればとても役に立ちそうですね。
アンケート第４弾では、フレームワーク使用に関するアンケートの結果をまとめています。
そしてアンケート第５弾では、イベントソーシングやCQRSに関する質問をまとめています。
吉祥寺.pm36の参加レポート及び、登壇のスライドと練習動画はこちらです。
Discussion