Seasar2によるスーパーアジャイルなWeb開発

『Seasar2によるスーパーアジャイルなWeb開発』発売記念
ひがやすをさんインタビュー［後編］

ひがやすをさんインタビューの後編は，本書のコンセプトにもなっているSeasar2の「スーパーアジャイル」にまつわる話題から，今後のSeasarはどうなっていくのか？ そして本書を読まれる皆さんへのメッセージをいただきました。

スーパーアジャイル－生産性を上げるために

―Seasar2で開発者の生産性に貢献したいとおっしゃいましたが，それを端的に表したのが，「スーパーアジャイル」ということですよね。

「スーパーアジャイル」自体はマーケティング用の言葉です。Agile（アジャイル）というのは本来，きっと精神的なところが一番大きいと思うんです。たとえば，モチベーションを重要視したり，人と人との会話を大切にするというのが，もともとあったアジャイルの考え方だと思うんですけど，それは少し置いておいて，マーケティング的なことで言うと，ちょうどスクリプト言語とかRailsがJavaなどの硬い言語よりも良い，と言われていましたよね。

スクリプト言語っていうのは基本的にはアジャイルなスタイル。修正しては試して，修正しては試してという短いサイクルでどんどん開発していくスタイルです。そのスタイルは，私はすごく良いと思っています。ただしそれを超えなきゃいけない。

アジャイルなスタイルは少数精鋭で，優秀な人だったら良いけど，そうじゃない人たちが集まると難しいと言われているように思うのですが，そこまで超優秀じゃなくても，普通にちゃんと本を一通り読んで理解していれば，どんどんアジャイルに開発できるようになってほしいな，という気持ちがあるんですね。

これまでのアジャイルというものをさらに使いやすくする。つまりアジャイルを超えるために，たとえばJavaのような静的言語はIDEの部分や，ツールを使って開発を楽にするという部分はスクリプト言語よりも結構うまくできたり，型情報がいっぱい取れるといった良いことがあるので，そういう硬い言語の良さを活かして，これまでのアジャイルの開発をさらに超える生産性を出していきたい，というのが「スーパーアジャイル」の意味です。

スクリプト言語並みの柔らかさはないといけないんですよ。ホットデプロイのように，アプリケーションサーバを再起動しなくても，どんどんソース書いてセーブすればすぐに試せるという俊敏さはもちろん必要。プラス，そこまでだったらスクリプト言語と一緒なので，今度は硬い言語のメリットを活かしましょうと。デメリットを解消しつつ，メリットをどんどん取り入れることによって，これまでのスクリプト言語のアジャイルを，さらに超えていきましょうということです。

これまでJavaが持っていた弱点は，ホットデプロイがあれば結構解消できる。今フレームワークがすごく発達しているから，そんなにコードって書くことはないと思うんです。たとえばSeasar2は，たいていのコードを自動生成しちゃう，しかもタイプセーフで。そうなると，フレームワークを使っている限り，言語の違いが大きく出るとはないんじゃないかな。もちろん，素の言語どうしで比べると，ある程度差は出てくると思うんですけど，今のフレームワークって，とくにオープンソースだと，相手のことを学びつつ，さらに良くしていこうとお互い切磋琢磨してがんばっている状態なので，もうそんなに差が出ないと思うんです。

そういうフレームワークはどんどん進化していっても，フレームワークだけでは対応しきれないところがあります。これが静的言語だと，さらにコード補完ができたり，タイプセーフだったりと，さらに上を目指せるので，静的言語でやわらかいフレームワークと硬いところの良さをうまく生かすことによって，より生産性の高いフレームワークができるんじゃないかと思いますね。

開発を続けるモチベーションは「人のため」

―先ほどから「開発者の生産性」に繰り返し言及されていますが，それはひがさんご自身の生産性を上げたいという目的もあるのでしょうか？

自分のことってどうでもいいんですよ（笑）。本当はフレームワークのコードを書くのはつらいんです。自分のためだけでは書けません。自分が得するためじゃなくて，人の生産性が上がったほうがうれしいなという思いで書いてるんで。自分がどうのこうのって考えたことはあまりないですね。

たぶん，一番最初にSeasarの0（ゼロ）を作ったときに，みんなに喜んで使ってもらったので，そのうれしさというのがきっかけだと思いますね。人に喜んでもらえるというのは，結構良いものだなと。自分のために努力するのはつらくても，人のために努力するぶんにはそんなにつらくないところが，人にはあると思うんですよ。自分のためだったら，つらかったらやめた方が楽だから，やめちゃえと思うんですけど，人のためにやって，終わったときに「良かった」と言われるとすごくうれしい。人は，頼りにされるとうれしくなる生き物だと思うんです。きっと。

本の執筆もそうです。たとえばSeasar2に関する情報も，ネットで探してかき集めれば，集められると思うんです。ただそれがコンパクトに1つのところにあって，「これを見れば良い」というのがあると，非常に安心感があると言う人がいたので。先ほどの「はてな」や，直接会った方などにも言われました。私は，文章書くのもあまり好きじゃないんですよ（笑）。プログラム書くのがあまり好きじゃないのと同じように，文章も書くのは非常につらいので，できれば書きたくないんですけど（笑）。

あと書籍に関して言うと，本の最初にもちょっと書いてあるのですが，今のJavaって，開発しづらいとか，生産性が低いとか，無駄なことが多すぎると思っている方が結構いらっしゃると思うんです。Javaの開発者もそうですし，Javaに興味がない人たちが興味を持てない理由の一部も，そういうところにあると思います。それは誤解だと私は思っているので，「Javaでもっと楽しく開発できるよ」ということをいろんな人に知ってほしいというのはありますね。Javaの開発者だけじゃなくて，PHPやRubyなどのスクリプト言語の開発者にも，「Javaもそんなに悪くないんだよ」というのを知ってほしい気持ちはあります。

―そんなにつらいのでしたら（笑），いつかはオープンソースの活動もやめてしまうこともあるのでしょうか？

私はコードを書くことも，本を書くことも，ブログを書くことも同じように人の役に立てばいい，と思っているので，表現の仕方は変わることもあると思うんですが，何かアウトプットを出し続けるというのは，ずっとやり続けて行くんじゃないかなと思っています。でも自分のためにやるのは，疲れるから（笑）できません。

―ひがさんご自身に挫折体験みたいなことはなかったのでしょうか？

昨年IPAのセミナーで話をする機会があって，それが「開発者は外に出なさい」といった記事になったことがあったのですが，そのとき話したのが，一度みんなが上に上がるタイミングで自分が上がれなくて，悔しい思いをしたという話です。その時はかなりがんばったけど，上に上がれませんでした。これが自分にとっては挫折と言うわけではないけど，自分なりに考える機会となって，技術者はもっと「自分は何をやっているのか」というのをアピールしなければいけないと思いました。また社内だけではなくて，社外に出て行って，いろんな人と触れあいつつ，自分の評価を外からも高めていかないといけないという話をしました。こうした考え方もオープンソースの活動につながっていると思いますね。

私も，自分がやったぶんは認められたいという思いはあります。好きなことをやらせてもらっていれば，別にどういう評価だって関係ないよ，というのは技術者にとって良くない。やっぱり自分がちゃんとやったぶんは，ちゃんと世の中からも会社からも認めてもらうような形にしないと，後から入ってくる人が，がんばろうというモチベーションがなくなるじゃないですか。今後のIT業界のために，ちゃんと何かやったぶんはほめられるよ，という世界にしていきたいなとは思っていますね。私をそのための良い踏み台にしてほしいです（笑）。

私がこれまでの活動を通して何ができたかというのは，自分ではよくわからないのですが，自分が始めたころから考えると，今Seasar2以外にもSeasarのプロジェクトが70くらいに増えて，開発者にとってオープンソースがそのくらい身近にはなったのかなと思います。

―Seasar2が今ではお仕事になっていますが，そうなるために何か活動されたのでしょうか？

会社は何もしないと認めてもらえないので，外からの評価を見せて，外からこれくらい評価されているのだったら，自分たちも評価しなきゃいけないな，というふうに会社に逆に思ってもらう。そういうことはしましたね。会社に直接は言ってません。会社の中でやったことはもちろん評価してくださいって言いますけど，外でやったものを評価してくださいとは言いづらいところがあります。Seasar2を仕事にしたいと思っていることは，会社にうまく伝わりましたね。

次のSeasarは「Less is more.」

―Seasar2は先ほど言わられたような，静的言語の良さとスクリプト言語の良さを兼ね備えたフレームワークとして完成形に近いと思うのですが，今後はどのように改良していきたいと思っておられますか？

いま考えているのは，いかに機能を削れるか，という点ですね。今のフレームワークとかJavaの仕様もそうですが，いかにできることを増やすか，というところでがんばっていると思うんです。それだと開発者の覚えることが増えて負担が増したり，間違ったときに複雑すぎて，何が間違ったのかわからないといった弊害があるんじゃないでしょうか。

なので，そういうすごく無駄なところをずーっと全部削っていくと，きっと本質的なものだけが残って，意外と本質的なものだけで，いろんな作業ができるんじゃないのかなと，私は思っています。

そのあたりは“Less is more.”（※1）という言葉があるのですが，このコンセプトをベースに次のSeasarを作って行きたいなという思いはあります。

※1）

ドイツの建築家Mies van der Roheの格言。

「作りたいもの」を見つけてほしい

―最後に，本書の読者にメッセージがありましたらお願いします。

この本を読んで知ってほしいのは，Javaでもさくさく開発できることを，実際に手を動かしながら学んでほしいということです。できればコンピュータの前に置いて，見ながら試してほしい。そのほうが感覚がつかめると思います。けっこう絵を豊富に載せているので，パラパラめくっても「こんな感じなんだ」というのはつかめるとは思いますけど。ただ目で見る情報と手を動かしながらの情報では，やっぱり手を動かしたほうが，より脳にいっぱい入ってくるんじゃないかな。よりいろんな部分，五感を動かして試してほしいなと思います。

そして，この本を読んだ後は，何か作りたいものを見つけて作ってほしい。学習が目的の場合と，作りたいものがあるときの2パターンだと，作りたいものがある人は自分で手を動かすから，どんどん新たなことを学んでいける。でも学習そのものが目的だと，学習し終わったあとに，これからどうしようかというところで考えちゃうと思うんです。

そういうときは，何かの真似でも良いし，できれば自分の作りたいものを思いつくのが一番良いと思うんですけど，そうじゃなかったら，たとえばWikiを作ってみるとか，ブログ作ってみるとか，身の回りのもの，これはどうなっているんだろうというのを自分で作ってみるというのが一番いいのかなと。基礎的なことはこの本を読めば，だいたいイメージできます。何かやりたいときに，こういうことをやればいいっていうのは掴めるはずです。

もしくは，過去自分が作ったもので，あまり複雑じゃないもの。あまり複雑だと途中でめげちゃう可能性もあるので（笑）。複雑じゃないけど，そこそこのレベル，コード量があったものでチャレンジしてみるのも良いかなと思います。