2007年6月アーカイブ

見積もりをする上での大原則があります。それは、

どんな方法を使っても完璧な見積もりは作ることは出来ない。

と言う事。
とはいえ、勘に頼って見積もりをするのは危険すぎます。

少しでも見積もりのブレをなくすためにも、見積もりの方法論を学ぼうと思い、整理してみました。

見積もりの流れ

見積もりは３つの段階があります。

1. 規模の見積もり
2. 工数の見積もり
3. コストの見積もり

中でも特に難しいのは、規模の見積もりと、工数の見積もりです。
単純に作業量だけでなく、リスクや体制によるズレも考慮しなければなりません。

見積もり手法の中にはそういった、リスクや体制も考慮に入れた手法も存在します。

手法は数多くあるのですが、代表的な手法を幾つかピックアップして、特徴とメリット、デメリットを纏めてみます。

類推法

経験値による見積もりであり、過去の類似の開発事例から開発規模を類推する手法です。
主に規模の見積もりをする際に有効です。

• メリット
• 過去に同様のプロジェクトが有れば精度はそこそこ
• 精密な資料が無くても見積もり出来る
• 過去の経験からリスクを想定し易い
デメリット
• 過去の案件の精緻な情報が必要（大企業向け）
• 見積もり担当者によりブレが生じる
• 新規の案件には対応出来ない

プログラムステップ法、LOC法

プログラムステップ数(LOC:Lines Of Code)に生産性を掛け合わせておこなう見積もり。要求仕様から開発するプログラムのコード数を推定し、そのコード数と１コード当りの生産性から全体の工数を見積る。工数見積もりに向く。

• メリット
• 既存コードの改修の場合は精度が高い
• コードが有れば見積もり出来る
デメリット
• 要求仕様からプログラムステップ数を推定する確実な方法は存在しない
• 新規開発に使用することはあまりない
• 類推法に頼る部分も出てくる

積算法、WBS法

WBS(Work Breakdown Structure)等によって 細分化されたタスク毎に工数(作業時間)を求めて、それらの推定した工数を積上げることにより 見積もりを行う手法。工数見積もり向け。

• メリット
• タスク自体の見積もり精度が高い
• １つ１つの見積もり範囲細かいので見積もりやすい
• スケジュール感が掴みやすい
デメリット
• 見積もりのベースになる資料自体に手間がかかる
• 資料が大量に必要
• 概算見積もりに使うのは現実的に無理
• 意外と過小見積もりになりがち

FP法(Function Point）,標準値法

FPという共通の指標で開発規模を表す。入出力ファイルの数、画面や帳票、バッチなどの処理プロセスなどの機能面から工数を算出する。工数見積もり向け。

機能数　×　重み付け係数 = FP
　FP　÷　生産性基準(FP/人月) = 工数（人月）

• メリット
• 精度が高い
• 組織も算出項目に入るので工数が出しやすい
• 利用者の視点から見積もりできる
デメリット
• 要求仕様書が無いと使えない手法
• 組み込み系の見積もりには合わない
• 技術的な物を視野に入れられない

積算法、WBS法

WBS(Work Breakdown Structure)等によって 細分化されたタスク毎に工数(作業時間)を求めて、それらの推定した工数を積上げることにより 見積もりを行う手法。工数見積もり向け。

• メリット
• 過去に同様のプロジェクトが有れば精度はそこそこ
• 精密な資料が無くても見積もり出来る
• 過去の経験からリスクを想定し易い
デメリット
• 過去の案件の精緻な情報が必要（大企業向け）
• 見積もり担当者によりブレが生じる
• 新規の案件には対応出来ない

COCOMO /COCOMO ２

Constractive Cost Modelの略。開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法。 FP法の手法を入れるとCOCOMO IIになる。工数見積もり向け。最大の特徴は、スケール変動要因や、リスク項目が定義されていること。

• メリット
• 精度が非常に高い
• 組織も算出項目に入る
• リスクを想定しやすい
デメリット
• 係数の算定が難しい
• 計算方法が煩雑

KKD法

じつは手法でもなんでもない。エンジニアの経験と間に頼った見積もりのこと。 K（勘）、K（経験）、D（度胸）の略。規模見積もり向けではあるが、単体で用いるのは危険。

• メリット
• 熟練した人であれば精度は高い・・かも？
• 他の技法でカバーできないものはコレで見積もる
• まったく根拠が無い場合はこれしかない
デメリット
• 算出根拠が薄弱
• 勘が外れると氏ねる
• 見積もる人によって見積もりが大きく変わる

精度を上げるために

どの技法も一長一短有りですが、あくまで一視点でしかない事に注意。

複数の手法を組み合わせて使ったり、複数手法で見積もりを出して検討するとより良いでしょう。
可能であれば、複数の人で見積もりを出して議論する方が誤りは少なくなります。

ユーザーの為にも、プロジェクトメンバーの為にも、そして何より自分の為に、皆様よいお見積もりを。

最後に、見積もりの参考になる本で、良く聞くのが此方。参考までに。

今日は自社で「見積もり手法勉強会」を行いました。
そもそもこの勉強会を企画した理由は、後輩が見積もりで失敗して苦労していたのがきっかけでした。

見積もりって言うと、流石に誰でも興味を持つところでは無いので、実際に見積もりで苦労した人、かつ、平日の勉強会なので、時間的になかなか厳しいのもあり、参加者は多くて５人程度だろうと想定していました。が、今朝の時点で参加希望者を調べてみると、21人！？

これは想定外。参加者の幅も、見積もり未経験者から、そろそろ見積もりを任されても良いだろうと思う人、かなり見積もりをこなした強者まで、相当広かったです。意外とみんな見積もりに興味あるのですね・・・意外。

見積もりを経験した事の無い人にとっても、自分自身の作業の見積もりは出さなきゃいけない事は多々あるので、それはそれで、良いこと。とはいえ、流石に５人の想定で考えたメニューでは予定の２時間では足りないので、急遽方針を変更することに。嬉しい悲鳴。

本来は、見積もり手法について、簡単に概要を説明して、
「フリーディスカッション形式で、実際にその場で色々な手法を使って見積もりを出してみる」というメニューにしていたのですが、20人のフリーディスカッションでは纏まらないだろうと考え、
「一人一人、見積もりを出して貰い、選択した手法と着眼点、工数を比較してみる」
というメニューに変更しました。

実はコレには一つ狙いがあって、「経験年数がランダムなメンバーで出した見積もりの平均値は意外と良いくんじゃないか？」って疑問の検証がしてみたかったのです。

お題に使った案件の実際の工数は5．7人月。
既存のパッケージソフトのカスタマイズで、ＧＵＩが16画面新規追加、入力ファイル21、出力ファイル7画面。
見積もり範囲は開発から、ＵＴまで。設計書の質は３段階のウチ最低品質。とても見直しなしには作成出来ないレベルです。（もっと細かい情報がありますが、過去にあった実際のプロジェクトなので、割愛）

書くメンバーにだして貰った工数は、最小が1．5人月（！）、最大は15人月（！）でした。
10倍の差が出ています。それにしても凄い。

私自身は、普段は画面ベースか、機能ベースで見積もりをだしているのですが、折角の機会なので、今まで「これはいけるんじゃないか？」という技法を採用して見積もってみました。

結局アプリケーションの本質は、入力されたデータを何か処理して、画面なり、ＤＢなり、ファイルなり、帳票なりに出力するのがメインな訳なので、入力ファイルと出力ファイルの数と項目数から、かなり精度の高い見積もりが出せるのでは無いか？と想定したのです。ＦＰ法のファイル特化バージョンです。

設計書の品質が低いので、1．5ポイント程度のウェイトを置いて算出。既存アプリ理解や環境設定のリードタイムを入れて、算出した工数が、5．75人月。

おおお！！なかなか行けるモノだ。現実に見積もり出すとすれば、６人月辺りで出すかな？って所です。

そして本題。
ばらつきがあった全員のサマリーを取ってみると、7．85人月程度。
ん・・・まぁまぁかなと思っていたら、参加していた部長から一声。

最大値と最小値を除いた見積もりの平均値を取ってみればどうか？と。標準偏差って奴でしたっけ？

今度は、6．１人月。おおおおおおおお！！
これぐらいの誤差なら全然ＯＫなんのでは。

結局、色々技法を凝らして考えても、ランダムに出した数値の平均もそれほどブレが無いような感じです。

これって、Wisdom Of Crowdsって言って良いのかな？

・・・いやどちらかと言うと、株式相場におけるランダムウォーク理論の法が近い気がする。
カオス理論とも思えるけど、実際に精密な計算して見積もり出すと、それなりの数値がでてくるので、カオスと言ってしまうと、少しズレがあるかもしれない。

今日の資料かまとめは、一部編集して近々あげる予定です。

↓元ネタ

Linuxを入れていたThinkPadを工場出荷状態にリカバリしようとおもったのですが、
リカバリを行おうとすると[Error #1828 Error: Free Space is too small] とか怒られます。

リカバリ用のソフトを展開するときに、MBRにでも展開してしまうからか...?

fdiskコマンドでパーティーションを開放すればいいんだけど、
中途半端にファイルが書き込まれたため、GRUBからLinuxが起動しなくなってしまった。

仕方ないので、そこいら辺りにころがっていたubuntuをCDブートして、fdiskで領域を全て開放したら、リカバリできそうな気配。

いまリカバリ中だけど遅くていつまでかかるやら・・・
ずっと奴のターン。

Powered by ScribeFire.

昔の事を思い出しました。

大学時代飲食店でアルバイトしていた事があったんですが、そこはテラ体育会系だったんです。
「頑張ってるかぁ？」って社員さんに聞かれて、普通に「頑張ってます」って答えたら、「ばかやろう！！」ってwww

理由を聞いて納得。
頑張っている様に見えたなら、わざわざ「頑張ってる？」なんて聞く必要ないんです。
つまり「頑張っている？」と聞かれる位に、頑張っている様に見えなかったって事なんですねぇ。ナルホド。

そんな感じでそのお店では、一切言い訳が通用しませんでした。
そこで得た経験って、未だにすっごく大切なモノで、私の社会人としての、いや人間としての礎はそこで培われて居るモノが多いです。

やがて社会にでて、会社に入って思ったことは、言い訳が多すぎる事。
初めはイライラばかりしていました。

仕事の都合上、色々な会社に行って、沢山の人たちとお話をする機会があるんですが、ほとんどのヒトが、「ウチの会社は駄目だ」とか、「周りの人がどうしようもない」みたいな事を聞きます。

ちょっと待てと。
会社がどうこう以前にあなたは何をしているんですか？周りの人なんて関係ないでしょう。
「誰それが駄目だから、会社が嫌になった」って言い訳にすらならないじゃないですか。

そういう人が、一人二人と増えていって、その結果として、あまり宜しくない結果になっている。
「会社が駄目だ」って行っているあなたが駄目にしているんですよ。自覚しなさい。

ふと政治の腐敗についての議論に似ている。

昔、政治家が賄賂を取ったニュースをウチの母親が見て、
「もう日本の政治は腐敗しているね」
って言っているのを聞いて、それは違うだろう。と思ったんです。

その時思い出したのが、こんなフレーズ。私のメンター銀英のヤン・ウェンリー先生のお言葉。

政治家が賄賂を取ることが政治の腐敗じゃない。それは政治家一個人の腐敗に過ぎない。政治の腐敗とは、政治家が賄賂を取ることを批判できない状態の事を言うんだ。

だから、「会社が駄目だ」とか言う前に、何が駄目なのか声を大にして言って欲しい。そしてそれを正すべく何かして欲しい。全員がそう思えば変革なんてたやすいでしょう。
そこまでするのが難しいなら、せめて、口をつぐんで自分のやるべき事をしっかりやって欲しい。誰も責めやしないのだから。

もし、「駄目だ」って事を口に出してしまったら、他の改革をしようとしている誰かの邪魔をすることになる。
それは、あまりにも寂しい。

組織が悪なんてのは、現実ではほとんどあり得ない。
もう一つ一部改変して引用。

組織があるから、個人が存在するのではなく、主体的な意思を持った個人が集まって組織ができる以上、どちらが主で、どちらが従か自明です。

主が諦めたら、従が腐るのは当然のこと。
たとえ腐っても、それを理由に自分の責任を放棄するのは、あまりに悲しい。

なんて思うんですよね。

シナトラさんのjkondoアワーが沈黙し、そしてhatenaに冬将軍が訪れたというエントリを読んで、『あぁ、確かにそんな印象あるな』と感じました。

個人的には『はてな』っていうと、２年くらい前にWeb2.0がほど加熱して来るちょっと前の時期に、とんでもなく衝撃を受けた覚えがあるんです。
あの頃は、ワタクシはまだＳＥ指向で、はてはアーキテクトに・・・とか思っていたんですけど、Ｗｅｂ上を徘徊していて、
「Web2.0っていうなんだか良く解らないモノが、トンでもなく凄い事になっている感じがする！」とかいう、訳の解らない興奮を少しずつ感じていた頃でしょうか。

同僚達と、「Web2.0 ってナンなんだ！？リッチクライアントとは違うのか！？」とか議論していた頃に、先輩から『Web2.0的サイト』として教えて貰った、変な会社が作ったWebサービスが「はてなブックマーク」だったのです。

はてブを使い始めて今まで見過ごしてきた周りの状況が見えてくるに従って、『はてな』って会社の（当時は）はちゃめちゃなやり方に熱狂するようになっていました。

あの頃の『はてな』が今の自分にとって大きな影響を与えている感じがしています。

ところが、シナトラさんの、

ようするに最近は社長の顔が見えなくなってきた＝はてなが見えなくなってきた感があるなと。

という発言をみて、確かにそんな感じがするんですよ。

ただ、考えてみると、『はてな』が変わったというのではなく、『はてな』があの頃やっていたことが、最近フツーになってきているような気がしている。それは、『はてな』が大きな影響を及ぼした結果なんでしょうけど。

数年前、とんでもなくインパクトを受けているから、今も無意識にそういったサプライズを期待してしまうのです。
新サービスを出さなくなったり、”衆愚化している”とか叩かれていても、jkondo氏が前線に居るときは、まだ「なんかやってくれそう」な勝手なワクワク感はあった。

２年もたてば、イロイロ状況が変わっているってのもあるんですが、
それでも、jkondo氏がシリコンバレーで何かおこしてくれる事を期待してたりします。

ただ、最近は無責任に期待して待っているぐらいなら、援護射撃ぐらい行きてぇな、と思う今日この頃です。

キャンドルナイト的なイベントを探していたら、素敵なイベント発見。
その名も東京八百夜灯。

場所は芝公園増上寺。うわぁ、会社の近くだぁ。まぁ、日曜なんですけど。

東京タワー消灯のカウントダウンもあったりして、なんだか面白そう。

まぁ、なんて素敵なんでしょう。
いってみたい、いってみたい、いってみたい！！

毎年やっているみたいで、今年は6/24(Sun)に行われるそうです。
梅雨なんですけどね・・・

Powered by ScribeFire.

最近仕事の都合で文字コードの事ばっかり調べています。
纏めるにはもう少しかかりそうなんですけど、文字コード調べるにあたって、知っておいた方が良いことをさらっと書きます。

まず基本となるのはISO2022という形式。
これは文字コード系ではなく、文字コード系切り替え手法を定義していて、コレを抑えておかないと、ＪＩＳＸ0208とか、JISX0213が理解出来ません。　泣

特徴は、0x1b（ESC）をつかって文字をコード表を切り替えることと、複数バイトを１文字に割り当てることが出来ること。
94×94=8,836文字表現可能です。

JISX0208は普段我々が使う文字コードで、第一水準と第二水準の漢字が含まれます。WindowsXPはコレに準拠しています。

VistaはJISX0213準拠で、２００４年に編纂されたＪＩＳＸ０２１３:2004に準拠しています。

とはいっても、WindowsはＪＩＳXを拡張したcpxxxシリーズを使っています。
JISX0208であればcp932とかがそれにあたります。

あとちょっと困るのが、ＪＩＳＸの中には、ベンダーによって違う文字が割り当てられているものがあります。いわゆる機種依存文字って奴ですね。JIS -> unicodeなら問題ないんですけど、そのあと、unicode -> JISとすると、文字が変わってしまう事があります。ラウンドトリップ問題とか言われる奴です。

一番なじみの深い、Shift_JISは、実はＩＳＯ2022に準拠していなくて、独自のコード体系ですが、JISXが採用している区点式のコードから計算式で算出可能です。

まぁ、算出できたところで、WindowsVistaでさえ、フォントに含まれていない文字形（グリフ）があったりするので、ＪＩＳＸ0213に準拠するアプリを作るときは注意が必要なようです。
また、JISX0213にはサロゲートペア文字(UCS4)がいるので、コレも注意。聞いたところによると３００文字程度らしいですけど。

暫くはこの辺りを調べ回る事になりそうです。

Windows Vistaがロールアウトしてから、もうすぐ半年。
なかなか企業での導入が進みません。

理由としては

• マルチメディア機能など、企業にとってはどうでも良い
• アプリケーションのサポート状況が固まっていない
• セキュリティが不安
• 文字コードの問題

などなどがあげられます。

本格的に導入が始まるのは、SP1が出たあと（おそらく来年初頭）になるでしょう。
が、我々エンジニアはそうも言っていられません。
ちらほらVista対応なんて言葉が出てくるはずです。

特に意識すべきは文字コードの問題です。
これが結構な大問題。

１．XPとVistaでは文字の見え方が違う
２．一部の文字がサロゲートペア

という状態です。
１はいいんですけど、２が大問題です。

まずは１から簡単に説明します。
したのPDFはMicrosoftから出ているグリフの違いに関するドキュメントです。

右がXPで表示したとき、左がVistaです。

これはXPではJIS X 0208、VistaではJIS X 0213という文字コードが使われているからなんですけど、
正しいのはVistaの方です。

JIS X 0213:2004に関する資料は、Microsoftのこのページからダウンロードできます。

JIS X 0208が間違えているんですね。ソレを0213で修正したわけなんですけど、
今企業にあるのはほとんどがXPなわけだし、環境によって見え方が違うのはちょっと気持ち悪いですね。

これはモジコードの問題なので、XP用の0213の文字セットもあるし、
Vista用の0208の文字セットもあるので、このことが説明できれば良いでしょう。

Windows XP および Windows Server 2003 向け JIS2004 対応 MS ゴシック &MS 明朝フォントパッケージ
Windows Vista 向け JIS90 互換 MS ゴシック & MS 明朝フォントパッケージ

問題は２です。サロゲートペア。
あ〜もう！って感じです。

何が困るかという話の前にUnicodeについてお話させてください。

1980年代、コンピュータ上で多言語をシームレスに扱えるようにしようという動きがありました。
提唱はゼロックスで、協力した企業として、マイクロソフト、アップル、IBM、サン･マイクロシステムズ、ヒューレット･パッカード、ジャストシステムなどが参加したユニコードコンソーシアムによって策定されました。
今は、ISO/IEC 10646として国際標準になっています（厳密にはUCSのことを定義している）。

で、このUnicode。
16ビットを使って一文字を表現しています。

16ビットで表現できるデータは65,536ですね。
問題は、65536文字で全ての言語の文字を表現できるか？って事です。

むろん出来るわけない。全然足りなくて、空いた２万文字の争奪戦が勃発したぐらいです。

このUnicodeをUnicode1.0といいます。

ではどうするか？というと、
さらに16ビット追加して、32ビットで一文字を表現する領域を作ったわけです。
無論今までの16ビットで表現できる文字はそのままです。

と言う事は、Unicode2.0には、16ビットで一文字をあらわすものと、32ビットで一文字をあらわすものが混在する、可変長な文字セットになっています。
この32ビットであらわす方法をサロゲートペアって言います。

可変長な文字扱うのって大変なんですよぉ・・ヽ(´Д`；)ﾉｱｩｱ...

そんなの関係あるの？と思った方。
それが大アリなのですよ！

例えばC#でcharに文字を代入するばあい、

char hoge = '[非サロゲートペア文字]'

はOKですが、

char hoge = '[サロゲートペア文字]'

はコンパイルエラーになります。

なぜか？というと・・・charが16ビットまでだからですねぇ。

じゃあ、どうするのか？

String piyo = "[サロゲートペア文字]"

こうするしかないのです。

もーね、コレが同いう事を意味するかプログラマならわかると思うのですが、piyo.lengthとか当てにならないわけですよ。
ほんと、「あ〜ぁ」って感じ(*´д`)

我らが愛する正規表現も影響を受けます。
バイト単位で見るため非サロゲートペア2文字 = サロゲートペア一文字でマッチしてしまう可能性は、大いにあります。回避策はちゃんとあるんですけどね。

プログラミングだけじゃないです。

インフラストラクチャレベルも影響を受けます例えば、RDB。
データ格納するだけならいいんですが、検索やキーに指定した場合は同様に問題が起こります。

アプリの実装に関しては、JIS X 0213:2004 / Unicode 実装ガイドが役に立ちそうです。

Powered by ScribeFire.

firefoxからblogへエントリを投稿するプラグイン、ScribeFireを使ってエントリしています。
これがすっごい便利！！




ただ単にエントリができるだけでなく、WYSWYGなエディタでエントリ出来ます。

フォントの色を変えたり、ボールドにしたり、斜体にしたりも簡単。


これでエントリもこまめにできますね。

Powered by ScribeFire.

Think Padのカーソルキーの上のブラウズボタン。
何かと悪さをしてくれます。
(ThinkPadのカーソルキー[←,→]の上にある奴）

Webページで入力中に、誤って押そうものなら、編集した内容は全て失われる。
今朝やってしまいました。

非常に邪魔なので、
別のキーに割り当てることにしました。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
に新規のバイナリ値としてScancode Mapを追加し、その中に文法に従ってキーコード等を記述すれば良い。

一行目はヘッダなので全て00
続いて、変更するキーの数（2個の場合、ターミネータを入れて3）
変更するキーの指定（Windowsキー　 戻るキー）が二行目。
変更するキーの指定（Applicationキー　進むキー） ターミネータ（全て0）

00 00 00 00 00 00 00 00
03 00 00 00 5b e0 6a e0
5d e0 69 e0 00 00 00 00

あとは再起動すればOK。

なお、キーの凡例
（書き込むときは左右をひっくり返すらしい）

但し、Alt + カーソルキーでも「戻る」の動作をするので注意。
コレも殺したい。

Macユーザーならば、どうしても使いたいTextMate一度使ってしまうと病みつきでなかなか抜け出せません。

ただ、致命的な欠点があって、日本語対応されていないんですよね。
フォント幅がアルファベット幅しかないので、日本語表示すると、隣の文字とかぶってしまう。
また、入力中も確定するまでは文字が見えないので、今何を変換しているかが見えないのです。

普段のテキスト編集ならばemacsで行うので良いんですけど、コーディングは出来ればTextMateでしたい。
コメント分を全部英語にすれば気にならないのだけれど、流石に複数人で開発しているときは、自由にならない事も多い。

というわけで、無理やり日本語対応させて見ました。

まずは日本語の表示。フォントをカスタマイズして日本語のフォント幅を縮めれば良いわけですが、どうやろうかな？と思っていたら、hetimaさんの所にこんなエントリを発見。

http://d.hatena.ne.jp/hetima/20061102/1162435711

ForMateKonaVeというフォントまで公開されています。コレを拝借させて頂く事に。
OSのフォントブックに登録して、TextMateのフォントを変更。

入力は同じくhetimaさんのCJK-Input.tmpluginを使わせて頂く事にしました。

http://hetima.com/textmate/index.html

ダウンロードした、CJK-Input.tmpluginを〜/Library/Application Support/TextMate/PlugIns/コピーするだけというお手軽さ。PlugInsディレクトリが無かったので、作成して入れてみたところ、こんな感じに。

おお、これで普通に日本語が使える。
本家が対応してくれれば一番早いんですが、コレでも全然ストレスはない感じです。

感謝。

僕は村上春樹の作品が大好きなんですが、その作品の中で良く出てくる作品がこの『グレート・ギャッツビー』です。
前々から気にはなっていたんたんです。いつか読みたいなぁ。と思っていたら、村上春樹自身が翻訳をしていたので、これぞとばかりに読んでみました。

春樹氏自身にも、大切な作品らしく、後書きにこんな事を書いています。

もし、「これまでの人生でもっとも重要な本を三冊あげろ」と言われたら、考えるまでもなく答えは決まっている。この『グレート・ギャッツビー』と、ドストエフスキーの『カラマーゾフの兄弟』と、レイモンド・チャンドラー『ロング・グッドバイ』である。 　（中略）　どうしても一冊だけにしろと言われたら、僕はやはり迷うことなく『グレート・ギャッツビー』を選ぶ。

また、こうも言っています。

それからこれまでに刊行された『グレート・ギャッツビー』のいくつかの翻訳書をひととおり読んでみて思ったのは、その翻訳書の質とは別に、「これは僕の考える、『グレート・ギャッツビー』とはちょっと（あるいはかなり）違う話みたいに思える」ということだった。

翻訳書がムズカシイのは、原著が本当に伝えたかった事、原著が持つ、世界をどれだけ正確に翻訳できているか？という事。これは原著の言語体系とか言うべきものだけでなく、本来の言語が持つ言霊とも言えるモノをどれだけ近いモノに置き換えられているか？ということにも繋がっているのだと思う。どんなにその言語の精通していても、その魂は翻訳されることで多少なりとも変質してしまうようなきがするんです。
だからこそ、翻訳者が誰であるか？ということは重要で、その点、作家として大好きな春樹氏の手によるモノであれば、少なくとも、作品の一つの解釈として楽しめると思ったのです。

この作品は、主人公ニック・キャラウェイの目を通して、Ｊ・ギャッツビーという人物の、哀しくも美しいひと夏を描いた物語。
貧しい身から、富を築いた隣人ギャッツビーが夏の間中毎週の華麗なパーティーを催す。誰でも自由に出入りできるその華麗なパーティーの裏には、ギャッツビーの切なくも純粋な想いが隠されていた・・・

今日読み終わったばかりなんですが、ギャッツビーの悲しみや喜び、絶望と希望がダイレクトに感じ取られて、暫く物語りの余韻から抜け出せませんでした。

１９２０年代を代表する名著ですが、読む機会があって良かった。

『グレート・ギャツビー』
Francis Scott Fitzgerald (原著), 村上 春樹 (翻訳)
中央公論新社 ￥ 861 （税込）