技術記事

横断的なテスト設計を考慮したプロジェクト設計について

はじめに この記事は、プロジェクトの立ち上がりからサービスインまでの作業や考慮すべきポイントなどを、
テスト設計を念頭においた全体的な流れとしてまとめたものです。 背景 実装として参加したプロジェクトで必要な情報が不足していると思うことが多かった さまざまな案件で必ずといっていいほど遭遇していると思いますが、何故この段階でこの整理がされていないのだろうと思うことがよくあります。 このような事がなぜ起きるのかはともかく、仕様漏れや手戻りが起きにくくなるようテスト設計を念頭に置き、
各フェーズで漏れを洗い出せる確率の高いプロジェクトの流れを整理します。 全体的な流れと各フェーズの成果物 0. 発端・課題の整理・定義 ここをしっかりしないと「作ってはみたものの誰も使わない」みたいな話になります。 目的と位置づけ 発案 (例: 社内要望 / 顧客要望 / 競合対抗 / 売上施策 / 業務改善) なぜ作るのか、何を解決するのかを明確にする(言語化) 主な作業 課題・背景整理 価値仮説立案 ※KPI(成果指標) 仮置き ※スコープ上限・下限定義 (何をどこからどこまでやるか) 成果物 企画メモ / 1枚企画書 課題仮説リスト KPI 草案 スコープ定義書 1. 企画・要件定義 (前半) 目的と位置づけ 「何を作るか」の大まかな外形とリリースにまつわる制約を整理する 主な作業 機能要件定義 非機能要件定義 ユースケース整理 対応 OS / 端末条件整理 ※(その他)法務・セキュリティ・ストア審査観点確認 成果物 要件定義書(ドラフト) ユースケース一覧 非機能要件一覧 2. 情報アーキテクチャ設計（InformationArchitecture設計） よくIAと略されます。これが曖昧なままだと、DBのテーブル定義には存在するけど、どこから入ってくる情報なのかよく分からないみたいな事態になります。
（過去の案件では画面デザインに入力UIがなく、終盤になって発覚し慌てて実装を追加しました。） 目的と位置づけ 要件を「構造」に落とし込んでいく工程 このあとの要件定義（後半）と UX / UI 設計（前半）の橋渡し 主な作業 情報・機能の洗い出し 用語・概念整理 グルーピング・階層化 ナビゲーション構造設計 情報の入出力整理(データフロー整理) 成果物 概念マップ 用語定義表 コンテンツ / 機能一覧 サイトマップ / 機能マップ ナビゲーション構造図 3. 企画・要件定義（後半） ＋ テスト観点洗い出し（前倒し） 目的と位置づけ 要件を「確認可能な仕様」として確定させる 主な作業 IA を踏まえた要件確定 正常系 / 異常系 / 境界値洗い出し 完了条件（受入基準）定義 非機能テスト観点整理 おまけ：次のMinimumViableProduct 判断条件整理 成果物 要件定義書（確定版） テスト観点一覧（高レベル） 受入基準（双方の認識合わせを行って書面化しておくほうが間違いが起きづらい） 4. MVP(Minimum Viable Product)設計・リリース戦略 ＋ 検証範囲定義 この部分については、発注側であれば最低限これだけあればリリースできるという線引になります。
(MVPにいくつか機能を追加したものを発注し時間が足りなくなった時などに、どの機能を次回リリースに回すかといった判断がしやすくなります。) 目的と位置づけ 初回リリースで成立する価値を決める 主な作業 MVP スコープ切り出し フェーズ分割（MVP / 拡張） リリース方式設計（β / 段階公開） MVP 必須テスト範囲定義 KPI 達成 / 未達時の判断基準設定 成果物 MVP 定義書 リリースロードマップ 段階公開計画 MVP テスト範囲定義 5. 体制・作業フロー設計 目的と位置づけ 開発・テストを回す仕組みを作る 主な作業 役割・責務定義 開発プロセス選定 チケット運用などタスク管理の方法の設計 レビュー・完了基準策定 成果物 体制図 プロセス定義 チケットテンプレート 6. UX/UI設計 ＋ 画面・状態テスト設計 目的と位置づけ IA を画面と操作に落とし込む 主な作業 画面遷移設計 状態遷移設計 ワイヤーフレーム作成 デザイン作成 画面単位のテスト観点定義 表示条件 入力制限 エラー表示 OS 差分整理（iOS / Android） 成果物 画面遷移図 通常遷移 エラー時の表示・遷移先など 状態遷移図 ワイヤーフレーム デザインデータ（Figma 等） 画面別テスト観点表 7. 技術設計 ＋ テスト前提設計 目的と位置づけ 保守性・テスト容易性を担保する 主な作業 アーキテクチャ設計 データ / API 設計 認証・セキュリティ設計 Mock 前提の責務分離 エラー分類・ログ設計 テストレベル設計（単体 / 結合 / UI） 成果物 技術設計書 アーキテクチャ図 API 仕様書 エラーコード定義 8. 基盤設計・構築 ＋ テスト環境整備 目的と位置づけ 安定した開発・検証環境を用意する 主な作業 環境分離（dev / stg / prod） CI / CD 構築 ※自動ビルド環境は出来ればあった方がよい 証明書・署名設定 (ものによっては無いと作業が止まります) テストアカウント / テストデータ準備 自動テスト実行基盤構築 ※自動テストを導入する場合 成果物 環境設定資料 テストアカウント一覧 CI / CD 設定 (もしくはビルド・テストリリース手順) 自動テスト実行環境 ※自動テストを導入する場合 9. 実装 ＋ 単体テスト並走 目的と位置づけ 設計通りに安全に実装する 主な作業 機能実装 UseCase / Repository 単体テスト実装 Mock を用いた異常系検証 コードレビュー 成果物 実装コード 単体テストコード レビュー記録 ※ここで単体テストが実行できる状態なら 生成AIを用いた作業もやりやすくなります。 10. テスト実行 (結合・統合) 目的と位置づけ 全体として期待通りに動くか確認する 主な作業 単体テスト実行 結合テスト（API / 認証 / 課金） UI テスト（重要導線） 端末・OS バージョン検証 非機能テスト（性能 / 安定性） 成果物 テスト結果報告書 不具合一覧 改修履歴 11. リリース前最終確認 目的と位置づけ 可能な限り安全にサービスインする事 主な作業 ストア提出情報確認 審査観点最終チェック 監視・アラート確認 障害対応手順確認 成果物 ストア提出物一式 運用・障害対応手順書 リリース判定資料 12. サービスイン（リリース） 主な作業 段階公開 初期監視 不具合即応 成果物 公開済アプリ 初期運用レポート(主にサーバ側) 13. サービスイン後 (受託においては担当外) 目的と位置づけ 期待通りの効果が出ているか測定する 継続的に価値を高める 主な作業 KPI 分析 改善施策立案 テスト観点更新 技術負債解消 成果物 分析レポート 改善バックログ 更新済テスト設計 まとめ お客さまとやり取りするしながら受託プロジェクトを進めていく場合には、実装までに必要な情報が揃っているかをチェックし、
揃っていない場合は実装開始までに必要なものが揃うよう交渉していきましょう。 必要な情報がないまま実装したとしても、結局、仕様確認や調整に無駄なコストがかかったり、後戻りする羽目になります。 基本的に、情報アーキテクチャ設計とUX/UI設計が曖昧になっていると、
実装のタイミングで仕様確認や調整に時間をかけてカバーすることになります。 あとから実装を追加したり変更すると、不要な処理になったりいびつな処理になることが多く、このような部分が負債となって積み上がっていきます。
そのような状況を避け、後戻りの少ないプロジェクトにするためにも事前にテストを想定した進め方を心がけるようにしましょう。