Product Thinking · 2026-08-09

クライアントに、こちら側のファイル管理を見せる必要はない

クライアントにDriveのリンクを送るのではなく、納品用の画面を用意している理由。

ファイルの管理はこちら側に残したまま、クライアントには必要な画面だけを渡している理由。

納品は、ファイル管理ではない

クライアントに動画を納品するとき、こちら側にはすでにファイルの置き場所があります。

フォルダで整理され、命名規則があり、Google Driveに入っています。自分の作業から見れば、この構造には理由があります。制作の進め方そのものだからです。

ただ、それをクライアントが見る必要はありません。なぜそのフォルダがあるのか、ファイルがどう並んでいるのか、こちらが何をどう管理しているのかまで、共有する必要はないのです。

納品時に必要なのは、もっとシンプルです。

動画を見る。

必要なものを選ぶ。

ファイルを受け取る。

そのために必要のない管理上の情報は、こちら側に残しておけばいい。

保管するための画面と、渡すための画面は違う

Google Driveは、ファイルを置く場所としてよくできています。

だからといって、その画面がそのまま渡すための画面になるわけではありません。

動画が並んだフォルダは、クライアントにファイルとフォルダの単位で考えることを求めます。フォルダを開く。ファイル名を探す。ファイルを開く。戻る。また別のものを開く。

どれも難しい操作ではありません。

ただ、納品そのものに必要な操作ではありません。

仕上がりを見て、必要なものを判断できれば十分です。

すでにある置き場をそのまま渡してしまうのは、こちらが楽だからです。ファイルがDriveにあるなら、Driveのリンクを送るのがいちばん早い。

でも、渡す側にとっていちばん早い方法が、受け取る側にとっていちばん簡単とは限りません。

だから画面のほうで、こちらの構造が見えないようにしています。

すべての納品にレビュープラットフォームが要るわけではない

逆に振りすぎても、同じことが起きます。

本格的なレビュープラットフォームなら、コメント、承認、ユーザー管理、通知、バージョン管理、タイムコード指定と、いくらでも足していけます。

案件がそれを必要とするなら、有用な仕組みです。

ただ、すべての納品がそうではありません。

仕上がった動画をひととおり見て、必要なものを選び、受け取る。それで足りる場面もあります。

そこに大きな仕組みを持ち込んでも、納品が丁寧になるわけではありません。

その案件には必要のない手順が、ひとつ増えるだけです。

ファイルは、Driveに置いたままにする

見やすくするためだけに、同じファイルを別のサービスへ上げ直したくはありませんでした。

ファイルはすでにGoogle Driveにあります。

そこで、ファイルはDriveに置いたまま、その手前にClient Video Portalを作りました。

新しいメディアライブラリを作ったわけではありません。既存のDriveフォルダから動画を読んで、一覧として見せているだけです。

クライアントはDriveの画面を開かずに、再生し、選び、ダウンロードできます。Driveの権限設定も、動画の配信の仕組みも、このポータルがどこで動いているかも、画面には出てきません。

ブラウザでのプレビュー対象にしていない大容量ファイルも、エラーとして扱いません。必要ならそのままダウンロードできるようにしています。

Driveは置き場所のままです。変えたのは、クライアントから見えるところだけです。

選んだ結果を、データベースにしない

同じことが、選択の仕組みにも言えます。

クライアントが何本かに印をつける。それだけのために、ユーザーアカウントや案件ごとのデータベース、承認の履歴を残す仕組みまで用意する必要は、必ずしもありません。

この使い方なら、選択は軽いままで足ります。

選んだファイルはブラウザが覚えています。クライアントはファイル名をコピーするか、CSVやJSONとして書き出せます。

Google Driveに書き戻すこともしません。

元のファイルには手を触れません。

選んだ結果は、そのあとのやりとりに使えれば十分です。そこから先には広げないことにしています。

納品の仕組み自体が、もうひとつの案件になってはいけない

これは、複数のクライアントで使い始めてから、はっきりしてきました。

新しい案件のたびに、別のデプロイ、別の環境変数一式、アプリケーションのコピーが増えていく。そういう状態にはしたくありませんでした。

それでは、クライアント側の手間を減らした分を、こちら側の手間で払うだけです。

そこで、案件の区切りをDriveのフォルダ構成そのものに持たせました。

クライアントごとの案件は、共通の親フォルダの下に自分のフォルダを持ちます。フォルダがひとつの案件にあたり、その中に置いた小さな設定ファイルで、タイトル、パスワード、ダウンロードの可否を決めます。

新しい納品は、アプリケーション側を作り直さずに、Driveにフォルダを足して設定するだけで用意できます。

ポータルはひとつのままです。

案件は、それぞれ独立したままです。

見せ方だけを、あとから作る

これがClient Video Portalの考え方です。

Google Driveが動画を置けないから作ったわけではありません。レビュープラットフォームがもうひとつ必要だったから作ったわけでもありません。

ファイルを保管することと、それを人に渡すことが、別の作業だから作りました。

ファイルは、すでにある場所に置いたままでいい。用意したのは、その手前に置く画面だけです。

FrameBaseでは、素材が来る前に受け皿を作りました。Client Video Portalでは、すでにあるファイルを動かさず、その見せ方だけを作りました。

クライアントに、こちら側のファイル管理を見せる必要はありませんでした。必要だったのは、仕上がりを見て、判断して、受け取れることだけです。

Client Video Portalは、その線引きから生まれたツールです。