« 2006年7月9日 - 2006年7月15日 | トップページ | 2006年7月23日 - 2006年7月29日 »

徹夜本「復讐する海」

 徹夜するほど面白かった小説企画。「徹夜するほど面白かった小説」で知った「復讐する海」を読了、これはスゴい。ありがとうございます、Bさん。
復讐する海
 ただし、ボリュームは無いので徹夜するまでもなし。しかも開始早々度肝を抜かれ(予備知識ゼロで手にしたのだ!)→以後イッキ読み→気づいたら終わってた、幸せな読書体験…というのは真っ赤な偽り。

 幸せと評したが、マチガイ、

 これを読めば地獄体験ができる。

 特に、この本、食前食後に読むの禁止。

 さらに、心臓の弱い方もやめておいたほうが吉。

 怒ったマッコウクジラに体当たりされ、沈没させられた捕鯨船の話は、『モービィ・ディック』が有名だが、本当の悲劇は「白鯨」のクライマックスから始まる。捕鯨船から脱出したのは20名――そのうち、生き残ったのはわずかに8人――赤道直下の太平洋で起きた極限状況を綿密な調査の下に描いたノンフィクション。2000年の全米図書賞を受賞。

 紹介文に「これが冒険小説ではなく、実話であることに衝撃を覚えずにはいられないだろう」とあるが、激しく同意。読む前も、読んでる途中も分かってはいたんだが、あとがきで、これがかけ値なしの実話だというところを再認識させられてめまいを覚える。

 書き手も分かってる。感情を排した淡々とした描写で、事実のみを記そうという姿勢で一貫している。おどろおどろしくドラマティックに書くことだって可能だろう。「くじ」を引いて友達を○○しなけりゃいけないことになった場面とか(泣いた)、死期を察したリーダーが取った行動とか。

 また、もっとジャーナリスティックに書くことだってできたはず。「最初に食べられた4人の黒人は、なぜ『黒人ばかり』だったのか?」、あるいは「船長の決断が覆り、結果的に全員を絶体絶命の場所へ追いやった原因は?」――等など、センセーショナルに書けば書けたものを、そうしなかった。

 メルヴィル「白鯨」は、ある生存者が書いた記録を元に著されているが、実は半分に過ぎない。本書では、最近発見された別の乗組員の手記とつき合わせることにより、より立体的に悲劇が明らかにされる。ともすると最初の記録を書いた乗組員の過ち、ごまかしを糾弾する筆致になろうとするのを著者は抑え、常に公平な立場で事実を詳らかにしよう、という意志が見える。

 さらに興味深いのは、救かった人の「その後」が描かれているところ。「こうして彼らは助かり、故郷へ帰っていったのでした、めでたしめでたし」となるはずがないところ。生き延びた時点でまだ10代、20代だった彼らが、その後、どうしたのかが、これまた淡々と書かれている。特に胸が一杯になったのは、生き延びた部下たちが、次の航海で選んだリーダー。思わず目が熱くジワっときたなり。そしてそのリーダーの末路…

 ええ、「白鯨」は未読ですとも。

 もちろん読みますとも。

――――――――――――――――――――――――――――――――――――――

企画「徹夜小説を探せ!」のリストを更新

■これから読む徹夜小説

  永遠の仔(天童荒太)
  第六大陸(小川 一水)
  ガダラの豚(中島らも)
  傭兵ピエール(佐藤賢一)
  ゼウスガーデン衰亡史(小林恭二)

  魔術師(J.ファウルズ)
  北壁の死闘(ボブ・ラングレー)
  イヤー・オブ・ミート(ルース.L.オゼキ)
  スワン・ソング(ロバート.R.マキャモン)
  シャドウ・ダイバー(ロバート・カーソン)
  カラマーゾフの兄弟(ドストエフスキー)米川正夫訳 /岩波文庫版

■徹夜を覚悟・徹夜した小説

  火車(宮部みゆき)某弁護士事務所では、新人研修に使う
  半落ち(横山秀夫)ラストで号泣、涙で読めねぇ
  ダ・ヴィンチ・コード(ダン・ブラウン)読むジェットコースター
  摩天楼の身代金(リチャード・ジェサップ)「最高」の冠を付けたい
  悪童日記(アゴタ・クリストフ)「ふたりの証拠」「第三の嘘」と一緒に!
  ベルガリアード物語(D・エディングス)ドラクエとFFを足して2倍した面白さ
  大聖堂(ケン・フォレット)2006年のNo.1スゴ本
  告白(町田康)読むロック(ただし8beat)
  復讐する海(ナサニエル・フィルブリック)これが冒険小説ではなく、実話であることに衝撃を覚えずにはいられない

半落ち火車悪童日記
ダ・ヴィンチ・コードベルガリアード物語1大聖堂
告白復讐する海

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

観鈴グッドエンド

 ゲームのみならず、TVアニメ、映画と、わたしたちは、何度も彼女の死に立ち会ってきた。微妙に違えども、ラストで彼女は必ず、「もうゴールしてもいいよね?」と訊いてくる。その度にひるんだり涙にむせたり。
AIR2AIR1
 くり返される「ゴール」の果てに、異なるラストに出会う。ちょっとふっくらとした観鈴、だがすんなり伸びた二の腕がまぶしい。「オフィシャル」の冠の下、同じ展開かと思いきや、まさかそうなるとは… !!

 いやいや、これはこれで良し。ファーストプレイのとき、彼女が助かるエンディングがあるに違いないと、必死になって探したことがある方なら

 空の少女にとらわれていたのは、実はわたしだったのかもしれない。これで憑き物が落ちた気分。これでようやく救われる、ありがとう。AIR、全2巻、知ってる方だけにオススメ。

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

要求仕様戦争(その4)

■開発工程をどうこうする――「要求開発」というフェーズを設ける

 いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。

 これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]

 例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC(品質管理)、生産物、バグトレースから再利用まで、様々な立場の人に使われている。

 しかし、要求を決める方法はおそまつ。とてつもなく場当たり的に試行錯誤を繰り返して「要求」を決めている。これは「情報システム部門」を作れば解決というわけでもなく、システムを超えた業務の全体最適化を図るためには、情報システムへの要求がロジカルに導出される必要がある(情報システム部は、「システム」しか目が行かないからね)。

 いかに良いツール(Eclipse)を有していても、何を作るかが曖昧モコモコのままだったら、まともなブツができるはずがない。まちがった要求を正しく作っても仕方がない――要求開発の発想はここが原点。そこで、ソフトウェア工学技術によって体系化された方法論――Openthology の出番。これを用いて、ビジネス上の目的と整合性の取れた価値のあるシステム要求を導くことを目的とした2冊をご紹介。

■「要求開発」のバイブル

要求開発 ひとつめ。「要求開発」はズバリそのもの、バイブルを目指して編まれており、要求開発を考える上で必要な全てのトピック・手法を網羅している。

 その重要性や位置付けはとても同意できる。特に激しくうなづけるのは次の一文――要求はもともとあるものではなく、ビジネス要求をもとに合理的かつ能動的に開発すべきもの――つまり、要求分析、要求定義といった「いまそこにあるもの」ものを紙に落としたりモデリングするやり方ではダメよ、というところ。

 確かにユーザーヒアリングを通じて得られる「要件定義」には限界がある。ユーザーから聞き出した要求を明文化したり、分析したりする作業とは一線を画した、能動的に要求を開発することが必要だ――が本書の主張。

 ではどうすればよいか? その答えを出来る限り網羅しようとしている。

 モデリング手法にUMLを取り入れ、ほとんどのグラフはUMLの流用。さらに、BSC戦略マップ、問題分析ツリー、ターゲット分析モデルといったコンサル手法もおさえている。すなわち、開発者とコンサルタントの双方のイイトコ取りをしている。スタッフ部門やコンサルタントがこっそり参考にすると重宝する。

 必読は第5章。それまでの「体系化」「網羅性」をかなぐり捨てて、「要求開発を『絵に描いた餅』に終わらせないために」とある。「Openthology に魂を入れる45のポイント」と銘打って、要件定義の場の泥臭い丁丁発止や、プロジェクト立上げに絶対やっておかなければならないこと、沢山の失敗事例がコレデモカというぐらい続く。これは読んでおくべき …まぁ、全ての要件定義フェーズに共通するリアルな教訓なんだが、Openthology に胡散臭さを感じ取っている人には良いキックとなるだろう。

■コンサルティング寄りの「要求開発」本

戦略的要求開発のススメ さらに上流の次元での話。「戦略的要求開発のススメ」は、視座が高いから「良い」というわけではない。鳥瞰的な分、より具体性が薄れている面もあるが、これから重要になることは間違いない。

 ひとたび作り始めてしまえば、あとは「いかに与えられたモノを正しく作るか」に没頭することになり、「与えられたモノ」を論議することはない(あたりまえだ)。あるいは、昨今の開発手法論議やメソドロジーは、ほとんどといってよいほど、「いかに正しく作るか?」に全力を費やしている。しかし、与えられたモノが誤っていたなら? 間違ったものをいかに正しく作っても無意味だ、「顧客は要求を正しく表現できる」なんて寝言だろ!というのが趣旨

 で、そのために、「要求開発」というフェーズを設けましょうという提案が続く。経営レベルの要求をITで実現するために「やるべきこと」を明確化するフェーズだ。まず、経営分析から「ビジネス要求」がアウトプットとして出てくる。「××の売上○%アップ」や「△△製品の歩留まりを○%にする」とかいうやつ。次に、それを実現するために、ITとして何ができるのかをああだこうだと議論する。それが「要求開発」というやつ。

 言っていることはごもっともなんだけれど、本書を読むと、これ、一度も動かしたことがないやり方だということが良く見える。コンサルティングメソッドをかじった抽象論が延々と続いており、そのままでも煮ても焼いても使えない。書いてる人も分かっているようで、「これからそんな戦略的なフェーズが要りますよ」と提唱をくり返す。

 むしろ、ここから真髄を素直に読み取り、自分のやり方に適用するのが賢い本書の使い方なんだろ。例えば、1コ上の要求(を併記した)仕様書にからめて、より高い(ビジネス戦略から見た「要求仕様」)とのリンケージをするとか(やりすぎ?)。

■「要求開発」というフェーズの弱点

 システムのグランドデザインを決めるフェーズにおいて、「要求を開発する」ことは、今後ますます重要視されるだろうし、その方式論がもてはやされるのも必至。コンサルタントは銭のネタとして、そして、ベンダーは要求仕様戦争の要因を回避する最終兵器として。

 しかし、経営者(意思決定者)にとってのメリットが皆無。ないことはないが、無理矢理ひねり出している後付けの理由。考えてもみるがいい。自分が経営者だとして、コンサルタントが書いた計画書がある段階で、こいつをRFPなり仕様書なりに落とすためにさらにひと手間かかる、といわれたら何と答えるだろうか?

 「要求仕様」の必要性なり必然性を確信しているのは、作り手であって顧客ではない。「デスマを回避するために必要」などとヌかしたら、顧客はきっとこう言う「期限内・予算内で、そうならないようにするのがオマエの仕事だ」と。ご紹介した2冊はこの疑問に答えていない。

 言い換えると、経営者に要求開発の動機づけをさせたSIer が勝ち、と読み取るのだ。つまり、フェーズ(期間)を新たに設けるのではなく、経営戦略フェーズにメンバを潜り込ませたり、人員増のための方便として… 等など。フェーズ、すなわち時間という概念を外しても可。例えば、要求仕様の「成果物」を出すための作業の必要性を認識させる。で、その作業への予算を割り当ててもらう。

 要は、この考え方を銭につなげられたモン勝ち。システム開発にあたり、見えてなかった本質が本書によりクッキリあぶりだされている。

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

« 2006年7月9日 - 2006年7月15日 | トップページ | 2006年7月23日 - 2006年7月29日 »