データガバナンスレビュのNG例 3選

最近、データガバナンスのガイドラインを作り、システム開発や業務現場への適用を試みている企業が増えているように感じます。では実際、ガイドラインは正しく適用できているのでしょうか?残念ながら、システム設計側は、個々の業務要件や開発スケジュールを重視するあまり、ガイドラインから逸脱した設計をしたり、逸脱したまま開発したりしてしまうことがあります。これを抑止するために、データガバナンス担当者は設計成果物のレビュを実施します。この「レビュ」というプロセスは、地道な活動でありながら、データガバナンスにおいて必要不可欠な活動です。そこで今回は、筆者のコンサルティング経験を基に、システム開発の要件定義・設計フェーズにおけるデータガバナンスレビュを行う際のNG例とその対策を3つご紹介します。

データガバナンスレビュのNG例とその対策

NG1.論理設計フェーズと物理設計フェーズの成果物を同じタイミングでレビュする

例えば、論理データモデルから物理データモデルを作り終えた時点で、まとめてレビュを行うとします。これは、最終的に実装されるデータモデルも含めてレビュするので、一見効率が良く見えますが、避けた方がよいです。なぜなら、物理設計が必ずしも正しい業務要件を反映したものではない(例えば、論理データモデルでは正規化されているが、処理要件を加味して非正規化されていることなどもある)ため、本来あるべき設計がされているのかどうか、論理設計でなければ正確に判断できないからです。この時点で、論理設計が間違っているので物理設計を見直す、となると手戻りが多く、そもそも開発が進んでしまっているため、開発の遅延を避けるため修正を行わず次のフェーズに進む、なんてことが起こりえます。
対策として、事前に開発プロジェクト側とスケジュールを共有し、論理設計後にレビュを行いレビュが通らなければ先に進ませない、ということを合意しておくことが必要です。また、レビュ後の修正期間も加味してスケジューリングしておくと、なお良いです。

NG2.ガイドライン違反の指摘や改善依頼を文書でのみやり取りする

レビュ結果を文書で記載し、その文書を共有するだけで済ますことは、避けた方が良いです。なぜなら、文書のみだと、意図が伝わらなかったり、想定とは異なる対応をされてしまったりして、結果として何往復もやり取りする羽目になるからです。ガイドライン違反の理由や指摘の意図を細かく記載しても、意思疎通はなかなか難しいものです。
対策としては、文書のみではなく、関係者と対面でコミュニケーションする場を設けることをお勧めします。対面でレビュ結果を説明し、その場で修正の方向性まで認識を合わせることができると良いです。特に、データモデルのレビュ指摘内容は、どうしても文章が長くなる傾向にあります。従って、文書として言語化しつつも、データモデルを画面上で共有して口頭で補足しながら修正箇所を説明すると効果的です。一方で、単純なネーミングルールの指摘であれば、文書のみでも問題無いケースが多いです。指摘内容に合わせて対面か文書のみか、対応の仕方を変えることが大切です。
また、母国語が異なる場合、意図がより伝わりづらくなるため、単純に翻訳ツールの翻訳結果をそのままコピーして貼りつけたりせず、翻訳結果の内容が正しいがどうか確認し、通訳者も含めて対面でコミュニケーションを取ることをお勧めします。

NG3.ガイドラインを逸脱した箇所の一部だけ指摘する

開発プロジェクト側で作成された成果物のレビュ結果を記載する際、守られていないガイドラインを指摘し、具体的な指摘箇所を一部のみ列挙するだけで済ますことは、避けた方が良いです。

例)

「論理データ項目名は、修飾語+主要語+区分語の組合せで命名してください。

 例1)誤:品目上位コード   → 正:上位品目コード

 例2)誤:在庫数量(引当済) → 正:引当済在庫数量

他にもガイドラインに沿ってないデータ項目名が複数ありますので、ご確認お願いします。」
こちらの例では、開発プロジェクトに携わる人々に対して、指摘した部分以外も自力で修正してくれるだろう、と期待して、必要最小限の記述に留めていますが、設計者としては、正しく命名しているつもりのため、自分で誤りを見つけることは、なかなか難しいでしょう。その結果、再レビュ時に同じ指摘を繰り返し、レビュがいつまで経ってもクローズしない、なんてことが起きます。(筆者は、これを何度も経験してきました…)
対策として、一つのガイドラインに対して具体的な指摘が複数ある場合、まずは、具体的な指摘対象を全列挙することを推奨します。一時的にデータガバナンス担当者の負荷は増えますが、レビュの往復回数が減り、成果物の質が向上することで、最終的には双方の負担が軽減します。また、どの指摘事項が完了したかを簡単に確認できる利点もあります。
初めのうちは、上記のような細かい指摘が必要ですが、いつまでもガバナンス担当者が全件チェックすることは現実的ではありません。事前にガイドラインの説明会を開催したり、レビュの中で繰り返し説明したりして、開発プロジェクトメンバーにガイドラインの内容をしっかりと頭に入れてもらうことも大切です。

データガバナンスレビュは、めげずに、コツコツと

データガバナンスのガイドラインを作成し、ガバナンス体制を整備し、運用手順を定めることで、データガバナンスの活動がスムーズに進む、と思われるかもしれませんが、実際はそう簡単ではありません。運用を開始すると、予想外の困難が生じ、心が折れそうになることも少なくありません。それでも、データガバナンスを担当される方は、あるべきデータアーキテクチャの実現や高品質なデータ提供など、データマネジメントにより目指したい姿の実現に向けて、本ブログでご紹介したNG例も参考にしつつ、めげずに、一歩ずつ、着実に、データガバナンスの取り組みを進めていただきたいと思います。

弊社では、データガバナンスに関する研修や、データガバナンスの企画立案から運用までのご支援など、さまざまサービスをご提供しています。ご興味・ご関心のある方は、こちらのリンクから詳細をご確認ください。

データガバナンスサービス
https://metafind.jp/service/datagovernance/

データマネジメント・アカデミー データガバナンススキーム構築コース
https://metafind.jp/education/data_management_academy/data_governance/