第6回:”翻訳する”ということにも、本質的なむずかしさがある|本気で読み解く”人月の神話”(エピローグ/訳語について/訳者あとがき)

AUTHOR :  田中 耕比古

”翻訳”とは、”創作活動”である

人月の神話【新装版】
人月の神話【20周年増訂 新装版】

本日は、普通ならあまり解説されないであろう「エピローグ」「訳者あとがき」を読み解いていきたいと思います。ただでさえ田山花袋の「蒲団」並に読まれていない「人月の神話」の、「エピローグ」や「訳者あとがき」まで真面目に読んでいる人は、指輪物語(およびホビットの冒険)の世界の神話の時代を描いた「シルマリルの物語*」を読んでいる人ぐらいレアな存在だろうと思います。

*日本の歴史でいえば「日本書紀」だと思ってください。

連載記事一覧は、コチラの最下段から

エピローグはたった1.5ページ

この300ページにわたる(読みにくい)長編のエピローグは、たったの1.5ページ(正確には、1.3ページくらい)です。行数にして39行。約1,300文字くらいです。もはや全文引用してもいいくらいですが、それではさすがに芸が無いので、とりあえず要点を括りだしておきます。

  • 13歳の時(1944年)に Harvard Mark I というコンピュータに対する記事を読んで、非常な驚きを得た
  • その後、10代のIBMでのアルバイト経験(プログラミング講習)を経て、ハーバード大学に学び、ソフトウェア開発の研究に没頭した
  • テクノロジーの進歩を目の当たりにしながら、自分自身が、スーパーコンピュータの開発に関与した
  • 時代は流れ、当時開発したスーパーコンピュータよりも何倍も高性能で、1000分の1の価格の”パソコン”が簡単に入手できるようになった
  • その技術革新と同様に、コンピュータ関連の知的分野も、爆発的進化を遂げた
  • 情報量は非常に増え、すべてを網羅して知ることは不可能になってきた
  • それは、悲しむべきことではなく、未来に向けて進歩する可能性が無限にあることを意味する。喜ばしいことだ

という感じですね。

ソフトウェア開発、ソフトウェアエンジニアリングの本質的困難を奇跡のように解決する「銀の弾」は無いにせよ、今後の進歩に「可能性」を託しているわけですね。

訳語に関する解説

ここからは、訳者の努力の痕跡を追っていきたいと思います。まずは「訳語」に関する解説です。すさまじくザックリ解説しておきます。

  • アーキテクチャ:ソフトウェアの基本設計。外部設計局面=業務要件と理解すればよいと思われる
  • インプリメンテーション:内部設計局面。すなわち”仕様”決定≒システム要件の決定
  • 実現(リアライゼーション):プログラミング局面。
  • アーキテクト:アーキテクチャを設計する人。ソフトウェアの基本設計を”デザイン”する人
  • 実現者・制作者:インプリメンテーションを担当する人、プログラミングを担当する人。(明確な切れ目が無い?)

というあたりですね。

最後にあげた、実現者・制作者については、この章の説明文を読んでも、正確な定義がわかりません。このあたり、「翻訳時には、めちゃめちゃ苦労したんだろうな」と思いますが、読者が混乱するのも仕方ないなと思ってしまいます。(引用しておきます)

ブルックスは、文脈によってはアーキテクト以外という意味でインプリメンテンターやビルダーという言葉を使っている。インプリメンテーション担当者、プログラミング担当者、あるいは製品組み立て担当者のことで、本訳書では文脈に応じて実現者あるいは製作者などという訳語をあてた。

ということなのですが、「実現=リアライゼーション」と定義しておいて、「インプリメンテーション担当者」を「実現者」と訳したら混乱するよな、という感じです。まぁ、そもそも、ブルックス氏が、「アーキテクト以外」をひとくくりにしているので仕方ない、というのも分からなくはないのですが・・・

訳者あとがき

と、エピローグ、訳語解説と来たわけですが、いよいよ今回のメインディッシュ「訳者あとがき」です。まぁ、お定まりの”謝辞”は飛ばしまして、”編集後記”を読み解いていきたいと思います。僕は「この本は読みにくい」と連呼してますが、訳者の皆さんが、相当苦労されたであろうことは、想像に難くないのです。

”普遍性”の3つの理由

訳者(の、富澤氏)は、「人月の神話」が20年経過した今も、まったく色あせることなく「そのまま実情に当てはまる」ことについて、3つの理由を挙げています。

  1. 優れた組織論であるために、色あせない。例え、組織の在り方が変わったとしても、組織運営をしていく上でのむずかしさは、本書が述べているものと同じである。
  2. ソフトウェア構築が、非常に”人間的な創作活動”であるためにいつの時代の、どんな物事にも適用できる。プログラミングは、創作活動の中でも”常に変化する”ことを前提とする必要があり、柔軟性が求められるものなので、さらにむずかしくなっている。
  3. パーソナルコンピュータの普及により、コンピュータの”利用者”が圧倒的に増えたことで、本書を必要とする人が増大した。利用者は専門家ではなく、一般ユーザーのため、迷わないための指針が必要であり、その役目を果たすことができるのは本書だけだ。

この3つは、非常にリーズナブルに思えます。特に二つ目の「人間的な創作活動に対する”銀の弾”の模索だから普遍的なのだ」という観点は、非常にしっくりきます。僕はこの連載を書くために、人月の神話を再読し、微細な部分まで読み込んでいるわけですが、読めば読むほど「普遍性」に気づきます。富澤氏がひとつめにあげた組織運営に関して適用できるのは勿論のこと、戦略コンサルティング(あるいは、経営そのもの)の領域にも適用できます。(このあたりは、次回以降(1章~15章)の読み解きの中で、触れていきます。)

「訳者の思想」が翻訳を難しくしたのではないか

続いては、「本書の読みにくさ」の理由と思しき一節を引用します。

もともとブルックスの関心はトータルとしてのシステムの構築にあった。その本質を攻略する「銀の弾」はないが、それを攻略するための有望な方法を挙げている。例えば、パッケージソフトの利用であり、プロトタイプであり、漸増的なプログラム構築法である。(中略)

しかし、「これらが直ちに、大規模なクライアント/サーバーシステムに当てはめられるとは思われない。まだ、大規模プログラム開発においては、生物のメタファーへのパラダイムシフトには時間を必要としている。この考えは実験室の話だ」と、訳者の1人は主張している。彼は現行ライブラリや仕事のやり方をオブジェクト指向に変えることに苦闘しているからだ。

この「訳者の1人」というのは、滝沢徹氏のことだと思われます。(というのも、巻末の訳者略歴に3名のお名前が記載されていますが、男性は、滝沢氏と富澤氏だけなのです)

もちろん、できるだけ公正に・公平に翻訳するように取り組まれたのだと思うのですが、本書は最早”哲学書”の領域にたどり着いてしまっています。それを翻訳するにあたっては「原著の著者と、同じ哲学・同じ思想を持った訳者」でないと、うまく翻訳できないのではないか、と感じてしまいます。

レベルの全く違う話で恐縮ですが、僕も、IBM在籍中に、あるホワイトペーパーの日本語版の監修を任されたことがあります。その際、一旦、翻訳業者に「日本語」にしてもらった資料を読み込んで、意味が通るように一字一句残らず書き直す、という作業を行いました。そして、ほぼ原形をとどめないレベルまで書き直した結果を、英語が堪能な方に”原文と齟齬が無いか”という観点で確認してもらいました。何を言っているのかというと「創作活動に近い領域に踏み込まないと、本当の意味での”翻訳”なんてできない」ということです。それはつまり「日本語版のホワイトペーパーは、監訳者である僕個人の考え方・思想を反映したものになる」ということを意味します。

そうすると、著者と訳者に、なんらかの”思想の差”がある場合には、「訳者の意向に沿う内容に寄せていく」か、「正確性を重視して、もってまわった表現にする」ことになります。本書の場合、さすがに前者という選択肢はなかったでしょうから、後者を選択した結果「回りくどい表現が多い本」になったのだろうと考えられます。

その後、訳者あとがきは「錬金術」の話から、「貨幣価値に換算される成長」の話となり、それを支える金融システムは果たして”実体”をもつのか否かという命題に辿り着き、電子マネーという”実体のない貨幣”の登場が、貨幣に対する認識を変えるのかもしれない・・・というお話に展開されていきます。非常に面白い視点ではありますが、これもまた、「別の思想・哲学」の話ですね。

非常に賢い方が別の言語で書いた本を、別の非常に賢い方が違う言語に訳す、ということには、非常なる「むずかしさ」があるのだということをしみじみ感じます。そもそも、英語で書いてある本を英語で解説することも難しいでしょうし、日本語の本を日本語で解説することだって難しいのです。この部分は、まさに”偶有的ではない、本質的なむずかしさ”だと言えるでしょうね。(笑)

 

ということで、今回は、やや「おまけ」っぽい雰囲気が漂ってしまったように思いますが、次回からは、いよいよ、本編=第1章~第15章の読み解きに入っていこうと思います。もう既に「第6回」ということで、いったい何回連載になるのか良くわかりませんが、懲りずにお付き合いいただけましたら幸いです。

連載記事一覧は、コチラの最下段から

SERVICE