「定義は細かく書くほど丁寧」と思っていないか。その思い込み、現場を混乱させる原因になっている。EA（エンタープライズアーキテクチャ）の推進に10年以上携わってきた経験から断言する。定義はシンプルに書け。

EA現場で定義をシンプルに書くべき理由

定義というのは、運用を回し続けるための拠り所だ。一度作ったら長く使い続けるものであり、普遍的であることが前提になる。

ところが細かく書けば書くほど、実態データとの矛盾が生まれやすくなる。

現場では、すべてのデータを精査してから定義を作るなんてことはできない。大枠を決めて運用を回しながら、実態に合わせて判断していくのが現実だ。そこに細かい条件や例外を書き込んでしまうと、「この考え方ではAに分類されるが、別の考え方ではBになる」という矛盾が普通に発生する。

シンプルな大枠であれば、判断に迷ったとき「原則に立ち返る」ことができる。細かい定義は、その原則を見えにくくする。

「具体例の多用」が定義を劣化させる

定義を補足しようとして具体例を大量に入れる人がいる。気持ちはわかるが、これも慎重にやるべきだ。

具体例には2つのリスクがある。

  1. 具体例自体が理解されない問題
    現場に浸透していない事例を具体例として使うと、定義ではなく具体例の説明から始めなければならなくなる。本末転倒だ。
  2. 具体例が増えるほど周知コストが上がる
    例が多ければ多いほど「結局どれが基準なの？」となる。ノイズが増えて、かえってわかりにくくなる。

具体例を入れるなら「間違いやすい例」だけに絞れ。「こういうデータはAではなくBに分類する、なぜなら〜」という形で、迷いが発生しやすいポイントだけを補足する。それ以外は入れない。ノイズを排除することが、定義の質を上げる。

「大枠定義＋間違いやすい例」が現場で最も機能する

自分が実践してきたのは、このスタイルだ。

  • 大枠の定義：誰が読んでも「こういう考え方ね」と理解できる、シンプルな原則
  • 間違いやすい例：現場でよく迷うパターンを厳選して補足

いくつか具体的なイメージを挙げておく。

コスト管理の定義であれば、「どの費用をどの区分に入れるか」の原則だけを書く。そして「システム保守費はここ、ライセンス費はここ」という、迷いが発生しやすいケースだけを例として添える。

データ項目の定義であれば、「この項目に何を入れるか」の概念だけを書く。「売上日付は請求日ではなく計上日を入れる」のような、現場でよく混同されるパターンだけを補足する。

用語定義であれば、「この言葉が指す範囲」を一文で書く。「顧客にはエンドユーザーを含むが、代理店は含まない」といった、境界線が曖昧になりやすい箇所だけを明示する。

このスタイルで定義を作ると、面白いことが起きる。大枠については誰も文句を言わない。教科書的に考えれば誰でも同じ結論になるからだ。議論が起きるのは各論・細部だけで、そこは運用の中で対応できる。

EAチームに求められるのは「傾聴」と「個別対応」

シンプルな定義で運用を回すとき、避けられないのが「このデータはどっちに入るの？」という個別の問い合わせだ。これは定義が曖昧なのではなく、定義が正しくシンプルだから発生する、健全な問いだと思っている。

EAチームはこうした問い合わせに対して、組織全体をセントラルに見る立場から個別対応を担う。いわば定義の番人であり、現場と定義をつなぐ通訳者だ。

ここでEAチームに求められるのは、2つのスキルだ。

傾聴：現場が何に困っているのかをきちんと聞く。相手の業務文脈を理解せずに「定義通りです」と返すだけでは信頼を失う。

相手の立場に立つ：その人の業務でなぜ迷っているのかを理解した上で、「この定義の考え方に基づけば、こちらになります」と丁寧に示す。

個別対応の積み重ねが、定義の実効性を高めていく。定義はドキュメントではなく、運用を通じて育てていくものだ。

データ定義・用語定義・業務ルール、すべてに共通して使える

データ定義・用語定義・業務ルール定義――どれも同じだ。「大枠で原則を押さえ、間違いやすい例で補足する」スタイルは、定義の種類を問わず有効だ。

細かく書くほど現場が動きやすくなるという幻想は捨てたほうがいい。現場が動きやすくなるのは、迷ったときに立ち返れる、シンプルな原則があるときだ。

本ブログでは、EAの推進に必要なシステム台帳の整備や経営IT連携についても継続的に発信している。あわせて読んでいただけると、より全体像が見えてくるはずだ。

あなたの現場では、定義を細かく書きすぎて混乱が起きた経験はありますか？ぜひコメントで教えてください。

筆者：EAの中の人｜事業会社の社内IT部門にてエンタープライズアーキテクトとしてEA推進・ITガバナンス・データ活用・AI活用に携わって10年以上。
本記事の内容は個人の見解であり、所属組織を代表するものではありません。