ドキュメント書くのって楽しくないですよね。プログラミングすることは好きでも、ドキュメント作成は嫌いって人は多いと思います。
その中でも、リリース作業のための手順書（以降、リリース手順書）を作るのが嫌いな人、私の周りにも多いです。嫌いというよりは、必要ないとか、無駄な作業、と思っている感じなのかもしれません。作るのがルールだから、という理由で書いている感じですね。
リリース手順書作成のメリット
私個人の考えですが、重厚なものであったり、テスト環境用のものを作る必要はなくても、簡易的でも良いから本番環境用は常に用意すべきと思っています
作るべきと思う理由をいくつかピックアップしてみました。
作業の抜け漏れを無くす
頭の中のことをアウトプットするだけでも、意味があります。詳細書くのが手間であれば、作業項目をリストアップするだけでも価値はあると思います。
書いているだけで、他にも必要な作業があることに気が付ける機会です。
単純な抜け漏れほど、情けなく防ぐべきものですが、失敗の大半はケアレスミスだったりするのです。
イレギュラーケースに対応しやすくなる
開発環境で確認した作業であっても、本番環境ではうまく行かない。なんてことは日常茶飯事です。ネットワークや構成の差異によるものであればまだ良いものですが、本番環境だけ見知らぬファイルがある、なんて経験している人も多いでしょう。
本来であればイレギュラーを防ぐことができればベストですが、なかなかそう簡単にはいかない。イレギュラーは常に起きるものとして考えたときに、手順書があるとある程度は円滑に対応できると思っています。
切り戻しの判断基準や手順が書いてあれば理想ですが、作業手順だけでも良いです。
自分の作業にミスが無いかの見直しに活用したり、周囲に助けを求める際のガイドブックになることもあります。もしものときのためにも、作っておくべきだと思うのです。
将来の資産になる可能性がある
裁判においての判例が重要なように、過去に実施した実績というのは貴重な判断材料になり得ます。もし今の作業を誰かに引き継ぐときに、過去の手順書は引き継いだ人にとっては重要なバイブルになってきます。将来の自分やチームのためにも、作った手順書は資産になると思います。
自分や周囲への意識付け
今ではクラウド環境が主流になってきているので、簡単に本番環境を触ることができるというプロジェクトも多くなってきました。一昔前のオンプレ全盛の時代では考えられません。本番サーバにファイルひとつ配置するにも、作業申請の許可だ、サーバルームへの入出の手続きだなんだで、作業ひとつの重みが変わってきたと感じます。
もちろん昔が良かったと言うつもりはなく、より簡易にして無駄を省くという意味では、今の方が何倍も良いと思います。ただ、作業ひとつの重みというのは常に意識しておくべきだと思うのです。
リリース作業なんてうまく行って当たり前みたいなものだし、慣れが生じた先に必ずミスは生まれるものなのだから。
そういう意味でも、ひとつの意識付けとして、面倒でもリリース手順書を作ることに価値はあると思っています。
リリース手順書をつくることのデメリット
当然リリース手順書をつくるくとにデメリットはあります。当たり前ですが。そりゃほとんどの人が無いよりは合ったほうが良い、って言いますよね。
私が思う、デメリットとそれに対する考えです。
予算や作業工数との兼ね合い
手順書作るにも時間はかかるし、それをレビューする人の工数も取られる。まぁそりゃそうだ。手順書を重要視していない人が指揮している組織であれば、なおさら工数を理由に作らない文化ができていることでしょう。
「手順書不要論」を唱える人
手順書不要論者は結構いると思います。主観ですが、初級者～中級者になりかけの人と、一部の天才肌の人に。どうせ想定外のことは起きるという考えや、目の前の手順書より経験や知識が大事と考えている人、います。まぁ間違っていないと思いますが、不要論者が組織で力を持っていると、作ることはデメリットの方が強い空気が生まれてしまうでしょう
リリース手順書作成にあたり心がけていること
- 前提を必ず書く
- 対象サーバ、作業ユーザ、何のための作業か、を明確にする
- バックアップを必ず残すようにする
- 何よりも確認を大事にする
- 手順書残すことで次の教訓を得る
コメント