前回の記事では、DDDにおける実装部分に焦点を当てましたが、今回は前段の部分について掘り下げたいと思います。そこで架空の企業の業務課題を例に、ビジネスプロセスをどのように理解し、専門家の知識を活用してシステムを構築するかを考えていきます。

ステップ0：プロジェクトが始まるきっかけ

現場の声

あるコンテンツ制作企業では、契約書関連業務の非効率さが問題となっていました。以下は現場からの具体的な声です。

コンテンツ製作者の声
- 「契約のたびに対面での説明が必要で、他のクリエイティブ業務に集中できない。」
- 「出演者との契約交渉に時間がかかり、配信スケジュールが遅れることが多い。」
法務チームの声
- 「契約書の作成と確認に多くの時間を費やしており、他の業務に支障をきたしている。」
- 「紙の契約書の保管スペースが足りず、過去の契約書を探すのが大変。」
契約者（出演者）の声
- 「対面での契約説明はスケジュールが合わず、契約までに時間がかかる。」
- 「契約書のサインや修正のために何度も訪問するのが負担。」

プロジェクトの背景と目的

このような問題が積み重なり従業員の残業が増加し、企業全体の効率が低下していました。改善のために契約書関連業務をシステム化するプロジェクトが立ち上がりました。目的は以下の通りです。

効率化：契約書の作成・確認・保管のプロセスを効率化し、従業員の負担を軽減する。
時間短縮：対面での契約説明を減らし、契約締結までの時間を短縮する。
コスト削減：紙の契約書の保管スペースを削減し、管理コストを抑える。

ステップ1：関係者を集める

関係者の選定と招集

プロジェクトに関わるすべての関係者を集めます。具体的には、以下の役割を担う関係者を招集します。

コンテンツ製作者：コンテンツの内容を決定し、契約時に必要な項目を決める。
法務チーム：契約書の作成および法的なチェックを行う。
ITエンジニア：システムの設計・開発を担当。

ワークショップの開催

次に、これらの専門家を集めてワークショップを開催します。ワークショップの目的は、各自が自分の業務について説明し、相互理解を深めることです。

ステップ2：ビジネスプロセスを一つずつ話し合う

現状のプロセスの確認

現状のビジネスプロセスを確認します。具体的なプロセスとしては以下が考えられます。

コンテンツ製作者がコンテンツの内容を決定し、契約時に必要な項目（出演料、配信期間、出演内容）を決める。
法務チームがその情報を元に契約書を作成する。
契約者が契約書を確認し、サインするかどうか判断する。
法務チームがサイン済みの契約書をチェックし、保管する。

問題点の洗い出し

現状のプロセスでの問題点を洗い出します。

対面での契約説明・サインに時間がかかる。
契約書の紙保管にスペースが必要。
契約書の不備があった場合の修正が大変。

ステップ3：エンティティとインタラクションの図を作成する

エンティティの特定

ビジネスプロセスに関わる主要なエンティティを特定します。ここでは以下のエンティティが考えられます。

コンテンツ：制作する作品や番組の情報。
契約書：出演料や配信期間などを記載した書類。
出演者：契約の対象となる人物。
法務チーム：契約書の作成および管理を行う。

インタラクションの図を作成

ステップ4：境界づけられたコンテキストを識別する

同一名称の異なる概念の識別

「契約書」という言葉が、法務チームの作業文書と、出演者がサインする最終的なドキュメントの両方を指す場合、それらを区別します。

コンテキストの定義

各エンティティがどのコンテキストに属するかを定義します。これにより、同じ名称のエンティティでも異なる役割を持つことが明確になります。

ステップ5：モデルを生きたドキュメントとして記録する

モデルの記録

作成したエンティティやインタラクションの図を元に、モデルをドキュメントとして記録します。このモデルはシステムの生きたドキュメントとして機能し、継続的に更新されます。

記録するドキュメントの例

ユビキタス言語辞書
エンティティ図
コンテキストマップ
シーケンス図
- 具体例：

共有スペースへの保存

モデルを共有スペースに保存し、チーム全体でアクセス可能にします。これにより、常に最新のモデルを参照しながら作業を進めることができます。

ステップ6：予算とスケジュールの策定

予算の策定

システム開発にかかる予算を策定します。考慮する要素は以下の通りです。

開発費用：ITエンジニアの人件費、ソフトウェアライセンス費用など。
ハードウェア費用：サーバーやクラウドサービスの費用。
テスト費用：テスト環境の構築やテスト実施の費用。

スケジュールの策定

プロジェクトのスケジュールを策定します。以下のフェーズに分けて計画を立てます。

要件定義：ビジネスプロセスの確認とシステム要件の決定。
設計：システムアーキテクチャの設計とモデリング。
開発：システムの実装。
テスト：システムのテストと修正。
リリース：システムのデプロイと導入。

ステップ7：モデルをシステムに変換する

システム開発への移行

作成したモデルを元に実際の開発を行います。必要な機能としては、以下が考えられます。

コンテンツデータの登録・編集機能：コンテンツ製作者がコンテンツ情報を登録・編集できる。
契約書の作成機能：法務チームが契約書を自動生成できる。
電子サインサービスとの連携：契約者がオンラインで契約書にサインできる。
契約アラート機能：契約が未完了の場合に通知する機能。

システム移行後のシーケンス図

テストとデプロイ

開発が完了したら、テストを実施し、問題がないことを確認した上でシステムをデプロイします。

まとめ

本記事では、DDDにおける開発に移る前の具体的なステップについて解説しました。DDDの本質は、ビジネスプロセスを深く理解し、専門家の知識を体系的に活用してモデルを構築することにあります。このプロセスを通じて、単なる技術的な解決策ではなく、ビジネスの課題を根本から解決するようなシステムを設計できる可能性があると感じました。より価値あるソフトウェアを作るために引き続き学んでいきたいと思います。