設計の進め方と 品質特性品質特性

2026年新卒研修資料

Transcript

1. 設計の進め方と 品質特性 RAILS TUTORIAL TRAINING / 2026 何を気にして設計するか 2026 | GMO ペパボ株式会社
2. はじめに この講義のゴール 設計を進めるときの思考の型を持ち帰る 設計を進めるときの思考の型 を持ち帰る 品質特性という共通言語を知る（暗記不要・索引として使えればOK） 別途の演習で何を気にしてほしいかを理解する 02 / 31
3. はじめに アジェンダ 01 02 03 設計の進め方 品質特性ざっくりツアー 演習の説明 03 / 31
4. 01 設計の進め方 要件理解からブラッシュアップまでの4ステップ
5. 1. 設計の進め方 ：まずは機能要件を把握する Step 1 最初に 「何ができるべきか／できてはいけな いか」を握る。 いか」 を握る。 例：マイページの投稿一覧 ・自分の投稿だけ新しい順に表示 ・削除済みの投稿は出さない ・他人の下書きは見えない ここが決まらないまま「いい設計をしよう」 と始めるのは、 目的が定まっていないのに使 うツールだけ決まっているようなもの。 05 / 31
6. 1. 設計の進め方 ：非機能要件のレベル感も把握する Step 1 「機能としてできる」だけでは足りない。 速さ・安全さ・止まらなさ・直しやすさ… 機能以外で満たすべきことも把握する。 例：マイページの投稿一覧 ・1秒以内に表示 ・他人に投稿が漏れない ・障害時もログイン画面は見える ・5人で長期保守できる 06 / 31
7. 1. 設計の進め方 ：素直な1案を書き下す Step 2 凝らない、カッコつけない。まずは動くもの を描く。 例：マイページの投稿一覧 ログイン中のユーザーの投稿を全件取っ て、新しい順に並べて表示する。 まずはこれで機能としては動く。 このときに「何のためにこの設計か」を言葉 にしてみる。 07 / 31
8. 1. 設計の進め方 ：微妙な点を炙り出す Step 3 素直な設計を眺めて、「これで本当に大丈夫か？」 「これで本当に大丈夫か？」と疑ってみる。 と疑ってみる。 投稿が1万件になったら、ちゃんと表示される？ 他人の投稿が混ざってしまうことはない？ 後でいいねやコメントを足したくなったら、楽に直せる？ 投稿を削除したあと、変な見え方をしない？ 08 / 31
9. 1. 設計の進め方 ：ブラッシュアップする Step 4 払拭する 妥協する 例：投稿が1万件で遅い → ページングやキャッシュで速くする 例：キャッシュを入れた代わりに → 古いデータが少し見えるのは許容する 懸念点に手を打つ 割り切って捨てる 09 / 31
10. 1. 設計の進め方 ステップは反復するサイクル 4 01 要件理解 機能・非機能を握 る → 02 素直な設計 まず1案を描く → 03 微妙な点 気になる点を炙り 出す → 04 ブラッシュアップ 払拭する／妥協す る 回で決まらない。再評価して戻ってOK。サイクルを回すことが設計の本体。 1 10 / 31
11. 02 品質特性ざっくりツアー つの特性とサブ特性キーワード 9
12. 2. 品質特性ツアー あの「微妙な点」には、実は名前がある 速さ・鮮度・追いやすさ・直しやすさ… Step 3で挙げた観点には、品質特性 で挙げた観点には、品質特性という共通の呼び名がある。 という共通の呼び名がある。 ISO/IEC 25010 という国際規格で、9つに整理されている。 12 / 31
13. 2. 品質特性ツアー なぜ品質特性を知っておくべきか レビューで何を見られるかわ かる 先輩が「ここパフォーマンスど う？」「ここセキュリティど う？」と聞く理由が、品質特性 の棚で説明できる。 設計時の観点漏れを防げる つの特性を上から舐めれば、抜 け漏れに気づける。チェックリ ストとして使える。 9 手法を引ける索引になる 「この品質を上げたい」と思った とき、サブ特性のキーワードから 手法を逆引きできる。 13 / 31
14. 2. 品質特性ツアー ISO/IEC 25010 の9特性 品質特性 機能適合性 性能効率性 互換性 インタラクション能力 信頼性 セキュリティ 保守性 柔軟性 いつ気にする？ 常に。無いと他を語る意味なし 大量データ／高アクセス 既存システム連携／複数バージョ ン ユーザーが触る画面・UI 止められない／データ消失NG 個人情報・決済・認証認可 長く育てる／大人数で触る スケール想定／差し替え可能性 サブ特性キーワード 完全性・正確性・適切性 時間効率・資源効率・容量 共存性・相互運用性 習得性・操作性・エンゲージメント 無欠陥性・可用性・耐障害性・回復性 機密性・完全性・否認防止性・真正性 モジュール性・解析性・修正性・試験性 適応性・スケーラビリティ・置換性 14 / 31
15. 2. 品質特性ツアー 機能適合性 概要 機能が、明示・暗黙のニーズをきちんと満たしている か。これが満たされないと他の品質を語る意味がな い。 完全性 必要な機能がすべて備わっているか 正確性 期待通りの結果を正しく返すか 適切性 ユーザーの目的達成に役立つか 15 / 31
16. 2. 品質特性ツアー 性能効率性 概要 リソース（時間・CPU・メモリ・容量）を効率よく使 えているか。大量データや高アクセス下でも要求され た性能が出るか。 時間効率性 レスポンスタイム・スループットが要求を満たすか 資源効率性 ・メモリ・帯域などの使用量が適切か CPU 容量満足性 扱えるデータ量・接続数の上限が要求に足りるか 16 / 31
17. 2. 品質特性ツアー 互換性 概要 他のシステムと、データやリソースを共有しながら共 存・連携できるか。既存資産との接続や複数バージョ ン併存で重要。 共存性 他システムと同じ環境で動作できるか 相互運用性 他システムと情報をやり取りできるか 17 / 31
18. 2. 品質特性ツアー インタラクション能力 概要 ユーザーがシステムを理解・操作しやすいか。多様な ユーザーに使ってもらえるか。旧Usabilityを拡張した 特性。 習得性 使い方を効率よく学べるか 操作性 操作・制御が容易か エンゲージメント 使い続けたくなる体験か インクルーシビティ 多様なユーザーに使ってもらえるか 18 / 31
19. 2. 品質特性ツアー 信頼性 概要 期待されたとおりに動き続けるか。障害が起きても影 響を抑え、復旧できるか。止められない・データ消失 NGなシステムで重要。 無欠陥性 期待される機能を欠陥なく満たすか 可用性 必要なときに使える状態か 耐障害性 障害発生時も動作を継続できるか 回復性 障害後に状態を復元できるか 19 / 31
20. 2. 品質特性ツアー セキュリティ 概要 情報・機能を権限のない利用から守れるか。改ざん・ なりすまし・否認を防げるか。個人情報・決済を扱う なら必須。 機密性 権限のある者だけが情報にアクセスできるか 完全性 情報が不正に改ざんされないか 否認防止性 行為の事後否認を防げるか 真正性 主体が本人であることを保証できるか 20 / 31
21. 2. 品質特性ツアー 保守性 概要 長く育てていけるか・大人数で触れるか。変更・改 修・追加が容易で、状況把握もしやすいか。 モジュール性 変更の影響が局所化されるか 解析性 原因や影響を追えるか 修正性 変更を効率よく安全に加えられるか 試験性 テストを書き・回しやすいか 21 / 31
22. 2. 品質特性ツアー 柔軟性 概要 環境変化や規模変化に追従できるか。差し替え・移行 が容易か。スケールや将来の差し替えを想定するなら 重要。 適応性 異なる環境・条件に適応できるか スケーラビリティ 負荷・規模の拡大に追従できるか インストール性 環境への導入・移行が容易か 置換性 他のソフトウェアと差し替えが容易か 22 / 31
23. 2. 品質特性ツアー 「効く／効かない」では粗すぎ 「保守性に効く」だけでは粗い。どの品質特性のどのサブ特性を・どんな手法で・ 「保守性に効く」だけでは粗い。どの品質特性のどのサブ特性を・どんな手法で・ どう改善するかまで考えられるといい。 どう改善するか まで考えられるといい。 品質特性 保守性 / 性能効率 性… サブ特性 → 解析性 / 時間効率… → 手法 DDD / SOLID / キ ャッシュ… → 改善される事 具体の現象 23 / 31
24. 2. 品質特性ツアー 特性同士は連動する TRADE-OFF （負の相関） 柔軟性 ↑ → 性能効率性 ↓ 差し替え可能にするほど抽象層が増え、実行時オーバ ーヘッドが増える傾向。 SYNERGY （正の相関） 解析性 ↑ → 修正性も ↑ 例：マイクロサービスにする 複数の特性が同時に動く 柔軟性のスケーラビリティ ↑、保守性のモジュール 性 ↑。 一方で、保守性の解析性 ↓（全体の挙動が追いにく い）、信頼性・性能効率性も ↓。 1つの設計判断が、複数の特性に同時に効いてくる。 「どこで何が起きているか」が追えれば、直しやすさ も自然と上がる。 24 / 31
25. 2. 品質特性ツアー つの手法は、いろんな特性に効く 1 手法は1つの特性に1対1で対応するわけではない。たとえば で対応するわけではない。たとえばDDDは複数の特性に同 時に効く。 保守性（モジュール性・解析性）：ユビキタス言語で「どこを直すか」が明確に なる 機能適合性（適切性）：ドメインの本質に合わせたモデルで仕様の取り違えが減 る 柔軟性（適応性）：境界づけられたコンテキストが変化を局所化する 手法の効果は「どの特性に・どのくらい・何を犠牲に」のセットで語ろう。 25 / 31
26. 2. 品質特性ツアー 設計に活かす3つの場面 設計するとき レビューするとき 手法を選ぶとき つの特性を上から舐めて、自分 の設計が見落としていないか確 認する。チェックリストとして 使う。 「ここパフォーマンスどう？」 を「時間効率は要件を満たす か？」と語れる。サブ特性が共 通言語になる。 「この品質を上げたい」と思った ら、サブ特性のキーワードから手 法を逆引きできる。 観点漏れを防ぐ 9 議論の言葉を揃える 索引として引く 26 / 31
27. 2. 品質特性ツアー 索引としての引き方 やりたいこと → 品質特性 → サブ特性 → 手法のキーワード 手法のキーワード。サブ特性まで降りる 。サブ特性まで降りる とググりやすい。 やりたいこと 速くしたい 追いやすくしたい 直しやすくしたい スケールさせたい サブ特性 性能効率性／時間効率 保守性／解析性 保守性／修正性 柔軟性／スケーラビリティ 手法のキーワード キャッシュ・非同期・インデックス ログ設計・トレーシング・命名規約 SOLID・DDD・モジュール分割 水平分散・非同期キュー・マイクロサ ービス 27 / 31
28. 03 演習の説明 タイムライン同期機能の設計バトル
29. 3. 演習の説明 演習内容とプロセス やる内容：Railsチュートリアル + タイムライ ン同期機能の設計バトル 01 02 03 個人ワーク：1人で設計を書き下す ペア議論：品質特性の観点で意見交換 講師バトル：設計意図を言語化して守る／改める 制約 最終成果物は講師との議論で合意を得た ものに限る。「なんとなく」はNG。 要件抽出を体験しよう 要件や制約は最初から渡されない。講師 に積極的に質問して明らかにすること。 29 / 31
30. 3. 演習の説明 求める成果物（4点セット） 01 抽出した要件・制 約 講師への質問で明らかにし た、機能・非機能要件と制 約。 02 03 04 何を重要視したか。どの品 質特性のサブ特性を最優先 したか。 コンセプトを満たす具体の 設計・実装方針。 切り捨てたサブ特性。何を 捨てたかを明示する。 コンセプト 手法 妥協点 30 / 31
31. Thank You! GMO Pepabo, Inc. 31 / 31