ドキュメント不足でもテストは実施できる｜PMの対処法

「テスト仕様書が途中までしか書かれていない」「設計書は初期のものしか残っていない」——受託開発のPMであれば、こうした状態でリリースが迫ってくる場面に、一度は直面したことがあるのではないでしょうか。資料が完全にそろっていないと、テストをどこから手をつければよいのか分からず、品質にも不安が残ります。しかし結論から言えば、ドキュメント不足の状態でもテストは実施できます。この記事では、その原因と品質への影響を整理したうえで、資料が欠けたままでもテストを前に進めるための現実的な方法を、PMが明日から使える形でまとめます。

なぜ開発現場でドキュメント不足は起きるのか

まず押さえておきたいのは、ドキュメントの欠落は「担当者の怠慢」ではなく、開発現場に構造的に組み込まれた問題だということです。原因を正しく理解しておくと、責める発想から「どう補うか」という発想に切り替えられます。

最初は整備されていたのに更新が止まる負のスパイラル

多くの現場では、プロジェクト初期はきちんと仕様書や設計書を作っています。問題はその後です。実装が進むにつれて仕様が変わり、ドキュメントの更新が一度後回しになると、「現物とズレた資料」を直す作業が重くなり、さらに更新が止まるという悪循環に入ります。

一度ズレた資料は、放置するほど直すコストが上がり、ますます更新されなくなります。この負のスパイラルは、意志の弱さではなく、更新コストが雪だるま式に増える構造そのものが生み出しています。

更新を止める3つの引き金

資料の更新が止まる背景には、典型的な引き金があります。代表的なのは次の3つです。

引き金	何が起きるか	資料への影響
納期プレッシャー	「動くものが先、資料は後」で進む	実装が先行し記述が追いつかない
度重なる仕様変更	変更のたびに全資料を直せない	記述と実装の不一致が蓄積する
属人化	担当者の頭の中だけに仕様が残る	暗黙知が形式知にならない

これらは単独ではなく、絡み合って進行します。納期に追われて更新を飛ばし、そこに仕様変更が重なり、結果として仕様が個人の記憶に依存していく——という流れです。

「後で直す」が積み重なる構造

「落ち着いたらまとめて直そう」という判断は、その時点では合理的に見えます。しかし落ち着いたタイミングは訪れず、次の案件が始まります。こうして未整備の資料が積み残され、気づけばテスト工程に入る頃には、頼れる資料がほとんどない状態になっているのです。

しかも厄介なことに、資料が更新されていないという事実は、テスト工程に入るまで表面化しにくいという特徴があります。開発中は担当者の記憶で補えてしまうため、問題が見えないのです。そして担当者の異動や退職が重なると、記憶という最後の頼みの綱まで失われ、誰も正解を知らない機能だけが残ります。

• 更新の先送りは、その場では時間を生むが後工程に負債を移すだけ
• 負債は「テストの根拠が分からない」という形で顕在化する
• つまり資料の欠落は、開発プロセスの副産物として自然に発生する

大切なのは、この状態を異常事態と捉えて立ちすくむのではなく、「よくあること」として受け止め、次の一手に進むことです。

資料の欠落がテストと品質に与える影響

資料が欠けたままテスト工程に入ると、具体的にどんな不利益が生じるのでしょうか。影響を可視化しておくと、対策の優先順位をつけやすくなります。

テスト設計の根拠が失われる

テスト設計は本来、仕様という「あるべき姿」と実装を突き合わせて、確認すべき観点を洗い出す作業です。仕様書や設計書が欠けていると、この「あるべき姿」が曖昧になり、何をもって正解とするかの基準が持てません。結果として、テスト担当者は「動いたからOK」という表面的な確認に流れやすくなります。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、要求こそがテストの根本的な問題の源だと指摘されています。要求仕様が満たすべき特性として「完全である」「曖昧さがない」「テスト可能である」などが挙げられており、資料が欠けている状態は、この「テスト可能な要求」が最初から欠けている状態に等しいのです。

抜け漏れと手戻りが増える

確認基準が曖昧なままテストを進めると、次のような問題が連鎖します。

• 観点の抜け漏れ: 確認すべき条件やパターンが洗い出されず、本番で不具合が発覚する
• 手戻りの増加: 「これは仕様通りか、バグか」の判断がつかず、都度開発者に確認して待ち時間が生まれる
• 再テストの膨張: 仕様の解釈違いによる差し戻しで、同じ画面を何度もテストし直す

これらはいずれも工数を押し上げ、ただでさえ厳しい納期をさらに圧迫します。資料不足は、単に「作業しにくい」だけでなく、品質と工数の双方に跳ね返るのです。

外部にテストを頼みづらくなる「情報格差」

資料が不十分だと、社外のテスト会社に依頼しづらいと感じるPMは少なくありません。実際、内製の開発と違い、外部の担当者には開発の経緯や裏仕様、設計思想が自然には伝わりません。

あるBtoBアプリのテスト代行案件の振り返りでは、チームメンバーがこう語っています。「テスト開始時の理解不足が原因で、本来1回の操作で済む確認作業に、余計な時間を費やしてしまった」。アプリの全体像を掴めていないと無駄な操作が増え、時間がかかる——これは多くの現場で共有されている課題です。

資料の欠落がそのまま「情報格差」となり、外部担当者のテスト精度を下げてしまう。ただし後述するように、この情報格差は依頼の設計しだいで埋められます。「資料がないから頼めない」は、必ずしも正しくありません。

ドキュメント不足でもテストは実施できる

ここからが本題です。資料が完全でなくても、テストは十分に実施できます。むしろソフトウェアテストの世界には、不完全な情報を前提とした技法が体系的に用意されています。

「完全な仕様書がないとテストできない」は思い込み

「仕様書が全部そろってから、それに沿ってテストケースを作る」——このやり方はスクリプトテストと呼ばれ、確かに有効です。しかし、それが唯一の正解ではありません。現実の開発では、要件は不完全で変化し続けます。完璧な資料を待っていたら、テストはいつまでも始められないのです。

リー・コープランド『はじめて学ぶソフトウェアのテスト技法』では、要件が不完全で変化し続ける現実の中でテストを順番通りに進めることを、「20の扉」ゲームで質問を全部事前に用意するようなものだと表現しています。前の答えを活用できない、非効率なやり方だというわけです。

探索的テスト——学習しながらテストする

資料が薄い状況で強力なのが、探索的テストです。これはテスト設計とテスト実行を同時並行で進める、規律あるアプローチです。同書では、探索的テストを提唱者ジェームズ・バックの言葉で「テスト設計とテスト実行の同時並行的な学習行為」と定義しています。

• 製品を実際に触りながら、次に確認すべき観点をその場で設計する
• 前のテストで得た発見を、次のテストの手がかりにする
• 仕様書がなくても、動くアプリそのものを情報源にできる

注意したいのは、探索的テストは「場当たり的テスト」とは違うという点です。場当たり的テストがスキル不要のデタラメな操作であるのに対し、探索的テストは担当者の観察力と仮説構築力を使う、スキルと経験を要する規律ある活動です。資料が欠けているからこそ、この「学習しながらテストする」姿勢が効いてきます。

具体例：仕様書がない画面をどうテストするか

たとえば、仕様書のない「見積書作成画面」をテストする場面を考えてみましょう。まず画面を開き、入力欄・ボタン・表示項目を一通り観察します。金額欄に数字を入れると合計が変わる——ここで「では税率はどう扱われるのか」という仮説が生まれます。実際に税抜・税込を切り替えて挙動を確かめ、その結果から「端数はどう丸められるのか」という次の観点へ進みます。

このように、一つの操作結果が次に確認すべき観点を教えてくれるのが探索的テストの核心です。仕様書という地図がなくても、アプリという現地を歩きながら地図を描いていくイメージです。得られた発見はその都度メモに残し、あとで見返せるようにしておきます。

• 入口: 画面を開いて要素を観察し、確認したい挙動を1つ選ぶ
• 仮説: 「こう動くはず」という予測を立てて操作する
• 発見: 予測との差分（＝バグまたは未知の仕様）を記録する
• 展開: その発見を手がかりに、次に確認すべき観点へ進む

適応型計画——分かった範囲から計画する

テスト計画についても、「最初に完璧な計画書を作る」必要はありません。同書が提唱する適応型計画は、分かったところまでを、分かったタイミングで計画するという考え方です。

軍事の世界には「いったん敵に遭遇すれば、計画書は用をなさない」というモルトケの格言があり、同書でも引用されています。計画は一度作って終わりではなく、新しい情報が得られるたびに見直すものだという発想です。優れた計画の原則は次のように整理できます。

原則	意味	テストへの応用
計画できるときに	時間とリソースがある範囲で	分かっている画面から着手する
計画できるところまで	持っている知識の範囲で	不明点は「未確認リスト」に残す
可能になる前には行わない	情報がない先を作り込まない	全体を精緻に埋めようとしない

「計画し、実行し、見直し、また計画を見直す」というサイクルを回せば、資料が不完全でもテストは着実に前進します。

実務に落とすと、こういうことです。最初から全機能の詳細なテスト計画を作ろうとせず、まず「情報がそろっている主要機能」から着手します。テストを進める中で新たに判明した仕様や、想定外の挙動は「未確認リスト」に書き足していきます。そして区切りのよいタイミングで、そのリストをもとに計画を更新する——このリズムなら、資料の空白を埋めながらテストを止めずに進められます。計画書が古びて使えなくなる、という事態も避けられます。

不完全なドキュメントから「テストの手がかり」を引き出す方法

技法の裏付けが分かったところで、実務の手を動かす話に移ります。資料が欠けていても、テストの手がかりはプロジェクトのあちこちに散らばっています。それを拾い集めるのがPMの役割です。

動くアプリ本体を一次情報にする

最も確実な情報源は、実際に動いているアプリそのものです。仕様書は古びますが、現物は「今の実装」を正確に語ります。画面遷移をたどり、入力と結果の関係を観察するだけで、確認すべき観点はかなり洗い出せます。

ただし注意点もあります。現物が語るのは「今どう動くか」であって、「本来どう動くべきか」ではありません。実装自体にバグが潜んでいる場合、現物を正解と信じてしまうと、その不具合を見逃します。そのため、動くアプリの観察は探索的テストの出発点として活用しつつ、業務ルールの正しさは別途ヒアリングや既存資料で裏づける——という二段構えが安全です。

既存資料・チケット・問い合わせ履歴を逆引きする

完成した仕様書がなくても、断片的な情報は意外と残っています。これらを逆引きすると、仕様の輪郭が見えてきます。

• 課題管理チケット: 過去の修正履歴から、仕様変更の経緯や注意点が読み取れる
• 問い合わせ・障害対応の履歴: 実際に問題が起きた箇所は、重点的に確認すべきリスク箇所
• 初期の設計書やメール: 古くても、設計意図や当初の想定を知る手がかりになる
• 画面キャプチャや議事録: 断片でも突き合わせれば仕様の再構成に役立つ

たとえば「割引が二重に適用される」という過去の障害チケットが1件見つかったとします。そこからは、「割引ロジックは壊れやすい」「クーポンと会員割引の併用は要注意」という重点観点が逆引きできます。1件のチケットが、仕様書の1章分に相当する情報を持っていることも珍しくありません。障害の履歴は、そのシステムが過去にどこでつまずいたかを教えてくれる、貴重なリスクマップなのです。

口頭・チャットの暗黙知を最小メモで形式知化

属人化した仕様は、担当者の頭の中にあります。ヒアリングした内容を、完璧な仕様書にしようとせず、箇条書きの最小メモで残すだけで十分です。目的は立派な資料を作ることではなく、テストの根拠を共有できる形にすることです。

限られた時間でヒアリングする際は、網羅を狙わず、テストで迷いそうな点に絞って聞くのがコツです。たとえば次のような問いかけが有効です。

• 「この画面で、絶対に間違えてはいけない処理はどれですか」
• 「過去にユーザーからクレームや問い合わせが多かった機能はありますか」
• 「仕様書には書いていないけれど、実は決まっているルールはありますか」

こうした質問は、リスクの高い箇所と暗黙のルールを効率よく引き出せます。聞いた内容はその場でメモに書き起こし、担当者に「この理解で合っていますか」と確認すれば、認識のズレも防げます。

テスト可能な形に要求を書き直す

集めた情報は、そのままではテストに使いにくいことがあります。前述の高橋寿一の書籍では、テスト可能な要求は「ステート（データ等）＋条件・アクション＋特定された結果」の3要素で書くと整理されています。

たとえば「顧客番号を入力する」だけでは曖昧ですが、「顧客番号（ステート）を入力する（アクション）と、8桁数値としてDBに保存される（結果）」と書き直せば、そのままテストの合否基準になります。曖昧な仕様は、この3要素に分解するだけでテスト可能な状態へと変わります。

なお、テストの根拠となる考え方をさらに体系的に知りたい場合は、JSTQB（日本ソフトウェアテスト技術者資格認定委員会）が公開しているJSTQBのシラバス・用語集が参考になります。

最低限そろえたい情報と「最小限のドキュメント」

資料をゼロから完璧に整える必要はありません。テストを回すために本当に必要な情報だけを、優先的にそろえるのが現実的です。

完璧な仕様書より優先すべき5つの情報

膨大な仕様書を作り直すより、次の5点を押さえるほうが、テストの精度に直結します。

1. システムの全体像: どんな機能が、どう連携しているかの俯瞰図
2. 主要な業務フロー: 利用者が実際に行う代表的な操作の流れ
3. 重要な業務ルール: 金額計算・権限・ステータス遷移など、間違うと影響が大きいルール
4. 過去の不具合と問い合わせ: 壊れやすい箇所＝重点的に見るべき箇所
5. 確認したい観点の優先順位: 何を優先して確認するかの合意

全体像と優先順位さえ共有できれば、テストは十分に設計できます。完璧さより、テストの土台になる情報を選ぶ視点が重要です。

テストドキュメントの最小構成

布施昌弘ら『ソフトウェアテストの教科書』では、テストドキュメントには全体計画書・設計仕様書・テストケース仕様書・不具合報告書など複数の種類があると整理されています。ただし、これらを最初から数千枚そろえる必要はありません。テストを回すうえで最小限そろえたいのは、次の2つです。

ドキュメント	最小限の中身	目的
テスト設計仕様書	確認する観点と合否基準の一覧	何を正解とするかを共有する
不具合報告書	再現手順・重要度・優先度	直すべき順番を判断する

この2つがあれば、テストの実施と結果の共有は成り立ちます。追跡性（要件→テスト→結果の紐付け）や記述の粒度は、運用しながら少しずつ高めていけば十分です。

テスト設計仕様書といっても、凝った様式は要りません。次のように「確認する観点・条件・期待結果」を1行ずつ並べた表があれば、立派に機能します。

確認する観点	条件	期待結果
合計金額の計算	税抜1,000円の商品を3点購入	税込3,300円と表示される
権限による制御	一般ユーザーで管理画面を開く	アクセスが拒否される
必須項目のチェック	氏名を空欄で登録	エラーメッセージが表示される

大切なのは、記述の美しさではなく「何をもって正解とするか」がチームで共有されていることです。この表があるだけで、テスト担当者は迷わず合否を判断でき、開発者との「これはバグか仕様か」というやり取りも激減します。

ドキュメントは一度に作らず、テストしながら育てる

資料は、テストの前に完成させるものではなく、テストしながら育てるものと捉え直しましょう。探索的テストで得た発見を最小メモに残し、それが次第にテスト設計仕様書へと育っていく——このやり方なら、資料整備とテストを同時に進められ、更新が止まる負のスパイラルにも陥りにくくなります。

なお、テスト工数や品質の見積もりを社内で議論する際は、IPA（情報処理推進機構）が公開するソフトウェア開発分析データ集のような客観的なデータも、上長への説明材料として活用できます。

資料不足のテストで陥りがちな失敗と回避策

資料が薄い状態でテストを進めるとき、いくつか典型的な落とし穴があります。あらかじめ知っておけば、多くは避けられます。

「動いたからOK」で確認を終えてしまう

最も多い失敗が、画面が正常に表示され、エラーが出なかったことをもって「問題なし」と判断してしまうことです。しかし本来確認すべきは、期待した結果になっているかです。合計金額が正しいか、権限のないユーザーが操作できないか——こうした業務ルールは、見た目が正常でも間違っていることがあります。確認基準を持たないまま進めると、表面的なテストで満足してしまいます。

全体像の把握を飛ばして個別テストに突入する

資料がないと不安から、とにかく目についた画面を片っ端からテストしたくなります。しかし全体像を掴まないまま個別のテストに入ると、機能同士のつながりを見落とし、無駄な操作も増えます。急いでいるときほど、最初に全体像を俯瞰する時間を惜しまないことが、結果的に近道になります。

発見をメモに残さず、頭の中だけで進める

探索的テストで得た発見を記録せずに進めると、同じ確認を繰り返したり、後から「なぜこの結果が正しいと判断したのか」を説明できなくなります。よくある失敗と回避策を整理すると、次のようになります。

陥りがちな失敗	何が問題か	回避策
「動いたからOK」で終える	期待結果との照合が抜ける	合否基準を1行でも先に決める
全体像を飛ばす	機能連携の抜け漏れ	最初に俯瞰する時間を確保する
発見を記録しない	再現・説明ができない	最小メモをその場で残す
すべてを均等にテスト	時間切れで重要箇所が薄くなる	リスクで優先順位をつける

資料不足そのものより、確認基準を持たずに進めることのほうが、品質にとって危険です。落とし穴を知っておけば、薄い資料でもテストの質は大きく変わります。

資料が不十分なままテスト代行を活用するには

社内のリソースだけでテストを回しきれないとき、外部のテスト代行を活用する選択肢があります。ここで多くのPMがつまずくのが、「資料が揃っていないから頼めない」という思い込みです。

「資料が揃ってから」ではなく現状のまま相談してよい

テスト代行の現場では、資料が途中までしかないケースはむしろ一般的です。資料が完璧になるのを待つ必要はなく、今ある状態のまま相談して問題ありません。整った仕様書がなくても、動くアプリと断片的な情報、そしてヒアリングの時間があれば、テストは設計できます。整備を待つほどリリースは遅れ、品質を確認する時間も削られてしまいます。テスト代行の基本的な流れや費用感を事前に把握しておきたい方は、ソフトウェアテスト代行の費用と進め方も参考にしてください。

情報格差を埋めるキックオフを設計する

外部に頼む場合の成否を分けるのは、資料の量ではなく、情報格差を埋める工夫です。前掲のテスト代行案件の振り返りでも、「特にテスト代行の場合は、アプリの全体像を知らずに作業を開始するとテストの精度が下がるため、全体像の理解に時間を費やすべき」という教訓が共有されていました。

• 全員で同じ画面を見る時間を作る: 各自が別々に触るより、一緒に操作しながら全体像の共通理解を作る
• 開発の経緯や裏仕様を口頭で補う: 資料にない設計思想こそ、キックオフで伝える価値が高い
• 重点的に見てほしい箇所を先に共有する: 過去の不具合箇所やリスクの高い機能を最初に伝える

「急がば回れ」で全体像の把握に最初に投資するほうが、トータルの作業時間は短くなります。丸投げではなく、情報を渡すフェーズを意図的に設けることが、外部活用を成功させる鍵です。

優先順位づけを一緒に行う

限られた時間の中では、すべてを均等にテストすることはできません。テスト項目を列挙するだけでなく、重要度・リスク・確認のしやすさで順位づけするところまでを、依頼側と一緒に決めておきましょう。優先順位が共有されていれば、資料が薄くても「まず何を守るか」がぶれません。依頼前に何を準備しておくべきか整理したい場合は、テスト代行を依頼する前の準備も参考になります。

順位づけの基準は、難しく考える必要はありません。「壊れたときの影響が大きい機能」「利用頻度の高い機能」「過去に不具合が出た機能」の3つに当てはまるものから優先的に見る、と決めるだけでも十分に機能します。逆に、めったに使われず、壊れても影響の小さい機能は、後回しにするか軽い確認にとどめる——この割り切りが、限られた時間で品質を最大化するコツです。

テスト体制の見直しや外部活用について具体的に検討されている方は、テストに関するノウハウ資料もあわせてご確認いただけます。

まとめ——資料不足を放置せず、テストを止めない

ドキュメント不足は、納期・仕様変更・属人化が絡み合って生まれる、開発現場の自然な副産物です。責めるべき対象ではなく、補うべき前提として受け止めるところから対策は始まります。この記事の要点を振り返ります。

• 資料の欠落は構造的に発生する。負のスパイラルを理解し、責める発想から補う発想へ切り替える
• 資料不足はテスト設計の根拠を奪い、抜け漏れ・手戻り・情報格差を生む
• 探索的テストと適応型計画を使えば、完全な仕様書がなくてもテストは実施できる
• 動くアプリ・チケット・問い合わせ履歴・暗黙知から、テストの手がかりは引き出せる
• 全体像と優先順位を共有し、最小限のドキュメントをテストしながら育てる
• 外部のテスト代行も、資料が揃う前の現状のまま相談してよい

完璧な資料を待つより、今ある情報でテストを止めないことが、品質と納期の両方を守ります。資料が足りないという理由で品質確認を後回しにすると、そのしわ寄せは必ず本番のトラブルとして返ってきます。

テスト体制の見直しや、資料が不十分な状態でのテストの進め方に不安がある方は、テスト体制についてお気軽にご相談ください。現状をうかがったうえで、今ある情報でどこまでテストを設計できるか、具体的にご提案します。