DBスペシャリスト試験の午後問題をIT基礎スキルで考える
はじめに
私は、2019年にデータベーススペシャリスト試験（以下、DB試験）を受けて合格しました。DB試験を受けた理由は、一言でいえば、数少ない「実践で役立つ」公的試験だからです。
午後の問題では実践で使うIT基礎スキルが問われます。私が選んだ問題は、要件定義で使うIT基礎スキル（の一部）が問われました。自分のIT基礎スキルが最低水準を満たしていることが、DB試験の結果で分かりました。
私なりの経験と、受験後の振り返りを踏まえて、以下にまとめました。
私がDB試験を受けた理由と感想
私は、データモデリングについて、参考書などを読んで実践することを約30年間繰り返してきました。その経験で培ったスキルが、一般的に通用するかどうかを知るために、DB試験を受験しました。そのため、実践スキルが問われる午後問題については、過去問をざっと見て実践で大事そうなところに絞って勉強するだけにしました。
DB試験の勉強をして感じたことは、業務システムの要件定義（以下、要件定義）で使うスキルを問う問題が含まれていること。要件定義を担当したいなら、DB試験の勉強から始めても良い、と今も思います。
ただ、残念に感じたのは、DB試験の合格を目指した勉強をしても、ゼロからデータモデルを作るスキルは身につかないこと。基本中の基本（の一部）は学べますが、それだけでは実践で通用するデータモデルを作るスキルを身につけるのは難しいです。
勉強の仕方を工夫する必要があります。本記事が少しでも役立てば幸いです。
過去問を使った他の理由
その理由として、DB試験で使う表記ルールや用語を知ることがありました。
データモデリングは、意外かもしれませんが、統一した定義やルール、考え方がありません。言い換えると、様々な流派があるようなイメージです。それではDB試験の採点が困難なので、DB試験では表記ルールや用語を定めています。
そのため、自分が使っている表記ルールと用語と、DB試験のそれらとの違いを把握して対処できるようにするために過去問を使いました。
午後問題は、要件定義スキルの向上に役立つ
主に3つの具体的なスキルが問われる
私は、要件定義の段階でデータモデル（以下、DM）、特に概念DMや論理DMを考えるようにしています。DMがあれば、業務の流れや機能などを具体的に頭に浮かべやすいので。だから、要件定義ではDMを考え出すスキル（以下、データモデリング・スキル）が必須だと思います。
このスキルの向上に役立つ問題（前述）に取り組むにはするには、次のような具体的なスキルが必要です。
初めて知る業界・業務でも、データモデルを考えて表現できるスキル
補足）言い換えると、業界・業務の知識や経験に頼らず、データモデリングの基礎技術を実践で使えるスキル他人が作ったデータモデルを読めるスキル
補足）レビューする場面や、事例を読み解く場面などで使うスキルデータモデルを素早く、複数考え出す
補足）言い換えると、短い時間内で数多く試行錯誤できるスキル
特に上記3のスキルが重要
DMを作る過程では、多くの試行錯誤が必要になります。自然と多くの時間を消費します。一方、DB試験の試験時間は短いです。その時間中で多くの試行錯誤ができるスキルが、合格の必須条件です。
短時間で多く試行錯誤するには、精度を求めるより、データモデリングの基礎を踏まえて次々と新たなアイディアが思いつき、手書きしてアウトプットすることを繰り課すことが最適です。清書は、試験の解答用紙に書く／描くときだけに留めるようにします。
余談ですが、最近は手書きではなく、パソコンやスマホに入力して済ます習慣が増えたように見えます。ただ、パソコン等への入力は思考のスピードについていけない（少なくとも私は）ので、思考の効率が悪いです。実践的な思考力を向上させたいなら、パソコン等への入力よりも、手書き習慣を増やしたほうがよいと思います。それが、手書きが必要なDB試験対策にもなります。
留意点
より良いDMを考え出すには、対象（業界・業務など）を知ることが欠かせません。それでも、上記1〜3のスキルがあれば、出来が7割ぐらいのDM、つまり「叩き台のDM」が作れます。後は業務ユーザーなどと話したり追加で調べたりしながら、徐々に精度を上げていけばよいです。
最初から完璧を狙わないことが大事です。
DB試験の午後問題へに取り組む手順
私は、DMを試行錯誤しながらまとめていきます。もう慣れているので、ある程度頭の中で考えがまとまることが多く、紙などにアウトプットする量は少ないです（注：ゼロではありません）。
ただ、頭の中で考えられるようになるには、多くの経験を重ねることが必要だと思います。それではノウハウにならないので、私なりに「（思考の）手順」をまとめてみました。
実際は手順どおりに進むことはなく、行ったり来たりしながら進めます。以下の手順を参考にして、自分が思考しやすい手順を考えてみてください。
説明で使うDB試験問題
『2020年データベーススペシャリスト試験 午後Ⅰ問題』
→ 問1の前半（図1より前の文章；以下、午後Ⅰ問1前半）
まずは図1、図2を見ずに、文章だけを読んで進めてください。
使用するIT基礎スキル
主に次の記事にあるIT基礎スキルを使います。
＜記事＞
『3つのデータモデルとエンティティ』
『概念DFD』
なお、「概念・論理DFD」や「概念・論理ERD」については、まだ記事を書いていません。後者については、次の記事が参考になると思います。
＜記事＞
『SAPオブジェクトと3つのデータモデル』
DFD、ERDで使う記号
手順1：概念エンティティ・タイプ別に概念エンティティを識別する
リソース型：［拠点］［生産工場］［店舗］［自社商品］
イベント型：［発注］［生産指示］［生産］［配送指示］［配送］
組合せ型：［配送ルート］
手順2：スーパータイプ、サブタイプを識別する
［拠点］－［生産工場］［店舗］
手順3：概念DFDを描く
イベント型の概念エンティティを使って概念DFDを描きます。概念DFDを描くことで、該当の概念エンティティがイベント型であることを再確認するとともに、同エンティティの理解を深めます。
手順4：識別子を定める
概念エンティティ・タイプが定まったので、識別子を定めます。
※DB試験問題では識別子が提示されています。ただ、実際の要件定義
では自分で識別子を定めます。そのことを踏まえて問題に取り組む
ことで実践力が養われます。（以下同じ）
［拠点 ＜拠点コード＞］
［生産工場 ＜拠点コード ＋ 拠点区分 "生産工場”＞］
［店舗 ＜拠点コード ＋ 拠点区分 "店舗"］
［自社商品 ＜商品コード＞］
［発注 ＜発注番号＞］
［生産指示 ＜生産指示番号＞］
［生産 ＜生産番号＞］
［配送指示 ＜配送指示番号＞］
［配送 ＜配送番号＞］
［配送ルート ＜ルート番号＞］
手順5：概念ERDを描く
以上の正しさ、およびリレーションシップを確認するために概念ERDを描きます。
なお、リソース型および組合せ型の概念エンティティと、イベント型の概念エンティティを分けた概念ERDにします。理由は、概念ERDを簡素化するため。全体を対象とした概念ERDにすると煩雑になり、かえって分かりにくくなります。
【補足】
リソース型や組合せ型の概念エンティティと、その他の概念エンティティとのリレーションシップは、通常は項目だけで判断できることが多いです。判断できない場合は、ERDで表現します。これは、論理エンティティの場合も同じです。
なお、午後Ⅰ問1前半に限らず、DB試験では1つのERDを描かせる傾向にあります。私が1つのERDで書いたのは、試験本番で清書するときだけです。
手順6：論理エンティティを定める
一般的には、イベント型の概念エンティティに対する論理エンティティを「～ヘッダ」と「～明細」に分けます。
イベント型以外の概念エンティティの場合、多くは概念エンティティがそのまま論理エンティティになります。ただ、業務要件次第で変わります。午後Ⅰ問1前半の場合は、組合せ型の［配送ルート］も「～ヘッダ」と「～明細」に分けます。
以下、イベント型の概念エンティティと［配送ルート］に対する論理エンティティを挙げます。
［発注 ＜発注番号＞］
：［発注ヘッダ］＋［発注明細］［生産指示 ＜生産指示番号＞］
：［生産指示ヘッダ］＋［生産指示明細］［生産 ＜生産番号＞］
：［生産ヘッダ］＋［生産明細］［配送指示 ＜配送指示番号＞］
：［配送指示ヘッダ］＋［配送指示明細］［配送 ＜配送番号＞］
：［配送ヘッダ］＋［配送明細］［配送ルート ＜ルート番号＞］
：［配送ルートヘッダ］＋［配送ルート明細］
手順7：概念・論理DFDを描く
概念DFDを、定めた論理エンティティを使って概念・論理DFDに変えます。概念・論理DFDを描くことで、概念エンティティおよび論理エンティティの理解を深めます。
手順8：論理エンティティの識別子を追加する
概念エンティティに対し、複数の論理エンティティに分かれる場合、それらの論理エンティティに識別子を追加します。
［発注 ＜発注番号＞］
：［発注ヘッダ ＜発注番号＞］
＋［発注明細 ＜発注番号 ＋ 発注明細番号＞］［生産指示 ＜生産指示番号＞］
：［生産指示ヘッダ ＜生産指示番号＞］
＋［生産指示明細 ＜生産指示番号 ＋ 商品コード＞］［生産 ＜生産番号＞］
：［生産ヘッダ ＜生産番号＞］
＋［生産明細 ＜生産番号 ＋ 商品コード＞］［配送指示 ＜配送指示番号＞］
：［配送指示ヘッダ ＜配送指示番号＞］
＋［配送指示明細 ＜配送指示番号 ＋ 商品コード＞］［配送 ＜配送番号＞］
：［配送ヘッダ ＜配送番号＞］
＋［配送明細 ＜配送番号 ＋ 商品コード＞］［配送ルート ＜ルート番号＞］
：［配送ルートヘッダ ＜ルート番号＞］
＋［配送ルート明細 ＜ルート番号 ＋ 店舗拠点コード＞］
手順9：概念・論理ERDを描く
以上を踏まえ、概念・論理ERDを描きます。これにより、DMへの理解をさらに深めます。
手順10：論理エンティティがもつ項目を定める
以上の論理エンティティがもつ項目を定めます。詳細は割愛します。
手順11：DB試験問題が求める形に変える
手順1～10までの表記ルールを、DB試験の表記ルールに変換します。その他については、次の大見出し以降にまとめました。
DB試験問題への回答づくり
私が描いた概念・論理ERDは、午後Ⅰ問1前半の図1「概念データモデル」とは異なります。
たとえば、次のような違いがあります。
私：［生産指示］と［生産］を分けました。なぜなら、概念DFDから見れば、概念エンティティを分けたほうが自然なので。
図1：［生産］のみとなっています。おそらく［生産指示］と［生産］のリレーションシップが「1：1」だから１つにしたのだと推測しています。この考え方も間違いではありません。
DB試験で回答する時は、自分が考えた概念・論理ERDを、DB試験問題で提示された図に合わせて、具体的な根拠に基づいて変換するスキルも必要になります。このスキルは次のような場面で使うので、無駄ではありません。
レビューする場面、レビューで助言する場面
事例を読む場面
DMについて助言を求められた場面
まとめ
DB試験の午後問題について
要件定義スキルが問われる問いが含まれる
過去問や本試験に取り組む場合、実践で使うIT基礎スキルを活用することで実践力も高められる
（単なる過去問対策で済ますと、実践力を身につけるのは困難）重要なIT基礎スキルとして、主に次の構想・設計スキルを使う
① 概念エンティティと論理エンティティ
② 概念DFD、概念・論理DFD
③ 概念ERD、概念・論理ERD