2008-02-09
■[プログラミングその他]素人が素人のまま仕事を出来てしまう

PHP はやはり良くないツールなのかもしれないと思いました。
私は PHP のことを良く知らないので、単なる「思いました」なのですが、PHP に関するいろいろなエントリと、私の ASP での底辺開発現場の経験を ミックスすると、どうもそのような気がしてくるのです。
これまで 「PHP 酷い」を聞いても、それでも PHP 自体に罪はなさそうにおもっていたけれど、今回はじめて「実は PHP にも罪があるんじゃないかしら」と疑問におもった次第です。
そんな疑問のきっかけになったのは、関数禁止令です。
* * *
筋肉炒飯 - 【逆説】PHP を使いつつ思考停止をすると頭脳が腐敗する さんのエントリはなんかすごくデジャブで、一連の PHP ネタの中では、群を抜いた共感度 No.1 でした。
私が見たのは ASP での開発現場でしたが、
別に他のプログラミング言語であれば劇的に改善するというものではないし、たとえば Perl を使って目も当てられない開発をしている現場も何度か目にはしたが、それでも底辺層の環境の平均は PHP よりましなはずだ。
筋肉炒飯 - 【逆説】PHP を使いつつ思考停止をすると頭脳が腐敗する
これには激しく同意してしまいました。確かに底辺には差がある!
当時、「自分も大概底辺を見てきたよね」と自負しながら(w その現場にやってきたのですが、このASPの現場を見て、下には下があるのだと戦慄ししました。元いた底辺な環境でさえ、素晴らしいものに思えた、それくらい酷かったなぁ、懐かしいにゃ。*1
そこに追い打ちを掛けたのが、
最もひどい話だと、関数を使うと処理があちこちに飛び火して把握が難しくなるという知能に重篤な障害があることを疑ってしまうようなひどい理由から、コーディング規約で関数を使うことが禁止されていたことがあった。
筋肉炒飯 - 【逆説】PHP を使いつつ思考停止をすると頭脳が腐敗する
のデジャブっぷり。ああっ!そういえば私も関数禁止例を見たのは ASPな開発現場だった!(「関数化しない言い訳」じゃなくて、プログラマが関数を一つ作ることすら禁止するということ)
関数を使ったコードの抽象化は、プログラマの基本的かつ重要なツールだから、これを禁止されてしまえば、正直話にならない。コの業界が酷いから、プロなのに上手く関数を使えないのは確かにいます。しかし、せいぜい「社員全員が上手く使えない」止まり。ナンボナンボでも関数禁止はあり得ません。どんな酷いところだって。――なのに、ある!? 酷さの底が知れないよぉ・・・。(今鮮やかによみがえる驚愕の記憶)
なんだろ、この類似点の多さ・・。それまでは漠然と「Web 開発って酷いところはホントに酷いよ..」くらいにしか考えていなかったのですが、ここに来て ASP や PHP みたいなのと 底辺の酷さに、やっぱり相関関係があるようにおもえてくる。うーん、あるとしたら、それはなに?
そんなとき
とりあえずはツクールシリーズみたいなWebアプリツクールがあって初心者はそれでアプリ作成、物足りなくなったらソースでって感じ
時代はオブジェクト指向なんだし、そろそろ言語離れ - それ
を読んで、これだ! と思いました。つまり、プログラム作成業の従事者には(分業という意味ではなくって)
- プログラミングしている人
- プログラミングしないでプログラムを作っている人
の2種類がある。で、後者が存在できる環境は希であって、この底辺の差は後者が存在できるか否かじゃないのかしら。
* * *
あたしたちプログラマは、ユーザが欲しいというモヤモヤっとしたイメージのものを分析し、その本質を探し当て、それをズバリ コードに落とすのがお仕事です。この「本質」を見つける作業は、プロの仕事のプロたる所以なのですが、だからこそ難しいし、素人は躓く。まつもとさん曰く「素人は抽象化が苦手」ですが(orだからこそ)、「本質捜し」のほうがもっと苦手だと思います。こちらを取り除く方が素人にはより福音かと。
素人に難しい「本質捜し」を「どうにか」するには、どうしたらよいか。このシンプルな解決作が「『本質捜し』をしなければよい」です。「本質」をコードとして具現化しない設計*2であればよいのです。
一つのアプローチは、この「本質」の実装に入り用な、関数とか抽象データ型といった抽象化技法のサポートを辞めること。古き良き手続き型のフラットな処理の羅列。本来「本質」が顕現するときに現れる 表層的な処理の羅列をただ記すだけの設計は、保守性や可読性・品質に劣り、ある程度の大きさ以上のプログラムになれば作るのに大きな労力が必要になりますが、一方で素人が最も容易に行える設計です。
もう一つ、「本質捜しをしないでプログラムを作る」を実現する手っ取り早いモノとしては View を拡張するだけでプログラムが作れてしまうモノでしょう。たとえばVBのフォームを主体としたものとか。そして、ASP や PHP のような 「HTMLにロジックを埋め込める」なシステムとか。このアプローチはとっても有効です。だって誰もが想像しやすい ページの見た目(View) をとっかかりに、コチョコチョやってしまえば、大抵はちゃんと(?) 動くWebアプリが作れてしまうんですもの。
ようするに、素人は目に見えるモノをそのままの形でソフトウェアに落とし込むことが実現できるツールが快適なのかな、と思います。
* * *
これら素人向けアプローチは悪いことではなく、本当にチョコチョコしたツールを個人で素人がつくるにはとても良いことなのです*3。また、素早く手軽に何かを実装する為の言語デザインが「モデルをつくらなくても動いてしまう」は副作用を持っていて、素人にも扱いやすかったというケースもあるでしょう。
でも、そう言うツールの力を借りて、仕事でも素人のままで居てしまう、素人仕事をする「プロ」が残念ながら多いのです。
「画面仕様」なるお絵かきだけあって、そこから分析も何もせず、ただでっち上げでアプリをつくってしまう。DBのテーブルは画面のテーブルとだいたい一緒で、だから画面の表示項目が一つ増えれば DBのテーブルも変わる。作業分担は、ページ毎に各プログラマに丸投げ。普通はこんなんやったらうまく行かないけれど、ASP(そして多分PHPも) なら何とかなってしまう。
大抵のプログラム開発環境は、素人のままでは仕事ができないから、向上心がなかろうが下手くそだらけだろうが、それでも素人のままということはないです。しかし、ASP は(そして多分PHPも) プログラミングについて素人のままでプログラムが作れてしまう。
これが底辺の底っぷりの差として表面化します。
とんでもないことを言う奴はどこにでもいるけど、「とんでもない」を全員に強制すればいくらナンボナンボでも暴動が起きるだろうと思います。たいていはここまでの無茶はそうそうまかり通らない。
しかし、そんな「いくらなんでも」な関数禁止を是とする村社会が、現実に実在できてしまうのは、その構成員がプログラミングをしないでプログラムを作っている人たちだからか!――と思った次第です。
* * *
最後に、私には「ASP の酷い開発現場」の経験はあっても「PHP の酷い開発現場」の経験はないので、空想が過ぎる面があるかもしれません。そのときはごめんなさいです。
また、「PHP には酷い人材を(業界で)生かせてしまう負の副作用がある(かも)」というのが主旨で、「PHP だからダメ」とか「PHPerはだめ」ということでは決してありません。
*1:このような現場はプログラマとしての自分もダメにします。きちんとやればやるほど莫迦をみるという次元の話じゃなくて、きちんとやることが許されない。たとえば、関数化したところをフラットに書き直せという理不尽な指示がでたりして、でこの指示がどうにも縦割りな中ででているので、変えようにも変えられ無くって、この中で生き残るにはダメにならなくてはいけないのだなぁと、しみじみ実感しましたり。
*2:設計しないというか、分析しないでそのまま表面をなぞるようにソフトの構造を決めてしまう、そんな設計
*3:素人が「ちょこちょこ」でWebアプリを作れてしまうことに対するセキュリティ面での問題定義が、まつもとさんの火種となったエントリでした
- 289 http://d.hatena.ne.jp/JavaBlack/20091031/p1
- 130 http://b.hatena.ne.jp/hotentry/it
- 77 http://reader.livedoor.com/reader/
- 34 http://twitter.com/
- 33 http://d.hatena.ne.jp/
- 29 http://b.hatena.ne.jp/entry/d.hatena.ne.jp/minekoa/20080209/1202577998
- 29 http://www.google.co.jp/reader/view/
- 25 http://b.hatena.ne.jp/entrylist/it
- 25 http://b.hatena.ne.jp/hotentry/diary
- 22 http://b.hatena.ne.jp/entrylist
以下、わりと暴論です。ネタと思ってください。
私は、プログラマーとツクール系職人との住み分けをすればよいかなと思っています。
プログラマとなりえない開発者は、そのままでいいと思います。
ツクールによる開発も、割と需要があると思うのです。
ですが、そのような仕事は、プログラマーにとっては
あまり興味深いものではありません。
それらの仕事は、毎回、同じように要件定義をして、
毎回、同じように開発・テストして
毎回、同じように仕様変更して、
同じことの繰り返しを嫌うプログラマーは
このような仕事に長く従事することが難しいと思います。
でも、「素人」は、飽きずにそれらの仕事をこなせます。
彼等は、何の疑問も持たず、どんな繰り返し作業でも容易にこなせます。
皮肉でもなんでもなく、これはプログラマーにはない彼等の長所です。
(繰り返し作業に疑問を持つ人、何とか自動化できないか、
そんな発想を持つ人は、”変人”です。「素人」の素質がないと言えます。)
ツクール系開発は、そういった種族に任せればいいと思います。
そうすれば、プログラマーは退屈な仕事から解放されます。
プログラマーは、彼等に、よりよい作業環境を提供してあげましょう。
プログラマーと彼等の間に上下関係はありません。
プログラマーから見れば彼等はユーザなのです。
だから、「素人」という呼び名は聞こえが悪いので
もっと彼等を尊重した呼称があればなぁと思います。
あと、ツクール思想を補強する理屈をひとつ言ってみます。
ERPなんかで既に実践されてることですが、ツクールの方法論として、
「ツクールをソフトウェアのカスタマイズ用ツールとして利用する」
というのがあると思います。
ソフトウェアの基本部分が出来ているわけですから
ツクールによる「素人」の開発箇所が少なくてすみます。
これにより「本質捜しをしないでプログラムを作る」場合に、
品質の劣化をある程度、抑えることが出来ると思います。
私も、似たような処理を関数化して使い回すべきだと考えて、関数を沢山つくったことがありました。
ところがそのシステムは関数呼出が20回ほど続くとスタックオーバーフローでシステムダウンしてしまいました。しかたなく、途中で別プロセスへデータを送るようにして関数呼出が連続しないようにしたという顛末です。
参考になれば幸いです。