いま、jflute は DBFlute をどうしたい?

DB変更に強いがわかったとき

いま、DBFluteの紹介ページを見ると...
 => DBFlute IntroductionDB変更に強い をテーマにした開発支援ツール」

というのが真っ先に出てきます。
DBFluteの特徴を最大限表現したもの、
ということで、途中からこういう風にしています。

昔はここまで前面に出してなかったかもしれません。
もちろん、大きな特徴のひとつではありましたが、
昔はDB変更しないプロジェクトも多かったし、
jfluteの中でもその特徴自体が当たり前になっちゃって、
同じことを言い続けるのもなんだか気が引けちゃって、
ってなことも、少しはあったかもしれません。

...

時代は変わり、ビジネス要求は、
変化とスピードをさらに備えてきました。
いわゆる受注の業務システムじゃない、
Webサービスのような開発も増えてきました。
DB変更は日常の風景になってきました。
DBFluteの非常に「古風な」特徴が、
Apache Torque から引き継いだ特徴が、
大活躍するようになってきたのです。

ちなみに、
それを発見してぼくに教えてくれたのはズバリ、
DBFluteを
「非常にタイトなリーンスタートアップ」
で使ってくれた...
Leihauoli, Bizreachstakeuchi さん。
ConditionBeanがスピードの糧になり、
その後のインクリメンタルなフェーズでも変化に耐える、
Webにフィットするって「概念!?」を教えてくれました。
ありがとう、感謝という言葉を無限ループさせたいです。

ユーザーの方から、
作者も気付かない役割を教えてもらえるという、
これもまたオープンソースのおもしろいところ、
といえるかもしれませんね。

スタートアップを支援したい

DBFlute自身は弱いフレームワークです。
バックグラウンドもなければ強いブランド力もない。
商売と同じです。差別化を図らなければ生きていけない。
DBFluteの最大の特徴を前面に出さないとね、
ってことで、いまの Introduction にしました。

幸か不幸か、Javaは、Webサービスの世界では、
あまり強い印象がありません。(個人の感想ですが)
巨大業務システムの世界では最強のJavaフレームワークでも、
スタートアップの世界では苦戦してると感じます。(個人の感...)

でも実は、スクリプト言語とはまた違った方向性で、
Java...というかコンパイル言語が、
スピード重視のWebの開発でも活躍できる「技」
があると考えています。
それちょっと、チャレンジしてみたいじゃん...

それゆえ、こう書いてるわけですね。

o リーン・スタートアップ&インクリメンタル開発
o 設計しながら実装する開発 (納期の短い開発)

ちょっと挑戦的かもしれませんが、
どちらかというとjfluteの決意と言えるかもしれません。
そういうフレームワークにしたい...そう、

スタートアップを支援できるフレームワークにしたい

個人的に身近なところで、
そういう方々が増えてきたってのもあります。
夢を抱いて、サービスと作ろうとする人たち。
たくさんの困難が待ち構えています。
彼らを助けるツールを作れたらいいなって。

というかまあ...
Webの世界でJavaが使われなかったら、
DBFluteもWebの世界でなかなか活躍できない、
するとWebの世界で仕事ができない!ひー。

...

もちろん、業務システムでも変化は激しくなってきています。
もとより、巨大なウォーターフォールばかりでもないしね。
jfluteの業務経験も「設計しながら実装」の
開発ばかりだったから...
(ウォーターフォールなんて見たことない)

なので、DBFluteのスタートアップへの対応が、
そういったレイヤでも巡って大活躍してくれるはず。
現に、AlterCheck とか SchemaSyncCheck は、
それの典型例かもしれません。

とにかく!

DBFluteの最大の古風な特徴

を、もっと磨いていこうと。

現場指向O/Rマッパー

その前ってどんなことを前面に出していたでしょうか?
それは...

「現場指向O/Rマッパー」

いまも、DBFluteのトップページ の上段に君臨する言葉。
Introduction でもこれがイチオシでした。

先の話でDB変更が前面に出てきて少し陰ってしまいましたが、
いまも上段にある理由、大きく二つあります。
それは...

...
...

まず、ひとつめ:

画像だったから簡単に変えられなかった。

...
...

そして、ふたつめ:

いまも、DBFluteの「現場指向」という思想に感銘して、
「そこが好きで」使ってくれているユーザが、
たくさんいらっしゃるということ。

色々話を聞いてみると、
個々の機能がどうのこうのもさることながら...

現場を優先するその方向性がなによりも気に入っている

こう言ってくれるユーザーの方々がいらっしゃいました。
世の中の流行り、話題、体裁、まるまる捨てての泥臭さ。

昔は、
今よりももっとユーザーとの接点を持つ機会が少なく、
メーリングリストでも機能修正の話が主でしたから、
その現場指向がどのくらい響いているのか、
それを知ることはなかなかできませんでした。
jfluteが言いたいから勝手に言っているだけ!?
...かなって。

だんだん、
Twitterやブログ、DBFluteフェスのような勉強会、
そういったところでユーザーの発信を、
たくさんキャッチできるようになって来ました。

現場指向というチャレンジな言葉。
この言葉は曖昧な言葉ではあります。
jfluteはすべての現場を知っているわけでもありません。
ときに誤解を生むこともあります。

そういったものに否定的な反応をする人もいるでしょう。
そういう声も聞いたことだってあります。

一方で、DBFluteを使った人からよく聞く言葉、

かゆいところに手が届く

最初は、現場指向?なんのことやら?
という感じで実際に使ってみたら納得!
というエピソードもたくさん頂きました。
それは、いまも昔も変わらず。

紹介文の最前面のテーマではなくなっていますが、
DBFluteを支えた根本の思想であることには、
変わりありません。その「作り」がないと、
DBFluteはここまで来れなかったし、
それがDBFluteの数多くの機能の起源でもあるから。
だから、現場指向もいまも昔も変わらず、
ぼくが大切にしていきたいことです。

というか、この曖昧な言葉に、
さらなるチャレンジをしていきたい!
って。

どうチャレンジするの?

最初は自分自身の経験と分析と想像の貯金で、
現場指向を作り上げてきました。

ぼくは大昔から、
「プロジェクト」を見るのが好きだったかもしれません。
新しい現場に入っては、
じぃーっと周りの人やプロマネの人を見て、
こういう風にならないか、ああいう風にできないか?
おおぉ、これはすごい良い!真似したい。
逆に、あれはどうすればよかったんだろう?

プログラムレベルでも、
フレームワークがこうなっていれば、
ツールがああなっていれば。DBがこうであれば...
こう書いていればこういうことは起きなかったのでは。

って、勝手な妄想をバンバン膨らませて、
分析とイメージトレーニングをしてきました。
これは勝手に。自分でも勝手に考えちゃう。
そのプロジェクトから離れて後でも、
ふとしたときにずっと考えちゃうんです。
それを繰り返してきました。

...

でも、やはり一人の経験と時間では、
この多様化の時代の現場は体験できません。
絶対に偏りはありますし。

実際、ぼくが行ってた現場は、
SIと言っても小さなサバイバルベンチャーだったり、
受注と言っても BtoC ばかりだったり。
世のSIネタ、よくある「つらい話」
実は半分はわかるけど、半分は知らないことも...

そこで、大切にするのは ヒアリング です。

あらたまって現場の人に話を聞く、
って感じのいわゆるヒアリングもありますが、
もっとフランクな感じもあります。
勉強会やDBFluteフェス、
Twitter上やメーリングリストとか、
フィードバックのやりとりの中から、
ちょっと気になったことを質問させてもらったり、
そこで出てきた情報を分析して勝手に想像を膨らませる。

厳密には、DBFluteに関係なくたっていいのです。
現場の話、現場の問題領域、現場のムードを聞く。
現場の問題を解決するのが DBFlute だから、
それがそのまま DBFluteヒアリングです。

jfluteの仕事も、立場と役割的に、
一つのプロジェクトのどっぷりつかるというより、
色々なプロジェクトを横断的に見ていくことが
多くなりました。

それはそれで、色々な現場を見ることができて、
ヒアリングのチャンスが盛りだくさん。
一方で、一つのプロジェクトを深く体験する
チャンスは減るので、それを補う分析と着眼点を、
常に意識しています。
一つ一つの関わりは深くはないけれども、
深く関わっている人たちになったつもりで、
問題を一緒に考え悩む。

それが DBFlute の改善につながって、
それをまた現場の人に提供する。
そしてまた現場の人と一緒に考える。

いま、その循環ができる仕事ができているので、
すごくよい環境にいます。現場に感謝です。

...

jfluteの経験とその分析、
人から聞いた疑似体験に最大限の想像と分析、
さいごにバランスを悩みに悩んで、判断をする。

これがjflute流の現場指向の行動ですね。

...

簡単に言ってますが、
最後の最後の「悩みに悩んで」は、
色々ながんじがらめのジレンマを抱えて、
本当に「振り絞るように」最後に判断するんですよ(^^。

DBFluteのそばにいること

そして、もうひとつ大切にしていること。
DBFluteを使っている現場に関わる仕事をすること。

これがいま、ぼくが仕事上心がけていることです。
何年も何年も前から。
そういう意味では、ぼくの仕事選びはわりと単純です。

DBFlute自体は単なるサービス構築のための道具ですが、
その道具を高めていくのがjfluteの役割ですから。
それがぼくのオープンソースビジネスとも言えるので。

やはり、
「作者が自分で使っていないツールを使う」
ってのは、少し寂しいじゃないですか。
そのとき、ユーザーの方はどう思うでしょう?

...というか、その状況は時に、
致命的な判断ミスを犯す可能性を秘めています。
現場指向のフレームワークが現場感のない判断をしたとき、
果たしてそのフレームワークは生きていけるでしょうか?

生活も絡むので100%確実にってのは難しいですが、
できる限り、

DBFluteを使った現場のそばにいられる仕事

をやりたいと思っています。

いまは、先の通り、
非常に良い環境でそれができています。
そんなチャンスはなかなかないでしょう。
だから、もっともっとバリューを高めていきたい。

集中力を高めて、DBFluteユーザーを高めたい

DBFluteで支援しつつ、DBFlute以外のことでも、
最高のパフォーマンスをみんなに届けたいと。

なので、いくらでも、
自分を鍛えるモチベーションが途絶えません。

現場のプロフェッショナルに贈る

そう、現場に寄り添っていることで、
よくわかってきたこともあります。

えーとぅ…
そのぅ…

「DBFluteは万人向けのツールではない!」
って(><。

いまさら!? って思うかもしれませんが、
やはり昔は「多くの人に使ってもらいたい」
という気持ちがありましたが...
(というか、いまもそりゃそうなんですが)

Hibernateのような超高機能O/Rマッパーほどの
難易度はないつもりですが、
何も勉強せずに使えるかっていったら、
やはりそんなことはありません。

特に ConditionBean は、
RDB (リレーショナルデータベース)
というものを強く意識したインターフェースです。
ディベロッパーも、
リレーションシップへの意識が求められますし、
IDEの補完を使って実装することも求められます。
やはり最初ある程度のトレーニングが必要です。

アーキテクトという役割の人がいないと、
現場フィット機能を横展開することもできません。
欲を言えば、同時にDB設計の視点を持っている人、
RDBへの心理的距離が近い人、すると効果が高い。

そう考えると、
「とりあえずSQLの文法知っていればすぐに実装できる」
というO/Rマッパーに比べれば敷居は高いですよね。
そもそも、それでは得られないハイレベルの問題解決、
少々難しくても現場にフィットする機能たち。
それを目指しているわけですから。

...

そういったことから、
良い意味でも悪い意味でも、

プロの道具

という位置づけがフィットするのかなって、
最近ちょっと思ったりしています。

事実、たくさん出会ってきたDBFluteユーザの方々は、
とても優秀な現場のプロフェッショナル、
そういう方ばかり。
「現場に対して真摯」な方々。

それならそれで、突き詰めようではないですか。
出会いがあってようやくわかってきた。

アイディアと夢

まだまだいっぱいあります。

幾らでも、
「こんな機能あったら絶対いいな」
「こここうなってるといいよねぇ」
って、発想が浮かびます。

なかなかそれを実現する時間がありません。
アイディアが先にポンポン出てきちゃう。

「DBFluteを、こういう風にしていきたい」

ありますよ。
行動もしてる。でも、道は長い。

...

それでも、
たくさんのDBFluteの周辺ツールや、
Example実装などを支援してくれる
ユーザーの方々が増えてきました。

いままで自分一人ではできなかったことが、
どんどん実現しようとしています。
本当に本当にありがとうございます。
すごく嬉しいです。

...

また、数年後、
いまよりももっとすごいことになってるよ。

そんな DBFlute Dream を夢見て、
また行動していきます。