« 2018年3月11日 - 2018年3月17日 | トップページ | 2018年3月25日 - 2018年3月31日 »

完璧な悪夢『夜のみだらな鳥』

 これは凄い。
 これは凄い。
 これは凄い。

 どろり濃厚ゲル状の夢に、呑まれ、溺れ、とり憑かれる体験。息詰まるような読書、いや毒書である。7年前の初読時、この毒に中った。極彩色の悪夢を直視する経験は、[劇薬小説『夜のみだらな鳥』]に書いた。以後、中毒状態だったのだが、本書は長いあいだ絶版状態となっていた(Amazonで平気で諭吉してた)。

 それが、水声社から復刊された!

 これは事件といってもいい。誰でも手に入る状態で、日本中にこの悪夢が解放されているのだから。これでいつでも、完璧な悪夢を見ることができる。なぜか? それは、常識を超えた毒書になるから。

Donoso

 物語の体をした小説は、語り手によって伝えられ、読み手によって受け止められる。一人または複数の語り手は、ふつう「出来事そのもの」や「因果の果」に相当するところから話を始める。語り手は騙り手でもあるから、読み手は騙されないよう気をつけつつ、「なぜそれが起きたのか?」を探りながら進める(オプションで、「語り手は誰なのか?」も心の隅に留めながら)。

 事実であれ小説であれ、物語は世界を理解するための方便なのだから、読み手は、原因と結果がつながっていることを暗黙のお約束とする。また、語り手は、たとえどんなに異形であったとしても、「語るべきもの」を伝える役目として、一つの存在であることが前提だ。さらに読み手はまさに、この本を読んでいる”わたし”であることは、言うまでもない。

 これが、ぜんぶ壊れる。一度にすべてが起きるのだ。原因と結果、語り手と読み手が混ざり合い喰い合う。語られているモノと、語っているモノが、重なりあう。何を言っているのか分からないと思うが、わたしも、何をされたのか分からない。

 しかも、語り手が頻繁に変わる。見捨てられた修道院で、ずっと主人公(ムディート)が語り手として回想しているのかと思いきや、いつのまにか「語られている相手」が語り手としてしゃべっている。「語られている相手」は、彼が恋焦がれる女だったり、彼を支配する大富豪だったり、その大富豪の畸形の子だったり、彼を犯そうと追いかける老婆だったり、その土地に古くから伝わる神話そのものだったり。誰かの悪夢を盗み見ているようで、同時に窃視しているわたし自身が覗かれているような気になる。

 その入れ替わりは、彼に憑依する形ではない。人格が崩壊した主人公の戯言として読んでしまえば簡単なのだが、描写がそうはさせない。客観描写を衒った神視点や、ドストエフスキーばりの連続会話、ジョイスやウルフの意識の流れに乗って読んでいくうちに、彼の語りを聞く「わたし」が知覚する世界が変転する描写で、シームレスに成り代わる。

 アインシュタインは、時間が存在する理由と、「一度にすべてのことが同時に起こらないため」と言ったが、わたしはその場所を一つだけ知っている。それは、わたしが見る悪夢だ。夢の中では、すべてのことが一度に起きる。まだ始まっていないのに、何が起きるのか、そして「なぜ」それが起きたのかを、わたしは知っている。と同時に、起きていないのに起きたことが経験済みとして扱われる。

 『夜のみだらな鳥』を読むことで、まさにこれが起きる。本書が完璧な悪夢である理由はこれ。

 物語に「ストーリー」すなわち予定調和や業(ごう)・因果を求める人がいる(というか、そんな人が小説を読む大半である)。そんな人向けの「ストーリー」を述べるなら、畸形の息子のために畸形の楽園を築こうとした大富豪の話が適切だろう。

 広大な敷地を買取り、世間から隔絶し、美しい豪邸と庭園、それを取り囲む村落という「世界」を丸ごとつくりだす。そこに、額に隻眼を持つ医師、身体は巨大なのに半分しかない女、侏儒、異形の者たちを高給で雇い、生まれたばかりの畸形の息子の周りに侍らせる。そこでは、五体満足の人間は逆に「異常」とされ、不具扱いされる。この、社会から隔離された世界のマネジメントを任されたのが、この物語の語り手である主人公のウンベルト・ペニャローサになる。

 ん? 先ほど主人公は「ムディート」と言ったじゃないか、というツッコミ上等そのとおり。途中から断りなく、ムディートとウンベルト・ペニャローサが重なり合う。呼び名の違いと済ませたいが、それぞれの過去が微妙にズレる。同じ名なのに別人物のように振る舞い、別名なのに同一人物のように扱われるのがザラで、そのうち両方を受け入れるようになる。

 しかも、ムディートが語る場所である半迷宮と化した修道院と、ウンベルト・ペニャローサが語る場所である畸形の楽園と化した豪邸が重なり合う。同じ過去と語るモチーフ、重なり合う人称「おれ」を用いることで、両者と両所は多重露光のように映し出される。

 さらに、この楽園に住まう畸形の息子「ボーイ」も、この露光に重なってくる。すなわち、ムディート=ウンベルト・ペニャローサ=ボーイの構造として「おれ」が語るのだ。しかも、場所のみならず、ムディートの回想(の中のウンベルト・ペニャローサの過去(の中のボーイの知見・対話)をボーイが否定した事実)を元にして、ムディートの現実が上書きされる。つまり、語り/語られの時間軸すら逆転したり捻じれている。

 読み手は、語り手がしゃべっているモノは何であるのか分からなくなり、小説内時間軸のどの時点の語りなのか見失い、そして、しゃべっている語り手が誰なのか、そもそも、語り手は誰にたいしてしゃべっているのかすら分からなくなる(語り手は唐突に「あなた」を言い出すが、それは読んでる「わたし」ではない)。

 起きていることと、その理由と、それを語るものと、語られるもの、それを聞く存在、これらすべてが、いちどきに発生し、知覚される。おぞましい存在から、うつくしい存在が生まれる。その時間のかかるシークエンスを、瞬間に感じることができる。善悪と美醜の混濁を、支離滅裂と片付けるにはもったいない、きちんと呑まれて、極上の、完璧な悪夢を堪能すべし。

 ただし、水声社のポリシー(?)により、ウェブストアは卸さないので気をつけて。大型書店で探すか注文取り寄せで入手して欲しい。Amazonで、またしてもセドリ屋が高い値で売ろうとしているが、相手にしてはいけない。


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

オフ会やろうぜ、4/14「サクラのスゴ本オフ」、5/27「B&Bでブックハンティング」

 ふたつオフ会を企画したので、タイミングと興味が合えばどうぞ。

 一つ目は、スゴ本オフ。「さくら」をテーマにした本、映像、音楽、ゲームなんでもOKなので、あなたのオススメを熱く語ってくださいませ。4/14(土)13:00~渋谷にて。参加費2千円、軽食・飲み物が出ます。子連れ・途中参加・退場・見学歓迎。「さくら」のスゴ本オフからどうぞ。

  1. テーマに沿ったオススメ作品を持ってくる オススメ作品は、本(物理でも電子でも)、映像(DVDの映画やYoutubeの動画)、音楽、ゲーム、なんでもあり。
  2. お薦めを1人5分くらいでプレゼンする あなたのオススメを存分に語ってほしい。刺さったところを音読するもよし、自己流の解釈もよし。
  3. 質問とオススメ返しの時間 あなたのオススメに対し、観客から質問やオススメ返しされる。「実は私も好きなんです!」と同志を見つけたり、「それが好きならコレなんていかが?」なんてオススメ返しされたり。このリアルタイム性がスゴ本オフの嬉しいところ。
  4. 放流できない作品は回収する ひととおりプレゼンが終わったら、回収タイムになる。「放流」とは本の交換会のことで、交換できない絶版本・貴重な作品は、ここで持ち主の手元に戻る。
  5. 交換会という名のジャンケン争奪戦へ 回収が終わったら、作品の交換会になる。ブックシャッフルともいう。「これが欲しい!」と名乗りをあげて、ライバルがいたらジャンケンで決める。

スゴ本オフ「お金」

02

スゴ本オフ「嘘」

02

 二つ目は、ブックハンティング。ビールやコーヒーを飲みながら、本屋でオフ会しましょう。B&Bで見つけたあなたのイチオシや、「これが読みたくなった!」という作品を熱く語ってください。5/27(日)10:00~12:00 下北沢B&Bにてやります。参加費は無料ですが、ワンドリンクをオーダーしてくださいね。B&Bでブックハンティングからどうぞ。

10:00-10:30 受付
  参加者は、1ドリンク注文し、紹介文のカードを受け取る

10:30-11:15 探索
  参加者は、店内でオススメの本を探索する
  参加者は、オススメの本の紹介文をカードに書く

11:15-12:00 発表
  オススメ本とカードを机に並べる(写真を撮ります)
  参加者は、3分ぐらいでオススメ本を紹介する
  「読みたい!」と思った参加者は、その場で購入する

12:00~ 解散
 B&Bは開店
 参加者はそのまま「お客」として物色するもよし

 本屋でオフ会するのは、とってもデンジャラスと言える。わたしの経験上、「気付いたら諭吉が消えてた」なんてザラ。なので、もっとも危険な読書会になるだろう。お財布を充分に温めていらしてください。

B&Bでオフ会

01

渋い選書。開いているのは内田百閒『東京日記』
03

 まっ昼間からビール飲んで好きな本について語るなんて、至福そのもの。あなたの「好き」を教えて欲しい。わたしが知らないスゴ本は、きっとあなたが読んでいるのだから。

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

「やりたいこと」を要件定義にする3冊

 システム開発でモメることは多々あるが、その本質は「やりたいこと」が分かっていないに尽きる。

 「やりたいこと」が分かっている場合、リソースが足りないとか突発的な事象が起きたといったトラブルがあっても、まだ何すればいいかは分かる(できるできないは別として)。

 しかし、「やりたいこと」分かっていない場合、リソースからスコープのあらゆる場面において、何をしていいか分からないことになる。恐ろしいことに、トラブルになって初めて「やりたいこと」が分かっていないことが見えるようになる。if文を書くときにelseで何するか決まってなかったり、リリース段階になっても運用方式が決まってなかったり。

 分かっていないとどうなるか? それぞれのタスクを受け持つ人は、自分のタスクを完遂するため、「一つ前の」仕事をするハメになる。つまり、自分のタスクへのインプットとなる成果物を作ることになる。稟議書を書くシステムエンジニア、仕様を書くプログラマ、プログラミングするテスタ、テストするオペレータ。この経緯は[なぜ糞システムができあがるか]に書いた。

 そして、「やりたいこと」を分かっていないのは、発注者である。冗談に聞こえるかもしれないが、本気だ。最も分かっているべき顧客こそが、分かっていない。「やりたいこと」を分かる(可視化する)ことが自分の仕事だと思っていないのである。ITの風刺画「顧客が本当に必要だったもの」を思い出してほしい。


出典 arison.jp

 期待通りのシステムにならなかった理由として、開発者の思い込みや営業の押し付けだということがアイロニカルに描かれているが、「顧客が本当に必要だったもの」が最後のコマであることに注意してほしい。顧客が最初に説明した要件からどんどんズレていっただけでなく、そうしたズレを目にしつつ、できあがったモノを見て、ようやく顧客が「やりたいこと」に気付けたのである。

 そして、これはシステムの発注者に限らない。開発者もまた、「顧客」である。オフショアの例を挙げずとも、全部ひとりで作り上げるわけではない。機材を調達したり、構築を依頼したり、運用を任せるとき、その発注元となるからだ。

 発注する人と受ける人が、「やりたいこと」を分かり合うために、どうすればよいか。これが難しい。そもそも発注者側が、「やりたいこと」を明確にする義務があることを自覚しない場合がある。稟議を通すためだけの、ゴミみたいな中身ゼロの企画書を放って事足れりとしたり、そもそもドキュメントすら存在しない場合もある。

 この「やりたいこと」について、発注者と受注者の両方に立ち、なおかつ同じ目線で分かり合うための本が、「はじめよう!」シリーズになる。

はじめようプロセス設計はじめよう要件定義はじめようシステム設計

 システム開発の本といえば、(その担い手である)受注側に寄り添ったものが多い。テクニカルなやつからマネジメント、最近だと紛争予防のための法務系まで、作り手の役に立つものばかりだ。

 しかし、作り手に対し、「やりたいこと」が渡せていなければ、いくら作ることを頑張ったとしても多寡が知れる。「やりたいこと」が不明確な分、それぞれの仕事を進めるために、「一つ前の仕事」をすることになる。ゴミを入力するとゴミが出力される法則[GIGOの法則]に従って、ゴミみたいな要件からは、糞みたいなシステムができあがる。

 だから、そうさせないために、「やりたいこと」を明確する。そのために、何よりも発注者、すなわち顧客が動かないと......なのだが、何をすれば「やりたいことが明確になる」か分かっていない顧客が多すぎる。あたりまえだ、開発者は多くの顧客を相手にしてきたが、”その顧客”にとっては初めてだろう。”その顧客”にとって、「やりたいこと」すなわち要件を定義するためにすべきこと、すべきでないことが書いてある。

 これは、顧客側の「情報システム部」も同じ。レガシーを後生大事に護ることが”仕事”だとカン違いしている。これ、古株であればあるほど強く思い込んでいるように見える。だから、要件定義を求めても「今と同じように」「現行を踏襲して」という答えしかできない。その「現行」が何か、分かっていない「情報システム部」の人にとっても、本書は効いてくる。

 顧客よりから考えると、最初は緑本『はじめよう! プロセス設計』になる。誰と誰が連携し、どうやって仕事を進めているのか(ビジネスプロセス)が明確になる。そもそもこの仕事が全体から見て必要なのかどうかも見えてくる。

 現行の仕事のプロセスが見えるようになると、本来やるべきことなのにやれていないこと(=「やりたいこと」)のFIT/GAPが可視化される。すると、GAPを埋めるためにシステムが何をしなければならないか(あるいは、何をしなくてもよいのか)が見えてくる。仕事を回すために、システムに求められていることが分かる。極論を言うと、開発不要になるかもしれぬ。ビジネスプロセスが標準化され、システムのこの部分が不要となりました、という解さえあるのだ。

 そして、システムに求める「やりたいこと」をソフトウェアで実現するためにどうすればよいか? その方法が、オレンジ本『はじめよう! 要件定義』にある。そもそも要件とは何か、要件定義をするということは何が決まってくるのかが、流れと内訳の両方から理解できるように書いてある。

 これは、発注者に読んで欲しい。実際に要件定義を「書く」のは受注者でも良いのだが、何が定義されていなければならないか(UI、機能、データ)、そのために何を準備しなければならないか(利用者行動シナリオ、概念データモデル)については、発注する「中の人」が理解した上で決めなければならない。

 UIとかデータモデルというと、なじみのない人は敬遠するかもしれぬ。だが大丈夫、「目玉焼きをつくる」という超簡単な仕事を例に、要件定義とは何かを教えてくれる(そして、「目玉焼きをつくる」を要件定義することは、意外と決めねばならぬポイントが多いことに気付くだろう)。

 さらに、できあがった要件定義を設計に落とし込む際に効いてくるのが、青本『はじめよう! システム設計』になる。一人で要件定義を聞き出して、一人で実装する程度であれば問題ないが、そういう小規模なものはレアケースだろう。複数の人が連携して、前提を洗い、不足を補い、管理できるタスクにまで落とし込む必要が出てくる。

 プロジェクトを横断的に見た場合、どのプロジェクトにも共通する層がある(フロント層、バック層、DB層)。そのそれぞれの層ごとに、何に気を付けることで他と連携して上手く回せるかが分かるように書いてある。開発者もまた、調達やオフショアする場合、あるいは別の担当に請け負ってもらう際の「発注者」になるのだから。

 例えば、「目的語と動詞を明確にする」「受動態から能動態に書き換える」「二重否定による条件をやめる」の3つを実行するだけで、見通しの良い設計書になる。痛い経験を積んできた人は無意識のうちにやっていることが、意識的に書いてある。

 要件定義を中心として、緑、オレンジ、青の順に進めることで、「やりたいこと」を可視化して、要件定義や設計に落とし込むことができる。わたしの場合、新人さんに渡してきたが、むしろ発注者に読んでほしい。

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

« 2018年3月11日 - 2018年3月17日 | トップページ | 2018年3月25日 - 2018年3月31日 »