PGの言い訳
2009年1月28日
プログラマの言い訳スクリプト集。
3つ以上言ったことがあるやつは、
好きな駄菓子の名前を言いやがれ！
裏に「これでも動きますから、間違ってませんよね」
という意味が含まれている。
受託だと、勝手に仕様を変えるのは基本NGなので、
仮に合理的な選択だとしても、
その調整のために、他の人にコストが発生するのは知っとく必要がある。
自社サービスや社内案件等の、ある程度仕様の決定権があるという状況で、
その実装に根拠があれば、むしろ良いことですけど。
仕様通りなんだけど、
そもそもの仕様がおかしいことを実装者のみが知っている場合に、
そのまま作ってしまうような状況。
いきなり前言を撤回するっぽいけど、これもダメだと思う。
というのも、無駄なものを作ったというコストは、
最終的には、絶対誰かが被ることになるという原理から。
「仕様通りに作れば、絶対自社の責任にならないような契約をしたぜ！」
と、カッチリキッチリ決めて進めているプロジェクトはほぼ無い(*1)と思うので
そのコストの落ち先はわからない。(*2)
まぁ、微妙な点ならスルー可能ですけど。
(*1) キッチリしてもいいんですが、そうすると高くてつまらなくなってしまう。
この辺のリスクをお互い譲り合って飲むことが出来ると、安くいいものが作れるんだけどな。
(*2) その点においては絶対自社に非がない状態でも、
案件を通してだとナァナァになり勝ちだと思う。
でも、作りっぱなしでテストしてなかったりとか。
それは出来て無いんだぜ。
過剰にテストをするのも、どうかとは思いますが。
「PCが重くてメーラ落としてます」「メールが一杯で読んでません」とか。
えー、と思うんだけど、割と良く聞いた。（俺だけか？）
どーーしても見たく無いなら、
せめて、その業務フローを顕在化すべきだと思う。
もうこの時代だと、クロスブラウザ確認をする方がデフォルトだと思う。(*1)
逆に「これはブラウザ関係ねーよな」ってのを個別に考えて、
地道なテスト減をするって方がいい。
(*1) 対応範囲は雰囲気によりますが、
Windowsの IE6/7 FireFox2/3 は必須だと思われる。
ある程度開発が進んだら、
デプロイ時になにをすればいいのかというのをまとめた方が、
リスク分散になると思います。
好きなお菓子は、東ハトのハーベスト！
好きな駄菓子は、アンコ玉。