とある新人のブラック就労記 その14
新システム導入当日。
ついにやってきた本番の日。
ネカフェから朝5時に出社した新人くんは、本番環境にアクセスできるデスクでシステムが稼働しているのを確認した後、自分のデスクで現場組からの連絡を待った。
睡眠時間は2時間ほどだが、不思議と眠気はなかった。
会社の始業時刻は9時なので、当然社内は誰もいない。
現場組が現場入りするのは朝7時だが、朝5時に最終システム稼働チェックをするのが移行作業のチェックの内の一つだったため、鈴木さんとは別に新人くんだけ先に出社していた。
誰もいないと逆にそわそわしてしまい、コーヒーメーカーでコーヒーを淹れたり、朝コンビニで買ったサンドイッチをもしゃもしゃ食べたり、艦〇れをしたりして時間をつぶしていた。
「おはよう」
朝6時半頃。鈴木さんが出社する。手にはかつ丼屋の持ち帰り弁当。朝からかつ丼を食べるらしい。不摂生な生活のせいか、ここ一か月で鈴木さんの体型が痩せ型からぽっちゃりに変化しつつある。
「現場から電話あったか?」
新人くんは首を振る。現場入りする前に連絡する決まりだったが、まだ連絡は来ていなかった。
改めて時計を見ると時刻は6時40分。
そろそろ連絡があっても良い時間だった。
「かけてみるか」
鈴木さんが長谷さんの携帯に電話をかける、が、繋がらなかった。
「……八九寺も出ない。新人の同期の番号、分かるか?」
鈴木さんに言われて新人くんはプライベートの携帯の番号に電話をかけてみる。新人くんと営業の同期――ムッツリはあまり接点はなかったが、一応番号の交換をしていた。
本来であればプライベート携帯の社用利用は禁じられているが、そうもいっていられない状況。
何コールかしたあと、ムッツリの携帯に繋がる。
『おー、新人、どうした?』
切羽詰まってはいない、のんきな声。
新人くんは現場組の状況を聞く、と。
『現場の人が気を利かせてくれてさ。朝7時は点呼とか朝の挨拶とかでシステム使わないから、8時半入りで大丈夫って話になったんだ』
新人くんがそのことを鈴木さんに伝えると、鈴木さんは割りばしをベキベキと折り始めた。
「聞いてねえぞ! そういうことは逐次連絡しろ!」
怒号が社内に響き渡り、それが聞こえたのかムッツリが電話の向こうで平謝りする。
「ったく。ってことは長谷さんと八九寺はまだ寝てんのか……。初導入の初日くらい早起きしとけっつの」
相当頭に来たのか、鈴木さんがぶつぶつと毒を吐く。
「……はぁ。とりあえず時間ができたから、リソースのチェックと……トラブルで緊急リリースがあったときのためにリリース準備しとくか」
それでも、鈴木さんは真面目に仕事をし始める。
キレやすさを除けば、鈴木さんの『最悪を想定して行動する』という決断基準は社内待機組の理想型だった。
現場に連絡が付かなければトラブルを想定していかなる手段を使っても連絡を取り、更にトラブルが起きたときの保険の手をいくつも打っておく。
実際、データ移行のリハーサル時にもいくつも不安要素があったが、鈴木さんの機転で全て未然に防ぐことができた。
鈴木さんがいたからこそ、無事にシステム導入日を迎えることができたと言ってもいい。
しかし、こういった影の立役者は会社では評価されづらい。むしろ、キレやすい、という人物面での評価を、その人の会社での働きの評価に直結させる事も多々ある。ぶっちゃけて言えば、仲が良い人が多いほど、評価が高くなる傾向。それもそれで一つの評価の基準ではあるため否定はしないが、比率がおかしいことは言うまでもない。
「ついでに本番環境リリースの手順も新人に教えなきゃな。基本的にはテスト環境と一緒なんだが――」
リリースとは、一般的なシステムを納品、使用可能な状態で客先に提供する、という意味とは別にもう一つ、修正したファイルや新規作成したファイルを本番環境に反映させることもリリースと呼ぶ。
システムは、本番導入日を迎えると気軽にサーバの停止が出来なくなる。それはもちろん、ユーザーが触っているからだ。ユーザーはシステムを使って仕事――つまり利益を上げているため、システムが止まることは客先の利益を潰すことに当たる。そのため、唐突に緊急メンテナンスをしたり、システム会社の都合で頻繁にシステムを停止したりすると、詫び石どころの話ではなくなってしまう。
「本番環境へのリリースは、客先の承諾と、社内の承認が必要になる。もちろん、緊急の時にお客がうちの会社に来るまで待つほどほど呑気な状況はないから、客先の承認は現場組が受け持つ。これが本番環境用のリリース申請書だ」
リリースの目的、システム停止時間、リリースするファイル一覧、リリースした前と後での動作の変更。
そして、トラブルが発生したときのリリースの場合はトラブル発生報告書を添付する。そのすべてに承認が必要。
――承認、承認、承認。うざったいほどに許可が必要な申請書。だが、一つでも抜かせば申請が通らず、申請が通っていない状態でのリリースは重大違反となる。
新人くんは鈴木さんの指示通り、申請書を後で簡単に提出できるよう、日付やファイル一覧などを抜いた虫食い状態で用意する。
「データ移行でも使ったと思うけど、バッチファイルをこまめに作っとくと便利だぞ」
バッチファイルとは、バッチスクリプトとも呼ばれる、Windowsのコマンドプロンプトを利用したコマンド操作をまとめたもの。
拡張子を.batでファイル保存するとコマンドプロンプトに関連付けられ、繰り返し何回も利用できるため同じような作業をする場合に用意することが多い。IT会社の開発部に所属する人間ならできて当たり前なはずだが、意外と作れない人も多い。(新人くん調べ)
バッチファイルを使えば、特定のファイルを名前を変えつつ(連番など)複数コピーしたり、テキストファイルの中の特定文字列を置換したり、Windowsサーバを使っている場合はタスクスケジューラと合わせることで、バックアップ処理などを自動で行うことも可能だ。
今回のパターンで言えば、リリースのためのファイルをかき集めるバッチファイル、リリース前とリリース後のファイル数やファイル名、更新日を取得するバッチファイル、リリースする前のファイル構成そのままをバックアップして取得するバッチファイル、などを作れ、という話。
「それと、昨日取ったデータベースのバックアップのコピーを社内のテスト環境に入れとけ。トラブル起こったとき、再現テストがやりやすくなる」
もしものときと下準備をしつつ、社内待機組は現場組のバックアップ体制を整える。
そのかいもあってか、初日はトラブルなく終了した。
が、鈴木さんは一日中キレていた。