こんにちは。菊地です。
自分で言うのもアレですが、私は地味です。生活も地味なら服装も地味なので、仕事っぷりも地味だったりします。

当然クール(イケてる的な意味で)なライフハックとか、シティボーイ(都会的な意味で)なガジェットとか、ナウ(now=今っぽい的な意味で)なネタは、あまりご用意できません。

そこで、今回は「地味」ならではの視点で、できる仕事術を考えていきたいと思います。

「俺って会社じゃ目立たねぇよなぁ…やる事はやるんだけどなぁ…」とか、「ミスはしないぞ!! しないだけだけど…」とか、「地味だけど堅実な仕事ぶりを評価されたい…」といった、そんな引っ込み思案さんに向けて、「ボクも地味でしょ? えへへ、よかったらマネしてね」的なメッセージを込めて書きます。


更新ファイルの把握術(対象:地味で繊細な人)

日々、膨大なファイルがアップデートされる制作の現場では、しばしばプロジェクトの変遷や相関関係がわかりづらくなります。
ライブドアでは基本的にBTSを使ってプロジェクトの進捗管理をしていますが、細かい動きの度に「このディレクトリの、このファイルを、こーして、あーしています…」と書いていくわけにはいきません。大雑把にタスク単位の作業進捗を、書いていくことがほとんどです。その方が読みやすいし、全体を把握しやすいわけです。

ところが、こんな声が聞こえてきたらどうしましょう?
「おーい! 誰だ? このファイル、いじってるの? 競合してんぞ!」
「うーい、俺ー、マージしといてー!」
「・・・僕が?」

「先祖返り・・・? なんで? 最新のリビジョンなんだけど…」
「あ、俺、コミット忘れた…」


こんな会話を頻繁に耳にしたら、プロジェクトを管理する立場としては、改善の必要がありそうです。

でも、エンジニアたちが、即断即決で作業を進めている中で、誰がどのファイルをいじっているかを把握して、「この人の作業が、アレして、こうなりそう…」なんていう風に予測するのは難しいですよね。
とはいえ、何もかもを現場のエンジニアに任せっぱなしだと、いざトラブルが発生した時や、説明を求められた時に、困ってしまいます。ディレクターが何もわかっていないと「君、何してたの?」ということになってしまいます。

そこで、私が「より細かく」プロジェクトを管理するために、実践していることを紹介します。


【01】更新表を作る

ライブドアのエンジニアは、サーバを管理しているデータセンターに向けて、追加、及び、修正するファイルや、影響するサーバ、ウェブサーバ再起動の有無などの情報を、メールで送ることになっています。全体周知のためというよりは、データセンターで監視しているスタッフに、「サーバの中にあるファイルが変わりますが、トラブルではなく作業ですよ」と通知するのが、主な目的です。

<文例>
お疲れ様です。XXXX です。
下記ファイルを本番化します。

/htdocs/hogehoge.html
/view/inc/hogehoge.inc
/bin/hogehoge.pl

対象のサーバはこちらです。
10.0.xxx.xx

apache の再起動を行います。


私は、このメールを見て、こんな表を作っています。

更新表

開発環境でのテストやコミット日は、BTS やソース管理ツールに書いてあるリビジョンの更新日を参考に書き込んでおきます(大体、同日になるはずです)。備考欄にはサーバの再起動があったのか、などを書いておけば良いでしょう。

基本的に、メールを見たらその時点で更新表をアップデートします。終業間際や、始業後すぐなどに前日の分を追加、などでも効率的だと思います。


【02】なんの意味があるの?

「性格的にやらずにはいられないというか…」、ではなく、きちんと履歴管理をする必然性があるからです。

例えば、当該ファイルが先祖返りしてしまったとき…。もちろん、こういったことは起こってはいけないのですが、Web従事者なら「そんな状況になったこと一度もない!」って人は、ほとんどいないのではないでしょうか?
いずれにしても、手違いというのは誰にでもあるわけですから、それを予期して対処しておくのが、地味ながらディレクターにとっては必要な作業といえるでしょう。

こうしておくと、万一のときでも、「○月△日に、htdocs/hogehoge.html を、××さんが修正していますね。今回□□さんが、修正されたファイルと同じですが、差分を確認してもらえますか?」
…って、テキパキと言えたら、ちょっと「デキる奴 風」じゃないですか!?

もちろん、言うこと自体は大したことではないのですが、本質的には、そういう情報を常に把握している事が、ディレクターの「仕事」だと思うのです。

「□□さんが、なんか、作業していたみたいなので、本人に聞いてください」でも、解決できる場合はありますが、担当者に任せっきりにしておいて、管理も記憶ベースの曖昧な状態では、誰に何を聞けばいいか判らなくなってしまったり、突発的な状況で対応できないことも多いのではないでしょうか?(問題は全て突発的に起こりますよね)

こういった地味で繊細な作業は、ミスを未然に防いだり、最小限に食いとどめたり重要な局面こそ威力を発揮すると考えています。

※ライブドアでは svncvs などのバージョン管理ツールに、更新内容がコミットされるとサーバのファイルを同期するようにしているため、基本的にそういう問題が発生する事は稀です。


【03】…っていうか、データセンターへのメールを読み返すだけでいいじゃん?

確かにそうかもしれません。

でも、そのメールは先述のように、ディレクターのために、送っている内容ではないので、そのときに知りたいことが明記してあるとは限りません。

そのメールに書かれていない「ディレクターが知っておくべきこと」とは、
・そのファイルがバージョン管理ツールにコミットされているか?
・開発環境と本番環境との差分は無いか?
などです。

コミットされていなかったり、差分が存在したりする場合は、その理由を確認しておくべきでしょう。そういう情報は、自らバージョン管理ツールやサーバのファイルを見比べて確認するようにしています。そこに気になる点があれば、その時点で更新表に記載して確認する、というやり方です。

ですから、私はあくまで送られるメールは、更新表に加筆するタイミングの目安として、読んでいて、実際に事故などの調査で活躍するのは、やはり独自に収集した情報でできている更新表なのです。


いかがでしょうか?
一部の地味で堅実な方々からの支持があれば、第二回を検討しようと思います。

ライブドアでは、「むしろ、私はもっと細かい仕事してますよ…!」と、スッと背後に忍び寄るようなディレクターを募集しています。