大した話じゃないんだけど、いや、大した内容なんか今まで書いたこともないけれど、ちょっと仕事の話を。

別に愚痴とかではないが、少し業界寄りの言葉で、一気に書き殴ってみる。

私は現在、事業会社の情報システム部門に所属していて、その中でも、社内システムのアレコレを面倒見たり、開発したりする業務を担当している。

で、最近、急ぎというか、スポットで作らなければならないプログラムがあった。開発業務に従事するメンバーは私以外にも居るが、線表上、現在タスクが空いていて対応できるメンバーは私くらいだったし、たまたま対象業務に関する仕様を比較的知っているということで、開発は私一人で担当することになった。

そして、「いつまでに作れる？」と訊かれた時、私は少し考えて、「2週間ほどあれば出来ます」と答えた。

実は、その開発にかかる工数について、当初の見積もり段階では、あまりバッファを積まなかった。その理由は、単純にスピード重視で仕上げたいと思っていたからだ。

ちょっと多めに盛っておいて「1か月くらいですかね」と言うことは簡単だ。しかし、そうした場合に、相手が「えー、そんなに時間かかるの・・」という反応になってしまうと、それはそれで自分の評価に影響する可能性がある。別に高い評価を求めて仕事をしているわけではないけれど、「仕事も遅いし、アイツ使えねーな」という評価になってしまうと、そこは哀しき雇われの身ゆえ、いつ肩叩きをされてしまうやもしれない。まだ住宅ローンを支払う必要があるため、こんなところで簡単にクビになるわけにはいかないのだ。

かと言って、「1週間で出来ます」とロクに精査もしないで工数を適当に叩き出してしまうと、実際に不測の事態（これが往々にしてまぁ予測できない。だから不測なんだけれど）が起きた場合に、当初のスケジュールからブレにブレてしまった結果、「何だよ。出来るって言って出来てないじゃん」ということになり、それこそ「口だけで、全然アイツ使えねーじゃん」という評価になりかねない。

といったわけで、あらかじめ可能な限り精緻に見積もりをして、少ないバッファで見積もって、それでいて、成果物の道筋をある程度の確度まで高めたうえで「よしこれなら恐らくイケるだろう」というギリギリの瀬戸際のところで、「2週間くらいです」と、ようやく工数を出してスケジュール承認を貰うということになる。

私のような平凡エンジニアには、そういうギリギリの戦いがある。いや、エンジニアというか、一兵卒のサラリーマンだからかもしれない。豪快な攻めはしないが、守りすぎない範囲で守るのだ。攻めの守りだ。よくわからん。

だから、もしかしたら「これくらいで出来ます」という言葉の裏には、

という膨大な情報処理と試行錯誤が繰り広げられていて、それは怠惰と勤勉の間でせめぎ合った結果、ようやく紡ぎだされた言葉なのかもしれない。

閑話休題。

そういうわけで、なるべくスピード重視で（それでいて多分間に合いそうなスケジュールで）開発していたのだけれど、その間は、「本当に終わんのかなぁ」と内心ビクビクしながら作っていたのだけれども。

そして今日、ようやくその完成の目途も立ってきた。ひとまず、全ての処理は実装できた。あとはパターン分けした細かいテストと、非機能テストというところまで来た。危なかった。

といったわけで、期限である今月末までには、恐らく間に合いそうなので、こうして少し落ち着いて、記事を書いてみている次第だ。

「終わるのかな」「終わらないのかな」という狭間でドキドキしながら生きるのは、なかなか心臓に悪い。思えば、この仕事に就いた時から毎日そういう思いで生きてきたつもりだったが、最近はそれをすっかり忘れていた。日々の業務に慣れてしまったということと、ゴリゴリの開発業務が久々だったということが原因だろう。初心を思い出すことができた。感謝。

しかし、ここからが最後の難所。安心するのは納品まで済んでからだ（いや、情シス的には納品後のほうが仕事としては大変だったりするのだけれども、その話は省略）。

そのプログラムでは膨大なデータ（約三千万件）を処理しなければならない関係で、この後に残されているタスクとしては、まずはパフォーマンステストをきっちりやらないといけない。そうでないと、最悪の場合、本番業務で使っているDBにまで負荷がかかってしまうからだ。そうなると、業務に影響が出かねない。

そう。顧客満足度的には、非機能テストこそ非常に重要。持論だが。

当然備えておくべき機能なんぞ、使えて当たり前なのだ。ユーザはそこに価値を見出すことはない。「言われたとおりに作りましたよ」だけだと「ああ、うん、サンキュー」で終わりだし、使われないことだってあり得る。普通にそれはあり得る。悲しいけれど仕方がない。「お！助かるなあ」というのは、いつだって、予想をちょっと超えた先にある。
これが攻めの話。

そしてさらに言うと、当然備えておくべき機能は当たり前として、それが明文化されていないものもあって、意図せずにその期待を裏切ってしまうと、評価としてはマイナスポイントになる。非機能要件はまさにそれにあたる。処理が安定していることとか、動きがサクサクしていることとか、普通に他の業務に影響がないこととか。目には見えないけれど、とても大事なこと。縁の下の力持ち的な機能なのだ。
これが守りの話。

したがって、上で述べたように、スポットで短期的に運用するツールに過ぎないのに、本番の通常業務に影響が出てしまっては、当然にNGなのだ。

まだまだ気が抜けない。でもこの開発という仕事が好きでやっているから、まだやれているんだろうと思う。

今回は、誰が読んでもよく分からない、そんなむちゃくちゃフワッとした話でした。以上。