プログラミングの仕事は「ノリ」が命！？

飛び回りすぎでプログラミングの仕事が溜まっているため、お盆休みは全く取れそうもないのですが、今日は久しぶりに1日会社で仕事ができましたので（昨日もほぼいましたが）、山積みのプログラミング仕事のうち、2つくらい片付きました。。

まあ、実際に二つにかかっていた時間は2時間半くらいなのですが、他に事務仕事などもありましたし、何より、頭を使う仕事は「その気になるまでの時間」が必要なのです。

自社製品の機能追加で公開しても大丈夫なので、具体的に書くと、「ProDHCPに、DOS攻撃防御機能をつけて欲しい」という要望への対応です。DHCPの処理は、クライアントからアドレスの要求を受けて、適切なセグメントの空きを探して貸し出す、というようなものですが、管理している情報が膨大になると、検索処理だけでもかなり重たい処理になります。DOS攻撃を受けてしまうと、サービスに影響が出てしまうわけです。もっとも、DHCPの場合、悪意を持って攻撃を仕掛けられるというより、クライアントやルーターのリレーエージェントのバグにより、とんでもない頻度でリクエストが繰り返されたりするケースが多いようですが・・・。

さて、具体的にどうするかということなのですが、リクエストが届いたクライアントのMACアドレスを全部覚えてカウントすることもできますが、さすがにISP向けのサービスともなると、クライアントの数は呆れるほど膨大になりますので、リレーエージェントごとにカウントするようにします。同一のリレーエージェントから、1秒間にたとえば100個以上リクエストが来たら、しばらくそのリレーエージェントは無視する、という感じにすれば良さそうです。当然、閾値や、どのくらいの期間無視しておくかなどは、設定ファイルで変更可能にしたいところです。また、ISP向けともなるとリレーエージェントの数もかなりありますので、カウントの検索自体で遅くなるようでは本末転倒ですし、メモリー資源を無駄にしないために、ある程度以上リクエストが来なくなったらカウント情報から削除しておくことも大事です。

さあ、こういう課題があるとき、プログラマーとしてはどう取り組むのか、というところなのですが、私の場合、先日「やることがたくさんあるときこそ手を抜くことを考える！」に書いたように、まずは寝かせておきます。いきなり力業で手を出したりしません。もちろん、ずっと思い出しては頭の中で考えています。

昨日は仕事が終わってからゴルフ練習場に行ったため、帰宅が23時過ぎでした。それからブログを書いたりメールの対応などをして、寝たのは3時前。さすがに今日は眠かったのですが、こんな時は意外とチャンスなのです。眠たいときにつまらない仕事をやると本当に寝てしまいますので、ワクワクしそうな仕事がいいのです。「今だ！」と、午前中の雑務を片づけてから、この課題に取り組みました。こんな感じに作れば良いという構想は既に頭の中にありましたので、作り始めると一刻も早く動かしてみたいという感じで、一気に1時間半で作り上げて動作確認まで終わらせたのでした。

1時間半でできるなら、とっとと片づければいいのに、と思う人は、プログラマーの性質を分かっていない人でしょう（極論しすぎ！？）。気分が乗らないときにこういうアルゴリズムものに手を出すと、ろくなものができません。だらだらとひどいソースを書いてしまい、性能も期待できず、しかも、後でメンテナンスできないようなソースになるものです。その気になったから1時間半なのです。

さて、午前中で難問の一つが片付いたので、午後もその調子で、、とはならないもので、集中した1時間半の後は結構疲れるのです。少しだらだらと雑用や気分転換をしながら、次はどれに手を出すかで悩みます。「これかな？」と思ってソースを眺めて、「うーん、やっぱりまだその気になれない・・・」と、他を見たり。。

結局もう一つ片づけたのは、「こういうふうに仕様追加して欲しいので、工数を見積もって」と依頼を最近受けた、メールセキュリティ製品：ATGatewayの機能追加でした。見積もるのは面倒なので、作ってしまった、という、いつものパターンです。こちらも1時間くらいで動作確認まで完了！お客さんには「見積もる前にできたのと、この機能は汎用的なものなので、通常のバージョンアップで対応します」と。つまり、ただで。1時間分でぼったくりたくないのと、少ない金額では伝票処理などの方が面倒、というところですね。。お客さんの担当の方がとても良い人なので、というのもあります。

こんな仕事の仕方が、私のプログラマーとしてのやりかたです。基本的に気分が乗らないときにはソースをいじらず、気分が乗って作ったソースは後で見ても分かりやすく、問題も起きにくいのです。私が書いたソースはかなりの製品に入っているのですが、それでも新しい仕事にチャレンジしたり、外をほっつき歩いたりする余裕もありますし、お客さんに怒鳴られまくったりしていません。

こういう背景を考えると、前にも書きましたが、ウォーターフォールで仕様書を書いてレビューして、プログラム作って、テスト結果を大量に書いて・・・問題が見つかると大騒ぎして、という、時間も労力もたっぷり使う仕事の進め方で品質が上がるとは思えないのです。「楽しみながら作ることこそ品質のポイント」だと思っています。まあ、世の中そうでない仕事の方がはるかに多いとも思いますが、私はこういう仕事の仕方が一番良い結果につながっているので、こうなる仕事を選びますし、作り出します。

とはいえ・・・2つ片付いても、まだまだ大量にあるんですよねぇ。しかも、どんどん増える。。まあ、楽しいのでいいのですけどね！