既存のシステムで、データ抽出や集計がうまく機能していないということは発生していないでしょうか？
私はその原因の一つに心当たりがあります。それは、マスタ項目に登録されている情報に一貫性がないため集計軸としての役割を果たせていないということです。
情報の一貫性を保つためには、一定のルールのもとマスタ項目を登録や更新して行く必要があります。そのルールを定める方法としてご提案したいのが「共通用語の定義」です。
長い期間をかけて開発したシステムを精度高く価値あるものとして長く使うことができるかどうかは、共通用語の定義づけにかかっていると言っても過言ではないと、システム開発に５年間業務部署のメンバーとして参加したことで強く感じております。参加したプロジェクトについてはこちらの記事をご覧ください。
この記事では、定義づけに必要な観点をこれまでの経験から実際の例題を用いながら解説していきます。
地味で、手間のかかる作業ではありますが、価値のあるシステム開発とその先の高度なDX推進を実現するには重要なパートですので、是非参考にしてみてください。
共通用語とは
そもそもただの「用語」と表現するのではなく、「共通用語」としたのは社内的な意識づけのためでした。用語ではダメということではなく、社内の誰もが同じ認識でいるために、必須の情報だという事を周知するために、あえて共通という言葉をつけています。要件定義では、業務側がシステム部署・システム会社様に対して要望を伝える場になりますが、何度も業務の内容について質疑が行われます。その中で、使われる言葉は世間一般的に使われている言葉かもしれないし、社内でしか使われていない言葉かもしれません。要件定義の場で、一般的な意味合いと異なる使われ方をした用語を用いることで、システム会社様には本来とは違う受け取られ方をしてしまう可能性もあります。
共通用語は、業務部署が説明・要望している事項がどんな意味を持つのかを正しく伝えるためのツールとして機能します。
共通用語の定義づけとは
「共通用語を定義する」ということは、その言葉の解像度を上げることを意味します。
解像度を上げるとは、あいまいな表現をやめ、具体的で詳細な言葉を使うことであり、誤解が減ることや情報が正確に伝わる状態にしていくことを実現することができます。
企業の中での用語は、世間一般的に使われる用語と同じ意味合いのものもあれば、解釈や見方が一般的な認識とは若干異なる場合もあるかと思います。さらには、解釈や見方の違いは企業単位だけではなく、業務部署単位、個人単位でも発生します。
共通用語の定義づけは、用語が持つ情報を具体化し、用語を使う人同士が同じ意味合い・尺度で会話することで認識齟齬を発生しづらくすることが可能になります。
先の例はとてもわかりやすい例ですが、社内の様々なところで認識齟齬が発生している可能性があります。
認識のズレは、システムでも簡単に検知できるわけではありません、業務部署が何を管理したいのかを一つ一つの言葉を丁寧に整理し、明文化することで初めて共通の認識とすることができます。
共通用語の階層イメージ
用語は大きく3つの階層で整理をしていきます。
- 管理対象：一つあるいは複数のキーで、括ることが可能な情報の塊のこと
- データ項目：管理対象の中にある特定の言葉で認識が可能な情報のこと
- コード：データ項目が持つ選択肢あるいはフラグの情報のこと
全体的な粒度としては、管理対象＞データ項目＞コードの順です。
管理対象を「商品」とした時の例題でご説明していきます。
「商品」という管理対象の中に、JANコード、カテゴリー、サイズ、などのいくつかの「データ項目」を持つことになります。
中でもカテゴリーのように社内で決められた情報の選択肢がある場合は、「コード」として定義を書き出します。
共通用語への定義づけ例
記入方法をご紹介した後に、先ほど同様「商品」を例に取って実際の定義の仕方をご説明していきます。
あくまで一例ですので、独自に記載したい項目の追加や後述の例までの情報は不要という場合には、アレンジをしていただければと思います。
どのように書くかも重要ですが、あくまでも目的は、一貫性を保ち認識齟齬が可能な限り発生しない状態とし、要件定義・システム開発・実運用で精度の高い情報管理を行うことです。
定義の記入方法例
記入方法の例の｛ ｝にご自身で検討された内容を入れていただくことで、各共通用語で統一の表現にすることが可能です。
これ以上の情報を記載してはいけないということではなく、基本的な情報として以下の記載を目安としてください。
| 検討する項目（定義によって明確になる内容） | 記入方法の例 《定義によって得られること》 |
|---|---|
| 意味説明 | ｛管理対象｝とは｛企業として管理対象をどのように捉えているのか｝である。 その他管理対象に関連する情報の取り扱いについて補足があれば記載する。 《全社的な共通の意味合いでの認識》 |
| 範囲 （情報の左右範囲の設定） | ｛情報として抽出やデータ集計軸として横並びで管理したい部分まで｝を対象とし、｛類似しているが横並びで捉えたくない部分｝は対象外とする。 《情報の捉えかたの枠組み》 |
| 粒度 （情報の上下の設定） | ｛管理対象を認識したい作業工程などの構成単位の粗さ、大きさの｝単位とする。 《情報の捉えかたの枠組み》 |
| 用途（必要性） | ～の為に使用している/必要としている。 《情報の必要性の認識》 |
| ライフサイクル （情報の保持期間） | ｛いつ・どんな時｝に｛誰によって｝生成され、｛いつ・どんな時｝に消滅する。 《情報をデータ的にいつからいつまで保持をする必要があるか、更新されるのか認識》 |
| 管理責任業務部門（情報の精度担保する担当） | ｛誰が管理をするのか｝ 《一貫性を保つ責任が誰にあるのかを明確にし、管理者の主体性を促す》 |
| 発生量 （情報のボリューム） | ｛どのタイミングにどのくらいの量発生するのか｝ 《情報の登録や更新時のボリュームでシステム的なスペックの検討がつく》 |
上記のようなルールに則って定義づけをしていきます。業務的にどのような視点で管理をして行くかを明確にして行くのとともに、システムとしてスペックの目安を検討するに必要な情報量の把握にも利用をすることが可能となります。
管理対象 例：商品
小売業における「商品」の定義記入例をご紹介します。
あくまで例題であることをご認識ください。商品といっても「業種によっても」「企業によっても」定義は異なりますので、ご注意ください。
| 検討する項目 | 記入例 |
|---|---|
| 管理対象の意味説明 | 商品とは、一般的な商品の概念「お客様に価値を提供するモノ・サービス」である。 社内での各業務が取り扱うすべての商品を対象とし、業務共通の情報をもつ。業務固有の情報は、業務機能別の管理対象（店舗販売商品、輸入商品、EC商品）にもつ。 |
| 管理対象の範囲 | 有形商品と無形商品は対象とし、備品と販売が伴わないサービスは対象外とする。有形商品とは、手に取ることができるモノである。無形商品とは、工事など、手に取ることができないサービスである。 |
| 管理対象の粒度 | 商品はSKU単位で、JANコードによって識別される。 SKUとは、POSを通す最小の単位である。 お客様に価値を提供する最小の単位でもあり、お客様に役に立つモノ・サービス・機能を果たす単位でもある。 JANコードは14桁で管理し、GTINの原則に従い発番される。 |
| 用途 | 商品を販売する為に登録する。 |
| ライフサイクル | 商品取引契約の締結で商品マスタが登録される際に生成され、商品取引契約の終了で消滅する。 |
| 管理責任業務部門 | 商品部 |
| 発生量 | 週数百～数千SKUを想定。 |
データ項目 例：カテゴリー
データ項目は、管理対象に含まれているマスタ項目の事を指します。
今回は、商品に含まれる「カテゴリー」を例にして紹介します。
| 検討する項目 | 記入例 |
|---|---|
| データ項目の意味説明 | カテゴリーとは、お客様の生活シーンを基準に商品をカテゴライズした単位である。ただし、カテゴリー別の売上報告を財務会計上も使用されるため、財務観点でのカテゴライズも意識する。 |
| データ項目の範囲 | 自社が扱っている商品全てをカテゴライズする。 管理をする対象範囲は、「商品」に準ずるものを対象とする。 |
| データ項目の粒度 | 自社が定める商品政策の区分にしたがい管理される。商品政策は、企業の方針による。 |
| 用途 | 財務部は、財務諸表のカテゴリー、資産評価方法に基づく商品のグルーピングの為に使用する。 商品部は、棚の配置や棚割り、売上や利益把握のために使用する。 |
| ライフサイクル | 一年に一回組織変更のタイミングに合わせてカテゴリーを見直す。 商品部でカテゴリー案を作成し、会社上層部にて判断される。 |
| 管理責任業務部門 | 商品部 |
| 発生量 | 原則、10カテゴリーで管理し、定期的な増減はない。 ただし、商品カテゴリの毎年の見直しや新規業態の発生によって、数件程度の増減はありうる。 |
コード 例：カテゴリーの区分値
コードは、各データ項目の区分値（選択肢）やフラグが対象です。
先のデータ項目で説明をした「カテゴリー」のコードを例にとって記載をして行きますが、管理対象定義とデータ項目よりも記載する情報は少なくなっています。
| コード | 内容 |
|---|---|
| 01：日用品 | 日用品とは、日常生活に欠かせない品物で、清潔を保つ目的で使われる品物、 生活必需品、食料品や衣料品などを除いた消費財を指します。 例：洗剤、石鹸、ティッシュペーパー、トイレットペーパー |
| 02：雑貨 | 雑貨とは、日常生活に使うこまごまとした品物や、あまり高価でない雑多な商品を指します。 例：文房具、キッチン用品、アクセサリー、インテリア |
| 03：家具 | 家具とは、家屋や室内で日常の生活を営むために使用する道具類を指します。 インテリアとの違い：家具は日常の衣食住のための道具類で、インテリアは室内装飾や室内調度品を指します。 |
| 04：内装 | 内装品とは、建物や室内の内部の仕上げや装飾、付随する設備などを指します。 |
コードにおける情報量が「管理対象」と「データ項目」より少ない理由は３点
- 情報の流動性が高いため細かな定義づけをしても使わなくなることが多い。
- 選択肢やフラグを管理するものなので、頻繁にデータ量が増えて行くような内容ではないため。
- 何を指しているのか？何を含み、何が含まれないのか？さえわかれば十分だから。
「先ほどまでの管理対象やデータ項目のような記述をしてはいけない」ということではありません。
始めに述べたように定義づけは認識のブレが発生しなくなることが目的ですので、こだわりすぎて実際のシステム開発に辿りつかないとなってしまっては本末転倒です。
共通用語の定義は、回りくどい言い方に見えると思いますが、その用語において定めたい情報と除外したい情報を記述していくと自然と記載することは多くなります。定義があいまいだと本来の管理からズレていってしまう可能性が高くなります。業務的なトラブルが発生する可能性はもちろん、集計軸としても機能せずデータ活用がうまくできませんので、DX推進からも遠ざかっていくこととなります。一つ一つの項目、言葉に注意を払って一貫性のある定義をすることで、長く、価値ある仕組みづくりのベースを作りましょう。
まとめ
共通用語の定義づけは、システム開発やDX推進の成否を左右する重要な取り組みです。
マスタ項目を一貫した基準で登録・更新するため、情報のブレが抑制され、集計や分析の精度が大幅に向上します。
言葉の解釈や意味があいまいなまま運用すると、各部署で異なる基準でデータが登録される危険があります。
その結果、集計軸が機能せず、必要なときに価値ある情報が取り出せなくなり、システムの真価が失われます。
一方、共通用語を丁寧に定義すると、誰が見ても同じ意味でデータを扱えるようになり、プロジェクト全体の効率を高められます。
「商品サイズ」という単純な言葉でも、物流部門では輸送・保管サイズ、商品部では陳列・使用時のサイズと認識が異なります。
この差を放置するとマスタ項目が分散して、本来の目的と違うデータが混ざり合う恐れがあります。
しかし、上記のように管理対象・データ項目・コードを明確に分け、対象範囲や粒度などを記述することで、部署を超えた一貫性ある情報を保てます。
共通用語を定義してマスタ項目を整理することで、集計軸が明確になり、DX推進を加速させる環境が整います。
「当たり前すぎる作業」に見えますが、手間をかけることで企業や部署を超えてデータを有効活用する土台となるため、非常に価値あるステップです。
いま一度、自社のマスタ項目や用語の定義を見直してみましょう。
誰でも同じ意味で使えるデータの基盤を築き、システム開発とDX推進を成功に導いてください。
