今日は「公開」というタスクについて考えてみたいと思います。
いろいろなプロジェクトの工程を経て、ようやく公開にこぎつけました。
長かった道のりもこの日で終わり。大変だったプロジェクトから、今日限りで解放されるわけです。
長かった道のりもこの日で終わり。大変だったプロジェクトから、今日限りで解放されるわけです。
という心境で、いざ公開を進めてみると予期せぬ問題が！
その対応に追われて、てんやわんや。
その対応に追われて、てんやわんや。
結局、公開前に描いていた「解放」は、遠のきました。
あなたはまだまだプロジェクトの火中にいます。
むしろ、公開失敗してトラブルになり、炎の中にいるのかもしれません。
# ネガティブな書き方ですが、本来プロジェクトは楽しいものです。
「ウェブページなんて、アップロードするだけじゃん」と思ったあなた、危ないですよ。
公開失敗は誰にでも起きる
公開失敗は、なぜ起きるのでしょうか。
- 公開作業中に何か間違えてしまった。
- 公開しようと思ったら、予想外のことが起きて作業を継続できなくなった。
- そもそも、準備していた内容に一部違いがあった。
- 準備していた環境と公開環境が異なった。
- クライアント側の都合で公開中止になった。
- そのほかいろいろ。
1. 公開作業中に何かを間違えてしまった。
これはシンプルな問題ですね。
たとえば、ウェブページでいけば、アップロード先のディレクトリを間違えてしまったとか、コマンドを間違えてしまったとか、手順の一部が計画者と作業者で認識あっていなくて、正しく作業されなかったとか。
対策
- 作業の自動化
- リハーサルで問題ないことを確かめておく
- 複数人で作業し操作ミスを防げるようにする
2. 公開しようと思ったら、予想外のことが起きて作業を継続できなくなった。
こちらは予想外なので、ピンポイントで事前の対策を立てることは難しいです。
たとえば、バックアップファイルを取得するときに、容量が想像以上に多くてダウンロード時間がかかり、予定していた時間で終わらなかった。クライアントの承認が必要だが、連絡がつかなくて作業が遅れてしまった。本番用の管理画面にログインしようとしたら、ログインできなかった。
たとえば、バックアップファイルを取得するときに、容量が想像以上に多くてダウンロード時間がかかり、予定していた時間で終わらなかった。クライアントの承認が必要だが、連絡がつかなくて作業が遅れてしまった。本番用の管理画面にログインしようとしたら、ログインできなかった。
対策
対策の考え方は2種類あると思います。
- 「予想外をなくす」ためにできること
- リハーサルで公開作業を先にやってしまい、考慮漏れがないか洗い出す。
- タイムテーブルを作成し合意していくことで、すべての予定を両社で共有し、各自が必要な時間を決めておく。
- 予想外が発生したときにスムーズに対応するためにできること
- 緊急時対応計画 (コンティンジェンシープラン)を決めておき、その通りに進行する。
3. そもそも、準備していた内容に一部違いがあった。
アップロードするファイルが間違っていた、公開手順に誤りがあった、準備していたコマンドが間違っていた、マージ作業用のファイルが違う、など。
対策
- リハーサルで公開作業を先にやってしまい、予定している手順で問題なくできるか事前に洗い出しておく。
4. 準備していた環境と本番環境が異なった。
ここは公開環境を自分たちで準備していない限り、起きる可能性が常にある項目です。
本番環境と開発環境で、実は構成が違った。本番環境はサーバーを複数台マウントして構築しており、開発環境は単独のサーバーで構築していたため、参照が正しく取れなかった。
本番環境と開発環境で、実は構成が違った。本番環境はサーバーを複数台マウントして構築しており、開発環境は単独のサーバーで構築していたため、参照が正しく取れなかった。
対策
- 緊急時対応計画 (コンティンジェンシープラン)を決めておき、その通りに進行する。
5. クライアント側の都合で公開中止になった。
公開直前で別部門からストップがかかった。社長の一声で仕様変更が入った、など。
対策
- 緊急時対応計画 (コンティンジェンシープラン)を決めておき、その通りに進行する。
6. そのほかいろいろ。
ほかにも様々なパターンで、公開そのものをとりやめなければいけない事態は発生すると思います。
失敗を計画通りとするには？
事前の対策が非常に重要です。
- 公開時にやらなければいけないことが可能な限り少なくなるような計画を立てる。
- リハーサルをやっておき、予想できる問題はすべて潰しておく。
- もしも何か起きたときのために、緊急時対応計画をちゃんと立てて、それにそって対応する。