Windows Vista の発売から五ヶ月が経過しました。 その性能については賛否両論あるようですが、私の個人的な意見としては、「ダメOS」でファイナルアンサー。

欠点をひとつひとつ挙げていくときりがないのですが、その中でも致命的なのが、インターフェイスの大幅な変更です。 エクスプローラのレイアウト改変に始まり、新しいボタンコントロールの導入、メニュー構造の変更等々、Vista はそれまでの Windows ユーザが習得してきたインターフェイスをばっさりと切り捨ててしまいました。

それでも、こうした新しい要素を取り入れることで、作業効率が上がる、あるいは、習得が容易になるといったメリットがあれば良いのですが、そのような効果は殆ど見られません。 「目新しさ」を出すことで、買い替えを促すといった狙いがあったようですが、ユーザの反応を見れば明らかなように、その「目新しさ」が仇になっています。 (Office 2007 が導入したリボンも同様の問題を抱えていますよね……。)

インターフェイスの変更は、例えそれが改良であっても、ユーザには大きな負担となります。 そのため、そうしたデメリットを上回るメリットが見込めない限りは、インターフェイスの変更を見送る、あるいは、旧スタイルでの操作も可能にする、といった措置が妥当だと思われるのですが、そうした発想は微塵も見受けられません。

そんな「ダメOS」の失点を挽回するためか、Microsoft からは早くも次期バージョンである Windows 7 の情報が出されています。 しかし、発表の内容を見る限りでは、ユーザが望んでいるのとは掛け離れた方向へ進化している模様。 Windows XP が第一線を退くのはまだまだ先のことのようです。

アルバイトの学生などと接していて、「惜しいな」と思うのが、表現・説明能力の低さ。 せっかく素晴らしい技術や感性を持っているのに、それを相手がきちんと理解・把握できる「言葉」に変換できないために、損をしている部分が非常に多いのです。

確かに、己の知識・技術を中身のない言葉で大仰に飾り立て、過剰に表現する輩は信用ならないものですが、だからといってその説明を放棄してよい、というわけではありません。 誇張せず、矮小化せず、自分の持っているものをありのままに伝える努力をすれば良いだけの話です。

相手の思考を楽観的に期待している状況…、これを、甘えている、というんだ。 いいかい、気持ちなんて伝わらない。 伝えたいものは、言葉で言いなさい。 それがどんなに難しくてもそれ以外に方法はない

『詩的私的ジャック』/ 森博嗣

どんなに優れた才能も、内に秘めているだけではまったく無意味。 知識も技術も、それを持っていることではなく、「理解され」「使われ」ることに価値があるのですから。

記事をコンスタントに上げようと思っても、1年365日24時間おもしろおかしいことが起きているわけではないので、今日のような「日記のネタが見つからない日」というのも (たまには) あります。 そんなときに役に立つのが、「その日食べたものについて書く」という無難にして (それなりに) 恰好の付く種類のエントリ。 しかしながら、「僕は昨日ししゃもを食べました」のような内容ではいかにも芸がありません。

というわけで、昨日の私の夕食の中の一品を、作り方を添えて紹介しようと思います。

「リーダになりたくない」という人が増えているとか。 言われてみれば、周囲の人々を観察する限りにおいても、そうした傾向は確かに見受けられます。

しかしながら、組織の規模がある程度以上になると「１人のリーダがいて、残りはすべてその人に従う」とった形態では立ち往かなくなります。 そのため、企業・軍隊などの組織は、その構成員を機能ごとに「部」「課」「係」 (あるいは「団」「隊」「班」) といった単位に分割し、それぞれにリーダを割り当てることで全体の統治・運営を行っています。

「リーダ」というのは非常に特殊かつ責任の重い役割に思えるかもしれませんが、(よほど大きな組織でない限り) より高い視点から見れば、「人」という「機能」を束ねるという「機能」のひとつでしかありません。 つまり、「リーダ」というのは、その他の役割と (権限はともかく機能的には) 同列であり、それほど特殊なものではないと言えます。 このような考え方に基づけば、「リーダ」に対して過大な期待や責任, 権限を求めることはなくなるため、誰もが自分の能力に応じてこの役割を引き受けることが可能になるのではないでしょうか。

リーダを立てられないというのは組織としては致命的であり、その原因は「責任を他人に押し付けて、自分は楽をしたい」という個々の (そして全ての) 構成員の幼稚さ・未熟さにあります。 そんな状況から抜け出すための最も手っ取り早い手段は、まず自分が立ち上がること。 「あなたがやらねば誰がやる?」ってヤツですね。

機械部品の故障は、他の部品との接触や、内部抵抗の増加 (あるいは短絡) によるものが殆ど。 それらの現象によって部品は変形・破壊されて正常に動作しなくなり、結果的にシステム全体が機能不全に陥るわけです。 この変形・破壊の際に生じるエネルギーの一部は「音」として周囲に放出されます。 構造内部で発生した音は、破壊が起こす他の現象 (見た目の変化や熱の発生) よりも早く顕著に外部に伝わるため、システムトラブルの最初の兆候が「音」の異常として現れるケースは少なくありません。

ハードディスクが壊れるときの「キューイ」あるいは「カラカラ」といった音、モニタが映らなくなる前の「プツプツ」といった音がその例。 完全に壊れる前であっても、異常な動作によって失われたエネルギーは音となって私たちの耳へと届きます。 (もちろん、すべてのものが壊れる前に音を出すというわけではありませんが。)

コンピュータに限らず、機械類全般、さらには生き物の身体でも同じことが起こるため、エンジニアや医師は「音」を異常検出のための重要なファクタとして位置付けています。 この音による検知能力は、耳の感度だけでなく、「音を積極的に聴く」「異音がないかに気を配る」といった姿勢に依るところが大きいようです。 集中力や気分を高めるために、仕事中にイヤホン/ヘッドホンで音楽を聴くという人が増えてきていますが、少なくともエンジニアとしてはあまり好ましい習慣ではないでしょう。

プログラミングの技術要素は、データ構造に関するものととアルゴリズムに関するものに大きく分けられます。 前者は主として「設計」の段階で、後者は「実装」の段階で必要になる知識と言えるでしょう。

私の見る限り、プログラミング技術に関する教育の場においては、「アルゴリズム (実装技術)」の習得が重視される一方で、「データ構造 (設計技術)」は非常に軽い扱いとなっています。 アルゴリズム関連の知識は、学校の講義・演習のような短時間かつ散発的な講義・演習でも (ある程度は) 習得可能が可能であるのに対し、「データ構造」を選択・採用する知識 (設計技術) を得るにはプログラムの長期的な開発・運用の経験が必要になる、といったことがその理由だと考えられます。

しかしながら、職業としての「プログラミング」においては、この「データ構造」と「アルゴリズム」の重要性が逆転します。 製品となり年単位の長期的なスパンで運用されるシステムにおいては、実装はむしろ些事であり、設計に起因する保守性・拡張性が評価に直結します。

仕様変更が起こったときに、「ああ、この変更はずいぶん前から要求されそうな気がしていたんだよなぁ…」と思うことはありませんか？ やはりここでも設計の善し悪しがものをいいます。 予測される変更を考慮して、それが実際に起こったときの手間を少なくするような設計をしておけば良いのです。 でも現実には、将来への準備を怠っているケースが多いようです。

( 中略 )

どうやら、知恵を使いさえすればしなくても済むはずの苦労が、ソフトウェア開発業界には蔓延しているようです。 これを逆に考えてみると、設計の技術を使いこなしてよけいな苦労を回避できるようになれば、人の何倍も仕事がこなせるようになるということです。

つくる人の味方: コーディングの向こう側 (設計ってナンダ？ – PART1)

ソフトウェア開発者を目指す人は、「実装」だけでなく「設計」を学んでおくと、実際の業務において大きなアドバンテージを手にすることができるかもしれません。

創造力の源は「直感」や「閃き」と呼ばれるものであると一般的には考えられているようですが、実際のところ、直感によってもたらされる着想の 99% 以上は役に立たないゴミ案です。 むしろ、これら膨大な量のゴミの中から 1% 未満の宝 (有益な何か) をより分ける作業こそが、創造という行為の本質ではないでしょうか。

この「より分け」はつまるところ、自分への駄目出しに他なりません。 自分が出したアイディアをひとつひとつ検証し、短所・欠点を探しては捨てていくわけです。 ゴミと宝の比率を考えると、「宝を探す」というよりは「ひたすらゴミを捨てる」という行為に近い上に、「ゴミを全部捨てたら何も残らなかった (全部ゴミだった)」という結論に達してしまうことも少なくはありません。 かくのごとく、創造というものは「閃き」よりもコツコツと「考える」ことによってなされる非常に地味な行為なのです。

ちなみに、「ゴミ案 (宝の候補) すら出てこない」という状態は、基本的な知識・理解の不足によるものであり、「創造力」云々以前の段階です。

「考える」という言葉を非常に安易に使っている人が多いと思う。 学生に「考えてきたか？」と尋ねると、「考えましたが、ちょっと良い案を思いつかなくて」と言う。 「じゃあ、悪い案を幾つか見せなさい」と言うと、きょとんとした顔で、「いえ、悪い案も思いついていません」と言う。 「考えましたが、まだ、ちょっとまとまらなくて」と言うから、「では、まとまらないものを見せて下さい」と言っても、たいてい見せてもらえない。 こういうのは、僕の場合「考えた」とはいわないのである。

( 中略 )

沢山の具体案を考えることは、無駄なようでけっして無駄ではない。 採用されなかった案が、その人の将来の持ち駒になるからだ。

MORI LOG ACADEMY: 本当に考えたの？

「クリエイティブな仕事」というのは、その言葉が持つイメージとは対照的に、とても地味で陰気で気の滅入る作業。 それでもなお、新しい何かへの期待で己を鼓舞し、ゴミの山を築き、そこへ突撃していける者だけが、クリエータたり得るのです。

Perl, Ruby など多くのスクリプト言語では、1つの配列に異なる型のオブジェクトを格納することができます。 Generics 導入前 (1.4 以前) の Java でも、同じようなことができました。 しかし、このテクニックは基本的に使ってはいけません。 次のプログラムを見てください:

books =[
    [ '神は妄想である', 'リチャード・ドーキンス', 2500 ],
    [ '穴 -HOLES-',   'ルイス・サッカー',       620 ],
]

この例では、配列 books の中の要素 (これまた配列) が各「書籍」のデータを表します。 0番目の要素が「表題」、1番目の要素が「著者名」、2番目の要素が「価格」がそれぞれ格納されるという寸法。 なので、すべての書籍の著者名を出力するコードは次のようになります。

books.each { |b|
    puts b[1]
}

......最低ですね。