System.Exit

IT 業界をどう生き延びていくか、とか最近よく考えるんですよ。
ま、いろいろな道があります。
いろいろあるんですけど、先のことを見越して今何をやるべきか、とか考え出すと正直ちょっと悩みます。

結局は、IT 業界に限らず仕事って問題解決の連続なんですよねー（僕の中の定義では）。
いかに上手く問題を解決するか。
問題を解決するためにはいろんなスキルセットが必要で、だから日々情報収集したり勉強したりしてるわけですよね。

あと、問題を解決するのも重要ですけどその前に、問題をちゃんと見極めるということも重要ですよね。
自分自身が問題の種になってたりすることもあるかもしれません。

もっと広い視点から語ると、重要なのは、あるべき状態にどういうふうにもっていくか、ということなんだと思います。
現状をどうしたいのか、ひいては自分の人生をどういう方向に持っていきたいのかとか。
そのためには何が必要で、現状はどうなのかとかいろいろ考えるわけです。

要は、問題を見抜くスキル・問題を解決するスキルをたくさん身につけるために日々努力し続ける必要があるってことですね。
まあ、幸いそういったことは嫌いではないというかむしろ好きなので、良かったなぁというか。
なんていうんですかねぇ、普遍的なスキルっていうんですかねぇ（そういうのがあるとして）。

ま、とにかく勉強します。

迷惑メールに律儀に返信してる人、いそう。

コンピュータは、むずかしすぎて使えない! アラン クーパー Alan Cooper 山形 浩生 翔泳社 2000-02 売り上げランキング : 265789 Amazonで詳しく見る by G-Tools

今これ読んでるけど、すごく面白い。
ユーザーインターフェイスについていろいろ考えさせられる。
バッドノウハウ的な要素も絡んでくる。
プログラマの心理を良く突いていて面白い。
そういえば「プログラマの心理学」って本が家にあるけど、途中までしか読んでないな。今度読も。

以下、ポール・サッフォーって人が書いてる序文から引用。

命からがら逃げ出せ——コンピュータの侵略だ！すさまじくプワフルなコンッピュータが、ますます重要な仕事を、使いにくい古くさいインターフェイスで処理するようになってきた。こうしたマシンが生活のあらゆるすみずみにまでしみこんでくるにつれて、それはわれわれをいらだたせ、おこらせ、何人かを殺してしまうことだってあるだろう。そのおかえしに、われわれはコンピュータを殺したくなるのだけれど、でも殺したりはしない。われわれはすでに完全に、ひきかえせないくらいにこの希望に満ちた化け物に依存するようになってしまっているからだ。これがあるからこそ、現代生活が可能になっている。

アマゾンのレビューを見てみると、訳者（山形浩生）によるの翻訳や「あとがき」に不快感を抱いた、という人が何人か見受けられる。
てことで、「あとがき」を読んでみたけど、そんなに悪い内容とも思えないんだけどなぁ。

せっかくだから、「訳者あとがき」からちょっと引用してみる。

はじめのうちは、要するに著者の会社を雇え、と言っているようにしか本書は読めない。これだけの技能をそなえた人間がそう転がっているとは思えない。そして確かにクーパーはデザイナーはだれでもなれるものじゃない、というようなことも言う。プログラマはデザインはできない、と著者は主張する。そりゃそうだろうなあ、単に観察力や分析力だけでなく、すさまじい対人能力、弁舌、交渉力と調整能力、政治力がないとこんな仕事は勤まるまい。たぶんウチの小渕総理なんかじゃ無理だぞ、これ。でもそんな技能保持者を養成しないとダメなら、ソフト製品って永久に絶望なんじゃないの？

ま、それは確かに現実問題としてそう思う。

後で、もうちょっと何か書く。
ていうか、まだ５分の１くらいしか読んでない。

まるまる一冊「NULL」について書かれた本ってないかな。
たぶん読まないけど。

IT系のネタでホラー映画作れないかな。
「スタックオーバーフローの恐怖」などの題名で。
こっちはもしかしたら観るかも。

…

あ、独り言なのであまり気にしないでください。

社内勉強会でどういったことを勉強するかを投票により決めようということになり、wiki上でまず候補をあげていくことになった。
さっそく、「Ruby入門」とか「Refactoring to Patterns」とかが候補としてあげられた。
そこに僕はこっそり匿名で、「ウォーターフォールについて再考する。」というテーマを追加し、以下のサイトを参考として載せておいた。

Waterfall 2006 – International Conference on Sequential Development

誰からの反応もなかった。
完全スルーだった。
orz

新・たけぞう瀕死の日記 – Clickによるステップ数の削減

… 書かなきゃいけないものがあるから自動生成するのではなく、そもそも書かなくて済むような方法を考えるというのが正しい方向のような気がするわけで …

同感ですね。
自動生成ってなんかダサいと思います。
いや、ダサいとかそうい問題じゃなくて、必要な時と場合もあるってのはわかるんですけどね。
自動生成ってのは、なにかのギャップを埋めるための暫定対応的なものなんじゃないかと思います。

ていうか、よりハイレベルなソリューションにおいては、自動生成とかはもはや言われなくなるんじゃないでしょうか。
どういうことかと言うと、例えばバーチャルマシンを例にあげると、あれって要はマシンが実際に実行するための命令を自動生成しているわけですよね。
でも、それをあえて自動生成とは言わないですよね。
単純化しすぎか。

So-net blog:Welcome 2 tomo’s blog!:J2EE design decisions

最近 POJOs、ライトウェイトフレームワークの話題が賑わせていますが、盲目的にそれを利用することは、EJB で犯した問題を繰り返すことになると警告しています。どんな技術でも強みと弱みがあり、それを理解してデザインを決定することが重要であると述べています。

確かに。

Javaの世界にいて感じるのは、「自分で選択できていないなぁ」という感覚。
EJBってのを聞かされると、「ああ、なんかそういうのが良いのかなぁ」とか思ってしまったり。
「これからはWebサービスかなぁ」と根拠無く思ったり。
なんていうか、「この目的のためにこれを使うぞ！」というような、強い確信を持つことができないことが多い気がする。

ま、僕みたいな下っ端が決められることなんてあまり無いんですけど。

…

話はそれるけど、「自分で選択できてる感」って結構重要だと思う。仕事等において。
たとえそれで失敗したとしてもね。