表現の手段と交換の手段 - A puzzler on the trail

「「プログラム設計書」って必要？：おごちゃんの雑文」とか「業務システム開発でドキュメントを作ることについて：満足せる豚。眠たげなポチ。」とか読んでいろいろ思い出しつつ纏めてみようかと思い立ちました。自分の中でこの辺りのことを考え出すきっかけになったのは、いま思い出してみればC++アプリとつなぐJavaアプリを作ったときに問題に直面したからなんですけど。CORBAとかJavaが出だしたころの話ですので、10年近く前の話になるのでしょうか。記憶もあいまいになってきましたので、技術的な細部については不正確な記述も混じるかもしれませんし、いまではその当時直面した問題も改善されているかと思います。何を今更かもしれません。その点についてはご了承ください。

文字コード問題が発端

C++アプリケーションとJavaアプリケーションをCORBAでつなげると言っても、当時は解説書とかもほとんどありませんから規格書とか製品マニュアルをにらみつつ開発を進めていました。Javaのchar型はUnicodeのUTF-16で2バイト表現ですので、CORBAでつなげるならCORBA::WCharを使えば良いよねと安直に考えて実装を始めたのですが、いざテストしてみると漢字が思いっきり化けます。UTF-16とSJISのエンコーディングの違いはJava側で変換して吸収しているつもりでしたので、いろいろ悩んでテストを重ねているうちに、当時使っていたCORBA製品ではCORBA::WCharでもLatin-1という1バイトコードしか想定していなくて、上位バイトを無視してしまうという問題を発見しました。仕方ないのでJava側でバイト列に変換して交換するようにしたのですが、このような問題に直面したのを契機に国際化に興味を持ちました。
いまでこそUnicodeは渋々でも受け入れるというスタンスが中心になっているかと思いますが、その問題に直面していた頃はまだ議論が盛んでUnicodeに対しても賛否両論の時代です。その辺の問題に関してはネット上では「小形克宏の「文字の海、ビットの舟」――文字コードが私たちに問いかけるもの：INTERNET Watch」が深く掘り下げられているかな。いろいろ文化と文字コードに関した本も出版されましたが、いま入手しにくいようですがDanさんおすすめの「電脳社会の日本語 (文春新書)」がいいのかな。文字コードの問題については最近でもWindows Vistaのときに問題になりましたよね。「Vista で導入される JIS X 0213:2004(JIS2004) のまとめ（お勉強編）：Drk7jp」とかで纏められているように。
文字コードに関しての主張をみて感じたのは、同じ文字と言っても表現の手段として捉えて議論している人と、交換の手段として捉えて議論していると言うことです。日本語においては、文字自体に表現を込める文化がありますので、自分達の表現手段を文字集合として縛られたり、先人たちが残した表現が正確に表現できない文字規格に対しては抵抗が強いようです。標準としての文字集合を決めるときに包摂という考え方がありますが、これは異字体は文字として区別することなく同じ文字として扱うという考え方ですが、ある漢字を包摂して良いかは常に議論になります。特に問題になるのは人名で、良く取り上げられるのが「内田百輭」の「輭」という字とか、「渡辺」さんも本当は異字体の「渡邉」であったりとか。
ただし、文字に表現の自由をあまり求められると困ることがあります。文学作品でしたら分かってもらえる人だけを相手にしていればいいのですが、報道文とかですとなるべく多くの人に理解してもらわなければいけません。そのために、国語審議会において「常用漢字表」とかで最低限これは覚えているものと考えてよいですよと定めているわけです。いわば情報交換の手段としての文字ですね。こちらの方の考え方では相互理解のためには制限も必要という考えです。その一番究極ともいえる例が通信分野での文字標準です。人間なら許容できるあいまいさも、機械では許容できませんから。
同じ文字コードについて議論していても、表現の手段として捉えている人にとっては、情報技術が進歩でコスト性能面からの縛りは緩くなっているから自由度を高めて欲しいといい、交換の手段として捉えている人は、扱いきれないので制限は必要と反論するというすれ違いが、未だに続いているようにも思えます。

計算機屋と通信屋の考え方の違い

表現の手段か、交換の手段かという問題、IT分野では標準化での発想の違いにも現れてきます。その典型的な例が計算機屋と通信屋での規格、標準のとらえ方の違いですね。一般に計算機屋は表現を重視し、通信屋は当然交換を重視します。たとえば、プログラミング言語の標準では規格本体に実装依存部分があります。これは、C言語のようにハードウェアに合わせて最適化できるようにするためであったり、CommonLispのようにもともと標準が決まってなかったところに後付で標準化したための妥協であったりします。プログラミング言語では環境を指定して開発しますので、当初からマルチプラットフォームを考えたり、移植したりする必要がなければそれでも問題はありません。また、プログラミングが好きな人も、プログラミングを表現活動と捉える傾向が強くて、きつい縛りの存在はあまり好まれません。
それに対して、通信屋では実装依存というのは自分達の仕事をそれだけ大変なものにしますから、標準を定める場合でも極力制限する方向に向かいます。交換している情報に解釈の違いが存在すると、その分吸収する必要がありますからね。コストと性能に跳ね返ってしまいますから、なるべく必要最小限という発想になるのは当然です。どうしても実装依存になってしまう部分はannexとかで切り分けます。
昔は計算機の世界と、通信の世界は接点が少なかったので、そのような考え方の違いも問題にされることがあまりなかったのですが、インターネットの発達でコンピュータの世界と通信の世界が密接にからむようになって問題噴出です。文字コードのところで取り上げたCORBAの問題も、通信を計算機屋が扱うと発生する典型的な問題かもしれません。最近はお互いに意識するようにはなっているようなのですが、まだまだすれ違いは残っていそうです。関数型言語に興味持っていろいろ見たことあるんですが、なかなかよさそうに思えたOCamlもint型が実装依存でかつ32ビット環境でもJavaとかと違って31ビット表現なんですね。OCamlに閉じていればスマートな実装かもしれませんが、他言語との接続考えると抵抗があります。マイクロソフトがCamlそのものではなくてF#にしたのも分かるような。CLR上で動かすときに問題起きそうですし。私自身は、一つのプログラミング言語でなんでもこなそうとするよりも、JVMやCLR上で言語を使い分けつつ共存するようなパラダイムの方が好ましく思えるので、そういってしまうのかもしれませんが。

設計書って

本来設計書が発端になってこのエントリーを書き始めたのですが、表現の手段とか交換の手段とかを思い出していたら、前振りが思っていたより長くなってしまいました。
では、設計ドキュメントは何のために作るのでしょうか。いままで表現と交換と区別してきましたが、普通は両方の側面を含んでいます。芸術では表現が強調され、指示書とかでは交換という側面が強くなります。設計書は基本的に前工程からの設計文書を元に、何を行うべきかを次の工程に伝える指示書なわけです。ここで情報の流れは一方向ではありません。人間ですから解釈の誤りとか、想定漏れとかがあって、次の工程で問題が露見することがあります。そのときに工程間で何が問題かを詰めなければいけません。そのときにどのような設計文書でコミュニケーションを図るべきかがここで問題になっているかと思われます。そして、ソースコードを書くことを、プログラミング＝設計と捉えるか、コーディング＝製造と捉えるかでその人の主張が異なっていると思います。
前工程の問題が後工程で露見した場合、問題を議論する土台になるのは後工程の設計書となるわけですよね。そこで問題になるのがソースコードを書くということをどのように捉えているかです。設計と捉えているならば、プログラムが何を何を行っているかをもっとも正確に表現した設計書がソースコードですので、プログラミング設計書なんて作業の重複にしか見えなくて余計なわけです。プログラミング設計書を作るというのならフォーマルメソッドでも導入しろよと言いたくもなるでしょう。それに対して、コーディングとして捉えている人はいわば作業員に対する指示書ですので、プログラミング設計書は必要となるわけです。ハードウェアとか設置する場合には作業する側から詳細な指示書を求められがちですし、そのような指示書と同じ感覚で捉えているのでしょう。ソースコードを書くことに対するとらえ方の違いが、議論のすれ違いになっているように思えます。
プログラミングとして捉えてすべてを伝えきれるかというと、伝えきれないこともあります。何をしているかは伝えやすいですが、背後にある設計思想みたいなものはつたえきれるとは限りません。設計思想というと偉そうに見ますが、ようは何故そうしたかということです。設計である以上何らかの意志決定をしているわけで、複数の選択肢から選択した結果がソースコードに現れているわけです。基本的にはプログラミング作法みたいなものは共通ですので、設計思想は共有されていると考えていいかと思います。ただ問題になるのはインフラの制約から行った選択はソースコードで伝えきれるとは限りません。有名なところでは2000年問題ですが、過去の制約を知らずに問題だけを取り上げた場合には、なんと馬鹿な設計をしたことかと思ってしまうかもしれません。でも、その設計がなされた当時に西暦を4桁で扱っていれば、貴重なリソースの無駄遣いと非難されたことでしょう。このような大きな問題に限らなくても、移植のときにミドルウェアとかＯＳのバグを回避するために行った修正とかは、バグが直った環境に慣れた人から見れば、なんでそのようなことをしたのか分かり難いかもしれません。その点については、私も過去に申し訳ないことをした記憶があります(汗)。実験論文を書くときには、再現実験のためにも使った試薬、機器を正確に書くことを求められます。プログラミングレベルでも、どのような環境で何故そのような選択をしたのか、残しておくと後の人の助けになると思います。

最近、哲学的なエントリーが続いたので、気分変えるのにちょっと雰囲気変えたエントリー書いてみました。ここに書いているのはあくまでも個人的な意見ですので、異論ある人も多いでしょう。