要件を聴かないとデータのモデリングはできないという話

はじめに

コミューンでフロントエンドエンジニアとして働いています西山です。
前回「エンティティってなんだっけ？」といった事をブログに書きましたが、今回は「じゃ、実際はどうやってモデリングする（してた）のよ」という事を書きたいと思います。使う用語なども前回の物を踏襲します。

また、前職までで経験してきた案件やDBの規模感なども前回のブログに書いています。記載の内容は規模などによっても大きく変わると思われるため、予めお断りしておきます。 tech.commmune.jp

要件は聞いてみないと分からない

依頼を受けたと想定して、実際にデータ構造を図にしてみます。
少し都合が良すぎる進行ですが、ご容赦ください。

「勤務表作って！」と依頼を受けたとして

要件1

「勤務実績が欲しいんです。従業員が何時間働いたか記録して集計したいんですよ。」

要件1を受けて

「従業員が何時間働いたか」管理しなければなりません。
1人がn件(n日)の実績を持つので「従業員」と「対象日」は別々のエンティティでなくてはなりません。
また、1日に対してn人の実績があるので、関係は多対多になりそうです。
多対多を表すために交差エンティティ「開始終了」を作り、「何時間働いたか」が必要なので、「開始時刻」と「時間」という属性を持たせました。

要件1の何が問題か

私ならまずは「タイムレコーダー・カードでは駄目なんですか？」と聞きます。
皆がよく知る機械ですが、csvなどのファイルでデータを出力できたりネットワークに繋がったりといった機能を持つものもあります。
もしかすると、お客様は時間を記録して集計する以外にも必要な要件を抱えているのかも知れません。

実は「プロジェクトにかかる人件費を計算したかった」

要件2

「実は…従業員1人は、1日に複数のプロジェクトの仕事をしている。プロジェクト毎に工数(時間)を管理して、人件費を元に費用を計算したいんだ。だからタイムカードでは足りないんだよね」

要件2を受けて

従業員が1日にn件のプロジェクトに従事しなければなりません。
となると「従業員」「対象日」とは別に「プロジェクト」エンティティが必要です。
また下の状況が自然だと思われるので、お互いのエンティティは多対多になりそうです。

1つのプロジェクトにはn人がn日従事する。
1日のうちに、n人によってnプロジェクトが行われる。
1人がn日に渡って、nプロジェクトの掛け持ちを行う。

また、交差エンティティとして「アサイン」を作り、属性として「時間」をもたせました。
合わせて費用計算のため、「従業員」エンティティに「給与」属性を持たせました。

要件2の何が問題か

私なら「従業員」ってどういう方が居られますか？と確認します。
給与形態を考えても、時間給、日給、月給、週給、日給月給、年俸など。契約形態だと正社員、派遣社員、契約社員と言った風に意外とハッキリしない事が分かります。
仮に「正社員」などと回答が返ってきても法律には正社員の定義がある訳では無く、どういった意図で話されているか確認が必要です。

とりあえず完成

要件３

「部署には、正社員（期間の定めがない日給月給の労働者）とアルバイト（時給の労働者）しかいないから、両方が考慮されてればOK」

要件3を受けて

従業員は「正社員」「アルバイト」どちらか（「正社員かつアルバイト」にはなれない）です。
例2を元に「従業員」に「給与区分」属性をもたせ、サブタイプとして「日給月給職員」「時間給職員」を作りました。

それでも課題は残る

一旦ここで終了にしますが、お客様が本当に必要な物が実現できるかはまだ分かりません。幾つか例えを挙げておきます。

休業や昇給・降給、賞与など、勤務時間以外での費用変動は考慮しなくても良いでしょうか。
「会社役員」は委任契約で役員報酬を受け取りますが社内で正社員と思われていないでしょうか。
「全体会議」など、特定のプロジェクトに紐付かない業務はどの様に考えれば良いでしょうか。

挙げていくと「どれだけ聞けば良いのだ！」という気持ちになりますが、その辺りはお客様やシステム化する対象の規模を見て話します。
このシステムは特定の部門で特定の人だけが使うのか、全社的に導入して業務の進め方を変えるのか。
いつから使いたいかを聞けば、開発にかけるコスト感（1〜2ヶ月で小さく作るのか、1〜2年掛けて考えているのか）の目安になります。
ちなみに「この機能、あったほうが良いですか？」とだけ聞けばまず間違いなく「あったほうが良い」と返ってきます。
最善は「予算幾らですか？」「その機能、要らないのではないですか？」と遠慮無く聞き、議論できる人間関係構築だと思います。

気をつけていたこと

具体的に例を挙げて話す
例えば上記のようなケースなら「xx部署のスズキ主任って働き方改革で個人事業主になられたって伺いましたよ？費用ってどう計算されてます？」などの会話ができると、具体的にイメージして貰いやすいです。
現実社会がどうなっているか、なんとなく知っておく
「正社員」って何だっけ？など、分かっていそうな単語でも定義を探してみます。正しく知っているに越したことはないですが、全員が認識を共有できている事が大切なので必ずしも厳密な定義を理解しておく必要はありません。
やらない事を決める
やりたい事は幾らでも大きくなるのでやらない事をきちんと決めます。「この機能は不必要だ」という提案もそうですが「まずは小さく作って暫く使ってください。その後"二次開発"として使いづらい事を洗い出しつつ、必要な機能があれば追加しましょう」と言うような進め方の提案も有効でした。兎に角「機能を増やすと、それだけお金がかかります」と共通の認識を持ってもらうようにしていました。
扱う情報が決まれば要件も大体決まる
情報処理と言うだけあって、扱う情報が決まれば何をするか・何ができるかも大体決まってきます。逆に扱う情報が決まらないうちから「xxx業務ではxxxテーブルが必要」といった風に一概にモデルが決まる訳ではありません（DBスペシャリスト試験の概念データモデル作成では業務の説明について何ページも割かれています。それだけ実際の姿が大切だという事だと思います）。

まとめ

「こんな業務なら、当然こんなテーブルが必要」などと書かれているのを理解できず色々とヘコんだりしましたが、言葉の定義が状況（顧客など）によって違うため結局は確認が必要になります。
「要件について共通認識を作るために、他の人に話を聞いてデータモデルを作る。まとめるのは自分。」といった進め方が良いのではないかと思っています。