SQLの担当は分けるべき - SQLer 生島勘富のブログ

おそらくSQLほど差の大きなスキルはない。

　SQLはスキル差が非常に大きい。
　本当にできない人はどうしようもなくできない。
　SQLは仕様書であってプログラムではないのですが、その感覚がつかめないと習得は非常に難しい。

　オプティマイザという人間に比べると杓子定規で出来の悪いプログラマに、如何に分かりやすいSQLという仕様書を書いて上げるかを考えて書かないと行けないわけです。アルゴリズムはオプティマイザが作るものなので、仕様書であるSQLはトップダウンで考える必要がある。それは意識してアルゴリズムを作ってきた通常のプログラミングとは発想が逆になるので、全く反対のイメージを持つしかないのですが、一度、嫌いになったり、他の言語のイメージが抜けない人はいつまで経ってもできません。

　よりよいシステムを作るには、できない人をできるように教育するか、できない人とできる人に担当を分けるべきです。

従来のスケジュールと人員配置について

　できないこと自体は問題ではありません。しかし、いにしえよりの伝統でプロジェクト自体がこんな風にスケジュールされ人員配置されています。

　このようにスケジュールし担当を分けると、RDBに関する部分とユーザインターフェースとを同時に設計することになり、逆の発想で考えるということが非常に難しくなります。もちろん実装も、逆の発想のものを同時に担当することになり非常に難しいです。仮に、設計者がSQLを熟知していたとしても、実装する人がついて来れないとしたら、それを考慮して設計をせざるを得ません。

　結果的に「全員ができるやり方」を選択せざるを得ない、つまり、できない人に合わせる必要が出てきます。そのため、古典的ウォーターフォールでは、SQLを使い切る設計・実装にすると非常に非効率なのです。

　アジャイル開発を選んでいても、基本的に古典的なウォーターフォールを引きずって、機能単位に担当を割り振りしてしまいますから、ほぼ同じ結果になります。O/Rマッパーなる珍妙なものが世の中に出てくるということは一つの現実ですし、人員配置は私がコの業界に入った15年前からほとんど変わっていませんから、それを正しいと本気で考えている人も居るのでしょう。その先があるということは夢にも思ってない。

　できない人に合わせ、それが非効率であったとしても、スケジュールに沿って終われば成功事例になります。それが正しいことになってしまいますから、永久にそれ以上伸びることはありません。つまりそれは、技術者としての死を意味します。

スキルの専門性を考えたスケジュールと要員配置

　スキルの専門性が全く違うのですから、スケジュールも要員配置も、モジュールも分けるべきです。スケジュールを分けるということは、それぞれ別モジュールを単体でテストする必要があります。

　そのためにストアドプロシージャを使ってDBを隠蔽します。

　このように分ければ、古典的ウォーターフォールよりも工程が増えますが、ユーザインターフェース側は設計担当者も実装担当者もごく僅かですみます。というか、早晩、同じ人が設計実装を担当することになり、アジャイル開発に移行することになるでしょう。慣れればDB側も設計・実装を分ける必要がなくなり、「テーブル設計以外の設計工程は不要」になって安全にアジャイル開発に移行可能です。

　ウォーターフォールに慣れた人でも安全にアジャイル開発に移行することができます。

　もっといえば、ユーザインターフェース側は顧客のシステムに詳しい人でも作ることが可能になるでしょう。顧客自身が、自分が一番気になるユーザインターフェースを自分で作ることになりますので、最もコミュニケーションギャップの小さくできます。顧客自身がユーザインタフェースの実装まで行った後、SQLが十分にできる人がDB側を担当すればシステム開発の人員は数分の一になる。

　実際には、SQL側はスキル差が非常に大きいので、慣れるまで従来と同じ工数を見込んでおいて、徐々に下げていけば非常に安全に移行が終わりますし、教育コストも出せます。

成功事例？

　従来型のスケジュールや人員配置は、COBOLから急激にオープン化を進めなくてはいけなかった時代に、時間も事例もなく本当に酷いデスマーチの中、COBOLerができるだけ違和感が少なく移行できるように作られたあだ花のようなものです。中に、工数に余裕があるプロジェクトがあって、それが成功事例として扱われ、それが文化として定着してしまって今に至っています。

　文化として定着すると、どんなにRADツールが進化しようとウォーターフォールから抜けれないし、アジャイル開発に移行したとしても肝心の要員配置は同じままです。

　プロジェクトの成功なんてものはいい加減なものです。

　普通に作ったものの100倍の工数と10倍の納期を掛けても、最後までオンスケジュールなら、完璧な成功事例となってしまいます。死人が出るほどのデスマーチも、終わったときの倍の納期と工数の見積になっていたら完全な成功事例です。

　デスマーチになった案件というのは、単純に工数と納期の見積に無理があっただけ。最後までオンスケジュールというのは、成功ではなく、ただ計画通りにいったに過ぎません。

　間違った成功事例ではあるけれど、成功ですから担当者は出世していきます。まあ「真っ当な工数をもぎ取ってきた」と営業的には大変評価できますけれど、技術者としては評価しがたい。ところが、技術者として間違って評価されていたりするから問題で、後輩達も技術者としてそれを成功事例と考えてしまって、文化として定着してしまた。

　必要なスキルが違うのに、スキルではなく機能単位に担当を割り振る馬鹿げた現状に、誰もおかしいと思わないということは、気づかないうちに文化になっている証拠です。

機能毎に担当に分けるな。

　機能毎に担当に分けると、ユーザインターフェース側の言語にSQLという異物が混入して見えます。そりゃ、隠蔽したいでしょう。隠蔽すべきです。

　機能毎に担当を分けていたら、隠蔽する先がストアドプロシージャというのは、作業も思考も完全に切られてしまうため何とも具合が悪い。O/Rマッパーも、LINQも、単純なSQLでユーザインターフェース側の言語でなんとかする古典的手法を発展させたものです。つまりは、COBOLerがなんとか対応しようとして作った文化から抜けれてない。

　機能毎に担当を割り振るならば、O/Rマッパーも、LINQも、単純なSQLでユーザインターフェース側の言語でなんとかする古典的手法も、正しいことになる。でも、私から言わせれば、それが正しいと感じる思想は、COBOLerの文化を受け継いだけの、COBOLをやってないCOBOLerの考え方なのです。

　そのわけ方を続けた結果、SQLから逃げようと思えば逃げれますから、SQLがちゃんとできる人がどんどん少なくなる。負の連鎖、マイナスの雪だるまの方へ転がっていきます。

　結果として、本来、ユーザインターフェース側の言語が担当すべきリッチなユーザインターフェースも伸びないし、私がコの業界に入ったころの数百倍のスペックのマシンを使っても、未だにパフォーマンスの問題が起きたりします。

　全く専門性が違うものを同じ人に割り振る。それを前提に考えるから、リモコンをラップするものを一生懸命開発したりする馬鹿な努力を繰り返すことになる。それは、担当を分けない構造を維持しようとするくだらない努力でしかない。繰り返すけれど、COBOLerがオープン系に入ってきたときから根本は変わってない。

　担当を分けてそれぞれ、特性を活かす方向で努力すれば、システムのパフォーマンスは今ほど悪いわけはないし、ユーザインターフェースはもっともっとリッチになるはずです。特性が違うものにはそれぞれの専門家をおいて、専門家が担当すべき。専門性が要るものを別のものでラップするのは、問題から逃げているだけの話で、まともな技術者のすることではない。

　……もし、専門性を持った分業体制になったときは、ユーザインターフェース側しかできない人の技術者としての価値はかなり落ちることにはなるけどね。今の半分以下の人数で事足りる。それは、不況だしちょうど良いと思うのだけれど。