FileMaker 正規化「要件定義」 中級編（１〜４章）

FileMaker公式テキスト中級編！！！突入です😊

中級編では、
中級開発者として複数の利用者を想定してシンプルなカスタムAppを作成する
といった内容になります。
全１６章です。
今回は、１章〜４章『システムの企画・設計』についての知識を学びます。

開発者になろう（１章）

初級編の復習も兼ねて、中級編で必要な考え方について説明します。

●カスタムAppの役割
システムにおけるカスタムApp の役割の基本は、いつも同じです。対象業務の中で『必要な情報の入出力』をユーザが使用する画面や機能で実現し、作業をサポートすることです。 

出入力について考えるべきこと
＜データ入力＞
（1） いつ
（2） どこで
（3） 誰が
（4） なにを
（5） どのように
（6） どうやって

＜データ出力＞
（1） いつ
（2） どこで
（3） 誰が
（4） なにを
（5） どのように
（6） どうやって  

●中級編で開発者として押さえておくこと
初級編での・ 身近な問題や課題の解決 に加え以下の４点が必要になります。

・ 自分以外の複数のユーザが使用すること
・ FileMaker Cloudや FileMaker Serverで共有すること
・『 いざというとき』のための運用 
・ 自分以外の開発者がメンテナンスできるようにする 

PDCA

「PDCA（＝ Plan Do Check Action）サイクル」 >>>「計画、実行、確認、 改善」というサイクルで開発を進めること。

●計画（Plan） 
『どれぐらいの期間（スケジュール）で開発するか』だけでなく「設計」という概念も該当します。
きちんとおこなっておくことでエラーを減らすことができるからです。
●実行（Do）
『計画を実行すること』です。
開発全体を進めること、実際にFileMaker Pro を操作して機能などの開発作業を行うことです。 
●確認（Check）
チェック、つまり「テスト」です。エラーがないか、正しい結果かどうかを確認します。
「計画 ＝設計」で想定した「答え＝動作や結果」になっているかどうかを確認するということです。  
●改善（Action）
確認後、必要があれば改善します。結果にエラーがあれば訂正し再度確認します。
ただし、計画時に用意したとおりの結果だったが状況が変わったために修正が必要になった、という場合、次の計画で新しい結果を用意します。
エラーがなければ、そこで完了か、別の計画に移ります。 

ここまでで1 回のサイクルとなります。PDCA は1 回で完了することもありますし、何度も反復して実施することもあります。 

システム開発のプロセス

システム開発の基本的なプロセス

(1) 企画
(2) 要件定義
(3) 設計
(4) 開発
(5) テスト
(6) リリース（完成）
(7) 運用 

一番大切なことは決定する答え（目的）です。
何を開発したいのかがはっきりしていれば変更や他の意見に対しても的確な判断ができ、開発中の混乱を防ぐことができます。意見の反映と結果の確認が可能になります。 

企画しよう （２章）

企画　>>> 様々な意見の中から、これから作成しようとしているシステムが『なにを対象にするか』 という「範囲」を絞り込むことが目的です。
範囲を決めることでゴールが決定し、そこを見据えて取り組めるようになります。

また、目指す範囲が広い場合、『何回かに分けて、ゴールを複数設定する 』『定期的、継続的にゴールを設定する 』ことも考えられます。

問題や課題の収集

どのような問題や課題を解決したいのか → 「目的」（解決して得たい結果） 
上記を考えるため、使用するユーザーから意見や問題を集めます。

●整理する
集まった問題や意見などを整理します。
１、箇条書きなどにして内容をまとめます。
これによって、 包括的に眺めることができるようになりゴールが見えてきます。 

２、整理された意見を元に、問題や課題の解決のために必要なツールについて考えます。

・ 解決のためにつくるもの（ツール） → 本書では「カスタム App」
・ ツールはどのような内容なのか → 大まかな「機能（役割）」 

●対象
ツール（カスタムApp）の「対象」について考えます。
・ どの業務（作業）か
・ どのような情報を取り扱うか
・ 誰がどこで使うのか 

●制約
ツール（カスタムApp）の「制約」について考えます。
・ ○○の期間だけ使えれば良い or 長く使いたい
・ ○月から使いはじめたい
・ どのようなネットワーク環境が必要か、あるいは用意できるか
・ クライアントは、パソコン、iPhoneや iPad、Webブラウザのどれか（1つまたは複数）
・ カスタム Appだけで完結するのか、他のシステムとの統合があるのか
・ セキュリティはどう考えるか
・ ハードウェアやソフトウェアは新たに購入する必要があるかどうか 

概要の把握と決定 

企画内容を決定し、そこから考えられることについても内容把握をする。

●概要について
以下が企画内容になります。
（1） 目的
（2） つくるもの　→ 本書では「カスタムApp」
（3） 対象範囲（業務、情報、誰がどこで使うか）
（4） 制約
（5） 作業期間、その他の制約 

●決定
最終的に企画内容を決定します。
『必要な人々の間で決定する』ということになります。

●書き残す 
決定した企画の内容は、図や文字で書き表して関係する誰もが確認できるようにします。 
業務で複数の 人が使用する予定のシステムは情報を公開することも重要です。 

●期間
制約に含まれている項目の中から「期間」を決定することは重要です。 
・ ○○の期間だけ使えれば良い or長く使いたい
・ ○月から使いはじめたい 

「いつから使えるか」は『いつまでにカスタムApp が完成しなければならないか』ということを表しています。 

●期間と作業量 
作業期間に比較して、カスタムApp 作成の作業量が多すぎるなら
・ 対象範囲のうち、次の開発に回すものを決める
・ 作成作業を実施する開発者を追加する
・ 作業期間を変更する
などの判断が必要になります。 
※カスタムApp開発期間とは別に、システムの使用開始までの準備期間も必要です！

●その他
新しいシステム業務を取り入れることで起こりうる業務変化を考えることも必要です。
・業務改善
問題や課題の解決に『今とは違う業務の進め方』が必要になる可能性です。 

業務の大きな改善とカスタムAppの開発を同時進行することが可能かどうかなど、カスタムAppを使用するためのその他の問題とも合わせて、実現可能かを考えていく必要があります。

 

中級編での決定企画内容　まとめ

『見積作成管理システム』

見積作成管理システム
目的	担当者がばらばらに作成している見積書を一元化したい （全員が見積書を同じデータベースで作成することで見積内容や注文されたかどうかなどの 活用をできるようになる
つくるもの	見積作成管理システム（カスタムApp）
対象範囲	対象部門：　営業部門 対象業務：　見積業務 ユーザ　：　営業部門の人員（10 人程度） 場所　　：　社内での使用
制約	FileMaker Pro で開発する ○ヶ月で完成想定 クライアントはパソコン FileMaker Cloud またはFileMaker Server で共有する（検討中） 既存の社内ネットワークを使用する 営業部門の人員以外は使用できないようにする 他のシステムとは統合しない
その他	サーバー機は専用サーバー機の購入が必要かどうか要確認 ソフトウェアは追加購入不要 クライアントパソコンの追加購入不要

要件定義しよう（３章）

企画内容を元にもう少し内容を明確にしていきます。

ヒアリング 

「ヒアリング」で情報を集めます。聞いたり調べたりすることです。

●なにを聞くか
・ カスタム Appにどのような機能が必要か検討するための内容
・ 入力する項目と書式（あれば）
・ 出力する項目と書式（あれば） 

●だれに聞くか
実際に使用するユーザの要望を聞きます。企画で対象範囲を決めました。
その対象 業務に携わる人、対象ユーザの人、必要があれば業務の責任者などにもヒアリングを実施します。 

●業務の流れ
開発者が、対象業務について具体的なことが分かっていないと良い開発はできません。
どのような作業があって、どのような流れで進める業務なのかを把握します。
フローチャートを使うのも良いかもしれません。

フローチャート（流れ図）>>> 業務の流れをわかりやすくする為、いくつかの箱（様々な形の）に意味を持たせ、矢印で繋いで流れを表現するもの。 

●入力の項目
この時点でわかっている入力、印刷や出力するものについて項目を確認します。
例
・ 入力は、申請書や申込書
・ 出力は、見積書や請求書 

※データで出力する場合は、ファイル形式や必要な項目、項目順なども併せて聞いておきます。
聞くだけではなく実際に業務で利用しているものを収集するのがベストです。フィー ルドを設計するために役立ちます。 

●できないこともある
ヒアリングで集めた要望は「要件」にする必要があります。重要なのは、必ずしもすべてが要件にできるわけではないことです。

次のものは要件にする検討対象から外します。
・ システムでは明らかに実現できないもの
・ 企画で決定した対象範囲から逸脱しているもの
・ 企画の制約では実現できないもの 

しかし、内容によっては将来の新しいシステム開発のための 検討事項としておくと良いかもしれません。 

●期限を切る 
後から後から意見が出てくるとヒアリングが終わらなくなることがあります。
そのような場合は、 期限を切ってそれまでに代表する人にまとめてもらいます。

●ヒアリング内容をまとめる

要件定義をする

「要件定義」では、企画からヒアリングまでに集めた要望の中から、システムで実現すること、そして実現のために必要な条件を企画内容を大前提に決定していきます。
主な要件定義は、カスタムApp の作成作業の開始前に決定します。
機能の確認、ユーザテストなどに必要な内容が含まれるからです。

以下について決定していきます。

●規模感
要件定義時に役立つ情報として「規模感」があります。
いくつかの角度から規模感を掴むことで、 カスタムApp ファイルや必要なハードディスクの大きさ、運用開始後に気をつけることなどを計画、決定する際にとても役立ちます。

その他にも機能の数、レイアウト数など別の方向から規模感を把握することで、全体を把握し各種の計画や決定事項に役立てます。 

●項目
構造を設計するために、フィールドとテーブルの元になる「項目」を考えます。
入力項目と、出力する書式や項目の内容から項目がわかります。
「見積作成管理システム」では、次表の項目が必要だとわかりました。

見積もり作成管理システムの項目

発行日

見積番号

お客様情報（会社名　郵便番号　住所　所属　肩書　名前）

自社情報（会社名　郵便番号　住所　所属　担当者名　電話番号　FAX 番号　電子メール）

見積の総額（￥xx,xxx,xxx.- 　の形式）

件名

見積期限

見積の内容（明細：品名　数量　単価　 金額　備考）　1 見積書に複数必要

小計（xx,xxx,xxx 　の形式）

消費税額（xx,xxx,xxx 　の形式　1 円以下は、切り捨て）

見積の状況（作成／お客様検討中／結果確定済）

結果（注文あり／注文なし）

要件を定義する２：作業を考える

要望を一覧にし、同じ内容のものは1つにまとめるなどして整理します。
可能であれば大まかな「作業」ごとにわけます。

●業務の流れのどこか 
大まかに切り分けた作業が実行されるのは、業務の流れのどこでしょうか。
以前まとめた業務の流れに沿って考えていきます。
さらに、作業にカスタ ムApp が必要かどうかも考えます。
これで、カスタムApp の持つべき役割が段々わかってきます。
↓↓↓

次のことがわかるようになります。
・ 業務の流れがどうなるか
・ 業務の流れには、どのような作業があるか
・ カスタム Appがどこで必要か、どの作業をサポートするのか 

この情報を元に、作業から機能を考えていきます。 

要件を定義する３：機能を考える 

カスタムApp が業務をサポートするために必要な機能は、どのようなものでしょうか。
これまでの内容から、「見積作成管理システム」の機能を洗い出します。

●作業を細分化する 
作業から機能を考える
例　・ 見積作成作業　の細分化を考える

・ 新しい見積データ作成
・ 自動入力
・ 既存見積の複製による新しい見積データ作成 

●機能を定義する 
作業を細分化した内容から機能を定義していく。
例　・ 新しい見積データを作成する 　の機能を定義する
（1） いつ →　お客様から見積書の提示を求められたら
（2） どこで →　企業内で／カスタムApp で／見積を作成できる画面で
（3） 誰が →　通常使用ユーザが
（4） なにを →　見積書を
（5）どのように →　1 件ずつ（1 件には、複数の品名が含まれる／一部項目自動入力　など）
（6） どうやって →　新しく作成する
（7） 何故 →　お客様に提示するため
（8） 備考 →　自動入力は、発行日、品名ごとの単価、計、小計、消費税額、見積額 

のように分解する。
ヒアリングで受け取る要望の内容は、人の気持ちを伝えるための言葉です。
その言葉を機能とするために細かい要件を確認していかなければなりません。 

●定義内容の確認 
定義した機能の内容を、新しいシステムに関係する人で検討します。
ヒアリングの要望が機能として実現されたかどうかを複数の目で確認してもらうためです。
プロトタイプを導入することも効果的です。 

要件を定義する４：その他

業務で使用する場合や、複数の人で使用する場合に必要 なことを考えます。 

●セキュリティ
＜使う人とレベルについて考えます＞
企画時に対象ユーザを決定しました。その内容で良いか確認し、セキュリティ のレベル（区分）がいくつあるべきかを考えます。
基本は2 種類です。

・ 普段の作業をする
・ システムで使用する共通のデータを管理する 

必要に応じてレベルを増やします。 

＜通信＞
接続（通信）の暗号化を考えます。
原則として、暗号化することをお勧めします。
詳しくは上級編やヘルプを参照してください。 

＜ファイル＞
カスタムApp ファイルを暗号化するかどうかを考えます。
※ FileMaker Cloud で共有する場合はファイルの暗号化は必須です。

●現在のデータはどうするか
これまでのデータをどうするかも決めます。
データを新しいシステム（本書ではカスタムApp）へ移すことを「データ移行」と呼びます。

＜移行対象＞
それまでのデータのうち、どのデータを移行するかを決めます。 

データの種類も考慮します。 
・マスタ的なデータ
移行する必要があることがほとんどです。それらの情報があら かじめ入力されていないと通常の作業（例えば、見積書作成）ができないからです。 
・イベント的なデータ
例えば、これまでの見積データは移行しないか、一部分だけ移行する決定をすることがあります。

＜移行手段＞
入力方法です。手入力にするか、データインポートにするか、別のシステムとデータ連携するかの、いずれかです。 

※カスタムAppへの影響
データ移行を実施する場合、とくにイベントデータの作成日や修正日で動作する機能について注意が必要です。移行時に過去の日付にするなどの対応を検討してください。 

●他のシステムは関係あるか
企画の段階で『他システムと統合しない』と決めていたとしても再度確認します。

●環境
企画で考えたカスタムApp の使用環境などについても確認して決定します。
パソコンのスペックが大丈夫かどうか「ネットワークは想定したように使えるか」「必要なソフトウェアは足りているか」などです。 

要件定義を合意する 

要件も『必要な人々の間で合意する』ということになります。

モデリングと正規化（４章）構造設計

企画と要件定義を元に設計をはじめます。「構造の設計」について解説します。 

構造設計 

これらを次のステップで行います。

できあがった設計に従ってFileMaker Pro でファイルにテーブルを作成し、リレーションシップグラフ、コンテキストを生み出すことで、レイアウト越しにデータをやりとりすることが可能になります。
設計はとても重要です。
データベースにおけるデータ取り扱いの基本ルールだからです。 

データモデリング

データモデリングによりデータベースの全体像を把握することができます。

データモデリング　>>> データを整理整頓してデータベースで利用できるように「概念的な構造 （スキーマ）」を決めることです。 

●ER図
データベースに必要なデータと、その関連を図示したものです。
リレーションシップグラフを作成するための設計図と考えてください。
リレーションシップグラフと似ていますが違います。

●エンティティを探す
要件定義で集まった入出力が必要なデータ項目からエンティティ（テーブル）を探し出します。
※項目を 同じ分類ができるような情報の集まり に分ける。

●エンティティの種類
エンティティを『イベント』（発生するデータ）と『マスタ』（存在するデータ）の２種類の分ける。

●関連の種類
関連を設計しなければなりません。
後述する「主キー」「外部キー」に関わるからです。
主に3 種類の関連があります。
・１対多
・１対１
・多対多　⇨多対多はDBでは成立しないため、中間テーブル置いて解消する。

●他のシステムとの関係
エンティティ同士の関連で、慎重に考えなければならないことがあります。
他のシステムとの統合です。
すでに存在している他のカスタムApp や、他のデータベースシステムのデータを利用する場合です。

連携するテーブルの主キー（あるいは外部キー）を見つけ、ER 図に加えます。

 正規化 

エンティティと関連が設計できました。
その概念を念頭に置いて、次は項目からテーブルを正規化していきます。

正規化　>>> 項目を一定のルールに従って整理整頓し、必要に応じてひとかたまりに分け、それらを関連付けることです。
データを効率良く管理できるようにすることが目的。

下記の３段階で正規化していきます。

見積もり作成管理システムの項目

発行日

見積番号

お客様情報　番号

お客様情報　会社名

お客様情報　郵便番号

お客様情報　住所

お客様情報　所属

お客様情報　肩書き

お客様情報　名前

自社情報　会社名

自社情報　郵便番号

自社情報　住所

自社情報　所属

自社情報　担当者名

自社情報　電話番号

自社情報　FAX 番号

自社情報　電子メール

見積の総額（￥xx,xxx,xxx.- 　の形式）

件名

見積期限

見積の内容（明細)　商品番号　1 見積書に複数必要

見積の内容（明細)　商品名　1 見積書に複数必要

見積の内容（明細)　商品数　1 見積書に複数必要

見積の内容（明細)　商品単価　1 見積書に複数必要

見積の内容（明細)　商品金額　1 見積書に複数必要

見積の内容（明細)　商品備考　1 見積書に複数必要

小計（xx,xxx,xxx 　の形式）

消費税額（xx,xxx,xxx 　の形式　1 円以下は、切り捨て）

見積の状況（作成／お客様検討中／結果確定済）

見積の結果（注文あり／注文なし）

はじめの正規化 

１つ目は『繰り返す属性は別のエンティティにする』です。 

今回の場合は「見積の内容（明細）」という1 件の見積書に複数必要である「見積明細」が含まれています。これを別のエンティティにします。
『J見積詳細』

J見積詳細

主キー

商品番号

商品名

数量

単価

金額

備考

2 番目の正規化

２つ目は『主キーに部分的に従属する属性は別のエンティティにする』です。

「見積情報」の主キーに関係しているけれど、見積自体についてのものではない項目が「主キーに部分的に従属する属性」です。

今回の場合は、「お客様」と「自社」がそうです。
別のエンティティにします。
『M顧客』『M自社情報』

M顧客

主キー

顧客番号

会社名

郵便番号

住所

所属

肩書

名前

M自社情報

主キー

自社名

郵便番号

住所

所属

担当者名

電話番号

FAX番号

電子メール

3 番目の正規化

3 つ目のルールは『主キーに従属しない属性は別のエンティティにする』です。

現在、少し変更する必要があるエンティティがあります。
「担当者名」は、現在「自社情報」の中にありますが、お客様ごとに担当者が決まっているとヒアリング時に聞いていました。
ですから、「顧客」に所属するべき項目です。 

さらに「顧客」に注目します。担当者は、1人1社ではありません。

さらにエンティティを分けます。「自社担当者」です。

M自社担当者

主キー

所属

肩書

名前

改めて全体を確認し「自社情報」から「自社担当者」へ「所属」を移しました。
「所属」は担当者 に従属すると考えたためです。 

---

●主キーと外部キー
各エンティティ（テーブル）にはリレーションシップのための「キー」を作ります。
キーは、大きく分けて次の2 種類です。
＜主キー＞
リレーショナルデータベースで、テーブルから他のテーブルのある1つのレコードを識別できるように作成されるのが「主キー」です。
※主キーは1レコードごとにデータベースが自動採番するユニークな数字にする。
※ユーザが変更できないようにする。
※「見積番号」 のような業務のために用意されたものとは別につくる必要がある。

主キーは常に不変で『あてになる』ものでなければなりません。 

＜外部キー＞
他のテーブルの主キーを保存するためのフィールドをつくります。
原則として、外部キーから見た主キーは常に1 つです。
1 対多では「多」側のエンティティ（テーブル）に『「1」側の主キーを外部キーとして持つレコード（フィールド）』が作成されることになります。 

この時にER図を考えながらキーの設定をしていくと分かりやすいです！

その他

データベースの構造の設計で、その他に注意したい点を押さえます。
●依存について意識する
データは関連に従った依存を持つことがあります。 

多対多では中間テーブルに作成できるデータは他の2 つのテーブルの外部キーを持つ必要があります。1 対多では、多（子）の側に1（親）の外部キーを持たないといけません。
↑↑↑このような関係を「依存」と呼びます。 

データベースの機能として、依存を無視したデータを作成することも可能です。しかし、ER図を無視した設計となります。

依存を無視したデータが必要であるとしたら、想定外のイレギュラーなデータか、設計時に間違いや見逃しがあるのかもしれません。もう一度、正規化を見直します。 

●正規化しすぎない
正規化を考えていると、新たに多対多にした方がいいのではないか、と考えることがあると思います。しかし中間テーブルを設定すると設計が複雑になります。納期や必要性について総合的に考慮して決定する必要があります。
まずは最低限、必要な機能について優先して考えましょう。 

●ルールは絶対ではない 

正規化で1 対多にするべき項目でも、あえてテーブルを分けない場合があります。

例えば、インポートやエクスポートでデータを取り扱いやすくしたり、『この属性に従属するのは ずっと3 つしかありえない』というような状況から、テーブルを分ける代わりにフィールドを必要な数だけ作成することでテーブル数を少なくし、データベースを必要以上に複雑にしないためであっ たりします。 

●設計と変更 
運用を開始した後に設計上の大きな変更を実施することはお勧めしません。
大きな設計変更は、多くの機能に影響します。
動作確認や変更に対応した作業をする必要があります。 

●数字とUUID
通常、FileMaker Pro のデフォルトのフィールドの自動作成では「主キー」フィールドに計算値自動入力で「Get(UUID ) 関数」が設定されています（計算値自動入力については後述）。
新規レコードを作成すると「主キー」 フィールドに次のような文字列が自動入力されます。 

67574151-F1FC-4ECB-8787-3BE8AA9B7D3F 

UUID（Universally Unique IDentifier）は、全世界でユニークになる（重複する確率が限りなく 0 である）識別子です。FileMaker Pro 独自の考え方ではなく標準化がなされている世界的なものです。 

※主キー数字の連番にするか、UUID を使うか、の選択はカスタム App の役割などによって設計段階で決定します。
※すでに動作している仕様を別な仕様で置き換えることはとても難しい作業です。
予期しないエラーや、関連が成立しなくなってしまった……などの障害が発生するかもしれません。
はじめに決めておきましょう！！

---

以上で１〜４章は終わりです。

次回は５章「リレーションシップ」について学習していきます😄