Webサイトの「モブ公開作業」のすすめ

今回は、Webサイトの公開作業を、安心して効率的に行うアイデアのお話です。

働く組織や場所を超えて、プロジェクトメンバーがZoom会議に全員集合。みんなで作業内容を確認し、公開作業を実施。問題が発生したらその場で方針を決めて、即対応するという、私が勝手に「モブ公開作業」と呼んでいるやり方について書いてみます（モブ＝集団で何かをすること）。

私もまだ2回しか経験していないので、ヒントとしてご覧ください。

昔の公開作業はやきもきする時間が長かった？

Webサイトが完成したら、いよいよ公開作業。公開作業のメンバーは、発注側の担当者たち、制作会社のディレクターやコーダー、場合によってはサーバー管理者もといったところでしょうか。

公開時にトラブルが発生した場合のコミュニケーション方法は、以前、私が制作会社のディレクターだった時だと、メールでコミュニケーションしたり、急ぎであれば電話で会話していました。

10年前にサイボウズに入ってWeb制作の発注側になってからは、メールがグループウェアに変わったものの、基本は同じです。どんなに事前にテストをし、計画をたてても想定外のトラブルが発生することがあるのも同様です。

トラブル対応のよくある風景

トラブル発生！即対応を制作会社に依頼。でも、発注者からすると、連絡した後に制作会社でどんな作業が行われているかは想像するしかありません。思ったより対応に時間がかかると、やきもきするわけです。。

夜、おなかを空かせながら「対応できたかな、まだかな、まだかな」と、ブラウザの更新ボタンを連打。そうしているうちに誰かが「あ、更新されてます！」と声をあげ、確認を開始。しばらくすると制作会社さんから更新したと連絡があり「はい、更新されてるのを見ました！いま確認してます」なんて返事をしたりして。

でも、確認したらまだ問題が残っていて、再度修正の連絡を依頼することも。その後「それ、ブラウザのキャッシュではないですよね？」「いえ、ちゃんと消したはずです」なんてメールをやり取りする間、また待つわけです。「これは長期戦だな」と覚悟決めて夜食を食べながら。

いま考えたら社内の関係者とのやりとりも大変だった気が。チャットでは状況がよくわからない時「いまどんな感じですか？」なんて状況を聞きにいったり。オフィスが広いので遠くの席までダッシュ。近くの席のメンバーにも、制作会社さんから聞いたことを口頭で言い直したり。

さんざんお互いに待って待たせ、焦ってやきもきした分、完了した時の喜びはひとしお！おつかれさま！

でも、ぐったりです・・・。

日本橋オフィスからの夜景。美しいのですけどねー。

そこで「モブ公開作業」を始めたわけです。

そんな負担がかかる方法は避けたい！今はもうリモートワークが基本ですし。そこで新しい公開手順についてWebチームで議論して、昨年くらいから始めたのが「モブ公開作業」です。

公開に携わるプロジェクトメンバー、具体的には自社、制作会社、サーバ管理を委託している会社のメンバーが、Zoom会議に全員集合。みんなでその日の作業内容を確認し、Zoomに繋ぎながら公開作業を実施。問題が発生したらそこで方針を決めて、即対応するというものです。

問題とまではいかなくても「予想よりデータが重い。時間がかかる」みたいな予定通りいかないこともあります。でもモブ公開なら、作業担当者がいまから何々をします、どんな状況です、と話しながらリアルタイムで作業を実施できるので、待っているメンバーはやきもきが軽減できるのです。

メリット、デメリット

まずメリット。作業を全員でリアルタイムで共有しやすいので安心して進められることや、判断から行動までが速いことです。

これまで、サーバ管理を委託しているパートナー会社さんに２回ほどモブ公開作業をお願いしましたが、作業中に名調子で技術的な解説までしていただいちゃったりして、安心を超えて楽しかったりしました。でも、これはその会社の標準サービスというより、担当者の方の個人の特色で特殊なケースかもしれません^^

あとは、うまくいったら制作会社さん含め、全員で「やったね！」と一緒に喜べることですかね。

デメリットは、作業される方が集中しにくいことがありそうなのと、拘束される方が多いことです。

デメリットの「拘束される方が多い」を解消するための試行錯誤

メンバーを減らしたり、途中で解放したり

あるプロジェクトで、公開作業に直接関係がないメンバーについては遠慮をしてZoomに呼ばなかったのですが、トラブルがあったときに対応が少し遅くなりました。

問題が発生するまではビデオと音声をオフのままでもいいので、極力参加してもらうようにしたほうがよいと思います。また、拘束し過ぎないように状況に応じて一部メンバーを途中で解放しました。ただ、その判断に難しさを感じています。後からやっぱり参加して欲しくなったら？？そこは今後の課題です。

実施の前提は心理的安全性？

参加メンバー間で信頼関係や、心理的安全性がある程度確保できていて意見を出しあえることが実施の前提になりそうです。立場がつよい人がそうでない方を詰めるような場になってしまったら、問題が発生したときに正直にそれを言えなくなってしまいます。萎縮してミスしたりしてモブを進めにくくなるし、リアルタイムな苦痛だし、最悪ですね。

長期的によいWebサイトを保持するためには発注者と制作会社間の信頼関係は大事なので、トラブルがあっても一緒に対応し、たとえうまくいかなかったとしても先につながる適切なコミュニケーションをしていきたいものです。

準備をしっかり

心理的安全性といっても、とんでもないトラブルが起きたら誰だって冷静でいるのは難しくなるはず。トラブル発生をできるだけ予防したり、発生しても対応できるように、公開手順と本番でのテスト項目は検討しておきたいです。これはモブ公開に限った話ではないですね。

公開手順書やテストシートを作成する際、私の場合はプロジェクトの規模に応じて、エクセルで作るときもあれば、メモ書き程度で準備したりしています。

2016年、企業サイトリニューアル時の公開手順書。エクセルに誰が何をいつやるのかを記載

公開数日前のタスクから書きはじめ、忘れがちな公開後の納品や、社内の告知（しっかりアピール）まで書くこともあります。プロジェクトのスケジュール表とは「別に」作っていまして、その理由は、細かい時間刻みで書きたいのと、ツールとして使いやすくするためです。

上記の表を見て2016年当時は、公開作業を18時から20時に実施していたことを思い出しました。最近はだれも残業しないで済むことを重視して、18時前に終わらせるように実施することが多いです。

そういえば、前回の公開作業で集まった時かな。参加者が自社含め4社で、それが初めてお話する機会だった関係者もいたのに、私がうまくファシリテートできなくて、あわわわ、もごもご、している間に他の方が自己紹介を始めてくださったり。恥ずかしい…。そのあたりも、想定したり心の準備もしておかないとでした。

最後に、モブ公開のはじめ方

関係者にお声がけして了承いただき、Zoom URLを発行するだけです！簡単ですよね。この方法がプロジェクトの進め方にあっていそうでしたら、ぜひ試してみてください。