議論の議論は興味なし
ふとしたとき、O/Rマッパーに関する議論が勃発します。jfluteとしては「またかぁ」みたいな感じではあります。
議論のための議論には付き合わない主義
なのであんまり関与しようとしませんが、恐らく若い人の中には真に受けて真剣に悩む人もいるでしょう。
「jfluteさん、どう思いますか？」
って聞かれることもよくあります。すいません、迷惑そうな顔してたりしませんかね...
悩むのは良いことではありますが、空中戦のような議論に巻き込まれて、その人のロジックが歪んだものになってしまうとよくないと思って、というかO/Rマッパーがどうのこうのってのはぶっちゃけどうでもいいんですが、議論の本質追究の仕方や問題解決の思考プロセスが曲がってしまうととくないので、ブログを書いてみました。
O/Rマッパーはどこへ？
O/Rマッパーに限りませんが、特にO/Rマッパーに関しては歪んだ議論は横行します。
そして、以前こんなブログを書きました。
// O/Rマッパーはどこへ (本質追究の議論のために)
http://d.hatena.ne.jp/jflute/20100131/1264881191
ここに書いてあることがほぼ全てですが、今回はさらにちょっとした補足をしたいと。
(最初で最後の記事って書いてたのにまた書いちゃった...)
ビジネス要件でアーキテクチャは変わる
システム開発はビジネス的な要求のもと存在します。極端な例をしてみましょう。
仮に
SQLをベタベタ書いた方がトラブルが少なく、SQLをジェネレートした方が速く作れると仮定します。互いにトレードオフ持つと仮定します。
そして、とある二つのシステム開発があって、どちらも規模的には一般的に7000万円かかると想定。
片方は、ミッションクリティカルでいかなるトラブルも許容できないシステム、9000万円かけてもいいから、リリース後のトラブルは発生させて欲しくないとのこと。こちらはSQLをベタベタ書いて作った方が良いでしょう。
もう片方は、ビジネス要求スピードの速いシステム、機能によってはちょっとくらいはトラブってもいいし、とにかく早くリリースしたいし、5000万円しか出せない。こちらはSQLをジェネレートして作った方が良いでしょう。
これはもちろん仮定の話、別にSQLベタベタの方がトラブルが少ないとは言えないし、SQLジェネレートの方が速く作れるかどうかはやり方次第、他にも要因はたくさんあるので、あくまで仮の世界の話。
ここで言いたいことは、
アーキテクチャの正解なんて、ビジネス要件によって簡単に覆るということ
システム要件ならず、機能ごとにも変わります。オンライン(画面)のSQLと、夜間バッチのSQLでは、求められるSQLも変わってくるでしょう。全然トランザクション数の少ないテーブルで、すっごい厳密なパフォーマンス考慮のSQLを書いたら、時間の無駄だと言われるでしょう。
要求のない世界でアーキテクチャをいくら語っても、半分しか結論はでない
その半分も大事だけど、やはり半分は半分なのです。逆に言うと、それを精度の高い半分にするためには、要求のない世界にいながらも、要求を仮定した議論の中で、アーキテクチャの柔軟な組み合わせを考えるべきです。
僕らにできることは、現場にフィットする多様な組み合わせを議論してその特徴を把握し、いざ現場でそれを実践すること。
DB最適ではなく全体最適
「SQLが書けない人がO/Rマッパーに頼る」という論理を掲げる人は後を絶ちません。ここにとても感情的な問題意識をDI(注入)する人も。なんとかして、"O/Rマッパーを使っている人をSQL書けない人に仕立て上げたい" という思いがひしひしと伝わってくることも。
それが問題であるならば、しっかり問題分析しましょう。
SQLが書けないことは確かに問題になり得ます。やはり、パフォーマンス劣化を引き起こす可能性のあるSQLが次から次へと作り出される可能性があるから。
じゃあ、全員がハイレベルなSQLを書けるべきでしょうか？
システムはDBのために作っているわけではありません
DBだけで成り立っているわけではありません。DBは大事な要素の一つですが、全体の一部に過ぎません。
ディベロッパーのやるべきことは多様化しています。
ハイレベルなSQLが書けて、ハイクオリティなプログラミング(Javaとか)ができて、ハイパフォーマンスなJavaScript/HTML/CSSができて、適切な業務仕様の設計ができる人がいるでしょうか？
ディベロッパー、というか、人の時間は限られています。全ての人が全てのレイヤでハイクラスになるのは難しい。いくら全員がハイレベルなSQLが書けても、Java部分がひどくてCSSも非効率だったらだめなのです。
もっと現実的な策を創造していかないと
誰もハイレベルなSQLが書けないのは確かにつらい。必ずそういう人を連れてくる、もしくは、育てる。それ以外の人には、最低限のことだけ伝えておくとか、SQLコーディングルールを徹底させるとか、ハイレベルなSQL担当に定期なレビューしてもらうとか、短い時間でもハイレベルなSQLを体得できる、効率の良いわかりやすい資料を作ったり勉強会をやるとか。パフォーマンス劣化しやすい機能だけはSQLベタベタ、それ以外は開発スピード重視でSQLをジェネレートするとか。たぶん、やれることは幾らでもあるし、正解はないでしょう。
「おれは書けるぜ、おれは書けるのに書けないやつのせいでおれが苦労するぜ、だから、こうあるべきだ」
残念ながらそれでは現場は納得しません。
それぞれのレイヤのプロが、自分のレイヤの重要性を主張します。自分もその気(け)があります…というか、やっぱり多少なりありました。だれでもあるのかもしれませんね。だから、気持ちもわかるっちゃわかるんですけどね。
自分の得意なレイヤの仲間を増やしたいという気持ちが作用するのでしょうか？まあ、そのレイヤの人口が少ないのであれば、その人口を増やすのは確かに大事なこと。それはそれで、アーキテクチャが悪い、ツールが悪いと言ってるだけでは何も進まないでしょう。
もっと現実的な策を創造していかないと
DB周りに興味のある人がいれば、時間を惜しまず親身に教えてあげるとか、そのきっかけを与える資料を作ったり。ときには、講演会をやったり勉強会を開いたり。
ただ、人に何か伝えるチャンスの場は限られています。例えば、jfluteは、DBFluteというツールを通じて、そういった活動にもつながればいいなとは思っています。少なくともDBFluteは、RDBを強く意識したツールであり、RDBのリテラシー向上につながるツールだと思っています。そういう思いも込めて日々開発をしています。
問題と思うのであれば、様々な手段を創造して、現実的な実践に移していかないと世の中は何も変わりません。
…
ちなみに、DBFluteコアユーザのみなさんは、ものすごくSQLも書けますね。DB設計スキルも素晴らしい。どちらかというとそういう人に好まれるツールかもしれません。
O/Rマッパーもがんばれ
一方で、O/Rマッパー提供側も考える必要があるでしょう。O/Rマッパーを使うことによるデメリットは確かにあるはず。それを少しでも軽減したり、リスクが顕在化しないような努力が必要だと考えています。
例えば、SQLをジェネレートするならば、ジェネレートされたSQLは、改行が入るなりして、「見やすいSQL」としてログに出力される方がいい。プログラム上で組み立てたものがどんなSQLになるか、ディベロッパーがログですぐに確認できるように。一行のSQLだったら、見る気も失せてしまいますから。
SQLのエラーとか、O/Rマッパーの中でのエラーメッセージは、できるだけ親切であげたいものです。SQLベタベタしたい人からすれば、そのラップされた世界は「余計なもの」に見えます。そこが足を引っ張れば、当然遠慮なくいやな顔されるでしょう。
逆に、ラップすることで得られるメリットもあるはず。そのメリットを最大限活かす機能を創造していきたいし、そこをもっと主張しないと伝わらないでしょう。
数え切れないほどの改善チャンスが幾らでも眠っています
細かく細かく継続的にアプローチして、ディベロッパーにO/Rマッパーを使うことによる逆の負担を、少なくする努力しないと、なかなか支持してもらえないでしょう。(耳が痛いぃぃぃ...><)
現場フィット
「SQLベタベタが大好きだぜー、O/Rマッパーきらいー」
って言ってた人が、DBFlute使ったプロジェクトに入って...
「いいじゃん、これぇー」
って言ってくれた人が何人もいらっしゃいます。今年一年でも何人かいましたし、今の現場にもいらっしゃいます。(というか、DBFluteはSQLベタベタ書くのも便利だし)
親身になって、その現場の特徴と求められていること、それに対するツールによる支援の必要性などを伝えました。ちゃんと現場の思いとニーズが合って使っていると。
まあだだ、jfluteの口から直接それを伝えることができるのは、当然のことながらjfluteが関わってるプロジェクトだけ。DBFluteを使ってくれているみんなは、というか、DBFluteを使おうと言ってくれたみんなは、厳しい議論を耐え抜いてきたんだろうと切に思います。
(ありがとう、ありがとう...)
その議論が少しでも楽になるように、jfluteはもっと頑張らなければなりませんね。
