第5部まとめ
このページで学ぶこと
Section titled “このページで学ぶこと”- セキュリティ、テスト、アクセシビリティの共通点と違い
- 品質を公開直前の検査ではなく、案件全体の意思決定へ組み込む方法
- リスク・受入条件・責任分界・公開判定を統合する方法
- 実案件のケースから確認項目を組み立てる方法
- 第6部のGit・CI/CD・監視・SEOへつながる考え方
第5部の三領域は別々の専門分野ですが、共通する考え方があります。
flowchart TD
R[事業・利用者のリスク] --> Q[品質要件]
Q --> D[設計]
D --> I[実装]
I --> V[検証]
V --> J[公開判断]
J --> O[監視・改善]
O --> R
- セキュリティ：不正・漏えい・改ざん・停止等のリスクを抑える
- テスト：要件と利用者フローが成立することを検証する
- アクセシビリティ：多様な利用者が情報・機能を利用できるようにする
いずれも、最後にツールを実行するだけでは達成できません。
三領域の共通点
Section titled “三領域の共通点”「安全に」「十分テスト」「配慮する」では合否が分かりません。
- 対象
- 目標
- 方法
- 担当
- 成果物
- 受入条件
- 未達時の判断
を決めます。
正常時だけでは不十分
Section titled “正常時だけでは不十分”- 認証失敗
- API停止
- 0件
- 入力エラー
- タイムアウト
- キーボード操作
- 拡大
- 外部サービス障害
- 権限不足
等を設計・検証します。
自動化だけでは不十分
Section titled “自動化だけでは不十分”自動ツールは反復・網羅に強い一方、事業要件、悪用シナリオ、文章の意味、操作の自然さは人間が判断します。
公開後の変更、CMS更新、ライブラリ、アカウント、外部サービスで品質が変化します。
保守・監視・回帰確認を用意します。
三領域の違い
Section titled “三領域の違い”| 領域 | 主な問い | 代表的な成果物 |
|---|---|---|
| セキュリティ | 何を誰から守り、問題時にどう対応するか | データ・権限表、診断結果、対応計画 |
| テスト | 仕様・業務・利用者フローが成立するか | テスト計画、結果、不具合、公開判定 |
| アクセシビリティ | 多様な方法で情報・操作を利用できるか | 目標、デザイン・実装仕様、試験結果 |
一つの「品質チェックリスト」へ完全に統合せず、専門領域ごとの深さも維持します。
品質計画の作り方
Section titled “品質計画の作り方”1. 対象を整理する
Section titled “1. 対象を整理する”- 公開ページ
- 管理画面
- API
- CMS
- フォーム
- 会員・予約
- 外部サービス
- PDF・動画
- 開発・検証環境
- Git・CI/CD
- 運用業務
2. 重要な利用者・業務フローを決める
Section titled “2. 重要な利用者・業務フローを決める”flowchart LR
A[利用者が探す] --> B[比較・判断]
B --> C[入力・認証]
C --> D[送信・決済・予約]
D --> E[完了・通知]
E --> F[管理・後続業務]
3. 失敗時の影響を評価する
Section titled “3. 失敗時の影響を評価する”- 利用できない
- 誤った情報
- 漏えい
- 二重処理
- 法務・契約
- ブランド
- 売上
- 復旧コスト
- 一部利用者だけ排除
4. 要件と検証を対応づける
Section titled “4. 要件と検証を対応づける”| 要件 | 設計・対策 | 検証 | 担当 |
|---|---|---|---|
| 管理者のみ公開可能 | ロール・サーバー側認可 | 権限別テスト | 開発・QA |
| 二重予約を防ぐ | 一意キー・状態確認 | 同時・再送テスト | API・QA |
| キーボードで申込可能 | HTML・フォーカス設計 | 手動・支援技術 | UI・QA |
| API停止時に案内 | タイムアウト・代替表示 | 障害状態テスト | 開発・運用 |
| ライブラリを維持 | SCA・更新フロー | CI・定期確認 | 保守 |
5. 公開条件を決める
Section titled “5. 公開条件を決める”- 重大指摘
- 必須シナリオ
- 未達事項
- 回避策
- 切戻し
- 監視
- 公開後対応
- 承認者
リスクベースで優先する
Section titled “リスクベースで優先する”品質活動には時間・予算の制約があります。
すべてを削るのではなく、高いリスクへ重点配分します。
flowchart TD
A[機能・コンテンツ] --> B[影響の大きさ]
A --> C[発生可能性]
A --> D[変更頻度]
A --> E[検出の難しさ]
B --> P[優先度]
C --> P
D --> P
E --> P
優先度が高くなりやすいもの：
- 個人情報
- 決済・予約
- 認証・権限
- 全ページ共通部品
- 主要コンバージョン
- 法的・契約上の必須情報
- API・外部サービス
- CMS公開
- 大量アクセス
- 多くの利用者を排除する障壁
リスクが低い箇所を無確認にするのではなく、確認方法・深さを変えます。
品質の責任分界
Section titled “品質の責任分界”| 役割 | 主な責任 |
|---|---|
| クライアント責任者 | リスク・目標・残課題・公開承認 |
| 業務担当 | 業務ルール・正しいデータ・受入 |
| PM・ディレクター | 要件、範囲、体制、進行、判断材料 |
| デザイナー | 状態、色、操作、情報表現 |
| エンジニア | 安全・堅牢な実装、自動テスト、ログ |
| QA | テスト設計、実行、不具合・結果 |
| セキュリティ専門家 | リスク・診断・助言 |
| アクセシビリティ専門家 | 標準・実装・試験・助言 |
| 運用・保守 | 監視、更新、障害、回帰、改善 |
| CMS編集者 | コンテンツ品質・公開ルール |
専門家へ委託しても、最終的な事業判断と運用責任は消えません。
ケーススタディ1：ヘッドレスCMSのコーポレートサイト
Section titled “ケーススタディ1：ヘッドレスCMSのコーポレートサイト”- 静的配信
- ニュース・事例をCMS更新
- 問い合わせは外部フォーム
- 多言語
- 動画・PDF
- 公開後は少人数保守
セキュリティ
Section titled “セキュリティ”- CMS・Git・CI/CD権限
- APIキー・Webhook
- 外部フォームの個人情報
- 依存ライブラリ
- CDN・ストレージ設定
- 管理者MFA
- ログ・権限棚卸し
- CMS公開から反映
- ビルド失敗
- 一覧・詳細・カテゴリ
- 多言語・長文
- フォーム
- 404・リダイレクト
- 計測
- 性能
アクセシビリティ
Section titled “アクセシビリティ”- 見出し・ナビゲーション
- 画像代替
- 動画字幕
- キーボード
- CMS入力ルール
- 拡大
- 多言語の言語指定
- ライブラリ更新
- CMSコンテンツ監査
- 外部フォーム障害
- 自動・定期アクセシビリティ確認
- ビルド監視
ケーススタディ2：キャンペーン応募フォーム
Section titled “ケーススタディ2：キャンペーン応募フォーム”- 公開期間3か月
- CM後のアクセス集中
- 個人情報
- CRM連携
- スマートフォン中心
- 抽選・完了メール
セキュリティ
Section titled “セキュリティ”- 収集項目の最小化
- スパム・Bot・大量送信
- 二重応募
- APIキー
- 保存・削除期間
- CRM・メールの部分失敗
- 管理画面権限
- 入力境界
- 戻る・再読み込み
- 二重タップ
- タイムアウト
- CRM停止
- メール失敗
- 大量アクセス
- 受付番号
- 公開終了
アクセシビリティ
Section titled “アクセシビリティ”- 入力ラベル
- エラー概要・項目エラー
- 自動入力
- ソフトウェアキーボード
- 文字拡大
- 完了通知
- 時間制限
- CAPTCHA・代替
短期サイトでも、公開期間中の修正時間が少なく、個人情報・CM流入の影響が大きいため、品質優先度は高くなります。
ケーススタディ3：SPA型予約サービス
Section titled “ケーススタディ3：SPA型予約サービス”- ログイン
- 検索・選択
- リアルタイム予約枠
- 決済
- 複数API
- 継続開発
セキュリティ
Section titled “セキュリティ”- 認証・認可
- 自分と他人の予約
- 金額・枠のサーバー側確認
- セッション
- 二重決済
- 監査ログ
- 外部API・Webhook
- コンポーネント
- API結合
- 主要E2E
- 同時予約
- タイムアウト
- 決済結果照会
- 回帰自動化
- ブラウザ・実機
アクセシビリティ
Section titled “アクセシビリティ”- SPA遷移
- モーダル
- 日付選択
- 入力候補
- フォーカス
- 動的残枠通知
- セッション期限
- キーボード完了
三領域を別々の最後の検査にすると、予約フローの設計問題を見落とします。
ケーススタディ4：CMS記事更新
Section titled “ケーススタディ4：CMS記事更新”公開時のテンプレートは適切だったが、運用開始後に次が増えました。
- 見出しの代わりに太字
- 「こちら」リンク
- 代替テキストなし
- 巨大画像
- PDFだけの案内
- 古い情報
- 外部埋め込み
- CMS項目・許可書式の制限
- 入力ガイド
- 承認チェック
- 画像最適化
- 自動リンク・構造検査
- 定期サンプリング
- 編集者研修
- 問い合わせ・改善バックログ
技術的な品質を、コンテンツガバナンスへつなげます。
公開前診断の結果に重大指摘がありません。セキュリティ保守をなくしてよいでしょうか。
回答例
診断は一定時点・範囲の確認です。ライブラリ、アカウント、設定、CMS、外部サービス、監視、インシデント対応は公開後も必要です。E2E自動テストがすべて通っています。受入確認を省略できますか。
回答例
業務ルール、文章、視覚、実機、アクセシビリティ、未知の操作等は別途確認が必要です。自動E2Eの対象・期待値にも誤りがあり得ます。自動アクセシビリティ検査のスコアが100点です。WCAGへ適合したと言えますか。
回答例
言えません。自動判定できない達成基準や、代替テキスト・フォーカス・操作の適切さがあります。対象・手動試験・適合要件を確認します。公開日を優先し、中程度の不具合を残すことになりました。何を残しますか。
回答例
内容、影響、発生条件、回避策、利用者案内、対応期限、担当、監視方法、責任者承認を記録します。安全・主要業務上許容できない問題は公開を見直します。第三者の予約ウィジェットがキーボードで使えません。自社では修正できません。どうしますか。
回答例
代替手段を提供し、制約を説明し、ベンダーへ改善を依頼します。選定・契約更新時にアクセシビリティを評価し、将来の代替製品も検討します。PMチェックリスト
Section titled “PMチェックリスト”- セキュリティ・テスト・アクセシビリティの目標と範囲を要件化している
- 重要な資産・利用者フロー・失敗影響を整理している
- 正常時以外の状態をデザイン・仕様へ含めている
- 要件と検証方法・担当を対応づけている
- 自動検査と人間による判断を組み合わせている
- 外部サービス・第三者コンテンツを対象に含めている
- 開発・検証・本番の差を把握している
- 専門診断・試験の範囲と時期を決めている
- 残課題のリスク受容を責任者が承認している
- 公開条件、切戻し、監視、公開後対応を定義している
- CMS・ライブラリ・権限・コンテンツの継続確認を保守へ含めている
- 結果・制約・改善計画を引継ぎ可能な形で残している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「品質担当が最後に確認すればよい」
Section titled “「品質担当が最後に確認すればよい」”要件・情報構造・デザイン・システム構成で決まる問題は、最後には高コストでしか直せません。
「ツールのスコアをKPIにすれば品質を管理できる」
Section titled “「ツールのスコアをKPIにすれば品質を管理できる」”スコアは一部の測定結果です。利用者の目的、事業影響、対象範囲、手動判断を合わせます。
「専門家へ委託したのでPMは内容を理解しなくてよい」
Section titled “「専門家へ委託したのでPMは内容を理解しなくてよい」”PMは技術詳細をすべて判断する必要はありませんが、対象、成果物、残課題、公開判断、責任分界を管理します。
「公開できたので品質要件を満たした」
Section titled “「公開できたので品質要件を満たした」”公開後に初めて実データ・アクセス・利用環境が現れます。監視・問い合わせ・改善を続けます。
「予算がない場合は三領域をすべて省略する」
Section titled “「予算がない場合は三領域をすべて省略する」”リスクに応じて深さを調整し、最低限必要な安全・利用可能性を確保します。省略する場合は影響と責任を明示します。
理解度チェック
Section titled “理解度チェック”Q1. セキュリティ、テスト、アクセシビリティの共通点は何ですか。
Section titled “Q1. セキュリティ、テスト、アクセシビリティの共通点は何ですか。”回答と解説
対象・目標・役割・検証を要件化し、正常時だけでなく異常・多様な利用を考え、自動と人の確認を組み合わせ、公開後も維持する点です。Q2. 品質計画をリスクベースで作るとはどういうことですか。
Section titled “Q2. 品質計画をリスクベースで作るとはどういうことですか。”回答と解説
失敗時の影響、発生可能性、変更頻度、検出難度等から重要箇所へ深い検証・対策を配分し、他の箇所も適切な深さで確認することです。Q3. 公開判定で残課題を許容する場合、何が必要ですか。
Section titled “Q3. 公開判定で残課題を許容する場合、何が必要ですか。”回答と解説
影響、条件、回避策、監視、対応期限、担当、利用者案内を明確にし、責任者が残存リスクを承認します。Q4. CMS運用が品質へ影響する理由は何ですか。
Section titled “Q4. CMS運用が品質へ影響する理由は何ですか。”回答と解説
編集者が見出し、リンク、画像、PDF、公開日時等を継続変更し、セキュリティ・正確性・アクセシビリティ・性能を変化させるためです。Q5. 第6部のGit・CI/CD・監視が第5部とどうつながりますか。
Section titled “Q5. 第6部のGit・CI/CD・監視が第5部とどうつながりますか。”回答と解説
変更履歴・レビュー、自動テスト・検査、安全な公開、ログ・アラート、障害対応によって、第5部で定義した品質を継続的に維持します。第6部へ進む前の確認
Section titled “第6部へ進む前の確認”次を自分の言葉で説明できれば、第5部の基礎は理解できています。
- 資産、脅威、脆弱性、リスク
- 機密性、完全性、可用性
- 認証と認可
- 多層防御とセキュア・バイ・デザイン
- テストを要件時から設計する理由
- 単体、結合、E2E、自動、手動テスト
- 受入条件と公開判定
- WCAGの四原則
- 標準HTML、キーボード、フォーカス
- モーダル・SPA等の動的UIの難しさ
- 自動アクセシビリティ検査の限界
- 公開後の継続改善
次の第6部では、変更を安全に管理・公開し、公開後に監視・改善するためのGit、CI/CD、運用、技術SEO、サイト移行を学びます。
- OWASP Top 10:2025
https://owasp.org/Top10/2025/ - web.dev Learn Testing
https://web.dev/learn/testing - W3C WAI WCAG Overview
https://www.w3.org/WAI/standards-guidelines/wcag/ - デジタル庁 ウェブアクセシビリティ導入ガイドブック
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook