khara@fmsc's weblog

時にはこんな書籍もいかが？　　（別に新刊でもないのですが、私は最近読んでホットなので。）

左脳に支配されているソフトウェアエンジニアリングの世界の方々へ。
そして、次世代へヒントを求めている方へ。

ハイ・コンセプト「新しいこと」を考え出す人の時代　　 ダニエル・ピンク (著), 大前 研一 (翻訳)

この本は、情報化社会(第三の波)後に来る「新しい大きなうねり」(第四の波)とそれに対処する生き方を示す書として注目を集めているようで、特にソフトウェアエンジニアの方には読んで欲しい内容です。情報化社会やITの時代はコモディティ化し、ソフトウェアエンジニア(情報処理技術者)がもてはやされる時代は終わり、コンセプチュアルな時代に移行。その時代を動かしていく力は、これまでと違った新しい思考やアプローチであり、そこで重要になるのがハイコンセプト、ハイタッチな能力であり、左脳主導の考え方を補う形で、右脳的な感性(Design, Story, Symphony, Empathy, Play, Meaning)が道を開く。コンセプチュアルな時代とは何か、ハイコンセプト、ハイタッチな能力って何か関しては、アマゾンの書評なり、ネット検索でもして頂くとして、ここでは省略します。

ブログタイトルの「A Whole New Mind」は原書の英語タイトルで、それがやけに気に入ったので付けてみました。「情報の時代」を引っ張ってきた「左脳的」能力は今でも重要ではありますが、もうそれだけでは十分でなく、創作力や共感といった右脳的な特質が差を決定つける重要な要素になる。ってことで、「A Whole New Mind:新しい全体思考」。Whole(全体)がいいかどうか分からないが、左脳に傾き過ぎてたし、もう左脳だけでは勝てないし生き辛いし、「New Mind(新しいマインド)」が必要とされているのはその通りだと思う。

あと、ナレッジワーカーとして、普通にソフトウェアエンジニア/プログラマが引き合いに出されているし。それも、ごく自然に。もはや専門的な職じゃなく代表的な職業ってわけね。情報化社会っても飽和状態で、普通にＩＴに強いくらいでは生き残れない時代ってこと。左脳だけでももはや優位性にならないのでダメってこと。

ソフトウェアエンジニアはとにかく、ロジック的な思考アプローチとなりがちだし、そうじゃないと作ったソフトウェアは信頼できないのではありますが、ロジック的に納得いかないと判断や行動に移せないみたいなのもどうかと。ふと、そう思うのです。コンピュータだけでなく、生活とかどんな物事にも、すべてロジック組んで判断して生きてしまってると。

まあ、IQとEQみたいな、左脳と右脳みたいな話ではあるのですが、少し頭がほぐれた感じがします。少なくとも、今の時代の呪縛から逃れて閉塞感を打開するには、従来の延長線上で左脳でロジック組むよりも、新しいマインドとか、根本的な発想法や価値観を変えないとダメってところまで来ている感じはしますね。大胆な「CHANGE」が必要ですね。

「新しい技術や手法」も大事ですが、一方で、それよりも「新しいマインド」ですよー。

この大不況のせいか、いやはや社会的な閉塞感のせいか、いざ知らず、近頃はおとなしくしている方々も多いと思う。確かに昨年は何もしない方が良かった年であったと言えるかも知れない。では今年はどうか？まだまだ不況の入り口だってか。

この業界の景気は世間より１年遅れで来るって言われたりしてるので、実は今年がリーマンショックならぬ、業界ショックが来ると思っている。システム開発系は年度予算ものの要素が強いため当然と言えば当然ですがね。

話は変わるが、リーマンショック以来、ヘッドハンティング会社からのコンタクトが急増した。なぜかよく分からないが、いろんなところで不況も逆にチャンスなのであろう。

不況「なのに」ではなく、逆に不況「なので」って考えてみても、その考え方自体がなんか普通な気がする。ごく普通に考えた「逆」ならあまり美味しくないであろう。あるいは、あまり考え過ぎると、裏の裏は表になってしまうし。難しい年頃ということか、最近は。何かヒラメキみたいなものが欲しいものである。

さて、個人的には、一昨年は闇雲にバタバタとし過ぎた反省もあって、昨年はおとなし気味は過ごしたと言える。そして今年は、何か人と違うことをやりたいなって思っている。

何はともあれ、そろそろ早めに？起きるとするか。

ご存じのとおり、米国大統領選でオバマ氏が当選した。そのスローガンが、CHANGE!。

ＴＶを見ていると、感極まって涙ぐむ米国人がとても多いのが、印象的である。そして、このメッセージは、日本人の私にまで強烈に届いた。（なので、こうやってブログに記事をアップしてみたが、別に私は、政治・経済の専門家でも、社会評論家でもないので、特に書くこともないのであるが。）

アメリカがチェンジを選んで歩み出すのであれば、日本にも相応のチェンジが起こるだろうし、それを期待している。何も国際経済のことを言ってるのではない。IT系のチェンジとその期待である。

日本のＩＴ業界、特にＳＩ業界では、７Ｋとか、閉塞感とか、泥だとか、鬱だとか、ネガティブな環境にあると言える。いいかげん、うんざりしている方々も多いと思う。ビジネス的にも技術的視点でも、「変わらない感」に支配されてしまっている。なので、ここにきて、大きな外部環境の変化が発生したのであるから、変わるかもしれない期待感が大いにある。ある意味、この変化はRailsより影響が大きいかも知れない。

金融マーケットは壊れたようだし、これから100年に一度の不況が日本にもやって来るから気を引き締めて行かないといけないと思う一方で、変化への期待とチャンスを感じている自分がここにいる。マーケット崩壊と新大統領誕生で、ちょっとエキサイティングしてるだけかも知れないが。

別に、変化を起こすのはあなただ、みたいな言葉は言われたくもないし、言うつもりもない。ただ、何か新しい芽やパラダイムめいた流れが発生するのであれば、ついて行くべしである。

なにせ、これほどの外部環境の大きなチェンジは滅多にない。技術革新とか、業界再編を生み出すだけのチェンジ要因には成り得る。次の上昇気流に乗れる可能性を探る時期でもあろう。

CHANGE、今の時代に相応しい、良い言葉だ。IT系変化期待だけでなく、社会的にも。。。

外付けの液晶モニターを購入して、デュアルモニター環境にして見た。

液晶モニターは秋葉原で21,432円で入手。安っ！。別にバッタもんじゃないよ。

以下がその写真。（携帯で撮ったのであまり写りが奇麗でないが。）

しばらく使ってみての感想としては、確かに開発効率は上がる。2万円程度で実現できるので、特にプログラミング作業をする人には、かなりお勧め。広ーい机で作業している感覚って言うのでしょうか。置き場所に困っていた物を置くための場所を貰えたみたいな感覚。サイドテーブルを付けたみたいな感覚。とにかく、快適な環境になります。

2台のモニタの使い分けですが、私は、ノートPCの画面をメインで使っていて、外付けモニターはあくまでサブの画面として使っています。例えば、ノートPCでEclipseでソース見たりプログラムしながら、外付けモニタには、そのソースの実行画面や仕様書を開くって感じです。

または、私のNotePCには、VMwareが入っていて仮想環境になっているのですが、ホストOSをノートPCで開いて、ゲストOSを外付けモニターで開くとかいう場合もあります。

でも、やっぱりお勧めはプログラミング環境としてのデュアルモニターですね。なんせソース見ながら、すぐ横の画面でそのソースの仕様書とか実行した画面を見れますからね。あるいは、サブのモニターでブラウザ開いてネット検索した情報見ながら、ソース書けたりもしますから。

そして、それが2万円程度で実現できるんですよ。会社におねだりしてみましょう。会社がお金もったいないからダメって言うなら、そんな会社に見切りつけてFMSCに移籍すればよい。（人材募集中）　FMSCなら即買いOKですよ。

あとは、そうですね。どんな液晶モニターが良いかですが、これは個人の好みと考え次第ですが、私がアキバの店員さんからいろいろと話をしながら写真に写っている液晶モニタにした理由は、以下の通り。

・光沢液晶ではなく、普通の液晶にした。

最初は光沢の液晶を買う気満々で行ったんだけど、別にゲームしたりテレビ見るわけじゃないので。それに、オフィスワークに最適と言われて。光沢は目が疲れるとか、反射して自分の顔が映るとか言われるが、それはどうかは分らない。でも、サブの画面なのであまり出しゃばってほしくないし、落ち着いた感じで、光沢でない方が良いと思う。あくまで私個人の主観ですが。それと、ノートPCのほうが、光沢液晶だからってのもある。

・１７インチのスクエア型にした。

予算的にも設置場所的にも、もっと大きな画面サイズのモニターを買うことも出来たんですが。でも、17インチぐらいで十分だと思う。そもそも、ノートPCの横にサブモニターとして使うのに、どデカいサイズの画面では。。。デカって思うでしょ。それに顔とモニタの距離が近過ぎるし。普通の液晶だと17インチも19インチも解像度は変わらないはずだし。

あと、ワイド型の液晶じゃなく、スクエア型にしたのは、これまたノートPCがワイド液晶だからサブモニタは普通ので良いかなってのもあるのですが、ワイドだと目で追うには端までの距離が遠いし、首が痛くなりそうなので。でも、メインのモニター(私の場合はノートPC)はワイドの方が良いと思う。なんせEclipseなどのIDE開くと、横長いのがやっぱいいでしょ。で、サブのモニターではExcelとかWordとかブラウザを開くことが多いので、横長である必要はなく、スクエアで良いと感じている。ま、ワイドのサブモニターを試したことないのではっきりとは分らないのですが。

・コンパクトでシンプルなデザインのものにした。

数ある１７インチ液晶のなかから写真のものにしたのは、コンパクトで、シンプルなデザインであったため。邪魔にならず、うるさいデザインでもなく、机の上の占領スペースも小さい方が良い。

まとめると、私的には、非光沢で１７インチのスクエア型でシンプルなデザインの液晶モニターがお勧め。ま、あくまで私の好みですが。

弊社(FMSC)の人材募集(採用情報)に関して、ここでは私の思いを書いてみます。

(会社の公式な採用情報としては、こちらです)

優秀な人材は常に募集しておりますが、今回２００８年度としては特に「ソースの読み書きが上手な若者」というテーマで、どこかに埋もれてしまっている貴重な人材と巡り合い、こちらの世界で活躍、あるいは相応のキャリアを積んで頂けるように、採用活動に取り組んで行くつもりです。

まず今回、弊社の求めるエンジニアは、「ソースの読み書きが上手」であること。今はJava言語を主体にしていますので、Javaで書かれたソースプログラムの事です。「プログラムが苦手な人・下手な人」は今回の対象ではありません。プログラミングという観点では知識・努力だけの結果でなく、きっと適性の問題も関係してくることでしょう。そして、このあたり当の本人が一番良く理解していることと思います。「自分はソースの読み書きが上手なほう」だという感覚をお持ちの方を対象にしています。

（注意事項としては、「俺はオブジェクト指向の達人だ」といくら主張しても、それは弊社の求めるエンジニア像とは違います。それに考えが古いようですし。）

もちろん「プログラムしか出来ない人」は要りません。仮にも「...コンサルティング」って会社名に付いていますので、いわゆる「コミュニケーション能力」は必要です。ただ、今回は「若者」を対象にしていますので、まだ能力が開発されていないでしょうし、経験も少ないでしょうから、一般的なコミュニケーション能力があれば充分です。

そこで「若者」ってのが次のポイントにもなります。何もプログラマとしてこき使おうとしている訳ではありません。弊社にはSEとPGの区別なんてありません。コンサルタントとして活躍して頂くつもりです。弊社コンサルタントの特徴としては、「卓越した技術力」と「コンサルティング力」、そして「現役のデベロッパー(開発者)」であることでしょうか。この「現役のデベロッパー」であることの証として、「ソースの読み書きが上手」という先の前提条件につながります。自分が上手く出来ないのに、コンサルティングなんて出来ないですからね。

逆に、優秀な若手技術者が、弊社環境の中において、今まで培ってきた能力を発揮し、さらに次のステップとして成長するために、より広い視野で技術力やコミュニケーション能力、さらにはコンサルティング能力を磨けるような、そんな感じのあり方でありたいと願っています。

「ソースの読み書きが上手」というキーワードを使いましたが、弊社では、ソースだけでなく「三位一体」として、管理、仕様/ドキュメント、ソースの三位を一体と見なしています。(ブログ記事「三位一体のソフトウェア開発思想」を参照)　また、「コンサルティング」という観点が常に頭の中にありますので、自然と、技術や手法を体系的に捉えようとするし、問題分析や問題解決への洞察力が生まれます。さらに、コミュニケーション能力、人間関係力など含め、様々な「経験」と「力」が開拓されていくことでしょう。

向上心ある「ソースの読み書きの上手な若者」の皆さん、PG,SE,PMの呪縛に捕われることなく、弊社のコンサルタントとして、共に成長して参りませんか。

これはある意味、ある方々にとって、「BIG CHANCE」です。

三位一体。普通の事ですが...今の日本のソフトウェア開発に必要な思想と思う。

三位一体とは、宗教的には

「神・キリスト・聖霊が本質的に一体であり、実体は三つの位格によって表れると考える教え(*1)」

ですが、ここでは単に、

「３つのものが結びつきがあって１つのなにかをなす(*2)」とか「三つのものが一つになる（心を合わせる）こと(*3)」

と言う考えや教えみたいな意味で、この言葉を使っています。

ソフトウェア開発で言う三位とは以下の３つ。

・管理 (プロジェクト管理/開発管理)
・仕様/ドキュメント (要件/設計/仕様)
・ソース (プログラム他、実装物)

いずれかが欠落していると全て上手く行かないとか、分業・責任範囲の明確化も大事だが一体であることの知識と認識を失ってはならないとか、みたいな。。。

誤解の無いように。ここで言いたい三位一体とは、３つを１つに統合と言うような考えではない。３つの各位はそれぞれ認められており、お互い考慮・尊重というか、相互依存の運命共同体というか、より高い視野であり、１つのことを多面的に見るアプローチや思考を指しています。

それに、普通の事なんですが、そもそも一体なはずなんです。いつの頃からか昔からか、責任という壁で分離されてしまって。責任範囲外のことは余計な精神的負担や金銭的工数になるので協力に消極的であったり拒絶したり。あるいは、一体とは程遠いので、歪みが出るの。それとも、業界の激しきモラルの低下現象なのか。

これからの日本のソフトウェア技術者は三位一体を語れるようになるべし、と思う。特に、上流ばかりに流れたり、管理型の開発ばかりに流れたり、今の日本のソフトウェア技術者は、空洞化していると感じるから。それに、３つを体得しないと、アジャイルなんて実践出来ないから。少なくともスーパーエンジニアを目指しているのなら。

上流から下流までアジャイル的に同じ人間がこなすことも１つの解。ただ、日本業界一般としては分業体制の中で解決法を探る必要があり、せめて共存共栄の精神のもとで各位の使命をまっとうするべし。

三位一体の思想。今の日本のソフトウェア開発に必要な思想と思う。

でも、普通のことなので、偉そうにアピールしても仕方ないか。説教くさいのは好きじゃないし。あとは自分で考えて。。。

*1 wikipediaなどより引用。文言は文脈に合わせて変更した。

*2 はてなダイアリーキーワードより引用。

なお、三位一体は、英語では、TRINITY(トリニティ)。
私のハマった映画「マトリクス」の登場人物の女性(NEOの恋人)がトリニティって名前。

*3 Microsoft Bookshelfより引用。

（新年度一発目の記事、ってか、久しぶりのブログ更新となりました。実はこのブログネタは、年末特有の空気にあわせて書こうとしていたネタなのですが、予定外の仕事と、また特にプライベートでも多忙になりまして、控えていたものです。ちょっと時期はずれかも知れませんが、新年度で何か新しいことを始めようとしている方も多いと思いますので、記事にしてみることにします。では、以下、本編。）

「いっぱい」だと、新しいものが入ってくるスペースがありません。新しいものを手に入れてから古いものを捨てるのではありません。古いものを捨てたことにより出来た空きスペースに新しいものが入ってくるのです。自然と導き入れられるのです。それがタイトルの「新しいことを導き入れるために空きスペースを作る」ということの意図です。先に空間を創るんです。上手く言えませんが、感覚的に、そういうのもありです。

新しいことを始めようとしている人、特にそういう意図はありながらもなかなか新しいものが入ってこない場合には、空きスペースを創るのが先に必要な時があります。たぶん今までいろんな知識とか経験を積み上げて「いっぱい」なんです。これは今まで多くのことを溜め込んで来たので当然のことなのです。特にソフトウェアエンジニアにとっては参画するプロジェクト毎に異なる大量の物事に溜め込んでいきますからね。

でも残念ながらスペースは無限にあるわけではありません。ヤル気の問題ではなく、気の物理的な制限なのです。溜め込み過ぎは頭や体に良くありません。意識していなくても、頭の片隅にでも残っていると、それだけで、気が取られるんです。視界に入ると、見ていなくても、気が取られるんです。無意識のうちに、です。ですので、意図的に不要なものは捨てなければなりません。まずは視界から消し去りましょう。「捨てる」ということです。きっと新しことが自然と導き入れられることでしょう。

本屋さんに行くと、お掃除整理本や捨てる技術本が並んでいます。あまりに普通の事を書いた本ばかりで退屈なものが多いようですが、１つ面白い本を見つけました。好き嫌いはあるとますが、風水整理術です。

ガラクタ捨てれば自分が見える―風水整理術入門

余計なガラクタを捨て、滞った「気」を除き、澄んだ空間を創り、自然の流れにそって、新しいことを導き入れる、そんな内容です。中国四千年の知恵「風水」恐るべしです。

ということで、私の身辺も整理して見ましたよ。

・パソコンから使っていないファイルを大胆に削除。これで空きスペースは充分。既にcygwinも消してvmwareでlinuxとか入れようかなって気になっているし。

・机の上や引き出しから過去の資料の大量破棄。取っておいても使わないし。内容も発想も古いし。そういう意味では、シュレッダーって一種の浄化装置となりえるのです。

・会社で本棚を買ったので、机の上の書籍を大量移動。これでSolaris2.6の本とか、EJBパターンの本とかはもちろん、StrutsとかUMLの本も、視界から消えた。これ重要ですよ。

・雑物の整理と捨て去り。うちの会社は個人ブースなので結構なスペースがあるので、さらに広々とした贅沢な空間となりました。

それとこれは会社のことですが、

・当面のラボ活動の自由研究化。空き時間には何の予定も無し。頭空っぽ。

・新しい仲間の入る空間創り、つまり、新規採用募集枠。

そんなところ。

これからはKY(空気読め)よりKT(空間創れ)だ。

これで新しいものが入ってこないわけはない。こういうのもありです。そういうもんです。

おしまい。

ちまたの界隈で話題になっているので、このブログでも少し話題にしておこうかなって。

人気?ブログの「分裂勘違い君劇場」の最近のエントリ[「好きを貫く」よりも、もっと気分よく生きる方法]。

絶妙のタイトルですね、ほんと。まだ読んでいない方は面白いので、文章は長いですが、読んでみることをお勧めします。ついでに、このエントリにトラックバックとか沢山付いていて、そこを辿ったりしていろんな意見や論議を読むと、もっと面白い。（ただし、私は最近偶然にもこのエントリで話題になっている元ネタの梅田望夫氏の「ウェブ時代をゆく」を読んだので面白いですが、このエントリだけ読んでもよく分からないかも知れませんので、そのあたりはあしからず。）

ちなみに、リンクだけでは何なので私事を少し書いておくと、私が大学を卒業してこの職に就いた理由は大きく２つ。

１つは、この手の分野の作業が得意であったこと。つまり、好きな事でなく得意な事を職にしていますね。

もう１つは、この業界に成長性があり未開拓の領域が多く残っていたことですね。安定性でなく仕事に面白さを求めたんですね。

そして、今、プログラミングが好きかって言われると、「別に」って答えますね。少なくとも、そういう趣味は持っていない。私にとっては、この業界の職業人としての、技能の１つですね。もちろん、プログラミングしてて、私の経験や哲学とか価値観を表現した作品創造みたいな、芸術的な感性をくすぐられることはありますよ。仕事には、自分の哲学とか思いとか価値観って言うんでしょうか、そういうものを表現できたり実行できるという要素があるんですよね。自己実現への欲求って言葉なんでしょうかね。そして、もっと上手く表現したいとか実現したいがために、もっと上を目指して、頑張るのでしょうね。。。なんて、語りだすと長くなるので、このへんにしとこっと。

はい、ちょっと話がそれてしまいましたが、この紹介したブログ「分裂勘違い君劇場」では、他にもいろんなエントリーがあるので、探索してみると面白いです。ハチャメチャな論理も多いですが、いろいろと考えさせられますよ。

昨晩、ＴＶ東京の「カンブリア宮殿」って番組をみました。

ゲストは楽天の三木谷さん。「仕事は人生最大の遊びだ」ってテーマ。

簡単な内容は、カンブリア宮殿：楽天三木谷社長　＠５０代オヤジの独言を参照してもらうとして。

楽天さんも、大きい会社なのでいろいろとやってはり、人によって注目している視点が違うと思いますが、私が注目しているのは、１つはIT企業としての経営とかビジネス、もう１つは積極的にRubyを採用して推進しているところですね。

特にRubyに対する動きに関しては、そこに何があるのだろう、どのような意図があるのだろうとか。普通に考えると、チャレンジャーですからね。まつもとゆきひろ氏を迎え入れての本腰を入れた活動ですし、また、大規模分散基盤みたいなのをやろうとしているのは、情報として知っていますが、技術だけでなく、そのような決断に至った思考に興味を惹かれるものがあります。それと、いよいよ楽天さんもワールド(世界)クラスを感じさせますね。

話を本題に戻しますと、カンブリア宮殿のトークで、三木谷さんが、最終的な決断はトップがやれば良いのだろうけど、そこに至る過程で、苦言を言ってくれる人がいることが重要と、そして奥さんが、「あんた最近つまんないわね、保守化してるんじゃない」って、ボソッと言うらしい。そして妙にこのトークが気に入ってここに記事にしているわけです。番組の終わり際の編集なので、それなりのメッセージ性を込めた意図があるのでしょうね。チャレンジャーであれとか、仕事は人生最大の遊びだってことの結びとして伝えたいことの１つだったのでしょうか。いずれにせよ、何か自分に言われているような気がしました。

なので、今日の一言。「あんた最近つまんないわね、保守化してるんじゃない」。。。と、それを伝えたいためだけのブログ記事でした。以上。

さて、皆さんは最近どうでしょう。

最近、弊社のラボ活動として、新しく「軽量なプロジェクト管理フレームワーク＆キット」をテーマに活動に取り組んでいます。

世の中には、プロジェクト管理の知識体系として有名なPMBOKがありますが、やはり一般的な表現になってしまいますが、「重厚」、つまり、ヘビーなわけです。ヘビーなプロジェクトには参考になるとは思うのですが、軽めのプロジェクトには、当然ながら、逆に重荷となるわけですね。そこで軽量なプロジェクト向けのマネジメントフレームワークとかが欲しいわけです。

それじゃあ、PMBOKとかをミニマムセットで使えば良いじゃん、いや、そうじゃなくって、軽量には軽量なりのフィットする枠組みがあるわけです。「大は小を兼ねる」と、心地が悪いのです。軽量という言葉がよろしくなければ、何を重視するかの観点が少し違うのです。あるいは「軽快」って用語なんてどうでしょう。

開発プロセスの領域では、ウォーターフォール型とかRUPとかの重厚(ヘビーウェイト)な開発プロセスに対して、「アジャイル」って呼ばれる軽量(ライトウェイト)な開発プロセスがありますが、別に「純粋なアジャイル」のプロジェクト管理のことを指しているわけではありません。テーマの空間領域が違いますからね。この表現でわかってもらえますかね。

どちらかと言うと、従来のオーソドックスなプロジェクト管理をベースに、軽量化したものとでも言いましょうか。少なくとも、「変化への柔軟性」とか「暗黙知」を前面に押し出すようなことはしないでしょうね。ドキュメントも書きますよ。ただし、軽量版ですが。

また別の観点で重要なポイントがありまして、「実践」で役に立つものを探求していきます。知識を身に着けたいだけであれば、本(書籍)を読めば良いわけです。本みたいな内容を活動成果としているわけではないです。出来れば、ドキュメントテンプレートなどで、「実践キット化」していく意図をもって活動しています。

そんな感じなラボ活動、テーマは「軽量なプロジェクト管理フレームワーク＆キット」。こういうものには名前を与えてやる必要があります。コードネームってやつですね。

「Ｍ(エム)」ってので行きますか。「いろは」の”い”みたいな意味で、ManagementのM、マネジメントのＭ(エム)ぐらいは、押さえておきましょうってことと、軽量なのでMぐらいでManagementの完璧な全部は入れないよってこと。（あと、ＳＭのＭじゃないよって、トーク・ネタで使えるでしょうし。）

ということで、「Project M(エム)」ですが、スコープを絞ると、今のところ、以下のような感じとなっています。

・軽量(ライトウェイト)

小規模プロジェクト。規模の定義はしていませんし、規模というより、いろんな意味で、軽めのやつです。少なくとも、人命とか社会インフラに関わるようなミッションものではないこと。

・ソフトウェア開発プロジェクト

システム/ソフトウェア開発のプロジェクトを対象領域にしています。もっと絞るなら、一般的なオーダーメイド型の受注開発、いわゆる受託開発ってやつですね。プロジェクト管理一般論では分かりづらい。

・内なる欲求からのプロジェクト管理

組織的な品質保証への取り組みとか言ったような、第三者・外部からの監視・監査的視点ではなく、開発プロジェクトのメンバとして、内なる欲求から産み出されるプロジェクト管理。管理という用語が相応しくなければ、プロジェクトの計画と運営ものが中心となるでしょうね。

ちなみに、FMSCでは、開発プロセスの領域として「Recipes」と言う体系化されたパッケージがあります。いわば、開発プロセスのフレームワーク＆キットですが、「Ｍ」は「Recipes」とダブルところもあるのですが、プロジェクトマネジメントのフレームワーク＆キットです。

今のところ、そんな感じです。。。

以上、「軽量なプロジェクト管理フレームワークへの探究」、いや、「探究心」と言うよりも、これはエンジニアとしての「向上心」を持った意識的な取り組みですぞ。

FMSCでは、そして特に私は、「王道」ってキーワードを時々使うことがあります。それは弊社のサービスポリシー、あるいは手法や思想などを表現する際に用いているキーワードなのですが、今日はその由来に関するお話です。この王道ってキーワードの出所は、実はテニスにまつわる「王道」と「覇道」のストーリーが背景にあります。

個人的な話からはじめて恐縮ですが、社会人になりたてのころ、仲間とテニスのサークルをしていました。社会人になってから本格的にテニスを始めた私にとって、ある程度、基本も技術も身について上手くなった頃、社内のテニス大会に出場することになって、もちろん何としてでも勝ちたいわけですが、やはりまだまだ技術も経験も未熟なわけで、独特のフォームで変な回転ボール仕掛けてくる相手や弱点ばかりを徹底的に狙ってきて嫌な気分にさせられてしまうような相手には勝てないわけです。そこで、この先、どのようなテニスを行っていくか、どのように上達して行ったら良いのか、悩むわけですが、その時に、ダブルスのペアを組んだ元テニス部の後輩から教えられたのが、「テニスには王道と覇道があって、私は王道のテニスを志しています」と。つまり「王道で強くなりたいし、王道で勝ちたいのです」ってこと。そのことがきっかけで、妙に「王道」って道に惹かれてしまった自分がいるのかも知れません。

今から調べると、宮本輝氏の「青が散る」という小説がルーツみたいですが、テニスには「覇道のテニス」と「王道のテニス」がありますと。覇道のテニスとは、勝つために手段を選ばず、フォームが独自の我流で、ボールには変な回転を掛けるような変則テニスです。王道のテニスとは、基本を大切にして、正々堂々と綺麗なフォームで素直なボールを打つような正統派のテニスです。どうせやるなら、他人から見て真似したくないと思われてしまうような我流のテニスではなく、他人から見てそれを身に付けたいとか学びたいと思われるような流儀のテニスを志したいものです。特に、我々のような技術や手法を伝授する立場にある人間にとっては、この「流儀」の考え方は重要なことのように思います。

ここであまり綺麗事ばかりを書きたてるつもりはないですし、覇道と王道にも賛否両論があることでしょう。覇道を用いないと勝てない状況にも多く遭遇することでしょうし、王道に拘り過ぎるのも決して良くないのでしょう。特別な必殺技と言うかキラー技があってこそ、一流になれるのかも知れません。ただ、強く洗練された王道という土台があってのことと思います。少し青臭い考えかもしれませんが、「王道で強くなりたいし、王道で勝ちたいのです」。そして、そのためのテクノロジーや手法や思想哲学といったものを提供したいのです。そんな思いで「王道」って言葉を使っています。

以上、少しの話のネタと結論が強引ではありますが、そんな感じな王道と覇道の例え話でした。

ある人から読んでみたらと言われて「ワーキングプア-日本を蝕む病(ポプラ社)」を読んでみたので少し感想を。何もネットカフェ難民や日雇い労働者の話をしたいわけではない。この本の「第５章：グローバル化の波にさらわれる中小企業」と同じ現象が、この業界にも進行しているのではないとかと言うことである。特に下請けの中小ソフトウェア開発会社は、大きなうねりを伴う波にのみこまれないように注意しないとね、と言うことである。

話の内容は、海外との激しい価格競争、近代化の波、日本に押し寄せる外国人労働者、単価の破壊的下落、過酷な労働、失業など、どん底に向けて負のサイクルによる競争という、何かの特集であるような良くある話ではあります。ソフトウェア開発に従事する人にとっては、この業界の話じゃないんだとか、オフショア開発の話で対岸のことと思いきや、この波の流れや余波によっては他人事ではなくなる可能性が無いわけではないですね。

特に、キーワード的なセンテンスだけ挙げてみますと、

以下、本文より一部引用。全文は本を購入して読んで下さい。

-----------------------------------------------------------------------------
○○さんにとって辛かったのは、仕事に対するポリシー、プライドさえも、かなぐり捨てなければならないことだった。...中堅の業者にまでなった○○さんは職人気質で「...は製品に施す化粧だ」が口癖だった。しかし、何千枚という製品を丁寧に仕上げるのは不可能だったし、そうした仕事を求められてもいなかった。....「大量に、安く、早く」---それが...の仕事になってしまった。
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
国産を好む消費者は必ずいる、品質を下げなければ生き残れる。それが○○さんの読みだった。しかし、---。「まさか国産を外国人が作るようになるとは思わなかったね。...
-----------------------------------------------------------------------------

１つ目は「近代化の波」とでも言えば良いのでしょうか。２つ目の引用は、外国人労働者が大量に日本に押し寄せてきて日本で仕事をするようになった話ですね。

皆さんの周りはどうでしょうか。別に脅かすわけではないですが、少しはこの業界でも通用する話なのではないでしょうか。そういえば、先日、ある会社の社長さんが、わがままで単価の高い日本人じゃなくて、意欲が高くて真面目な外国人エンジニアを採用したって感じのことを言ってました。どこの話って、もちろん、この業界の仕事の話ですし、ＩＴ技術者のことですよ。

どの時代にも、大きな波のうねりというものがありますので、うまく泳いでいく必要があります。ましてや、波に飲み込まれないようにしないといけないですね。ただでさえ、この業界は、新しい３Ｋ職場と言われたりもしています。この話とはまたちょっと違いますが、うつ病にかかる人が増えているという話も聞きます。まさに病める業界への死の行進、新たな「デスマーチ」が進んでいるのかもしれません。

なので業界を変えようなんて大それた意識は持っていませんが、せめて、大切な家族と社員だけは守れるような、自衛の手を打っていくべきかも知れません。信念を持ちつつも、時代の波に逆らわないように。

ちょっと業界を明日を憂う、今日この頃...でした。

先日、チームのメンバーと昼ご飯を食べていて少し話しに出てきた内容を、このブログに関心を寄せて頂いた読者の方々に伝えたいと思い、なんとか記事にしてみたい。上手く伝わるかどうか心配ですが...

我々は、JAVAの基盤系技術に強く、J2EEの初期アーキテクチャから、様々な会社のフレームワークを見てきたし、最近で言えばオープンソース系ってところもです。この業界、もっと絞って言うなれば、Java開発のフレームワーク技術については、次々と目新しいものが登場してくる。少し前で言えば、DI（Dependency Injection）+AOP（Aspect Oriented Programming）だとか、JSF(Java Server Faces)だの、CoC（Convention Over Configuration：設定より規約）だとか。JPA（Java Persistent API）だとか、アノテーションでメタ情報とか。ちょっと分野が違いますが、Ruby on Railsとかね。

次々と登場してくる新しい話題と技術。我々専門家としては相応に消化して取り入れていく訳ですが、この急速な変化と言うか、昨日はこっちで明日はあっちみたいな思想の流れ、そして多次元に広がる流れに、真に付いて行けている開発技術者がどれだけいるのか、振り回されているだけではないのか、と言う疑念が生じてきます。現場でも、その技術を理解しているしていないとかの問題ではなく、思想としてポリシーとしてそれで良いのかって、首を傾げたくなるシーンも多く見受けられます。つまり、上手く消化できていなかったり、必要でないのに捨て切れていなかったり、見合っていないのに取り入れたり、その技術概念に取り付かれて広い視野で物事が見れなくなっていたり、ってのを感じることがあります。これは今の状況に限ったことではなく、永遠の論議であり教え事でもありますが。

別の表現を試みて見ましょう。いわゆる「state of the art」(最新の技術)を全てかき集めて、今のマーケット的に話題で流行の技術をベースに開発しようとしています。ひょっとしたら１つや２つぐらいは試してみたい新しい要素もおそらく取り入れていることでしょう。あるいは、ベンダーのマーケッターが、これからはこれですよって、耳元で囁いているかも知れません。さて、あなたは、いや、あなたのチームには、これらの目まぐるしく変わる最新の技術要素を吸収して身につけているエンジニアがどれだけいるでしょうか。そして、どのように取り組めば良いのでしょうか。昔、とあるお客さん曰く、「自分が１０人とか２０人いればそのような方式でやるだろうけど、そうじゃないので、こういう方式にしてある」と信念を持って話してたお客さんもいらっしゃりました。おそらく、最新の技術や話題の技術に重点ポイントがあるのではなく、業務を知っていたり、自社の要員とか力量であったりとか。あるいはまた、物事を難しくしないでシンプルにするってことでもあります。その分、他のことに気が回りだします。そして、それが一番生産性が高く発揮できたり品質が良かったりするわけですね。技術的には、最新のセクシーな感じではなく、オーソドックスなスタイルとでも言いましょうか。もちろん、レガシー技術を例えているわけではなく、どれもJavaベースの話ですよ。

日々、目新しく登場する技術や人を魅了する話題など、急速な変化と情報の流れの中、すべてを飲み込んで取り入れて消化するリソースもないと思うのです。古い技術のままの居場所にずっと留まっているのは死を意味する一方で、少しでも最新の技術を採用したいとか最新技術のオープンソースを組み合わせてという思想も理解出来る一方で、そんな両極端なものではなく、どちらかというと、技術的に「ゆったりとした流れを創る」というような設計思想というか、そういう方針で取り組まれてもよろしいんじゃないでしょうか。

生産性を上げるとか品質を上げるイコール、最新の技術を使うということではありませんし、ベースとなる設計思想やフレームワークの頻繁な乗り換えには疑問です。確かに新しい流行には楽しい要素があり技術者としてエキサイティングな面はあるのですが、ソフトウェアの生産性や品質を上げるためには、目まぐるしい急速な変化の中で、自社あるいはプロジェクトに見合ったゆったりとした流れを意図的に創ることも重要でしょう。これを標準化と言う言葉で表現することも出来ることでしょう。じっと動かないのではないですよ、ゆったりとした流れを創るのです。特に技術要素の乱立・乱用気味の昨今の流れの中、このような考え方も重要なのではないでしょうか。

Webサービスを調べる機会があったので、少し記事にしてアップしておきます。

当然、Amazonを調べて参考にするわけで、次に楽天あたりを参考にするわけですが。

AmazonがWebサービスとして、SOAPとRESTを採用しているのはご存知の通りですが、その利用の85%はRESTって話みたいです。その他、大勢がRESTだけなんですね。もう少しSOAPとRESTの両方提供するところがあっても良いと思っていましたが、そういう流れなのでしょう。

それはさておき、楽天APIでJSONがサポートされるようになっていました。これも流れでしょうか。

http://webservice.rakuten.co.jp/api/itemsearch/

リクエストパラメータからXMLがなくなり、レスポンスもXMLじゃなくなってしまうのでしょうか。
javascriptやAJAXの世界では既にそうなんでしょうが、サーバーサイドも含めて、データ構造の表現がJSONに置き代わっていく可能性もありますね。

最近、XMLがどんどん使われなくなっていくような気がするのは私だけでしょうか。
Webサービスに限らず、Javaの世界でも複雑なXML設定を記述しなければいけないのを避ける流れにありますしね。さて、XMLは、いずこに？

以上、ちょっと気に止まったので、記事にしてみました。

このラボのチーム・ブログでは、個人が別々のブログとして管理していますが、バラバラなのを、まとめたいときがありますよね。

ちょっと調べましたところ、RSSをまとめてくれるMixFeedというサービス(無料)がありましたので、試してみました。

チーム・ブログのRSSフィードをまとめてみました。以下、ご参考。

http://mixfeed.jp/6187

さらに、ブログメールというサービスを発見、ブログの更新状況をユーザーにメールで通知してくれます。

このサービスでは、

-------------------------
・ブログメールは個人情報保護を重視しており、あなたのブログに登録したユーザーの電子メールアドレスは一切公開しておりません。購読者数のみ確認できます。

・ブログメールのメールには購読解除リンクがあり、ワンクリックで解除できるようになっています。また購読フォームに解除オプションもついており、設置された購読フォーム上で解除も行えるようになっています。
-------------------------

とあるので、ユーザも気軽に利用出来ますね。しばらく実験で使ってみます。

-------------------------

FMSCラボでは、このようなインターネットを使った新しいサービスもいろいろと調査・研究しています。お楽しみに。

jaba言語に関する記事です。いわゆる「java」言語ではなく、「jaba」プログラミングに関する記事です。

さて、読者の皆さんは、このブログ記事には、どのようにして、たどり着きましたか？

Googleとかの検索エンジンから来られたのであれば、見事にSEO対策に嵌っています。

タイプミスとか、漢字の誤変換を狙って、検索エンジンの上位表示を狙うって手法です。

そうです。このブログでちょっと実験してるわけです。悪意はございませんのでお許し下さい。

さて、何位に上位ランキングされるでしょうか？その持続期間は？

javaをjabaで間違えることはそう多くないでしょうが、では、無線ＬＡＮ内臓パソコンとかね。
間違いに気付きましたか？これに関しては、下の記事でも読んで見て下さい。

「湯に黒」をただの誤変換と侮るなかれ

以上、失礼しました。

ドリコムさんのRSSサービスを使って、FMSCラボのニュース・サイトを構築してみました。
深い意味は無いのですが、これもラボの研究活動の一環です。

http://starss.jp/khara_fmsc

ユーザ登録からサイト構築完了まで、わずか15分程度で完了。
ドリコムさん、お見事です。

と感心しているのではなく、今度はこういうインターネットサービスを提供する側に回りたいものです。
...と思う、今日この頃。。。いろいろ調査しています。ラボですから。

さらに、ブログやホームページの好きな場所に貼り付けられるブログリストって機能もある。

ここに貼り付けてみた。評判が良いならサイドバーに採用しようかな。

----　ここから　------------------------------------------------------

----　ここまで　------------------------------------------------------

久しぶりに少しまとまった時間を頂いてプログラマーしてました。と言っても、過ごした時間の大部分は、仕様の詰めのやり取りであったり、打合せであったり、ドキュメント書きであったりなわけで、実コーディングしている時間ってのはそんなに多くないわけですが。そういう意味では、生産性をあげるためには、全方位の工夫とフレームワークが必要なわけで。まあ、それはさておき。。。

今日はLOOK&FEELなプログラムのお話。え、GUIの操作のこと？そうじゃないよ。

プログラムでも、見たまま、感じたままに使えるってのが上質なインタフェースなわけで。特にフレームワークとか共通ライブラリのAPIを提供するプログラムってのはそういうもののはず。難解な構造を理解しないと使えないとか、ドキュメント読んで良く理解しないと使えないとか、動かしてみないと何が返って来るか分からないとか。

まあ、それは極端な例としても、パッケージの名前とか纏まった括り方とか、クラス名とか、メソッド名とか、引数の名前と型とか。特に名前でLOOK＆FEELな表現は出来る要素はともて多い。もちろん、共通APIの名前に限らず、どんなプログラムコードでも、ボディ部分であっても、誰かが見るわけで、LOOK＆FEELなコード表現が出来ているか、人に優しいプログラムかって感じのことも意識すると、すっごく良くなります。

ある優秀なプログラマーいわく、「処理ロジック書くのに悩むことはないけど、メソッド名とかのネーミングに悩むし時間が掛かる。」とさ。変な名前付けると気持ち悪くて自分で嫌なんでしょうね。

普通にプログラムが書けるようになって、もっと上を目指すなら、処理効率とか実行コンテキストを意識するのはもちろんのこと、LOOK&FEELなプログラムを意識して見てはいかがでしょうか。そうすると、すっごく、イケてるコードになります。どうせやるなら、綺麗なコードを書きたいものですよね。

今日は家訓にまつわるお話。

実は我が社(FMSC)には家訓があるのだ。家訓と言っても、「顧客尊重」とかそう言った社訓じみた話ではなく、フレームワーク開発時において留意すべき事柄を家訓として表現して見ただけなのであるが。これはFMSCの2周年記念パーティの席で、出席者へのプレゼントとして披露したコンサル・ネタなのであるが、先日4周年を迎えたこともあり、ここにアップデートしておこう。

【家訓：Javaフレームワーク編】

其の一： 技術や手法に酔ってはいけない

いくら素晴らしい技術や手法に出会ったとしても、それに酔いしれることなく、本来の目的を達成するに相応しい方法で。酔っ払うと周りが見えなくなっちゃいますよ。とにかく自己満足型、複雑超越型、趣味型にならないように。特に研究機関やコミュニティに多く見受けられる症状。そして、もう少しシンプルに行きましょうね。

其の二： 今が華ってことはよくある

とにかく流行モノに跳び付きたがる挙動を制止するための一言。単なる流行モノなのか、本流モノなのか見極めは確かに難しいし、そもそもそれはマーケットが決める事。ちょっと待てよ、頭を冷やして冷静に。それだけで効果は充分かな。問題発言したく無いのでどの技術とは言わないが、芸能界で言えば、あの人は今？って事象に近いものはこの業界でもあるのだ。それはさておき、まあ、最初の跳び付きたい挙動さえ抑止できれば良いための薬ってことで。

其の三： 偏り過ぎには必ず副作用が伴う

そのことがやたらと気に言っちゃうと、それがすべてに思えてしまう症状を和らげるのに効果的な薬。最近で言えばDIコンテナに捧げたい一言かな。其の一に類似するが、何事も乱用は避けましょう。世の中広いのです。視野を広く持ちましょうね。

其の四： 銀の弾丸など無いのだ

これはあまりにも有名な言葉なので、説明不要でしょう。ご存知の通り、魔法の解決法など無いということ。

以上が、2年前に考案された家訓。いかがだろうか。

当時の時代背景としては、技術的にはJ2EE仕様に対してDI+AOP+POJOが叫ばれ始め、オープンソースとしてStrutsから新興勢力としてSpringやHibernateなどが登場してきた時代で、正に混乱の時代。我々は、これらの家訓を戒めとしながらも、その先に見える新しい秩序の世界へのシナリオを描いて、正に、生き残りへの進化を遂げようとしていた時期でもある。我々の創業時からの持論でもある、「進化論」、まさに、技術・環境・活用形態の変化...さらに物事の考え方などに至るまで、変化への対応を遂げていた時期である。

あれから2年、さて、今日、これらの家訓を与えられたとして、どうだろうか。保守的過ぎるように感じるのは私だけだろうか。Java業界としては「乱世」から「安住」の時代へと移った感がある中、今、求められているのは、そこまで「保守的」な考えではなく、「革新的」な考えの取り入れではないだろうか。まさに、イノベーション、新しいことを取り入れる変化、それを起こさせるべき家訓としての言葉が求められているのではないだろうか。

もちろん、これまでの経験で培った家訓に手を加えるつもりも無い。そこで、4周年を記念して、4つの家訓に加えて、１つ追加して、この家訓ストーリーを締めくくることにしたい。

其の五： それでも環境は変化し、人も進化しなければならない

いかがなものだろうか。

最近、皆さんはJava EE(Enterprise Edition)の新バージョン、例えば、Java EE 5とか、Java EE 6に、どれだけの興味を持って注目しているだろうか。もはやコミュニティ主導で進化する中、Java EE仕様は完全に、追いかけられる側から、追いかける側に回った感がある。ラボの他のメンバーも自身のブログ(kimada)に記載しているが、今さらJava EEの中で仕様化することに、どれだけの意味があるのだろうか。逆に混乱を招かなければ良いのだが...。

かと言って、Java EEのコミュニティ主導のスペックにも、その威力と影響力が薄れてきている感がある。Javaが、定住化する中で、それぞれが成功体験と成功パターンを蓄積してきているわけで、その尺度との比較で、冷静に、かつ、賢く物事を測ることが出来るようになってきたということだろうか。あるいは、皆と同じようにやっていても競争に勝てないので独自の工夫を凝らし始めたからだろうか。一部では、「ブルーオーシャン戦略」って用語までも飛び出して来ているようなので...。(この件に関しては、いつの日か弊社のBlendの思想について語る機会を頂くことにしよう。)

それよりも、私の中では、Java SE(Standard Edition)の進化への興味が増している。これは多分にRubyの影響が大きいのではあるが...。Java SE 5としては、GenericsやAnnotationなど、大幅な仕様拡張が行われたのは記憶に新しいだろう。個人的には、Annotationに大いに興味があるし、上手に使いこなしたい(乱用ではなく上手に...ね)と思っている。これまた他のメンバーのブログ(hisama2)で記載されているが、クロージャなど、まさに今後のJavaは言語的な進化がテーマなのであろう。そうでないと、今のJava EEも乗り越えられない壁にぶち当たっているようにも思える。

追記：
この記事ではチームメンバーのブログ間の相互の関連付けを行ってみた。以前のブログ記事でも記載したが、相互作用により生まれてくる何かに期待したい。インターネットWeb 2.0の世界ではそれが普通なのだから。

先日「JavaからRubyへ」って書籍が出版されましたが、実はその前編とも言える「Beyond Java」っていう名著があります。残念ながら、こちらは日本語翻訳版(注1)は出版されていないのですが、英語原本で良ければ購入できます。「JavaからRubyへ」はどちらかと言うと、マネージャー向けに書かれているようですが、「Beyond Java」はJavaを一通りマスターしたプログラマーに是非読んでもらいたい内容です。文章にセンスがあって、例え話もとても面白いです。私の超お勧め本です。

内容はJavaの先に見えるプログラミング言語の洞察などが中心となっていますが、第一章に「茹で蛙(Boiling Frogs)」の例え話が出て来ます。この茹で蛙の例え話は、別にJavaに限ったことわざではなく、熱湯に蛙を入れると逃げ出すのに、ぬるま湯につけられて徐々に温度を上げられると熱いと思ったときにはもう手遅れで致命的だよ注意しな、って話ですが、これが実にJava技術者の現状をうまく比喩表現出来ている気がします。特に我々のような一歩先を歩まねばならない会社にとっては死活問題でもあります。もちろん、まだ沸騰するほどお湯の温度は上がっていないですし、今後、どうなっていくかは分かりませんが、周りの温度のチェックだけは怠らないようにしないと行けないステージに入ってきた感はありますね。先日の「JavaとRubyを」のブログ記事も参考にして見て下さい。

(注1) あまりに素晴らしい内容なので、出版社の方に、日本語の翻訳版を出版して頂けないかとお願いをして見ました。現在、真剣に検討頂いているようで、ひょっとしたら翻訳版が出版されることになるかも知れません。

日本全国に展開している私のアンテナショップ(意味不明？ まぁ、つかみだからいいか。)がキャッチした情報をもとに分析してみると、今年はJBossが来る予感。。。

RedHatがJBossを買収したまでは覚えていたが、突如、私の目の前に急浮上してきたのだろうか。いや、きっと必然的なものなのだろう。

当然ながら「商用オープンソース」としてのRedHatの成功シナリオをもとにした戦略を取ってくるわけで。すなわち「商用サポート付き」。これほど魅力的な言葉は無いのでは。さらに、サブスクリプション型のライセンス体系で、初期導入コストが無いに等しい。そして、コミュニティとして、今や2EE仕様をリードする存在感。理由を挙げると、沢山ある。

でも、なぜ、今年なのか? それは、「日本国内でのサポート強化」にある。私の前職時代の知人もRedHat JBossへ移籍した。何か手応えを感じているようである。人が動けば何かが動くのがこの世界であり、兆候は現れるもの。参考のために、以下にプレス記事へのリンクを貼り付けておこう。

http://www.jp.redhat.com/news_releases/2007/05232007.html

企業向けに使うのに少し抵抗があったSI会社が、日本での商用サポート付きと言うことであれば、動くのではないか。責任分解点理論が重視される日本社会では、これはかなり大きな理由付けというものだ。

なお、誤解の無いように説明しておくが、弊社はJBossだけを特に推奨しているわけではなく、どのベンダーからも中立的なポジションに立っている。それは弊社がコンサル会社であるからと言うのも１つの理由であるが、我々の中での答えは明確で、「どのアプリケーションサーバが良いかは、諸々のコンテキストにより決定されるべきもの」であるから。すなわち、システムの特性、プロジェクトの事情、担当者の思いなどにより決定されるべきものだからである。

いずれにせよ、今年はJBossの動きに注目ということだけは、読者の皆さんに発信しておきたい。

「JavaからRubyへ」って書籍がありますが、私からはそれにちなんで「JavaとRubyを」ってことで一席。

そもそも、なぜ今、Ruby/RoR(Ruby on Rails)かってことですが、はやりJavaの行き詰まり感が背景にあると見ています。それが仕様の混乱と乱立の結果なのか、あるいは、スペック(仕様)主導の功罪なのか、いろいろな解釈があると思うんですけど。何を言ってるかと言うと、例えば、気持ち的には、もう以下のような感じ。

1. J2EE仕様
特にEJBか。JMSのAPIもイマイチ。デプロイメントとか。他にも指摘しだすと切が無いか。

2. コミュニティ仕様
Struts仕様、Spring仕様、Hibernate仕様みたいな。これもオーバースペック。
初期Strutsはまだしも、他は技術的に懲り過ぎってか、ちょっとやり過ぎだろう。

3. ベンダー仕様
ベンダーの独自仕様のこと。これはある意味仕方が無いので責めはしないが。

ってこと。私的には、もういい加減にしろって怒鳴りたくなる。それに何事にも技術的に懲り過ぎなのは良くないよね。これじゃあ、生産性の向上どころか、益々悪くなるってことで、鮮烈に登場したのがRailsなんでしょう。まあ、Railsに限らず、もやはJavaから学ぶものはなく、Javaは他の分野から学んでいかなくては進歩しないってことを、Javaの技術者自身が気付いて行動する必要があるように思うのです。だから今、「JavaとRubyを」ってことがお勧めなんです。

そこで、Ruby/RoRですが、単純にRailsのデモ見て凄い生産性ってことではなくて、本質的な視点というか、もっと突っ込んだ洞察で捉えて欲しいですね。なぜ、RailsがRubyを選んだかって、やはりJavaでは出来ないRubyの動的型付けと強力なメタプログラミング機構にあるのでしょう。Railsみたいなことは、Rubyのような言語仕様じゃないと実現出来ないし、逆にRails並みにRubyを上手く使いこなさないと、Rubyを使う意味が無いというか逆効果と言えるかも知れませんね。それと、Ruby/RoRには先進性というか、Beyond Javaの潜在性みたいな空気が感じられて、Java界の優秀民族の一部が住居の移動を始めちゃったりもしていますね。ただ、もちろん、すべてがバラ色な訳では無く、Ruby/RoRも、今後、信頼性や性能、高度で自由過ぎるRuby言語仕様、RoRの実践での適用性とか...などの課題が山積みではあります。

JavaとRubyに関してはいろいろな見解はあると思うのですが、確かなのは、今、Java系技術者(会社)が最も注目し、また、必ず押さえておくべき必要のあるテーマ、それがRuby/RoRだと言えるし、１コンサルタントとしてそれを推奨する。Ruby/RoRを本質的に押さえることにより、Javaの良い点・悪い点が見え、現状改善に繋がるはずである。つまり、JavaとRubyの相乗効果を狙うべきだと思っている。

と言うことで、「JavaからRubyへ」とか「JavaかRubyか」ではなく、「JavaとRubyを」って落ちでした。

追伸：
弊社のラボでは、Enterprise向けRuby/RoRの活用へ向けての研究活動に取り組んでいます。題して「Enterprise Ruby」。これに関しては、またの機会に書きますね。