« 2008年3月 | トップページ | 2008年5月 »

2008年4月の8件の記事

2008年4月30日 (水)

ウィキノミクス

読み終わっていたのだがentryを上げていなかったので、書いておく。

簡単に言ってしまえば、「様々な技術や仕様のオープン化することにより、自社内だけではなく、世界の優れた人材を活用することができ、それによってより生産性が高まる」という事について語っている本。

以前にも書いたが、僕は「富の未来」と「ウィキノミクス」と「フラット化する世界」は個人的には今の時代を概観するための必読書三冊(上下も数えると五冊)だと思っているのだが、その中で本書は特に多国籍企業のとるべき戦略について語っている。

金鉱山の会社の印象的なエピソードで幕を開け、ボーイング、IBM、中国のバイクメーカー、BMW、P&Gなどの新旧の会社が、インターネットとオープン化の時代に「マスコラボレーション」によって如何に成功を収めているか、収めつつあるかについて、多くの証言に基づいて語る。

本書ではマスコラボレーションが万能ではないし、何でもオープン化すればよいというわけではないとは言いつつも、それこそが企業が今の時代を勝ち抜いていくためには大事な事であると語る。翻って自分の仕事の現状を見ると、とても仕様のオープン化など言っているどころではなく、ひたすらクローズドな世界になっている。それが会社にとって長期的にいいことなのか悪いことなのかは分らないが、単純に生産性向上という視点で見れば、仕様をオープン化した方が低コストでできる気がしてならない。そして、企業で働く個人としても、マスコラボレーションの時代がうれしいことなのかどうなのか難しいところだと思う。容易に世界中から高い技術を低コストで使うことができるとするならば、自分がそこに存在している意義はなんだろうか?これは哲学的な問いなのではなくて、単純に、自分は会社に雇われるだけの価値を持ちうるのか?という問題だ。要は「オレ、用なしになっちゃうんじゃない?」ということ。

ボーイング社は個々のパーツの設計業務から手を引き、世界中のパートナーの調整役として生きていく道を選んだとある。僕も、世界中のパートナー各社に個々の設計は任せて、自分はその調整役として生きていけるよう、スキル選択していくことが経済合理的な行動なのだろうか?技術を学ぶべきではない?未来は分らない

| | コメント (0) | トラックバック (0)

2008年4月29日 (火)

雨の降る日曜は幸福について考えよう

この詩的なタイトルの本は、日経新聞の日曜版に連載されていた。第一回目は友人が自殺した話から始まる。

橘玲の巧さはタイトルにあると思う。そしてその巧いタイトルに負けない、それ以上の内容を持っている。たとえタイトルから想像されるようなメルヘンチックな話題ではないにしても。

本書は、橘玲ファンにとってはおなじみの内容(保険は宝くじ、持ち家は高リスクな投資、国民年金は払った方が得で、サラリーマンの厚生年金は損)が繰り返される部分もあるが、新たな発見もある。ひとつは、橘玲の過去について少し語られていること。またFAQの章では「あなたは誰ですか?」という問いに対してもちろん明確な回答は無いが、誠意を持って答えている。そしてもうひとつは、「PARTII正しさの問題」と参考文献において、橘玲が自分自身の思想的背景について語っていること。僕は、著者の、現実主義的であると同時に語り口が詩的で、達観しているかのような物言いに魅力を感じていたのだが、まさか、「ポストモダン」の影響下にあったとは。

僕はファインマンとドーキンスが好きで、彼らが、ある種の哲学を「中身のない言葉遊びに過ぎない」と断じているのを読んでから、「ポストモダン」については少々疑いの目で見ている。特にドーキンスは「ポストモダン」が大嫌いみたいで盛んに著書で馬鹿にしている。なので、橘玲に「ポストモダン」の影があるとは驚きだった。(ちなみに僕は「ポストモダン」についてのちゃんとした知識は無いので深追いはしない)

詩的なタイトルに反して、現実的な内容(曰く、「知人はこの底辺校に奉職しているが、自分の職場は教育機関ではなく、生徒の収容施設だと言う。わが校の責務は、日中、異様な風体の子供たちが町を徘徊し、健全な社会生活を脅かすのを阻止することだ。」)でありながら、哲学的な背景を持っている。そんな多重性を持った本をものす橘玲は稀有な作家だと思う。

| | コメント (0) | トラックバック (0)

2008年4月19日 (土)

理想のシステム開発

理想のシステム開発は、「現実に則った」ものであるべきだと思います。現実のシステム開発で苦しいのは「お客さまや上司の理想」を実現しなければならない、でも現実にはそうは行かない点です。理想ではすべてのパターンを洗うべきだけど。理想では仕様をすべて把握すべきだけど。理想ではあらかじめ仕様をすべて確定すべきだけど。などなど。

理想を追い求めるべきだとも思いますが、実現不可能な理想を掲げて進捗やバグ数をごまかすよりも、現実的で納得性のある手法をチームみんなで実行していくことの方が、みんながハッピーになれて、長期的には良い品質のシステム開発ができるのではないでしょうか。ただ、そのためには、チームのメンバーの意欲、向上心、スキル、が必要になるとは思います。

お客さまや上司からの厳しい要求→モチベーションの低下→下がる生産性→さらなる厳しい管理・・・の負のスパイラルから抜けだし、上司からの現実的なスケジュール、リソースの提示→モチベーションの向上→向上する生産性→自律的なチーム運営・・・の正のスパイラルに進みたいものです。

PMBOKなどの世のプロジェクト管理手法には、このような事は記述されているのでしょうか。

プロジェクト管理って何なんでしょう?プロジェクトの成功って何で判定するのでしょう?プロジェクトの成功とメンバーの幸せとはどういう関係があるのでしょう?

とりあえず、スキルアップに励むところからはじめます。

| | コメント (1) | トラックバック (0)

2008年4月18日 (金)

edとヒアドキュメント

いまどきedなんて使う人いるのかと思っていたら、最近edってありがたいなーと思う機会がありました。ヒアドキュメントと正規表現を使えば素敵なスクリプトがかけますね。

たとえば、狂信的zsh信者なら
#!/bin/sh
PASSWD_FILE="/etc/passwd"
ed $PASSWD_FILE << EOF
%s/\/bin\/bash/\/bin\/zsh/g
w
q
EOF

これでみんなのシェルを強制的にzshに変えられます。crontabに仕掛ければ直しても直してもzshです。ヒドイですね。現実的にはたくさんのサーバでファイルを同じ様にに編集しなきゃいけないときとかに使えます。

あーよく考えたら、edの代わりにvimでもおんなじ様にできるのでしょうね(未検証)。でもedの方が軽くてスクリプトになじみますね。

ではまた。

| | コメント (0) | トラックバック (0)

2008年4月16日 (水)

「関係の空気」「場の空気」

日本語だとか空気だとかみんな一家言持っていて、かくいう僕も日本語の使い方について気になるほうなのですが。

僕の今までの感覚として、「現代の日本語」について批判的に語る人は、その人自身が語る「仮想敵としての現代日本語」に違和感があるなぁと感じていました。あなたが批判している「現代の日本語」はちょっと現実とズれてるんじゃない?と。逆に柳原可奈子の話す「現代日本語」にはリアリティがあるなと思います。だから笑えるのでしょう。もっと言ってしまえば、日本語について語る人は「現代日本語」の最先端について行っていないのではないか、普段本ばっかり読んでて音声でナマの日本語を使っていないのではないか?はっきり言って空気読めてないんじゃない?

で、本書の著者の持っている日本語感覚のリアルさに驚いたわけです。

本書は日本語の持つ「関係の空気」を利用した高密度な1対1のコミュニケーションの良さと、反面「場の空気」による非論理的な決定がなされてしまう不合理さ。について語っているわけですが、一番のキモは、「公的な場では、ですます調の丁寧語をスタンダードとすべきである」という主張です。これは日本語の乱れを嘆いてのことではなく、「場の空気」が支配することによる閉塞感を打破するためには、お互いの関係性を対等に保つことのできる「ですます調」を使うべきである。という理由からでした。

タメ語が醸し出す上から下への威圧感については深く考えたことがありませんでした。口下手な僕としては、むしろ、親しみを醸し出すためにわざとタメ語にするのが高度なコミュニケーションスキルの一部かとすら思っていました。(一対一の場合はそれでもよいのかも)

とにかく、現代日本語について一家言持っている人は、ご参考まで。

| | コメント (0) | トラックバック (0)

2008年4月 8日 (火)

デッドライン

プロジェクト管理業界では有名らしい、デマルコさんの本です。プロジェクト管理のコツについて、物語の形式を借りて語ります。ビッグ テレフォン&テレグラフ社をリストラされようとしているトムキンス氏が、旧ソ連のモロビア共和国の美人スパイに連れ去られるところから話が始まります。

おっさんが美人スパイに連れ去られるなんて、眠たい展開だなーと、はじめは思っていたのですが、話が本題の「プロジェクト管理実験室」に入ってくると、ソフトウェア開発でいかにもありそうな困難な事態(突然のスケジュール変更、突然の追加プロジェクト、高圧的な上司)に対して、トムキンス氏が様々な人に教えを請いながら「開発者フレンドリー」な解決策でプロジェクトを成功に導く様に引きこまれてしまいました。

トムキンス氏が行ったプロジェクト管理は、ソフトウェア開発における理想かもしれませんし、ある意味ファンタジーなのかもしれませんし、もしかしたら現実的な話なのかもしれません。現実であってほしいなと思います。

また、本書では「デバッグに時間がかかるなら、デバッグが不要なくらい高品質なコードを作ればよい。それには可能な限りコーディングを遅らせて設計をしっかりやれ」と書かれています。これは最近流行のコーディングしつつ仕様を固めていく、テスト駆動開発と相反するのかなーとか思いました。どっちが正しいとかはないのだと思います。

ソフトウェア開発、プロジェクト管理で苦労した人こそ(管理者も開発者も)、楽しめる本だと思います。トムキンス氏のような管理者に出会え/なれますように。

| | コメント (0) | トラックバック (0)

LINUXデスクトップHACKS

結論から言うと、訳が酷くて全部読んでません。翻訳は株式会社ドキュメントシステムというところですが、バイトの大学生が訳したのでしょうか?bashのターミナルのカスタマイズの項に惹かれて深く考えずに買ってしまったのですが、正直ちょっと後悔してます。

内容としては、デスクトップHACKSというタイトルにも関わらず、単純な「デスクトップの見た目」の話だけではなくて、ブートにまつわる話題やカーネルの話、ハードウェアの話も載っていて、個人的にはそっちの方が興味深いです。が、いかんせん訳が酷い。「究極的な端末の透明性」とか。。。これなら原文のままで、ページの下に難しい単語の意味を載せた中学校の教科書スタイルの方が分りやすいと思います。

あまり悪口は言いたくないのですが、内容に期待していただけに、残念だったので。オライリーは、もうちょっとユーザーフレンドリーになってもいいなぁと思います。

| | コメント (0) | トラックバック (0)

2008年4月 5日 (土)

bashの改造

bashを改造して、入力コマンドのログを記録するようにしてみる。入力したコマンドを知るためにはlastcommとかあるけど、イマイチな感じなので。。。と思って、とりあえず、ここからbashのソースをダウンロードする。その後、

$ tar zxf bash-3.2.tar.gz
$ cd bash-3.2
$ ./configure
$ make

でとりあえずmakeしてみた。どこにmainがあるんだろうと思ってgrepしてみたら、何箇所かmainが出てきて戸惑う。で、改めてソースファイルを見てみると、eval.cとかshell.cとかexecute_cmd.cあたりが怪しい感じ。色々見てみると、COMMANDっていう構造体(を起点に構成される各種構造体のリスト)に入力コマンドが単語に分かれて格納されているみたい。コメント文にbisonがどーのと書いてあるソースがあったので、おそらく、bashの入力文字列をまず構文解析して、その結果をいったんCOMMAND構造体群に格納しているのではないかなと。

で、僕が欲しいのは入力文字列なのだけど、これまたprint_cmd.cっていうそのままのソースがあったので、そこに仕掛けをして再makeして実行してみたけど、残念ながら入力コマンドがログに出力されない。ちょっとハズしたみたい。ただ、make_command_string()っていう、COMMAND構造体から文字列を生成する関数は使えそう。

で、結論を言うと、execute_command()っていう関数内で、command変数をmake_command_string()に渡して文字列化して、それを出力するととりあえず満足する結果が得られました。興味のある方は、execute_command()関数内で、入力コマンドをログ出力するなり、syslogに渡すなり、標準出力に出すなり、色々やってみてください。

なお、このページではdoxygenで作ったと思しきオープンソースのドキュメントが公開されています。バージョンが古いですが、bash-2.05bも載ってます。

| | コメント (0) | トラックバック (0)

« 2008年3月 | トップページ | 2008年5月 »