ヒアリングは大事
ヒアリングをするときは、相手の意図を確認する事が重要です。発言内容の表面だけを要件として受け止めてしまうと、後々ズレてくることが多いです。
相手が自分の意図を正しく伝える技術を持っていない事が多い、ということを心掛けておかないといけません。
相手の発言を聞いた際、違和感があれば、早めにギャップを解消した方がよいと思います。相手は、やりたいことを具体的にイメージした上で伝えているわけでなく、具現化していく課程で認識が間違っていることに気付くことが多いはずです。
そんなときは、自分なりの解釈を加えて、相手との問答を想定しながら組み立てていくのがよいです。まずは自分の意図を説明した上で、認識あわせをするのがよいと思います。説明に要する労力は掛かりますが、後からズレを修正するより総体的に見て近道となるはずです。
相手の意図を確認する、というのは想像力が必要となります。質問の仕方や自分の知識などテクニカルな要素は必要ですが、基本は、
・なぜ、そのような事を言っているのか？
・具現化すると何が起きるのか？
を突き詰めていくと、意図が見えてくると思います。
さらに、相手が意図する背景を固めるには、
・一般論
・業界、同業他社、類似案件
・特殊性
など、いくつかの切り口で裏を取る作業を行うと、対外的な説得力が増すので、認識のズレを解消できると思います。
話の意図が見えない場合は、案件としての目的が定まってなかったり、個人的見解に偏っていることが多いです。個人的見解も大事ですが、他人に受け入れられないことがあるので注意が必要です。相手が満足する結果となっても、不完全燃焼のままでは、継続的な関係を構築するのは難しいと思います。
ヒアリング段階で、単に相手の話を聞くことが着地点ではなく、ヒアリング後のアクションをイメージしながら、足りない要素を引き出し、場合によってはその場で作り上げる行為ができるとよいです。後工程がやりやすくなります。
相手が自分の意図を正しく伝える技術を持っていない事が多い、ということを心掛けておかないといけません。
相手の発言を聞いた際、違和感があれば、早めにギャップを解消した方がよいと思います。相手は、やりたいことを具体的にイメージした上で伝えているわけでなく、具現化していく課程で認識が間違っていることに気付くことが多いはずです。
そんなときは、自分なりの解釈を加えて、相手との問答を想定しながら組み立てていくのがよいです。まずは自分の意図を説明した上で、認識あわせをするのがよいと思います。説明に要する労力は掛かりますが、後からズレを修正するより総体的に見て近道となるはずです。
相手の意図を確認する、というのは想像力が必要となります。質問の仕方や自分の知識などテクニカルな要素は必要ですが、基本は、
・なぜ、そのような事を言っているのか？
・具現化すると何が起きるのか？
を突き詰めていくと、意図が見えてくると思います。
さらに、相手が意図する背景を固めるには、
・一般論
・業界、同業他社、類似案件
・特殊性
など、いくつかの切り口で裏を取る作業を行うと、対外的な説得力が増すので、認識のズレを解消できると思います。
話の意図が見えない場合は、案件としての目的が定まってなかったり、個人的見解に偏っていることが多いです。個人的見解も大事ですが、他人に受け入れられないことがあるので注意が必要です。相手が満足する結果となっても、不完全燃焼のままでは、継続的な関係を構築するのは難しいと思います。
ヒアリング段階で、単に相手の話を聞くことが着地点ではなく、ヒアリング後のアクションをイメージしながら、足りない要素を引き出し、場合によってはその場で作り上げる行為ができるとよいです。後工程がやりやすくなります。
Webサイトの運用受託業務について
受託でWebディレクターをやっていて面白いと感じるのは、いろんな業種を知ることができるという点です。
知的好奇心を満たすには最適な仕事と言えるかもしれません。
まず、ひとくちにWebサイトといっても様々です。
受託なので、どういうクライアント、Webサイトと巡り会えるのか分かりません。
コーポレートサイト、マーケティングサイト、ECサイト、社内向けサイト、会員向けサイトなど目的によって考え方やアプローチが異なります。
プロモーション要素の強いスポット案件もあれば、継続的な運用が発生する案件もあります。
受託が生業の軸であれば、継続的な運用案件があると事業的には安定につながります。
運用の作業に追われてしまうと新規開拓ができず、それはまた不安定要素になります。
これは経営者としてはジレンマなのではないでしょうか。
幸い、私はディレクターとしての面白さを追求している立場なので、運用案件の魅力についてまとめてみようと思いました。
Web受託の運用案件にも様々あります。
・情報の更新が中心
・キャンペーンページなどページ制作
・バナーなどクリエイティブ作成
・システムの保守、管理が発生
・継続的なサイト改善を伴う
・コンテンツ企画を伴う
まず「運用の受託」というイメージがつきやすい「情報の更新が中心」から。
テキストやイラストの差し替えを代行する業務です。
コンテンツが多いサイト（ショッピングサイトや商品紹介がメインのサイト）が主な対象です。
クライアント側に運用担当、または窓口担当がいるけど、HTMLに詳しくなかったり画像を加工・作成するスキルがない、更新量が多くて内部で処理できない、などのケースが想定されます。
基本的にはクライアントから依頼があり、指示通りに進めます。
依頼内容が来ると、テストサイトやステージングサーバーに反映後、クライアント確認を経て本番公開、公開後のクライアント確認という流れが基本です。
更新手段として、CMSが導入されていたり、ファイル一式をFTPでアップなど案件により様々なルールがあります。
本番公開はクライアント側にて操作するパターンもあります。
開始前に、運用ルールの取り決めが重要です。
■作業フロー
依頼方法はメール、FAX、電話が主です。
依頼数が多い場合は、管理表や案件番号をつけてステータスをチェックします。
ステータス「完了」にするのを誰が行うか取り決めることは大事です。
ベンダー側の窓口（運用ディレクター）が「完了」と変更する場合でも、最終的にはクライアント側にも確認してもらう方がよいです。
双方で二重チェックをした方が漏れを軽減できるのが利点です。
また、トラブルが発生した場合、損害賠償問題になることがあります。
例えば、表示価格をミスして売れてしまった場合、「誰の責任か？」と言及されるケースが想定されます。
公開したベンダーの責任、と一方的に言われないようにリスクヘッジのためにも最終確認はクライアントにして頂くことが重要です。
ディレクターは、重要と思う修正（数値だったり、社長コメントだったり企業・団体にとって影響が強いと思われる情報）は、公開直後に確実にクライアント確認をとるべきです。
トラブルケースとして、完了メールを送っていたけどクライアントから返事がなく放置しておいたら被害が大きくなった、、、というのは私の体験談です。
電話で確認したり、直接窓口が不在の場合は、クライアントの別担当に確認を依頼したりと、確実に抑えておいた方がよいです。
特に、休日前日の夕方更新は気をつけましょう。
クライアントが帰ってしまって確認が取れず、そんな時に限って休日の朝に緊急修正依頼（社長がたまたまサイトをみて担当者に連絡など・・・）が来ます。
システム設定変更が絡むような更新は、金曜日は避けるというのも運用ルールの一つだと思います。
定期的な作業報告も必要です。
更新履歴は残しておいた方がよいのと、作業ボリュームの認識あわせが出来ます。
類似の作業が発生することがあります。
例えば、年次の数値変更や、季節モノなどが想定されます。
過去にどのような作業を行ったのか、すぐに確認できると、作業効率がアップしますし、クライアントからも重宝されます。
運用案件は、定期的に作業ボリュームを計測しておいた方がよいです。
1ヶ月で何ページだったのか、どのくらい時間が掛かったのか、何人くらい投入したのか、など分かるようにしておかないと、契約内容が適正だったのか判断できなくなります。
結果的に赤字だったり、クライアントから何となく高いと思われて、別のベンダーに打診されたり（打診を受けたベンダーはディスカウント提案するはず）、、、ということが発生されます。
計測する上で悩ましい課題があります。
作業スピードと品質は、作業者のスキルに依存する部分が多い、ということです。
「HTMLができる」という作業者でも、レベルはバラバラです。
ITスキルはあるが、ミスが多いというタイプもいます。
スキルがなくても、慣れてくると作業が早くなります。
そんな要因があるので、個人のスキルに左右されてしまうのは避けられない事実です。
そんな状況で、作業担当者の申告通りに、時間を積算しても、会社としてのレベルが低いと捉えられる可能性もあります。
ディレクターが品質をチェックして、適切な工数を判断する必要があると思います。
■制作ガイドライン
サイトを構築やリニューアルする際、制作ベンダーは制作ガイドラインを作成します。
HTMLコーディングルールや、スタイルシートの構成、デザイン的なトーン＆マナーなどのメニューで構成されます。
ディレクターおよび作業者は、内容を理解しておく必要があります。
クライアントが、自分のブランドを保持するために必要な要素なので、独断はNGです。
定期的に、制作ガイドラインをアップデートするクライアントもいるので、刷新された際には関係者に周知して必要に応じて意識あわせをやったほうがよいと思います。
制作ガイドラインは、社内の共有サーバーなど全員がアクセスできる場所に保管しておきます。
また、Web上に作成された制作ガイドラインもあるため、定期的なチェックも必要です。
トーン＆マナーに関して、運用前に確認が必要なのは、デザインが発生する可能性があるか？という点です。
タイトル文字や、訴求要素のバナー作成、営業所の地図作成など、内容によりデザイナーやイラストレーターが必要なケースもあります。
当初の契約には含まれてなくても、運用中に相談されることもあります。
依頼が来たときに慌てなくても良いように、体制かスキルの準備をやっておいた方がよいです。
都度外注になると、コストが読みづらくなります。
また、使用するフォントの確認が必要です。
持っていない場合は、購入するか、特殊フォントの場合はクライアントに提供依頼など行います。
通常、「モリサワ」の基本セットはあった方が便利です。
運用中、意外と迷うのはファイルの命名規則です。
英単語なのか、日本語のアルファベット表記なのか、連番なのか、等々決めておいた方が良いと思います。
あとファイルが増えていくと、ディレクトリー階層を見直す場合も発生します。
年次で分けたり、カテゴリー毎に分割したり、という感じです。
運用途中で問題視されることが多いと思いますが、SEO対策やファイル管理（リンク切れをなくすためリダイレクトさせるなど）上、好ましくないので最初に取り決めをしておいた方がよいと思います。
CMSが導入されていると、通常ルール化されているので気にしなくてもよいです。
■環境
テスト・ステージング環境、本番環境へのアクセス手段を確認します。
FTPで直接ファイルをアップする場合とCMSなど更新ツールが導入されている場合があります。
FTPでアップするには、HTMLの基礎知識が必要となります。
FTPでなくても、Windowsの共有フォルダにアップする場合も同様です。
アクセス制限を掛けている場合もあります。
VPN接続やIPアドレス制限などアクセスできるかどうか確認します。
固定IPアドレスがない場合は、受託自体が不可という可能性もあり得ます。
また、ステージング環境まではファイルをベンダーがアップを許可して、本番公開は別のサーバー管理部隊が対応というケースもあります。
複数のベンダーで運用しているサイトは、所有権が異なる場合があります。
以下のようなフローとなります。
1．FTPで接続し、所有権の確認（制作ベンダー）
2．所有権が異なれば、変更依頼（制作ベンダー -> サーバー管理部隊 -> 制作ベンダー）
3．ステージング環境にファイルアップ（制作ベンダー）
4．クライアントへステージング環境の確認依頼（制作ベンダー -> クライアント -> 制作ベンダー）
5．本番環境へのファイルアップ依頼（制作ベンダー -> サーバー管理部隊 -> 制作ベンダー＆クライアント）
6．公開後の確認（制作ベンダー＆クライアント）
この場合、サーバー管理部隊へ作業依頼時に、クライアント担当から事前申請や署名が必要です。
FTPで接続する場合、ルートの設定をお願いした方が無難です。
ホームページのルート以上のアクセス権を頂いた場合、できるだけ制限を掛けてもらいます。
というのは、オペレーションミスやウイルス感染などによるアクシデント時の被害を絞るためです。
特に、アンケートフォームなど個人情報を取得するサイトでは、取得したデータへアクセスできないようにします。
システム運用を受託している場合でも、コンテンツ更新時とアカウントを分けましょう。
人為的ミスを発生させないのは、受託側の取り組みとして当然ですが、発生するという前提で、システム的な制限を掛けておくことがリスクヘッジになります。
CMSや更新ツールが導入されている場合は、更新手順を確認します。
編集できる範囲、公開権限、承認フローなど決められているはずなので、HTMLの専門知識がなくても対応出来る場合もあります。
CMSやサイトの特性によっては、編集エリアにHTML記述もあり得るので、受注前に管理画面や更新マニュアルを確認しておく必要があります。
CMSによっては、画像ファイルが一つずつしかアップできない場合があります。
画像を多用するサイトの場合、登録作業に想定以上の時間が掛かる場合があるので、FTPアップと併用が可能か、など相談をした方がよいかもしれません。
運用する上で、テストサイトは必要と思います。
テスト環境とステージング環境は厳密には異なると思いますが、クライアント都合によるので、定義は気にしないでよいと思います。
要は、本番サイトに影響しない確認用のサイトの位置づけです。
動作検証が伴う運用の場合は、壊れてもよいテスト環境（開発環境）、本番サイトと同じステージング環境、本番環境の３つが必要になります。
テスト環境、ステージング環境は、外部など第3者からアクセスできないように制限を掛けます。
一般的には、Basic認証で済むと思いますが、VPN接続やIPアドレス制限もあります。
SSLが含まれるサイトは、ステージング環境にもSSL対応した方がよいです。
特に、プログラムが絡む場合は必須です。非SSL環境で制作したスクリプトが動かない場合があります。
SSLから非SSLコンテンツを読み込む際アラートが表示されたります。
ブラウザの設定で回避できますが、不特定多数が利用するマーケティングサイトではアラート表示はマイナスイメージなので避けたいです。
イントラ向けのサイトでは、クライアントの社内端末のブラウザ設定変更が不可（プロパティが表示できない）の場合があります。
SSLを認識していても、実際にサイトアップするまで気付かないケースがあります（体験談。。。）
ステージング環境で確認しておいた方が安全です。
ただ、ステージング環境の管理者が通常クライアント側なので、ライセンスの問題等々で導入NGとなることがあります。
その際は、クライアントにリスクを了承して頂いた上で、ベンダー側で気をつけるしか手段がありません。
またはベンダー側の開発環境にてSSLを導入することもありますが、維持費が発生するので費用次第と思います。
一見、単純作業と思われ勝ちな運用業務でも気をつける点はたくさんあります。
作業者は、経験の浅い担当でも対応出来るかもしれませんが、品質管理ができる運用ディレクターか同等のポジションをこなす作業者が必須です。
そうでないと、クライアントとの関係性を持続させるのは難しいと思います。
受託範囲内では、如何に早く、正確に作業するかがポイントになるのですが、継続する内に次のステップが見えてくるはずです。
ノウハウが溜まってくると、管理主体が少しベンダー寄りになる場合があります。
それは、過去の実施内容について質問が来るようになったり、クライアントの指示ミスを訂正する機会があったり、様々なタイミングです。
そのような行為は、当事者は普通の感覚で気付かないと思うのですが、案件に深入りできるチャンスです。
担当の入れ替わりが激しかったり、新人教育やアルバイトの一環と捉えているベンダーであれば単純作業の受託範囲で満足かもしれません。
私だったら、案件を面白くしたいので、無用と言われても深入りしがちです。
この話は別の機会で。
次は「キャンペーンページなどページ制作」です。
またいつの日か。
知的好奇心を満たすには最適な仕事と言えるかもしれません。
まず、ひとくちにWebサイトといっても様々です。
受託なので、どういうクライアント、Webサイトと巡り会えるのか分かりません。
コーポレートサイト、マーケティングサイト、ECサイト、社内向けサイト、会員向けサイトなど目的によって考え方やアプローチが異なります。
プロモーション要素の強いスポット案件もあれば、継続的な運用が発生する案件もあります。
受託が生業の軸であれば、継続的な運用案件があると事業的には安定につながります。
運用の作業に追われてしまうと新規開拓ができず、それはまた不安定要素になります。
これは経営者としてはジレンマなのではないでしょうか。
幸い、私はディレクターとしての面白さを追求している立場なので、運用案件の魅力についてまとめてみようと思いました。
Web受託の運用案件にも様々あります。
・情報の更新が中心
・キャンペーンページなどページ制作
・バナーなどクリエイティブ作成
・システムの保守、管理が発生
・継続的なサイト改善を伴う
・コンテンツ企画を伴う
まず「運用の受託」というイメージがつきやすい「情報の更新が中心」から。
テキストやイラストの差し替えを代行する業務です。
コンテンツが多いサイト（ショッピングサイトや商品紹介がメインのサイト）が主な対象です。
クライアント側に運用担当、または窓口担当がいるけど、HTMLに詳しくなかったり画像を加工・作成するスキルがない、更新量が多くて内部で処理できない、などのケースが想定されます。
基本的にはクライアントから依頼があり、指示通りに進めます。
依頼内容が来ると、テストサイトやステージングサーバーに反映後、クライアント確認を経て本番公開、公開後のクライアント確認という流れが基本です。
更新手段として、CMSが導入されていたり、ファイル一式をFTPでアップなど案件により様々なルールがあります。
本番公開はクライアント側にて操作するパターンもあります。
開始前に、運用ルールの取り決めが重要です。
■作業フロー
依頼方法はメール、FAX、電話が主です。
依頼数が多い場合は、管理表や案件番号をつけてステータスをチェックします。
ステータス「完了」にするのを誰が行うか取り決めることは大事です。
ベンダー側の窓口（運用ディレクター）が「完了」と変更する場合でも、最終的にはクライアント側にも確認してもらう方がよいです。
双方で二重チェックをした方が漏れを軽減できるのが利点です。
また、トラブルが発生した場合、損害賠償問題になることがあります。
例えば、表示価格をミスして売れてしまった場合、「誰の責任か？」と言及されるケースが想定されます。
公開したベンダーの責任、と一方的に言われないようにリスクヘッジのためにも最終確認はクライアントにして頂くことが重要です。
ディレクターは、重要と思う修正（数値だったり、社長コメントだったり企業・団体にとって影響が強いと思われる情報）は、公開直後に確実にクライアント確認をとるべきです。
トラブルケースとして、完了メールを送っていたけどクライアントから返事がなく放置しておいたら被害が大きくなった、、、というのは私の体験談です。
電話で確認したり、直接窓口が不在の場合は、クライアントの別担当に確認を依頼したりと、確実に抑えておいた方がよいです。
特に、休日前日の夕方更新は気をつけましょう。
クライアントが帰ってしまって確認が取れず、そんな時に限って休日の朝に緊急修正依頼（社長がたまたまサイトをみて担当者に連絡など・・・）が来ます。
システム設定変更が絡むような更新は、金曜日は避けるというのも運用ルールの一つだと思います。
定期的な作業報告も必要です。
更新履歴は残しておいた方がよいのと、作業ボリュームの認識あわせが出来ます。
類似の作業が発生することがあります。
例えば、年次の数値変更や、季節モノなどが想定されます。
過去にどのような作業を行ったのか、すぐに確認できると、作業効率がアップしますし、クライアントからも重宝されます。
運用案件は、定期的に作業ボリュームを計測しておいた方がよいです。
1ヶ月で何ページだったのか、どのくらい時間が掛かったのか、何人くらい投入したのか、など分かるようにしておかないと、契約内容が適正だったのか判断できなくなります。
結果的に赤字だったり、クライアントから何となく高いと思われて、別のベンダーに打診されたり（打診を受けたベンダーはディスカウント提案するはず）、、、ということが発生されます。
計測する上で悩ましい課題があります。
作業スピードと品質は、作業者のスキルに依存する部分が多い、ということです。
「HTMLができる」という作業者でも、レベルはバラバラです。
ITスキルはあるが、ミスが多いというタイプもいます。
スキルがなくても、慣れてくると作業が早くなります。
そんな要因があるので、個人のスキルに左右されてしまうのは避けられない事実です。
そんな状況で、作業担当者の申告通りに、時間を積算しても、会社としてのレベルが低いと捉えられる可能性もあります。
ディレクターが品質をチェックして、適切な工数を判断する必要があると思います。
■制作ガイドライン
サイトを構築やリニューアルする際、制作ベンダーは制作ガイドラインを作成します。
HTMLコーディングルールや、スタイルシートの構成、デザイン的なトーン＆マナーなどのメニューで構成されます。
ディレクターおよび作業者は、内容を理解しておく必要があります。
クライアントが、自分のブランドを保持するために必要な要素なので、独断はNGです。
定期的に、制作ガイドラインをアップデートするクライアントもいるので、刷新された際には関係者に周知して必要に応じて意識あわせをやったほうがよいと思います。
制作ガイドラインは、社内の共有サーバーなど全員がアクセスできる場所に保管しておきます。
また、Web上に作成された制作ガイドラインもあるため、定期的なチェックも必要です。
トーン＆マナーに関して、運用前に確認が必要なのは、デザインが発生する可能性があるか？という点です。
タイトル文字や、訴求要素のバナー作成、営業所の地図作成など、内容によりデザイナーやイラストレーターが必要なケースもあります。
当初の契約には含まれてなくても、運用中に相談されることもあります。
依頼が来たときに慌てなくても良いように、体制かスキルの準備をやっておいた方がよいです。
都度外注になると、コストが読みづらくなります。
また、使用するフォントの確認が必要です。
持っていない場合は、購入するか、特殊フォントの場合はクライアントに提供依頼など行います。
通常、「モリサワ」の基本セットはあった方が便利です。
運用中、意外と迷うのはファイルの命名規則です。
英単語なのか、日本語のアルファベット表記なのか、連番なのか、等々決めておいた方が良いと思います。
あとファイルが増えていくと、ディレクトリー階層を見直す場合も発生します。
年次で分けたり、カテゴリー毎に分割したり、という感じです。
運用途中で問題視されることが多いと思いますが、SEO対策やファイル管理（リンク切れをなくすためリダイレクトさせるなど）上、好ましくないので最初に取り決めをしておいた方がよいと思います。
CMSが導入されていると、通常ルール化されているので気にしなくてもよいです。
■環境
テスト・ステージング環境、本番環境へのアクセス手段を確認します。
FTPで直接ファイルをアップする場合とCMSなど更新ツールが導入されている場合があります。
FTPでアップするには、HTMLの基礎知識が必要となります。
FTPでなくても、Windowsの共有フォルダにアップする場合も同様です。
アクセス制限を掛けている場合もあります。
VPN接続やIPアドレス制限などアクセスできるかどうか確認します。
固定IPアドレスがない場合は、受託自体が不可という可能性もあり得ます。
また、ステージング環境まではファイルをベンダーがアップを許可して、本番公開は別のサーバー管理部隊が対応というケースもあります。
複数のベンダーで運用しているサイトは、所有権が異なる場合があります。
以下のようなフローとなります。
1．FTPで接続し、所有権の確認（制作ベンダー）
2．所有権が異なれば、変更依頼（制作ベンダー -> サーバー管理部隊 -> 制作ベンダー）
3．ステージング環境にファイルアップ（制作ベンダー）
4．クライアントへステージング環境の確認依頼（制作ベンダー -> クライアント -> 制作ベンダー）
5．本番環境へのファイルアップ依頼（制作ベンダー -> サーバー管理部隊 -> 制作ベンダー＆クライアント）
6．公開後の確認（制作ベンダー＆クライアント）
この場合、サーバー管理部隊へ作業依頼時に、クライアント担当から事前申請や署名が必要です。
FTPで接続する場合、ルートの設定をお願いした方が無難です。
ホームページのルート以上のアクセス権を頂いた場合、できるだけ制限を掛けてもらいます。
というのは、オペレーションミスやウイルス感染などによるアクシデント時の被害を絞るためです。
特に、アンケートフォームなど個人情報を取得するサイトでは、取得したデータへアクセスできないようにします。
システム運用を受託している場合でも、コンテンツ更新時とアカウントを分けましょう。
人為的ミスを発生させないのは、受託側の取り組みとして当然ですが、発生するという前提で、システム的な制限を掛けておくことがリスクヘッジになります。
CMSや更新ツールが導入されている場合は、更新手順を確認します。
編集できる範囲、公開権限、承認フローなど決められているはずなので、HTMLの専門知識がなくても対応出来る場合もあります。
CMSやサイトの特性によっては、編集エリアにHTML記述もあり得るので、受注前に管理画面や更新マニュアルを確認しておく必要があります。
CMSによっては、画像ファイルが一つずつしかアップできない場合があります。
画像を多用するサイトの場合、登録作業に想定以上の時間が掛かる場合があるので、FTPアップと併用が可能か、など相談をした方がよいかもしれません。
運用する上で、テストサイトは必要と思います。
テスト環境とステージング環境は厳密には異なると思いますが、クライアント都合によるので、定義は気にしないでよいと思います。
要は、本番サイトに影響しない確認用のサイトの位置づけです。
動作検証が伴う運用の場合は、壊れてもよいテスト環境（開発環境）、本番サイトと同じステージング環境、本番環境の３つが必要になります。
テスト環境、ステージング環境は、外部など第3者からアクセスできないように制限を掛けます。
一般的には、Basic認証で済むと思いますが、VPN接続やIPアドレス制限もあります。
SSLが含まれるサイトは、ステージング環境にもSSL対応した方がよいです。
特に、プログラムが絡む場合は必須です。非SSL環境で制作したスクリプトが動かない場合があります。
SSLから非SSLコンテンツを読み込む際アラートが表示されたります。
ブラウザの設定で回避できますが、不特定多数が利用するマーケティングサイトではアラート表示はマイナスイメージなので避けたいです。
イントラ向けのサイトでは、クライアントの社内端末のブラウザ設定変更が不可（プロパティが表示できない）の場合があります。
SSLを認識していても、実際にサイトアップするまで気付かないケースがあります（体験談。。。）
ステージング環境で確認しておいた方が安全です。
ただ、ステージング環境の管理者が通常クライアント側なので、ライセンスの問題等々で導入NGとなることがあります。
その際は、クライアントにリスクを了承して頂いた上で、ベンダー側で気をつけるしか手段がありません。
またはベンダー側の開発環境にてSSLを導入することもありますが、維持費が発生するので費用次第と思います。
一見、単純作業と思われ勝ちな運用業務でも気をつける点はたくさんあります。
作業者は、経験の浅い担当でも対応出来るかもしれませんが、品質管理ができる運用ディレクターか同等のポジションをこなす作業者が必須です。
そうでないと、クライアントとの関係性を持続させるのは難しいと思います。
受託範囲内では、如何に早く、正確に作業するかがポイントになるのですが、継続する内に次のステップが見えてくるはずです。
ノウハウが溜まってくると、管理主体が少しベンダー寄りになる場合があります。
それは、過去の実施内容について質問が来るようになったり、クライアントの指示ミスを訂正する機会があったり、様々なタイミングです。
そのような行為は、当事者は普通の感覚で気付かないと思うのですが、案件に深入りできるチャンスです。
担当の入れ替わりが激しかったり、新人教育やアルバイトの一環と捉えているベンダーであれば単純作業の受託範囲で満足かもしれません。
私だったら、案件を面白くしたいので、無用と言われても深入りしがちです。
この話は別の機会で。
次は「キャンペーンページなどページ制作」です。
またいつの日か。
MacBook + Pocket Wifi での ワークスタイルの変化
MacBookを使い始めた時には、USBタイプのイーモバイルを使っていましたが、そのうちPocket Wifiが発売されました。
iPod Touch（初期型）を持っていた（音楽と写真メイン）ので、Pocket Wifiに切り替えました。
電池の減りが早いのと、起動してから繋がるまでの待つのが面倒、という点を除けば、とても気に入ってます。
一番の変化は、仕事の場所を選ばなくなりました。
事務所でなくても、仕事ができるようになったのは、私にとっては大きかったです。
考え事をしたいとき、事務所はノイズが多く非効率的です。
かといって、運用を受託していると即時対応が多かったりするので、メールは常時チェックする必要があります。
仕方なく、事務所にいて集中力を欠きながら仕事するより、好きなところ（電源がある、電波の圏内という制約はあるものの）で作業が出来るというのは、解放された気分です。
いろいろ試したくなって、極力事務所から離れて仕事ができるか、と工夫をしてみました。
時間を掛けて少しずつ調整をしてみて、外のカフェでも結構対応できることが分かりました。
移動中は、iPod Touch + Pocket Wifiでメールチェックができるし、GmailでIMAPを使えば、メールの重複閲覧が軽減できるし、場所やデバイスを選ばなくなる方向は今後も進みそうです。
携帯電話をつかう量は増えたものの、Skypeで対応できる事も多いです。
iPod touchの新型
を買えば、Skypeの音声通話やFaceTimeなど強力なコミュニケーションツールだと思います。
私は、どちらかというと顔を合わせてないと落ち着かないタイプでしたが、インターネットの仕事に携わっているので、何かと経験したおいた方がメリットデメリットが分かるし、今後ますますロケーションは関係ない流れが強くなりそうなので、いまのうちからワークスタイルを確立しておこうと思っています。
あとはバッテリー対策かなあ・・・
ちなみによくチェックするサイトは以下です。
・電源検索サイト [HACK CAFE]
・電源が使える喫茶店
・モバイラーズオアシス
iPod Touch（初期型）を持っていた（音楽と写真メイン）ので、Pocket Wifiに切り替えました。
電池の減りが早いのと、起動してから繋がるまでの待つのが面倒、という点を除けば、とても気に入ってます。
一番の変化は、仕事の場所を選ばなくなりました。
事務所でなくても、仕事ができるようになったのは、私にとっては大きかったです。
考え事をしたいとき、事務所はノイズが多く非効率的です。
かといって、運用を受託していると即時対応が多かったりするので、メールは常時チェックする必要があります。
仕方なく、事務所にいて集中力を欠きながら仕事するより、好きなところ（電源がある、電波の圏内という制約はあるものの）で作業が出来るというのは、解放された気分です。
いろいろ試したくなって、極力事務所から離れて仕事ができるか、と工夫をしてみました。
時間を掛けて少しずつ調整をしてみて、外のカフェでも結構対応できることが分かりました。
移動中は、iPod Touch + Pocket Wifiでメールチェックができるし、GmailでIMAPを使えば、メールの重複閲覧が軽減できるし、場所やデバイスを選ばなくなる方向は今後も進みそうです。
携帯電話をつかう量は増えたものの、Skypeで対応できる事も多いです。
iPod touchの新型
を買えば、Skypeの音声通話やFaceTimeなど強力なコミュニケーションツールだと思います。私は、どちらかというと顔を合わせてないと落ち着かないタイプでしたが、インターネットの仕事に携わっているので、何かと経験したおいた方がメリットデメリットが分かるし、今後ますますロケーションは関係ない流れが強くなりそうなので、いまのうちからワークスタイルを確立しておこうと思っています。
あとはバッテリー対策かなあ・・・
ちなみによくチェックするサイトは以下です。
・電源検索サイト [HACK CAFE]
・電源が使える喫茶店
・モバイラーズオアシス
MacBookを使い始めて一年半になります。
学生の時に、Macintosh LC475の中古を購入したのが、Macとのつきあいはじめになります。
社会人になって、Power Macintosh（型番は失念）を買いましたが、職場ではWindowsメインだったので、あまり使ってませんでした。
Web制作の仕事を始めてから、Macの興味が戻ってきて、自宅用にMac Mini（Tigerの発売日！）を購入したのですが、iTunesマシンとしてしか使ってなくて、業務はWindows主体でした。
デザインだからMacでは？とか思っていたのですが、ディレクターの仕事では打合せ資料、議事録や要件定義書などのドキュメントは、ファイルをクライアントとやりとりすることが多く（最終納品物はPDFなどですが、議事録の赤入れなどファイル編集が発生するので）、レイアウトが崩れるとNGでしたので、WindowsのOfficeが必要でした。
以前は、打合せにはPCは持参せず、紙に出力することが多かったです。
打合せをしながら、メモしたり、イメージを手書きで確認する際は、紙資料が便利です。
最近は、PCで対応出来るところは極力印刷しないようにしていますが、クライアントが好む場合は紙資料を使います。
ホワイトボードに書くこともありますが、さっくりイメージを共有したい場合もあるので、手元にスケッチブックを用意しています。
Macに話を戻します。
Intel Macが発売されて、WindowsもBootCampで使えるようになりました。
また、MacBookのアルミボディーのプロダクトとしての美しさは衝撃的でした。
ちょうど大阪での案件が始まったので、MacBookを購入しました。（自費ではなく会社の経費です・・・）
VMware + Windows VISTA + Office 2007もセットです。
極力、Mac OSを使って、Officeが必要なときはWindowsにしています。
4Gのメモリでは、VMwareを立ち上げるとギリギリです。
最初は慣れなくてイライラしました。
OfficeもXPを使っていたのが、2007でインターフェイスが違うし、キーボードのタイピングも違うので、作業がはかどらなかったのですが、徐々に慣れてから快適になりました。
Windows 7は自費で購入して、BootCampを入れ替えました。
そこで気付いたのが、VMwareを使えば、検証環境が楽になるということでした。
Web制作の際、ブラウザチェックは必須です。
Internet Explorer6,7,8で見た目違いますし、FirefoxでもOSにより異なる場合があります。
なので、いろんなマシンでチェックするのですが、他人が使っている端末を借りたりしていたので、面倒だなあと思ってました。
使わなくなったWindows XPマシンがあったのでVMwareにインポートして、Mac OS X、Win XP + IE6、Win Vista + IE7、Win 7 + IE8という環境を自分の端末に構築できました。
メモリの都合上、2つ同時に起動できないのが残念ですが、自分の端末で概ねチェックができるようになったのは快適でした。
ある案件で、Windows Me + IE6 SP2でのみJavaScriptに不具合が発生するケースがあって、知り合いをあたって実機を借りた以外は、自分のMac Bookで対応出来てます。
あとノートパソコンをメインマシンとして業務をすることになって、ワークスタイルが変わってきました。
この話は別の機会で。
ここ最近、iPhoneやiPadなどAppleの話題が多いので、Macユーザーとしてはとても嬉しいです。
まったくWin端末には興味がなくなり、できるだけMacで業務が完結できるように試行錯誤しています。
社会人になって、Power Macintosh（型番は失念）を買いましたが、職場ではWindowsメインだったので、あまり使ってませんでした。
Web制作の仕事を始めてから、Macの興味が戻ってきて、自宅用にMac Mini（Tigerの発売日！）を購入したのですが、iTunesマシンとしてしか使ってなくて、業務はWindows主体でした。
デザインだからMacでは？とか思っていたのですが、ディレクターの仕事では打合せ資料、議事録や要件定義書などのドキュメントは、ファイルをクライアントとやりとりすることが多く（最終納品物はPDFなどですが、議事録の赤入れなどファイル編集が発生するので）、レイアウトが崩れるとNGでしたので、WindowsのOfficeが必要でした。
以前は、打合せにはPCは持参せず、紙に出力することが多かったです。
打合せをしながら、メモしたり、イメージを手書きで確認する際は、紙資料が便利です。
最近は、PCで対応出来るところは極力印刷しないようにしていますが、クライアントが好む場合は紙資料を使います。
ホワイトボードに書くこともありますが、さっくりイメージを共有したい場合もあるので、手元にスケッチブックを用意しています。
Macに話を戻します。
Intel Macが発売されて、WindowsもBootCampで使えるようになりました。
また、MacBookのアルミボディーのプロダクトとしての美しさは衝撃的でした。
ちょうど大阪での案件が始まったので、MacBookを購入しました。（自費ではなく会社の経費です・・・）
VMware + Windows VISTA + Office 2007もセットです。
極力、Mac OSを使って、Officeが必要なときはWindowsにしています。
4Gのメモリでは、VMwareを立ち上げるとギリギリです。
最初は慣れなくてイライラしました。
OfficeもXPを使っていたのが、2007でインターフェイスが違うし、キーボードのタイピングも違うので、作業がはかどらなかったのですが、徐々に慣れてから快適になりました。
Windows 7は自費で購入して、BootCampを入れ替えました。
そこで気付いたのが、VMwareを使えば、検証環境が楽になるということでした。
Web制作の際、ブラウザチェックは必須です。
Internet Explorer6,7,8で見た目違いますし、FirefoxでもOSにより異なる場合があります。
なので、いろんなマシンでチェックするのですが、他人が使っている端末を借りたりしていたので、面倒だなあと思ってました。
使わなくなったWindows XPマシンがあったのでVMwareにインポートして、Mac OS X、Win XP + IE6、Win Vista + IE7、Win 7 + IE8という環境を自分の端末に構築できました。
メモリの都合上、2つ同時に起動できないのが残念ですが、自分の端末で概ねチェックができるようになったのは快適でした。
ある案件で、Windows Me + IE6 SP2でのみJavaScriptに不具合が発生するケースがあって、知り合いをあたって実機を借りた以外は、自分のMac Bookで対応出来てます。
あとノートパソコンをメインマシンとして業務をすることになって、ワークスタイルが変わってきました。
この話は別の機会で。
ここ最近、iPhoneやiPadなどAppleの話題が多いので、Macユーザーとしてはとても嬉しいです。
まったくWin端末には興味がなくなり、できるだけMacで業務が完結できるように試行錯誤しています。
議事録係からプロジェクトマネージャーに昇進
前記事から続きます。
プロモーション用のFlashコンテンツは、制作が進み出すと私の役割は一旦落ち着き、 制作チームにお任せ状態でした。
「これ、どう？」と聞かれてても、的確な指示を出せる訳ではなかったので、進捗確認とクライアントへの報告以外にやれることがなかったです。
いまなら、クライアントの要望や状況を加味して、何かしらの判断をするのですが、当時は逆に「分からないので聞かないで～」という心境でした（笑）
ただ制作現場がいることは刺激的で楽しかったです。
アーティストのマネージャー時代も、レコーディングスタジオとかやることがない（ケータリングくらい）けど、制作の現場は楽しかったのと同じ感覚でした。
もう一つのサービス説明コンテンツの制作は、クライアントから提供される素材をページデザインに反映する作業でしたが、ある程度、形が見えた段階から難航しました。
私の仕事は、提供素材の確認、制作ページの進捗管理が主で、提供素材や修正指示が正しく反映されているか、デザイン・コーディングそれぞれチェックすることでした。
最終判断は、クライアント上層部で権威のある方が行うのですが、なかなかOKが出ません。
デザインの細部から、文言に至るまで何度もやり直しが発生しました。
リリースするサービスを理解してもらうためには表現に妥協しない、という姿勢は当然で、大きな規模のプロジェクトなので、大変なのはWeb制作に限らないと思います。
プロジェクトの体制上、最終決定者に至るまでに、いくつも通過します。
それも当たり前なのですが、制作会社は末端に位置づけられるので、制作を取り仕切るエージェントの窓口から先の状況が見えないのが困りました。
どこまで了解が取れているのか、さっぱり分かりません。
エージェントの窓口、その上司・関係者、クライアントの窓口、その上司・関係者、クライアントの最終決定者と何段階もあると、誰の意見なのか分からないまま、制作会社は指示を受けることになります。
仕組みがわかるまでは、「なんでこんなに指示がブレるんだろう・・・」と思ってましたが、やっていくうちに決定プロセスの壁が見えてきました。
見えてきたところで、その段階では手の打ちようがなかったので、とにかくコミュニケーションをとって、先方のノリを掴むしかなかったです。
そこでやっぱり大事だと思ったのは、コトバによる説明でした。
周囲や上に向かって、しっかりと意図や考えを伝えてくれると、フィードバックの内容も読めるようになってきます。
なので、途中からクリエーターに事前にポイントを聞いておいて、「このデザインは、実はこういうことなんですよ」と話をするようにしました。
だけど、トップダウンの指示は断れないジレンマはありました。
上部の何気ない一言（もしかして迷いや思いつきも含んでいるかも）が、調整の余地がなく、指示として落ちてくるためです。
背景や意図を説明しても、ボトムアップで調整ができる状況ではなかったので、「神の声」として処理するしかなかったです。
当然、ディレクターは制作サイドとクライアント（エージェント含む）との板挟みになります。
どうやってその場を乗り切るのかは、コミュニケーションスキルかなと思っています。
クライアントの指示だから、と制作サイドに「通達」するのは簡単です。
ただ、制作サイドのモチベーションが下がるとプロジェクトはうまくいきません。それはアーティストのマネージャー時代に経験していたので避けたかったです。
できるだけ話し合いをしました。
クライアント側の意図を確認して、どういう背景で発生した指示なのか、制作サイドに伝えるようにしました。
最後は時間との戦いになるので、割り切って指示通りに進める事になりましたが、話し合いが出来たのは後々の関係性の構築に役に立ったと思います。
そんなこんなしているうちに、プロジェクトの中心部にいることは実感してました。
「ただ納期までに間に合わせるには何が必要か？！」を考えて動いていたのですが、全体の状況を把握しているのは自分なので、判断を求められることが増えてきました。
自分では判断できなくて、各担当の状況を集約して調整、の繰り返しだったのですが、公開日が近づいたあるとき、制作エージェントから「で、リリースどうするの？」と聞かれてしまいました。
その質問には「は？」とビックリしました。
リリース可否の判断は、私ではないと思っていたからです。
私は制作会社の人間なので、エージェントとクライアントが判断するべきでしょう、とも言えず、制作サイドのトップに相談しました。
それまではクライアントの打合せ参加は私だけだった（移動時間がもったいないので制作チームは動けない）のですが、納品や検収に関する重要事項だったので、同席してもらいました。
公開に関する打合せ後、帰り道に制作トップに言われたのは、
「君、プロジェクトマネージャーになってるよ（笑）」でした。
正確には「プロジェクトマネージャーとしての立ち振る舞いを勝手に押し付けられてる」でしたが。
そんな意識が全くなかったので、何をすべきか「？」でした。
が、公開も間もないので出来ることも少なく、チェックや公開手順の段取りを調整して、皆さんに周知、伝わっているか念を入れて確認することで、PMとして求められた雰囲気を醸し出してみました。
そのプロジェクトは、期日に公開できました。
公開したときには嬉しかったですが、なぜかあまり感動しませんでした。
乗り切った安堵感はありましたが、どこか他人事のような感覚でした。
1ヶ月ちょっと前は、議事録係だったはずなので、大出世（？）した怒濤の1ヶ月だったと思います。
恐ろしいことに、公開直前まで、最終決定者（海外出張か何かで確認できないだったと思う）の承認がとれてなくて、大どんでん返し（大修正）があるかも、と脅されてました。
あとになって分かってきたことですが、クライアント窓口や間にいるエージェントの担当者は、万が一失敗したときの責任回避として、制作ベンダー側に責任転嫁をすることがあるようです。
制作会社の私がPM的な役割をさせられたのも、リスクヘッジの一環だったのかもしれません。
私のWebディレクター2作目は、こんな感じでした。
プロモーション用のFlashコンテンツは、制作が進み出すと私の役割は一旦落ち着き、 制作チームにお任せ状態でした。
「これ、どう？」と聞かれてても、的確な指示を出せる訳ではなかったので、進捗確認とクライアントへの報告以外にやれることがなかったです。
いまなら、クライアントの要望や状況を加味して、何かしらの判断をするのですが、当時は逆に「分からないので聞かないで～」という心境でした（笑）
ただ制作現場がいることは刺激的で楽しかったです。
アーティストのマネージャー時代も、レコーディングスタジオとかやることがない（ケータリングくらい）けど、制作の現場は楽しかったのと同じ感覚でした。
もう一つのサービス説明コンテンツの制作は、クライアントから提供される素材をページデザインに反映する作業でしたが、ある程度、形が見えた段階から難航しました。
私の仕事は、提供素材の確認、制作ページの進捗管理が主で、提供素材や修正指示が正しく反映されているか、デザイン・コーディングそれぞれチェックすることでした。
最終判断は、クライアント上層部で権威のある方が行うのですが、なかなかOKが出ません。
デザインの細部から、文言に至るまで何度もやり直しが発生しました。
リリースするサービスを理解してもらうためには表現に妥協しない、という姿勢は当然で、大きな規模のプロジェクトなので、大変なのはWeb制作に限らないと思います。
プロジェクトの体制上、最終決定者に至るまでに、いくつも通過します。
それも当たり前なのですが、制作会社は末端に位置づけられるので、制作を取り仕切るエージェントの窓口から先の状況が見えないのが困りました。
どこまで了解が取れているのか、さっぱり分かりません。
エージェントの窓口、その上司・関係者、クライアントの窓口、その上司・関係者、クライアントの最終決定者と何段階もあると、誰の意見なのか分からないまま、制作会社は指示を受けることになります。
仕組みがわかるまでは、「なんでこんなに指示がブレるんだろう・・・」と思ってましたが、やっていくうちに決定プロセスの壁が見えてきました。
見えてきたところで、その段階では手の打ちようがなかったので、とにかくコミュニケーションをとって、先方のノリを掴むしかなかったです。
そこでやっぱり大事だと思ったのは、コトバによる説明でした。
周囲や上に向かって、しっかりと意図や考えを伝えてくれると、フィードバックの内容も読めるようになってきます。
なので、途中からクリエーターに事前にポイントを聞いておいて、「このデザインは、実はこういうことなんですよ」と話をするようにしました。
だけど、トップダウンの指示は断れないジレンマはありました。
上部の何気ない一言（もしかして迷いや思いつきも含んでいるかも）が、調整の余地がなく、指示として落ちてくるためです。
背景や意図を説明しても、ボトムアップで調整ができる状況ではなかったので、「神の声」として処理するしかなかったです。
当然、ディレクターは制作サイドとクライアント（エージェント含む）との板挟みになります。
どうやってその場を乗り切るのかは、コミュニケーションスキルかなと思っています。
クライアントの指示だから、と制作サイドに「通達」するのは簡単です。
ただ、制作サイドのモチベーションが下がるとプロジェクトはうまくいきません。それはアーティストのマネージャー時代に経験していたので避けたかったです。
できるだけ話し合いをしました。
クライアント側の意図を確認して、どういう背景で発生した指示なのか、制作サイドに伝えるようにしました。
最後は時間との戦いになるので、割り切って指示通りに進める事になりましたが、話し合いが出来たのは後々の関係性の構築に役に立ったと思います。
そんなこんなしているうちに、プロジェクトの中心部にいることは実感してました。
「ただ納期までに間に合わせるには何が必要か？！」を考えて動いていたのですが、全体の状況を把握しているのは自分なので、判断を求められることが増えてきました。
自分では判断できなくて、各担当の状況を集約して調整、の繰り返しだったのですが、公開日が近づいたあるとき、制作エージェントから「で、リリースどうするの？」と聞かれてしまいました。
その質問には「は？」とビックリしました。
リリース可否の判断は、私ではないと思っていたからです。
私は制作会社の人間なので、エージェントとクライアントが判断するべきでしょう、とも言えず、制作サイドのトップに相談しました。
それまではクライアントの打合せ参加は私だけだった（移動時間がもったいないので制作チームは動けない）のですが、納品や検収に関する重要事項だったので、同席してもらいました。
公開に関する打合せ後、帰り道に制作トップに言われたのは、
「君、プロジェクトマネージャーになってるよ（笑）」でした。
正確には「プロジェクトマネージャーとしての立ち振る舞いを勝手に押し付けられてる」でしたが。
そんな意識が全くなかったので、何をすべきか「？」でした。
が、公開も間もないので出来ることも少なく、チェックや公開手順の段取りを調整して、皆さんに周知、伝わっているか念を入れて確認することで、PMとして求められた雰囲気を醸し出してみました。
そのプロジェクトは、期日に公開できました。
公開したときには嬉しかったですが、なぜかあまり感動しませんでした。
乗り切った安堵感はありましたが、どこか他人事のような感覚でした。
1ヶ月ちょっと前は、議事録係だったはずなので、大出世（？）した怒濤の1ヶ月だったと思います。
恐ろしいことに、公開直前まで、最終決定者（海外出張か何かで確認できないだったと思う）の承認がとれてなくて、大どんでん返し（大修正）があるかも、と脅されてました。
あとになって分かってきたことですが、クライアント窓口や間にいるエージェントの担当者は、万が一失敗したときの責任回避として、制作ベンダー側に責任転嫁をすることがあるようです。
制作会社の私がPM的な役割をさせられたのも、リスクヘッジの一環だったのかもしれません。
私のWebディレクター2作目は、こんな感じでした。