相変わらず「金の話とエンジニアの話の真ん中くらい」をふらりぶらりしているおいちゃんでございます。
ふと、偶然ではあるのですが。
ちょいとばっかり「壮絶な」ものを拝見したのと、そこに起因して随分といろいろ、考察できるネタがあったので。
その辺の考察の…途中経過、程度のものを、Blogにて。
とりあえず今回俎上に挙げるのは２タイプ。どちらにも共通しているのは「DRYなにそれ？ レッツコピペ駆動開発！！」な行動原理。
A)複数個所のテストだろうがどんだけ単純作業の連打だろうが「僕は」黙々と丁寧に根気よく続けます
B)テスト？ なにそれおいしい？ 理想論として耳にしたことはあるけど、現実、テストなんてやってらんないよ？
Aは、割と典型的な「無能で勤勉な人間」。
http://d.hatena.ne.jp/gallu/20081114/p1 の話を思い出すのであれば、彼らは速やかに[除隊 | 馘首 | 銃殺]されなければならない。
ちょいと真面目に考察すると。
「考えて」「改善すれば」できるコスト削減を彼らはず〜っと「やらない」ので、無駄なコストの発生源になりえるです
で、無駄なコストを生み続けるってのは、ビジネスのメイン目的の１つである「利益の創出」に真っ向から対立する概念なので(利益ってのが「売上 - 費用(コスト)」だ、っていう数式知ってりゃ誰にでもわかる話だ)。
従って彼らは極論としては「ビジネスの敵」になりえるわけです。
あぁ、少しだけ寄り道。
対局に「改善だけ考えて動かない」連中ってのがいて、これはこれで「邪魔なことこの上ない」です。「何もできていない」と比較するんなら「無駄なコストがかかり続けている」ほうが、まだ、極わずかに、１ミクロンくらいマシ。ついでに言うと「口先だけでできもしないことをわめいたりする」ので、ぶっちゃけうざい。
そうならないためには「まず動く」っていう部分と「常に考察を重ねる」っていう部分とをバランスよく保つのが、基本にしてコツ。
人によっては「まずｎ分間考察、しかる後に動く」って人もいるし、おいちゃんは「まず手を動かしながら、頭を並列処理化させて、現在データを分析して改善案を想定」するかな。
この辺「どうバランスをとるか」は、個人差ってか個性。
もう一つ…最近遭遇した怖いのが「テストをしない」という生き方(笑
えと…時系列を思い出しながら。
とあるところのソースコードが…なんていうか「ある意味革命的」で。
本番リリース直後とかなのに
・ソースコードがコピペの山
・使われていないメソッド多数
・使われていないクラスがちらほら
・使われていないテーブルがちらほら
・使われていないカラムがそこそこ
・謎のifやらforやらのネストの山
・意味のない共通化と密結合だけはそれなりに山盛り
というコード。
とりあえず思ったのは「テスト無茶(経路網羅はむろん、分岐網羅ですら、100%にするには手間がかかりすぎる)」「改修無理(コピペと密結合の嵐なので、どこから手を出したものやら…)」「追加困難(同左)」という三重苦。
どうやってこれでうまくやってるんだろう…っと思ってしばらく見ていたのですが。
結論からいうと「テストしてない」 orz
あとは「言われた事を狭い範囲で局所最適解的に額面通り、あるいは場合によっては曲解して理解して、かつその局所に対する修正しかしない」orz
あぁ「こういう理由があるから(根っこ)これを作って(実装)」ってお願いをしたら、根っこをドン無視したブツが上がってきたこともありましたな(遠目
どうも見ていると。
結局のところ「テストを全くしていない」かつ「テストをする必要性すら理解していない」ようなので(正常系の最小限をぎりぎり、それですらやっていないケースがあったっぽい)。
結果的に
・コピペ部分を「別途テストする」必要がないから、気にせずにコピペ
・分岐網羅率100%を満たすテストとか未考慮なので「似たような機能」を「あちこちに別々に書いて」も、手間はかからない
・データの確認とかしないので「似たようなカラム」「未使用のカラム」とかの存在も問題なし
という風になっているみたいざんす。
ついでに、基本的に「言われたことを実装してお金をもらえればよい」しか頭にないぽいので(そこさえもあるかどうか微妙なんだけど…)、相手の言ったことに対する「意図を知るための質問」とか、その辺が皆無。
ゆえに端的には「先方のビジネスに対して、全くコミットメントできない」ブツが仕上がってくる。
まぁ、納品されたほうとしてみればぶっちゃけい「いい迷惑」レベル*1。
上述AとBを見ていると「納品先のビジネスについてドン無視」ってところが、一致していると思うのですね。
Aは「どんだけコストをかけても無問題(ひどい言い方をすると、定期的にコストがかかったほうが、システム会社としては、短期的には大儲け)」。
Bは「押し付けるように納品してしまえば、あとは野となれ山となれ」。
むろん、発注元の担当者だって必ずしも「ちゃんとビジネスを意識している」とは限らない、ってのはあるのですが*2。
その辺をきちんと最低限踏まえていれば、たとえば「システムを作らない」というシステム会社の提案とかが、普通にあり得ると思うですし。
その中で「いかに運用コストをかけないつくりにするか」とか、そういう中から「よいもの」が生み出されてくると思うのですだよ。
その辺、相手の「ビジネス全体の系、の一部としてのコンピュータシステム」という認識に至れるかどうか。
システムってのは「発注者と受注者のコラボレーションである」というスタンスに至れるかどうか。
結構重要な考え方なんじゃなかろうか、って思うのですが、どうなんですかねぇ？
