フォルダのどこに何があるかわからないから整理して!

by tanabe on December 30, 2006

新年一発目の仕事のための備忘録。

ファイル共有サーバの整理を求められた。
旧いリソースを有効に使うために、フォルダ構成の標準化をしたいらしい。

問題を定義しなおそう。

今の一番の問題は?

  • どこに何があるかわからない → ×
  • 必要な情報が必要なときに見つけられない → ○

つまり、検索性が低いことが問題!

ということで、ソリューション。

Let's Google.
http://www.google.co.jp/enterprise/mini/index.html



「一覧性が必要な常に使う標準的なファイルたち」については、Wikiにでもまとめてメンテすればいい。(つまり、インデックス化)

物理的な配置への依存とコピーなどによるメンテナンスコストが大きく、拡張性に乏しい「フォルダ構成」というユーザインタフェースにいつまでもこだわるのは止めましょう。

ってことで。

  

Ruby, Rails, HSP とイノベーションのジレンマ

by tanabe on December 22, 2006

まつもとさんの「まつもとゆきひろ氏のHSPに対する見解について」に対する反応のエントリを読んで、非常に興味深かった。ただし、メインテーマとはまったく関係ないところで。(つまり、HSP 自体の言語としての価値や意義はまったく今回の話の対象外。)

興味を惹かれたのは次の一文。

まあ、「正しい言語」とか存在しないんだけど、それでも「良い言語」と「そうでない言語」はあると思う。しかし、「そうでない言語」であっても当面の目的を果たすのに十分であれば、ユーザを引きつけられるということか。

言語デザイナーの方の感じる「良い言語」とユーザの求める「良い言語」にズレが生じたときに、プログラミング言語でもイノベーションのジレンマ的な現象が起きるのかな、という興味を持ったのだ。(それは必ずしも「良いプログラミング言語」ではないだろうけど。)

ただ、よく考えてみると、プログラミング言語における破壊的イノベーションは、いわゆる総プログラマ社会と同じ話なのかもしれない。

振り返ってみれば J2EE に対する軽量コンテナのように、要求と設計のギャップとそれに対する対抗技術というのはこれまでも存在したし、そもそも Ruby だってできることを全部やるのではなくてある面で削ぎ落としているから、楽しいプログラミング言語になっている。

その一方で、例えば Rails のように DSL 的に働く Helper や plugin を大量動員して開発量は減らすという、フレームワーク+カスタマイズ型の流れというのも明らかに方向性として出てきている。(もちろん、Java系のフレームワーク+XML 設定ファイルというのもフレームワーク+カスタマイズだろう)

この流れがぐーっと進んで、しかも導入の敷居が下がると、どこかで懐かしの(?) End User Conputing との再開を果たして、よく言われる総プログラマ社会に突入をするのかもしれない。(そういえば、 Salesforce.com がやっていることはまんまこれだな。どちらかというと、ERP からの流れなのだろうけど。)

まぁ、他にも何やらもやもや考えたけど、もう一つまとまんなかったので、途中までで投げてしまおう。

  

クイックソートって。

by tanabe on December 17, 2006

よくないネーミングだよなぁ。

  

Gmail について本当に注目すべきなのはメール消えるかもよって件の方。

by tanabe on December 11, 2006

はてブでおお、Gmailはこれで完璧になった」という記事が注目を集めている。

Plagger のクライアントとして Gmail が好まれているのでもわかるけれど、Gmail のインターフェースやユーザビリティはたしかに好ましい。ぼくも普段使いのメーラーとして頻繁に使っている。

ただ、本当に注目しないといけないのは、

まぁ、まだGmailはβテスト中なわけで、バックアップもなしに使う方が悪いのである。
というたださんの二つのエントリの方だろう。

使うときには、十分に気をつけて。

  

所信表明

by tanabe on December 11, 2006

ブログの、ではなくて仕事の方での表明。

思いつきでも、早とちりでも、楽観主義でも、とにかくやった方が良いと感じたアイデアはアウトプットするようにしよう。

すべてのきっかけはアウトプットと偶然だけが生むのだし、疎まれるのはほとんどの場合アウトプットの行為そのものではなくて、そのやり方(タイミングとかアクションプランの有無とかね)なのだから。

  

Aクラスを手なずけると言えば。

by tanabe on December 11, 2006

はてブで小盛り上がりしていたあの話は、otsune さんのこのエントリがおもしろかった。

思うに、「この仕事はその人じゃなければ出来ないんだ」という属人性の高い仕事に、高いサラリーを支払う仕組みってのは会社経営的には脆弱なんじゃないか?

たしかにリスク管理としてはそうなんだろうと思う一方で、「その人じゃなきゃできない」ような仕事なくしてどうやって他社と差別化するんだよ!というツッコミのできる大企業病のような気もする。誰にでもできることばかりじゃ、戦略的な勝利はあり得ないだろうっていう。

そして、自分へのツッコミとしては、誰にでもできることを誰にもできないレベルにまで組織として磨くと、トヨタとかマクドナルドみたいに勝てる企業になるんじゃない?っていうものもある。

最後に、話の根っこの記事は興味なしってことで。

  

人より優れた虫けらとして生きる

by tanabe on December 11, 2006

あー、うん。とむっつり型ナルシストの自分がうなずいた気がしたので、メモしておこう。

「自分は人より優れていると感じて一生を過ごす人もいれば、虫けらのようだと感じて生涯を送る人もいる。そしてナルシストは、自分は人よりも優れた虫けらのようだと感じながら人生を送る。」のである。

Harvard Business Review January 2007 の記事「困ったAクラス社員を手なずける法」より。

ちなみに本題の方の感想なのだけど、最近のプログラマー界隈を見ると、意外に唯我独尊型の天才は少なくて、ギークとして名を馳せている人は、コラボレートの能力が高い気がする。(つまり、Aクラスは”困った”タイプなことが少ない気がしている)

これはオープンソース以降の文化的な影響だと思うのだけど、どうなんだろう?コラボレートできる人はより情報が集まって高度な段階に進めるけれど、そうでない人は集められる情報に限界があって結果として相対的に低いレベルで壁ができてしまう(あるいは留まらないまでも成長の速度が遅くなる)からなのではないかと予想しているのだが。

それともこれは未熟な過渡期ならではなのかなぁ。

伊藤直也さんの宮川さんに関する記事を読んで以来、ずっと自分の中で興味深いテーマになっているので、今さらの話題ではあるのですが、エントリしてみました。(うーん、虫けらからずいぶんと関係ない方向に話が飛んだな。)