なんだかちょっと今さらだけれど、web屋の仕事内容についての話題が出ていた。
ホームページを作る人のネタ帳
「WEB業界の人が、今更WEB屋になに作ってるんですか?というのは何事」
元々は
F's Garage
「何故、Webデザイナーが美大卒じゃなくてもやっていけるのか?」
とか
DESIGN IT! w/LOVE
「Web屋さんって何をつくるお仕事なんですか? その職業の方は必要なスキルが多いんですか?」
など。まとめるのも面倒だけれど、「webサイト制作者の仕事で求められる仕事範囲って広いよね」とか「そんなことない。他の業種だってどっこいどっこい。Web屋は自分たちの作っているものについて、もっとちゃんと考える時期では?」「いや、失礼だろそれは」「いやいや、あれはね…」とかあれこれ。飲み会の2次会くらいな話題。結局のところ何が問題とされてるのか、読めば読むほど分からなくなってくる(のはこちらの根気と理解力の問題か)。それはさておき。自分なりに読んで考えたことを漫然と。
web屋ってのが具体的に何なのかいまいちピンときてないんだけれど、webサイト制作を仕事としている人や会社のことだろう。当ブログで言うところのweb制作会社のことか。で、web屋を考える上でまず重要なのは「自社サービスの制作・運営」と「受託案件の制作・運営」を分けること。この両者は同じ会社が手がけていようが業務の方向性としては大きく違うので、分けた上で考えないと話が食い違ってくる。
「自社サービスの制作・運営」なら、DESIGN IT! w/LOVEで書いてあるように「自分たちは何を作っているのか?」「Webとは何の役に立つのか?」を考えることはけっこう大切だろうと思う。
受託案件の場合、これらを考えるのは重要じゃない。まあ、考えても無意味じゃないだろうけど、優先度は低い。
というのも、受託案件の場合は「これこれをして欲しい」というゴールをクライアントが設定するので、請け負う側はそれをどう実現するか考える方が主になるからだ。クライアントと一緒にゴールを考えることもあるだろうけれど、その場合でも「webとは~」なんていう「人生とは~」みたいな手前のことを考えるよりは、クライアントの抱える問題点なり要望なりを把握して、WEBを使ってそれをどうすればいいか考えた方が実際的だ。それがコーポレートサイトなのか、プロモーションサイトなのかってのはどうでもいい。案件によっては営業マンの代替でもいいし、そうじゃなくてもいい。ウィンドディスプレイの代替が必要なときもあるだろうし、インストラクターの代替が必要な時だってあるだろう。要するに同じwebの名の下に、非常に多くの異なる役割を持ったものが作られているのが現状なわけで。本当は出版社の編集部制度みたいに、サイトごとのゴールに合わせて特化した担当部署(物販は第1制作部、コーポレートサイトは第2制作部、プロモーションサイトでも製品プロモーションは第3で、イベントなら第4、みたいな)が存在するといいのだけれど、それは現状では難しい。
受託案件で「webとは~」ということを考えて、それを具体的な形にして提案して、クライアントが賛同してくれて、一緒に取り組んでいく。それは素晴らしいだろうけれど、うーん。事例としては参考にならないくらいのレアケースだよな、という印象はある。それってweb業界以外の事業を行うクライアントにとっては必要じゃないだろうし。役に立たないとまでは言わないものの。たとえばクライアントの情報をユーザに発信するなら、「web~とは」なんて視点は全然なくてもかまわない。他に考えるべきことがある。
あとえっとなんだっけ?ここまで読み返したら論旨がカオスすぎてわけが分からなくなってきた。
そうそう。web屋の求められるスキルが広範かどうかだけれど、これはwebの技術進歩が早いのと、web屋の大多数が零細企業で人手が少ないせいで、他の製造業のイメージよりは広範になってると思う。ぶっちゃけweb制作会社が自動車メーカーくらいの規模だったら、下請けでマークアップしかしないところとか、デザインしかしない部署とか、見積りしかしない部署とか、UI設計だけをやってる社員5人くらいの企業とか、いくらでも分業していける。ただ、そうなってない。全社員が数十人なら、自然と一人辺りがカバーするエリアは本来の必要以上に広くなるってもんだろう。それだけの単純な話だ。
ホームページを作る人のネタ帳
「WEB業界の人が、今更WEB屋になに作ってるんですか?というのは何事」
元々は
F's Garage
「何故、Webデザイナーが美大卒じゃなくてもやっていけるのか?」
とか
DESIGN IT! w/LOVE
「Web屋さんって何をつくるお仕事なんですか? その職業の方は必要なスキルが多いんですか?」
など。まとめるのも面倒だけれど、「webサイト制作者の仕事で求められる仕事範囲って広いよね」とか「そんなことない。他の業種だってどっこいどっこい。Web屋は自分たちの作っているものについて、もっとちゃんと考える時期では?」「いや、失礼だろそれは」「いやいや、あれはね…」とかあれこれ。飲み会の2次会くらいな話題。結局のところ何が問題とされてるのか、読めば読むほど分からなくなってくる(のはこちらの根気と理解力の問題か)。それはさておき。自分なりに読んで考えたことを漫然と。
web屋ってのが具体的に何なのかいまいちピンときてないんだけれど、webサイト制作を仕事としている人や会社のことだろう。当ブログで言うところのweb制作会社のことか。で、web屋を考える上でまず重要なのは「自社サービスの制作・運営」と「受託案件の制作・運営」を分けること。この両者は同じ会社が手がけていようが業務の方向性としては大きく違うので、分けた上で考えないと話が食い違ってくる。
「自社サービスの制作・運営」なら、DESIGN IT! w/LOVEで書いてあるように「自分たちは何を作っているのか?」「Webとは何の役に立つのか?」を考えることはけっこう大切だろうと思う。
なんてことも問い続ければいい。特に新しいサービスを行おうとしてる企業なら。ECサイトをはじめ、ベタに既存のオフラインな事業を行っている企業なら、他にもっと考えるべきことがあるだろうと思うけど。コーポレートサイトとか、プロモーションサイトとかって括りで、自分たちが何をつくっているかを理解してるつもりだったらどうかしてるんですよ。じゃあ、そのコーポレートサイトって何よ? プロモーションサイトって? って聞かれたらなんて答えますか。そもそもWebサイトって何よ?って聞かれたどうします。
それは思考のための道具なの? 人を賢くする道具なの? それとも、もっと他のなにか?
受託案件の場合、これらを考えるのは重要じゃない。まあ、考えても無意味じゃないだろうけど、優先度は低い。
というのも、受託案件の場合は「これこれをして欲しい」というゴールをクライアントが設定するので、請け負う側はそれをどう実現するか考える方が主になるからだ。クライアントと一緒にゴールを考えることもあるだろうけれど、その場合でも「webとは~」なんていう「人生とは~」みたいな手前のことを考えるよりは、クライアントの抱える問題点なり要望なりを把握して、WEBを使ってそれをどうすればいいか考えた方が実際的だ。それがコーポレートサイトなのか、プロモーションサイトなのかってのはどうでもいい。案件によっては営業マンの代替でもいいし、そうじゃなくてもいい。ウィンドディスプレイの代替が必要なときもあるだろうし、インストラクターの代替が必要な時だってあるだろう。要するに同じwebの名の下に、非常に多くの異なる役割を持ったものが作られているのが現状なわけで。本当は出版社の編集部制度みたいに、サイトごとのゴールに合わせて特化した担当部署(物販は第1制作部、コーポレートサイトは第2制作部、プロモーションサイトでも製品プロモーションは第3で、イベントなら第4、みたいな)が存在するといいのだけれど、それは現状では難しい。
受託案件で「webとは~」ということを考えて、それを具体的な形にして提案して、クライアントが賛同してくれて、一緒に取り組んでいく。それは素晴らしいだろうけれど、うーん。事例としては参考にならないくらいのレアケースだよな、という印象はある。それってweb業界以外の事業を行うクライアントにとっては必要じゃないだろうし。役に立たないとまでは言わないものの。たとえばクライアントの情報をユーザに発信するなら、「web~とは」なんて視点は全然なくてもかまわない。他に考えるべきことがある。
あとえっとなんだっけ?ここまで読み返したら論旨がカオスすぎてわけが分からなくなってきた。
そうそう。web屋の求められるスキルが広範かどうかだけれど、これはwebの技術進歩が早いのと、web屋の大多数が零細企業で人手が少ないせいで、他の製造業のイメージよりは広範になってると思う。ぶっちゃけweb制作会社が自動車メーカーくらいの規模だったら、下請けでマークアップしかしないところとか、デザインしかしない部署とか、見積りしかしない部署とか、UI設計だけをやってる社員5人くらいの企業とか、いくらでも分業していける。ただ、そうなってない。全社員が数十人なら、自然と一人辺りがカバーするエリアは本来の必要以上に広くなるってもんだろう。それだけの単純な話だ。
株式会社ココアがクローズドα版を公開した「meet-me」を触ってみた。人数制限があって本登録は順番待ち[*1]の「国産セカンドライフ」とも言うべきものだ。
で、その順番が回ってきたので本登録して触ってみた。α版なので、バグと思われる部分はさておいての感想。とある理由で、スクリーンショットはない[*2]。
2時間くらいは滞在したけど、30分くらいでやることがなくなった。
以上。終了。
もちろんα版なので、まあそんなものかも。できることは「釣りゲーム」「会話」「散策」の三つ。釣りゲームは興味が湧かず、試していない。会話については少し行ったものの、ネット上なら他に会話を楽しむツールは無数にあるので、わざわざ「meet-meでは~」と書くほどのことでもない。
で、散策。07年12月現在、行ける場所は限られている[*3]。渋谷・原宿と新宿と六本木。あといくつか。いちおうmeet-meの世界は東京をモデルにしているので、六本木ヒルズや109など見慣れたランドマークがちらほら。ただ、
グラフィックはこちらのとおり。ただ、こちらの環境のせいか、私が見たのはもっと「モッサリした」光景だった。渋谷駅周辺にクリスマスツリーもあったけれど、見惚れるほどじゃなかった。
人は少ない。登録人数を制限しているせいもあるのだろうけど、こまめにアクセスするほど現状では見るべきものがないせいもあるだろう。
というわけで、「人の少ない、東京を思わせるガランとした空間」を歩いて回ることになる。ちょっとゾンビ映画を思い出させるシチュエーションだ。ランドマークの入り口や地下街への入り口は軒並みシャッターが下りてるし。
アクセス可能になった日はサーバメンテがあり、終了後すぐに再度アクセスすると文字通り「誰もない」状況で『アイ アム レジェンド』のようだった。本当に見渡す限りに誰もいないので、思わず奇声を発してしまった。妙な開放感。
会員登録時にmeet-meの通貨である「ココア」を2000ポイント支給されるサービスがあったのだけれど、使える場所がどうしても見付けられなかった。上記にも書いたように、店は全部閉まってるし。今後のα版機能追加まで待つしかないのかもしれない。
で、これから機能が増えて人も増えたらどうなりそうか?といえば、なにせ現状では何もなさ杉で予想が難しい。ただ、現状ではファーストインプレッションで惹き付けられるほどじゃない。
というわけでなんだか尻すぼみな終わり方だけれど、実際にそうなんだからしょうがない。β版にアクセスできるなら、もう一回アクセスしてみるだろうと思うけど、それまでは放置の方向で。
で、その順番が回ってきたので本登録して触ってみた。α版なので、バグと思われる部分はさておいての感想。とある理由で、スクリーンショットはない[*2]。
2時間くらいは滞在したけど、30分くらいでやることがなくなった。
以上。終了。
もちろんα版なので、まあそんなものかも。できることは「釣りゲーム」「会話」「散策」の三つ。釣りゲームは興味が湧かず、試していない。会話については少し行ったものの、ネット上なら他に会話を楽しむツールは無数にあるので、わざわざ「meet-meでは~」と書くほどのことでもない。
で、散策。07年12月現在、行ける場所は限られている[*3]。渋谷・原宿と新宿と六本木。あといくつか。いちおうmeet-meの世界は東京をモデルにしているので、六本木ヒルズや109など見慣れたランドマークがちらほら。ただ、
とあるように、完全な東京の再現ではない。けっこうランドマークの間は空き地だったり匿名な高層ビルだったりする。※ 本サービスは、実在している場所や建築物等をモデルにしてはありますが、あくま でも仮想空間であり、イメージです。そのため、実際の場所や建築物等と 直接関係していないものが多く含まれております。
グラフィックはこちらのとおり。ただ、こちらの環境のせいか、私が見たのはもっと「モッサリした」光景だった。渋谷駅周辺にクリスマスツリーもあったけれど、見惚れるほどじゃなかった。
人は少ない。登録人数を制限しているせいもあるのだろうけど、こまめにアクセスするほど現状では見るべきものがないせいもあるだろう。
というわけで、「人の少ない、東京を思わせるガランとした空間」を歩いて回ることになる。ちょっとゾンビ映画を思い出させるシチュエーションだ。ランドマークの入り口や地下街への入り口は軒並みシャッターが下りてるし。
アクセス可能になった日はサーバメンテがあり、終了後すぐに再度アクセスすると文字通り「誰もない」状況で『アイ アム レジェンド』のようだった。本当に見渡す限りに誰もいないので、思わず奇声を発してしまった。妙な開放感。
会員登録時にmeet-meの通貨である「ココア」を2000ポイント支給されるサービスがあったのだけれど、使える場所がどうしても見付けられなかった。上記にも書いたように、店は全部閉まってるし。今後のα版機能追加まで待つしかないのかもしれない。
で、これから機能が増えて人も増えたらどうなりそうか?といえば、なにせ現状では何もなさ杉で予想が難しい。ただ、現状ではファーストインプレッションで惹き付けられるほどじゃない。
というわけでなんだか尻すぼみな終わり方だけれど、実際にそうなんだからしょうがない。β版にアクセスできるなら、もう一回アクセスしてみるだろうと思うけど、それまでは放置の方向で。
- というか、「12/26までに本登録のメールが来ない人はα版の登録を諦めてください」的な記述があったので、α版は実質締め切り?→その記述があるページを発見できなくなってた。夢か?[↩back]
- インストール後にPCが激しく不安定になったので、もうクライアントソフトをアンインストールしてしまった。[↩back]
- 新宿駅は西口から新南口経由で歩いて東側へ行こうとしたけれど、不気味な袋小路に阻まれて行けなかった。[↩back]
公開されないサイトマップというのがある。VIP専用の裏ページ…ではなく、要するに関係各者でページ間の関係性などを把握するために使う資料だ。エクセルなんかで木構造として描かれる。たぶん、制作資料用のサイトマップとかどうでもいいと思ってる人が多いだろうな。
しかしサイトマップを作る側としては、やはり関係者みんながなるべくサイトの構造を理解しやすいような資料を作ってやる必要があるわけですよ。「誰もサイト構造の全貌が把握できていない案件」なんて香ばしいでしょう?ここがすっきりしてないと、ページが増えた時点で行き当たりばったりに改築した屋敷みたいになってしまうし。制作資料としてのサイトマップには、関係者へサイト構造に対して共通のイメージを持たせると共に、webディレクターが思い描いたサイト構造を整理するものでもあるのだ。
というわけで、ユーザ公開されないサイトマップも地味ぃ~にwebディレクターとしての頭を悩ませる。というか、なってきている気がする。「あれ?これってどういう配置にするんだ?」というケースが増えてる気がする。こちらの知能が退化しているせいもあるかもしれないが。
というのも従来型のサイトは静的な構造なので、ページ間の関係性は把握しやすく描きやすく、手を加えなければ不変だった。一方、システム側で動的にページを生成したり、CGMサービスだったりすると、こうしたページの静的な関係が崩れ、木構造では精度の低いサイトマップになってしまうことがある。
いやまあそれでも、ユーザがアクセスするページをTOPとし、そこから1クリックを2階層目、最低でも2クリック必要なものを3階層目として無理に木構造にすることはできる。あるいは、意味・内容からページに上位下位を割り振り、フォルダ構造とは一致しなくてもスッキリした木構造にするとか。
そんなわけでたいていはどうにか木構造化できるのだけれど、メルカトル図法で描かれた世界地図のように、やや歪みが出る。この歪みが大きいと、関係者間の認識の相違が大きくなって後で困ることになったり。
さらに、動的というよりCGM的なサイトだと、規模が大きいのに「TOP→以下全部同じ階層」みたいなケースもありうる。これではサイトマップの意味があまりないのだけれど、まあそういうサイトだから、と割り切るか、別の意味レベルで切り分けたものをもう一個作るか。
なんにせよ、時代が進めばそのうち静的なサイトマップというもの自体が作れないケースも出てくるだろう。動的にサイトマップをそのつど生成するとか。とはいえそれは「不思議なダンジョン」みたいなもので便利ではなさそう。まあ、サイトを作る前段階では動的につどつど生成とかできないわけだけど。
しかしサイトマップを作る側としては、やはり関係者みんながなるべくサイトの構造を理解しやすいような資料を作ってやる必要があるわけですよ。「誰もサイト構造の全貌が把握できていない案件」なんて香ばしいでしょう?ここがすっきりしてないと、ページが増えた時点で行き当たりばったりに改築した屋敷みたいになってしまうし。制作資料としてのサイトマップには、関係者へサイト構造に対して共通のイメージを持たせると共に、webディレクターが思い描いたサイト構造を整理するものでもあるのだ。
というわけで、ユーザ公開されないサイトマップも地味ぃ~にwebディレクターとしての頭を悩ませる。というか、なってきている気がする。「あれ?これってどういう配置にするんだ?」というケースが増えてる気がする。こちらの知能が退化しているせいもあるかもしれないが。
というのも従来型のサイトは静的な構造なので、ページ間の関係性は把握しやすく描きやすく、手を加えなければ不変だった。一方、システム側で動的にページを生成したり、CGMサービスだったりすると、こうしたページの静的な関係が崩れ、木構造では精度の低いサイトマップになってしまうことがある。
いやまあそれでも、ユーザがアクセスするページをTOPとし、そこから1クリックを2階層目、最低でも2クリック必要なものを3階層目として無理に木構造にすることはできる。あるいは、意味・内容からページに上位下位を割り振り、フォルダ構造とは一致しなくてもスッキリした木構造にするとか。
そんなわけでたいていはどうにか木構造化できるのだけれど、メルカトル図法で描かれた世界地図のように、やや歪みが出る。この歪みが大きいと、関係者間の認識の相違が大きくなって後で困ることになったり。
さらに、動的というよりCGM的なサイトだと、規模が大きいのに「TOP→以下全部同じ階層」みたいなケースもありうる。これではサイトマップの意味があまりないのだけれど、まあそういうサイトだから、と割り切るか、別の意味レベルで切り分けたものをもう一個作るか。
なんにせよ、時代が進めばそのうち静的なサイトマップというもの自体が作れないケースも出てくるだろう。動的にサイトマップをそのつど生成するとか。とはいえそれは「不思議なダンジョン」みたいなもので便利ではなさそう。まあ、サイトを作る前段階では動的につどつど生成とかできないわけだけど。
ディレクションの技と言うと「クライアントに納得してもらう」「納期を守ってもらう」「スタッフのモチベーションを保つ」など、「こうすればこうなる」的な行動と結果が一対一対応してないものの方が実際には多い。なので、以下の小技も一見すると「技」に見えないだろうけれど。
「デザインについて、クライアントのイメージを引き出す」というのは、案件初期のwebディレクションにおける重要なミッションの一つだ。漠然とした方向性だけでも引き出せれば、話がしやすくなるし、デザイナーさんも無数の選択肢がある程度は絞られてデザインしやすくなる。中でも、具体的にイメージと近いサイトを教えてもらえると、グッとやりやすくなる。もちろんこちらでその辺も考えて提案できるとよいのだけれど、納期や予算的にあまり試行錯誤ができない場合は、教えてもらうに越したことはない。ただ、これが難しい。
・イメージするサイトがない
クライアントはデザイナーでもweb業界の人でもない場合が普通なので、これは仕方がない。
こういうクライアントには「どんなデザインが好きですか?カワイイのとかアッサリしたのとか、親しみやすいとか高級感があるとか」など、具体的なキーワードを織り交ぜつつ、好みを聞き出すところから始めると、少しずつイメージが引き出せる。あと、普段はどんなサイトを見ているか、とか。
・イメージするサイトがあっても言いたがらない
言ってしまうと、デザイナーがそのイメージに引っ張られすぎることを心配しているケース。
これは全くの杞憂、と言えないところが辛い。確かに、そういうデザイナーさんも皆無じゃない。いや、あれはカンベンしてください。ホント。
で、ここまでは基本。小技でもなんでもない。小技というのは「教えてもらったサイトらしさ、がどの辺にあると思っているのかを探る」ということ。
教えてもらっただけで安心して、いざデザインが上がって来ると「イメージしてたのと違う。わざわざ参考になるサイトまで教えたのに」という場合はだいたいがこれ。つまり、クライアントとデザイナーさんの間で「なにがそのサイトらしいデザイン要素か」という解釈に大きな違いがあったわけだ。逆に、あまり似せすぎないようにしたつもりが「教えたサイトのデザインを丸ごと持ってきただけじゃないか」という事態も。
こうしたことを避けるために、サイトを教えてもらったら(自分でそのデザインを見て)どの辺が「そのサイトらしいか」「どの辺がいいと思っているのか」を引き出せるようにトライしてみる。それは配色かもしれないし、見出しの雰囲気かもしれないし、ボタンなどパーツの形かもしれない。場合によっては、レイアウトのことかもしれないのだ。
参考サイトを教えてもらったら、なるべくそのサイトのデザインについてあれこれ引き出しておくこともセットで忘れずに。それはデザインをする上で、きっと役立つ情報になるはず。
さらにおまけ技
教えてもらったサイトは、なるべく早くスクリーンショットを撮影しておくこと。確認しようと思って後日そのサイトにアクセスしていたら、全面リニューアルでまったく違うデザインに…
という笑えない事態を防げる。
「デザインについて、クライアントのイメージを引き出す」というのは、案件初期のwebディレクションにおける重要なミッションの一つだ。漠然とした方向性だけでも引き出せれば、話がしやすくなるし、デザイナーさんも無数の選択肢がある程度は絞られてデザインしやすくなる。中でも、具体的にイメージと近いサイトを教えてもらえると、グッとやりやすくなる。もちろんこちらでその辺も考えて提案できるとよいのだけれど、納期や予算的にあまり試行錯誤ができない場合は、教えてもらうに越したことはない。ただ、これが難しい。
・イメージするサイトがない
クライアントはデザイナーでもweb業界の人でもない場合が普通なので、これは仕方がない。
こういうクライアントには「どんなデザインが好きですか?カワイイのとかアッサリしたのとか、親しみやすいとか高級感があるとか」など、具体的なキーワードを織り交ぜつつ、好みを聞き出すところから始めると、少しずつイメージが引き出せる。あと、普段はどんなサイトを見ているか、とか。
・イメージするサイトがあっても言いたがらない
言ってしまうと、デザイナーがそのイメージに引っ張られすぎることを心配しているケース。
これは全くの杞憂、と言えないところが辛い。確かに、そういうデザイナーさんも皆無じゃない。いや、あれはカンベンしてください。ホント。
で、ここまでは基本。小技でもなんでもない。小技というのは「教えてもらったサイトらしさ、がどの辺にあると思っているのかを探る」ということ。
教えてもらっただけで安心して、いざデザインが上がって来ると「イメージしてたのと違う。わざわざ参考になるサイトまで教えたのに」という場合はだいたいがこれ。つまり、クライアントとデザイナーさんの間で「なにがそのサイトらしいデザイン要素か」という解釈に大きな違いがあったわけだ。逆に、あまり似せすぎないようにしたつもりが「教えたサイトのデザインを丸ごと持ってきただけじゃないか」という事態も。
こうしたことを避けるために、サイトを教えてもらったら(自分でそのデザインを見て)どの辺が「そのサイトらしいか」「どの辺がいいと思っているのか」を引き出せるようにトライしてみる。それは配色かもしれないし、見出しの雰囲気かもしれないし、ボタンなどパーツの形かもしれない。場合によっては、レイアウトのことかもしれないのだ。
参考サイトを教えてもらったら、なるべくそのサイトのデザインについてあれこれ引き出しておくこともセットで忘れずに。それはデザインをする上で、きっと役立つ情報になるはず。
さらにおまけ技
教えてもらったサイトは、なるべく早くスクリーンショットを撮影しておくこと。確認しようと思って後日そのサイトにアクセスしていたら、全面リニューアルでまったく違うデザインに…
という笑えない事態を防げる。
他の仕事と同じく、webディレクターも経験を通して学んでいく。失敗すれば「次はこうならないよう気をつけよう」と考える。
経験が少ないうちは事前に予想できることなど多くない。それが、案件をこなすごとに急激に増えていく。前は長い時間の掛かっていた「想定ケースの予想」もかかる時間が減っていく。一方で、思いつく想定ケースは増えていく。
そうすると、様々な事態に対応できるよう「あれも言っておこう」「これも確認しておこう」といった項目が際限なく増えていく。失敗から学んだ教訓を生かそうとすればすれるほど、この傾向は強い。
結果的に、下準備に掛かる時間は増えていく。本人からすれば「様々な事態に目配りした」結果が他の人からは煩雑で付き合いきれないものになってしまう。
こういう場合、たいていはディレクター本人がやってられなくなり、今度は下準備が減少していく。同じクライアントや制作スタッフなら、案件を重ねるごとに共通の感覚が育ってくるおかげで、勘所が見えてくるせいもある。また、ディレクターが経験を積むことで、「必ず押さえるべきこと」とそうでもないものとの感覚が解ってくるためでもある。ただ、減少するのも行き過ぎると「確認漏れによるミス」が発生し、あらためて気を引き締めることになる。
本当はここで「じゃあどうするか?」ということが書けるといいのだけれど、こればっかりは個別の試行錯誤で上手く行ったり失敗したりを繰り返すしかない。たぶん「ディレクション」という業務そのものには技術的なイノベーションがない代わりに、こういう基本的な問題の周りをずっとグルグルすることになってるんだと思う。
経験が少ないうちは事前に予想できることなど多くない。それが、案件をこなすごとに急激に増えていく。前は長い時間の掛かっていた「想定ケースの予想」もかかる時間が減っていく。一方で、思いつく想定ケースは増えていく。
そうすると、様々な事態に対応できるよう「あれも言っておこう」「これも確認しておこう」といった項目が際限なく増えていく。失敗から学んだ教訓を生かそうとすればすれるほど、この傾向は強い。
結果的に、下準備に掛かる時間は増えていく。本人からすれば「様々な事態に目配りした」結果が他の人からは煩雑で付き合いきれないものになってしまう。
こういう場合、たいていはディレクター本人がやってられなくなり、今度は下準備が減少していく。同じクライアントや制作スタッフなら、案件を重ねるごとに共通の感覚が育ってくるおかげで、勘所が見えてくるせいもある。また、ディレクターが経験を積むことで、「必ず押さえるべきこと」とそうでもないものとの感覚が解ってくるためでもある。ただ、減少するのも行き過ぎると「確認漏れによるミス」が発生し、あらためて気を引き締めることになる。
本当はここで「じゃあどうするか?」ということが書けるといいのだけれど、こればっかりは個別の試行錯誤で上手く行ったり失敗したりを繰り返すしかない。たぶん「ディレクション」という業務そのものには技術的なイノベーションがない代わりに、こういう基本的な問題の周りをずっとグルグルすることになってるんだと思う。
| ホーム |