システム導入の資料レビューの進め方｜誰が何を確かめるかを決める
『この資料を確認してください』と頼まれたけれど、何を見ればよいのか分からない。会議で説明を聞いても、自分の会社の仕事に合っているか、誰に質問すればよいかが曖昧なままになっていませんか。
この記事では、システム導入を進める社内担当者に向けて、資料の確認を依頼する準備と、指摘した後の確かめ方を説明します。資料などを、目的に合っているか関係者が確かめることを『レビュー』と呼びます。読み終えたら、一つの資料について『何を・どんな例で・誰が確かめるか』を、確認依頼に添えられるようになります。
この記事で整理できること
- 資料を確認する目的を、業務で判断したいこととして一文にできる。
- 通常の依頼・情報が足りない依頼・担当者が不在の場面を、確認する例として用意できる。
- 作る人・使う人・条件を決める人と、指摘後の再確認を計画できる。
製作会社『工房野』の社内受付を、説明のための架空例として使います。依頼する図面や数量、受付の状態をどう記録するかをまとめた資料を確認します。実在する会社の資料や、実施済みの確認結果ではありません。
この資料で、誰がどんな判断をできるかを決める
工房野では、『相談の段階か、社内の正式依頼として次へ進める段階かを、受付担当が区別できるか』を確認します。例えば、図面がないまま届いた相談を、そのまま正式依頼として扱わないために、資料でどんな条件を示すかを考えます。
ここで確認するのは、仕事の条件をまとめた資料です。このような『仕組みにどんな働きを求めるか』を書く資料を、要求資料と呼ぶことがあります。この記事では『受付の条件をまとめた資料』と考えて読み進めてください。
確認する対象が資料なら、文章や例から、受付の判断を説明できるかを確かめます。まだ作っていない画面の操作や処理の速さは、この資料を読むだけでは確認できません。それぞれ、何を使って、誰が確かめるかを別に決めます。
| そろえること | 工房野の例 |
|---|---|
| 対象 | 受付の条件をまとめた資料。どの版を見るかは依頼時に明記する |
| 確かめたい問い | 図面や数量の情報から、相談か正式依頼へ進める状態かを区別できるか |
| 使う人 | 社内の受付担当者 |
| 今回、この資料だけでは確かめないこと | 画面の操作、処理の速さ、実際に利用できるかの動作確認 |
『資料の確認をお願いします』の後に、答えてほしい業務の問いを一文足します。
資料の版と、通常・情報不足・担当不在の三つの例をそろえる
工房野では、図面と数量がある依頼、図面が指定されていない相談、判断する担当者が不在の時を用意します。三つは、この架空の受付業務で考える例です。どの業務も三つで足りる、という意味ではありません。自社で起きやすい迷いを追加してください。
資料には、例と関係する箇所を示します。確認する人が、図面の有無をどこへ記録し、受付の状態をどこで見分けるかをたどれるようにします。ファイル名だけでなく、更新日や版の名前も添え、違う版を見ながら話すことを防ぎます。
始める前に、資料を読む人が必要な内容を開けるか、業務の条件を判断する人へ確認できるかを確かめます。まだ資料がそろわない場合は、何が未完成かを示して、案への意見を集める範囲を決めます。未確認の閲覧権限や不足資料は、そのまま確認事項として残します。
| 業務の場面 | 用意する例 | 資料を読んで答えてほしいこと |
|---|---|---|
| 通常の依頼 | 確認用の図面と、数量3個が書かれた依頼 | 受付担当が、次に確認する内容と渡す相手を説明できるか |
| 情報が足りない | 図面が指定されていない相談 | 正式依頼へ進めず、必要な図面を確認する扱いが分かるか |
| 担当者が不在 | 業務の判断をする人がその場にいない | 代わりに確認する相手と、判断がつくまで進めない範囲が分かるか |
いま確認する資料へ、普段の例と、担当者が迷いそうな例を一つずつ添えます。
資料を作る人・使う人・条件を決める人へ問いを分ける
資料を作る人は、書いた条件と業務の例が、資料のどの箇所に対応するかを説明します。受付で使う人は、その説明を読んで次の仕事を選べるかを確かめます。業務責任者は、正式依頼へ進める条件や、担当者不在時の判断範囲を確認します。
一人が複数の役割を担うこともあります。その場合も、『資料を説明する立場』『受付で使う立場』『業務の条件を決める立場』を分けて問いを残します。別の受付担当者に例を渡して、説明を受けなくても迷わず読めるかを確かめる機会も設けましょう。
必要な担当者が参加できない時は、その分野の確認先と回答をもらう予定を残します。セキュリティなど専門の条件が含まれる場合も、分かる人へ確認する項目にします。会議で反対が出なかったことだけで、欠席者の担当範囲まで確認済みにしないようにします。
| 役割 | 頼むこと | まだ決まっていなければ |
|---|---|---|
| 資料を作る人 | 資料の版、条件、業務例との対応を説明する | 資料の担当者と、不足している箇所を確認する |
| 受付で使う人 | 各例で次の作業と確認先を選べるか確かめる | 実際に受付をする人へ、確認できる日を相談する |
| 業務の条件を決める人 | 正式依頼へ進む条件や、不在時の判断範囲を決める | 判断する相手と、回答を確認する予定を残す |
確認依頼に、参加する役割と、その役割へ聞きたい問いを並べます。
指摘する箇所・期待する扱い・直す人を一件にそろえる
図面がない相談の例を読むと、資料上では正式依頼のように見えるとします。『表現を修正してください』だけでは、どこをどう直すかが伝わりません。『図面未指定の例が正式依頼に見える。期待する扱いは、相談として必要な図面を確認すること』と書きます。
指摘には、資料の版と箇所、使った例、困る理由、対応する人を添えます。確認したい質問なのか、条件と食い違っていて直す必要がある指摘なのかも区別します。質問への回答が得られたことと、資料の不足が直ったことを混ぜないためです。
資料担当から修正の連絡が来たら、確認する人が修正版で同じ例を読み直します。必要に応じて、別の情報不足の例でも判断できるかを確かめます。何を追加で試すかは、修正した内容と影響を見て決めます。修正報告だけの段階では、再確認する予定が残っていると記録します。
| 項目 | 書く内容の例 |
|---|---|
| 資料と箇所 | 受付の条件をまとめた資料の、図面未指定の扱い。版と該当箇所は依頼時に記入する |
| 使った例と迷う点 | 図面がない相談なのに、正式依頼のように見える |
| 期待する扱い | 相談として残し、必要な図面を確認することが分かる |
| 対応する人 | 資料担当へ相談する。引受けと予定は未確認 |
| 再確認する人と条件 | 受付担当が修正版で同じ例を読み、次の作業を説明できるか確かめる。結果はまだない |
指摘を一件選び、資料の箇所、期待する扱い、再確認する人を書き足します。
確認結果と残った指摘をまとめ、次へ進めるかの判断につなげる
開始前に、何がそろえば今回の確認を終えられるかを相談します。工房野の例なら、用意した場面で受付の判断を説明できるかを確かめ、指摘、対応する人、再確認の予定、残る業務上の判断を記録することが目安です。判断できない内容が残った時の扱いも決めておきます。
終了時には、対象の版、確認した例、実際に分かったこと、残った指摘、判断した人と理由を残します。『指摘への対応予定が決まった』状態は、その指摘が直り、再確認も済んだ状態とは違います。修正後の確認が残るなら、次の仕事として追います。
資料の確認を行った後、その内容で次の作業へ進めるかは、業務責任者など所定の判断者へ確認します。社内の資料レビューを行っただけで、契約上の承認や検収が済んだと扱うものではありません。必要な手続は、自社で定めた担当へ確認してください。
NASAの技術評価の資料でも、レビューの目的、開始・成功の条件、確認するチーム、指摘への対応、判断理由の記録が整理されています。本稿ではその考え方を参考にしています。NASAの制度を、読者の会社へ一律に当てはめるものではありません。
| 記録すること | 書き方の例 |
|---|---|
| 確認した範囲 | どの版の、どの箇所を、どの業務例で見たか |
| 結果と判断理由 | 何が説明でき、何に迷ったか。誰がどの理由で判断したか |
| 残っていること | 未確認の分野、未修正の指摘、修正後に確かめる予定 |
| 次の担当と行動 | 誰が何を直し、誰がいつ確かめるか。次工程への判断を誰へ求めるか |
議事録や確認メモに、『確認した範囲』と『残っていること』の欄を用意します。
まとめ：次の確認依頼に、目的・業務の例・見る人を添えよう
資料レビューは、目的と対象を決め、業務の例と確認する役割をそろえて始めます。指摘が出たら、箇所・期待する扱い・担当・修正後の確認を一件につなげます。最後に、確認した範囲と残ったことを分け、次に誰が何をするかを残しましょう。
まず、次に誰かへ確認を頼む資料を一つ選んでください。その依頼に『この資料で判断できるようにしたいこと』『一緒に見てほしい業務の例』『役割ごとの問い』を添えます。分からない条件は、確認先を決める項目として書けます。
資料を受け取った人が、何から見ればよいか分かる。作った人が、どこを直せばよいか分かる。そこまで具体的にできれば、確認を一人の記憶や気配りだけに頼らずに進めやすくなります。下のメモで、次の一件を相談できる形にしてみましょう。
一つの資料についてメモを作り、実際に使う人と確認の目的を相談します。
資料の確認依頼を8項目で整理する
確認を依頼する資料を一つ選び、目的・業務例・役割と再確認を整理します。計画として書く内容と、実際に確認した結果を区別してください。
これは資料の確認を依頼する前の計画メモです。参加者の引受け・修正・再確認・承認が済んだ記録ではありません。
入力した内容は外部へ送信しません。このページを再読み込みすると消えるため、必要なメモは保存してください。個人情報や機密は記入しないでください。
空欄の用紙と、書き方を確認できる架空例
CSVは、項目名が8列・記入内容が1行の形式です。架空例は完成した実績ではありません。自社で確認した内容へ書き換えて使います。
資料レビューでよくある疑問
まだ完成していない資料でもレビューできますか？
案への意見を集めることはできます。未完成の箇所と、今回どこまでを確認するかを明示してください。資料の不足や未決定の条件を、会議を行ったことだけで確認済みにしないようにします。
詳しい人を全員集める必要がありますか？
確認する目的に必要な役割を決めます。全員が同時に集まれなくても、誰にどの問いを確認し、いつ回答をもらうかを計画できます。参加しない分野の条件は、未確認として残します。
指摘が残っていても確認の会議を終えてよいですか？
会議を終える時は、残った指摘、対応する人、再確認する人と予定を記録します。会議が終わったことと、指摘が解消したことは分けます。次の仕事へ進めるかは、残る影響も添えて所定の判断者へ確認します。
用語の質問も、修正する指摘と同じように扱いますか？
一緒に記録しても、質問への回答が必要なのか、資料を直す必要があるのかを分けます。何が分かれば終わるかが違うためです。質問への回答から修正が必要と分かった場合は、対象箇所と期待する状態も残します。
出典と、このガイドの前提
原稿・一次情報の確認日：2026年10月12日。図の人物・職場・資料は生成した架空の説明例です。確認の完了や導入の効果を示す実績ではありません。
- NASA Systems Engineering Handbook：6.7 Technical Assessment
6.7.1.2.2〜3と6.7.1.3。レビューの目的、開始・成功の条件、確認するチーム、指摘への対応、結果や判断理由を残す考え方。
NASAの技術評価向け資料です。本稿の会社・資料・業務例・8項目のメモは読者向けに作った架空の教材であり、NASAの公式様式や、日本企業に課す制度・契約上の検収の規則ではありません。
- 日科技連：レビューオリエンテーションキットを用いた育成によるレビュー文化の醸成（2011年度研究報告）
付録1には、事前にすることや、対象・役割ごとの確認の観点を知りたいという回答があります。準備を具体的に説明する本稿の主題を考える際に参照しました。
当時の研究報告であり、現在の検索需要や製作会社全体の実態を示す調査ではありません。工房野の受付例とメモは、本稿で作成した教材です。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。
