RDBは人生に効く
はじめに
この記事は「会計系 Advent Calendar 2024」12月21日担当の招き猫.mdbの記事となります。
今年も企画頂いたblanknoteさん、ありがとうございます！
昨日のじゅんしさんからタスキを受け取り、明日はblancoさんの記事になります。
終盤も素晴らしい記事の連続です！
お見逃しなく！
あらためまして、招き猫.mdbと申します。
メーカーでSAPを使った原価計算の実務を10年以上やっています。
使われている方はご存知かと思いますが、SAPというシステムは小回りが効かないため、サブシステムを構築してデータ分析を行うことがとても多いです。
私にとってのサブシステムは過去の担当者がAccessで自製したDBでした。
皆さんは、RDB（リレーショナルデータベース＝関係データベース）というものをご存知でしょうか。
ご存知ではない方のために簡単に説明すると、RDBとは、「データを複数の表で管理し表と表の関係性を定義することで複雑なデータの関連性を扱えるようにしたデータベース形式」のことです。
IBMのエドガー・F・コッドが考案し、現在もっとも広く用いられるデータモデルとなっています。
これだけでは、システムに馴染みのない人はイメージがつかないと思いますので、まずはExcelのvlookup（もちろんxlookupでもOK）をイメージしてもらえればよいと思います。
関連する項目同士を繋げて、別表からデータを持ってきて表を加工する、最初はそのイメージで構いません。
「DB？えっ、ドラゴンボール？正直、世代じゃないんであまり読んでないです。」って人は、ちょっと待ってください。
貴方が気付かないうちに貴方の周りはDBで溢れています。
会計もRDBを作る仕事です。むしろ会計はRDBの一つなのです。
私はMicrosoftが提供しているRDBソフトであるAccessを15年以上使ってきました。また壮大なRDBで構築されたERPソフトであるSAPも同様に使ってきました。
そのような経験から得た教訓として、RDBを構築するフローは、少なくとも物事を整理する上で強力なフレームワークになるということです。
システム開発に活用できることはもちろん、実際に仕事をする上での状況整理にも役立っています。
そこで、今年の記事は、データベースをあまり知らない人向けに、AccessでRDBを開発する過程をざっくり説明しながら、RDBの考え方とその実践について解説を試みたいと思います。
「なんで今更Access？」という意見もあると思いますが、Accessは古いソフトだけあってRDBに必要な要素が詰まっています。
XにはAccessに故郷を焼かれた人たちも沢山いらっしゃるみたいですが、本記事のテーマはAccessの具体的な使い方ではなく、またAccessそのものを推奨している訳ではないので安心してお読み下さい。
注意:
本記事で解説するAccessの使い方は、説明の都合上、データ同士を繋げて必要な形に組み換えるETLツールに近いものとなります。
Accessには履歴データを累積させて台帳として管理する使い方も他にありますが、本記事では触れていません。またレポートという帳票出力機能についても触れていません。
全体構成
Accessには下記の基本的機能があります。
それぞれの機能を順番に設定することでDBが完成するため、設計図となるER図の作成も含めて上から順に解説しています。
その際、経理としてのシステム開発における実務やRDBの構造的な考え方にも触れています。
・設計図の作成＝ER図の作成
・必要情報の整理＝テーブルの作成
・アウトプットの決定＝クエリの作成
・処理手順の整理＝マクロの作成
・業務の可視化＝フォームの作成
では、以下より本格的にスタートです!
※今年も去年ほどではないですが、長いです。
（約15,800字）
Accessにそれほど興味のない方は6章だけでも読んでもらえると嬉しいです。。
1 RDBの設計図を作成しよう＝ER図の作成
まずは、RDBの設計図となるER図の作成です。
ER図とは、E（エンティティ＝事実）と、R（リレーション＝関係）の組み合わせでシステムのデータやデータ間の処理構造を示す図になります。
簡単に言うとRDB内のデータ間の繋がりを示す図です。これがないとシステムの全体像とデータの流れが見えないため、システムを構築できません。
一般的な経理担当者にとっては、馴染みのない言葉だと思いますが、とても重要な図です。
1-1 システム開発における要件定義の重要性
システムの開発においては、よく要件定義が重要だと言われます。要件定義を前提に次工程のシステム開発に移るからです。
しかし、この要件定義が曖昧なままスケジュールの都合で開発フェーズに移ってしまうPJも多々あります。
ベンダーはシステムそのものには詳しいですが、ユーザーの業務のことは分かりません。
要件定義のフェーズで、データの関係性や業務の流れをベンダーに正確に伝えないと、開発フェーズで想定と全く違う仕様で作られることもあります。
要件定義をより良いものにするために、事前にER図をユーザー側で書くことをオススメします。
ER図は要件定義に必要な業務データの関係性を図解するものとなります。そのため、ユーザー、ベンダー双方で齟齬のない業務の理解にとても役立ちます。
ユーザー側が、既存業務を理解する上でも役立ちますし、ベンダーに最低限守らないといけないシステムの必須要件を明確に伝えることができます。
1-2 ER図の書き方
具体的な書き方としては下記になります。
① 業務要件の定義
まず、そのシステムの目的や関係者、必要情報、アウトプットを時系列に沿って簡単に整理します。
目次に記載したセグメント別在庫明細の例であれば、以下の通りとなります。
目的：事業部における品目別セグメント別在庫情報の把握
関係者：経理部、情報システム部門
必要情報：原価システム→原価情報及びセグメント情報
在庫システム→棚卸数量明細
アウトプット：品目別セグメント別在庫金額明細
処理時期：月次で事業部門へ4営業日目に開示する。
② Entityの特定
次に登場するデータ（Entity(エンティティ)と言います。）がどのような情報を持っているのかについて記載していきます。
③ 関係性の記述
それぞれのEntityで共通する項目を結びつけ、関係性を把握します。なお、この共通する項目（キー）を繋げることをリレーションと呼びます。
この段階で更に下記も整理できるとベストです。
・データの多重度（そのEntityにキーとなる項目が重複して存在するか）
・時系列に沿った実際の業務フロー
・それぞれのEntityがどのように作られるのか（別システムからデータを持ってくる場合もあります。）
なお、ER図はあくまで設計図で後工程で必要情報が追加される場合も多々あります。その場合は、ER図を都度更新することをおススメします。
1-3 ER図は構造的な思考ツール
慣れてくるとシステム導入や新しい業務フローを設計する場面で、関係者の情報がどう繋がっていくのか意識しながら、考えることができるようになります。
ER図はシステム内のデータの関係性を整理するために書くのですが、普段の業務メモにも十分活用できます。
私は実際に新しい業務に取り組む時は、簡単なER図を頭に思い浮かべて、作業それぞれの関係性を意識した業務整理をするようにしています。
ER図はメモリーツリーと似た繋がりを示す図法ですが、各エンティティの中のどの項目が具体的に繋がっているのかを記述できるため、記憶に残りやすく、個人的にとても気に入っています。
2 必要な情報を整理しよう＝テーブルの作成
次はテーブルについてです。
テーブルとは、データが詰まった表のことです。
単純なDBでは、ER図で記述したEntityがほぼそのままテーブルとなります。
RDBは表と表を関連項目で繋げてアウトプットするため、その元になるテーブルは重要です。
2-1 テーブルのデータ型
DBで使うテーブルは、Excelの表と異なり各フィールドに入力するデータの型が明確に決まっています。
数字型のフィールドには文字型は入れられません。一見不便に感じますが、データ入力の統制を保つためには必要な機能です。
データベースは日々変化する業務を複数人で管理する前提で構築されるため、入力ルールは厳格でなければなりません。
例えばExcelで予算の入力表を各部門に配った場合、ユーザーの入力統制で悩む方は結構いらっしゃると思います。
数値欄に文字を入れられたり、余計な行挿入をされたり、数式を壊されたりetc…
Accessの場合、テーブルのフィールドに入力できる内容の制限が比較的容易にできる仕様となっています。
2-2 テーブルのデータ連携（データはどこから来るのか）
Accessのテーブルを作る際にテーブルを直接入力することもできますが、別のシステムやCSVファイルを取り込んでテーブルにすることも出来ます。
マスタデータなどは基幹システムから常に最新のマスタを連携することをオススメします。
Accessの場合、他のAccessやSQLServerからリンクテーブルとして連携することも出来ます。
Access自身にマスタデータを手入力する例もなくはないですが、基本的にデータは外部システムからの取り込みの方が良いです。
人の手を介在させた連携の場合、更新忘れや処理ミスの可能性が残ります。また元データが変更になる度に手入力による修正作業が必要となり業務負担が増える懸念もあります。
2-3 テーブルの正規化
次にRDBにはどのようなテーブルを持たせるかですが、RDBでは、ざっくり、DBが対象とする業務の事実が蓄積されるファクトテーブル（明細）とファクトテーブルのデータを一意に識別するためのディメンションテーブル（マスタ）に分かれます。
テーブルを何故、わざわざ明細とマスタに分けるのかというと、RDBは日々変化する業務に対して複数の人間で協働して使うことを前提としているからです。
例えば、仕入先別残高を管理するテーブルに対して、仕入先名の変更があった場合、関連する明細テーブルを全て手入力で変更する必要が出てきます。
また取引がない仕入先をシステムに登録することも出来ません。
しかし、仕入先名マスタを別に分けて、仕入先IDを設定して、主キーとして明細テーブルと繋げた場合、マスタの名称が変われば、常に最新の仕入先名を複数の明細テーブルに表示させることができます。
このように明細を一意に定義できる（関数従属と言います）マスタ項目を別テーブルに分ける作業を正規化と呼びます。
正規化によって明細の累積とマスタの更新を別々の工程に分けることが可能となり、最新のマスタ情報を明細にタイムリーに表示することも可能になります。
なお、この正規化には元の明細データに余計なデータを持たせないようにして容量を節約する意味もあります。
2-3 主キーについて（データの重複）
正規化は、マスタ1に対して明細が多の関係性を保つように各テーブルを作ることが基本です。
この時、マスタと明細を繋ぐ項目を主キーと呼びます。
マスタの主キーは必ず一意でなければなりません。主キーとなるコードが重複して存在するとマスタとリレーションさせた明細データの出力が重複するからです。
後述するクエリで金額集計した場合、マスタの主キーが重複していることデータ出力が倍になることは、Accessに慣れていない時はよくあるミスです。
このような事故を防ぐためにAccessではテーブルに主キーを設定して、同一コードを入力できないようにする機能もあります。
しかし、自分が出力した結果の値が元データと合致しているかを確認することはあらゆる仕事における基本動作の一つです。これは何もAccessに限った話ではありません。
データ加工時の何らかのミスで集計を誤ることは、Excel作業でも起こり得ます。
どのような仕組みを使ったとしても前工程と後工程で理論上、金額が合致するのであれば、まず最初にそれを確認すべきです。
理論的に円単位で合致するはずのものが、1円でも合致しない時は何か不具合が生じています。
マスタの問題か、
集計条件の問題か、、
些細な金額だからと、気にせずにそのままスルーする人がいますが、論理的に間違っている内容は絶対にそのままにしてはいけません。理由を一つ一つ徹底的に検証することは重要です。
特にシステム開発の場面では、社内SEやベンダーは、計数的なあるべき姿を持っていないため、ユーザー側でエラーを100%潰すという姿勢を持った方がよいです。
調査後のシステム改修は、当然ベンダーにやらせなければなりませんが、エラー発生時の画面のスクリーンショットと合わせて、機能とデータの構造から考えられるエラー原因をベンダーに積極的に伝えることでスムーズな開発が進められることは多いです。
システム開発はベンダー任せにせず、エラー検証を中心に主体的に取り組むべきです。
2-3 スタースキーマ
先程、1対多の関係性について触れましたが、1対多の関係性を説明する際に欠かせないテーマの一つがスタースキーマです。
スタースキーマは、データウェアハウスやデータマートの設計手法の一つで、データの分析やレポート作成を効率的に行うためのデータの持ち方のことです。
スタースキーマは、主要な数値データ（例: 売上、高さ、量など）が記録されているファクトテーブルと分析の基になるマスタ（属性データ）を持つディメンジョンテーブルに分かれます。
ここで重要なことは、 ディメンションテーブルとファクトテーブルが1対多の関係にあるように設計しているということです。
多数の数値データを持つファクトテーブルを中心に、数値データを一意に識別するディメンジョンテーブル（マスタ）を星型に配置することで、視覚的にも理解しやすい構造をとっています。
単にわかりやすいだけでなく、スキーマ（関係性）がシンプルなので、データベースでの集計処理が高速で効率的に実行でき、分析の目的に応じて、必要な情報をすぐに取得できる設計になっています。
スタースキーマは、データ分析を効率化するための強力な設計手法であり、特にBIツールを構築する上で広く使われています。
単純でメンテナンスしやすいため、今後、RDBを構築する際には第一に選択すべきテーブル設計となります。
2-5 テーブルは情報の整理
テーブルは情報の整理です。
テーブルが持つ情報（属性とデータの出所）、データ間を結ぶキーが明確になっているからシステムが成立します。
これは業務の前提を整理することと同じです。
現実の世界でも、業務の前提が曖昧であれば、お互いの業務を理解した複数人の分業は成立しません。
どこから来た、
どのような情報を、
どういう形で保持するのか、
それが他者の業務とどう繋がるのか
前提を理解するための重要性をテーブルは示しています。
3 具体的な処理を決めよう＝クエリの作成
次はクエリです。
クエリは複数のテーブルを組み合わせて新たなアウトプットを作るデータベースの根幹的機能です。例えば、明細とマスタを繋げてマスタ項目を表示させた明細テーブルを作ることが出来ます。
RDB内のデータ加工作業はこのクエリで行います。一つの明細に複数のマスタを繋げて多項目の切り口のデータ出力を実装したり、計算ルールによる加工したデータを作ることが出来ます。
ほとんどのRDBは様々なクエリの繰り返しで構築されています。
クエリはデータを特定の条件で集計、明細へのデータを追加、新たなテーブルの作成など、多彩なアクションが可能です。
3-1 クエリの種類
ER図に近い形でテーブルをリレーションさせて抽出項目を設定する
1. 選択クエリ (Select Query)
一番オーソドックスなクエリです。
データを検索し、特定の条件に基づいてレコードを取得します。
テーブルからデータを読み取るだけで、データを変更しません。
表示するフィールドや記録を選択するための条件を設定できます。
データの集計も可能で、例えば合計や平均を計算することができます。
2. 更新クエリ (Update Query)
既存のテーブルを更新するクエリです。
特定の条件に基づいて、あるテーブルの1つ以上のフィールドの値を変更できます。
一度に複数のレコードを更新することが可能です。
更新されてしまうと元には戻せないため、更新するデータの確認や、誤ってデータを変更しないためのバックアップが推奨されます。
大事なことなのでもう一度言います。
更新されてしまうと元には戻せないため、バックアップが推奨されます。
3. 追加クエリ (Append Query)
新しいレコードを既存のテーブルに追加するクエリです。
他のテーブルからデータを取得し、それを新しいレコードとして指定したテーブルに挿入します。
追加するデータに対して条件を設定し、特定のレコードだけを追加することもできます。
一度に多数のレコードを追加可能で、データのバッチ処理が行えます。
4. 削除クエリ (Delete Query)
特定の条件に基づいて既存のレコードを削除するクエリです。
指定した条件に合致するレコードを一括して削除します。
削除する前にデータのバックアップをとることが強く推奨されます。
データテーブルから完全にレコードを取り除くため、元に戻すことができません。
くどい様ですが大事なことなのでもう一度言います。
更新されてしまうと元には戻せないため、バックアップが推奨されます。
（…本当に戻せないです。）
5.テーブル作成クエリ(Table Create Query)
特定の条件に基づいて抽出したクエリの結果を新たなテーブルとして作成するクエリです。
既にテーブルが存在する場合は、毎回既存のテーブルを削除して新たなテーブルを作ることになるため、注意が必要です。
これらのクエリは、Accessでのデータ管理において非常に重要な役割を果たしています。それぞれのクエリを用途に応じて使い分けることで、効率的にデータ操作ができます。
3-2 追加クエリと更新クエリの違い
データ追加、更新の違いはAccessに限らず、RDBを扱う上で理解しておかないといけません。
更新クエリは前述の通り、既にあるレコードをキーにデータを書き換えにいきます。
そのため、書き換えたい元テーブルに変更対象のキーがない場合、書き換えられません。
例えば、間接部門からABCという3つの製造部門への配賦率データを書き換えたいとします。この時、新しい配賦率がABのみとなるため、下記のようにデータを投入すると、前回設定したC部門への配賦率が残ってしまいます。
このような場合はC部門に対しても0を設定する必要があります。
また元々予算データが100となっているA部門に対して120になるような金額修正を追加クエリで行う場合は新たなデータとして20を追加する形（差分更新）になります。
データ修正機能が更新なのか、追加なのかによって修正データの投入方法が異なるのです。
文章で書くと「そんなの当たり前じゃないですか」と言いたくなる話なのですが、自分の使っているシステムのデータ修正ルールを正確に理解できている人は意外と少ないものです。
Accessに限らず、システムに修正データを投入する場合は追加か更新の形を取ります。
それぞれの考え方の違いを理解することは大事です。
3-3 不一致クエリ
マスタと明細を突合した時に、マスタにないデータが明細で発生した場合、Accessの通常の選択クエリではマスタと明細で一致しているデータのみが抽出されるため、マスタにない明細データは集計されません。
Accessに限らずマスタと明細のキー項目の不一致が原因で金額の合計が合わないことが実務ではよく起こります。
この点、Accessは不一致クエリという機能でデータ同士の差分を抽出できます。
マスタにない不一致の明細データを見つけることがだけでなく、差分をそのままマスタに追加クエリで追加することもできます。
経理の仕事の大半は、合わない数字を探す作業と言えます。これは、不備のあるマスタを探す事と言い換えても良いです。マスタの差分管理はAccessに限らず重要です。
マスタの不備は必ず起こると考えて、適宜差分を見つけてマスタ修正ができる業務設計をする方がいいでしょう。
3-4 クエリはメンテナンス性を第一に
Accessは、数年もすると開発者以外でメンテナンスできる人がいなくなり、使えなくなる場合が多いです。
但し、これは大型ERPのアドオン（追加）機能でも同じです。
では、メンテナンス性を高めるにはどうすればよいのでしょうか？
そのためには、変数となる業務ルールを可視化して、柔軟に変更できるような設計を行います。
例えば、Excelで条件分岐させる時はIF文を書くことが多いと思います。
単純な分岐で分岐条件が増えない場合は、特に意識する必要がないと思いますが、分岐条件が複雑になればなるほど、IF文でネストさせて書くと式が読みにくくなると思いませんか？
下記は保護猫の種類NOに応じて、猫の種類を分岐させて表示させるワークですが、一見して読みにくく、猫の種類の増加にも対応できません。
しかも、猫の種類が増加した場合、式そのものを修正する必要があります。
このような場合、下記のように猫の種類の採番ルールをマスタ化してlookupで取得するようにした方がシンプルだと思いませんか？
猫の種類が増えてもマスタを変更すればよいだけで、式自体にメンテナンスは不要となります。
このようなビジネスルールの変更に応じて柔軟にユーザーが条件設定できるようにルールをマスタ化する考え方をテーブル駆動方式と呼びます。
Excelを例にしましたが、関数をプログラムと置き換えれば、これは、システム開発全般に当てはまる話なのです。
条件を外出しする事でマスタ化すれば、シンプルな設計になるところをプログラムで複雑に記述するために、著しくメンテナンス性が低いシステムが出来てしまうことがよくあります。
クエリも同様に複雑にならないように設計することが重要です。
3-4 クエリは業務ルールの決定
クエリはデータに対してどのような集計・加工を行うかを決めるものです。
クエリを見れば、ある業務で明細をマスタと繋げてどう処理したかが分かるため、ビジネスルールを把握することが出来ます。それを応用することでクエリで業務内容を理解することもできます。（実際は引継ぎがないと死ぬほど苦労しますが、、）
現実でも、新しい業務を任された時は、
・明細情報
・マスタ
・アウトプットの内容
上記を意識することで迅速に内容を把握することができます。
その処理が、どのような背景の元に設定されているのかについては、別途確認する必要がありますが、アウトプットが分かれば目的を類推する助けにもなります。アウトプットの内容を押さえる重要性をクエリは教えてくれます。
4 業務の処理手順を決めよう＝マクロの作成
4-1 Accessにおけるマクロとは
AccessによるマクロはExcelのそれと違い、簡単なUIで時系列順にアクションを登録できます。この機能を使って、テーブルを開く処理や様々なクエリの実行を一括りにできるのです。
マクロの登録を行うことで、処理のスケジュール化が可能となり、実行するだけで一連のデータ更新処理が完了します。
4-2 処理手順を確認することの重要性
処理手順を意識することで、処理の抜けやクエリの正しい前後関係の把握が可能になります。
複雑なDBの場合、マクロを設定する過程で想定通りに動くか順番にクエリを実行していると、かなりの確率で不備が判明します。
例えば、「最新のデータでテストしてみると、実は毎月メンテナンスすべきマスタを変更する工程がまるまる抜けていた」と分かることがあります。
このようにマクロを設定する過程には、運用が問題なく回るかをチェックする意味もあります。
これは、ソフトウェアテストで結合テストと言われる内容に相当します。
システム開発では、テストが不十分で使えないシステムが出来てしまうことが良くあります。
しかし、本番を想定したテストは意外と難しいものです。
わずかなサンプルデータでのテストでは、実務の多様なデータに対応できないことが多いです。
導入するシステムをテストをする時は必ず前月実績や当期実績など本番環境に近いデータを使うべきです。
4-3 オブジェクト名称設定のルール
マクロで処理順を設定する際に重要なのが、オブジェクトの名称です。
オブジェクトとはAccess内で設定するテーブルやクエリのことです。
これらは連番かつ、どの機能なのかを識別できるように名前を設定する必要があります。
もし名称がバラバラで設定されていたら、クエリが多数ある場合に処理順でマクロを設定することが難しくなります。
例えば、私は下記の体系で連番管理します。
連番で各オブジェクトを管理することで、マクロの設定時に名称順に設定することができ、システム修正の必要性が出た場合に、どこに修正処理を挟み込めば良いか判断するための可読性が格段に上がります。
というか、連番管理されていない他人が作った複雑なAccessを解析する事はかなり困難です。
オブジェクトの名称には必ず処理内容が識別できる名前だけでなく、連番管理をしましょう。
4-4 Accessマクロは工程管理
マクロ設定は業務の工程管理の重要性を教えてくれます。
Accessに限らずシステムを長く使うためには、メンテナンス性を高めることが一つの鍵となります。
このメンテナンス性は、テーブルやクエリといったシステム設計自体の問題は当然ありますが、それ以上に後続の担当者が処理を読み解けるように可読性を高める工夫も重要です。
時系列で処理を設定するマクロは、システムの可読性に直結します。
皆さんもグチャグチャなフォルダ構成や優先順位が分からないタスクリストに悩んだことはないでしょうか？
効率的なフォルダ整理については下記のblancoさんの一連のツイートをお読みになることをオススメします。
業務効率化のためのフォルダ整理術
— blanco (@amor_tizacion) September 18, 2020
（その１）
■根本思想（楽しく、ストレスなく会社の仕事を組織的に回すために必要な精神）
① 経緯を残す
…メールなどをそのまま保存等。
② 見てわかるように残す
…ファイルを開かなくても内容わかるようにする。
③ やりながら残す
…整理は事後にしない。
現実の業務でも作業工程の把握は重要です。
自分の業務の前後工程は把握できていても、スタートから最終ゴールまで見えている人は希少です。
日頃から全体の流れを意識して自分の業務ができる人は極めて重要です。
マクロは工程管理の重要性を教えてくれます。
5 業務しやすい画面を作ろう＝フォームの作成
フォームとは、UI（ユーザーインターフェース＝ユーザーが実際にDBを使用する画面）の設計となります。
5-1 フォームの重要性
AccessでRDBを構築した場合、高確率で作成者以外の人には構造が分からなくなります。
ER図でテーブルの関係性や処理内容を残すことは当然ですが、日々使うためには、業務で使う機能やメンテナンス項目が可視化されている必要があります。
フォームは管理者以外も広くシステムを使えるように機能を可視化するものです。フォームの出来次第で、システムの使いやすさが全く異なります。
5-2 フォームの設定方法
フォームで機能を設定するためには、フォームの画面上に配置した図形などにマクロを登録して割当てます。
フォーム上に集計対象の年月日やマスタ項目を入力させ、クエリの条件とすることもこともできます。
またクエリの結果をフォームで画面表示させることで通常のデータシートビューよりも見やすい画面を作ることも出来ます。
5-3 フォームは業務の可視化
フォームは業務を可視化するものです。
マクロで設定した作業工程を画面に割り当てることで使いやすくします。
管理画面となるフォームには、データの集計条件やマスタをどのタイミングでメンテナンスすべきかも明記した方がいいです。
直感的に使えるレイアウトも重要ですが、長く使われるシステムに必要なのは、内部処理についての注意事項や必要なマスタのメンテナンス方法が明記されているかです。
日常の業務でも後続の担当者も理解できるように注意事項を明記したマニュアルを整備すると思います。
業務手順を可視化して誰でもシステムを使えるように標準化するにはどうすればよいか、ユーザビリティの必要性をフォームは教えてくれます。
6 貴方の業務も全体の一部＝RDB的思考法
ここまで読んで頂きありがとうございます。
RDBの基本的な機能についてはご理解頂けたでしょうか。
賢明な読者様の中には、RDBを構築する過程に日常の業務に通じる部分が結構ある事に気づいていただいたと思います。
そうです。
貴方は大きなRDBの流れの中にいます。
最終となるこの章では、自分を取り巻く環境を大きなRDBと見立てた時にその構造的な考え方をどう活かすかについて書いていこうと思います。
もう少しお付き合い下さい。
6-1 貴方は誰かのファクトであり、マスタでもある
経理の業務には必ず前工程があり、殆どの業務の場合、後工程もあります。
例えば、貴方のところに営業部門が起票してきた接待伝票が回ってきました。
これは貴方にとってはファクト（明細）です。
貴方の業務は、このデータを交際費か会議費か脳内にあるルール（マスタ）から判断することです。
また、法人税担当にとって貴方の仕訳データはファクト（明細）となります。
法人税担当は貴方の仕訳を集計して、別表15の交際費明細に転記すると共に損金不算入となる交際費の額を別表4という税務と会計の差額調整テーブルに投入しています。
このように会計は、ビジネスデータというファクトに多数の人間が、税務・会計というマスタを連続して関連付けして財務諸表の形に集約していく仕事と言えます。
貴方は会計という業務の全体の中で、誰かのマスタとなり、また明細にもなるのです。
マスタとしての役割を果たすには、会計・税務の知識が必要なだけでなく、前工程から流れてきたビジネスデータのどの項目が自分の知識と繋がるかを意識する必要があります。
また明細として役割を果たすためには、後続の担当者がファクトデータとして自分のデータのどの部分をなぜ使うのかを知る必要があります。
自分が誰かのファクトなのか、マスタなのかを求められる役割を意識することで、業務を円滑に進めることが出来るのです。
6-2 マスタとしての役割
経理部門は、前述の通りマスタとしての役割を果たすことが多い部門です。
マスタとしての役割で業務をする場合、当然ですが正確な知識を持っている必要があります。
判断が一意でなければビジネスデータを会計データに変換出来ません。
しかし、中には固定資産の科目判定のように画一的に判断することが難しいケースもあるでしょう。
それでも、判断基準を設定して社内外で合意を取り、一意に決める必要があります。
時に曖昧にしか書かれていない会計基準の趣旨を解釈して事実に当てはめ、一意の処理に落とし込むことはなかなか難しいですが、曖昧な判断では誰も動いてくれません。
そういった意味で経理はマスタ（ルール）を判断するだけでなく作る部門とも言えます。
今後、AIによる処理能力の向上で単純な「明細」を作る作業は駆逐されていく可能性は高いですが、マスタをデザインしてメンテナンスする仕事は今後も残る可能性が高いです。
経理として必要な要件と現場の利便性の両面に配慮した運用設計ができる人になりましょう。
6-3 RDB的学習法
一意で経理業務の判断を行うには、会計法規だけでなく社内ルールにも精通する必要があります。
一見するとこれはかなり難しいことのように思えます。
しかし、RDBは学習にも使えます。
読者の皆さんは、記憶力に自信がありますか？
…私はありません。
出掛けた後で、家の玄関の鍵を閉めたのか、すぐに不安になります。。
そんな私でも業務に関する記憶を保っていられるのはER図を意識した記憶のクセにあると思っています。
囲碁や将棋の棋士が一局を初手から再現できるのは、一手一手に明確な意味を持ち、関連する盤面の形を一つの塊として圧縮して記憶できているからと言われています。
棋士ほどではありませんが、我々のような一般人もER図で業務の関係性を意識して時系列で並べるだけでも、業務のストーリーとイメージを紡ぐことはできます。
そして、そのように意識した業務については全体の流れだけでなく、細部についてもよく記憶出来ています。
たまに殆どマニュアルを作らずに、アウトプットと元データを見ただけで業務が再現できる人がいますが、その人は恐らくシステムや運用など業務の相互関連性を熟知しているのです。
とはいえ、マニュアルを作った方が効率的に作業できる上に他者にも伝えることが出来るのでマニュアルは作成すべきです。
関係性を意識して議論を押さえる。
関係性を図解してまとめる。
関係性を意識して他者に伝える。
これらに注意するだけでも、業務に関する記憶力は強化されると思います。
6-4 一は全 全は一
会計データは、星の数ほどの社内外の業務で作られた数字を積み上げることで成立しています。
そのため自分の会社の業務を隅々まで把握出来ている人はそれほど多くないと思います。
一般的な経理部員としては、せいぜい、自分の前後の工程ぐらいまでではないでしょうか。
そのため、全体像を把握できている人は貴重となります。
この全体像の把握のためにRDBの考え方はとても役立ちます。
RDBは、主キーという自分の関係する項目を軸にデータが他者とどのように繋がるかを理解するものだからです。
自分の業務が、
誰に、
なぜ、
どう使われるか、
最初は細部の理解から始まり、大きな流れの把握に繋がっていきます。
例えば、PL予算の策定業務は最終的に利益計画に収まりますが、売上計画、原価計画、経費計画、設備計画、要員計画、などの体系に因数分解されます。
設備計画を担当する人は、最初は案件から償却費や修繕費を計算することが業務の中心になるでしょう。
しかし、関係者とやり取りしながら具体的に業務をやる中で、計画の関連性がイメージできるようになれば、自分の出した償却費・修繕費が後工程の原価計画でどのように使われるかについても理解する必要があることが分かってきます。
更に全体スケジュールの中の自分の業務の位置が理解できるようになれば、今後の業務の予測も立つようになるのです。
業務間の関係性の理解が深まれば深まるほど、全体的な流れを予測できる範囲は広がります。
細部の関係性を積み上げて全体を具体的に理解する。それがRDB思考です。
RDB思考ができれば、現状の業務の見直しや再構築にもとても役に立ちます。
皆さん、自分と周囲の関係性を日常的に意識しましょう！
あとがき＝今からRDBに触れる人はPower queryを使おう
ここまで長文にお付き合い頂きありがとうございます。
今までデータモデルやRDBについてご存知なかった人もRDBが実は普段の業務と繋がるものだとイメージを持ってもらえたらこの記事は成功です。
（…なんだかよく分からないという場合は私の力不足です。ごめんなさい。）
ここまで散々、Accessの解説をしてきてなんですが、初心者がRDB的な考え方を理解する場合、Power queryを使用されることをおススメします。
無料で機能が制限されたランタイム版を除きAccessは有料です。そのため個人で気軽に使っている人はあまり見かけません。。
（今はOffice365の契約があれば使えるので、以前よりは幾分かハードルは下がりましたが、、）
Power queryは、データの整形・加工に特化したExcelで使えるETLツールで、解説したAccessの機能のうち、テーブル・クエリ・マクロがステップという概念でまとめて設定でき、とても分かりやすいUIとなっています。
データの整形・加工に特化しているだけあって、Accessでは大変苦労するクロス集計やクロス集計の解除もピボット解除という処理で簡単に設定できます。またデータ型の変換も容易です。
但し、power queryはDBではありません。
そのため、power query自体に加工後のデータを累積していくことはできません。Accessの場合は、累積テーブルを作り、加工後のデータを累積できます。
なお、Accessでもpower queryでも考え方は同じです。
おそらく、どのツールを使っても重要なのはRDBの考え方を理解しているかどうかです。
世の中の業務運用やシステムに強いと言われる人は自社システム内のデータ関係性を完全に理解しています。
その段階になれば、どのツールを使っても大差はありません。
（利便性の問題はありますが、、）
最後にまとめです。
業務の関係性を整理し、
情報の出所を整理し、
処理の内容を決定し、
工程を整理する。
そして、それらを可視化して他者に伝える。
是即ち、RDB思考なり。
明日はblancoさんの記事になります～！
今年も長時間のお付き合い、ありがとうございました。少し早いですが、良いお年を！
参考文献:
杉本啓 .データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて. 技術評論社,
ミック.達人に学ぶDB設計徹底指南書: 初級者で終わりたくないあなたへ. 翔泳社,
マンガでわかるデータベース.オーム社