同じ業務を、違うモデルで確かめる

架空事例：青葉機材の予約・点検・貸出し業務をモデル化する。表中のデータ、期間の取り方、状態、制約は本書の説明用モデルであり、公式問題の図表ではない。

一本の矢印が、四つの意味を持ってしまう

営業が依頼を受け、倉庫が機材を確認し、営業が顧客へ回答する。担当者は、その流れを三つの箱と二本の矢印で描いた。会議では誰も反対しなかった。

ところが、開発者は矢印を「次に実行する処理」と読み、業務担当者は「渡す帳票」と読み、データベースの設計者は「参照関係」と読んでいた。三人とも同じ図を見て、違う設計を想像していたのである。

モデルは現実を縮小した模型というより、ある問いに答えるための表現である。何を残し、何を省略するかによって、読み取れる性質が変わる。コンプリートテキストは、業務フロー、DFD、ER図、CRUDを、それぞれの目的から区別している。1 副読本では、その区別を実際の不整合の発見に使う。

青葉機材で最初に答えたいのは「誰の確認を待つために回答が遅れるか」だった。この問いには、人の作業順序と受渡しが見える業務フローが合う。一方、「貸出し可能という判断に、どの情報が必要か」を調べるには、処理へ入るデータと出るデータを整理する必要がある。問いが変わったのに同じ矢印を使い続けると、図は分かりやすいまま、不正確になる。

DFDに描くのは、次の処理ではなく渡す情報

予約処理を一つのプロセスとして見る。営業から機種、数量、利用期間を受け取り、営業へ可否と回答根拠を返す。点検管理から点検状態を受け取り、予約記録を読み書きする。これをデータの流れとして整理したものがDFDの見方である。

DFDは、プロセス、データフロー、データストア、外部実体によって、データがどこから入り、どう変換され、どこへ出るかを表す。矢印は、そのデータの受渡しを示すのであって、処理の開始条件や順序をすべて表すものではない。1

「倉庫確認」から「予約確定」へ矢印を引くなら、何が渡るかに名前を付ける。単に「次へ」ではなく、「確認結果」や「確保可能な機材一覧」とする。名前を付けられないときは、データの流れではなく、制御の順序を描こうとしている可能性がある。

ただし、図の上で別々の矢印になっているから、別々の通信APIを作る必要があるわけではない。一回のAPI応答で複数の論理データを返す実装もできる。論理モデルで分けるものと、実装上のメッセージを一対一に対応させると、設計の自由度を不要に狭める。

分解すると、存在しなかった入力が現れる

上位の「予約処理」を、依頼登録、貸出し可否判断、予約確定へ分解した。可否判断を詳しく考えると、契約条件の有効性も確認する必要がある。そこで下位図に、契約管理システムから「契約状態」を受け取る矢印を追加した。

これは新しい発見である。しかし、下位図だけを直して終わると、上位図では受け取らない情報を下位処理が突然利用することになる。

DFDの階層間では、親プロセスと、分解した子プロセス群の境界を出入りするデータが整合している必要がある。これがバランシングの観点である。矢印の本数を機械的に一致させるのではない。上位でまとめた依頼情報を下位で機種と期間に分けても、それらの意味が対応していればよい。一方、上位にない外部入力を下位へ足したなら、上位の不足か、下位の境界の誤りかを確かめる。1

この事例では、契約管理との連携を上位へ反映し、契約状態を取得する責任と失敗時の扱いを検討する。新しい機能を見つけたから何でも追加するのではなく、採用する業務に必要な情報かを先に確かめる。上位の目的に戻れない入力は、要求ではなく、設計者の思い付きかもしれない。

反対に、子プロセス同士だけで使う中間データは、必ずしも親の外部インタフェースへ追加しない。予約候補の一覧を可否判断から予約確定へ渡す場合、それは親の内側の分解で生じたデータである。外との契約を変える情報と、内部で増えた情報を区別する。

CRUDの空欄は、欠陥ではなく質問の入口

機能とデータの関係を、次のように並べてみる。これは青葉機材の候補モデルを一部だけ示した表であり、完成した機能一覧ではない。

業務機能	依頼	予約	機材個体	点検結果
依頼を受け付ける	C		R
貸出し可否を調べる	R	R	R	R
予約を確定する	R/U	C	R	R
予約を取り消す	R	U

Cは生成、Rは参照、Uは更新、Dは削除を表す。表を作ると、点検結果を読む処理はあるのに、作る処理がないことが分かる。直ちに「点検結果登録機能を実装し忘れた」と結論するのは早い。点検結果は外部の既存システムで作られる前提かもしれない。この場合、必要なのは自前の登録機能ではなく、情報をどこから取得するかの確認である。1

予約取消しがUで、Dではない点にも意味がある。本事例では、予約を消すのではなく、取消しという状態を記録して履歴を残す設計候補にした。画面上の「削除」ボタンが、データモデルでもDになるとは限らない。業務上の取消し、論理削除、物理削除は同じ操作ではない。

CRUD表は、操作主体と対象を横断的に見せる。一方、取消しを何時まで許すか、参照と更新を同じトランザクションで行うか、外部の点検情報をいつ取得するかは、この表だけでは決まらない。表に書かれていない時間や順序を、空欄から推定しない。

SAシラバス5-4には、機能間の情報の流れに加え、情報管理の観点、管理の単位、形式が含まれる。2 CRUDを埋める作業も、どの単位の情報を管理するかが曖昧なままでは進められない。

「機材」を一つの表にすると、違うものが重なる

顧客は「測定器Aを二台」と依頼する。倉庫が出庫するのは、管理番号M-101とM-105の二つの実機である。この二つを同じ「機材」と呼んでいても、業務での役割は違う。

機種は、顧客が要求する仕様や料金区分に関わる。機材個体は、製造番号、点検状態、所在、故障履歴に関わる。一つの機種に複数の個体が対応するモデルにすれば、機種の名称を変更することと、ある個体を修理中へ変更することを分けられる。

また、予約の段階でどの個体を使うか決めない業務も考えられる。機種と数量だけを確保し、出庫前に個体を割り当てるなら、予約明細から個体への対応は、確定直後にはまだ存在しない場合がある。「予約一件には必ず一個体がある」と最初から決めると、機種単位で予約する業務を表現できなくなる。

この巻の候補モデルでは、依頼、予約、予約明細、機種、機材個体、個体割当てを区別する。すべての業務システムにこの表構成を勧めているわけではない。機種単位で予約し、後で個体を決めるという業務上の事実から、この分離が必要になったのである。

多重度や必須性も、業務の時点を含めて読む。確定した予約には明細が一件以上必要でも、入力途中の下書きには明細がない状態を許すかもしれない。一つのクラス図で全状態を表すなら、状態に応じた制約を別に記述する必要がある。記号だけを揃えても、そのモデルがどの状態を許すかは自動的には決まらない。1

台数を足す前に、期間が重なっているかを調べる

一台の機材に、月曜から水曜までの予約と、水曜から金曜までの予約がある。同じ水曜に二つの予約があるから重複だろうか。それとも、水曜に返却して貸し出せるだろうか。

答えは、日付の表記だけでは決まらない。返却予定時刻、点検に必要な時間、次の出庫時刻が必要である。

説明を明確にするため、機材が他の予約へ使えない時間を、開始時刻を含み終了時刻を含まない半開区間 [開始, 終了) として定める。終了は顧客の返却時刻そのものではなく、点検等を終えて再び貸出し可能となる時刻とする。これらは本事例で置くモデルの約束である。

二つの非空区間AとBが重なる条件は、Aの開始 < Bの終了 かつ Bの開始 < Aの終了 となる。Aの終了とBの開始が同じなら、この表現では重ならない。例えばAが九時から十二時、Bが十二時から十五時なら接しているだけだが、Aの終了が十二時三十分なら三十分重なる。これは上記の区間定義から導いたものであり、特定DBMSの仕様を引用した式ではない。

この小さな式には、業務の約束が埋め込まれている。点検時間を除いて終了時刻を決めれば、数学的に重複がなくても、実機を渡せない予約が生じる。時間帯や休業日、倉庫間の移送をどう扱うかも、実際に必要な範囲で定義しなければならない。

機種単位で複数台を予約する場合は、個々の予約が別々の期間と数量を持つ。ある日の総予約件数だけでは、その時点に必要な台数を求められない。重なる期間の需要と、条件を満たす供給を比較する必要がある。ただし、個体ごとの仕様差や点検予定があると、総台数だけの比較で割当て可能性を保証できない。単純化したモデルが何を捨てたかを覚えておく。

重複した値が、異なる事実を表すこともある

顧客の住所を顧客表へ集約した。更新箇所が一つになり、住所変更への対応は簡潔になった。ところが、過去の貸出し契約を表示すると、当時の届け先まで現在の住所へ変わってしまう。

ここで保持したいのは「顧客の現在の住所」と「その貸出しで合意した届け先」である。値が同じでも、意味と基準時点が異なる。後者を取引時点の情報として保持することは、単に正規化に失敗して同じ値を複写したことと同じではない。

どの属性が何によって決まるかを考える前に、属性が表す事実を定義する必要がある。顧客番号で定まるのは、定義した時点における顧客情報かもしれない。契約で合意した届け先は、契約や配送指示の内容として決まる。この区別をしないまま「重複は全部削除」と進めれば、必要な履歴を失う。

本書の例から、すべてのデータを毎回複製して残す結論も導けない。保持すべき履歴の目的、参照時点、訂正方法を定める必要がある。データモデルは、保存する値の形だけでなく、何を事実として記録するかの合意なのである。

図同士を照合すると、要求の穴が見える

DFDでは予約処理が点検結果を受け取っている。CRUD表ではその結果を読む機能がある。データモデルには機材個体と点検結果の関係がある。ここまで揃っても、最新の点検が未実施だった場合の可否判断は決まっていないかもしれない。

モデルを増やすだけで完全性が上がるわけではない。同じ用語の定義、対象、時点を揃えて照合するから意味がある。貸出し可否判断に必要な情報はデータモデルにあるか。その情報を取得・更新する仕事は存在するか。未取得の状態は業務フローでどこへ進むか。一つのモデルが省略した性質を、別のモデルで問い直す。

シラバス7-2が挙げる一貫性や追跡可能性は、書類の形式を合わせることではない。取得者のニーズから要件をたどり、複数の表現で同じ業務の約束を守っているかを確かめるための観点である。2

一本の矢印にすべてを語らせることはできない。しかし、矢印が語っていないことを意識すれば、必要なモデルを選べる。図を描く能力は、図から何を結論してよいかを判断する能力と切り離せない。

知識を答案へ戻す

午前Ⅱの判別軸。 DFDのバランシングは親子のプロセス数の一致ではなく、境界の入出力の意味の整合である。CRUDは操作とデータの対応であり、時系列やトランザクションをそのまま示さない。多重度は関連する個数の制約であり、どの時点・状態をモデル化しているかも読む。

午後Ⅰへの接続。 図と本文を往復する。本文に「返却後に点検してから貸し出す」とあるのに、図では返却直後に貸出し可能へ戻っていれば、その違いに着目する。本文にない点検時間や権限は、答案を具体的に見せるために追加しない。

午後Ⅱへの接続。 「データを一元管理した」より、「機種と機材個体を分け、予約時点の数量確保と出庫前の個体割当てを別に扱った」と書けば、業務のどの性質を設計へ反映したかが伝わる。さらに、点検期間を貸出し不能期間へ含めた理由を示すと、モデルが防いだ問題まで説明できる。

立ち止まって考える：点検結果をCする機能がCRUD表にない。実装漏れか

それだけでは判断できない。点検結果が外部システムで生成される、別の業務範囲で登録される、調査から漏れている、といった可能性を分ける。必要な情報の生成主体と取得経路を確かめ、現在の対象範囲に登録機能が必要と分かったときに初めて不足と判定する。

出典と照合範囲

[1] コンプリートテキスト『午前Ⅱ 技術知識の地図』第4・5・17・18章：DFD、CRUD、モデルの視点、多重度、データの意味と関係を出発点とした。半開区間の予約計算、機種と個体の分離、契約時点の届け先は、本書の仮定と推論による発展例であり、原教材に同じ事例があるわけではない。

[2] IPA「SAシラバス Ver.5.2」：4-6、5-4、7-2、10-3。業務モデル、管理の単位、要件評価、概念・論理データモデルの接続を照合した。表の様式や本章のテーブル構成を必須とする記述ではない。公式PDF