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

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

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

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

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

記事をコンスタントに上げようと思っても、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]
}

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

このところ、「脳開発」がブームになっている模様。 書店へ行けば、

• 計算力を強くする
• 計算力を強くする part 2
• 記憶力を強くする

ゲームを買いに行けば、

• Wiiでやわらかあたま塾
• 脳年齢 脳ストレス計 アタマスキャン

といった具合に、「頭脳系」の商品がたくさん目に付きます。 人間は、「健康な肉体」と同様、「優秀な頭脳」に憧れるもの。 記憶力・計算力も高いに越したことはありません。

しかし、プログラマである私などは、 「計算とか記憶って、コンピュータにやらせるべき仕事じゃないの？」 なんて思ってしまったり。 人間の思考の価値は、コンピュータにはできない、「ミスをする」「飛躍する」「忘れる」といった特性にあります。 その特性こそが、新しい概念、斬新な発想を生み出す下地に他ならないからです。

コンピュータを速く、正確に、間違わず動かすべくあれこれ知恵を絞ってるソフトウェア開発者から見れば、人間というのは敢えて「論理的正確さから外れる」 = 「(部分的にではあるけれど) 間違う」ことを目的として稼働する非常に贅沢なシステム。 そんな贅沢なシステムに、コンピュータでもできる計算力・記憶力を過剰に詰め込むというのは、少々無粋な気がするのです。 「如何に間違うか」こそが、人間の思考の価値なのですから。

現在、XMLパーサ (構文解析プログラム) を作成しています。 DOMと同様、XMLデータを木構造として扱う仕様なのですが、ここで問題となるのがノードの分類方法。 一見して同じような形式だったり、良く似た名前であっても、実際の分類は全く違うというケースがかなりあります。 例えば、「XML宣言」と「文書型宣言」というものがあるのですが、「『○○宣言』という名前だから同じグループに属するんだろう」と思っていたら、これがまったくの別物とか。

「コウモリは翼を持っているから鳥の仲間だろう」というような誤りに通じるものがあります。 「コウモリは鳥類」という前提で研究を続けていたものの、ある日唐突に真実に気が付き、打ちひしがれる生物学者。 「よく考えたら、こいつ間違いなく哺乳類じゃん……。」

とまぁ、そんなわけで、私のパーサもかなりの部分で書き直しが必要になってしまいました。 ......紛らわしい名前付けんなよチキショー。

先週末は会津美里町 (旧会津高田町) にある、蓋沼森林公園へ行ってきました。 冬に行こうとした際は入り口を見つけられず、柳津町の方へ向かってしまいましたが、今回はちゃんとたどり着くことができました。