COBOLer からの脱却 - SQLer 生島勘富のブログ

COBOLer の DNA

　IPA の調査では、2009年の段階で96％がウォーターフォールを採用しているそうです。 http://sec.ipa.go.jp/press/20100330a.html

　まさに、ウォーターフォールは一つの文化として確実に定着しています。ウォーターフォールには COBOLer の DNA が流れています。

　年寄りの与太話ではなく、昔々、COBOLer が大挙してオープン系にやってきて、その後、WEBシステムを手がけるようになりました。WEBシステムへの移行が済んでからコの業界に入った人も大勢いるし、入れ替わりの激しい業界ですから、現在では、実際に COBOL 経験がない人の方が多いでしょう。ちなみに私がコの業界に入った頃は「COBOLerにあらずんば技術者にあらず」でしたけどね。私はずっとマイノリティだな（苦笑）。

　しかし、「Javaから入った」「.NETから入った」という人でも、ウォーターフォールに違和感を感じないとしたら、もう、完全に COBOLer の DNA を受け継いでいます。COBOL をやってない COBOLer です。

　ウォーターフォールは COBOL では巧くいったのですが、ウォーターフォールの一番悪かったところは、設計と実装でフェーズを分け、担当者も分けてしまったことです。場合によっては設計と実装で別々の会社が担当することもあり（ってか普通にあるね）、多くの悲喜劇を生みました。10年もやってれば笑うしかないネタをほとんどの人が持ってるでしょう。

　オープン系という言葉があった時代、カウボーイコーディングかウォーターフォールしか選択肢はないほど混沌としていました。もっとも、カウボーイコーディングをやっている本人は、VB や Delphi の「RADツール」という言葉を信じて、プロトタイピングのつもりでしたけどね。当時の COBOLer はイベントドリブンが理解できないまま設計をしていた、なんてのはザラで、どうしようもないほど混沌としていて「SQLがどうとかいってる場合じゃない」「とにかく動くことが正義」という時代でした。

　牧歌的でもあったけれど、今の何倍も仕事があって、そりゃあ、もう、大変な中、COBOLer が中心となって今の体制の原形が出来上がってしまいます。もちろん、属人性の高いカウボーイコーディングでは大きなシステムが動くわけもなく、COBOL で実績のあったがっちりとしたウォーターフォールでオープン系のシステムを作る流れが完成し、文化として定着してしまったわけです。　

　COBOL のイメージが抜けなかったためもあるし、そもそも最終がどんなソースコードになって、技術的にどこが問題か分かってない、COBOL 以外コーディングしたことがない COBOLer が中心となって作った文化ですから、ユーザインタフェース担当と、DB担当という切り分けはできず、機能単位で設計を担当することになりました。もちろん、実装も同じように、機能単位でユーザインタフェースからDBまでを同じ人が担当することになり、SQLは当然のようにソースの中に単なるStringとして存在していました。

　WEBシステムが普通になってきた頃に「リテラルはいくら何でも不味かろう」ということで、O/Rマッパーや、LINQ以外にも、様々なものができては消えていきましたが、ほとんどの考え方は、同じ人がユーザインタフェースとDBを担当するための方法として考え出されたものです。O/Rマッパーができた頃の宣伝文句を思い出せば分かります。「SQLを書かなくてもシステムが構築できます！」ってね。

　そもそもの「なんで違うスキルが要る技術を同じ人が担当するのか」ということが問題視されることは、現在に至るまでほとんどありません。「違う技術を同じ担当者に任せている」という根本的な問題について、問題として認識されることもなく、DB担当というのは、DBのインストールや移行作業、チューニングを行う人のこと（そういう専門家が必要と言えば必要ですが）、という切り分けになってしまったのです。

　時代背景に対する印象は、コンシューマ向けのWEBシステムをやっている会社（非SIer）なら、違う印象を持つでしょう。しかし、設計をひとくくりにしてしまった COBOLer の考え方から脱却できず、そのままの考え方でできたツールや言語を通して、非SIer企業も COBOLer の DNA を受け継いでしまっているところもあります。

　今後、アジャイル開発に流れていくとして、O/Rマッパー、LINQ、その他のものでも、同じ人がユーザインタフェースとDBを担当するために考え出されたものは、所詮はリモコンをラップするもの。SQLが分かっている人から見ると、なんだか意味不明のものをありがたがって「SQLなんて」と思うのは、COBOLer の DNA を正しく継承しているということです。

もし、変わったら。

　まずは、こんな風に分けるべきです。

　96％がウォーターフォールを採用しているということですが、分けたらユーザーインターフェースは、すぐにでもアジャイル開発に移行できるでしょう。DB側は、いきなりアジャイル開発はイメージのギャップが大きすぎるので、一応、設計、実装と分けています。

　しかし、本来的には設計と実装が分かれているのは非効率で、同じ人が担当すべきです。つまり、こんな感じ。

　SIerの巨大案件から、WEB系の小さな案件まで適応することが可能です。もっとも、あまりに小さいなら慣れたやり方をお勧めしますが。

　最近は、新規開発が少ないので、テーブル設計が必要ない（変更できない）ということもあるでしょう。そういうときは、ユーザインタフェースとDBでやりとりするインターフェースさえ決めれば、各々、独自に開発することも可能です。便宜上、ユーザインタフェース側を先にスケジュールしていますが、テーブルが固定されているならDB側を先に開発してもかまわない。

　何度も繰り返していますが、SQLと他の言語は全く逆の技術です。逆の思考が必要になります。同じ人ができないとは言わないけれど、同じ人がやることは非効率です。

　サッカーで言えば、フォワードとキーパーを全員がやるようなもの。全く逆ですから、専任するのが当たり前。フォワードの選手にキーパーをやらせるのは、練習では全く意味がないとは言わないし、コンバートしてはいけないとは言わないけれど、同じ試合でやるのは間違っています。

　システム会社も同じで、ユーザインタフェースとDBを教育として両方やらせることは大賛成ですが、同じプロジェクトではできれば分けるべき。人員構成上無理でも、せめてフェーズは分けるべきです。

　フォワードの選手にキーパーをさせるための技術や道具を開発するよりも、ちゃんとキーパーを育てて、各々の仕事に徹するべきなのです。

　私は極めて当たり前のことしか言ってない。それに違和感があるとしたら、自分で気づいてないだけで、あなたの根底に流れている資質は COBOLer です。