「あるまじき」とアルマジロって似てるよね!
てくるで今日聴いた講演について。はっきりいって、内容そのものはつまらなかった。 が、少なくともあのセンセイは臨床で真面目に大脳を研究している神経科医のようで、 いわゆるTV局ご用達の“脳科学者 (かっこ藁)”とは違うらしく、 主催者の見識を疑うような人選ではなかったので安心した。 でも講演は面白くないんだよね。
プレゼンテーションの訓練のむずかしさは、スポーツのようなものとは違って、 客観的な評価ができないし、自分のどこが悪いのか、自分ではわかりにくいところにある (逆にいえば「自分の悪いところ」がはっきりわかっていれば、 それだけで問題の 90% はすでに解決したといえる)。いっぽうで、 世の中にはこんな規則をまったく教えなくても、ほぼ“天然で”いい発表ができる人がいる。 そしてそれは「言葉の流暢さ」とはとくに関連がないようだ。 実際、新山は「英語がカタコトだが、すばらしくいい説明をする」学生を見たことがある (ブルガリア出身の Roumen、彼はいまどうしているだろうか…)。
どうしてそういう違いが生まれるのだろう? 結局、プレゼンテーションというのは 究極的には「通じりゃなにをやってもいい」わけだ。これは商売というものが 究極的には「儲かりゃなにをやってもいい」のと似ている (もちろん、本当に なんでもいいわけじゃないが、少なくとも世の中のいろんな商売をみると、すごい自由度があるだろう)。 逆にいえば、つねに決まりきった方法に頼っていては、ろくな成果は望めない。 臨機応変に、その時々に応じた創意工夫が必要となる。 結局、プレゼンテーションの極意を一言で表現すれば
Be creative. (創造的であれ)ってことにつきるのだ、と思う。
おっと、誤解しないでくれよ。日本語では「創造的」というのは、なんか芸術家じみた、 バタくさい、iPhone的なイメージをもたれることが多いが、 「創造的」というのは「前衛的」「他人と違うことをしろ」ということとは違う。 「自分のアタマで考えたことをやる」ってことなのだ (と新山は考えている)。 他人の出した答えをそのまま写すのは、どうみても創造的ではないから。 自分で考えた末に平凡なやり方に落ち着いたとしても、それはそれでいい (そうする必要がある時は)。ただし重要なのは「自分で納得するまでやってみる」ところにある。 もちろん、世の中には、すでに頭のいい他人が考えた良い回答が山のようにたくさんあるわけで、 それをパクらない手はない。しかし、何よりもその前に「まず自分で考えてみたか?」 ってところをオレは問いたい。そもそもプレゼンテーションってのは、相手と状況によって千万差別で、 ちょうど小説が何万種類も書かれているのと同じように、毎回毎回が新しい状況・新しい問題なのだ。 新山は「人間はみんな生まれつき頭がいいはず」という 性賢説 (←なんか漢字にすると、アヤしい) 論者であるので、ほとんどの人は ちゃんと考えればまともな回答を出すものと信じている。 ただし問題は、自己の責任で答えを出すのはリスクがともなうので、 多くの人々は (とくにいまの日本のような完璧主義社会では) それを極端に恐れるということだ。その結果、下手なプレゼンばかり増えるってわけ。
リスクなんかクソくらえ。
Madoff氏、ほとんどの被害者が「基本的な事実を調べようともしなかった」と供述。
ベルナール・メイドフって知ってる? 日本ではゼーンゼン有名じゃないが、 ようするに「豊田商事事件」を全世界に拡大し、さらに長い長い時間をかけて熟成させたともいえる、 宇宙最大規模の金融詐欺の犯人である。2008年に崩壊した。40年以上にわたってズーっと詐欺を進めてきたが、 本人 (もとNASDAQ社長で、ウォール街1番の高給取りといわれていた) の社会的地位があまりにも高かったため、 身内から告発されるまでバレなかった。そんで崩壊したあとにフタを開けてみたら、 一連の詐欺で総額1700億ドル以上がだまし取られていたという。 1700億ドルって、よくわからんが日本の国家予算の半分ぐらいか? ちなみに本人はこの種の罪としては最高の懲役150年を言いわたされ、現在服役中。 こういう犯罪を取り締まる立場にあるSECにとっては破滅的な不祥事。 いろんな意味でちょっと信じられない事件なのだが、いちばん驚いたのは当のMadoff本人だったらしい。 「この手の犯罪を捜査しようとしたら、まず手形交換所の記録をあたるのが基本だ」とMadoff氏。 ようするに、SECの捜査官さえも基本的な事実関係をチェックしていなかった。 なぜなのか? かつてヒトラーは「たいていの悪党は小さなウソばかりつくから失敗する、 途方もなく大きな嘘をつけば大衆はみなそれを信じてしまう」というようなことを言った。 こういうニュースをみると、やはり「人類は、みな騙されたがっている」といった言明を思い出してしまう。 いまごろになって被害者はみんなMadoffを訴えているが、もう後の祭りだろうね。
しかし、この人、自分の身内にも知られないほどの秘密主義者だったというが、 バレそうになった機会がこれまでに2回あるという。そのたびに逮捕を覚悟したが、運よく逃れてきた。 どうやら本人は「バレたらバレたで、その時はしょうがない」と思ってやってたらしい。 自分の置かれている状況を冷静に判断して、かなり醒めた行動をしていたんではないかと思える。 まさしくホンモノの悪党だ。
こういう事件でヒトが騙される背景には、 心理学的な「否認」というものが大きく関連してると思うのだけど、 (つづく)
この季節になると、いまだに昔のことを思い出して後悔するときがたまにある。 新山にとっても「あのときにああしていたらなあ」という分岐点は、 だいたいいまから15〜6年ぐらい前にあるのだが、 しかしその一方で、あのときどんな選択をしても結局 (ケッキョキ) 同じような自分になっていたかもなあ、とも思うのである。 春や夏に一人っきりでいてもべつに何も感じないが、 秋に一人でいるとなんかみょうに哀しいよね…。
さいきん、ここにほとんど薄暗いこと書いてない。これはよくない。
失敗して、それから失敗して失敗して失敗して失敗する。とにかく失敗すること。
そのうち失敗しなくなる。人はそれを学習という。
正直いって、これを言うのは非常に不本意なのだりますが、 C# は今のところ (Python を除いて) 新山のもっとも好きな言語になりつつある。 どの点も極端に抜きんでているわけではないのだが、全体的にバランスがいいのだ。 マイクロソフトを褒めるのはムカつくのだが、はっきりいって「やられた」としか言いようがない。 仕事で使うぶんには、スクリプト言語なら Python で、 それ以外の言語なら C# で (今のところは) ほとんど OK である。 しかし MS が言語でも独占をしてしまいそうなところは危機感をおぼえるが…。 C# はもともと世界征服 (?) を念頭において設計された。 MS は、今のところは Mono などの他実装を (特許侵害で) 訴えないといっているが、 いつまでもつのだか。あいかわらず新山はこの会社を信用していない。 こいつら恐ろしい連中だよ。これには Adobe PDF なんかとはぜんぜん違った雰囲気を感じる。 たとえば PDF についていえば、あんな腐った仕様でおまけに使いやすくもない フォーマットが普及したのは、おそらくそれ以外に代替品がなかったからだろうと思われる。 しかし C# は明らかに競合言語が沢山ある中で「勝ちに行っている」言語だ。 MS のほかの仕様がほとんど狂ってるとしても、C# を設計した連中だけは正気だ。
とくに最近は C# の "event" に慣れてきて、なんでもかんでも event ベースで 枠組みを作るようになってきた。いまでは自分が書く Python のコードでも この手法を真似しつつある。Python で "eventもどき" を実装するのはむずかしくない。 以下のようなテキトーなクラスを作って、使いまわせばよい:
class Event(object):
def __init__(self):
self.procs = []
return
def add(self, proc):
self.procs.append(proc)
return
def remove(self, proc):
self.procs.remove(proc)
return
def fire(self, *args):
for proc in self.procs:
proc(*args)
return
eventベースの枠組みは並列プログラミングでとくに有効だが、 逐次的な処理でもこの書き方は役に立つ。と、いうのは、 ある処理を event を使って書こうとすると、自分でもそれまで明示的には 気づいていなかった “隠れた依存関係”をコード上に明示的に表現せざるを 得なくなるからである。逐次実行だと制御の流れそのものが文脈になるので、 見落としやすい依存関係をきちんと発見し、それをわかりやすいやり方で 切り離しておけるのは、とってもいい。とにかくソフトウェアには「分離」が必要だ。 この意味で、ソフトウェア開発で要求される技能というか「気質」は、 アルゴリズム設計なんかのそれとはまるきり違う。
そういやー、こないだ会社で「片付け士」なる肩書きの人から整理整頓の重要さを聞いたんだよ。 でも、はっきりいって新山にはたいして役に立たなかった。なぜなら、自分でいうのもなんだが、 整理整頓はオレにとって普段の「組み込みバックグラウンドタスク」としてあまりに一体化しているために、 ある意味でオレは「整理整頓そのものが人生」という感じになってしまっているからだ。 品物も人間関係もきれいサッパリ切り落とす、という方針でして…。 そもそもソフトウェア開発の本質は、新山にとっては整理整頓だと思っている。 いろんな要求やら制限やらを区分けし、自分の世界観に従って 「あるべきところに」設置したもの、それがソフトウェアだ、というわけだ。 そんな新山にとって、整理整頓に (つまり設計開発にも) 重要な要素は 「達観」と「思い切り」である。物事を整理するためには、さまざまな現象が 自分の頭の中で、収まるべき所に収まっていなければならない。 そして一旦それが決まったら、あとはすみやかに、ためらうことなく一気に 遂行せねばならない。新山はこのようにものすごい直観主義なので、 他の人はいつも見ていてハラハラするらしいが、 余計なためらいはかえって事故のもとになる。 しかしいつもなかなか達観が得られずに苦労するのだが。
ところで、「イベント指向」「データフロー指向」といわゆる "hollywood principle" って意味的には具体的にどう違うのだろう? なんか、どれもお互いに関連してそうな気はするが、どれも別々の階層のことを 言っているようにも思える。まだはっきり自分の中で整理できてない。
新山は最近、メールがきたら通知する機能を使わないようになった。 なぜなら、中途半端なメールに反応してると気が散って、かえって効率が悪くなるからだ。 それよりも、コーディングが一息ついたときにメールをチェックすることを好む。
これは、まさに pub-sub とポーリングの利点や欠点と同じだ。 ポーリングは、メールが来てもすぐには反応できないかわりに、自分のペースで仕事できる。 いっぽう、メールチェックをしてばっかりで仕事が進まない人は、 まさに livelock の状態になっている。
もっと卑近な霊でいうと、人は必ずしも機能の多いほうを望むわけじゃないし、 必ずしも値段の安いものさえ望まない。「もし人が合理的ならこう判断するはずだ」という 憶測にもとづく設計は、じつはあんまり成功したためしがないのかもしれない。 とりわけ営業や工学ではこれはそうである。
よく覚えている、覚えて覚えて覚えているよ、気がトンだ時のことを
あの場所にはとてつもない悦びが支配してた
自分の感情さえ反響するようだった
広い宇宙の中で
その場所にいたとき
まったくおかまいなしに
ああ、気がふれていたよ
でもそれは世の中を知らなかったからじゃない
知りすぎていたからだ
俺はキチガイになってしまうのか?
僕はキチガイになってしまうのか?
アタシはキチガイになってしまうのかしら?
たぶんね…
どことなく哀しい曲調なのがいいよね…
あたりまえのことだが、たいていの技術書や入門書は、独学者向けに書かれている。 しかし、この業界はいまでも徒弟制度がいちばん有効な教育方法であるので、 企業なんかで同僚にしょっちゅう質問したり、技術をいくらでも「盗む」機会のある人には、 はっきりいって技術書や入門書なんかいらない。書籍はそういう機会のない人を対象とすべきだ。 「情報量」だけでは意味がない。そういう意味で、新山はいわゆる「専業」ライターによる 書籍をあまり信用してない。あるいは実用主義でなく、ほんとに体系立った入門書を書くなら、 アルゴリズムとデータ構造の基礎ぐらいしっかり教えろ! でもほとんどの場合、これは大学の教科書の仕事になってしまっている。 非常に脱力する。 あと、プログラミングの簡単さを必要以上に強調する本は信用できない。
ふうーーーーーー…!
てくるで (ところで) ついでに書いておくが、「みんなのPython」はあいかわらずダメな本だった。 (でもWebサービス編はあんがい方向性としてはいいかも? と思ったが、例題がダサい)
てくるで (ところで)、最近うちの会社でもようやくバグトラッキングをやるようになった。 なぜなら社内の開発部員が (今までより1人増えて) 3人になったからで…。 今までの「口頭で報告 → 修正 → 文書化」という流れが追いつかなくなったためである。 といっても、Bugzilla などのシステムを使うようになったわけではない。 新山のいうバグトラッキングとは、単に「バグに一意な名前 (ID) をつける」ことで、 それだけが重要だ。逆に、名前をつけていなければ物事はトラッキングできない。 いままでは、バグの現象を指し示すのに「X月X日に○○さんが言ってた、あのバグ」などと言っていた。 バグを『参照可能にする』ことこそがバグトラッキングの本質で、 『記録する』のは二次的な問題だと新山は考えている。 まあ、実際にはどっかに記録しておかないとだめなのだが、 それはメールでやろうが、データベースでやろうが、そっから先は枝葉の問題である。 しかし「バグに名前をつける」ということは仕事のやり方に関する問題である。 そのためにはヒトの行動規範を変える必要があり、組織でいちばん重要な (そして骨の折れる) 過程はここであると思う。そのためには垣根をなるたけ低くしておかねばならない。 新山がとくに気をつかったのは、社長 (うちの会社では社長もバリバリの製品テスターである) がバグ報告をするさいに、負担にならないようにするということだった。 新山はバグトラッキング用ツールの導入にはかなり慎重だる。 開発がかなり組織化・体系化している会社ならともかく、うちのような会社では 今のところツールの都合にふりまわされる危険性のほうがずっと高い。 アホみたいに簡単なやつなら入れてもいいけど、いまのところはメールを整理しておけばいいや。 この枠組みが確立してから、既存のシステムをそれに合わせるのは、その逆よりもずっといい。
Still drunk.
どうでもいいけど (どうでもよろ)、 U2はなんでこんなに相変わらずカリスマなんだろう? 新山にはちっともわからない。オバマが好きだから? ほかにも Apple に肩入れしたり、 いまいちハリボテくさいバンドだ。どうでもよいが (ようでもどろ)、新山は U2 はぜんぜん好きじゃないのに、 なぜか "I still have found what I am looking for" をいまだにかなり歌えたりする。 なぜなら中学校のときの英語の先生がおかしな人で、授業中に教材として生徒にU2を聴かせていたからである。 こんなのあり? ちなみにこの先生はおボウさんでもあり、何度かうちにお経を上げにきた。 いま考えると、かなり型やぶりな先生だったと思う。
つねにパクられるような存在でありたいものです。
そのあと時間があったので、Software Engineering Radio を聴く。 これは、エピソードによっては当たり外れが大きくあるのだが、 Episode 59: Static Code Analysis の回は非常におもしろかった。将来的には、いま静的コード解析をやってる人々の間から チューリング賞受賞者が絶対出てくるだろうと思う (もう出てるのかもしれない)。 正当性の検証とか、そういう分野ではすでに受賞者が出ているが、まだ一般にはなじみがない。 しかしソフトウェアの監査・検証手法はこれから ますます一般に普及していくだろうし、普及させる必要があると思う。 なぜなら、望むと望まざるとにかかわらず、今後ともソフトウェアは巨大化する一方だろうから。 (そして、そのほとんどはバカがいいかげんに書いたコードになる運命だろうから!) ともあれ、新山はソフトウェア検証には非常に興味がある。 なぜならこれは人間がいかに「筋道をつけて考えるか」を支援する技術であり、 まさにハードコアな計算機科学そのものだ。機械学習にテキトーにデータを投げて、 他人はおろか自分自身をも煙に巻いてるどっかの研究分野とはおおちがい。
…いっぽうで、ソフトウェア“開発”手法のほうは、今後もあいかわらず いかがわしい似非科学のままだろう。新山は (馬鹿にしつつも) これまでわりと いろんなソフトウェア開発に関する文献を読んでみたのだが、どれも感心しない。 どれも「手法」などと呼べるほどマトモなもんじゃないのだ。 こいつらは「必ず unittest を先に書きましょう」とかいう教条主義になるか、あるいは曖昧すぎて ただ意味のない儀式をくりかえすだけの密教になる。ようするに、どっちもまだ“宗教”のままである。 これは政治における「なんとか主義」という分類と似ている。『共産主義』とか、 『新自由主義』とか、『社会民主主義』とか、名前はついていても、それらはあくまで茫漠とした 方針もどきにすぎない。具体的に個々のケースでどのようにポリシーを策定するかは、 結局のところ莫大なデータと細かい分析によって変わるのだ。にもかかわらず、 「××主義」という名前だけが一人歩きして、特定のカリスマ的人物の言ったことを “信奉”する頭のキチガった人々が世の中には多く存在している。 ソフトウェア“開発”手法もこれと同じ。こっちは、しばらくは (あるいはもしかすると永久に) このままだろう。ちょうど政治のそれと同じように。
てくるで、この番組を聴いていてふと思ったのだが、
近年のプログラミング言語設計の流れとして、言語の中の
「より宣言的っぽい部分を増やす」というのがあるような気がする。たとえば
Lisp (+Python) の with や、C# の using などは、
どちらも「言語をより宣言的にする」構文とみなせる。
言語を宣言的にすることのメリットというのは、意味的な制約
(たとえば「fopen() 開いたファイルは必ず fclose() で閉じなければならない」など) を
単純な、機械的な仕組みによってチェックできることだ
(ただしそのかわり書き方の自由度も下がるけど)。
すべてが手続きに分離されているような言語だと、これは非常にむずかしい。
いっぽうで、prolog のようにすべてが宣言的なのも行きすぎで、
まだ中間点はどっかほかにあることになる。
それにしても、大阪の地名は「浪速」とか「戎」とか、読み方で一瞬つまるような漢字がけっこうある。 でも「難波」は「なにわ」じゃなくてストレートに「なんば」なのな…ヘンなの。 中でも「放出」には声をあげてゲラゲラ笑ってしまった。 たいていの変な漢字の読みには慣れているつもりだったが、 これにはヤラレタ。
どんな言語においても、いちばん言うのが難しい言葉って知ってるかい?それは「ごめんなさい」だよ。
-- Desmond Tutu
Document ID: 768783af2b341bb402c2ccfd0bb1a6ef
Yusuke Shinyama