市民開発者向け正しいテーブル設計

5K Views

June 22, 24

スライド概要

市民開発者として活動してすぐの方々にとって、身近なデータは Excel であることから、アプリのデータソースとしてのテーブルをExcelライクな設計にしがちです。
そんな方々に、テーブル設計はどのように行うべきか、なぜ必要かを解説しています

profile-image

高校卒業後、デザイナーとして就職しましたが、その後キャリアチェンジを行い、インフラエンジニア、そしてシステムエンジニアとして様々な企業に対してシステム導入コンサル及び設計構築を行い、その後友人と共に株式会社ソントレーゾを立ち上げました。立ち上げ後は、お客様に対してデジタルトランスフォーメーションを推進するため、Azure、AWS、GCPを使用したオンプレミスシステムの移行や Microsoft 365 の導入支援、Power Platformの導入・教育・構築支援を行っております。お客様に対しては、企業文化、業務オペレーションなどといった様々な観点から最適でかつ低コストで導入できるような設計を心掛け、最終的にはお客様自身で利活用推進が可能になるように努めました。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

市民開発者向け 正しいテーブル設計 株式会社 BizOptimars りなたむ(中村亮太)

2.

自己紹介 りなたむ Microsoft MVP Business Applications (2020-2024) Cacoo アクセラレーター Power Platform 関連の動画の作成や、ITコミュニティの支援や運営を行っています。 市民開発者の創出やキャリアチェンジのアドバイスなどもしています。 ◇運営コミュニティ ・Japan Power Platform User Group ・Japan Power Apps User Group 大阪 ・CMC_Meetup 大阪 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. Rinatamu_ITDR Rinatamu_Bike @rinatamu_bike 2

3.

自己紹介 中村 亮太 株式会社BizOptimars 代表取締役社長 - 記事 - - 経歴 ・金融機関の情報系システムの導入提案/設計構築 ・業務システムのクラウド移行提案/設計 ・Microsoft 365 の導入提案・教育 ・テレワーク / BYOD / セキュリティコンサル ・Power Platform (ローコード開発プラットフォーム) の導入・教育支援 ・多種多様な企業へのDX導入コンサル ・市民開発者の創出支援 ・社内コミュニティ支援、企画など - 執筆・監修 - - 受賞 ・Microsoft MVP(Most Valuable Professional) Business Applications 部門受賞 (2020-2024) 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 3

4.

(Business + Optima)× Engineers = 業界・業務 最適な・最善な 開発者たち 我々は、顧客ビジネスの「最適解」を適切に提供する技術集団です。 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 4

5.

内製化を成功させます 既存システムの導入スタイルから、内製化に移行する 企業が増えてきている中、自らの業務をどのように 改善すればいいのか悩まれている企業も今だ多い 現状です。 当社は、これまで多くの企業や団体に対して、内製化 文化を根付かせ、支援してきました。 10+ 3000+ 200+ 支援企業 支援団体数 支援コミュニティ 延べ参加人数 総Q&A回答数 ※2024年6月現在 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 5

6.

市民開発者とは 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 6

7.

依頼から内製化へ 他者や他部門、そして他社に依頼していく中で、業務ノウハウはどんどん失われていきます。 そのまま開発をするのではなく、コミュニケーションやフィードバックを繰り返しながら開発をしていくこと になっていきます。その時間やコストが非常にもったいないからこそ、内製化は必要なのです 今までは これからは 開発依頼 IT担当者 開発依頼 担当Sier 業務委託者など 業務担当者

8.

市民開発者とは・・・ ビジネスにおいて最も最適なシステムを提案、開発を行っていく人です。 専任技能はなくとも、ビジネスの目標を完全に理解し、それに基づき必要な仕組みやUXを提案し 作り上げていく開発者です。

9.

コンポーネント分離 これまで、企業や業務に合わせてそれぞれカスタマイズしなければならず、多大な労力を払っていた部分を 内製化によって、それらは実際に使うユーザーが独自に作り、開発者は内製化に必要な部品(API)を用意する だけで済むようになります。 プロ開発者 ミドルウェア ミドルウェア 導入プロダクト API 導入プロダクト ローコード・ノーコード 企業・業務文化 企業・業務文化 プロ開発者 2024/6/22 BizOptimars, Inc. All Rights Reserved. 市民開発者 9

10.

やりがちなデータ設計 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 10

11.

“異様”に列が多いテーブル Excel 的な感覚で作ることが多いため、異様に列が多いテーブルを作りがち ※一つにまとめたがる傾向にある 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 11

12.

列が多いテーブルの問題点 一つのテーブルで完結している場合の問題点は以下の通り • 共通項目 • 商品や科目といった、選択入力項目にする追加や削除がされやすいデータに 対応するためにアプリ側を修正する必要がある • アプリ側を修正するので、そういったデータの追加や削除の度に再度テストをし 直さなければならない→デグレード確認 • データ正規化の欠如 • データが修正された際の過去データが喪失する場合がある • 第3承認で却下され、第1承認からやり直した場合、前回の履歴が上書きされる • 商品購入データの場合、購入後、一部返品により削除されると、何を購入したかわからなく なる • 同一レコードの更新が頻発し、データ不整合が発生する場合がある • 処理スピードの低下 • データ量の増加によるパフォーマンス低下 • 検索などのクエリが複雑化する 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 12

13.

最適なデータ設計 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 13

14.

エンティティ システムが利用するデータの実態(エンティティ)についてまとめ、表形式に定義します 商品 Id 商品名 カテゴリ 1 うるさらX エアコン 200 300,000 2 risora エアコン 400 150,000 3 ストリーマ 空気清浄機 500 50,000 在庫数 単価 注文 Id 商品名 顧客名 住所 1 うるさらX A様 大阪府吹田市 3 900,000 2 risora B様 大阪府大阪市北区 1 150,000 3 ストリーマ C様 兵庫県尼崎市 2 100,000 2024/6/22 注文数 金額 BizOptimars Co., Ltd. All Rights Reserved. 14

15.

エンティティを整理する エンティティをまとめた上で、それらのデータの更新タイミングなどを検証し、データ種別をまとめる データの種別 概要 データ例 マスターデータ項目 特定のイベントがなければ 更新されないデータ項目 ・商品 ・品目 ・取引先企業 ・ユーザーデータ ・事業所 一般利用データ項目 ユーザーの「利用」により 都度更新されるデータ項目 ・問い合わせ ・見積もり ・販売 ・営業 ログデータ項目 ユーザーの「操作」により 都度更新されるデータ項目 ・参照履歴 ・ログイン履歴 ・取引履歴 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 15

16.

正規化 データ種別毎に分類した上で、テーブルを作成し、IDといった一意識別子に置き換えて各テーブルを結びつける 商品 カテゴリ Id 商品名 カテゴリID 1 うるさらX 1 2 risora 3 ストリーマ Id カテゴリ名 300,000 1 エアコン 1 150,000 2 空気清浄機 2 50,000 3 給湯機 在庫管理 単価 注文 顧客情報 Id 商品ID 在庫数 Id 商品ID 顧客ID 1 1 200 1 1 1 2 2 400 2 2 3 3 500 3 3 2024/6/22 Id 顧客名 住所 3 1 A様 大阪府吹田市 2 1 2 B様 大阪府大阪市北区 3 2 3 C様 兵庫県尼崎市 注文数 BizOptimars Co., Ltd. All Rights Reserved. 16

17.

正規化 データ種別毎に分類した上で、テーブルを作成し、IDといった一意識別子に置き換えて各テーブルを結びつける 商品 カテゴリ Id 商品名 カテゴリID 1 うるさらX 1 2 risora 3 ストリーマ Id カテゴリ名 300,000 1 エアコン 1 150,000 2 空気清浄機 2 50,000 3 給湯機 在庫管理 単価 注文 顧客情報 Id 商品ID 在庫数 Id 商品ID 顧客ID 1 1 200 1 1 1 2 2 400 2 2 3 3 500 3 3 2024/6/22 Id 顧客名 住所 3 1 A様 大阪府吹田市 2 1 2 B様 大阪府大阪市北区 3 2 3 C様 兵庫県尼崎市 注文数 BizOptimars Co., Ltd. All Rights Reserved. 17

18.

ER図 正規化したデータの関連がわかりやすいように図式化します 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 18

19.

なぜデータ設計が必要なの? 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 19

20.

整理整頓 部屋の掃除と同じで、分類ごとに細かくデータが分別されていないと、人間と同じようにコンピューターも 探すのが時間がかかりますし、人間もそのシステムを理解するのに非常に苦労します。 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 20

21.

実態データ(トランザクション)は「更新」しちゃダメ 購入履歴や承認履歴のような、事実のデータは、追加はもちろんのこと、修正や削除といったこと自体も 記録する必要があるため、登録データを「更新」してはいけないと認識し、修正や削除といった事実を 記録するということを覚えておきましょう 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 21

22.

アプリも更新しちゃダメ アプリの修正は、修正後に必ず「リグレッションテスト」(変更に伴う不具合の確認)を行います。 このテストは、作成時と同様のテストを行う必要があるため、データ更新の度にアプリを更新すると 非常に多くの人的負荷が発生する。 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 22

23.

データの更新は、データの更新で完結する仕組み マスターデータなどの更新が必要な場合は、データ更新のみで終わる仕組みを考えることが大事。 そうすることで、不要なアプリの更新を減らし、作業負荷を軽減させ、ユーザーにいち早く変更を 反映させることができるようになる 2024/6/22 BizOptimars Co., Ltd. All Rights Reserved. 23