概要
導入から20年を超えた古い業務システムは、レガシーシステムと呼ばれ、DX(デジタルトランスフォーメーション)の推進を阻害する大きな要因とされています。
レガシーシステムは古いプログラミング言語で書かれていることに加え、システム全体を把握している人やシステムそのものを保守してきたシステムエンジニアの多くが2025年までに定年を迎えるなど、第一線を離れることになり、その対応に苦慮している企業は少なくありません。
彼らのノウハウを次の世代に伝えようにも、当時のシステム開発における要件や仕様、業務知識の共有と継承は(コロナ禍の期間が数年間あったとはいえ)、思うように進んでいないといわれています。
本シリーズでは、先送りしてきたレガシーシステムの対応、特に業務仕様の可視化と共有をどうしていくべきかお悩みの方々に向けて、業務ナレッジ継承のためのデータモデリングとその有効性について、その概要をお示ししたいと思います。
図面によって現状業務のあり方や問題を共有
現状業務を可視化するには?
それでは、現状業務を可視化し、プロジェクト関係者(業務部門、情報システム部門、ベンダー)の間で共有できるようドキュメントに表していくためにはどうしたらよいので
しょうか?
業務は、「注文を受け付ける」「商品を発送する」「売掛金を請求する」…のように、複数のDO(…する)の連鎖の中で情報を流通させています。
そのため、業務の可視化・共有を行う場合、まず業務プロセスのフローを作成することから始めるプロジェクトが多いのではないでしょうか。
業務フローは業務部門の方々にとっても比較的取り組みやすいドキュメントであることは間違いありません。
しかし、業務の実態は複雑です。さまざまな業務プロセスと情報が絡み合っています。
ただ業務の「DO」の連鎖を羅列するだけでは全体を把握することはできないのです。
私たちデータ総研は、この「プロセス」に加えて「データ」も業務と情報システムの重要な構成要素であると考えています。
そして「データ」は「プロセス」と比較して、各段に“安定”していると考えます。
近年、インターネット技術の発展は消費者の購買行動モデル、具体的には「注文する」というプロセスを大きく変化させました。
しかし、店頭での買い物や電話注文やハガキによるひと昔前の「注文」と、現代のネット経由の「注文」、それぞれのプロセスにおいて「注文」という行為の中で扱うべきデータに大きな違いはありません。
プロセス自体が変化したとしても注文日時や注文金額、金額合計など、注文に必要な「データ」の多くは不変です。つまり安定しているといえるのです。
データに着目し、業務を表現する
それでは、「データ」に着目し、DO(…する)を業務として表現する方法を、「受注する」というDOを例にして見てみましょう。
「受注する」を詳しく理解し、共有するための「誰が、何を、いくつ、どこに、いくらで…」といった詳細を表現しなければなりません。
私たちデータ総研は、業務で扱う物事(もの・こと)を把握するための最も有効な手段として、「データモデル」という図面で、必要なデータとそれらの関係がどうなっているかを形式知化し、プロジェクト内で共通認識するために活用しています。
帳票や入力画面をもとにデータモデルに表す
これらのデータモデルを書き起こしていくにあたって、私たちはまず「業務入出力」のコピーを収集することからスタートします。
ビジネスは、モノやお金が動いた際に、必ず証跡(業務入出力)が残る仕組みになっています。
「業務入出力」とは出力された帳票、入力画面などを指し、ある業務のアウトプットであり、次の業務のインプットなのです。
例えばコンビニエンスストアでは、「レジで会計する」という行為に対して、“レシート”という業務入出力が残ります。
つまり、“レシート”という業務入出力を分析すれば、「店舗」・「レジ#」・「売上」・「商品」・「売上明細」・「ポイントカードNo.」・「顧客」・「店員」といった、“レジで会計する”という業務に必要なデータ項目を捕捉することができます。
このレシートにあるデータ項目をデータモデルに表すことによって、「レジで会計する」という業務の詳細を共有することができるのです。
なぜデータモデルを使うと共通理解ができるのか
それでは、データモデルという図面を共有することによって、さまざまな立場の関係者の間で業務とデータに対して同じ認識を持つことができるのはなぜか、という点についても更に説明していきましょう。
現実の世界を、ある決められた表記法(ルール)によって記号化することを「モデル化」といいます。身近なところでは、地図や建築の設計図などがあります。
これらは標準的な表記法が定まっています。そのため、その図面を見れば表現されていることについて多くの関係者の間で共通理解ができるのです。
住宅の場合、施主と設計者、施工業者は平面図、立体図、展開図といったエンジニアリング図面の上で仕様を検討し、明確にします。
業務の世界も同じように考えられないでしょうか。
「私たちの仕事はこういったデータを用いている」、「今度のデータ活用ではこういったデータが必要だ」…、情報システムの設計に必要なこれらのビジネスルールを明快な要求仕様として理解し、共有する。
つまり、現状の業務がどうなっていて、どう変えていきたいのか、関係者が同じ認識を持つためには、自然言語によるコミュニケーションだけでなく、曖昧さを排除するための図
面が必要になるのです。
とはいえ、ただ図面であれば何でも良いというわけではありません。表記のルールが曖昧なまま独自の感覚で書かれた図面は、大規模になればなるほど読む側の第三者に
は理解ができなくなります。誰が書いても同じように表現され、誰もが読めるドキュメントでなければ、いずれ使われなくなり、誰も参照しなくなってしまいます。
整理されたデータモデリング技法
データ総研のデータモデリング技法は、数人から十数人で実施するデータモデリングのプロジェクトを想定し、遂行するための手順、作成する成果物、知っておくべき知識に
ついて体系的に整理しています。データ総研のデータモデリング技法では、データモデルの管理対象の配置ルールなどが定められています。その表記例を以下に示します。
ブラッシュアップされ続けた方法論と技法
私たちデータ総研は、方法論(考え方、成果物)と、データモデリングを核とした各種技法(表記法、成果物の作り方・手順)を自社で開発し、それをお客様へ移転するコンサルティング事業を40年近くに渡って継続してきました。
そしてこのデータモデリング技法も方法論に基づいて定義されているため、他のモデリング技法にベースが変わったとしてもデータ総研の考え方を応用しやすいという特長があります。
そして、数多くのコンサルティングでの経験を基に、この方法論と技法をブラッシュアップし続けており、その成果をコンサルティングの現場のみならず、教育研修のコンテンツや
書籍において最新の知見・ノウハウとしてフィードバックさせていただくことによって、他のお客様の気づきにつながる。そのサイクルがデータ総研の事業基盤となっているのです。
連載一覧
筆者紹介
佐藤 幸征(さとう こうせい)
1998年、ビジネスデータの設計と標準化に特化した方法論に基づくコンサルティングと教育研修を事業基盤とする株式会社データ総研に入社。営業グループ配属後、2019年8月代表取締役社長に就任。国内リーディングカンパニーを中心に人材育成や組織づくりの啓蒙活動を行い、新たな時代のデータマネジメントとデータの資産価値向上の支援に従事している。
コメント
投稿にはログインしてください