ちょっと古いエントリらしいがTwitterのTLに流れて来たので。
頭のいいプログラムの出来る側の人の言いそうなことである。
言いたいことはよくわかるし、昔そう思っていたこともないわけではないが、今はその必要は全く感じてない。
なぜそうかと言えば、「そーゆーもの」というドメインが明らかに存在しているからだ。
SIerの現場で書かれるプログラムに「難しい」ものはあまりない。SIで大変なのはシステム設計であり、円滑な実装(=プロジェクトの進捗)である。ここで書かれる「プログラム」の多くは退屈な同じようなロジックがほとんどである。
私がまだ新米のシステムエンジニアだった頃、システム設計の他に実装もやっていた。当時なので、コーディングシートに書いてパンチ屋さんに出して、それを計算機に入れて以降は端末で… というフローであった。その時に気がついたのは、
シーン(画面)は違っても抽象的な機能はほとんど同じ
ということである。今時の言葉で言えばCRUDでだいたいの処理が表現出来るということである。もちろん対象となるデータベースが違ったり、それぞれのシーンで扱うデータやチェックやアシストは異なるのだが、主だった処理の流れロジックはほとんど同じだということだ。今時の感覚で言えば、
ほとんど(Railsの)Scaffoldと同じ
だということだ。まぁその当時の感覚がモダンになったものがScaffoldだと言えば良いんだろう。
他方、外注や後輩のプログラマやを使っていると、時としてその品質の低さに泣くことがある。オリジナルのロジックでやっているのはいいんだが、何やら小難しいことをやってバグのすくつ巣窟になっているとか、そーゆー奴が結構あった。中には「おお！」と思うようなトリックがあったりするんだが、別にそこにオリジナリティーもトリックもいらないよと。
そういった時にあれこれ考えた結果に思いついたのは、
コピペで済むテンプレート
を作ることであった。
具体的にどうしたかと言えば、コーディングシートに「標準ロジック」の穴埋め用のコードを書いておいて、それをコピー(紙)して穴を埋める。そうすると自動的に品質の揃ったコードが書けるとゆー寸法である。つまり、積極的にコピペを推奨するようにしたわけだ。お陰で、妙なオリジナルロジックに悩まされることなく、また生産性も上げることが出来た。
こういった話をすると、すぐにカバーレンジの話になってしまうのであるが、プログラムを書いているのは「人間」なので、足りない部分は修正するなり自分でオリジナルで書き足すなりすれば良かった。コピペで済むところはコピペ推奨ということにして、だんだんその「資産」を増やしていった。
まぁ今だとこういったことは「スニペット」だとか「デザインパターン」だとかゆー格好いい言葉で呼ばれるのだろうが、なんのことはない
コピペの技術
なのである。粒度の違い、抽象度の違い等々あるにせよ、やっていることに大差はない。
当時の仕事はそれでかなりの部分が解決がついた。つまり、ほとんどがコピペで済んだわけだ。だから、「量産型」とか「コピペ」とかというのは、
システム開発の技法の一つ
くらいに思っておけばいいんだとゆーのが、当時の経験である。
となれば、やるべきことは「量産型プログラマの撲滅」ではなくて、そういったプログラマをアシストするための、
良質なコピペ元の提供
である。
どこの馬の骨かわからない(=ライセンス的に問題があるかも知れない)、品質がどうなのか、性能がどうなのか… というような訳のわからないコードをコピペさせるのではなくて、「弊社推奨」とか「○○プロジェクト謹製」とかというような、素性がわかったものを使い、その品質を担保する。そういった方向の考え方が必要なのだ。
もちろん「コピペプログラマー」が自分で問題だと思って学習して行くことは悪くないし、それは正し方向だ。しかし、「SIerのプログラマ」の大多数(と言い切ってしまう)はそこまでプログラムを書くということ自体にモチベーションはない。
仕事だからやっている
程度のプログラマがほとんどなのである(個人の経験です)。そういったプログラマが大多数だという前提に立てば、「もっと勉強しろ(仕事でもないのに？)」とか言ってもムダなことで、「それでも通用する」という環境を作ってやることが必要なのだ。
会社の仕事というのは学校の勉強とは違う。本人の「本当の能力」なんてのはどうでも良くて、大事なのは「問題解決の能力」である。だから、結果が出ていればその先は仕事には関係がない。「カンニング」は大いに結構なのだ。
もちろんその結果、「彼/彼女」の能力がどうなるかは知ったことではない。オリジナルでプログラムが書けるようになれば、それはそれで素晴しいことだと思う。とは言え、そうならなかったところで「俺」には関係のないことである。まぁ、「後輩」みたいな関係にあれば、いろいろケアしてやる必要もあると思うのだが、それでも個人的な成長よりは「仕事が出来る」ということに意味があることは忘れてはならない。
そんなわけで、量産型プログラマを撲滅することに意味はない。現にそういった奴等が大勢いる現場であるなら、そいつらに合った環境を提供してやることこそが、問題解決なのである。
余分な話であるが、私自身、ほとんどのプロダクションコードはコピペで作っていると言って良い。そのコピペ元は適当なサンプルであったり過去に自分の書いたコードだったりといろいろであるが、多分半分以上はコピペなんじゃないかと思う。そうすることでプロダクションコードが書けるのだ。まぁ当然同じプログラムを何度も書いているわけじゃないから、「粒度」はとても小さいのだけど。
私が時々「PHP(Java|Python…)は公式には書けないことになっているので」というようなことを言ったり書いたりするのだけど、これは「勉強はしたし書けることは書けるのだが、有効なコピペ元を持っていない」という意味とほぼ同じである。私がコピペをするのは、「自分がスクラッチで書くよりもいいコード」からなので、まずはそういった「目利き」が必要である。ところが、その言語を使った経験が少ないと、そういった「目利き」にはなれない。そうすると、結果としてその時自分が書くコードはその時の自分の能力が限界だということになって、とてもプロダクションコードと言えないものになってしまうかも知れない。それ故、「公式には書けないことになっている」ということになるのである。