クリエイティブチームのワークフローにおける5つのステージ（そして、それぞれが崩壊する原因）

すべてのクリエイティブなプロジェクトは、ブリーフ（要件定義）、構築、レビュー、納品、アーカイブという同じライフサイクルをたどります。そして、それぞれの段階には、予測可能で、予防可能であり、どのような規模のチームであっても驚くほど共通している「失敗パターン」が存在します。

クリエイティブチームは、その作業の進め方において驚くほど共通しており、その作業が破綻する場所においても驚くほど共通しています。ロンドンの代理店も、ロサンゼルスの制作スタジオも、ベルリンの社内ブランドチームも、大体同じ5つのステージからなるライフサイクルをたどっており、そして皆が同じような場所で時間をロスしています。

ステージそのものはよく理解されています。ブリーフと計画、構築と制作、レビューと承認、納品、そしてアーカイブと再利用です。あまり理解されていないのは、これらのステージの間の摩擦、引き継ぎ、文脈の喪失、散乱したフィードバックが、その中での実際の作業そのものよりも多くの時間を費やしているということです。統合されたワークフローとは、すべてをこなせる1つのツールを見つけることではありません。プロジェクトがステージからステージへと移行する際、文脈（コンテキスト）をそのまま維持することであり、それによってチームが前フェーズで何が起こったかを再構築するのではなく、クリエイティブな作業に時間を費やせるようにすることです。

1. ブリーフと計画

何が起きるか： プロジェクトが始まります。目標が定義され、クリエイティブな方向性が確立され、参考資料が収集され、タイムラインが設定され、チームは何をなぜ作るのかについて認識を合わせます。

どこで破綻するか： ブリーフはドキュメントとして存在しています。参考資料は、3人のブラウザにまたがるリンクやスクリーンショットとして存在しています。ブランドガイドラインは、誰かの受信トレイにあるPDFです。ムードボードは、チームの半分がまだ見ていないPinterestのボードです。キックオフミーティングで話し合われたクリエイティブの方向性は、出席した人々の記憶の中にだけ存在し、他のどこにもありません。

チームが構築を開始する頃には、計画資料は散逸してしまっています。デザイナーはプロデューサーにブランドガイドラインを求めます。エディターは参考動画がどこにあるか尋ねます。プロジェクトマネージャーは、予算が口頭で合意されただけで、一度も文書化されていないことに気づきます。計画フェーズでは多くの資料が作成されましたが、ワークフローにおいてそれらを見失ってしまったのです。

どうやって維持するか： すべてを1つのプロジェクトの場所に一元化します。理想的には、ファイル名やフォルダではなく、意味（セマンティック）で検索できる場所が良いでしょう。ブリーフ、参考資料、ムードボード、ブランドアセット、スケジュール、ミーティングノートは、1回の検索で見つけられるようにすべきです。Fabric（セマンティック検索とムードボード用のキャンバスを備えたプロジェクトスペース）、Notion（柔軟なプロジェクトページ）、または適切に構成された共有ドライブなどがすべてこの機能を果たします。キックオフミーティングは録音・文字起こし（Fabric、Granola、Otterなどを使用）し、口頭で議論されたクリエイティブな方向性が、消えゆく記憶ではなく検索可能なテキストになるようにします。

2. 制作と構築

何が起きるか： クリエイティブな作業が行われます。デザイナーがデザインし、エディターが編集し、ライターが執筆し、デベロッパーが構築します。コンテンツが制作されます。

どこで破綻するか： 制作フェーズでは、2種類のアウトプットが生成されます。クリエイティブアセット（映像、デザイン、コピー、コード）と、それらを取り巻く知識（なぜこの方向性が選ばれたのか、クライアントがカラーパレットについて何と言ったか、監督が現場で何を決定したか、なぜワイヤーフレームからレイアウトが変更されたのか）です。1つ目は制作ツール（Figma、Premiere、CMS、コードベースなど）に入ります。しかし、2つ目はどこにも保存されません。

クリエイティブな作業を取り巻く知識は、朝会で口頭で共有されたり、スクロールして流れてしまうSlackスレッドで議論されたり、誰も文書化しなかったミーティングで言及されたりして、クリエイティブリードの記憶に蓄積されます。チームが決定事項を参照する必要があるとき（「なぜセリフ体からサンセリフ体に変更したのか？」など）、その場にいた人に尋ねる必要があります。その人が休暇中だったり、昼食に出ていたり、会社を辞めてしまっていたりすると、その答えは失われます。

どうやって維持するか： 決定事項やクリエイティブの根拠を、クリエイティブアセットと並行して記録します。重要なクリエイティブセッションの後にボイスメモを残すことで、その思考プロセスを保存できます。Slackの議論やミーティングから生成される自動作成ドキュメントは、誰かがわざわざ手を止めて書き留めることなく、意思決定の文脈を捉えます。クリエイティブアセットのバージョン管理は、クリエイティブツール（Figmaの変更履歴、Git、Frame.ioなど）に任せます。バージョン変更の背景にある「理由」は、プロジェクトの知識レイヤーに属するべきです。

異なるデバイスや場所で作業するチームにとって、クラウドネイティブなファイルレイヤーは「あのファイルはどのマシンにある？」という問題を解消します。Fabricのクラウドドライブは、お使いのコンピューターにフォルダとしてマウントされ、ローカルストレージを消費することなく、必要に応じてファイルをストリーミングします。開いた時にファイルがクラウドからストリーミングされるため、デザイナーのノートPCがプロジェクトのアセットでいっぱいになることはありません。これには、ドライブから直接編集するためのビデオのような大容量ファイルも含まれます。スタジオのiMacで作業を始め、自宅のノートPCで続け、移動中のタブレットで確認するなど、どのデバイスからでもプロジェクトライブラリ全体にアクセスできます。メディアを保存するのと同じプラットフォームにブリーフ、参考資料、プロジェクトの知識も保存されるため、検索レイヤーがその両方を網羅することになります。

3. レビューと承認

何が起きるか： 関係者が成果物をレビューします。フィードバックが提供され、修正が行われます。承認されるまでこのサイクルが繰り返されます。

どこで破綻するか： これは、規模や業界を問わず、クリエイティブチームにおいて最も不満がたまりやすいステージです。失敗パターンは、散乱し、矛盾し、遅れてやってくるフィードバックです。

クライアントはアカウントマネージャーにメールで修正指示を送ります。クリエイティブディレクターはミーティングで口頭のフィードバックを与えます。ブランドチームはGoogleドキュメントにコメントを残します。法務のチェッカーはSlackで問題を指摘します。各レビュアーのフィードバックが異なるチャネルに存在しています。5つの異なる修正指示を、1つの首尾一貫した方向性に統合した人は誰もいません。エディターやデザイナーは、断片的で時には矛盾した指示を受け取り、作業に入る前にそれらを解釈し、調整し、優先順位をつけなければなりません。

2つ目の失敗パターンは、遅れて参加するレビュアーです。第2ラウンドで4人の関係者が承認しました。しかし、以前のラウンドに参加していなかった5人目の関係者が、ほぼ完成したバージョンを見て、以前の承認内容と矛盾する変更を要求します。そして、4回目の修正サイクルが始まります。

どうやって維持するか： 2つのルールを守ることで、ほとんどのレビュー問題を解決できます。

第一に、フィードバックは別のチャネルで説明するのではなく、成果物そのものに紐付けます。ビデオやオーディオの場合、タイムスタンプ付きのコメントを使用することで、レビュアーは議論している正確な瞬間をピンポイントで指摘できます。画像やデザインの場合は、アセットに直接描き込むこと（「ここをクロップ」「この要素を左に移動」など）が、どんな文章による説明よりも明確です。Fabricのアノテーション機能は、ビデオやオーディオへのタイムスタンプ付きコメント、画像への描画やマークアップ、あらゆるファイル内の特定ポイントに関連付けられたスレッド式の議論の3つすべてをサポートしています。Frame.ioも、ビデオに対して同様のフレーム精度のコメント機能を提供しています。Figmaはデザインに特化したフィードバックを処理します。ツールが変わっても原則は同じです。アセットに直接紐付いたフィードバックは実行可能です。アセットを言葉で説明するメールのフィードバックは実行しにくいものです。

第二に、フィードバックを制作者に渡す前に集約します。誰か（プロデューサー、プロジェクトマネージャー、あるいはミーティングの書き起こしやメッセージを横断して要約できるAIアシスタント）が矛盾を解決し、1ラウンドあたり1つの統合された修正指示書を作成すべきです。この集約ステップは、ほとんどのクリエイティブチームが実行できる、最もレバレッジの高いプロセス改善です。

第1ラウンドの前に、レビュアーのリストと承認権限を定義しておきます。レビューの途中でステークホルダーのマップを変更してはいけません。

4. 納品

何が起きるか： 承認された成果物が、それぞれの仕向け先に向けて準備され、クライアント、プラットフォーム、または一般に納品されます。

どこで破綻するか： よくある失敗は2つあります。1つ目は、フォーマットの混乱です。納品から3週間後にクライアントからInstagram版を求められ、書き出しフェーズで誰もそれを作っていなかったことに気づきます。ソーシャルチームは9:16のクロップを必要としています。セールスチームはエンドカードなしのバージョンを必要としています。各バリエーションがその場しのぎで作成され、適切な計画を立てていれば回避できたはずの時間が消費されます。

2つ目は、プレゼンテーション（見せ方）です。成果物がGoogleドライブのフォルダ、WeTransferのリンク、またはメールの添付ファイルとして届きます。何週間ものクリエイティブな努力を費やした成果物が、ファイルを単に投げ出したような形と同じ扱いで提示されてしまうのです。クライアントとの関係がビジネスを左右する代理店やスタジオにとって、納品体験はクライアントがリピートしてくれるかどうかを決定づけます。

どうやって維持するか： 予測可能なすべての納品バリエーションは、後からではなく、書き出しフェーズの時点で作成します。フォーマットのリスト（16:9のマスター、9:16のソーシャル用、1:1の正方形、字幕の有無、プラットフォーム固有のコーデック）は、プリプロダクションの段階で定義し、納品時に一挙に実行されるべきです。

成果物をプロフェッショナルに提示します。すっきりと整理され、リンク分析（誰が何をいつ見たか）やパスワード保護を備えた公開スペースは、丁寧な仕事を印象づけます。ブランド化され、整理された納品スペースを受け取ったクライアントは、「FINAL_ASSETS」という名前のGoogleドライブフォルダを受け取ったクライアントとは違った形でその成果物を評価するでしょう。クライアントがまだ成果物を確認していない場合に、自動でフォローアップを行うことで、手動で追いかけることなくプロジェクトを前進させることができます。

5. アーカイブと再利用

何が起きるか： プロジェクトが終了します。ファイルが保存されます。チームは次のプロジェクトへ移ります。

どこで破綻するか： アーカイブが「墓場」と化してしまいます。プロジェクトファイルは、当時のPMがたまたま使っていたフォルダ構造のまま、コールドストレージに入れられます。クリエイティブな決定事項、クライアントのフィードバック、制作ノート、参考資料などは、メールやSlack、共有ドライブに散らばったままになります。6ヶ月後、似たようなブリーフが届いたとき、チームはまたゼロからスタートすることになります。過去のプロジェクトは、当時のPMしか理解できないフォルダ階層の奥深くに埋もれ、見つけることができないからです。

問題はストレージではありません。ストレージは安価です。問題は「取り出し（検索）」です。検索できないアーカイブは、存在しないのと同じです。そして、ローカルストレージを一切消費しないクラウドストリーミングアーカイブ（Fabricの仮想ドライブなど）があれば、実質的に見えなくなってしまうコールドストレージに移すことなく、すべてをアクセス可能な状態に維持するコストはかかりません。

どうやって維持するか： 後から取り出すことを念頭に置いてアーカイブします。完成した成果物にメタデータ（プロジェクトタイプ、クライアント、業界、クリエイティブなアプローチ、チームメンバー、日付など）を付与します。最終的なアセットだけでなく、ブリーフ、クリエイティブの根拠、クライアントのフィードバック、意思決定ログなど、プロジェクトの文脈全体を保存します。

アーカイブを「意味」で検索できるようにします。プロジェクトファイル、ミーティングの文字起こし、ノートを横断するセマンティック検索は、アーカイブを単なる死んだストレージから、生きたクリエイティブライブラリへと変貌させます。「フィンテッククライアント向けのドキュメンタリー風ブランドフィルム」と検索すれば、関連する過去の成果物、効果のあったアプローチ、クライアントの反応、制作ノートが浮き彫りになるべきです。コンセプトで検索できるアーカイブは、雪だるま式に増える資産となります。完了したすべてのプロジェクトが、将来のすべてのプロジェクトに役立つライブラリを豊かにしていくのです。

チームによっては、正式なプロジェクト振り返りドキュメントを作成することもあります。また、蓄積されたプロジェクトの文脈（自動作成ドキュメント、ミーティングの文字起こし、Slackの決定記録など）をそのまま非公式の振り返り資料として機能させ、誰もまとめレポートを書くことなく検索できるようにしているチームもあります。

よくある質問

チームのワークフローにおいて、最もインパクトのある変更は何ですか？ フィードバックの一元化です。メール、Slack、各種ドキュメントに散らばった、矛盾するフィードバックによって失われる時間は、他のどのワークフローの非効率性をも上回ります。すべてのフィードバックをプロジェクトごとに1つのチャネルに移行し、制作者に届く前に集約することで、最も即効性のある時間短縮が実現します。

各ステージごとに別々のツールが必要ですか？ 必ずしもそうではありません。最低限実用的なクリエイティブワークフローは、プロジェクトの文脈と検索用のナレッジワークスペース（Fabric、Notionなど）、制作用のクリエイティブツール（Figma、Premiere、CMSなど）、そしてフィードバック用のレビューツール（Frame.io、Figmaのコメント機能など）で構成されます。多くのチームは、5つのステージすべてを3つのツールでカバーし、うまく機能しています。ツールの数よりも、それらを一貫して使用する規律（ルール）の方が重要です。

小さなチーム（2〜5人）はこれをどのように処理すればよいですか？ 同じ5つのステージが適用されますが、プロセスはより簡易になります。ブリーフは正式なテンプレートではなく共有ドキュメントかもしれません。レビューはプラットフォーム上ではなく通話かもしれません。アーカイブはタグ付きライブラリではなく、適切に命名されたフォルダかもしれません。しかし、原則（資料の一元化、決定事項の記録、フィードバックの集約、成果物のプロフェッショナルな提示、アーカイブを検索可能にすること）は、どのような規模であっても適用されます。

メディア用とプロジェクトの知識用で別々のツールが必要ですか？ 必ずしも必要ありません。Fabricのようなプラットフォームは、ストリーミング機能付きのクラウドメディアストレージ、メディアとドキュメントを横断するセマンティック検索、ビデオ/オーディオ/画像へのアノテーション、文字起こし、自動作成ドキュメント、プロジェクトスペースなど、その両方を処理します。フレーム精度の編集フィードバックを得るために、専用のビデオレビューツール（Frame.io）を追加するチームもありますが、デザインチームやコンテンツチームの多くは、統合プラットフォームだけで十分です。

複数のプロジェクトが同時に進行している場合はどう対処すればよいですか？ プロジェクトごとに1つのプロジェクトスペースを用意し、それぞれに独自の資料、フィードバック、文脈を保持します。すべてのプロジェクトを横断できる（「サステナビリティの視点を取り入れた過去のキャンペーン」など）、あるいは特定のプロジェクトに絞り込める（「ヒーロー動画に対するクライアントAのフィードバック」など）セマンティック検索を使用すれば、チームは個々のプロジェクト内で作業を進めながら、プロジェクト全体から学ぶことができます。

クリエイティブなワークフローにおいて、AIはどのような役割を果たしますか？ 現在、AIが最も得意とするのは、ミーティングや映像の文字起こし（Fabric）、コンテンツを意味で検索可能にすること、複数チャネルにわたるフィードバックの要約、チームのアクティビティからのドキュメント自動生成（自動作成ドキュメント）、そしてプロジェクト資料の自動整理などです。AIはクリエイティブな作業自体を置き換えるのではなく、クリエイティブな作業を取り巻く「事務的なロジスティクス」を置き換えます。

現在の（破綻している）ワークフローからどのように移行すればよいですか？ 最も苦痛を感じているステージから始めてください。多くのチームにとって、それはレビュー（フィードバックの一元化）か、アーカイブ（過去の成果物を検索可能にすること）です。まず1つのステージを改善し、時間短縮の効果を実感した上で、次のステージに取り組みます。5つのステージすべてを一度に刷新しようとすると、変化による疲弊が生じてしまいます。

ワークフローが機能しているかどうかをどのように測定しますか？ 次の項目を追跡してください：プロジェクトごとの平均修正サイクル（減少するはず）、ブリーフから納品までの時間（短縮するはず）、チームがアセットやコンテキストの検索に費やす時間（劇的に減少するはず）、そしてアーカイブされたアセットの再利用率（増加するはず）。これら4つの指標が改善されていれば、ワークフローは機能しています。

関連する読み物： ビデオ制作ワークフローのガイド、 代理店が時間の30％を無駄にしている理由、 クリエイティブチームでFabricがNotionに取って代わりつつある理由、 リピートビジネスを勝ち取るためのクライアントへの引き継ぎ。 関連ページ： クリエイティブチーム向け、 自動作成ドキュメント、 音声・動画の文字起こし、 キャンバス、 パブリッシュ。