「運用でカバー」とは

出来上がったシステムの質があまりよろしくなかったり、機能が不足していた場合などに聞くことがある、とても頼もしい言葉。

システムの至らない点を、マンパワーで解決するという決意が込められた、たくましい言葉である。

代表的な実行例としては、自分が作り出したファイルを消さずに溜め込んでしまうようなシステムをカバーするために、管理者が気が向いた時に古いファイルを手で消しているとか、長期間運用していると徐々にメモリがリークしていくので１日に１度再起動して対応するなどが挙げられる。

長期的に見れば運用コストのほうが高くつく場合が多いので、多少予算をかけてもシステムに手を入れたほうが得なような気もするけど、それでシステムが問題なく運用できてしまっている状態だと、なかなか予算が下りないことが多いもの。

「ライセンス条項でカバー」とは

作成したソフトウエアに対して「これ入れるとPCが不安定になるんだよな」とか「ユーザがオペミスした時の防御が少し甘いんだよな」といった不安を抱えている時に、エンジニアの気持ちを安らかにしてくれる効果があるクリーンな防御手段。

もっとも典型的な例は、「このソフトウエアを使用して生じた問題について、当方は一切の責任を負いません」的なフレーズがある。

頑張ってライセンス条項を考えても、ユーザが読んでいるかどうかは不明である。というか、ほとんどの人はまともに読んでないような気がするが、それについては深く考えてはいけないもの。

「ヘルプでカバー」とは

技術力不足やコミュニケーション不全、当初の構想からして間違っていた等の理由によって、直感的に使うことが不可能な斬新なアプリケーションを作ってしまった際に使用することがある手法。

ライセンス条項と同じく、ユーザが読むかどうか怪しい存在であるヘルプに、そのアプリケーションの使い方を懇切丁寧に書くことで、ユーザから「さっぱり使い方が分からない」というクレームを受けても、「ちゃんとヘルプに書いてあります」と答えることができる。

「トラブル対応」とは

運用中のシステムに障害が発生した場合などに、その対応を行うこと。エンジニアの心を凍らせたり沸騰させたりする非常に心臓に悪い作業である。

ハードウエア障害の場合は、壊れた箇所（ハードディスクが真っ先に壊れる場合が多い）を入れ替える作業などが必要になり、これにデータの復旧などが絡むと、システムを復元するまでに何時間も必要になってしまうことがある。継続して運用しなければならないシステムが完全に停止してしまったような緊急時には、復旧するまで休みなしで緊張感溢れる連続作業を行わなければならない場合がある。復旧が終わった瞬間に身も心も崩れ落ちそうになるような、厳しい作業である。

ソフトウエアに障害があってシステムが動作しなくなってしまった場合は、原因の調査とプログラムの改修が必要になる。

障害原因の調査は、それが特定されるまでは自分のミスが原因じゃありませんようにと祈りながら行うことになる。これもまた、適度にプレッシャーのある作業である。また、普通にデバッグしただけでは発見できないような難易度が高いバグの場合は、なかなか原因がつかめず周囲のプレッシャーにさらされながらもんもんとした時間を過ごすことになったりすることも。

トラブル対応をしている時のエンジニアの中には、蒼白な顔で必死に作業をする人と、何故かテンションが上がって嬉々とした表情をしている人の２種類がいる。後者のエンジニアの表情を見ていると、トラブル対応というのは決して辛いだけではなく不謹慎ながらも楽しい気分になる要素も含んでいるのではないかと思われる。

「とりあえず777にしておく」とは

Linuxのファイル操作がかかわるプログラムを組んでいる時に、たまに耳にすることがある言葉。

主に以下のような会話の中で使用される。

「すいません、このファイルの書き込み権限が必要なんですが」
「ああ、後でグループ設定しようと思ってるんだけど、今時間ないからとりあえず777にしておくよ」

尚、この後、ちゃんと777から適切なパーミッション（たぶん660とか）になるかどうかは、時間的な制約、セキュリティに対するチェック体制、それからエンジニアの良心などにかかっている。

「とりあえず共有ユーザを使っておく」とは

サーバにログインするためのユーザなどを、とりあえず１つだけ作成しておき、それを開発者全員に通知することで、人員の入れ替わりが発生するたびに行わなければならないはずのユーザの作成や削除作業を省略できるという、古典的な作業時間短縮技である。

被害が想定しづらいところ（イントラ内で一時的に使用している開発用サーバとか）で使う分には、まだ危険は少ないだろうと思われるが、セキュリティを考えると、極力避けておいたほうが良いと思われる行為。

自宅からでも作業できるようなグローバルな場所にいるサーバに対してこの技を使用していると、そのプロジェクトにかかわっていた人は退職後もずっとそのサーバにログインできるという、ちょっと怖い状態を作り出してしまう。

特に退職時に恨みを買っていたとか、他社の人間に見られると困る情報が入っている場合などには、早めにそのユーザは廃止することがオススメされる。

「とりあえずTODOと書いておく」とは

仕様が不明確だったり、共通機能が処理する予定になっているがまだ当該機能ができていない箇所などに、コメントとして入れておくことがある言葉。一部のIDEでは、コメントに「//TODO」と入れておくと、その文字が入っている箇所を一望できるようにしてくれたりもする。

「後でやろう」と思ったことを、確実に覚えておけるような優れた記憶力を持った人には必要ないものかもしれないが、さっきまで考えていたことを１分あれば完璧に忘れられるような高い忘却能力を持った（筆者のような）エンジニアにとっては、非常に重宝する言葉である。

プロジェクトの初期の段階で、とりあえず作成されたソースをレビューすると、すべての例外処理部分に「//TODO 例外処理の規約を決めてください」と書いてあったり、「//TODO テーブル構成変更予定。変更反映後に修正する」などの言葉が並んでいるのを見かけて、あぁ、このプロジェクトはこんなにも課題が山積みなんだなぁと思わせてくれたりすることもあるもの。