テスト業務の属人化を4層で解く現実的な対処法

「あの人がいないとテストが回らない」——テスト業務の属人化という時限爆弾

「このアプリのテストは、結局◯◯さんに聞かないと分からない」——受託開発の現場で、こんな言葉が当たり前になっていないでしょうか。特定の担当者だけが仕様の裏側を把握し、その人の頭の中にだけテストの勘所が詰まっている。日々の開発が回っているうちは、それが問題として表面化することはありません。

しかし、その担当者が別案件にかかりきりになったり、体調を崩したり、あるいは退職したりした瞬間に、テストは静かに止まります。テスト業務の属人化とは、そういう「普段は見えないが、抜けた瞬間に致命傷になる」時限爆弾です。

専任のQA担当を置けず、エンジニアがテストを兼任している少人数のチームでは、この構造はほとんど宿命のように生まれます。リリース直前でスケジュールが詰まっているとき、一番テストに詳しい人に作業が集中するのは、短期的には合理的だからです。ですが、その合理性の積み重ねが、いつの間にか「あの人がいないと何も判断できない」状態を作り上げます。

この記事でお伝えしたいのは、この属人化は「人を増やせば解決する」問題ではなく、「層に分けて剥がしていく」問題だという視点です。採用も外注も、すぐに動かせるとは限りません。だからこそ、いま手元にある人と時間の中で、何から手を付ければいいのかを整理する必要があります。

以下では、属人化を「知識・手順・判断・関係」の4つの層に切り分け、剥がしやすいものから順に、予算をかけずに着手する道筋を示します。

こんな兆候が出ていたら要注意

まずはセルフチェックです。次の項目に思い当たるものが複数あれば、属人化はすでに進行しています。

• 特定の担当者が休むと、その案件のテストが実質止まる
• テストの合否判断を「◯◯さんならOKと言うか」で決めている
• 過去に出たバグの再発防止策が、個人の記憶にしか残っていない
• 顧客の細かい要望や「地雷」を知っているのが一人だけ
• テスト仕様書はあるが、実際のテストは書かれていない観点で動いている
• 引き継ぎのたびに「口頭で全部説明する」しかない

これらは単なる作業の偏りではなく、チームの品質が個人に依存しているサインです。

なぜ「気合」と「採用」では解決しないのか

属人化の話をすると、「頑張ってドキュメントを整備しよう」「テスト専任を採用しよう」という結論に飛びがちです。しかし、少人数の受託開発チームでは、そのどちらもすぐには現実解になりません。

気合でドキュメントを整備しようとしても、日々の納期に追われる中では続きません。完璧なテスト仕様書を目指した瞬間に、着手のハードルが上がって放置されるのが典型です。採用にしても、専任QAを雇う予算とマネジメント工数を確保できるチームは限られます。

つまり、人・金・ツールを大きく増やせないという制約を直視したうえで、いまある資源で剥がせる部分から手を付けるのが、現実的な出発点になります。次章から、その「剥がし方」を具体化していきます。

テスト業務の属人化が招く3つの実害

属人化を放置すると、実害は3つの方向で表面化します。ここを具体的に見ておくことで、「なんとなくまずい」という感覚を、手を打つべき対象へと変換できます。

品質のばらつき（同じ機能でも人でテスト範囲が変わる）

属人化した現場では、同じ機能をテストしても、担当する人によって見る範囲が変わります。ある人は境界値や異常系まで丁寧に確認し、別の人は正常系をなぞって終わる。この差は、テストの観点が個人の経験の中にしか存在しないために生まれます。

結果として、「誰がテストしたか」で品質が決まってしまい、チームとして一定の品質を保証できません。顧客から見れば、同じチームなのにリリースごとに品質が揺れる不安定なパートナーに映ります。

たとえば、ある改修で入力フォームに手を入れたとき、いつもの担当者なら文字数の上限や全角・半角の混在まで確認するのに、別の人が対応した回はそこが抜けてリリース後に不具合が出た——といったことが起こります。原因はスキルの優劣ではなく、確認すべき観点がその人の頭の中にしかなく、共有されていなかったことにあります。裏を返せば、観点さえ外に出しておけば、担当が変わっても同じ品質を再現できる余地があるということです。

担当者が抜けた瞬間に止まる再現性のなさ（退職・長期離脱）

属人化の最も分かりやすいリスクは、再現性のなさです。テストの手順も判断基準も個人の頭の中にあるため、その人が退職・長期離脱すると、同じテストを再現できません。

• 何をどこまでテストすればよいのか分からない
• なぜその確認をしていたのか、背景が誰にも説明できない
• 引き継ぎに膨大な時間がかかり、その間リリースが滞る

一人の離脱でスケジュール全体が寸断される。これは少人数チームほど深刻に効いてきます。

しかも、こうした離脱の多くは予告なく訪れます。「辞めるかもしれない」と分かってから引き継ぎ資料を作り始めても、間に合わないことがほとんどです。だからこそ、平時のうちに少しずつ頭の中を外に出しておくことが、唯一の現実的な備えになります。備えのない属人化は、担当者の状態にチームの命運を預けているのと同じです。

顧客対応まで担当者に紐づく怖さ

さらに厄介なのは、テストの属人化が顧客対応の属人化と地続きになっている点です。「この顧客はこういう使い方をする」「前にこの画面でクレームがあった」といった情報が、テスト担当者個人の記憶に紐づいていることがよくあります。

こうなると、担当者が抜けたとき、失われるのはテスト手順だけではありません。顧客との信頼関係を支えてきた文脈ごと消えてしまうのです。この「関係の層」の剥がしにくさについては、後半で改めて扱います。

品質・スケジュール・顧客信頼——この3つは独立していません。暗黙知への依存が品質のばらつきを生み、それがバグの流出につながり、最終的に顧客信頼を損なうという連鎖で結びついています。IPAが過去に公開していた「ソフトウェア開発分析データ集」でも、品質に関わるデータが開発現場の意思決定の材料として整理されてきました（IPA ソフトウェア開発分析データ集。現在は事業終了で更新は止まっていますが、品質を定量的に捉える発想の裏付けとして参考になります）。だからこそ、属人化は感覚で語らず、どの層で起きているかを切り分けて手を打つ必要があります。

テスト業務の属人化を4層に切り分ける——診断フレーム

ここからが本記事の核心です。この属人化を、ひとまとめの「悪いもの」として捉えると、対策も「全部ドキュメント化しよう」という漠然としたものになりがちです。そうではなく、属人化を4つの層に分解して診断します。

4つの層とは、①知識の層、②手順の層、③判断の層、④関係の層です。この順番には意味があり、①から④に向かうほど剥がしにくくなり、少人数チームは剥がしやすい①②から着手するのが現実的です。

各層が何を指し、どんな症状として現れるのかを整理します。

知識層——「その情報、頭の中にしかない」

知識層は、仕様の背景・過去のバグ・顧客固有の癖といった「情報」が個人に閉じている状態です。症状は「聞かないと分からない」。ドキュメント化すれば移転できるため、4層のなかで最も剥がしやすい層です。

手順層——「テストのやり方が明文化されていない」

手順層は、何をどうテストするかという「進め方」が共有されていない状態です。境界値分析や同値分割といった、明文化できるテスト観点がここに含まれます。これらは技法として言語化できるため、リスト化すればチームに移せます。

判断層——「どこまでやれば十分かの基準が個人の勘」

判断層は、「このテストで十分か」「これはリリースしていいか」という合否や優先度の判断が、個人の経験則に依存している状態です。症状は「◯◯さんの感覚頼み」。基準を言語化しにくいぶん、知識・手順層より剥がしにくくなります。

関係層——「顧客や経緯との信頼がその人に紐づく」

関係層は、顧客との信頼関係やプロジェクトの経緯といった、人と人との文脈が個人に紐づいている状態です。最も剥がしにくく、単純なドキュメント化では移せません。

4つの層を、剥がしにくさと着手の目安で並べると次のようになります。

層	属人化しているもの	主な症状	剥がしにくさ	着手の目安
①知識層	仕様の背景・過去バグ・顧客の癖	「あの人に聞かないと分からない」	低	予算ゼロ・明日から
②手順層	テストの進め方・確認する観点	「やり方が人によって違う」	低〜中	予算ゼロ・今週から
③判断層	合否基準・優先度の付け方	「どこまでやれば十分か曖昧」	中〜高	合意形成が必要
④関係層	顧客との信頼・案件の経緯	「あの人しか顧客対応できない」	高	仕組み化＋外部視点

この表を使えば、自分のチームの属人化が「どの層で、どれくらい深刻か」を診断できます。まずは各層について「該当する症状があるか」をチームでチェックしてみてください。診断の目的は、全部を一気に直すことではなく、着手する順番を決めることです。

もう一歩具体にするなら、各層に「0〜3点」で深刻度を付けてみるのも有効です。0はドキュメントや仕組みで共有できている状態、3は完全に一人に依存している状態を指します。点数が高い層ほど、その担当者が抜けたときの打撃が大きいと考えてください。合計点を競う必要はありません。狙いは、どの層の点数が突出しているかを見て、最初に手を付ける場所を1つに絞ることです。多くの少人数チームでは、①知識層と②手順層に高い点が付きます。だからこそ、次章ではその2つから着手します。

知識の層と手順の層——予算ゼロで明日から始める棚卸し

診断で層が見えたら、剥がしやすい①知識層と②手順層から着手します。この2つは、ツール導入や標準化サービスを前提とせず、いまいるメンバーの時間だけで進められるのが最大の利点です。

大事なのは、完璧を目指さず「明日・今週・今月」の粒度で小さく始めることです。

知識層の一手——頭の中を聞かれる前に書き出す

知識層は、担当者の頭の中にある情報を外に出すだけで剥がれ始めます。ポイントは、網羅ではなく「聞かれて困る順」に書き出すことです。

• 明日できること: いま担当している機能について、1画面分の仕様メモを書く。UIの意図や、なぜその挙動なのかを数行添える
• 今週できること: 過去に出したバグのうち、再発するとまずいものを3〜5件、再発防止メモとして残す
• 今月できること: 顧客固有の癖や「地雷」——過去にクレームになった箇所、特に厳しくチェックされる画面——をリスト化する

この段階では体裁を気にする必要はありません。箇条書きのメモで十分です。大切なのは、担当者が抜けたときに「せめてこれだけは残っている」状態を作ることです。

手順層の一手——テスト観点の棚卸しと簡易リスト化

手順層では、テストの観点を棚卸しします。ここで移転できるのは、境界値分析・同値分割といった、明文化できる技法に基づく観点です。これらは「この入力欄なら、下限・上限・その前後・空欄を確認する」というように、ルールとして書き下せます。

テスト観点を言語化するとき、用語や観点の共通言語として公的なシラバスが役立ちます。JSTQB（ソフトウェアテスト技術者資格）のシラバスは、テスト設計技法や観点を体系的に整理しており、チーム内の用語をそろえる拠り所になります（JSTQB 認定テスト技術者資格 シラバス）。ゼロから独自の言葉を作るより、公的な枠組みに乗せたほうが、後から入るメンバーにも伝わりやすくなります。

棚卸しの進め方は、次のように段階を分けます。

タイミング	知識層でやること	手順層でやること
明日	担当機能の仕様メモを1画面分	よくテストする画面の確認観点を箇条書き
今週	再発防止バグメモを3〜5件	境界値・異常系など明文化できる観点をリスト化
今月	顧客固有の癖リストを作成	テスト観点リストをチームで一度レビュー

やってはいけない——いきなり完璧なテスト仕様書を目指さない

ここで最も陥りやすい罠が、最初から完璧なテスト仕様書を作ろうとすることです。網羅的なドキュメントを目指すと、作成に時間がかかりすぎて日々の業務に埋もれ、結局更新されずに形骸化します。

続かない標準化は、やらないより悪いこともあります。まずは「メモレベルでも残っている」状態を優先し、運用しながら育てる発想に切り替えてください。

続けるコツは、棚卸しを「イベント」ではなく「習慣」にすることです。まとまった工数を確保しようとすると、いつまでも着手できません。たとえばリリースのたびに15分だけ、今回触った画面の観点と、出たバグの再発防止メモを書き足す時間を取る。既存の作業の締めに数分ぶら下げるだけなら、忙しい時期でも続きます。小さく積み上がったメモは、半年後には立派な引き継ぎ資料になっています。

なお、知識層の棚卸しはテストに限らず、チーム全体のナレッジ共有の一部として位置づけると定着しやすくなります。ナレッジ共有の仕組みづくりそのものについては、ナレッジ共有で開発チームの生産性を高める考え方もあわせて参考にしてください。

判断の層——「どこまでやれば十分か」を個人の勘から合意へ

①②を進めても、まだ属人化が残ります。それが③判断層です。「このテストで十分か」「これはリリースしていいか」という判断は、知識や手順よりも言語化が難しく、個人の勘に依存しがちです。ここが、品質のばらつきの本丸です。

品質のばらつきの正体は「判断基準の不在」

同じ機能でも人によってテスト範囲が変わるのは、多くの場合「どこまでやれば十分か」の基準がチームで共有されていないからです。基準がないため、各人が自分の経験に照らして「これくらいでいいだろう」と判断し、その結果がばらつきます。

つまり、品質のばらつきは能力差というより、判断基準が言語化されていないことの表れです。基準を個人の頭の外に出すことが、この層への処方箋になります。

リスクベースで優先度を合意する

判断層を剥がす第一歩は、「全部を均等にテストしようとしない」と決めることです。限られた時間で品質を守るには、どこに厚くテストを当てるかをチームで合意しておく必要があります。

優先度づけの目安は次の通りです。

• 重要機能: 壊れると業務や売上に直結する中核機能
• 変更箇所: 今回の改修で手を入れた箇所と、その影響範囲
• 過去バグ多発箇所: 何度も不具合が出ている、いわば「弱い」モジュール

この3つに厚く配分し、それ以外は軽めにする——という方針をチームで共有しておくだけで、誰がテストしても優先順位が揃うようになります。欠陥を管理し、どこにバグが偏っているかを可視化する仕組みがあると、この優先度づけの精度が上がります。具体的な進め方は欠陥管理プロセスの基本的な組み立て方が参考になります。

「終わらせ方」をチームの言葉にする

もう一つ、判断層で言語化すべきは「テストの終わらせ方」です。多くの現場で、テストの終了は「◯◯さんがもういいと言ったら終わり」になっています。

ここで注意したいのは、「テストを終えてよいかの目安」と「出荷してよいかの経営判断」は別物だという点です。前者は、あらかじめ決めた観点をすべて消化したか、重大な不具合が残っていないか、といったチーム内の目安です。後者には、納期や顧客との関係、ビジネス上のリスク許容度といった、より広い要因が絡みます。

この2つを混同すると、「まだテストが不十分なのに出荷を迫られる」場面で、判断の拠り所を失います。まずはチーム内の終了の目安を、簡単な言葉でよいので共有しておくことをおすすめします。たとえば「決めた観点を消化し、重要度の高い不具合が残っていない状態」を目安とする、といった具合です。

終了の目安は、次のような形でチームの共通言語にしておくと、担当者が違っても判断がぶれにくくなります。

• 事前に決めた重要度の高い観点を、すべて消化したか
• 未解決の不具合のうち、重大なものが残っていないか
• 残っている不具合について、対応するか見送るかの判断を記録したか

ポイントは、これを一人の頭の中の感覚ではなく、チームの誰もが確認できる形に残すことです。基準そのものは各チームの実情に合わせて調整して構いません。大切なのは「基準がある」という事実が、担当者への依存を薄めてくれることです。

関係の層と自力の限界——外部の目が効くケース

最後に残るのが、最も剥がしにくい④関係層です。そしてこの層に触れると、「すべてを自力・自チームだけで剥がすのは難しい」という現実にも向き合うことになります。

関係層はなぜ剥がしにくいか

関係層が剥がしにくいのは、それが「情報」ではなく「文脈」だからです。顧客との信頼、これまでの経緯、言外のニュアンス——これらは仕様メモのように書き出しても、そのまま移りません。

それでも、仕組みで少しずつ移すことはできます。

• 顧客とのやり取りの経緯を、議事録や共有台帳として一箇所に残す
• 「なぜこの仕様になったか」の決定経緯を記録に紐づける
• 顧客対応を一人に固定せず、意図的に複数人が同席する場を作る

完全には移せなくても、文脈を「その人だけのもの」から「チームで参照できるもの」へ近づけることはできます。

明文化しきれない領域——探索的テストのスキル依存

もう一つ直視すべきは、テストには明文化しきれない領域があるという事実です。手順層で棚卸しできる境界値分析や同値分割は、ルールとして書き下せます。しかし、製品を触りながら「なんとなくここが怪しい」と気づき、その場で次の一手を組み立てていく探索的テストは、性質が違います。

Copeland『ソフトウェアテストの技法』では、探索的テストを「テスト設計とテスト実行の同時並行的な学習行為」と定義し、それが場当たり的なテストとは違って、スキルと経験を要する規律ある活動だと述べています。つまり、観点として棚卸しできる技法と、経験に依存する探索的テストは別物であり、すべてを明文化しようとすると必ずどこかで折れます。

だからこそ、目標は「全部を標準化する」ことではありません。棚卸しできる部分は棚卸しし、経験依存の部分は「そういう領域がある」と認めたうえで、その経験をどう補うかを考える——という現実的な線引きが必要です。

判断・関係層で外部の目が効く場面

③判断層と④関係層は、身内だけで剥がそうとすると、どうしても基準が甘くなりがちです。同じチームで長く見ていると、「これはいつものことだから」と見逃す観点が生まれ、判断が内輪の常識に閉じてしまいます。

こうした場面で有効なのが、第三者の視点です。外部のテスト担当者にレビューを依頼すると、内輪では当たり前になっていた前提を問い直してもらえます。

場面	身内だけの課題	外部の目が効く理由
判断基準の妥当性	内輪の常識で基準が甘くなる	客観的な観点で抜けを指摘してもらえる
経験依存の探索	スキルが特定個人に偏る	経験豊富な第三者が補完できる
顧客視点の確認	作り手の思い込みが残る	ユーザーに近い視点で検証できる

外部活用というと大がかりに聞こえますが、いきなり全面委託を考える必要はありません。まずは③④の一部について第三者レビューを入れる、といった小さな一歩から検討できます。リソース不足を外部の力で補う考え方については、外部テストでリソース不足の品質課題を解決する視点も参考になります。

なお、探索的テストのように人に依存する領域を補う手段として、テスト自動化を挙げる声もあります。ただし自動化は、明文化された手順を繰り返す部分には効きますが、経験と勘を要する探索そのものを肩代わりするものではありません。属人化対策の文脈では、自動化は万能の解ではなく、あくまで最後に検討する選択肢の一つと位置づけるのが妥当です。

まとめ：テスト業務の属人化は「順番に剥がす」もの

ここまで、属人化を4つの層に分けて見てきました。最後に、持ち帰っていただきたい判断軸を整理します。

• ①知識層・②手順層: 予算ゼロで、自力で剥がせる。明日・今週・今月の粒度で小さく始める
• ③判断層: 合意形成が中心。リスクベースの優先度と「終わらせ方」をチームの言葉にする
• ④関係層: 最も剥がしにくい。仕組み化で文脈を共有しつつ、外部の目が有効になる領域

大切なのは、属人化は一気に解消するものではなく、剥がしやすい層から順番に剥がしていくものだという視点です。全部を一度に直そうとすると挫折しますが、順番を決めれば、いまの人員と予算のままでも今日から動けます。

今日決める「最初の一手」チェックリスト

明日からの一歩として、次のうち1つを選んで着手してみてください。

• いま担当している機能の仕様メモを、1画面分だけ書き出す（知識層）
• よくテストする画面の確認観点を、箇条書きでリスト化する（手順層）
• 「重要機能・変更箇所・過去バグ多発箇所」に厚く配分する方針をチームで共有する（判断層）
• 顧客とのやり取りの経緯を残す共有台帳を用意する（関係層）

まずは1つで構いません。小さく始めることが、続く仕組みへの一番の近道です。

自力の限界を感じたら——外部の目という選択肢

①②は自力で進められますが、③判断層・④関係層は身内だけでは基準が甘くなりがちです。長く同じチームで見ているほど、内輪の常識に判断が引っ張られてしまうからです。

テスト体制に第三者の視点を入れて見直したい方は、まず現状の属人化診断からご相談ください。どの層が、どれくらい深刻なのかを整理するところから、無理のない改善の一歩を一緒に描けます。

テスト体制の属人化について相談する