Wicketによる開発のこれまでの経緯
Wicketとの出会い
僕は会社の製品リニューアルを担当することになりました。
とはいえ、現行製品自体はちゃんと使えますし、何一つ問題らしいものが見えません。
もう少しカスタマイズがしやすいといいのかなぁと言うくらいで、あまり不満らしい不満はありませんでした。
そんな中、昨年5月頃、Wicketを知りました。
どうも、今までと全く違う開発手法になるなという印象でした。
そのときまでは、JavaはRuby on Railsに比べて生産性が低いと思っていたので、
Rubyを勉強して会社に広めようと思っていました。
しかし、Wicketのことを知ると、「Ruby on Railsは、結局Strutsの延長なんだな。」と思うようになりました。Wicketを使うとデスクトップアプリのように開発できるし、HTMLをビューのテンプレートに使えるので、これは生産性の向上に直結する確信が持てました。
8月ごろから本格的に本を読んで勉強し始めました。
10月ごろから、いよいよWicketを使って、製品を作り直すプロジェクトを始めました。
開発の経緯
最初の僕の考えでは、Wicketに細工を施して、ViewだけWicketにして、バックグラウンドは現行のコードがそのまま動くようにしようという方向でした。
ただ、それだとあまりに無理が多い構成にどうしてもなってしまいました。
自社開発のフレームワークが、Strutsのようなアクションベースの開発を前提として、内部的にガチガチになっていたのです。
こういうことは、技術レベルの高い方はあざ笑うかもしれません。
「今時はDIを使って、ORマッピングをするのが普通でしょ？」
でも、今だから言えるのですが、これは、このコードを書いた当時としては最適の決断だったということです。
実際、僕は１プログラマーとして自社のフレームワークは使いやすいと思っています。
それはすごいデザインパターンを使っていたとかそういうのではなく、初期の技術者たちが、
使いながら、かゆいところに手が届くように、当時としては適切に対応してきたということだと思います。
ちょうど今、
これを読んでいて、
現実主義者 vs. 理想主義者の話が、まさしく（うちとは規模が全然違いますが）同じ話なのだと思います。
そこで僕がとるべき選択は３つでした。
- Wicketをあきらめる
- なんとかインターフェースを同じにして無理矢理対応させる
- Guice + ActiveObjectsのような、現在の標準的なアーキテクチャに追従し、プロダクトは１から作り直す
ここを僕は2番目の選択をしてしまいました。
その結果わかったことは、生産性も、効率性も、先進性も何もない、明らかにいびつで、明らかに脆弱で、明らかに読みづらい滑稽なフレームワークでした。
まだWicketの機能を深く知らないままにやってしまった若気の至りです。
もう少し謙虚にWicketの勉強をしてみると、僕が一生懸命作ってきたものは、Wicketの機能として既にあるものばかりでした。
方針転換
そこで、まず僕が作ってきたものを削って行きました。
それでも、まだうまくいかない。
社内フレームワークと、Wicketの相性がいまいち良くないのです。
ここで、
- このままのアーキテクチャで進めるのか
- 全部作り直すか
の選択に迫られました。
時既に開発に入ってから6ヶ月！
いい加減成果を上げなければならないというプレッシャーに駆られていました。
オープンソース化
もう僕一人だけで、このプロジェクトを抱えることに限界を感じました。
相談相手だけでも欲しい。聞いてもらえるだけでもいい。でも、会社には僕以外にこのプロジェクトに人を当てることはできないようです。
いろいろ考えた結果、僕はこのブログを始めました。
もちろん、会社には許可を取って仕事の内容に言及しています。
ブログをやってみると、思った以上にすばらしいコメントやトラックバックを受けました。
でも、ソースコードを公開していないので歯がゆいと感じました。
そこで、さらに会社に相談しました。
ソースコードを公開していいですか？
かなり奇抜なアイディアですが、議論を重ねた結果、GOサインが出ました。
ソースを公開してから
少し準備をしてから、ソースコードを公開しました。
ソースを公開したからには、独自体質を脱却する必要がありました。
そこで、今まで作ってきたフレームワークを破棄し、Seasar2などのメジャーなフレームワークに乗ろうという決断をしました。
これがここまでの流れです。
プロジェクトの成果
ここまでで僕は会社に何も成果を上げられていません。
また、当初の、「社内主力製品をWicketを使って便利にする」という方向性から若干ずれてしまっています。
そこで、再度、相談をしまして、次のように決まりました。
- Wicketによる次期製品をリリースを遅らせる/凍結するが、Wicket、およびオープンソースの研究自体には投資を続ける
- 社内製品開発については、現行のものをなるべくいじらない形で必要な機能を追加する
ということになりました。
結果として
社内プロジェクトのメインストリームから外れたことで、僕の業務時間のすべてをここにコミットすることはできなくなりました。
しかし、作業が空いている時間は業務時間内であっても、こっちに時間を自由に割いて良いことになりました。
そうすると、もはや、「社内のために製品を早くリリースする」というプレッシャーもなくなりました。
僕はこのプロジェクトをやりながら、いろいろなことを学びました。
今までは、社内にいて「仕事を片付ける」ことにしか目が向いていなかったでしょう。
今は外のことに興味が向いています。
ここで得たことをそろそろ会社にフィードバックしたいと思います。
ここで理想と現実の問題がはっきりしました。
理想主義で行けば、古いものは捨ててしまうことかもしれません。
でも、現実的に考えれば、一気に理想へ向かうのではなく、毎日半歩ずつ進めていった方が、みんなもついてきてくれると思います。
だから、メインストリームでは、会社の製品を半歩ずつ前へ進めていき、サブストリームでは、Wicketを中心に新しいことを追いかけて行こうと思います。
何を作るのか。BirdieMartはどうなるのか？
それについては今考えているところです。
もはや作るものはECである必要すらなりました。
ただ、現時点で僕が作れるシステムはECしかないのと、ECは、お金や物の流れを扱う基本的な仕組みなので、色々なものに応用が利くとも言えます。
ここは、会社からの機能要望を全く無視して、超シンプルなものを先に作るということもありかなと思っています。
