Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
システム設計勉強会1回
Search
Sora-T
April 01, 2026
Technology
6
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
システム設計勉強会1回
システム設計勉強会1回
Sora-T
April 01, 2026
More Decks by Sora-T
See All by Sora-T
システム設計勉強会2回
soratogo331
0
7
LT会ネタ AI時代に対する自分の思考
soratogo331
0
52
Other Decks in Technology
See All in Technology
JAWSUG TOHOKU 青森支部 「LoGoチャット」のAWS移行で 乗り越えたこと
taketakekaho
0
330
子育てエンジニアの可処分時間が減っても成長を諦めない戦い方
sudoakiy
6
4.6k
Getting Started with Google Antigravity
glaforge
0
300
二歩目のフロントエンド・ウェブアクセシビリティ
camiha
2
570
アウトプット初心者、半年間のふりかえり
4o1sobblue
0
430
AIにシークレットを見せない、WSL2で安全な開発環境
yazm
0
300
"優秀な誰か"の下位互換にならないために
yut0naga1_fa
1
1.8k
宣言型部分更新は何を解決しどこへ向かうのか
shuta13
1
450
Claude の新機能を、 出た日に触って社内に届けるまで
rfdnxbro
1
170
Tofu-Controller lightning talk @ Containerday 2026
gionn
0
110
Post AI時代のリファクタリング実践記 / Refactoring in the post AI era
kaminashi
1
230
SAENM ~Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録!~
terapyon
0
110
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
940
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
280
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
Faster Mobile Websites
deanohume
310
32k
Automating Front-end Workflow
addyosmani
1369
210k
Into the Great Unknown - MozCon
thekraken
41
2.8k
Darren the Foodie - Storyboard
khoart
PRO
4
4k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.6k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
330
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Transcript
システム設計とは? 第1回勉強会
そもそもシステムとは何? システム = 受け取ったデータを処理して値を出力する仕組み 例えば、 • 入力値: 購入したい商品のバーコード • 処理:
商品価格の計算 • 出力値: 会計の金額
なぜ設計が必要なの? エクセルで十分じゃない?
なぜシステム設計が必要なの? 要件があるから • 他システムと連携 • データ整合性 • セキュリティ • 数千人規模のユーザーで使いたい
• データ量が膨大だから 要件に合わせるためにシステム設計が必要
システム設計では何を考えるの? ExcelがインストールされたPCで • 在庫管理 • 発注管理 • 人員管理 • etc,,,
上記のことは実現できるがユーザーには不十分 なぜなら要件を満たさないから
システムの概要設計 概要設計のフェーズでは、 • 「何を作るか」を決める • 機能一覧・画面構成・データの流れ • 発注者・PMと合意するための設計 • 例:商品番号が入力されたら価格を取得し、合計金額を計算する
システムの詳細設計 詳細設計のフェーズでは、 • 「どう作るか」を決める • DB定義・API仕様・クラス設計 • エンジニアが実装するための設計 • 例:「入力された商品番号を元に商品マスタテーブルから価格を取得し、レスポンスとし返却する」
システム設計に必要な 4要素 システム設計では単に概要設計の中身を詳細設計に落とし込むだけでは不十分 単にシステムが使えるだけでなく、以下のような場合のことを考えなければならない • システムが稼働するサーバーがダウンしたら? • ユーザー数が増えてサーバーの負荷が増大したら? • データに整合性が保たれるか?失われることはないか?
• パスワードが解読されてしまったら? 上記のようなリスクファクターを洗い出すためにこれから紹介する考え方が必要となる
可用性(Availability) 使用するサービスがダウンした場合、 • 在庫管理システムなら発注できない、在庫数が把握できない • 社内システムなら業務が遂行できない • 銀行のシステムならATMが利用できない、オンラインバンキングが利用できないなどの影響 とりあえず動くシステムとサーバーがダウンしてもバックアップサーバーで稼働するシステムでは、根本の設計か ら異なる
→要件として最初に定める必要がある
可用性(Availability) 可用性には、SLA(Service Level Agreement)という定量的に定められる指標が存在する • SLAの目標値によってシステム設計の内容も変わってくる • 要件側で定める必要がある SLA(%) 年間ダウンタイム
99% 約87時間 99.9% 約8.7時間 99.99% 約52分
スケーラビリティ (Scalability) 例えば以下の場面を想像してみよう • システムを利用するユーザーの数が5倍に増えた • データの量が増えてサーバーのストレージ容量が不足しそう • システムに多くの機能が追加され、サーバーへの負荷が増大した システムは最初の規模のままでは対応できないという問題が発生する
スケーラビリティとは、システムの負荷やデータ量が増えたときに性能を維持しながら拡張できる能力
スケーラビリティ (Scalability) スケーラビリティを実現する方法 • 1台のサーバー強化する(垂直) ⇨簡単だが上限がある、変化する需要には対応しづらい • 複数台のサーバーを用意する(水平) ⇨柔軟に増減できるが、オンプレや自社 DCなど物理設置では上限がある(クラウド向き)
一貫性(Consistency) 例えば以下の場面を想像してみよう • ECサイトで在庫が 1個しかない商品 • 同時に 2人が購入 • 両方の注文が成功してしまった
システム上で在庫が-1個となってしまう システムではデータの矛盾が発生する可能性がある
一貫性(Consistency) 一貫性とは、 • データが常に矛盾のない状態を保つこと 一貫性を実現するには? • トランザクション(DB側で排他制御) • 楽観ロック・悲観ロック •
メッセージキュー(SQSなど)で順番に処理
エクササイズ 1: 人気アイドルのチケット販売 シナリオ: 某人気アイドルのライブチケットが 7/7 20:00より開始 • 過去には通常時の100倍のアクセス数を記録した Question
• サーバーが落ちないようにどう設計する? • アクセスが集中してもパンクしないようにリクエストをどう捌く?
エクササイズ 2: SNSの「いいね」カウンター シナリオ: 某メッシ・某クリロナが SNSに写真を投稿した • 過去の投稿では1時間に100万「いいね」が押された Question •
全てのユーザーに「全く同じ瞬間、全く同じカウント数」を見せる必要がある? • それとも、数秒遅れてもいいから、システムが止まらないことを優先する?