1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

重厚長大ドメインにDDDで挑む。SRエンジニア組織の現在地

Last updated at Posted at 2025-12-01

株式会社センシンロボティクス(以下、長いのでSRと記載します)でエンジニアリングマネージャ(同 EM)をしております、 @bon71 です。 本記事は、SRの 2025年アドベントカレンダー 1日目の記事です。先頭打者として、私たちの組織がいま取り組んでいる「熱い」挑戦についてお話しさせていただきます!

社会インフラを支えるSRの技術と、EMとしての課題意識

SRでは、ロボティクスとAIを駆使したソリューションを社会実装し、これまで数多くの社会インフラの現場に貢献してきました。

弊社には技術力の高いエンジニアが集まっていますが、EMとしてさらに貢献できることとして、「個人の技術」を「組織の価値」として積み上げていくための土台作りが必要だと考えました。(※高い技術力の片鱗は、明日以降のアドベントカレンダーできっとお見せできるはずです!)

なぜ今、DDDなのか?:複雑なドメインへの対抗策

image.png

私たちが相手にしているのは、電力やプラントエンジニアリングといった重厚長大、かつ専門性の高いドメインです。しかも、それらは一つではありません。 このような状況下で持続的に価値を積み上げるには、エンジニア全員がそれぞれの所属する担当ドメインを深く理解し、チーム一丸となってプロダクトの拡張性を維持し続ける必要があります。

そこで、我々のチームの手札に「DDD(ドメイン駆動設計)」を加えるべく、この半年、様々な取り組みを行ってきました。

エンジニア×PMで挑む「共通言語」作り:PMを巻き込み「社内受託」からの脱却

以前から個人レベルでDDDに関心を持ち、学習を進めているエンジニアはいました。しかし、個人の熱意だけでは、チーム全体で共通理解を築き、実際のプロジェクトに適用していくには限界があります。 また、当時の課題として、エンジニアとPM(プロジェクトマネージャ)の間で、仕様策定と実装が分断されがちな、いわば「社内受託」のような関係になりやすいという側面がありました。

そこで今回は、エンジニアだけでなくPMも巻き込み、全員で同じ研修を受けることにしました。 講師には、難解なDDDの概念をワークショップ形式で実践的に教えられており、ブログ等での発信でも信頼の厚い松岡さん(@little_hand_s)に依頼しました。

研修を通じて、ヒアリングした内容をシステム関連図やユースケース図に落とし込み、そこからオブジェクト図、ドメインモデルへと昇華させる一連の流れをPMと共に体験しました。 これにより、「エンジニアがなぜその情報を欲しがるのか」「PMはどう表現すれば伝わるのか」という相互理解が劇的に深まりました。結果として、以前のような一方通行の依頼関係から、共にモデルを探求するパートナーとしての関係へと、徐々に、しかし確実に変化しつつあります。

DDDtraining.png

チームで実践する:30名超で挑む、全社規模でのワークショップ

研修で得た知見を一握りのメンバーだけに留めておくのは勿体無いと考え、四半期ごとに実施している全社エンジニアワークショップのテーマとして、DDDの実践を取り入れました。

「ドメインマスター」を中心としたチーム編成

SRには大小合わせて20以上のプロダクトが存在します。そこで、各プロダクトの立ち上げに関わったり、実装に深く精通しているエンジニアを「ドメインマスター」としてアサインしました。 ワークショップでは、このドメインマスターを中心に4〜5名のチーム(オンライン・オフライン混成)を組み、架空の課題ではなく「実際に動いている自社プロダクト」を題材にモデリングを行いました。実際に動くシステムを確認しながら進められたことで、抽象的な議論に終始せず、解像度の高い議論が可能になりました。

AI・ロボット・ソフトの共通言語としての「戦略的DDD」

参加者はソフトウェアエンジニアだけではありません。AIエンジニアやロボットエンジニアも参加する、総勢30名強の場です。 全員にコードレベルの「戦術的DDD」を強制するのではなく、コンテキストの境界や関係性を明らかにする「戦略的DDD」の理解に重きを置きました。これにより、職能が異なるエンジニア同士でも「どこで境界を切り、どう連携するか」という共通認識を持つきっかけを作ることができました。 導入判断自体は各プロジェクトの規模感に任せつつも、まずは全員が「体験する」ことを重視しました。

スクリーンショット 2025-11-27 12.08.05.png

ツールには、多くのエンジニアが使い慣れているDraw.ioを採用しました。ツールの操作につまずく時間を最小限に抑えられたことで、3時間という限られた時間の中で、全チームが目標としていた「システム関連図」と「ユースケース図」の作成をクリアすることができました。

現場への適用と、チームに起きた化学反応:実プロジェクトでのモデリング

研修での学びを活かし、実際のプロジェクトへの導入も進めています。 アプローチはプロジェクトの状況に合わせ、あるチームではビジネスロジックの分割から少しずつ、別のチームでは新規要件の仕様すり合わせベースでモデリングから、といった形でスタートしました。

マネージャー主導から、チーム主導へ

正直に言うと、最初から順風満帆だったわけではありません。当初は「毎日少しずつやろう」と試みたものの、目的が曖昧なままでは熱量が上がらず、メンバーの関与も受動的でした。 転機が訪れたのは3回目くらいです。多忙なマネージャー(私)のファシリテーションを待っていては進まないと感じたのか、国籍や経験年数も異なるメンバーたちが主導権を握り始めました。「毎日少し」ではなく「期限を決めて1〜2時間集中投下する」スタイルに切り替え、Draw.ioを囲んで白熱した議論が交わされるようになりました。

「DB脳」からの脱却

モデリングの実践中、ハッとする気づきがありました。議論が進むにつれ、無意識のうちに慣れ親しんだ「DB定義書」のような構造でモデルを描こうとしてしまっていたのです。 DDDの本質は、業務理解に基づく「集約」の発見です。自分たちの思考がデータ構造に引っ張られている癖(DB脳)を自覚し、矯正できたことは大きな収穫でした。

image.png

また、コードへの落とし込みに際しても、事前にPMと共に研修を受けていた効果が出ました。「なぜリファクタリングや設計に工数が必要なのか」の共通理解があるため、スムーズに工数確保の合意が得られ、技術的負債を残さない開発サイクルが回り始めています。

定性的な変化と、定量的評価への見込み

取り組みの結果、まだ数値として誇れる段階ではありませんが、確かな手応えを感じています。

具体的には、プロジェクト内でのモデリング実践により、チーム内の業務理解が飛躍的に進みました。これまで「特定の人しか知らない」状態だった仕様がコードとモデルに落ちることで、実装の属人化が解消されつつあります。これは遠くない未来、リードタイム短縮という数字で証明できる見込みです。

何より大きな変化は、エンジニアの意識変革です。焦点が「How(どう実装するか)」だけでなく「What/Why(どんな業務課題を解決するか)」にシフトしました。社内コンサルタントチームとも連携し、業界規模と業務単位での価値分解を行うことで、カバレッジの算出という形で成果を可視化していく予定です。

理想と現実の狭間で:今まさに直面している壁

導入に向けた手応えを感じる一方で、一筋縄ではいかない課題にも直面しています。

「走りながらエンジンを交換する」難しさ

最もDDDの恩恵を受けられるのは、複雑化した大規模プロジェクトや、長年運用されている既存プロダクトです。しかし、既に顧客が利用し日々動いているシステムであるため、そこにDDDを適用するには、膨大なリソースと慎重な調整が必要です。 特に、ドメイン知識を深く持つ「ドメインマスター」は、現行プロジェクトの要でもあるため多忙を極めます。彼らの時間を確保し、リファクタリングやモデルの再定義に工数を割く判断は、経営的な視点も含めた難しい舵取りが求められます。

「10社以上が絡む」ドメインの深淵

また、私たちが向き合う「社会インフラ」というドメイン自体の複雑さも大きな壁です。 単純な B to C サービスとは異なり、システムの「利用者(エンドユーザー)」と「決裁者(ステークホルダー)」が異なるケースは日常茶飯事です。一つのプロジェクトに関係する企業が10社以上に及ぶことも珍しくありません。 誰の、どんな課題を解決すべきか。真のドメインエキスパートはどこにいるのか。この複雑な相関関係を解きほぐし、正しいドメインモデルを描き出す難易度は非常に高く、まさに今、チーム全体で頭を悩ませながら挑んでいる最中です。

しかし、だからこそエンジニアリングで解決する価値があると考えています。

今後の展望:モノから「コト」へ

最後に、これからの展望について。

私自身の反省として、どうしても理想を追い求めすぎて「ビッグステップ」「パーフェクトステップ」を踏もうとしてしまう癖があります。しかし、組織づくりやDDDも、一朝一夕に完成するものではありません。 まずはこの悪い癖を自覚し、少しずつでも着実に、継続的な価値貢献ができるチームビルディングを進めていきたいと考えています。

そして何より目指したいのは、エンジニアの視座の転換です。 コードや「モノ」を作ることに閉じるのではなく、その先にある顧客の課題解決、つまり「コト(価値)」に焦点を当てられる組織へ。 数値的な成果はまだ道半ばですが、実装の属人化解消や、業務理解の深化といった確かな変化の手応えを、近く「リリースサイクルの短縮」や「カバレッジの向上」という数字で語れるようにしていきたいと思います。

この1年で蒔いたDDDという種が、来年はさらに大きな花を咲かせ、日本の社会課題解決を支えるエンジニアリングの力になるよう、組織全体で取り組んでいきます。

明日はSRアドベントカレンダー2日目、技術統括の中山さんです!お楽しみに~

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?