概要

コンテキストマップで整理されたコンテキストについて、なぜそのような切り分け方をしたのか、切り分ける意味が何かといったことを開発者以外にも伝えたい、という課題があった。

そこで本稿では、「境界づけられたコンテキスト」について、開発者以外にも伝わるような説明を試みる。

コンテキストの違いを意識する

同じ言葉であっても、コンテキストが異なれば言葉の意味が変わることがある。

例えば「注文」という言葉を例に挙げる。

営業部門では「お客様からの依頼」を指し、倉庫では「出荷の指示」、会計部門では「請求対象のデータ」を意味するかもしれない。

他にも以下のような例がある。

• 「ユーザー」：開発チームではログインする人、カスタマーサポートでは問い合わせをしてくる人、マーケティングではターゲット顧客を指す
• 「サービス」：技術者はAPIを、営業は顧客向けプランを意味する

このように、同じ言葉でも使われる業務や立場によって意味が変わる。

この違いを明確にするのが、「コンテキスト」という考え方である。

コンテキストとは

コンテキストとは、言葉やルールの意味が一貫して通用する業務のまとまりのことである。

ドメイン駆動設計（DDD）においては、これを「バウンデッドコンテキスト（Bounded Context）」と呼ぶ。

例えば「注文」という言葉も、コンテキストによって意味が以下のように異なる。

• コンテキストAでは、顧客の購入意思
• コンテキストBでは、倉庫への出荷依頼
• コンテキストCでは、請求の対象

このように、それぞれの業務で言葉の意味やルールが変わるところを「区切って」扱うのが、コンテキストの特徴である。

なぜコンテキストを整理するのか？

このコンテキストを意識せずに業務を進めたり、システムを設計したりすると、さまざまな問題が発生する。

• 「注文」テーブルに請求や出荷の情報まで詰め込んだ結果、複雑で壊れやすいシステムとなる
• チーム間で「○○ってどういう意味？」という質問が飛び交い、認識齟齬や責任の不明確さが生じる
• 業務改善をしようとしても、影響範囲が読めず手が出せない

逆に、コンテキストを分けて整理しておけば、以下のようなメリットが得られる。

• 言葉の意味が明確になる
• 業務やシステムの責任範囲が整理される
• チームの分担や変更がしやすくなる

つまり、コンテキストが適切に整理されることで、システムや組織は次のような恩恵を得ることができる。

• コミュニケーションコストの削減
• システムの設計や実装の複雑性の低減
• チーム間の役割分担や責任範囲の明確化

正しくコンテキストが整理されていることは、システムと組織の両面における安定性の向上につながる。

コンテキストの例：ECサイトの「注文」

ECサイトの注文に関する業務を、3つの部門に分けてみる。

これらはいずれも「注文」という言葉を使っているが、扱っている内容・目的・処理がまったく異なる。

この違いを無視してひとつの言葉でまとめてしまうと、

• システムは複雑化する
• 修正時の影響範囲が不明になる
• 誤解が生まれやすくなる

だからこそ、「コンテキスト」を分けて考えることが重要である。

開発者だけの話ではない

コンテキストは、開発者だけが理解していれば良いものではない。

例えば以下のような疑問に思い当たることはないだろうか？

• 「うちのチームはどこからどこまでが担当なのか？」
• 「これは営業に聞くべきか？開発か？サポートか？」
• 「この変更はどこに影響するのか？」

こうした問いは、すべてコンテキストの整理と密接に関係している。

業務の目的や言葉の意味が変わるところに境界を引き、その境界ごとに役割や責任を明確にする。

この視点は、開発者に限らず、営業、サポート、企画など、あらゆる職種にとって有益である。

まとめ

• 同じ言葉でも意味が異なることは多い
• その意味の違いに気づき、業務やシステムの境界として整理するのが「コンテキスト」である
• コンテキストを明確にすることで、認識のズレやシステムの複雑性を防ぐことができる
• チーム間の役割分担や業務改善にもつながる、全職種にとって有効な考え方である