作業を始める前に、何が承認されるかを定義しましょう。

一般的な依頼を、使用状況に置き換えましょう

「ビジュアルを改善する」とは、ファイルを拡大すること、背景を削除すること、色を統一すること、あるいは別の雰囲気を作り出すことを意味する場合があります。これらの作業は同じようには評価できません。まず、出力がどこで使われるのか、その受け取り手が何をできる必要があるのかを尋ねることから始めましょう。ソフトウェアやGPUの名前はその次です。

人、結果、用途を結びつける一文を書きましょう。「ショップの責任者が、このコレクションの12枚の写真を自分の商品ページで差し替えられるようにする。」既知の制約を加え、まだ未解決の質問も記します。GOV.UKのサービス・マニュアルは、このユーザーニーズとその満足度を検証する基準との分離を提案しています。ここでは、それを小さなタスクに応用しています。

期待するパッケージを5行で説明する

始めるのに長い仕様書は必要ありません。適切な納品を認識するために必要なことを書き留め、制作前にこのシートを読み返してもらいましょう。受け取り手が必要な形式をまだ把握していない場合は、その人のツールで開ける小さなエクスポートを作成しましょう。そうすれば、不確実性は的確な確認作業に変わります。

以下の表は適宜調整して使う作業テンプレートであり、レンタルで提供される能力の一覧ではありません。個人のタスクの場合は、クライアント名を自分の確認に置き換えてください。それでも、出力が適切かどうかを決めるのは人です。

必須要件と好みを分けましょう

ブロッキングとなる要件とは、その出力が本来の用途に使えなくなるものです。たとえば、製品が違う、テキストが読めなくなった、ドキュメントが欠けている、開けない形式である、といったケースです。一方、優先的な好みは、すでに使える複数の出力の中から選ぶための基準になります。この違いは試作の前に伝えておいてください。そうでなければ、後から出た見た目の好みが、製作上の不具合と混同されてしまうことがあります。

「とてもきれい」「知的」「プロフェッショナル」のように、解釈によって変わる基準は避けましょう。それらを使う場合は、合格した例と観察できる事実に結びつけます。たとえば、欠けている部分がない輪郭、指定した参考色に一致した色、正しい箇所に基づいた回答、といった具合です。判断がどうしても主観的になる場合は、決める人を明記し、その人の参考例を残しておきます。

業務と無関係な制約を積み重ねないようにしましょう。やり方を選ぶための試作は、根拠のある提案とコメント付きの出力がいくつかあれば完了としてよいものです。それを、配信できる完成品として提示してはいけません。

例：小さなコレクション向けの12点のビジュアル

この架空の例では、フリーランスの女性がコレクションのビジュアルを差し替えるために12枚の画像を受け取ります。最初の依頼は「もっときれいな仕上がり」でした。やり取りを経て、範囲は次のようになります。1,600 × 1,600ピクセルのPNGを12枚、商品を白背景の中央に配置、ロゴや商品の細部は変更しない。この寸法はこの例での選択であり、EC全般に当てはまる普遍的なルールではありません。

最初のやり取りのために3点を選びます。明るい被写体、暗い被写体、テキスト入りのパッケージです。クライアントはバッチ処理の前に、これらのサンプルの構図と背景を承認します。テストした3枚は12枚の出力に含めることができますが、注文数に自動的に加算されるわけではありません。

各結果にステータスを、やり直しには理由を付けましょう

この例の最初のパスでは、9枚が承認、2枚が修正、1枚が読み取れないソースによってブロックされたと仮定します。合計は12枚のままです。「承認」「要修正」「ブロック」という状態を示す表があれば、残りの作業がすぐにわかります。フォルダに12個のファイルがあるだけでは、同じ結論には至りません。

修正後、2点のやり直しは承認されました。結果は承認済み11点、ブロックされた入力1点となります。したがって、期待された完全な納品は達成されていません。フリーランスの女性は、使える素材を求めるか、11点という範囲について明確に合意するよう依頼します。12点目の参照を一覧から消すのではなく、該当バージョンとともに判断を保持しておきます。

各フィードバックについて、ファイルの識別子、確認された不具合、期待する変更を求めてください。「image-007のテキストが崩れている。原本の記載を維持してほしい」と言えば、やり直しの方向を示すのに十分です。「これはダメ」では、依頼を一から組み立て直す必要があります。

検証をスケジュールに組み込み、その後で変更を処理しましょう

サンプルと納品をいつ確認できるかを決めておきましょう。検証に担当者の都合が必要なら、その待ち時間も体制に織り込んでおきます。予算ガイドでは、レンタルの準備、実際の作業、待機、やり直し、書き出しを区別しています。レンタルを保持したままの待機時間は、計算が一切動いていなくても枠を占有します。

新しい依頼が現れたら、実行する前にその影響を説明しましょう。12枚から20枚への増加、フォーマットの追加、別スタイルの依頼は、いずれも作業範囲を変えます。新しい数量、追加の確認事項、見直すべきスケジュールを記録してください。既知の不具合の修正と要件の拡張は、一つのリストに混ぜたままにしないようにしましょう。

また、何回のやり取りを予定するかも決めておきましょう。たとえば、サンプルのレビューを一度行い、その後、計画的な再作業を行うといった流れです。それでもなお却下される場合は、終わりのない試行を重ねる前に、方法と範囲について改めて話し合ってください。

このシートは作業上の判断を整理するものであり、あなたの案件固有の商取引上の合意に代わるものではありません。また、計算時間を導き出せるものでもありません。選定したソフトウェアとファイルで実現可能かを確認するには、最初の試行がどうしても必要です。

この枠組みで本当に判断できるかを確認する

会話の文脈を抜きにして、もう一度このシートを読み返してみてください。成果物として作成するファイルを挙げられますか。却下された出力を見分けられますか。承認する担当者を特定できますか。答えられない項目があれば、作業を広げる前にそこを補ってください。また、クライアントから提供された要素についても確認を取りましょう。ソースのバージョン、参照となるビジュアル、使用許諾です。

よくある誤りは、いきなりバッチ全体に着手すること、生成されたファイルをそのまま承認済みの成果として数えること、試行のたびに基準を変えてしまうことです。最初のシートを保管し、改訂を記録しておきましょう。どのサンプルも要件を満たさない場合、方法を見直すか、その方向性を打ち切るのが正しい判断となり得ます。有益な枠組みがあればこそ、そうした結論を下せます。