品質3兄弟という別々のものさし
前回のN-08では、処理を待たせるか裏で回すかという、同期・非同期の設計判断を学びました。今回は、アプリ全体の品質を測る3つのものさし、可用性・拡張性・保守性を扱います。これらは、非機能要件としてM-06で数値化した内容を、設計側で受け止めるものにあたります。3つはまとめて語られがちですが、実はまったく別のことを指しています。
このスライドのポイント
- 前回N-08: 同期・非同期の設計判断（結果を待たせるか、裏で回すか）
- 今回: アプリ全体の品質を測る3つのものさし＝可用性・拡張性・保守性
- これらは非機能要件（M-06）を設計側で受け止める話
- 3つはまとめて語られがちだが、指しているものは別物
3つの品質の定義
順に定義します。可用性とは、止まりにくさ、そして止まっても早く元に戻れることです。M-06で決めた「止まってよい時間」を、設計でどう実現するかという側面です。拡張性とは、利用者やデータが増えても対応できることで、E-10の計算量やJ-10のステートレスな作りが土台になります。保守性とは、変更のしやすさで、N-05で学んだ責任分離と、N-06の結合度・凝集度が整った状態が、そのまま成果になります。大切なのは、この3つは別物であり、同時に全部を最高にはできない、という点です。
このスライドのポイント
- 可用性＝止まりにくさ・止まっても早く戻れること（M-06「止まってよい時間」の設計側）
- 拡張性＝利用者・データが増えても対応できること（E-10の計算量・J-10のステートレスが土台）
- 保守性＝変更のしやすさ（N-05の責任分離・N-06の結合度と凝集度の成果）
- 3つは別物で、同時に全部を最高にはできない
区別できないと投資を誤る
3つを区別できないと、投資の判断を誤ります。たとえば「とにかく止まらないように」と言われるまま、社内50人しか使わないアプリに何重もの冗長な構成を組んでしまう。これは費用も複雑さも無駄に増やすだけの過剰投資です。逆に、これから伸ばす前提のサービスなのに拡張性をまったく考えず、利用者が増えた途端に行き詰まるという、反対向きの失敗もあります。3つを見分けられて初めて、どこにどれだけ力を入れるかを決められます。
このスライドのポイント
- 過剰の例: 社内50人のアプリに、言われるまま何重もの冗長構成→費用と複雑さの無駄
- 不足の例: 成長前提のサービスなのに拡張性を捨てる→増えた途端に行き詰まる
- 3品質を見分けられて初めて、どこにどれだけ力を入れるかを決められる
3品質の対比と優先注記
3つの品質を表で並べて比べます。列は、意味、それを高める設計の例、そして過剰に投資したときに出る症状です。高め方はそれぞれ違い、可用性なら冗長構成、拡張性なら分散や増強、保守性なら責任分離、というように別々です。ここで押さえてほしい優先注記があります。業務アプリでまず効くのは保守性です。利用者数が急増しないアプリでも、承認ルールや税率といった仕様の変更は必ず来るからです。
このスライドのポイント
- 3品質を対比表で並べる: 意味／それを高める設計の例／過剰投資の症状
- 高め方は別物: 可用性=冗長構成／拡張性=分散・増強／保守性=責任分離
- 業務アプリでまず効くのは保守性（利用者数が急増しなくても、仕様の変更は必ず来る）
経費精算アプリでの落とし所
経費精算アプリで、現実的な落とし所を考えます。可用性は、夜間に止まっても翌営業日までに復旧できれば十分で、L-10のバックアップと復旧手順書があれば要件を満たせます。拡張性は、全社員500人分の申請件数をE-10の見積もりで確かめ、それで足りるなら追加の作り込みは不要です。そして保守性は、N-05の責任分離を最優先で守ります。承認ルールや金額の扱いが変わっても、直す場所が1か所で済むようにしておくことが、このアプリでは最も効く投資です。
このスライドのポイント
- 可用性: 夜間に止まっても翌営業日までに復旧できれば十分＝L-10のバックアップと復旧手順書で足りる
- 拡張性: 全社員500人分の申請件数をE-10で見積もり、足りるなら追加の作り込みは不要
- 保守性: N-05の責任分離を最優先。承認ルールや金額の扱いが変わっても直す場所が1か所で済む
技術サンプルカード: 品質の目標設計メモ
サンプルは、3つの品質ごとに目標と根拠を書き出した設計メモの表です。目的は、自分のアプリで各品質をどこまで高めるかを、根拠付きで決めることです。読み方のポイントは2つあります。目標が「最高」ではなく「この規模で足りる線」で書かれていること、そして根拠の列に必ず規模の数値か既出の判断が入っていることです。AIへの質問例はこうです。「このアプリの規模で、可用性・拡張性・保守性のどれにどこまで投資すべきか、過剰な点と不足している点を指摘してください」。
このスライドのポイント
- 種別: table
- 目的: 自分のアプリで各品質をどこまで高めるかを、根拠付きで決める
- サンプル本体:
混同しやすい概念: 拡張性と保守性
混同しやすいのが、拡張性と保守性です。拡張性は、数が増えることへの耐性、つまり利用者やデータが多くなっても耐えられるかの話です。保守性は、仕様が変わることへの耐性、つまり後から作り替えやすいかの話です。似て見えますが、片方は「量」の問題、もう片方は「変化」の問題で、まったく別の軸です。小規模な業務アプリで先に効いてくるのは、ほぼ後者の保守性です。
このスライドのポイント
- 拡張性＝増加への耐性（利用者・データが増えても耐えられるか）＝「量」の問題
- 保守性＝変更への耐性（後から作り替えやすいか）＝「変化」の問題
- 似て見えるが、まったく別の軸。小規模な業務アプリで先に効くのは、ほぼ保守性
バイブコーディングでの確認点
AIが構成を提案してきたら、その規模感を必ず確かめます。聞くべきはこうです。「その構成は何人・何件までを想定していますか」。そのうえで、M-06で決めた自分のアプリの数値と突き合わせ、「この規模に対して過剰ではないですか」と確認します。AIは指定がないと、立派で大がかりな構成を出しがちなので、規模の物差しを人間が持って、過剰投資を止めることが役割です。
このスライドのポイント
- AIが構成を提案してきたら、その規模感を必ず確かめる
- 質問例:「その構成は何人・何件までを想定していますか」
- M-06で決めた自分の数値と突き合わせ、「この規模に対して過剰ではないですか」と確認
- AIは指定がないと大がかりな構成を出しがち。規模の物差しは人間が持つ
一問一答とまとめ
一問一答です。変更のしやすさを指す品質は何でしょうか。（間）答えは、保守性です。30秒でまとめます。可用性は止まりにくさ、拡張性は増加への耐性、保守性は変更への耐性で、3つは別物であり、同時に全部を最高にはできません。業務アプリではまず保守性が効き、可用性と拡張性は、自分の規模に合わせて足りる線を決めるのがコツです。次回はカテゴリNの最終回、これらの判断をまとめて使う技術選定とトレードオフへ進みます。関連資料は「アプリ運用チェックリスト」「AIアプリの品質評価シート」です。
このスライドのポイント
- 一問一答:「変更のしやすさを指す品質は？」→ 保守性
- 30秒まとめ: 可用性=止まりにくさ／拡張性=増加への耐性／保守性=変更への耐性。3つは別物、同時に全部は最高にできない
- 業務アプリではまず保守性が効く。可用性と拡張性は自分の規模に合わせて足りる線を決める
- 次回: カテゴリN最終回、技術選定とトレードオフ
- 関連資料: 「アプリ運用チェックリスト」「AIアプリの品質評価シート」
