「確認お願いします」で何を頼む？ レビューを修正・育成・承認に分ける

原稿を送り、「確認お願いします」と添える。返ってきたコメントには、数字の間違い、見出しの別案、「ここを先に書いた理由は？」という問いが並んでいる。全部直せばよいのか。理由を答えればよいのか。そもそも、誰の返事をもって公開してよいのか。

これは、編集やデザインの仕事を想定した架空の場面だ。ただ、確認を頼む一言の中に、違う仕事が入っていることは見えてくる。今回の成果物を直すこと。次回は自分で判断できるようになること。そして、外へ出してよいかを決めること。同じコメント欄で進められても、終わり方は同じではない。

ここでは、その目的を「修正・育成・承認」に分けて考える。Googleが公開するコードレビューの指針と、GitHubのレビュー機能を手がかりにした、CONTEXT編集部からの提案である。制作現場全般に効果が実証された分類ではない。まず、いま頼んでいる確認の目的を言葉にするために使いたい。

修正では、直す箇所と理由を渡す

事実の誤り、読み手が取り違える表現、依頼時の要件から外れた構成。今回の成果物を出す前に解消したい問題が、修正の中心になる。「もっとわかりやすく」だけでは、どこをどう判断するかが受け手へ丸ごと残る。

たとえば記事の確認なら、「2段落目の前年比が、出典の表と一致しません。対象年度と計算を確認してください」と書ける。問題の場所、確認できる根拠、してほしいことが一続きになる。修正案まで示すか、書き手に考えてもらうかは、締め切りと相手の経験に応じて決めればよい。

Googleの指針は、レビュー対象のコードについて話し、開発者本人への批判にしないこと、指摘の理由を説明することを勧めている。また、問題だけを示すか具体的に導くかのバランスにも触れる。対象はソフトウェア開発だが、「あなたは説明が下手だ」から「この一文では対象がわからない」へ言い換える手がかりになる。Googleのコメント指針

もっとも、具体的なら必ずよい指摘になるわけでもない。文章を丸ごと書き換えて渡せば、早く完成に近づける場合はある。その一方で、書き手には「なぜそうするのか」が残らないこともある。今回の修正を急ぐことと、次回の判断力を育てることは、別に時間を取ってもよい。

育成の問いを、公開の条件に混ぜない

育成で確かめたいのは、相手が次に似た場面へ出会ったとき、何を手がかりに選べるかだ。完成形だけを覚えてもらうのではなく、対象読者、情報の順序、別案を捨てた理由など、判断の過程を一緒に扱う。

先ほどの原稿なら、「なぜこの数字を冒頭に置いたのか」「別の数字を選ぶなら何か」と聞くことができる。ただし、公開直前に問いを増やせば、相手は答えが合うまで提出できない試験だと受け取るかもしれない。理由を聞きたいだけなら、今回の公開を止める問いなのか、後日の振り返りなのかも添えたい。

Googleのレビュー基準は、学びにつながるコメントを歓迎しつつ、必要な基準を満たすために不可欠でない助言には、今回の変更で対応が必須ではないことを示すよう求めている。「教える価値がある」と「今直さなければ進めない」を分けている点が参考になる。Googleのレビュー基準

制作の現場に移すなら、「このまま公開できます。次回のために、冒頭の選び方だけ後で振り返りたいです」と伝えられる。反対に、読み手を誤解させる数字が残っているなら、先に修正が必要だ。学びを理由に誤りを残すのでも、すべての学びを公開前へ押し込むのでもない。

振り返りでは、足りなかった点だけでなく、うまくいった判断も取り上げたい。たとえば「専門用語の前に読者の場面を置いたので、何の話か入りやすかった」と理由まで返す。抽象的な「よかったです」より、次も使える選択として残せるのではないか。

承認では、誰が何を確かめたかを残す

承認は、意見をたくさん集める作業とは異なる。「この版を、合意した条件のもとで出してよい」と判断する仕事である。文章として読めること、事実が確認できていること、企業として発信できることは、それぞれ確かめる人が違う場合もある。

GitHubの公式説明では、レビュー結果をComment、Approve、Request changesから選べる。一般的な意見、変更の承認、対応を求める指摘を、別の状態として示す仕組みだ。これは本稿の「修正・育成・承認」と一対一に対応する分類ではないが、コメントがあることと承認されたことを分ける例になる。GitHubのレビュー結果の説明

編集の仕事でも、「確認済み」だけでは何を確認したのかわからない。担当者が製品名と数値を見たのか、広報が会社の見解を見たのか、編集者が文章を読んだのか。確認対象と版を残し、誰が最後に公開を判断するかを決めておきたい。

たとえば「9月23日版。製品名と仕様の確認は完了。写真の掲載許諾は未確認なので、公開は保留」と書く。未確認の項目が見えると、次に誰へ何を渡すべきかがはっきりする。承認は、全員が何も言わなくなった瞬間を待つことではない。

なお、GitHubでも変更要求が必ず自動的に取り込みを止めるわけではなく、保護ルールなどの設定に依存する。ボタンやラベルだけで責任が決まると考えず、実際の運用を合わせておく必要がある。GitHubの送信手順と注意点

同じコメント欄でも、次の行動は分けられる

3つの目的を整理すると、確認を受ける人に頼みたい行動が変わる。次の表は、公式資料の分類の転載ではなく、編集・制作向けに本稿で組み立てた例である。

運用を始めるために、会議を3つへ増やす必要はない。コメントの先頭へ「公開前に必須」「提案」「次回のために」を添えるだけでも、扱いを話しやすくなる。これは絶対的な優先順位ではなく、今回どう扱ってほしいかを伝える印である。

もし必須の修正が大量に出るなら、書き手の力量だけを見る前に、最初に渡した条件を振り返りたい。読者像や企画の目的が後から変わったのなら、それは初稿への指摘だけでは処理しきれない。追加の仕事として、時間や締め切りも相談する必要がある。

制作の月額契約を考えた記事でも扱ったように、相談やレビューは、納品物の本数だけでは見えにくい仕事だ。確認回数を決めるだけでなく、何を判断する回なのかを共有することが、引き受ける範囲を考える材料になる。

最初の依頼文に、終わり方まで書く

「確認お願いします」を、次のように書き換えてみる。「今回は事実誤認と読者が迷う箇所を、木曜の午前中までに見てください。構成の別案は提案として分けてもらえると助かります。公開判断は私がまとめ、書き方の振り返りは公開後に相談します」。これも架空の依頼例であり、期限や担当は現場に合わせて変える。

受け手から確認してもよい。「このコメントは、公開前の必須修正でしょうか」「理由の説明でよいのか、別案まで必要でしょうか」。聞き返すことを、指摘への反抗だと決めつけない。依頼の意味が揃っていなければ、直しても終わりは近づかない。

もちろん、目的を明示しただけで信頼の問題まで解けるわけではない。正しい指摘と伝える人への信頼を分けて考えた記事のように、過去の振る舞いや、判断の一貫性が問われることもある。ラベルを付けた指摘も、理由を説明し、相手の事情を聞く必要がある。

レビューを終えるときに確かめたいのは、コメントを全部消したかだけではない。今回直すべきことは直ったか。次に考える問いは残せたか。そして、誰が何を確認し、進めてよいと判断したのか。その違いが見えるだけでも、「確認お願いします」の返事は変えられる。