「許す」と「赦す」の件(みんな間違っている)
「シャルリー・エブド」誌の翻訳の問題がホットなようです。
私から見ると、みんな三者三様に間違っています。
(最初に書いておきますが、ここでは主に日本語表記について述べ、シャルリー・エブド誌の表紙という本題にはあまり触れません)
関口涼子氏の間違い
まず、関口涼子氏の間違いから。
Tout est pardonnéを、「すべては許される」とすることで、この読みの多様性が全て消えてしまう。
もうすでにあちこちで指摘されていますが、「許す」は「赦す」を含んでいます。
現代日本語で「許す」と「赦す」が排他的に使い分けられているなんていうことはありません。
で、こういうときには必ず、常用漢字(当用漢字)云々という人が出てきますが、それも誤解です。
そういう人の頭の中では、戦前の日本語は失われたエル・ドラド的なもので、その世界ではすべての書き分けが正しく(「正しく」とは?)行われていたというイメージなのかもしれませんが、全くそんなことはありません。
「ゆるす」に関して言うと、「許す」は昔から "pardonner(pardon)" の意味でも "permettre*1(permit)" の意味でも使われてきています。*2
本を読んでいれば当然わかることですが、そうでなくてもちょっと調べればわかることです。
例えば、菊池寛の訳した「后デルヴオルギラ(オーガスタ・グレゴリー)」に次のような部分があります。
もし書き分けが昔からされていたとしたら、ここは「赦す」を使っているはずのところです。
じゃあなぜ「許す」が使われているか。
単純に、明確な使い分けがなかったからです。
青空文庫で検索してみれば、このような用法はいくらでも見つかります。
もし私が亡友に対すると同じような善良な心で、妻の前に
懺悔 の言葉を並べたなら、妻は嬉 し涙をこぼしても私の罪を許してくれたに違いないのです。
ああ、許し給へ。どんなまづしい作家でも、おのれの小説の主人公をひそかに神へ近づけたがつてゐるものだ。
「それを半分だけ上げますから早く私を許して下さい」
関口涼子という人がどれほどのものかは知りませんが、これらは全部間違っているとでも言うのか、それともこれらは全部 permettre の意味だとでも言うのでしょうか。
それに、彼女自身が「許す」を pardonner の意味で使っているんですよね。
長い間の不和があり、それは実際には忘れられることも、許されることも出来ないかもしれない。
これは permettre では意味が通りません。
自分から、「許す」を(日本語の伝統に基づいて、正しく)pardonner の意味で使っているということです。
語るに落ちるではないですが、「書くに落ちる」とでもいうところでしょうか。
念のために付け加えると、「ゆるす」はほかの和語同様に昔から多様な表記があり、その中にはもちろん「赦す」も含まれていて、あえてその字を使う場合には「罪をゆるす」という意味で使われているというのは確かです。
しかし、「許す」との明確な使い分けが成立していた時代なんていうものはありません。
それは現代でも同じです。
「許す」が pardonner の意味で使われているから、「絶許(絶対に許さない)」のようなものがあるわけです。
(それとも、これも「絶赦」と書けとでも言うのでしょうか)
こういうわけで、関口氏が "Tout est pardonné" の訳にあえて「赦す」を使うのは自由ですが、「すべては許される」と訳したのを誤訳だというなら、それは間違いです。
しかし、じゃあ読売新聞には何の問題もないのかというと、それはまったく別の問題です。
読売新聞の間違い
"Tout est pardonné" を解釈するには、訳文ではなく原文のニュアンスを取る必要があります。
翻訳では、原文のニュアンスがどうやっても失われるものです。
原語がわからない人が、「すべては許される」という訳文から勝手に意味を取ってはいけません。
訳文にどの漢字を使ったら OK という問題ではありません。
いい例はないかと探してみたら、次のようなものがありました。
この絵本のタイトルは "Qui a éteint le soleil ?" ですが、これは直訳すると「誰が太陽を消したのか?」となります。
しかし、この「誰が太陽を消したのか?」という訳文から、「著者は太陽が消滅した世界を描くことで…」のようなことを書いてしまうと、とんでもない見当違いになってしまいます。
というのは、"éteindre" は「火・電灯などを消す」という意味であって、「消滅させる」ではないからです。
この場合、日本語ではどう頑張っても「消す」としか書けないので、原語を表記に反映させることはできません。
しかし、それは「誰が太陽を消したのか?」が誤訳ということではありません。
突き詰めると、すべての翻訳は誤訳であるということになってしまいます。
(それは一面の真実ではあるのですが)
元々、外国語の意味を正確に移すなんていうことは、平仮名で書こうが漢字で書こうが不可能です。
ですので、読売新聞の間違いは「すべては許される」と訳した段階ではなく、その訳文からニュアンスを推測したという段階です。
原文の表現について何かを言うためには原語の知識が必要だという、ごく当たり前のことです。*3
id:yuki_chikaさんの間違い
「許す」と「赦す」は同じ意味ですよというタイトルですが、これはもちろん間違いです。
私個人としては高島俊男先生のファンですし、面倒な書き分けを増やすのにも反対で、なぜ広まった? 「『訊く』が正しい」という迷信という記事を書いたぐらいですが、書き分けをしている人にはその人なりの意図があるというのが当然です。
私が反対しているのは、「ask の意味では必ず『訊く』と書くべきだ」というような、これまで存在したことのない厄介なルールを導入することであって、「訊く」を ask の意味で使うことは止めていません(というより、止められません)。
同様に、「pardonner の意味では必ず『赦す』と書くべきだ」なんてバカらしい主張には反対だというのが私の意見ですが、「赦す」と書く人は permettre ではなく pardonner という意味に限定しようとして使っているというのはあまり争いのない事実でしょう。
意見と事実は分ける必要があります。
高島先生の意見を敷衍すると、日本語の「ゆるす」は pardonner と permettre にわたる*4広い意味を持っているので、書き分ける必要はなく、平仮名で書くか、漢字で書くにしても「許す」という代表的な表記ですべて表すようにしたほうがいいということになるでしょう。
実際、高島俊男先生ご本人はあらゆる和語の書き分けに反対している(「取る」「採る」「捕る」「撮る」などを書き分けず、「とる」または「取る」と書く)ので一貫性はあるのですが、普通はそこまで振り切ることはできません。
現に、id:yuki_chika さんも「採る」という表記は使っています。
私は別に反知性主義を採るものではない。
「『ググレカス』が世界を変える」…のか? 自由と情報をめぐる議論
これは使い方としてはごく普通ですし、揚げ足取りが目的ではありません。
言いたいのは、高島先生のような強烈なキャラクタの人間でもなければ、現代に生きて日本語を使う以上、誰でもある程度の和語の書き分けはせざるを得ないということ、そして書き分けをする以上は「何を書き分けて何を書き分けないか」ということは難しい問題とならざるを得ないということです。
まとめ
- 読売新聞は、訳文から原文のニュアンスを推測するという間違いを犯しています。
- 関口涼子氏は、「すべては許される」を誤訳とするという間違いを犯しています(「すべては許される」という訳文を誤読している、と書けば間違いのないところです)。
- id:yuki_chikaさんは、「和語は書き分けるべきではない」という「意見」と、「和語の書き分けに意味はない」という「事実」を混同しています。
個人的には、シャルリー・エブドの真の意図についてはフランス語のわかる各個人が個別に判断すればいいことで、あまり意見はありません。
しかし、そこから派生した「ゆるす」の表記問題については黙っているわけにはいきません。
「今後この使い分けをしていこう」というならまだしも(もちろん私は個人的な意見として反対しますが)、「これまでにこういう使い分けがされている」という主張であれば、それは明確な嘘です。
ちょっと考えれば、これまでの日本語で、例えば「いくら謝っても赦してくれないんだよ」みたいな気持ち悪い書き方はほとんど見たことがないということぐらい、誰でもわかるはずのところです。
それにしても、予想できることですが、「許す」と「赦す」の書き分けが成立していると(事実に反して)思い込んでいる人が大量に湧いています。
上に挙げた夏目漱石や太宰治すらろくに読んでもいないくせに(あるいは、読んでも一瞬で忘れて)、ネットでそれっぽい漢字の書き分けを見ると1000年前から知っていたような顔をして得意げに書き込む頭の軽い人間ばかりのようです。
しかし、数からいうとそういう頭の軽い人間が圧倒的多数派でしょうし、今後それっぽい漢字の書き分けがどんどん増えていくのは、憂鬱ですが避けられないところかもしれません。
最近では、「笑う/嗤う」みたいな書き分けも頭の軽い人たちの間でかなり定着してきているみたいですし、次に出てくる新しい書き分け(個人的には「助ける/救ける/援ける…」あたりが来そうな気がしています)を1000年前から知っていたような顔をする準備をしておいたほうがいいかもしれないですね。
(まあ、そういう人は自然にそうしていると思いますが)
最後に、とってつけたように最近読んだ本へのアフィリエイトリンクを貼っておきます。
なぜ誤訳指摘をしたか
善意のひどい訳についてについての補足を書く。
まず、「なぜ指摘を公開でやったのか」ということから。
「アスペ日記」というタイトルで日記を書いてはいるけれど、「こんなふうに誤訳指摘したら気ぃ悪い(感じ悪い)*1よなぁ」ぐらいの感覚はぼくにもあった。
じゃあ、なぜそうしたか。
その理由を箇条書きしてみる。
この記事を書くことで、id:ymotongpoo さんの傷口に塩を塗るようなことになるかもしれないけれど、許してもらえればと思う。
1. 翻訳記事の読み方について考えるきっかけになると思った。
元記事は、ぼくが最初に見たときは100ブクマも行っていなかったと思うけれど、みるみるうちに伸びて、300ブクマを超えた。
あれだけ誤訳の多い記事が、ただ漫然と消費される様子に疑問を持った。
日本語だけ読んでもおかしなところがある(指摘箇所を見てもらえばわかると思う)翻訳なのに、みんな適当に目を滑らせて、何となくわかったつもりになって、それでいいのか?
誤訳を指摘することで、それに一石を投じてみたかった。
2. 体感英語力と翻訳の実力に乖離があると思った。
記事を見たあとで id:ymotongpoo さんについて調べてみると、東京大学の修士課程を修了し、Google で働いているらしいということがわかった。
ということは、英語の論文もそれなりに読んでいるだろうし、仕事でも毎日英語を使っているだろう。
そうなると、本人の体感英語力は相当高いだろう。
しかし、翻訳は明らかに誤訳が多い。
「英語を使って生きていく能力」と「英語を間違えずに解釈する能力」は別なんだろう。
これは気づきにくいことで、ぼくもあまり意識していなかった。
そのことについて書こうと考えていた(が、結果として元記事ではそこまで書けていない。推敲が足りなかった)。
3. 翻訳はコンパイルエラーのような形で誤訳がわからないから。
コードであれば、書いた内容に間違いがあれば、コンパイルエラーといった形でそれがすぐにわかる。
しかし、翻訳の場合、訳し間違いがあっても本人にはわからない。
だから、本人にわかる形でフィードバックをしようと思った。
これだけでは公開でやる理由にはならないが、4以降で補足する。
5. 誤訳箇所があまりにも多かったから。
これを最後に持ってくるのは本当に感じ悪いとは思うけれど、嘘をつくよりは実際のところを書く。
誤訳を指摘しようと思ったのは 4 までの理由だが、この誤訳密度で修正箇所を訳し直すと、原文の相当な割合を翻訳することになる。
それなら、ぶつ切れで翻訳するより、全体をいったん自分のバージョンとして訳し直したほうが楽だ。
それと突き合わせて誤訳を指摘することにした。
さて、そうなると訳し直したバージョンがもったいない。
日本語としてこなれてはいなくても、内容を理解して読めるものにはなっているはずだ。
それを公開することで、誰かの役に立つかもしれない。
この動機は、id:ymotongpoo さんが最初に公開された動機と同じだろう。
しかし、id:ymotongpoo さんを傷つけないということと、訳し直したバージョンを公開するということはどうしても両立しない。
それで、申し訳ないが後者を優先した。
それがアスペ的だと言われたらそうかもしれない。
言葉遣いについても配慮が足りなかったかもしれず、申し訳ない。
ところで、ぼくは「完璧な翻訳でなければ公開するな」とは言っていない。
ぼくだって完璧な翻訳なんてできない。
でも、5ページ(PDF版)の文章に(修正箇所を含めると)32箇所の誤訳というのはちょっと多いんじゃないかと思った。
普段から、(引き合いに出して申し訳ないが)江添氏の翻訳などは読んでいるが、そこまでのことは普通はない。
ところで、この件に関しては非常に不愉快なことがあった。
で、この人達は原著者の許可は取ったんだよね?
善意のひどい訳について - アスペ日記 / http://t.co/xfxxYZF9Fy
— らくだの卯之助 (@camloeba) 2014, 10月 13
へぇぇ。
このタイミングで言うんですか。
「この人達」って、id:ymotongpoo さんとはつながってるんだから、その前に記事がバズってたときにいくらでも言う機会があったと思うんですけどねぇぇぇ。
これが、アスペでない人間にはあるという雰囲気を読む能力ですか。
いやぁ、ついていけないっすわ。
(吐瀉音)
100%正しい翻訳というものがありえない以上、公開ドキュメントであっても翻訳をし公開するのであれば原著者の許可が必要かと思います。原著者の意向を歪める事を極力避けたいことを強調されるこのブログの方はもちろん許可を取っておられると信じますが…
— らくだの卯之助 (@camloeba) 2014, 10月 13
>原著者の意向を歪める事を極力避けたいことを強調されるこのブログの方は
>原著者の意向を歪める事を極力避けたいことを強調されるこのブログの方は
>原著者の意向を歪める事を極力避けたいことを強調されるこのブログの方は
すごい!!!
こう書けば、仲間は非難せずにぼくだけを倫理的に非難できると。
高等技っすねぇ。
(吐瀉音)
ぼくは確かに雰囲気を読む能力が欠けているところがあるので、日常生活での行動は周りの常人を見習ってやっている。
道路標識に50キロ制限と書いてあっても、周りの車が時速70キロで走っていたら時速70キロで走る。
そんな感じだ。
例の記事も、かなり古い伝説的な文書で、元記事の人が何も書かずに翻訳していて、300ブクマぐらいの間誰にもツッコミを入れられていないので、あぁ人間的にはこれはオッケーなのかなと思ってぼくもそのまま公開した。
いやぁ、しかしまさかぼくだけ倫理的に非難する裏技があったとは。
そこまでは思いつかなかったなぁ。
で、調べてみるとこのファイルはPlan 9のソースに含まれているようで、Lucent Public License version 1.02 が適用されるようだった。
一応追記しておいた。
id:ymotongpoo さんも追記しておいたほうがいいかもしれないですね。
いやぁ、ゴミが同じことをしたせいで手間をかけさせて申し訳ないですね。
*1:関西に住むうちに中途半端に関西弁がうつった。
善意のひどい訳について
2014/10/14 追記: 補足記事を書きました。なぜ誤訳指摘をしたか
ぼくは、ずっと昔から「ひどい翻訳」というものに憤りを感じてきた。
以前、別の記事に書いたこともある。
統計学を拓いた異才たちのようなひどい翻訳を見るたびに、どうして世の中からはこの手の悲劇がなくならないのかとため息が出る。
この前、またひどい翻訳を目にする機会があった。
ちょっと原文と比較すると致命的な誤訳がいくつも見つかる、最低クラスの翻訳だ。
やれやれと思いながら、翻訳のひどさを嘆くコメントをはてブに残して、ツイッターに流した。
日常の一コマだ。
ここでちょっといつもと違う流れになったのは、訳者の方からリプライをもらったということ。
@takeda25 はじめはいわゆるpretty printerだと思っていましたが、後でインクがどうのこうの言ってるので、当時のプログラムを印字していた話だと読みなおしましたが、この場合文意とどうつながらないか、ご指摘いただければ幸いです
そういえば今はネット時代なんだから、誤訳指摘が訳者の目にもとまるというのは十分ありうることだ。
その後リプライを通して、誤訳を 2箇所直してもらった。
普通の流れなら、ここで一件落着、みんなハッピーというところだ。
でも違う、そうじゃない。
誤訳は 2箇所 どころじゃない。
ちゃんと指摘すると、何箇所になるかわからないぐらいあるんだ。
統計学を拓いた異才たちを読んだとき、あまりに翻訳がひどいので原書(おすすめです)を買って読んで、和訳の誤訳箇所に付箋を貼ろうとしたことがある。
しかし、最初の数ページまで見たところで付箋だらけになってしまい、不毛な気持ちになってあきらめた。
でも今回は、量が少ないこともあるので、「誤訳の全指摘」をやってみることにした。
ひどい翻訳というものにはどれだけの誤訳があるものかを示したかったし、自分でも興味があった。
自分でも全文を翻訳してみて、それと比べながら指摘箇所をまとめた。
すると、誤訳は(指摘済みの2箇所のほかに)30箇所あった。
誤訳指摘は別記事にまとめた。
ちなみに、ぼくの参考訳はこちら。
今回の件で、ひどい翻訳というものについて真剣に考えることになった。
これまで、ひどい翻訳を見ると、無意識のうちにそれを何らかのモラルの欠如によるものだと思っていた。
ろくに英語を勉強していない人が身の程知らずに翻訳しているか、手抜きで翻訳を見直しもしないとか。
だから、ひどい翻訳を見るといつも怒りを感じていた。
しかし、今回の翻訳を出した id:ymotongpooさんは明らかに紳士的な人で、人間としても技術者としてもすばらしい人のようだった。
ツイッターで話してみると真面目に考えて訳されたようで、調べてみると外資系企業で普段から英語を使って仕事をされているらしい。*1
マニュアルの翻訳や書籍の翻訳もされているようだ。
でも、背景はともかく、例の翻訳はあまりにもひどい。
コードの質が、誰が書いたかではなくどう書かれているかで判断されるように、翻訳の質も、誰が訳したかではなくどう訳されているかで判断するべきだと思う。
例の翻訳も、ぼくの翻訳も、さらっと読んだ感じの印象はあまり変わらないかもしれない。
翻訳の質というのは、それほど重要じゃないのかもしれない。
それでもぼくは、誤訳の多い翻訳はよくないと思っている。
理由は主に二つ。
- 文章をきちんと読むという習慣を阻害する。
- 著作物のアイデンティティの問題。
一つ目の「文章をきちんと読むという習慣を阻害する」というのは、そういう誤訳だらけの文章を読んでいると、一字一句をちゃんと理解して読もうとするとつまずいてしまうからだ。
例えば、元の翻訳の次の部分。
if(goleft) p->left=p->right->left; else p->right=p->left->right;
p
の複合的な使い方をしているこのコードが何をしているかを考えてみましょう。
ここでの「このコード」はただの例だ。
「何をしているか」を考えてもしょうがない。
でも、「きちんと読む」ということをしようとしてしまうと、ここで引っかかってしまう。
ちなみに、ぼくの翻訳は次のようなものだ。
次のコードで、もし p の代わりに複合式を使っていたらどんな見た目になるか考えてみてください。
二つ目の「著作物のアイデンティティの問題」というのは、「その訳文は、そのタイトルに値するのか?」ということ。
「統計学を拓いた異才たち」を読んだ人は、"The Lady Tasting Tea"と同じ本を読んだと言えるのか?
「C言語でプログラミングする際の覚書」を読んだ人は、"Notes on Programming in C"を読んだと言えるのか?
どちらも、訳文の意味の通らないところを読んで、読者が「この著者の書く文章はわかりにくいな」と思ってしまうかもしれない。
ひどい翻訳というのは、機械翻訳よりはずっとましかもしれないが、そういう点で危険だ。
機械翻訳なら、原著者がわかりにくいことを書いたとは思わないだろう。
いろいろ悪く書いたけれど、それはあくまで訳文に対するもので、人格攻撃ではない。
翻訳というシステムがもっとうまく動くようになってくれればいいと願っている。
原文を読めばいいと言う人もいるかもしれないが、外国語を読むのには時間がかかる。
ぼくは速いほうだとは自負しているけれど、それでも日本語に比べるとだいぶ遅くなる。
技術翻訳は残念なものが多いが、文芸翻訳は平均して質が高いと感じる。
翻訳で読んだ本には、すばらしいものがいくつもある。
ここではお気に入りを二つ挙げる。
どちらも翻訳でも原文でも読んだけれど、誤訳はほとんどなかった。*2
何百ページもある本をほとんど誤訳なしに訳すのだから、考えてみるとすごいことだ。
技術翻訳も、専業の翻訳者との連携でできたらいいんじゃないかと思う。
専門知識のない翻訳者でも、技術文書の翻訳で助けになれるところは多いはずだ。
例えば、
a naming convention from which np means ``node pointer'' is easily derived.
の "which" が関係代名詞であること、
parsing tables, which encode the grammar of a programming language
の "parsing tables" が動詞-目的語構造ではなく全体でひとつの名詞句であることを読み取るのに、プログラミングの知識は必要ない。
それは英語自体から読み取れる。
英語(外国語)の構文を間違えずに読むというのは、ひとつの能力だ。
翻訳には、分野の専門知識と同じぐらい、外国語を読む能力が必要だ。
(その能力のない)技術者が単独で翻訳をすると、分野の専門知識を何も知らない翻訳者が単独で翻訳するのと同じぐらい悲惨なことになる。
しかし、専門知識のない翻訳者が単独で技術書を翻訳することはあまりないのに、英語(外国語)の読めない技術者が単独で技術書を翻訳するというのは、ずっとよくあることだ。
「翻訳」ということの本質的な困難さが認識されて、後者が前者と同じぐらいひどいことだという認識が広まってほしいと思っている。
ところで、id:ymotongpoo さんが「すごいErlangゆかいに学ぼう!」を翻訳されたときはGitHubのプライベートリポジトリなどでされたそうだ。
この書籍はまだ拝見していないが(そのうち読んでみたい)、多くのレビュアーによって質の高いものになっていることと思う。
こういう体制が普及していけば、例えば専業翻訳家との連携のようなこともやりやすくなって、統計学を拓いた異才たちのような「英語の読めない専門家によるひどい翻訳がそのまま書籍になってしまう」という悲劇が起こらなくなるんじゃないかと期待している。
後記1 この記事の中では「統計学を拓いた異才たち」を非常に悪く言っているが、この訳書はそれに値するものだと思っている。仕事になるのであれば、その数百箇所にのぼるであろう誤訳を全指摘したいところだ。
後記2 「じゃあお前は何を翻訳したんだ」と言われるかもしれない。ぼくはこれまで翻訳はあまりしていない。そのことはこの記事の主張とは関係ないと思うが、いま少しずつ手をつけているものはある。公開できるところまで行ければいいと思う。
「C言語でプログラミングする際の覚書」の誤訳箇所
ここでは、C言語でプログラミングする際の覚書の誤訳を列挙します。
参考として、私の翻訳はC言語プログラミングの覚え書き(改訳)にあります。
What follows is ...
×従うべきは
○これから述べるのは
"What follows" で「続くもの」という意味です。ここでの「続く」というのは、現在の文章に続く、つまり「以下に述べること」です。
But they've been accumulating in my head, if not on paper until now, for a long time, ...
×しかし、私の意見は頭のなかにしばらくあったものをまとめたものであり、長らく文章として公開してきませんでした。
○しかし、これらのことは、文書として書いたことはありませんでしたが、私の頭の中に長い時間をかけて蓄積してきたもので、…
"if not on paper until now" これは、"in my head" との対比です。「頭の中にはあったが、文書にしたことはない」という意味です。また、"for a long time" は "they've been accumulating in my head" にかかります。
I've yet to see a good essay on how to plan the whole thing,
×これまでプログラム全体の計画に関しての良い文章は読んだことがありますが、
○全体を計画する方法についてのよいエッセイを読んだことはありませんが、
"yet to" は「まだ…していない」という意味です。文意が完全に逆になっています。
a clear program is not made any clearer by such presentation
×明瞭なプログラムはそのような見た目で成されるものではなく
○明瞭なプログラムはそんな表示をしてもそれ以上明瞭にはなりませんし
"not made any clearer" は「さらに明瞭にはならない」ということです。
... is more to type (or calls upon your text editor)
×タイプ量(あるいはエディタ内で呼ばれる回数)が増え
○タイプ量が増える(または、エディタの助けを求める)ことになりますし
"call (up)on" は「頼る」という意味です。
if you consistently use a naming convention from which np means ``node pointer'' is easily derived
×どの np が "node pointer" を意味しているかがすぐに分かる命名規則を一貫して使っていれば
○np が "node pointer" を指しているということが簡単に導けるような命名規約を一貫して使っていれば
"from which" の "which" は "naming convention" を指しています。
As in all other aspects of readable programming, consistency is important in naming.
×プログラムの可読性に関していえば、命名において一貫性は重要です。
○プログラムの可読性に関するほかの側面での場合と同じように、命名においても一貫性は重要です。
元の翻訳では "As in all other aspects" が訳されていません。
I prefer minimum-length but maximum-information names
×私は最短の名前ではなく最も情報量がある名前を好み
○私は最短の長さで最大の情報量のある名前を好み
「最短であるが、しかし最大の情報量を持つ」という意味です。
They jangle like bad typography.
×悪い印刷のように目障りなのです。
○ひどい表示の仕方と同じように目障りなのです。
最初は、全篇を通して "typography" が「印刷」と訳されていたと思うのですが、その名残でしょうか。
Pointers are sharp tools
×ポインタは賢い道具で
○ポインタは切れ味の鋭い道具で
文字通りの意味です。「賢い」では、あとの「使い方を間違えると…」とつながりません。
If we want the next element's type
×もし次の要素の型が必要な場合は
○もし次の要素の type が必要であれば
原文で type がコード用フォントになっていませんが、文脈から構造体の要素名であることが明らかです。
less effort is expended by the compiler and computer
×コンパイラやコンピュータが展開する労力も減ります
○コンパイラやコンピュータの費やす労力も減ります
"expend"(費やす)を "expand"(展開する)と間違えたのでしょう。
which allows some helpful compile-time error checking that array indices cannot share
×これでコンパイル時に配列のインデックスが適切で無い旨のエラー検出が可能になります。
○配列の添字と違ってコンパイル時の便利なエラー検出が利用できます。
"array indices cannot share" の "share" は、「同じく持つ」という意味です。配列の添字ではエラー検出ができないということです。意味が取れておらず、つじつま合わせになっています。
As a rule
×ルールとして
○だいたいの場合
熟語です。
expressions that evaluate to elements of a data structure
×データ構造の要素を評価するような…データ構造
○データ構造の要素として評価される式
ここでの "evaluate to" は、「評価されることによって…になる」という意味です。
Consider what ... would look like using a compound expression for p
×p の複合的な使い方をしているこのコードが何をしているかを考えてみましょう
○もし p の代わりに複合式を使っていたらどんな見た目になるか考えてみてください
「p の代わりに複合式(例えば、node[i] など)を使ったらゴチャゴチャした見た目になる」ということです。元の訳では意味不明です。
Sometimes it's worth a temporary variable (here p) or a macro to distill the calculation.
×時には一時変数(この場合は p )を使用したり、計算の本質を抜き出すマクロを使用する価値があります。
○計算の本質を抜き出すには、時には一時変数(ここでは p)やマクロを使うことが役に立ちます。
「一時変数」と「マクロ」は並列です。
Procedure names should reflect what they do; function names should reflect what they return.
×プロシージャ名はそれが何をするかを反映すべきです。つまり関数名はそれが何を返すかを反映すべきです。
○プロシージャ名は、それが何をするかを表しているべきです。関数名は、それが何を返すかを表しているべきです。
原文にない「つまり」があるために、実際にはない論理的関係があるかのように見えてしまいます。
A delicate matter, requiring taste and judgement.
×慎重に、経験と判断をもって書く必要があります。
○これはセンスと判断力が必要となる難しい問題です。
コメントの「書き方」ではなく、「コメントを書くこと(書くかどうかを含め)」全体に対するものです。
a symbol table might be implemented ...
×シンボルテーブルは…として実装されているでしょう
○シンボルテーブルは…として実装されるかもしれません
"might" はかなり弱い意味です。
Algorithms, or details of algorithms, can often be encoded compactly, efficiently and expressively as data rather than, say, as lots of if statements.
×アルゴリズム、つまりアルゴリズムの細かな部分は、しばしばデータという簡潔で、効率的で、表現豊かな形に記号化されます。それは、たとえば、多くのif文という形ではありません。
○アルゴリズムや、アルゴリズムの細かいところは、たくさんの if 文のようなもので書くよりも、データとして書いたほうが、効率よく強力に記号化することができることがよくあります。
元の訳は、日本語としてよくわからないものになっています。
A classic example of this is parsing tables, which encode the grammar of a programming language in a form interpretable by a fixed, fairly simple piece of code.
×古典的な例で言えば、表のパースです。これはプログラミング言語の文法を、定形のかなり単純なコード片によって説明可能な形式に記号化することです。
○典型的な例としては、パージングテーブルというものがあります。プログラミング言語の文法を、定型のかなり単純なコードによって解釈できる形に記号化したものです。
"parsing tables" は全体でひとつの名詞です。動詞-目的語ではありません。また、"interpretable" はコードによって「解釈」できる、つまり読み込んでそれに従って動作できるという意味で、「説明」ではありません。
Finite state machines are particularly amenable to this form of attack
×特にこのような問題に取り組むときには有限状態機械が採用されていますが
○この手のやり方としては有限状態機械が特に柔軟に使えますが
"amenable" は「従順な」、つまり「柔軟に使いやすい」ということです。
can be constructed profitably as a data-driven algorithm
×生産的な形としてデータ駆動のアルゴリズムになります
○データ駆動アルゴリズムにすることでいい結果が得られるでしょう
"profitably" は、「利益が得られるような形で」というニュアンスです。
One of the reasons data-driven programs are not common, at least among beginners, is the tyranny of Pascal.
×データ駆動プログラムが一般的でない理由の一つは、少なくとも初心者においては、Pascalによる圧政でしょう。
○データ駆動プログラムが(少なくとも初心者の間で)一般的でない理由のひとつは、Pascalの独裁です。
"at least among beginners" は前にかかります。
This flies in the face of the theories of Turing and von Neumann
"fly in the face of" は「真っ向から対立する」です。これは私も調べたところなのですが、「ここはたぶん熟語じゃないか」というセンスが必要です。適当に訳をでっち上げるのはよくありません。
I cannot recommend an implementation style more highly
×より高度な次元の実装方法を推奨することはできません
○これほどお勧めできる実装スタイルはありません
"highly recommend" という組み合わせはよく聞くものですが、"recommend ... more highly" はその比較級です。「それ以上お勧めできない」、つまり「とてもお勧めできる」ということです。
Maybe that's it:
×以上です。
○きっとこういうことなのでしょう。
これは ":" に続くものに対しての文です。
by construction
×ビルド時に
○組み立て方によって
「組み立て方を工夫することで(多重インクルードを避けられる)」程度の意味です。
but it's usually done wrong in practice
×普通は間違った結果となります
○実際には正しく運用されないものです
"in practice" 実際にやってみると、"done wrong" 悪いやり方で行われる、という意味です。元の訳ではなぜ「間違った結果」になるのかわかりません。
C言語プログラミングの覚え書き(改訳)
Rob Pike
1989年2月21日
Copyright (C) 2003, Lucent Technologies Inc. and others. All Rights Reserved.
Lucent Public License Version 1.02
前書き
KernighanとPlaugerによる“The Elements of Programming Style” (「プログラム書法」木村泉訳)は重要で影響力のある本です。この本にはそれだけの価値があります。しかし、その中の簡潔なルールが、本来意図されたような哲学の簡潔な表現としてではなく、よいスタイルのレシピとして受け取られているように私は時々感じます。この本が変数名は意味を持つようにつけられるべきだと言うなら、名前が使い方を説明するちょっとしたエッセイのようなものであるほうがいいということになるのでしょうか。MaximumValueUntilOverflow
は maxval
よりもいい名前ということになるのでしょうか。私はそうは思いません。
これから述べるものは、融通の利かないルールではなく、全体としてプログラミングの明確さという哲学を促進するような短いエッセイ集です。すべてに同意してもらおうとは思いません。これらは意見であり、意見は時とともに変わるものだからです。しかし、これらのことは、文書として書いたことはありませんでしたが、私の頭の中に長い時間をかけて蓄積してきたもので、多くの経験に基づいています。そのため、これがプログラムの詳細を計画する方法についての理解の助けになればと願っています(全体を計画する方法についてのよいエッセイを読んだことはありませんが、この文章は一部それについて書いています)。もし変わっていると思われても、問題ありません。同意できないとしても、問題ありません。しかし、なぜ同意できないかを考えていただくきっかけになれば、そちらのほうが望ましいことです。決して、私がこう言ったからこう書くということをしないでください。プログラムの中で達成したいことを最もよく表現できるとあなたが考えるようにプログラムしてください。また、それを一貫して、容赦なく行ってください。
あなたのコメントをお待ちしています。
表示の問題
プログラムは出版物のようなものです。プログラムはプログラマ自身やほかのプログラマ(それは数日後、数週間後、数年後のあなた自身かもしれません)に読まれるもので、そして最後に機械に読まれるためのものです。機械は、プログラムの見た目の美しさを気にしません。プログラムがコンパイルできれば、機械はそれで満足です。しかし、人間は美しさを気にしますし、気にするべきです。時々、やりすぎになることもあります。プリティプリントを行うプログラムは、プログラムのどうでもいい細かいところを強調するようなきれいな出力を自動的に行います。これは文章の助詞をすべて太字で表示するのと同じぐらい馬鹿らしいことです。プログラムはAlgol-68 Reportのような見た目じゃないといけない(システムによってはそのスタイルでプログラムを編集するよう強制したりもします)と考える人は多いですが、明瞭なプログラムはそんな表示をしてもそれ以上明瞭にはなりませんし、ひどいプログラムは笑ってしまうような結果になるだけです。
もちろん、表示についての一貫した規約は見た目をわかりやすくするためには重要なものです。インデントは、最もよく知られた、最も役に立つ例でしょう。しかし、見た目がプログラムの意図より目立つようでは、表示が主体になってしまっていることになり、本末転倒です。ですから、古き良きタイプライター的出力で通すにしても、表示上の馬鹿げたやり方には気をつけましょう。装飾を避けましょう。例えば、コメントは簡潔に、バナーをつけないようにしましょう。言うべきことはプログラムの中で、簡潔に一貫性を持って言いましょう。それから次に進みましょう。
変数名
そう、変数名です。名前で重要なのは、長さではありません。重要なのは表現の明確さです。めったに使われないようなグローバル変数であれば、長い名前をつけてもいいかもしれません。例えば、maxphysaddr
のように。ループ内のすべての行で使われるような配列の添字には、i
よりも凝った名前は必要ありません。index
や elementnumber
といった名前をつけるのは、タイプ量が増える(または、エディタの助けを借りる)ことになりますし、計算の詳細よりも目立ってしまいます。変数名が非常に長くなると、何をしているのかわかりにくくなります。これは、表示の問題の一部でもあります。次の二つについて考えてみましょう。
for(i=0 to 100) array[i]=0
for(elementnumber=0 to 100) array[elementnumber]=0;
実際の例では、問題はもっとあっという間にひどいことになります。添字はただの記法です。そのように扱いましょう。
ポインタもちゃんとした記法が必要です。np
が "node pointer" を指しているということが簡単に導けるような命名規約を一貫して使っていれば、np
は nodepointer
と同じぐらい覚えやすいものになります。これについては次のエッセイで詳しく書きます。
プログラムの可読性に関するほかの側面での場合と同じように、命名においても一貫性は重要です。ある変数に maxphysaddr
という名前をつけたら、同種の変数に lowestaddress
という名前をつけてはいけません。
最後になりますが、私は最短の長さで最大の情報量のある名前をつけ、残りは文脈から補完できるようにしています。例えば、グローバル変数は普通、使用時にあまり文脈がないので、名前は比較的内容がわかりやすいようなものである必要があります。このため、私はグローバル変数には maxphysaddr
(MaximumPhysicalAddress
ではありません)という名前をつけますが、ローカルで定義して使うポインタには NodePointer
ではなく np
という名前をつけます。これは感覚によるところが大きいですが、感覚は明瞭さに関わってくるものです。
名前に大文字を入れることは避けています。散文調の文章に慣れた私の目には、大文字は不格好で快適に読めません。ひどい表示の仕方と同じように目障りなのです。
ポインタの使用
C はポインタが何でも指せるという点で変わっています。ポインタは切れ味の鋭い道具です。切れ味の鋭い道具というものは、うまく使うと楽しく生産的になりえますが、間違った使い方をするとひどい傷をつけます(この記事を書く数日前に、私は彫刻刀を親指に刺してしまったところです)。ポインタも例外ではありません。ポインタは危険すぎる、何か汚いものだと思われているため、学術界での評判はよくありません。しかし、私はポインタは強力な記法だと考えています。これは、ポインタは明瞭な表現をする役に立つということです。
考えてみてください。あるオブジェクトに対するポインタがあるとき、それはまさにそのオブジェクトに対する名前であって、ほかのものではありません。些細なことのようですが、次の二つの式を見てください。
np node[i]
一つ目はノードを指していて、二つ目は同じノードを指すように評価されます(ということにします)。しかし、二つ目の形式は式です。あまり単純なものではありません。解釈するには、node
が何か、i
が何か、そして i
と node
がその周りのプログラムの(おそらく明記されていない)ルールによって関連づけられているということを知る必要があります。式だけを取り出してみると、i
が node
の有効な添字なのかを知る手がかりはありません。もちろん、望む要素を指す添字なのかもわかりません。もし i
と j
と k
が全部ノードの配列の添字だとすると、簡単にうっかりミスをしてしまいます。その場合、コンパイラは助けてくれません。特に、サブルーチンに渡すときには間違いを犯しやすくなります。ポインタは単純なひとつのものですが、配列と添字は、それがセットとなるものであることを受け取るサブルーチンのほうで信用しないといけません。
オブジェクトとして評価される式は、本質的にそのオブジェクトのアドレスよりもわかりにくく間違いやすいものになります。ポインタは、正しく使うことでコードを単純にできます。例えば、
parent->link[i].type
と
lp->type
です。
もし次の要素の type が必要であれば、
parent->link[++i].type
と
(++lp)->type
になります。
i
は値が進みますが、式の残りはそのままです。ポインタの場合、進めるものはひとつしかありません。
ここでも表示の問題が絡んできます。ポインタを使って構造体の中を読み進めるのは、式を使うよりもずっと読みやすいものになります。インクの使用量も減りますし、コンパイラやコンピュータの労力も減ります。関連した問題として、ポインタの型はその正しい使い方と関係しているので、配列の添字と違ってコンパイル時の便利なエラー検出が利用できます。また、オブジェクトが構造体であれば、フィールドは型を思い出す役に立つので、次のようなものは十分に意味がわかります。
np->left
添字によって配列を使う場合、配列はきちんと選んだ名前を持つことになり、式は長くなってしまいます。
node[i].left
ここでもまた、例が大きくなれば余分な文字はどんどん厄介なものになっていきます。
だいたいの場合、もしあなたのコードに似たような複雑な式がたくさんあって、それらがデータ構造の要素として評価されるなら、ポインタを注意深く使うことですっきりさせることができます。次のコードで、
if(goleft) p->left=p->right->left; else p->right=p->left->right;
もし p
の代わりに複合式を使っていたらどんな見た目になるか考えてみてください。計算の本質を抜き出すには、時には一時変数(ここでは p
)やマクロを使うことが役に立ちます。
プロシージャ名
プロシージャ名は、それが何をするかを表しているべきです。関数名は、それが何を返すかを表しているべきです。関数は式の中で使われるもので、if
のようなものの中でよく使われます。そのため、適切に読めるようになっている必要があります。
if(checksize(x))
は不親切です。checksize
がエラーのときに true を返すのか、エラーでないときに true を返すのかが推測できないからです。それに対して、
if(validsize(x))
はその点を明確にしているので、将来そのルーチンを使うときに間違いが起こりにくいでしょう。
コメント
これはセンスと判断力が必要となる難しい問題です。私は、いくつかの理由から、コメントをあまり書かないようにしています。ひとつは、もしコードが明確で、よい型名や変数名を使っているなら、コード自身が説明になっているはずだからです。それに、コメントはコンパイラにチェックされないので、正しいという保証がないからです。特に、コードが変更されたあとはそうです。ミスリーディングなコメントは非常に紛らわしいものです。最後に、表示の問題です。コメントはコードをごちゃごちゃにしてしまいます。
しかし、私も時々はコメントを書きます。ほとんどの場合、その次に続くことの説明として使っています。例を挙げると、グローバル変数と型の説明(この場合だけは、大きなプログラムでは必ずコメントを書きます)、あまり見ないプロシージャや非常に重要なプロシージャの紹介、大きな計算セクションの区切りなどです。
有名な悪いコメントというものがあります。
i=i+1; /* i に 1 を足す */
そのもっと悪いやり方もあります。
/********************************** * * * i に 1 を足す * * * **********************************/ i=i+1;
笑うのは早いですよ。笑うのは、実生活で出会ってからでも遅くありません。
コメントでは、かっこいい表示を避けましょう。中心となるデータ構造の宣言のような重要なところは例外としてもいいでしょうが(データに対するコメントは、普通アルゴリズムに対するコメントよりもずっと役に立つものです)、コメントの大きな塊を避けましょう。基本的に、コメントを避けましょう。もしコメントがないと理解できないようなら、理解しやすくなるように書き直したほうがいいでしょう。ここで、次の問題が出てきます。
複雑さ
ほとんどのプログラムは複雑すぎます。つまり、問題を効率的に解くのに必要な以上に複雑だということです。なぜでしょうか。多くの場合、それは設計の悪さが原因ですが、その問題は大きすぎるのでここでは飛ばします。しかし、プログラムは細かいレベルでも複雑すぎることが多いもので、そのことについてはここで書くことができます。
ルール1 プログラムがどこで時間を使うかはわかりません。ボトルネックは驚くような場所で起こるので、ボトルネックの場所を証明できるのでなければ、適当な推測で高速化ハックを入れるのはやめましょう。
ルール2 計測しましょう。計測なしに速度のチューニングをしないでください。計測した場合でも、コードの一箇所がほかの場所に比べて圧倒的に時間がかかっているのでなければ、チューニングはやめましょう。
ルール3 かっこいいアルゴリズムは、n が小さいときには遅いものです。そして、n は普通小さいものです。かっこいいアルゴリズムは大きな定数項を持っているものです。n がよく大きな値になるとわかっているのでなければ、かっこいいことをするのはやめましょう(n が大きくなる場合でも、まずルール2 を使いましょう)。例えば、日常業務の問題では、二分木は常にスプレー木より速いものです。
ルール4 かっこいいアルゴリズムは単純なアルゴリズムよりもバグが起こりやすく、実装が難しいものです。単純なアルゴリズムと単純なデータ構造を使いましょう。
ほとんどの実用的なプログラムでは、次に挙げるリストのデータ構造があれば十分です。
- 配列
- 連結リスト
- ハッシュテーブル
- 二分木
もちろん、これらを組み合わせて複合データ構造を作る覚悟は必要です。例えば、シンボルテーブルは文字の配列の連結リストを含むハッシュテーブルとして実装されるかもしれません。
ルール5 重要なのはデータです。もし正しいデータ構造を選び、物事をうまくまとめれば、アルゴリズムはたいてい自明なものになります。プログラムの中心は、アルゴリズムではなく、データ構造です。(詳しくは「人月の神話」を参照してください)
ルール6 ルール6はありません。
データでプログラムする
アルゴリズムや、アルゴリズムの細かいところは、たくさんの if
文のようなもので書くよりも、データとして書いたほうが、効率よく強力に記号化することができることがよくあります。その理由は、手元の仕事の複雑さが独立した細かい部分の組み合わせによるものであれば、記号化できるからです。典型的な例としては、パージングテーブルというものがあります。プログラミング言語の文法を、定型のかなり単純なコードによって解釈できる形に記号化したものです。この手のやり方としては有限状態機械が特に柔軟に使えますが、何らかの抽象的な入力を「パージング」して何らかの独立した「アクション」列にするようなプログラムであれば、どんなものであってもデータ駆動アルゴリズムにすることでいい結果が得られるでしょう。
このような設計のおそらく最も興味深い側面は、テーブルがほかのプログラムによって生成されることもあるということです。典型的な例でいうと、パーザジェネレータがあります。もう少し身近な例としては、OSがI/Oリクエストを適切なデバイスドライバに割り当てるテーブルによって動いている場合、マシンに接続されたデバイスについての記述を読み込んで対応するテーブルを表示するようなプログラムで「設定」できるでしょう。
データ駆動プログラムが(少なくとも初心者の間で)一般的でない理由のひとつは、Pascalの独裁です。Pascalは、その作者同様、コードとデータを分割することを固く信じています。そのため、(少なくとも元の形では)初期化されたデータを作ることができません。これは、プログラム内蔵方式の原則を定義したチューリングやフォン・ノイマンの理論に真っ向から喧嘩を売っています。コードとデータは同じものです。少なくとも、同じにすることができます。そうでなければ、コンパイラがどうして動くのか説明できないでしょう。(関数型言語はI/Oに関して同じような問題を抱えています)
関数ポインタ
Pascalの独裁の結果には、初心者が関数ポインタを使わないということもあります(Pascal では関数を値に持つ変数を使えません)。複雑さを記号化するために関数ポインタを使うことには、いくつかの面白い性質があります。
複雑さの一部は、ポインタの指すルーチンに渡されます。ルーチンは、同じように呼び出されるルーチンセットのひとつとなるので、何かしらの標準プロトコルに従う必要があります。しかし、それより重要なのは、ルーチンが自分の責任範囲のことしかしないということです。複雑さは分散されることになります。
このプロトコルという考え方は、同じような使われ方をする関数は同じようなふるまいをしなければならないというものです。このことが、ドキュメントの記述やテスト、プログラムの発展をやりやすくしています。さらには、プログラムをネットワーク越しに動かすこともやりやすくなります。プロトコルは、リモートプロシージャコールとしても記号化できるのです。
私の主張は、オブジェクト指向プログラミングの核心となるものは、関数ポインタを明確に使うことだというものです。データについて実行したい操作セットがあり、それらの操作に対して適用したいデータ型のセットがあるなら、プログラムをまとめる一番簡単な方法は、それぞれの型に対して関数ポインタのグループを使うというものです。これは、一言で言うと、クラスとメソッドを定義するということです。もちろん、オブジェクト指向言語にはそれ以上のものがあります。きれいな構文、派生型など。しかし、概念的には、ほとんど変わるところはありません。
データ駆動プログラムと関数ポインタを組み合わせると、びっくりするほど表現力のある書き方ができるようになり、私の経験では、意外な喜びをもたらしてくれることもよくありました。特別なオブジェクト指向言語なしでも、余計な手間なしでオブジェクト指向のいいところの90%を手に入れることができ、結果についても自分でコントロールしやすくなります。これほどお勧めできる実装スタイルはありません。この方法で構築してきたプログラムは、かなりの開発を重ねてもうまく生き残っています。もっとゆるいやり方の場合よりも、ずっといい結果です。きっと、この手法に求められる規律は、長い目で見ると割に合うということでしょう。
インクルードファイル
単純なルールです。インクルードファイルはインクルードファイルを決してインクルードしてはいけません。その代わりに、どのファイルを先にインクルードするべきかが(コメントで、または暗黙的に)言明されていれば、どのファイルをインクルードするべきかという問題はユーザ(プログラマ)に押しつけられますが、ある意味では扱いやすく、組み立て方によって多重インクルードを避けることができるようになります。多重インクルードはシステムプログラミングの癌です。ひとつの C のソースファイルをコンパイルするのに、5 回以上もインクルードされるファイルがあることは珍しいことではありません。この面から言うと、Unix の /usr/include/sys
はひどいものです。
#ifdef
を使ってファイルが 2 回読まれないようにする小手先のテクニックがありますが、実際には正しく運用されないものです。#ifdef
はファイル自身の中にあり、インクルードする側にあるのではありません。結果として、何千行もの不要なコードが字句解析器に渡されることになってしまいます。これは、(良いコンパイラの場合)最も負荷の高いフェーズになってしまいます。
単純なルールに従いましょう。
片付けを始めるコツ
個人的にうまくいった、「片付けを始めるコツ」について書いてみます。
ぼくと同じタイプの人間向けです。
概要を箇条書きにすると、次のようになります。
- 限られた回数の「片付け動作」をする。
- リラックスする。
以上の繰り返しです。
「片付け動作」とは何か。
これは、片付けを進める動作であれば何でもOKです。
例えば、本Aを本Bの上に重ねるとか、重ねた本を動かすとか、紙くずAを拾うとか、その紙くずAを別の紙くずBとまとめるとか、まとめた紙くずA・Bをゴミ箱に捨てるとか。
ここでのコツは、「できるだけ細かく分解する」ということです。
重ねるのと動かすの、まとめるのと捨てるのは別動作です。
で、この片付け動作を3回やる。
例えば、手元の本Aの上に本Bを置いて、その上に本Cを置いて、その3冊の本を本棚の近くに移動する、とか。
ここで、3回も片付け動作をすると当然精神的に疲労困憊しているころなので、敷きっぱなしの布団の上に横になって、お菓子を食べながら漫画を読んでリラックスします。
お菓子は、ピーナッツとかマーブルチョコとか、そういう単位の小さいものがいいです。
個人的には韓国ノリがおすすめです。
漫画は、四コマ漫画等、ちょっと読んだところで止められるやつが向いています。
個人的にはイカ娘とか荒川アンダーザブリッジとかを読んだりもします。
そして、5分ぐらいゆっくり休んだら、次の3動作をやります。
例えば、ゴミを適当に3つ拾って手元に集めたら、それで終わりです。
それからまたお菓子と漫画。
5分で3動作というこのペースで片付けをすると、30分で18動作分片付けが進みます*1。
すると、部屋は目に見えて(部分的に)きれいになっているはずです。
片付け前にゴミや本があった場所にスペースができているとか。
その達成感に浸り、残りは次の機会に回します。
次回以降もこのペースで続けてもいいのですが、どうしても我慢できないぐらいもどかしくなったら、一度の片付け動作を10回に増やします。
休憩時間も、必要に応じて短くします。
1分程度にするとか。
個人的には、この「10回・1分」ぐらいを上限にしています。
ところで、この方法には、ひとつの前提条件があります。
それは、「一人暮らしをしている」ということです。
誰かと一緒に住んでいると、その人の基準で片付き度を評価されてしまいます。
例えば、足の踏み場もない部屋をこのやり方で片付けて、本を20冊ぐらい移動させて足の踏み場がわずかにできたとしても、常人にとってはどちらも手の付けようのないゴミ部屋にしか見えないわけです。
ぼく自身、この方法で部屋の乱雑度をわずかに減らすことができるようになったのに、結婚してからまたできなくなってしまいました。
やる気を尊重して長い目で見てくれてもいいんじゃないかと思うのですが、大きく考えると人類の生存のためには各人が向いていることをやる必要があっただろうし、何かに向いていない人間にはそれをさせないようにする本能があるのかもしれないし(適当)、しかたないですね…。
まあ、そういう他人の評価さえなければ、片付けというのは少しやっただけでもそれに見合った効果があるので、一人暮らしの人にはおすすめです。
*1:21動作じゃないかとツッコみたくなった人は、最後の休憩の後そのまま終わりとすると考えてください。いずれにせよ正確な数字でもないので、素直な計算にしています。
「履く」と「穿く」が面倒なことになったいきさつ
ズボンや靴を「はく」というのは、どう書くか。*1
ご存じの方は多いと思いますが、これはけっこうやっかいな問題なんですよね。
もっとも、「あ、これ正解知ってる」という人もいるでしょう。
ズボン・スカートは「穿く」で、靴は「履く」でしょ、と。
ここで、「じゃあ、靴下は?」となると、問題が急に面倒になります。
というのは、靴下を「はく」をどう書くかについては、辞書によって主張が分かれているからです。
国語辞典
調べてみたところ、靴下を「履く」派と「穿く」派の辞書は、以下のようになっていました。
かなり拮抗していますね。
でも、この問題が複雑になったのはどうしてなんだろうというのが、私にとっては前から疑問でした。
というのは、漢字の意味、つまり中国語での意味を考えると、全部「穿」で問題ないところだからです。
「ズボン等は突き通すから『穿』だ」というのはよく見ますが、近代中国語*3では服もズボンも靴も靴下も、全部「つきとおす」という発想で「穿」を使います。
戦前の表記
実際、戦前(明治から昭和前期)の間は、中国語と同じ発想で、すべて「穿く」を使うのが普通でした。
「股引、脚胖、足袋、草鞋の穿きやう迄」と、まとめて「穿く」が使われています。
その前後を見ても同じです。
日本初の近代的国語辞典といわれる「言海」を見てみると、挙げられている漢字はやはり「穿」「着」です*4。
(二)腰ヨリ下部ニ着ク。「袴ヲ―」脛巾ヲ―」足袋ヲ―」沓ヲ―」穿 着
「腰ヨリ下部ニ着ク」というのはわかりやすい説明ですね。
江戸以前
ただ、この「穿く」というのは主に明治以降のもののようです。
それ以前のものを見ると、はきものについては古くから「履く」が使われています。
たとえば、今昔物語集を見ても「履く」が使われていますし、その後ずっと江戸時代まで、はきものを「はく」というときの主流の書き方は「履く」でした。
足袋についても、浮世風呂などで「履く」と書かれています。
一方で、下半身につけるものについては、「着(は)く」という表記が「田舎芝居忠臣蔵」にありました。
この時代は袴などについても「着る」「着ける」と言うことが多かったようなので、漢字を当てるなら「着」になるのが自然だったのかもしれません。
ただ、カナで書かれている場合も多くあり、「着(は)く」はあまり定着していなかったように見えます。
戦前の「履く」の広がり
江戸時代までは主流だった「履く」ですが、言海には収録されていません。
後で書くように「履く」という表記は日本独自のものなので、この段階で認めることは難しかったのかもしれません。
しかし、その後の辞書を見ると、徐々に「履く」が進出してきています。*5
大言海に「履く」がないのは、「言海」の後を継ぐという性質によるものかもしれません。
この時代の特徴としては、「履く」を採用しているものでも、「穿く」の例文に靴類が挙げられているということがあります。
辞苑では次のようになっています。
は・く[穿く] 腰から下に著ける。うがつ。「下駄を―」
は・く[履く] 足に著ける。足にうがつ。
こちらは広辞林(初版)です。
は・く[穿] 腰より下に著く。うがつ。「袴を―」。「靴を―」。
は・く[履] 足に著く。足に穿つ。
このように、「履く」を項目として挙げるものの、依然として「穿く」は腰から下につけるもの一般に使えるという扱いでした。
戦後の辞書の変遷
戦後は、今につながる「履く」「穿く」の書き分けが広がっていきます。
たとえば、辞海(1947)では、次のように書いています。
(二)[穿]腰から下につける。うがつ。「足袋(ゲートル・ズボン)を―」(三)[履](げた・くつ等を)足につける。
語釈の「腰から下につける。うがつ。」というのはそれまでの辞書と同じなのですが、靴類が例文にありません。
広辞林でも、初版には「穿く」に「靴を―」という例文があったのが、新版(1958年)では消えています。
は・く[〈穿く] 袴・ズボンなどを身につける。うがつ。
広辞苑と新明解の変遷も面白いところです。
広辞苑の初版では、次の画像のように、項目の漢字として【佩く・帯く・穿く・履く】を挙げながらも、使い分けは示さず、語釈としては「(2)腰・腿(もも)・足につける。うがつ。」と「(3)(下駄・靴などを)足先につける。」で分けていて、「足袋」は(2)に分類しています。
それが、第四版(1991年)では次のようになっています。
「足袋・靴下など」を(3)に分類し直したうえで、《履》という表記をつけています。
第三版までは足袋は(2)だったので、意図的に分類し直したということですね。
これは推測ですが、足袋に対して「履く」を使っている例があるため、そうしたということかもしれません。
ここまでは第四版の話なのですが、その後第五版(1998年)で(2)(衣類)に《穿》という表記が加わり、今に至ります。
新明解のほうは、第一版(1972年)は次のような語釈です。
は・く
[一]【〈穿く】
(一)足を保護する物を足先につける。「たびを―・くつを―」〔後者は、履くとも書く〕
(二)下半身や手先を保護する物を身につける。〔着くとも書く〕
「たび・くつ」と「下半身や手先を保護する物」という分類です。
漢字表記については、「基本的な表記は『穿く』で、靴の場合は『履く』とも書く」という、戦前からの流れを汲む書き方です。
それが、第四版(1989年)では次のようになっています。
は・く
[一]【履く】足を保護する物を足先につける。「足袋を―・靴を―」
[二]【〈穿く】下半身や手首から先を保護する物を身につける。「ズボンを―」
それまで「靴」は「穿く/履く」で足袋は「穿く」という扱いだったのが、靴・足袋ともに「履く」という扱いになっています。
これも意図的なものですね。
ここでちょっとずるいなと思ったのは、「靴下」について触れていないというところです。
「足袋」なら古い用例があると言えるので、あえてそちらだけ記載したということかもしれません。
「履」の字義
ここでいったん、明治より前の事情に戻ります。
江戸時代までは主流の書き方として使われてきた「履く」ですが、そのころの主な辞書類で「履」の読みとして「はく」が挙げられることはなかったようです。*7
どうして、実際に使われていた「履く」は冷遇されてきたのでしょうか。
それは、古代中国語(漢文)の「履」という単語に「はく」という意味がなかったからでしょう。
「履」の意味は、主に「くつ・はきもの」「ふむ」の二つです。
ここで少しややこしい事情があります。
「履」には「くつ」という意味があるのですが、これは動詞として「くつをはく」「くつをはかせる」という意味にもなります。
史記の留侯世家に「父曰履我」というところがあるのですが、この「履」は「くつをはかせる」という意味です。
古代中国語では、名詞がそのまま動詞として使われることが多かったようです。
このような品詞転換は、たとえば英語で "pin" という単語が「ピン留めする」という動詞としても使われるのに通じるところがあります。
しかし、この用法はあくまで「『履』をつける」というものなので、漢文の理屈としては「靴を履く」というのはおかしいということになります。
「はきもの」の表記
じゃあ、なぜ「履」が「はく」として使われるようになったのか。
ここで、「はきもの」の表記について考えてみます。
現代の感覚では、「履く物」だから「履物」だというのが自然に感じられます。
しかし、「はきもの」は元々「履」という漢字一文字に当てられる読みでした。
「履」は当時の中国語で「くつ」の意味なので、日本語にすると「くつ」や「はきもの」になるということです。
ですので、日本語の「はきもの」という言葉を書くときには「履」と書けば正しいはずです。
しかし、字義としては正しいのですが、これでは「くつ」との区別ができません。
そのためもあってか、「はきもの」は「物」をつけて「履物」と書かれたようです。
今昔物語集にも、「履物」表記が出てきます。
「はきもの」が「履物」であれば、「はく」は「履く」と書くのが自然です。
その後、「履物」表記は明治に至るまで使われ続けます。
一方で、言海は「はく」に対する「履く」は認めていません。
一般にも「はく」は「穿く」と書かれていたので、この時代のものには「履物を穿く」という書き方が表れます。
しかし、「はきもの」が「履物」である以上、「はく」も合わせて「履く」としたくなるところです。
そのことが、その後の「履く」の復権に至ったのかもしれません。
用例
ここで現代に戻って、少納言というサイトを使って、最近の書籍等での使われ方を見てみます*9。
靴をは(く等) : 221件
靴を履 : 150件
靴を穿 : 6件
靴下をは: 25件
靴下を履: 9件
靴下を穿: 5件
ズボンをは: 85件
ズボンを履: 8件
ズボンを穿: 18件
現状としては、靴・靴下を「はく」の漢字表記としては「履く」が優勢です。
ズボンは、漢字については「穿く」が優勢です。
しかし、「穿く」が当用・常用漢字表外になるズボンだけでなく、靴・靴下についても優勢なのは平仮名でした。
今後
今後、「はく」の表記はどうなるんでしょうか。
個人的には、「腰から下につける」という意味の「はく」にひとつの表記があったほうが日本語として便利だと思います。
明治から戦前にかけては、すべて「穿く」が使えたところです。
でも、「穿く」が支配しかけていたところに江戸からの「履く」が復権して侵食してきたという流れを考えると、今後統一される望みはなさそうです。
ネットで見る実態としては、「履く」はズボン・スカート類にもだいぶ進出しています。
直近では、(下品で申し訳ないですが)「トランクス女子を流行らせよう(提案)」のブコメ*10を見ても、本文では「穿く」が使われているのに、ブコメでは本文の引用以外では「穿く」は1個しかなく、それに対し「履く」は10個もあります。
しかし、ズボン・スカート類については「穿く」と「ちゃんと」書くことにプライドを持っている人はすでに多くいます。
それに、今後ツイッターなどで「正しい日本語」が拡散されやすくなるにつれ、「ズボン・スカートは『穿く』だ」という「知識」はいわゆる情報強者層にはどんどん広がっていくでしょう。
「はく」と平仮名で書くというのはこれまで多く行われてきたことなのですが、上のブコメを見てもわかるように、ネットでは平仮名表記はだいぶ少なくなっています。
そうすると、ズボン・スカートを「はく」というのも「履く」か「穿く」のどちらかになるのですが、前者は間違っていると思われ、後者は目に慣れないというジレンマがあります。
まあ、ズボン・スカートは最終的には「穿く」に収束するのでしょうが、せめて靴下類は「履く」に落ち着いてくれるといいなぁと思っています。
「靴下について『履』を使うのはおかしい」と言うなら、「靴をはく」に「履」を使うのもおかしいんですよね。
どうやっても妥協の産物になるので、どうせなら靴・靴下がひとまとまりのほうがいいんじゃないでしょうか。
(そうするとストッキングはどうなるという話になるのですが、まあ答えが出る問題ではないですね)
「はく」はひとつ
今さらですが、日本語の「はく」はひとつの単語だという当たり前の事実を確認しておきます。
「はく」という単語の意味は、言海の時代の「腰ヨリ下部ニ着ク」から変わっていません。
それをどう書くかが揺れているだけです。
しかし、あきれたことに、世の中には「はく」が二つの単語だと思っている人もいるようです。
高島俊男先生の言う、「健全な日本人」でない人ですね。
上に、日本人ならだれでもわかるように「とる」の意味は一つだ、と言ったが、「健全な日本人なら」と限定をつけたほうがよいかもしれぬ。漢字かぶれの日本人のなかには、「とる」の意味は一つではない、どの漢字を書くかによっていくつもの意味がある、別の語になる、と思っている者もいるかもしれないから。
今回、いろいろ辞書を調べるなかで一番あきれたのが「明鏡国語辞典第二版」です。
「穿く」の項目に、書くに事欠いてこんなことを書いています。
「履(は)く」と同語源。
同語源ってことは、今は別語ってことですか。
頭おかしいんじゃないですかね。
同語源の別語というのは、「読む」と「詠む」のようなものについては言えるでしょう。
「読む」と「詠む」は同語源ですが、現代語では別の単語なので、たとえば「彼は和歌を一首と本を一冊よんだ」とは言えません。*11
これを書いたのは何人か知りませんが、「ズボンと靴下をはく」とか「靴下と靴をはく」とか言わないんでしょうか。
まあ、実際はそこまで考えていないんでしょう。
漢字にくらまされて日本語が見えなくなっている
というやつですね。
嘆かわしいこと限りないですが、今後はこういう辞書が増えていくのかもしれません。
日本語のつながり
今では、「履く」と「穿く」を「ちゃんと」書き分けられるかどうかというのは、物を書く人間を判断するリトマス紙のようになってしまっているところがあります。
それはいいのですが、それに「漢字の意味」のような余計な解説を付け加える人も多くいるようで気になります。
この書き分けは歴史的経緯によるもので、「日本語の漢文からの脱却」の象徴的なひとつの例とも言えるようなものです。
「『靴をはく』は『履く』であって『穿く』ではない」というのも、時代が時代であれば、何をバカなことを言っているんだと漢学者にあきれられるところです。
「漢文は日本語の規範ではない」ということを前提に、この書き分けは成り立っています。
たまに、戦前の日本語を理想化して、戦後はその「古き良き日本語」から断絶してしまったように思ってる人がいます。
しかし、「漢文からの脱却」という流れで見ると、明治から戦前・戦後の日本語は一貫してつながっています。
「はく」について言うと、「はきもの」の表記として言海に「履」ではなく「履物」が採用され、大正〜昭和初期の国語辞典に「履く」が収録され、戦後の国語辞典で「穿く」から靴類の用例が削られるという、いくつもの段階を経て現状に至っているわけです。
最近「漢文脈と近代日本」という本を読みました。
そこから一節を引用します。
…私たちが立っているのは、漢文脈の秩序の外側に開拓された領野だからであり、それは、漢文脈的でないものを目指して開拓されたはずだからです。極端に言えば、漢文脈とは、いったんは捨てたはずのものです。そうであるならば、なぜ捨てたのか、それを捨てた私たちとは何であったのか、目を向けないわけにはいきません。
漢字クイズのようなものにゼロイチの答えを求めるよりも、こういう「日本語の来し方行く末」のようなことについて考えるということも、たまにはいいんじゃないでしょうか。