これまで様々な案件に携わってきましたが、その中でもダントツで辛かったのが、10年くらい前に前職で担当した大手通販会社のWebサイト運用です。
案件の概要
この案件は大手通販会社の公式サイト兼プロモーションサイトを毎週2回更新するというもので、当初はサイトのトップページだけだけど、慣れてきたらトップ以外の商品の特集ページとかメルマガの作成なんかもあるよっていう感じでした。
弊社に割り振られる予算規模は毎月最低でも150万円以上で、作業が増えてきたら更に増えるという話でした。前職の会社は地方だったこともあり、この金額は社内では最大規模の予算でした。
運用体制
この案件は通販会社（X社）と直接契約している大手コンサルティング会社（A社）がおり、その下請けとして広告代理店（B社）がいて、私のいた会社はさらにその下請けという立場で、つまりは孫請けでした。
案件開始前にA社と顔合わせ的なことは行いましたが、我々への具体的な作業の依頼や指示は、基本的にB社が行うというものでした。
元々別のシステム会社：C社が通販会社のECサイトの開発を行っていて、同社がWebサイトの運用も担当していました。しかしC社のキャパシティが足りなくなってレスポンスが悪くなったということで、Webサイトの運用部分だけ、別の会社に移行することになったという経緯でうちに行き着いたのでした。
孫受けの弊社でも毎月の予算が150万円だったので、全体予算はおそらく少なく見積もっても800万円〜1000万円程度はあったのではないかと思います。
運用開始前から感じる不穏な空気
そんなX社の運用案件は、開始前から雲行きが怪しいものでした。
案件が決まったのが9月頃で、実際の運用が始まるのが12月の予定でした。
我々が担当するにあたり、Webサイトの仕様や作業方法についてC社から引き継ぎのための説明会が行われたのち、プレ運用的なことをしながら我々に完全移行するというのが当初話で聞いていた段取りでした。
が、案件が決まった直後くらいにエクセルで作られた過去の指示書だとか、本当に簡易的な手順書などを受領したものの、肝心の説明会が行われる気配はなく、いよいよ運用開始直前となりB社やA社からC社を突っついてもなしのつぶてという状態でした。
あとから分かったことですが、C社はリソースが危機的に足りていない状態に陥っており、さらにクライアントのX社の担当者も激務すぎて、引き継ぎを行える状態ではなかったそうです。
完全に向こうの都合なわけですが「引き継ぎをしないならやっぱ受けない」ということにはならず（できず）、結局引き継ぎらしい引き継ぎをしないままなし崩し的に運用が開始することになります。
まぁこの業界だと意外とある話だと思います。
ものすごくアナログな運用
我々が運用を行うWebサイトは、主に新商品や売出し中の商品のプロモーションを掲載して、X社のECサイトの各商品ページへ誘導するというのが主な目的でした。
X社は割とイケイケドンドンな会社だったので、始まる前はどんなすごい運用なのかなーとワクワクしていたところもあったのですが、実際には極めてアナログ的で非効率な運用ばかりでした。
まず作業指示書は方眼紙状のエクセルファイルでした。この時点で嫌な予感がしました。当時すでにGoogleスプレッドシートは存在していましたが、そんなもの利用することはなく、作業指示書ファイルはメールに添付されて送られてきました。
指示書には更新する場所や、設置する画像、テキスト原稿などが記載されていますが、指示ミスや表記ゆれが多く、全く当てにはできない代物でした。なので、指示書を受け取ったら最初にじっくり読み込んで気になる点があったら確認するという作業が必要でした。
また、とりあえず一通りの更新ができたら一旦B社を通してX社に報告をするのですが、毎回必ず報告書をエクセルで作成し、しかも報告書には制作したWebページの画面キャプチャの添付が必須でした。これが1〜2回で済めばまだ良かったのですが、なんやかんやで4〜5回は変更作業が発生するので、とてもストレスの貯まる作業でした。
後に運用を続けていくに従って作業自体は徐々に効率化できたのですが、この画面キャプチャだけは最後まで我々の足を引っ張っることになりました。
面倒すぎる修正と確認作業
当然のことながら実作業も大変でした。
我々は行う作業は基本的にHTMLやCSSの調整、画像の差し替えなどがメインだったので、正直なところ引き継ぎはなくともソースコードを見れば、なんとなく対応できるレベルではありました。
しかし、このWebサイトはJSPというサーバー言語で構築されており、ソースコードはHTMLとJSPが入り混じった状態でした。そのため不用意に修正してしまうとWebページが表示さなくなることもあるため、慎重にコードを解読しながら作業する必要がありました。
またセキュリティを理由に詳細なサーバー情報を開示してくれなかったので、動作検証をするための環境をローカルに構築することができませんでした。実はC社に開発環境を用意してもらうはずでしたが、結局これも用意されることはありませんでした。
さすがにいきなり本番反映というわけではなく、ステージング環境は用意されていたので、そこで表示の確認をする形でした。
しかしステージング環境にファイルをアップロードする権限はB社にしか与えられなかったため（A社も権限を持っていたが作業しないから意味はなかった）、いちいち我々が更新したコンテンツの差分ファイルだけをZIP化してB社に送付し、B社に反映してもらってからブラウザで表示確認するという作業を繰り返す必要がありました。
しかもステージング環境にアップロードしても、反映されるまでに5〜10分くらいのタイムラグがあるため、表示確認や動作検証は非常に時間がかかりました。
このWebサイト運用で更新するページはPC向けとスマートフォン向けの2ページで、少なくとも週2回更新が発生し、それらをまとめて納品する必要がありました。
初回は2回分の更新の計4ページだけだったので、ページ数的には大したことはありませんでいたが、1ページあたりのボリュームがまぁまぁあったのでそれなりに時間はかかりました。
そして、ほぼ引き継ぎ無しでソースコードを慎重に調べながら作業を行い、更新作業を行うたびにいちいち差分ファイルを作成して、B社にステージング環境への反映を依頼し、反映されるまで待機して、反映したら表示確認して、間違っていたら再度修正・・・というのを繰り返すという地獄のようなループを繰り返しました。
ステージング環境をX社に確認いただいて問題無しとなってから、ようやく本番環境に反映となります。
ステージング環境への反映と同じく、我々が納品用のZIPファイルを作成しB社に送付し、それをB社が本番環境の予約投稿領域にアップロードするという流れでした。
しかし予約投稿領域には我々以外の会社もアクセスしており、さらに同時にアクセスできないことから、予約投稿のための予約が必要でした。
予約の手続きはB社がやってくれるので、我々にできることはなにもないのですが、なんとなく立場上、予約投稿が完了するのを見届けないといけないみたいな雰囲気だったので、待機する必要がありました。これも地味に辛かったな・・・。
これは長い地獄の始まり
結局初回の運用を開始してから最初の一週間はほぼ毎日深夜1時〜2時過ぎまで作業するはめになりました。
しかしこれは地獄の始まりに過ぎませんでした。
納品が完了したらすぐさま翌週の更新作業が始まるわけで、この地獄のようなループが、このあと5年も続くことになります。
また最初はトップページだけの更新でしたが、後に特集ページの作成やメールマガジンの運用などさらなる困難が待ち受けることになります。
それらの話はまた機会があれば・・・・。