弱い技術者は実はおやじ予備軍

本当の問題は「スーツ + 頭のカタイおやじ VS. 無垢な技術者」という話だろうか。なんで、スーツの人や、頭のカタイおやじや、無垢な技術者がいるのか、その前提条件を問わなくちゃいけないんじゃないのか。その前提条件に、自分がどんな一手を打てるのかを考えて、世界を変えていこうよ。ていうか、世界を変えていたじゃない。

なんか、高井さんが勘違いしているみたいだから、書いておくけど、俺は、「だから世の中が悪い」とかいうつもりはありません。この構図は、過去何度も繰り返されている事実だから、まず私たち技術者は、その事実をきちんと認識しなければならない。
昨日は書かなかったけど、実は、「弱い技術者」というのは、「頭の固いおやじ予備軍」でもだったりする。
実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統一したほうが無難」なんてのは、おやじ予備軍シンドロームだと思う。
常に最新のものが良いといっているわけではありません。常にチャレンジすることが重要だといっているわけでもありません。
重要なのは、「常に自分で考えて自分で手を動かすこと」です。
典型的なおやじ予備軍は、自分で考えるよりも権威のある人にこれだって言ってもらうのを好みます。身に覚えはありませんか。これって頭の固いおやじがスーツなやつらに付け込まれているのと同じです。
自分でコードを書かずに他人のblogでいってることをそのまま鵜呑みにしたり、海外や国内の記事をそのまま信じていませんか。「忙しいから時間ないんだよね」。確かにそうかもしれません。でもそれって頭の固いおやじが言ってることと一緒。
頭の固いおやじが悪いわけではありません。歴史はいつも繰り返されているのです。でも、もしあなたが頭の固いおやじに対して悔しい思いを抱いていてそれを何とかしたいと思うなら、まず自分が変わることです。「常に自分で考えて自分で手を動かすこと」。
試した結果、現状の標準なりデファクトが良いと判断したなら、自信を持ってそれを使ってください。他人の意見を鵜呑みにしているわけではないから、多少のトラブルがあっても対処できるでしょう。
火を噴いた案件は、自分で考えずに他人の意見を鵜呑みにしたおやじたちが引き起こしていることが多いのではないでしょうか。
実は、チャンジャーに見えるRailsユーザもおやじ予備軍の危険性があります。「JavaからRubyへ」でこのような意見があります。Javaの世界はフレームワークが乱立していて適切な組み合わせを選ぶのが大変だからRailsで統一されているRubyがいいんだと。
これには、全然賛成できません。悩みたくないからスーパーなデファクトを望むのは、危険だと思うんですよね。ライバルがいないとどうしても進歩の速度が鈍ります。Rails一党独裁よりも、いくつかのフレームワークが競い合うほうが健全なのではないかと思います。
ちょっと脱線しましたが、いいたいことは頭の固いおやじに不満があるならまず自分がかわれということです。
そのためには「自分で考え自分で手を動かすこと」。
今ね。俺は、めちゃくちゃコード書いてますよ。俺が何を考えて何を作るのか楽しみにしてください。

ぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか?

コードを書くだけなら簡単です。でも、それを維持し続けるのはその何倍ものコストがかかります。それを趣味の範囲でやるのは無理でしょう。

ってのが俺には腑に落ちない。俺趣味*1でRubyのメンテやってますけどあれか、俺が提供してるようなものはままごとレベルだと仰る?だとしたら今後銀行でRails採用するところはありえないのか?だってRuby本体のほうが担当俺なんだし。

まずメンテナンスのコストの話から。メンテナンスのコストは、単にソースコードやドキュメントを修正したりといったことだけではなく、MLやblogで疑問がある人や困っている人がいれば助けてあげなければいけない。単に知識だけで即答できることならまだ簡単ですが、再現ケースを自分で作らなければいけない場合など、それだけでかなり時間がかかります。最近は、フルスタック構成なことが多いので、WEBだとかDBにかかわることだけではなく、すべてが絡み合うことも多いのです。これは結構大変。Railsのメンテナンスがローコストでできているなら、すばらしいことだと思いますが、残念ながらSeasarの場合は、コストがかかっています。
MLならまだ楽です。ユーザのほうから投稿してもらえるから。MLは敷居が高いので、blogに書いて済ませるユーザもかなりいます。そのようなbloggerをいろいろな方法を使って検知して、フォローするのは大変です。コストはかかりますが、私はそのようなbloggerも大切にしています。
単に時間がかかるという問題だけではありません。Seasarを仕事で使われている方が結構いらっしゃるので、質問があれば、迅速に答えてあげなければいけません。質問によっては、それで仕事がストップしているようなことがあるかもしれないからです。
常にそういう人たちに迅速に答えるためには、昼間に作業をする必要があり、一人だけでなく、チームで作業をする必要があります。それを趣味でやるのは、すくなくとも私たちにとっては無理だと思っています。
追記:Seasarなみの分厚いサポート・あるいはクリティカルなサポートを私たちが趣味でやるのは無理です。
Rubyができているのはそれはすごいことだと思います。
きっとRubyのサポートを趣味扱いされたことが気に入らないんだと思いますが、もう一度私の書いた文章を見ていただくと、誤解が解けると思います。エンタープライズな分野でクリティカルなユーザを相手するには、趣味ではやっていけないということです。
Seasarだって仕事でやっている人たちだけではないですよ。ボランティアベースでご好意で参加されている方も大勢います。この人たちのおかげでSeasarも成り立っています。
ただ、クリティカルなサポートは、趣味ではできないということです。
さらに追記:

趣味の活動を否定されるならそもそもSaesarをエンタープライズに適用するのは諦めたほうがよろしかろう。違いますか。

もう一度、私の書いた文章を見てください。

Seasarだって仕事でやっている人たちだけではないですよ。ボランティアベースでご好意で参加されている方も大勢います。この人たちのおかげでSeasarも成り立っています。

趣味の活動は、まったく否定していないつもりです。
そして、何度もいってますが、クリティカルなサポートは、趣味ではできないということです。

コードを書く VS メンテナンス

私が「コードは好きだから書いている」でも「メンテナンスは好きではない」、だから「仕事としてメンテナンスしている」。という風に理解していいて、「本当にメンテナンスが好きなら趣味でもできるはずだ。」という主張なら、その理解していると思っている部分は事実とは違います。
私は、そもそもコードを書くことが好きなわけではありません。私の願いはユーザの役に立つことです。
Seasarがどうして生まれたのかご存じない方も多いと思いますが、羽生さんとこの案件で使ってもらうために作ったのが最初(正確にはもうちょっといろいろあるけど、Seasar0は間違いなく羽生さんところ用)です。
ユーザの役に立つのは、フィードバックを受けてメンテナンスすることだと思っているので、私はメンテナンスすることが好きです。
Seasar2の開発の初期のころは、一週間ごとにリリースしていました。これは、ユーザのフィードバックを即座に反映させるためです。もちろん、これもメンテナンスです。ソフトウェアは、最初に作った後は、ずっとメンテナンスが続くのです。
趣味でメンテナンスし続けることができるなら最高ですが、少なくてもSeasar2の場合は、やらなければいけないボリュームと迅速な対応が必要だったため会社仕事としてやっています。
ユーザにとっては、趣味だろうが仕事でメンテナンスしていようが関係なくきちんと自分の望むメンテナンスがされていることが重要でしょう。
ユーザの望むメンテナンスのあり方は、ソフトウェアの内容によって違うので、「RubyでできているからSeasarでできないのは、お前らがやろうとしないからだ」というのはちょっとだけ違うのではないかと感じました。
Rubyも趣味でメンテナンスしている人も仕事でメンテナンスしている人もどっちもいると思いますが、そこに優劣はないですよね。それぞれの役割をきちんとこなしていることが重要だと思います。