FigJamから一時共有URLへ切り替えるタイミング

できること

FigJamはフェーズ初期の要件整理・サイトマップ作成・ワイヤー検討に適しており、社内メンバーが付箋でコメントしながら非同期で構造を詰めていく作業が得意だ。この段階では外部への共有は不要で、FigJamの編集共有リンクを社内Slackチャンネルに貼り付けるだけで回せる。

HTMLのコーディングが完了し「実際のブラウザ表示でクライアントに確認してもらいたい」と感じた瞬間が切り替えの起点になる。PCとスマートフォンで表示を自分で確認し、レイアウト・フォント・インタラクションが意図通りであれば、その時点で一時共有URLを発行してクライアントに送る段階に入ったと判断できる。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

FigJamのフレームはスクロールやホバーなどのCSSアニメーションを再現できない。コーディング済みのHTML特有の動的表現をFigJam上で確認させようとしても、静止画的な表示に留まるため、実装の正確なフィードバックを得られない。

FigJamはHTMLファイルをそのままホスティングする機能を持たないため、AIで生成したHTML/zipを「ブラウザで動く状態」で渡すことができない。この制約があるため、コーディング完了後にFigJamを使い続けることは手段として成立せず、何らかの一時公開サービスへの移行が必須になる。

認証と期限の違い

FigJamリンクは有効期限を持たず、誰に送ったかの記録も共有者側では追いにくい。一時共有URLサービスを使う場合は「このレビューは〇月〇日に期限を設定しました」とクライアントに明示できるため、古いURLへのアクセスが続くことを防げる。

案件の機密レベルに応じて認証手段を選ぶとよい。不特定多数が対象なら公開URLのみでも構わないが、競合他社に見られたくない場合はパスワードかメール認証を追加し、社内向けのステージング共有なら会社ドメイン認証で絞り込むのが確実だ。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

一時共有URLへ移行した後に修正が発生した場合、同一URLで差し替えられるサービスを選んでおくと運用が楽になる。毎回新URLをクライアントに送ると「どのURLが最新か」の確認コストが増し、特にメールでやり取りしているケースでは混乱が起きやすい。

一時共有URLを発行したら、ファイル名または管理ダッシュボード上のメモ欄に「v1-client-review-2024-07」のような識別子を付けておく。最終納品版と途中のレビュー版が混在しないよう、期限を過ぎたURLは失効させるか手動でアーカイブし、アクティブなURLを常に1本に絞る運用が理想だ。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

FigJamが向くのは「要件定義〜ワイヤーフレーム段階」で社内メンバーが構造を議論する局面だ。この段階では外部共有を行わず、FigJamの編集リンクを社内限定で使い、完成度が上がるまで外に出さない運用が適している。

一時共有URLへの切り替えが必要になるのは、HTMLコーディングが完了して社外レビューに入る段階、もしくは静的サイトを本番公開前に特定のステークホルダーに見せる必要が生じた段階だ。この二つのトリガーどちらかに当てはまったら、認証付き共有URLを発行して移行する。