Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
私の推し技術(DERTA Gig #18)
Search
akshimo
July 06, 2025
1
46
私の推し技術(DERTA Gig #18)
akshimo
July 06, 2025
Tweet
Share
More Decks by akshimo
See All by akshimo
UPDATEがシステムを複雑にする? イミュータブルデータモデルのすすめ
shimomura
3
630
5分でわかる イミュータブル データモデル
shimomura
2
140
アラートの話 をしよう!
shimomura
0
70
serverless
shimomura
1
200
機械翻訳との付き合い方
shimomura
0
240
Featured
See All Featured
A better future with KSS
kneath
238
17k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Why Our Code Smells
bkeepers
PRO
337
57k
We Have a Design System, Now What?
morganepeng
53
7.7k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
340
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Balancing Empowerment & Direction
lara
1
450
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
How GitHub (no longer) Works
holman
314
140k
Transcript
私の推し技術・プロダクト DERTA Gig vol.18 akshimo
• akshimo(あくしも) • フリーランス • ソフトウェアエンジニア • PHPカンファレンス新潟2025 コアスタッフ •
Niigata5分Tech実行委員会 • KomeKaigi2025実行委員会
• AI系(Devin, Claude Code, n8n,...) • Vim • アジャイル系の何か(ふりかえり手法とか...) 思いついた推し技術・プロダクト候補
今回の推し技術は …
RDB 今回の推し技術は …
今日の内容は ぺちこん新潟での登壇内容と かなり重複します 別に時間がなくてネタを作れなかった わけじゃないんだからね!
• 大生成AI時代を生き残るために • RDB自体ではなく、それを通してあることを伝えたい • こんな時代だからこそ地に足をつけて なぜ推すのか? 学生も多いしね
遅延束縛(結合) キーワード
多少専門的な用語や人名を 出すことがありますが、 雰囲気で聞いてください
エンジニアの人?
エンジニアリングできる人?
エンジニアリング? プログラミングと違うの?
ソフトウェアエンジニアリングとは 時間で積分したプログラミングである Titus Winters, Tom Manshreck , Hyrum Wright 『Googleのソフトウェアエンジニアリング
―持続可能なプログラミングを支える技術、文化、プロセス』
• ソフトウェアは作って終わりではない • ビジネスにあわせ成長・進化・変化が求められる • そして、「データベースの寿命はアプリケーションより長い」 by そーだいさん エンジニアリングは時間積分
かといって未来を全て予測はできない … どうすれば良いか?
DBに何を保存すれば 良いか? 鍵となる考え
ITって情報技術でしょ? じゃあ”情報”を保存すれば いいんじゃない?
その考えはちょっと気をつけた方が 良いかも? ITって情報技術でしょ? じゃあ”情報”を保存すれば いいんじゃない?
DIKWピラミッド 知恵 知識 情報 データ
• データ ◦ 客観的、事実、未整理、未加工、意味がない。 • 情報 ◦ 整理、分析、解釈、計算されている。 意味、目的がある。 データと情報の違い
• データ ◦ 客観的、事実、未整理、未加工、意味がない。 • 情報 ◦ 整理、分析、解釈、計算されている。 意味、目的がある。 データと情報の違い
こっちを保存すべき!
”ユーザー”テーブル
先月に有料会員を辞めた人に 再入会を勧めるお知らせを送りたいんだよね
”ユーザー”テーブル
オワタ\(^o^)/
こうしておけばよかった
Write • トランザクション整合性 • 集約単位 • ドメインモデル、正規化 Read • 結果整合性
• 集約をまたぐ • クエリ最適化、非正規化 WriteとReadに求められるもの
• DBには起きたコトをそのまま保存する • 計算・解釈は”後から”できる ◦ リレーション演算(テーブル、クエリ、View) ここまでのまとめ
• DBには起きたコトをそのまま保存する • 計算・解釈は”後から”できる ◦ リレーション演算(テーブル、クエリ、View) ここまでのまとめ 遅延束縛!
• 蒸留 • インピーダンスミスマッチ • 非エンジニアとのコラボレーション 今日話せなかったが 他にもこんなことを考える必要がある
じゃあ全ての設計を “ガチ”でやれば良いのか?
• エンジニアリソースは無限ではない • 8:2の法則を意識する • バリューを生み出す”コア”の部分を優先する ◦ それ以外は外注、SaaS、AIの利用を積極的に検討 個人的な答えは No
事業を理解し 戦略を策定できる エンジニアが求められる
事業理解・戦略策定し 進化可能なソフトウェアを設 計する 現状AIには難しいこと
こんな時代だからこそ 地に足をつけ 真にバリューを出せる エンジニアリングをする
ご清聴 ありがとうございました!