multiplus

気まぐれに書評とか。

ウィスキー飲みたくなってきた―村上春樹『もし僕らのことばがウィスキーであったなら』

村上春樹の小説はほとんど読んだことがないのですが、エッセイは好きで読んでいる気がします。『職業としての小説家』を読んでから、村上春樹がエッセイを書く時期・短編小説を書く時期・長編小説を書く時期という波をもった作家だと知り、そこからエッセイに興味をもったのがきっかけです。

『ポートレイト・イン・ジャズ』は、ジャズを聴きたくさせるエッセイでした。今回読んだ『もし僕らのことばがウィスキーであったなら』を読んで、今度はウィスキーを飲みに行きたくなってきました。いや、これから冷蔵庫にあるウィスキーを飲みます。

私がウィスキーを飲むようになったのは、バイト先のマネージャーの影響が大きいです。彼に薦められて、バイトの終わりなどにいろいろ試し飲みするうちに、ウィスキーに興味をもつようになりました。そこから、自分自身でウィスキーを買って飲むようになりました。

でも、ウィスキーの味はべつに毎日飲みたくなるほど好きなわけではありません。飲んでいるうちに、人並みに気持ち悪くなってきてやめます。では、ウィスキーをそこまでおいしいと感じていないのになぜ飲むのか?私は、ウィスキーにまつわるストーリーなどを味わいながら飲んでいるのではないかなと、自分自身を振り返って思います。飲んでいる間は、「ウィスキーを飲んでいる自分」に酔うことができます。こう書くとナルシズムっぽいですが。

一方で、村上春樹もこうしたウィスキーの〈記号消費〉をしていないとは言いきれないとエッセイを読みながら思いました。村上春樹がウィスキーの味を表現するとき、そのウィスキーの背景などを交えながら記述していたからです。彼も私と(そして多くのウィスキー飲みと同様に)、ウィスキーのバックグラウンドをたのしみながら飲んでいる人のひとりではないでしょうか。

魅力を「ことば」で伝えなければならない苦悩

さて、この本のタイトル『もし僕らのことばがウィスキーであったなら』についてですが、その裏の意味がじつはあります。

もし僕らのことばがウィスキーであったなら、もちろん、これほど苦労することもなかったはずだ。僕は黙ってグラスを差し出し、あなたはそれを受け取って静かに喉に送り込む、それだけですんだはずだ。とてもシンプルで、とても親密で、とても正確だ。しかし残念ながら、僕らはことばがことばであり、ことばでしかない世界に住んでいる。

村上春樹は、本書を書く際に、ウィスキーの味を表現することにとても苦労したように見受けられます。いつも読むエッセイとは違って、今回は「あ、苦労して書いたんだなあ」というのがまるわかりな気がします。ウィスキーの味ですから、当然それを正確に伝えることは不可能でしょう。ことばを尽くしても、伝わりきらないディティールがどうしても出てきてしまうことには致し方のない面もあります。

が、それ以上に、ウィスキーの味というのはそれほどまでに複雑で奥行きの深いものだ、ということを示唆しているのではないでしょうか。一流のことばの使い手である村上春樹がこれだけ苦心して、最後の最後で「僕らのことばがウィスキーであったらなあ…」とぼやいてしまうくらいに、それくらいウィスキーというのは深いのだなあと思いました。

さて、ウィスキーを飲みに行きましょう。ちなみに、本書に出てくるアードベッグタラモア・デューブッシュミルズは好きでよく飲みます。あと村上さん、バーボンは好きじゃないのかな?バーボンの話はいっさい出てきていませんでしたね…

もし僕らのことばがウィスキーであったなら (新潮文庫)

もし僕らのことばがウィスキーであったなら (新潮文庫)

フロントエンド未経験エンジニアがフロントエンドをちょっといじってみた(1)

普段が忙しすぎてなかなか最新鋭のsomethingを触る機会がないので、お正月ですがコツコツ作ってみました。まだ動くレベルにまではいっていませんが、ひとまず感想を書いておきます(今年のJJUGでアウトプット大事って言ってたし)。

まず、私は普段Javaしか使いません。たまにWebアプリに配属されて、ちょっとフロントエンド周りを触って(元々Webデザイナーなので、HTMLとCSSjQueryとかなら爆速で書ける)プロジェクトを離脱、なんてことはありましたが、基本的にはJavaでずっと書いています。

Java好きなのでJavaで問題ないんですけど、AngularとかReactとかカッコイイ言葉使ってみたいじゃん?という不純な動機でフロントエンド系のいろいろなものに手を出してみよう、という勝手な企画です。

今回手を出してみたのが下記です。

Materialize.css

materializecss.com

bootstrapは昔これでもか!というくらい使ったので、今回はちょっと話題になってたMaterializeを使ってCSS書きました。とりあえずbootstrapより使える色の数が多い感じ。あと、各コンポーネントがいちいちオシャレ。しかし、若干bootstrapよりやれることが少ない(独自実装が必要)な気がする。ポップアップでYes/No選べるやつ(名前がわからない)とか、多分自分で作らなきゃいけないような…

Vue.js

jp.vuejs.org

AngularかReactかVueかで迷って、結局Vueにしました。サイトのデザインが好きだったから、というのが選んだ理由です。でも、ReactかVueかで比較すると、速さの点で少しVueの方が勝るみたいです。それ以外の違いはあまりないかもしれません。Angularとそれ以外というくくりなのかなと理解しました。

昔のプロジェクトで使い慣れたknockoutとVueの実装を比較したページもあって、こちらでもVueの良さが伝わるかなと思います。まあべつに使いやすいやつを使ったらいいと思います。

個人的には、.vueファイルにコンポーネントの処理を記述して、.jsにビジネスロジックとかを記述する感じが好きですね。ほかのjsライブラリを知らない(knockoutとかdurandalとかしか知らない…)ので、他のやつにあったらごめんなさい。

Spring Boot

https://projects.spring.io/spring-boot/

Javaフレームワークです。最近だと、とりあえずこれ使いますか、という感じになります。セキュリティ周りまで充実してますしね。私も、以前使って使い慣れているので今回もこれを使いました。

Vue.jsを使おうとしたらインストールの必要が出てきたツールたち

しかし、これだけでは済みませんでした。思った以上にフロントエンド界隈って複雑でした。1つにならないんですか?と思うんですが、よく考えたらJavaも別に1つになっていたわけではありませんでした。とりあえず、フロント界隈に初めて触れる方向けに、覚えておいたらいい用語をメモします。

npm

Node Packaged Modules(npm)のことです。npmをJavaで言うと、Mavenですね。ライブラリの管理をやってくれるものです。npm install XXXと打つだけで、jsのライブラリを勝手に該当のディレクトリに入れてくれます。便利なので、これを使ってjsライブラリの管理をするととても楽です。

実装の際には、package.jsonなるファイル(Javaでいうと、Mavenのpom.xmlとかbuild.gradleとは)に依存関係とかを書き込んでおいて、あとは適当なビルドツール(後述)を用いてビルドすれば完成。JavaScriptにビルドの機能がついたなんて、jQueryで遊ぶ程度だった私は知りませんでした…。

browserify

http://browserify.org/

あまりよくわかっていないのですが、require('vue')とかすると、vue.jsを読み込める、みたいな機能を持たせるものらしいです。npmで取り込んだjsを呼び出して使えるものらしい。(知らず知らずのうちにrequire('hoge')してた)。

私の理解としては次のとおりです。jsには長いことJavaで言うところのimport文がなく、お互いの依存関係は一旦HTMLにscriptファイルを書いて記述する必要がありました。そこで、そんなめんどくさいことをする必要がないように、js同士で依存関係を解決できるようにしたのがこの「require」文なのでしょう。便利ですね。

gulp

http://gulpjs.com/

ビルドツール。他に、gruntとかいうのもあるらしいです。よくわからずとりあえず参考したチュートリアルがgulpを使っていたのでgulpを使いました。どこがいい、とかそういう話はできません。ただ、Node.jsのAPIを使ってビルドするみたいなので、先述したnpmと相性がいいとかあるのかもしれません。

Babel

babeljs.io

jsにもいろいろあるらしくて、これはそのうちの「ES6」なる構文で.jsファイル内では書いて、コンパイルするとどんなブラウザでも認識できる古いjsの構文に直してくれる、というツールです。

ところでES6なのですが、

  • クラスが使える
  • スコープがまともなletとか、定数constが使える
  • Arrow関数(Java8で言うと.forEach(v -> {})の「->」)を使える

等々、あんなにわかりづらかったjsがめちゃめちゃわかりやすく書けるじゃん!という強者です。もうみんなこっちで書けばいいのにっていうレベル…

クラスをクラスとして扱えるのと、extendsを使って継承できるなど、Javaしか触ったことのない私でも「あ、なんとかなりそうだ」という気分にさせてくれました。実際、なんとかなりました。

ただ、1つ問題があって、babel等でbuild.jsなるファイルに吐き出したjs、どうがんばってもデバッグできなそうなんですけどフロントの皆さんはどうやってるんですかね?ちょっと調べてみたんですが、Chromeの検証ツールはあんまり役に立たないみたいですし…デバッグは死活問題ですし必ず誰かが解決していると思うのでもう少し調べてみよう…

エディタ

Java側はIntelliJ、フロントサイドは全部Atom、みたいな使い方をしています。IntelliJは安定といえば安定なんですけど、コマーシャル版だとjs側の補完が全然効かなくてわりと不便です。また、Atomだとlanguage-vueというパッケージがあって、これをインストールすると.vueファイルでも補完が効くようになるので、その点でもAtomを選びました。参考までにどうぞ。

ひとまずフロントエンドの皆様が使っていそうなツールを一通り使って、これから三が日で簡単なWebアプリでも作ってみようかなと思っています。githubはもうちょっとできてからコミットします。

ヒトラーが現代に蘇った場合、彼の猛進を防ぐ手段はあるのか?―ティムール・ヴェルメシュ『帰ってきたヒトラー』

『帰ってきたヒトラー』を読みました。ヒトラーを扱うブラックユーモア小説として、ドイツ国内では大ヒットした作品。ドイツに限らず、アメリカや、なんと…イスラエルでも出版されたそうです。映画化もされており、映画も時間を見つけて見てみたいと思います*1

ヒトラーが浦島太郎のように現代に蘇り、ユーチューブなどを通じてモノマネ芸人(コメディアン?)として人々の認知を集め、その後政治家を志していくというストーリー。ヒトラーは当然「インターネット(本人は"インターネッツ"と呼ぶ)」を知らず、YouTubeにもWebサイトにも興味津々で、扱うのに苦労します。そこが笑えるところなのですが、後半になるにつれ、ヒトラーの「人を惹きつける」ところが強調されていきます。そして、そこが怖いところでもあるのですが…

ヒトラーは再び当選してしまうのか?

私はこの作品を読んで、まず気になったのが「ヒトラーは政治家に再び当選してしまうのか?」という点です。そして、現代においてはこれは確実に「YES」だと思います。

ヒトラーが政治番組に出たり、さまざまな人と話をするシーンがあるのですが、ヒトラーにはどうやら人を惹きつける力があったようです。当然といえば当然です。あの時代のドイツであれだけの支持を集めてしまったのですから、人を惹きつける力は半端ではないです。また、人の心を読むのも上手だったことが描写されています。これもまた、政治家には必要な資質でしょう。

当然のことながら、ヒトラーはこのあと人々の支持を集め、当選してしまったと思います。原作には描かれていませんでしたが、「このままいくとうまくいっちゃうよね」ということを作者は暗に示しているなあと感じました。

一方で、では「ヒトラーを再び当選させないためにはどうしたらよいのだろうか?」という問いに対して、現代においては打つ手だてがないかもしれないと考えました。結局こういう人たちは、言論の自由に守られて何を言うのも自由です。そして、賛否両論を巻き起こし、最終的には賛同者を集めて当選してしまうことでしょう。そして、それは簡単です。政治は過半数の支持を得られればよいからです。51:49でも、50.5:49.5でも、過半数であればそれは成功なのです。

極論を言うと、この作品のように独裁者が復活した場合、現代において打つ手だては、彼らの言論の自由を無視し、独裁者を逮捕して自由を拘束することしかないのではないでしょうか。危険思想のように思われるかもしれませんが、現実的な手だてはそれしかないように思います。

そしてそれこそが現代の民主主義の矛盾であり、個人の自由と社会全体の利益を天秤ではからなければならない政治制度の限界を示しています。個人の自由を最大限保障すると、ときにヒトラーのように社会全体にとって不利益をもたらす存在を止められないかもしれないです。個人の自由と社会全体の幸福のどちらを選択すべきか、という問題は、マイケル・サンデル教授も熱心に著作で論じている政治哲学でも重要なテーマです。もっとも、社会全体の利益が何(だった)かなんて、未来から過去を振り返ることでしかわからないとは思うのですが。

何より、現にこの作品で起きていたような「賛否両論を巻き起こすヤバメの人」が当選してしまった例はすでにありますよね。トランプの当選です。最近は賛否両論を巻き起こせるような人が当選する傾向にあるように思います。そこまで予測して作者が書いていたかはわかりませんが、この本が描くような世界に今なりつつあるのは間違いないのではないでしょうか。

これからの「正義」の話をしよう (ハヤカワ・ノンフィクション文庫)

これからの「正義」の話をしよう (ハヤカワ・ノンフィクション文庫)

「過去との新しい対話」が求められている

本書の最後にニューヨーク・タイムズによる、著者インタビューを含む書評が載っていて、そこに気になる記載があったので紹介しておきます。作者自身の意図としては、「過去との新しい対話」を目指したとのことです。

ドイツ国内では、ヒトラーの過去をどうしても二度と振り返りたくない記憶として取り扱うことが多いようです。しかし、そうやってヒトラーの政治から目をそらしていては、たとえばヒトラーの人を惹きつける力があった、というような重大な事実を見逃してしまいがちになります。だから、「ユーモア」「風刺」を用いて先入観なしにヒトラーを記述することで、読者の目ををヒトラーその人に向かせよう、という意図があったように見受けられます。そして、それこそが過去との新しい対話という言葉に現れています。

翻って日本はどうでしょうか。日本もドイツと同じように、戦争の記憶が刻み込まれた国のひとつです。日本の場合は、過去の戦争を「感動モノ」として描くことが多いように思います。たとえば『火垂るの墓』『永遠の0』などはその代表例でしょう。しかしこの態度は、戦争の現実と向き合っていると言えるでしょうか。私は疑問に思います。現実から目をそむけているだけではないかと。

本書の「ヒトラー自身の人となりを描く」という「過去との新しい対話」は成功しているように思います。結局ドイツの場合は、ヒトラーその人自身が圧倒的に大きな発生源だったからです。だから、ヒトラーその人に着目した作品がこうして出てきたことで、人々はヒトラーという人間と向き合うことになり、結果としてそういう人を警戒するようになるかもしれないです。

日本にも、そうした「感動モノ」をやらない、過去との新しい対話を目指す戦時小説が出てくるといいなと思いました。正直ちょっと、戦争モノが感動ばかりを扱うのに疲れてしまったんですよね。戦時中のリアルな人間関係とか、結局何人亡くなったとか、そういうのを総合的に描いてくれている作品があったらぜひ見てみたい(漠然)。今のところ、半藤一利『昭和史』を上回る、戦争についてまともに書いた本を読んだことがない気がします。まして、小説に至っては…

ただ一方で、「風刺」を使うことの是非は問うべきかとも思いました。風刺だからタブーに踏み込みやすい、というのはあるかもしれませんが、風刺は本当にタブーと向き合う手段として妥当なのか?風刺だからなんでもいいのか?については疑問です。この点については今後考えてみよう。

本書を読んでいてよくわからなかったこと

  • 最後の方で、ヒトラーがネオナチの人間にリンチされるシーンがあるのですが、なぜネオナチの人たちはヒトラーをリンチしたのでしょうか?本来は仲間のはずでは…?

帰ってきたヒトラー 上 (河出文庫 ウ 7-1)

帰ってきたヒトラー 上 (河出文庫 ウ 7-1)

帰ってきたヒトラー 下 (河出文庫)

帰ってきたヒトラー 下 (河出文庫)

*1:今はじめて予告編を見たのですが、原作で示唆されていなかったストーリーまで描かれているようですね。これは見てみたい!

トンチンカンな質問をされるのは、自分自身に原因があるのかも?―木村亮示・木山聡『BCGの特訓』

今年に入ってから買って、3回くらい読み返した本です。本日3回目読み返しましたが、そういえば書評をまともに書いたことがないと思い書きます。

最近悩んでいることがあります。ひとつは自分自身の成長について。そしてもうひとつは、新人の育成です。あ、新人のみならず配属された技術派遣の人の教育も含みます。今日は、新人の育成の上で困った「トンチンカンな質問問題」を、ご紹介する本を参考に少し考えてみます*1

質問の質が低すぎる!

新人(技術派遣)の育成についての悩みは、「質問の質が低すぎる」ということです。具体的には、「具体的な質問をしてこない」という悩みです。とくに40歳をゆうにこえた派遣の人でさえ、質問の質がとても低く、正直辟易する毎日でした。

「具体的な質問をしてこない」というのはどういうことかというと、2つあります。「仮説をまったく挟まない質問」です。要するに「どうすればいいですか?」みたいな質問をしてくるケースです。もうひとつは、「事実だけを説明して私に何を聞きたいのかよくわからない質問」です。「プログラムがこうこうこうなっています」という質問(雑談?)に来て、私としては「で?」となってしまうのです。正直とても困っていて、直してほしいんですが、40こえたおじさんに「質問のしかたを直してください」と伝えるのは、本人のプライドも傷つけちゃうしよくないことだな〜と思っていたんですね。

どちらにも共通していることは、「答えを他者に求めている」ということです。責任を負いたくないのか、はたまたただ思考停止しているのかどちらかはわかりませんが、いずれにせよ自分で答えを出す気がないのだな…と感じてしまいます。そして、こういう人はそもそもマインドセットから甘いので、マインドセットから直していかないといけないんですね。

じゃあマインドセットを40歳こえたおじさんに教えますか?というと大変失礼な気もしてしまうわけです。そこでいい方法はないかなと思ったとき、「私がちゃんと聞き返す」ということが必要なんだなと本書を読んで思いました。結構できていないかも。答えを与えちゃってるかも。私が頭をウンウン悩ませて、結論を出して伝えてその通りに作業をしてもらう、みたいな流れになってしまっているかも。そう思いました。

具体的にではどのように聞き返していくか?どうすればお互いにとっていい質問タイムとなるか?それは、私自身と相手の理解度を確かめ合うということを目標とし、「よりよい聞き返し」を繰り返すことなのではないでしょうか。たとえば、「今どこまでわかっていて、どこでバグが発生していると思いますか?」「そのオペレーションをすると、このメソッドや変数に何が入っていて、その結果として何が返ってきていますか?」「投げられている例外はどういうもので、どういう想定が考えられますか?」などと聞き返していくことです。

この方法のいいところは、質問した側の気づきを促すところです。多くの普通の人は、わからない事象が湧いてきて、頭で考えてもわからなくて、わけがわからなくなってきてその状態でリーダーに質問に来ます。そしてその「わからないこと」を整理してあげるのは、リーダーのひとつの仕事なのではないでしょうか。その質問の繰り返しによってメンバーは気づきを得て帰っていってくれたら、もしかして自分で解決してくれるかもしれません。

ただ一方で、これには質問される側に高度な「問いを立てる技術」が求められます。なぜなら、適切に問いを立ててメンバーに投げかけるようにしなければ、思考の整理のために来たはずなのに、余計に混乱して帰ることになるからです。正直、問いをわざわざ立てるのはとても面倒くさいです。問いを立てる行為はとてもめんどくさい行為なので、多くのマネージャはそれをせずに怒って突き返すか、冷たく返すか、あるいは一緒に答えを出してしまいます。

しかし、それではメンバーは成長しないです。そして、また同様のトンチンカンな質問をする→こちらのイライラがたまる…の連鎖が起きてしまいます。その連鎖を解決するために、あえて答えを渡さないで質問を繰り返すことは重要なのではないでしょうか。本人に考えさせ、どういう問いを立てるとマネージャーがいい答えを返してくれるかを禅問答方式で伝えるのが一番いい方法かと思います。

そしてなにより、40歳をこえたおじさんにマインドセットを教え直さなくていいのが楽でいいですね。

仕事の任せ方が悪い?

一方で私自身の仕事の任せ方が悪い説もあります。本書を読んでだいぶ反省したのですが、仕事の任せ方にはいくつか方法があるようです。

まず前提として、個々人のスキルレベルは当然把握する必要があります。ただ、私の仕事は業務ロジックも計算ロジックも複雑怪奇で、外資系の金融機関でバリバリFEやってました、というレベルの人でない限り、新人も40歳を超えたおじさんも大差ない、みたいな仕事なので、スキルレベルはほぼ一概にあまり高くないと想定するのが無難だなと思っていました。

ただ、個人の思考力を測る方法はあって、それが先程あげた「質問の仕方を観察すること」と、「聞き返しの結果、どのような答えが返ってくるかを観察すること」かなあと思っています。両方とも、その人の思考回路をたどることができるので、仕事を任せる際にはその人が迷わないようにどう任せたらよいかを判断できます。

仕事の任せ方としては、たとえば、「こういうふうに考えられるけど、それが正しいか調査してもらえますか?」という仕事の任せ方と、「この手順で作業をしてくだしさい。いじるクラスはここで」みたいな任せ方を使い分けるとよりよいです。また、よほどできる人には、「じゃあ、このチケットお願い」程度で十分です。

明日から使い分けをしてみよう、と思いました。

質問の仕方が悪いのも、原因は自分にあるのを忘れないようにしよう

勢いで書いてここまで来てしまいましたが、最後に重要なことをひとつ書き留めておきます。それは、周りの質問の仕方が悪いのは自分自身に原因があるかもしれないということです。原因自分論です。

とくに、自分自身の仕事の任せ方が悪いのかもしれない、ということは改めて確認すべきことだなと思います。丸投げ可能なぐらいにその現場での経験があるような人に丸投げは可能ですが、まだ配属されたばかりの人に丸投げをしても頭の中には「???」しか浮かびません。

一方で、容易に答えを与えるようなことはしてはいけないです。あくまで、問答を繰り返して相手に自分で考える習慣をつけさせるしかないです。最初のうちは時間もかかるし、自分が答えを与えれば5分で済む話が1時間かかることだってあるかもしれません。が、そこはむしろその時間も込でスケジュールを先読みして、タスクを長めに任せるマネジメント側の努力が必要です。

明日からの仕事の任せ方と質問への接し方を少し変えてみようかなと思ったいい機会でした。もっとも、「仮説を立ててから質問する」「考えるとはどういうことか?」くらいの話は大学やあるいは研修などで教えておいて欲しい、基本的なことなんですけど。

BCGの特訓 ―成長し続ける人材を生む徒弟制

BCGの特訓 ―成長し続ける人材を生む徒弟制

*1:私はまだ社会人2年目で、まだまだひよっこなのです。しかし、それなりにメンバーを抱えるプロジェクトを任されていて、年齢層も幅広いみたいな状態です。

スピノザ―ジル・ドゥルーズ『スピノザ』

ジル・ドゥルーズスピノザ』を読みました(やっと)。この本はガタリと共著した『千のプラトー』が出た翌年に出版されたもので、ドゥルーズのどちらかというと中〜後半の思想を代表している本のひとつだといえます。

ドゥルーズは、他にも『スピノザと表現の問題』という本を書いています。こちらはどちらかというと専門家向けの一冊に仕上がっていますが、『スピノザ』は一般の、これからスピノザを始める人向けかなあという印象を持ちます。それくらい、わかりやすくて読みやすいです。

ちなみに『スピノザと表現の問題』は今読んでいる最中ですが、なかなか止まってます(笑)。

スピノザの思想について

スピノザ自身の思想について少し復習をしておきましょう。スピノザの思想は端的に言って、デカルトの思想を知らないと理解できません。そしてざっくりスピノザを捉えるには、デカルト「でない」方向に向かった、と考えるとひとまずは読みやすいかと思います(デカルトの思想の紹介をすると文字数が大変なことになるので端折ります)。

スピノザの思想ははっきり言って難しいです。私がスピノザを読んでいてよくわからないのが、スピノザが文中でしきりに「神」と書くものが、果たしてキリスト教的な意味での「神」なのか、それとも神即自然という意味での「自然」一般を指すものなのか、はたまたプラトンが想定した「イデア」みたいなものなのか、イマイチつかめないからです。そして、スピノザ本人も『エチカ』の中で、神がどういうものなのかを具体的に書いてくれてはいないからです。

しかし、もしかするとこの疑問は野暮なものなのかもしれません。当時、哲学は神抜きでは考えられませんでした。ここでいう神とは、キリスト教の教義にある神です。聖書で言うところの主です。スピノザが正統派キリスト教が嫌いだったとかそういう話はおいておいて、ひとまず当時の人々が何かしらの形で信仰していた「神」のことを指していて、そしてあまりにそれが当たり前すぎたから、あえて書いていないのかと思います。

そして、創世記(1-1〜1-29くらい?)などを読むとわかるように、神が結局自然(というかこの世)をお作りになったのです。つまり、神=自然なのです。なぜなら、神が諸原因の根源であり、その原因から生じた結果である「自然」はすべて神という属性を帯びるからです。この考えを受け入れると、スピノザの思想が少し視界の開けたものになるかもしれません。

ところで、このように神とその他のものという従来の序列関係から、神とその他のものが同様の優先度である(逆に言うと、この2つの間に序列関係はない)というスタンスを取ると何が起きるか、が重要です。スピノザの思想の画期的なところはここにあります。

哲学史において偉大な思想家であると言われる人たちは、かならずこの解体作業を行っています。スピノザデカルトの思想内の各所に見られるこの序列関係をいったん解体してみました。すると、まったくデカルトとは異なった世界観が誕生しました。

もっとも重要なのは、道徳的な意味での善悪の解体でしょう。神=自然法則な世界において、道徳的な意味での善悪という概念は残らないからです。物事の正しさを決める尺度を判定する裁判官が世の中から消えてしまうからです。そこには、ある存在が「ただ在る」状態だけが残ります。

かくて、〈エチカ〉〔生態の倫理〕が、〈モラル〉〔道徳〕にとって代わる

よく人は、「・・・するべきだ」という考えのもとに物事を判断しようとしてしまいます。自分が他者の裁判官になっているのです。だから、世の中には諍いが耐えないし、イライラが止まらなくなるのです。しかし、その諍いやイライラの原因が道徳的な善悪から生じており、その根拠がまったくどこにもないことを認識すれば、他者のことを受け入れることができるようになります。そうして肯定的に物事を捉えることで、他者と自分の差異を冷静に受け止められるようになります。

これが、ドゥルーズ自身の差異の哲学ととてもマッチしたようで、ドゥルーズはその点でスピノザに肯定的な評価を下しています。

ドゥルーズ自身の考えるスピノザについて

ドゥルーズ自身がスピノザをどう評価しているかについては、むしろ『スピノザと表現の問題』の方が詳しく書いてあります。ドゥルーズスピノザの哲学を「純粋肯定の哲学」と評しています。

「肯定の哲学」という言葉をドゥルーズの観点から読むなら、それは「生きる力の肯定」ということになるでしょう。では、生きる力の肯定とは何か?これは結構漠然とした難しい問いですが、私は「反応すること」にあるのではないかと思います。そして、「反応する」ためには、あらゆる物事に「気づく」必要があって、その気づきを得るためには、周りの存在を肯定する必要があるのではないか、そう思います。

というのもの、人は肯定されたものしか認識できないからです。肯定とはそれを必要なものであると見なすことです。私たちはそこまで記憶力がいいわけでも、エネルギー効率がいいわけでもありません。したがって、不必要なものは無視してしまう癖があります。肯定する幅が小さくなると何が起きるか。答えは明白で、視野が狭くなります。

視野が広いほうが、よりリアクションを起こしやすくなります。関心事を広げようということです。それがそのまま、他者の存在を肯定することにつながります。他者への何かしらのリアクションを起こすことが、他者の存在の肯定にそのままつながります。こうして、より人の生きる領域が広がって行き、結果としてより〈いい〉状態に向かっていくことでしょう。

今回読んでみて、スピノザの「力能」という言葉の理解が甘いなという結論に至りました。ドゥルーズは当然、ニーチェとの関係性の中でスピノザの「力能」を捉えています。なので、今度はニーチェも少し掘り下げて読んでみようかと思いました。

スピノザ―実践の哲学 (平凡社ライブラリー (440))

スピノザ―実践の哲学 (平凡社ライブラリー (440))

ゼロから理解する機械学習―斎藤康毅『ゼロから作るDeep Learning』

機械学習の勉強の最初の本として買いました。ちなみに私はど文系の政治哲学出身なので、数学はサッパリです。大学の教養の授業で、理系の学部2年目までに習う線形代数微分積分を取ったくらい。ただ、仕事で数学を使うことになったのでそれから勉強して、かろうじて確率過程がわかるくらいという数学力です。

そんなど文系でも、結構わかりやすかった。とりあえず、ReLU関数なるものはコール・オプションだし、ブラック・ショールズとおんなじかんじか〜、機械学習って究極CAPMと同じかもね、なんていうふうに、金融工学の話と強引に結びつけてなんとか理解しました。まだ使えるレベルじゃないけど、おおよそ機械学習なるものが何をやってるかはよくわかりました。

実装が豊富に載っているのも良い点ですね。数学がわからなくても、コードを読んだら理解できたところは結構あったと思います。

本書にひとつ付け加えるとしたら、計算の概観みたいな図がほしかったかなというところですね。途中まで、パーセプトロンとかが何を目標にして使われているのかつかめなかったので・・・本の最初に、そういう計算見取り図的なものがあると嬉しかったかな、と思いました。

JJUGのLT会に行ってきた

JJUGのLT会に行ってきました。いつも薄い感想を抱いてこういうセミナーって終わっちゃうので、せっかくの機会なので感想をしっかり書いてみようと思います。ただし、書く気力が続いたら(現在、AM2:42)。

ピザとビールを片手にみなさんの発表を聞く会でした。ほんっっとどうでもいいですけど、カマンベールチーズが入ったピザが超おいしくて、また食べたいな〜なんて思いながら(そのピザの名前がわからない)書いてます。

freemakerの人(って私のメモには書いてある)

[Slide Shareとかに上がってませんでした]

timeleafと同系列で、freemakerなるものがJavaにはあるらしい。timeleafは知ってたけど、freemakerは知らなかった。Webデザイナーをしていた自分としては、React.jsとかと比較したときに、freemakerを始めとするJava系のテンプレートエンジンを使うメリットがよくわかりませんでした。どなたか詳しい方教えてください…

この前Webアプリの開発をしたのですが、そのときはSpring Bootとdurandal.jsを使ってやりました。durandal.jsにはknockout.jsも入っていて、HTMLを非常に綺麗に書けるのでとてもおすすめです。後継のAureria.jsが今後は主流になるみたいですけど…

JDBCでつながるSaasの世界

「ざっくりまとめると、CData JDBC Driversの宣伝」と私のメモには書いてあります。多分そうだったかと思います。SQLからTwitter API経由でツイートできちゃうんですね。ちょっと遊んでみたいな〜と思いました。

Javaとメールで遊んでみた話

私は金融業界の人なので、Javaでメールを送るという業務要求がありません。まず、Javaでメールを送れるということを知りませんでした(笑)。これ、便利ですね。ちょうど、社内で毎回同じような文面で送るメールを自動化したいな〜なんて思って、入力項目をコンソールで入力すると自動で文章を補完してくれる、みたいなプログラムを勝手に作って遊んでました。メールを送るところまで自動化できると、よりできることの幅が広がりますね。

Microsoft Cognitive Serviceと組み合わせて、メールの文面から感情を読み取る一連の作業をやってくれるデモもやってました。ただ、Text Analyticsとか諸々が結構Javaに対応してなくて、悲しい思いをする…というあるあるな話に妙に共感しました。最近はPythonばっかりですしね。なんでなんでしょう?

ArrayListをじっくり読んでみた

LTの中で一番おもしろかったです。ArrayListSDKを真面目に読んでみた結果、発見できたことをシェアします、という話でした。ArrayListって普段よく使うんですけど、実際の実装ってほーとんど見たことないですよね。

ArrayListの実装ってめちゃくちゃ省エネしてるらしくて、たとえばインスタンス変数をローカル変数に置き換えて、後続の処理ではすべてローカル変数を使うようにして省エネしたり、値と参照と代入を同時に実行して省エネしたりと、数々の省エネ対策を行っているようです。また読んでみよ、と思いました。

JDIの話

これもArrayListの話と同じくらい興味深かったです。まず私の勉強不足だったのですが、JDI (Java Debug Interface) なるものがあるということを初めて知りました。これ、Eclipseとかのデバッグを起動すると実行されるやつみたいです。へー。

たとえば、JDIを使うとこんなコードが書けるらしい。Javaを実行すると数秒後に落ちて終わる、みたいなもの。

public class Main {

    public static void main(String... args) {
        Runtime.getRuntime().addShutdownHook(new Thread(() ->
            System.out.println("shut down hook")
        ));

        System.out.println("processed");
    }
}

これを実行すると、ランタイムを落とすことができます…云々、です。デバッガって普段何でできてるかを意識することはほぼないと思うのですが、JDIを見るとデバッガってこういうものでできてるんだ、ふーん!という気持ちになれるので、ちょっと読んでみることをおすすめします。

synchronizedの怖い話

あるあるすぎてまじ!!!!と叫びたい気持ちになりました。64コアとかの巨大CPUでsynchronizedすると、とにかく重い!しぬ!という話でした。Java の HashTable とかは、synchronized を使っちゃってるので気をつけましょう。ConcurrentHashMap とかを使うようにしましょう。

ちなみに、 Properties は HashTable を継承してしまっているので注意だそうです。知らなかった。