1. 20冊の分厚いバインダーという「物理的な敵」
練習アプリでの成功を糧に、ついに当社業務の「命綱」である**「部品管理台帳システム」**の開発に着手しました。
現状、私たちの目の前には、部品ごとの図面や購入・販売履歴が綴じられた「紙のバインダー」が鎮座しています。その数、実に20冊以上。片手では持てないほどの重量と厚みを持ったこの物理ファイルこそが、今回デジタル化すべき最大のターゲットです。 本来ならきちんとした設計図（ER図）を書くべきでしょうが、そこは一人開発の特権。「作りながら考える」という直感重視のアジャイルスタイルで、この膨大なデータの移行に挑みます。
2. 最初の重要決断：すべてを司る「ユニークID」の設計
データベース構築において最初に直面した課題は、**「何を基準にデータを区別するか（主キーの選定）」**でした。 図面番号や品名は顧客が決めるものであり、重複したり、そもそも番号がなかったりするため、「ユニーク（唯一無二）な値」としては不適格です。
そこで、自社管理専用の**「内部ID」**を発行することにしました。
- ルール： 7桁の数字。開始番号は「5000000」。
- 動作： 新規レコード作成時に自動採番され、絶対に重複しない。
この「5」から始まる7桁の数字が、以後の全システムで部品を特定するための背骨となりました。
3. 直感が冴えた「2段階構造」のアーキテクチャ
ここで、開発者としての「直感」が働き、いきなり台帳を作るのではなく、データを2階層に分ける構造を採用しました。
- 部品マスタ（親）： 顧客名、図番、品名などの「基本情報」だけを持ち、ユニークIDを発行する場所。
- 管理台帳（子）： マスタのIDに紐づき、詳細な履歴やスペックを管理する場所。
なぜ分けたのか。それは「マスタ登録はしたが取引履歴が発生しないケース」への対応や、万が一の手配ミス（台帳削除）時のリスク分散、そして将来的な「アセンブリ部品（別部署）」への拡張を見越してのことでした。 結果として、この**「マスタとトランザクションの分離」**という判断は、後のシステム拡張において大正解だったことが証明されます。
4. データベースの壁：「リレーション」と「ルックアップ」
開発を進める中で、Excelユーザーが必ずぶつかる壁、**「リレーションシップ（関連）」**の概念についに直面しました。 「テーブル（年賀状の宛名リスト）」同士を線で繋ぎ、IDをキーにして別テーブルの情報を表示させる機能です。
さらに、ここで非常に重要な概念の違いを学ぶことになりました。**「リレーション（参照）」と「ルックアップ（転記）」**の違いです。
① リレーションシップ（動的な参照）
- 仕組み： 常に参照先のデータを表示する。
- 例： マスタの「品名」を修正すると、過去の全ての表示箇所でも新しい品名に変わる。
② ルックアップ（静的な転記）
- 仕組み： データ作成時の値をコピーして保存する。後で参照元が変わっても、こちらは変わらない。
- 例： 過去の注文書の「単価」や「図面番号」。
なぜ使い分けが必要か？（結婚改姓のパラドックス）
わかりやすい例として「結婚による改姓」があります。 山田花子さんが結婚して田中花子さんになった時、マスタは「田中」に変更します。これからの年賀状は「田中様」宛で良いですが、過去に「山田様」宛に出した年賀状の記録まで「田中様」に書き換わってしまっては、歴史の改ざんになります。
当社の業務も同じです。図面が改訂されて「Ver.2」になっても、過去に納品した「Ver.1」の記録はそのまま残さなければなりません。 「常に最新を見たい場所」にはリレーションを、「その瞬間の記録を残したい場所」にはルックアップを。 この使い分けを理解した瞬間、データベースを制するための大きな鍵を手に入れた確信がありました。
（続く）
【編集協力】 このプロジェクト記録の文章表現は、Gemini（Google AI）による構成案の作成および校正支援を受けています。