エンタープライズで問われる「品質の証明」
エンタープライズレベルのWebサイトには、高度な品質が求められます。では、その品質はどう担保するのでしょうか。たとえば外部のベンダーに依頼して「豊富な実績を持つ我々が完成させました」と宣言されたら「なるほど、完成ですね」と受け取る……ということはありえません。
エンタープライズの現場では第三者によるテストをもって検収完了とされるケースがあります。これは以下のような理由によります。
- そもそも受け入れテストの項目を作るのが難しく、専門的な作業である
- 二者間による合意では信頼性にかけるので、かならず第三者を入れる決まりがある
- テスト結果が文書という形で残る
本稿では「WordPressの制作をベンダーに依頼している企業」と「エンタープライズ案件を引き受けたWordPressエージェンシー」の両方に役立つような情報を記載したいと思います。
第三者によるWebアプリケーションテストとは
誰が何をするのか
第三者テストを担うのは、大きく2種類の事業者です。
品質保証会社は品質管理テストを担当します。Quality Assurance＝QAという呼び方をすることもあります。多数のテスターを抱え、テストケースを人手で実行する体制をとっているのが特徴です。制作会社でも発注元でもない立場から、要件定義書を作成し、仕様書どおりに動いているかを確認します。
セキュリティ専門会社は、脆弱性診断を担当します。自動スキャンと手動検査を組み合わせ、攻撃者の視点でシステムを検査します。企業によっては品質担保よりもセキュリティ担保を優先することがあります。
いずれも流れは同じです。計画 → 実施 → 報告 → 対応 → 再テストという過程の中で、発注側が判断すべき場面が繰り返し訪れます。
なお、脆弱性対策そのものの考え方や技術的な手段については、WordPressの脆弱性対策とは？診断項目・ツール・実施頻度の目安を解説で解説しています。本記事は第三者が入ってきたときにどう向き合うかに集中します。
テストの種類
Webアプリケーションテストと一口に言っても、中身は複数あります。何が実施され、何が実施されないかは案件ごとに異なっています。
| 種類 | 何を確認するか | よくある実施主体 |
|---|---|---|
| 機能テスト | 仕様どおりに動作するか。CMSの投稿・編集・公開など | QA会社 |
| シナリオテスト | 業務の流れに沿った一連の操作が完遂できるか | QA会社 |
| 構成テスト | 端末・ブラウザ別の表示、リンク、レイアウト崩れ | QA会社 |
| 負荷テスト | 想定アクセス数に耐えられるか、応答時間は許容範囲か | インフラ事業者、専門会社 |
| セキュリティ診断 | 脆弱性の有無。Webアプリケーション診断が一般的 | セキュリティ専門会社 |
| アクセシビリティ検証 | JIS X 8341-3等への適合状況 | 専門会社 |
予算と期間の制約から、多くの案件では一部だけが選択されます。自動化された安価なソリューションもありますし、すべてを人手を介在させるフル仕様で行う場合もあります。後者はサイト制作費以上の高額な費用がかかることもあるでしょう。アクセシビリティ診断やセキュリティ診断は高度に専門的な知識が求められるのでここだけ特定のベンダーに依頼することもあります。いずれにせよ、この選択は、発注側が決めることです。
この10年ほどのトレンド
受け入れテストという言葉自体は昔からあります。しかし、その中身は変わりました。
弊社が10年ほど前に手がけた大規模サイトの移行案件では、第三者検証会社によるテスト計画書に、セキュリティテストは「対象外」と明記されていました。実施されたのはCMSの機能テストと、多数の実機による構成テストです。確認レベルも「画面UI上で確認できるレベルを基準とし、ログファイルやサーバ内の情報は確認しない」と定義されていました。
しかし現在ではセキュリティテストが最重要事項としてリストアップされるでしょう。10年前の感覚で「表示と機能が問題なければ検収は通る」と考えていると、そうはいきません。
テスト計画書に書かれること、書かれていないこと
テストが始まる前に、計画書が提示されます。発注側がここを読み飛ばしてはいけません。 テスト計画書に書いてあることはすなわち検収条件、つまり、「完成しているためには必達でなければならない条件」と考えても良いでしょう。
確認すべき項目を挙げます。
対象範囲と対象外
最重要項目です。前述のとおり、実施されないテストの種類は計画書に「対象外」として明記されます。
読むべきは、対象になっているものより、対象外になっているものです。対象外の領域については、テストが通っても何も保証されていません。そこを誰がどう担保するのかは別途決める必要があります。ここをいかに先回りしてカバーするかは制作者の腕の見せ所です。
確認レベルの定義
見落とされがちですが、決定的に重要です。
「画面UI上で確認できるレベルを基準とし、ブラウザのコンソールエラー、ログファイル、サーバ内の情報は確認を行わない」という定義があるなら、画面に出ないエラーは検出されません。データベースに不正なデータが入っていても、画面が正常に見えていれば合格になります。テストの深さがどこまでかを、あらかじめ共有しておく必要があります。
ただし、ログをいっさい確認しないWebアプリケーションの保守は適切ではありません。エラーが出ているか確認し、かならず潰すようにしましょう。Warningが放置されっぱなしの状態は避けたいものです。
期待結果、テストケース、想定障害率
計画書には、テストケースの総数と、想定される障害率が数値で置かれることがあります。これは「バグが出ること」を前提に計画が組まれていることを意味します。
この点は後述しますが、受け入れテストの思想を理解するうえで重要な手がかりです。
終了基準
いつテストが終わったと見なすのか。ここも明記されます。
典型的な終了基準は「全テストケースが実施されていること」「検出された障害がすべて報告されていること」です。障害がゼロであることは、終了基準に含まれません。
環境と体制
- どの環境に対して実施するか（本番／ステージング）
- 実施時間帯と、可用性への影響の許容範囲
- 障害を検出したときの連絡経路と、判定の担当者
- 再テストの範囲と回数
特に環境については、本番と同一構成でなければ意味のない結果になるという原則があります。CDNの有無、WAFの有無、PHPのバージョン、キャッシュ設定。どれか一つ違うだけで結果が変わります。したがって、テストの際には本番環境相当の準備ができている、つまり、完成している必要があります。
もっとも、本番環境同等でテストを通ったからといって、開発を担当する場合はそれだけでは不十分だと考えるべきです。負荷対策でいえば、CDNの強力なキャッシュの下でのみ動作しているけれども、キャッシュなしだとランダムアクセス同時接続10件で落ちてしまうのでは困ります。テストの基準にないからやらない、という手抜きはしないように注意しましょう。
障害ゼロは終了基準ではない
ここが本稿で最も重要な点です。
テストは合意で終わるように設計されています
機能テストの終了基準は、前述のとおり「全ケース実施」「全障害報告」です。障害ゼロではありません。想定障害率という数値が置かれることからも、バグが出ることは前提だと分かります。
セキュリティ診断も同じです。診断結果の管理票には通常「対応の有無」という列があり、その隣に「対応概要（対応しない場合はその理由も記載）」という列が置かれます。さらに「再テスト判定」の欄で、未対応とした理由に対して判定が下されます。
つまり、未対応という選択肢が様式に最初から組み込まれているのです。
実際、ある案件では6件の指摘のうち2件を未対応のまま検収を通しています。
- 開発情報（ソースパス＝scssファイルへの参照）が残っていた件は「記載されているのは公開して問題のない情報であり、除去すると開発効率が低下する」という理由で未対応
- 「一般の閲覧者には発生しない事象」が問題と指摘されたが、本サイトでは一般の閲覧者がログインして利用することはないので未対応
診断側は、いずれの理由に対しても「OK」と判定しています。第三者テストの価値は、問題を見つけてもらうことよりも、判断を記録に残せることにあります。 「うちは問題ないと判断しました」という自己申告では、監査部門にも取引先にも通りません。第三者の判定が付いて初めて、対外的に説明できる文書になります。
「指摘ゼロ」を求めているのは誰か
では、なぜ「脆弱性診断で指摘ゼロであること」といった条件が要求仕様に現れるのか。それは検証会社ではなく要求仕様を書いた側が望んだからです。書いた本人は誠実に対応しているつもりです。しかしその転記によって、本人が望んでいない代償が仕様として確定します。これについては後述します。
差し戻される仕組みがあることも、価値です
未対応とした説明が、常に通るわけではありません。前述の案件では、「一般の閲覧者には発生しない」という説明に対して、申告した取り扱い情報の一覧と照らして本当にそう言えるのか確認が必要という差し戻しを受けています。理由を書けば通るのではなく、事実として正しい理由を書くから通るのです。
指摘が返ってきたら：4つの分類
報告書を受け取ったあと、最初にやるべきはトリアージです。指摘は次の4種類のいずれかに分類できます。
- 真の不具合：仕様と実装が食い違っている、または脆弱性がある
- 仕様・設計上の意図：そう作られている。WordPressの設計に由来するものもここに入ります
- テスト条件・環境に起因するもの：本番では発生しない、あるいはテストの実施条件が生んだ事象
- リスクを認識したうえで受容するもの：直せるが、コストや副作用を考えて当面は受容する
1については議論の余地なく直すべきでしょう。また、このレベルの不具合はテストに臨む前に潰しておきたいものです。基本的に第三者テストは数十万円〜数百万という高額なサービスです。デバッガーのように使うのはやめましょう。
2については「管理者が管理画面からscriptタグを入稿できてしまう」という類です。管理者は最高権限を持っており、危険な作業を管理画面から行うことができると発注者が納得しているのであれば、特に対応は不要でしょう。
3は「記事画面に編集リンクが表示されている」という指摘です。これはログイン状態で診断が実施されたために発生した事象で、一般の閲覧者には起きません。これも理由を説明することで対応は不要です。
4については「会員制サイトで会員限定のPDFがURL直叩きで見えてしまう」という指摘があったとします。これは「アクセス制御の不備」であり、対応は可能ではありますが、実際にPDFのURLが流出した場合しか問題とならず、また、その場合もURLを差し替えれば対応できます。また、そもそもPDFとして配布している時点でユーザーはそれをSNSなどで共有できてしまうので、対応する必要性は薄い、と考えることができます。ただし、受容とは「起きない」と判断することではなく、「起きても対処できる」と判断することです。検知の方法と、起きたときに誰が何をするかが決まっていないなら、それは受容ではなく放置になります。
いずれにせよ、これらの対応は次のフローをとります。
- 検証会社が問題を指摘する
- 開発会社が対応する、あるいは対応しなくてよい理由を説明する
- 発注者が同意する
- 項目が「完了」となる
WordPressで「満たせるが代償がある」要求
もう少し具体的な内容をWordPressの例で解説します。
それは不具合ではありません？
WordPressは、ユーザー名を機密情報として扱いません。ブログツールとして生まれ、「誰が書いたか」を示すことを前提に設計されているからです。これはコアチームが明確に言明しており、対応予定はありません。
しかし、診断でREST APIやアーカイブページからユーザー名が取得できる点が指摘として挙がったとします。するとWordPressに詳しい開発者は、こう答えたくなります。
「それは仕様です。ユーザー名は機密情報ではありません。」
技術的には正しい説明です。しかし、こう返されたらどうでしょうか。
「でも、ユーザー名が秘匿されていたほうが、パスワードだけで守るより突破される可能性は数学的に低いでしょう？」
これも正しいのです。 認証の突破にはユーザー名とパスワードの両方が必要です。ユーザー名が既知なら、攻撃者が探索すべき空間は狭くなります。つまり、両方の主張が正しく、議論は決着しません。ここで論争を続けても、検収は前に進みません。
そのうえ、要求の背景がセキュリティですらないこともあります。エンタープライズの現場では「記事を書いた人と入稿する人が別」というケースが珍しくなく、編集方針としてライター名を出したくないという要求が出てきます。これはセキュリティリスクの話ではありませんが、必要な技術的対応は同じです。
対応のための技術力
ここで必要となるのは対応するための技術力です。秘匿したいのであれば、秘匿できるようにします。 実際に、著者情報の露出経路をまとめて塞ぐHide Author Archiveというプラグインをタロスカイでは開発・メンテナンスしています。要求が来るたびに個別対応するのではなく、再利用可能な実装として持っておく。それが専門事業者の仕事だと考えています。
もちろん、代償も提示します。「記事の作者＝投稿者」で運用しているにもかかわらず、著者アーカイブを隠したい場合、著者アーカイブが持っていた検索流入は失われます。著者の専門性でコンテンツの信頼性を担保していたサイトでは、その訴求手段がなくなります。これも説明した上で対応すべきです。技術的な正しさを主張して要求を突き返すのではなく、要求は満たせるものとして実装を示し、トレードオフを明示して、判断を事業者に返す。
そして判断は発注側の仕事です。検索流入と秘匿性のどちらを重視するかは、技術ではなく事業の問題だからです。
要求仕様は手段ではなく目的で書く
要求を手段で書くと、副作用がついて回ります。目的で書けば事業者側が最適な実装を選ぶ余地が残ります。
| ✕ 手段で書いた要求 | ○ 目的で書いた要求 |
|---|---|
| 第三者テストで指摘がゼロであること | 全ての指摘に対して対応方針（是正・代替策・受容）を記載し、協議のうえ合意すること |
| ユーザー名を外部から特定できないようにすること | ユーザー名が既知であっても認証が突破されない設計であること |
| 管理画面のURLを推測困難なものに変更すること | 管理画面への到達をネットワーク層で制限すること |
| REST APIを無効化すること | 未認証で取得可能な情報の範囲を定義し、それを超える情報が露出しないこと |
| WordPressのバージョン情報を非表示にすること | サポート対象かつパッチ適用済みのバージョンを使用し、更新プロセスが文書化されていること |
| 常に最新バージョンを使用すること | セキュリティ修正の適用について、検証手順と適用期限が定められていること |
| Content-Security-Policyを設定すること | クロスサイトスクリプティングに対する多層的な緩和策を実装すること |
左側は、一見すると具体的で厳しい、よい要求に見えます。しかし実際には、発注側が意図していない運用制約を自ら課しているのです。
右側にはもう一つ利点があります。事業者の技術力が見えるようになることです。「ユーザー名が既知でも突破されない設計」を求めたとき、返ってくる提案の質で、相手がWordPressを理解しているかが判別できます。手段で指定すると、言われたとおり実装するだけなので、この判別ができません。
責任分界を契約に書く
もう一点、要求仕様と同時に決めるべきことがあります。
WordPressサイトの構成要素は、責任の所在が分かれています。
| レイヤー | 一次的な責任 |
|---|---|
| インフラ（OS・ミドルウェア） | ホスティング／インフラ事業者 |
| WordPressコア | 更新の適用は運用保守事業者 |
| 配布プラグイン・テーマ | 更新の適用は運用保守事業者、修正は作者 |
| カスタム実装 | 制作・開発事業者 |
| 運用（アカウント管理、権限、公開審査） | 事業者（発注側） |
受け入れテストの場面では、この問題が先鋭化します。検収前なので、対応コストは基本的に受注側が負います。しかし指摘の中には、インフラ事業者の領域のもの、WordPressの仕様に起因するもの、発注側の運用ルールに属するものが混在しています。「管理者権限のユーザーが多すぎる」という指摘を、制作会社が直すことはできません。
検収条件を「全指摘の是正」と書くと、受注側が構造的に達成不能な条件を負うことになります。だからこそ、対応方針を協議して合意する形にしておく必要があるのです。
まとめ：チェックリスト
第三者によるテストは、「誰が責任を取るのか」という問いに文書で答えるための仕組みです。報告書は答えではなく、判断とその記録のための材料です。
計画段階
- 実施するテストの種類を、目的に照らして選んだか
- 計画書の「対象外」を確認し、その領域を誰が担保するか決めたか
- 確認レベルの定義（どこまで見るか）を把握したか
- 終了基準を確認したか（障害ゼロが基準になっていないか）
- 本番／ステージングのどちらで実施するか、環境の同一性を確認したか
- セキュリティ診断では、認証済み診断の有無と権限を決めたか
- レイヤーごとの是正責任を契約に明記したか
報告を受け取ったあと
- 指摘を4分類（真の不具合／仕様・設計／テスト条件・環境／受容）に整理したか
- リスクレベルをそのまま使わず、環境を考慮して評価したか
- 「満たす方法」と「その代償」の両方が提示されているか
- 受容の判断が、システムオーナー（発注者）によって承認されているか
- 未対応とした理由が、事実として正しいか確認したか
- 再テストのスコープと期限を合意したか
次回以降のテストに向けて
- 報告書の指摘を、そのまま要求仕様に転記していないか
- 要求を手段ではなく目的で記述したか
- 要求を満たすことで失うものを把握したうえで決定したか
「このWebサイトは本当に大丈夫なのか」、そして「誰が責任を取るのか」。この問いに答えるのは、報告書そのものではありません。報告書を読み解き、リスクとコストを比較して判断し、その判断を記録に残せる体制です。
WordPressは、適切に設計・運用すればエンタープライズの要求水準を満たせるCMSです。そのために必要なのは、指摘をゼロにする技術ではなく、指摘の意味を説明し、選択肢と代償を提示できる技術です。
