未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

①(まるいち)という文字

あなたのブラウザは①(まるいち)を表示できますか?
Windowsで見ている人は多分表示できる。UnixないしLinuxの人はどうだろうか?
ブラウザの文字コードEUC-jpにしている人は多分表示できない。なぜか、①(まるいち)がEUC-jpというエンコーディングには入っていないからだ。そんなばかな?Windowsエンコーディングは通常CP932(シフトJISという人もいる)というが、それには①(まるいち)とか㈱((株))とかの文字種を持っているがEUCと呼ばれているエンコーディングにはそのような文字種がないからである。CP932に表現できる文字種を全部EUCで表現してしまえばこの問題は解決するが、いろいろ議論はつきない。
Unicodeで表現すればいいという人もいるが、UnixLinuxの場合、昔からEUCで運用していたりすると、簡単にUnicodeに諸般の事情で移行できないので、たかが①(まるいち)をサポートするためにいろいろ面倒なことがおきる。
そのような面倒なことを、どーにかこーにか回避するというのがレガシーエンコーディングプロジェクトであったりする。
そんなことをid:ogwata:20060503:p1を読みながら思った。
http://blog.livedoor.jp/dankogai/archives/50480727.htmlから

ソフトウェアの互換性

本当はすごい「Windowsの互換性維持」を読んだ。Windows95と地上の星もあわせて読んだ。
ITPROのコメントを読むと互換性維持に多大な努力を払うことにネガティブな意見が多い。利用者としては互換性維持は当たり前品質なので賞賛に値しないというスタンスだろうか?まあ、仮にそうだとしても、中の人の当時のお話(Windows95と地上の星)は貴重だ。
技術者として互換性の維持を保持することは、技術的な新規性を求める開発プロジェクトと違ってあまりやりたくない仕事なのかもしれない。技術的新規性を見出すことは難しいかもしれないが、それでも、工夫はいたるところにあるだろう。それを尊重するかどうかは企業風土による。
企業にとって互換性維持をプライオリティ上位にあげるのは、顧客を自社製品にロックインするための基本戦略である。他社製品に流れるコスト、これをスイッチングコストと呼ぶ、を上げつつ自社製品を使い続かせるためには、バージョンアップのコストを下げないといけない。それはとりもなおさづ互換性を保つことに他ならない。前のバージョンで動いていたものが動かなくなったとしたら、なんでわざわざその製品を使いつづけなくてはいけないのか?極めて単純な製品戦略である。しかし言うのは易いが行うのは難しの典型である。
マイクロソフトの凄みは、そのようなビジネス戦略を製品開発の現場の隅々まで徹底したことである。評論家的技術者(それはどんな会社のどんな技術部門にもいる)は、互換性維持ということのビジネス的な重要性を過小評価し、「技術的なチャレンジがない」、「後ろ向きな開発だ」、「こんなタコのような実装をして、おれらが苦労する」(わたしの勝手な妄想だけど)というようなネガティブな発想の元、互換性維持に価値を見出さない。新製品を開発する方がどんなに楽しいか。しかしそんなことばかりをやっていたら会社はつぶれてしまう。
個々のエンジニアが

しかし、かといってWindows3.1との互換性をないがしろにすることは、絶対にできない。ユーザーが持っているWindows3.1用のアプリをそのまま走らせることが出来るからこそ、Windows95への移行がスムーズに進むのだ。互換性が維持できなければ、AppleIBMに付け入るスキを与えてしまう。

という自社の立場を明確に理解し、自分のやるべきことをはっきりと自覚しているチームは強い。
リーダは、

「この状態を打開するために、各部署から人を出してスワットチームを作って欲しい。3ヶ月以内に、市場に出ている売れ筋のWindows3.1用のアプリ全てがWindows95上できちんと走るようにして欲しい。どんな手段を使っても良いからかならずそれを実現するのが君らの役目だ」

明確なゴールを設定する。ここでのゴールは「3ヶ月以内に、市場に出ている売れ筋のWindows3.1用のアプリ全てがWindows95上できちんと走る」ようにすることだ。これほど明確なゴールはない。リーダがゴールを示し、メンバーがそれを正しく理解する。そのようなチームは強い。
達成した目標に対しては会社がその貢献をたたえる。これも重要である。

 翌年7月。予定通りの日付にWindows95をリリースした開発チームにDavid Coleが感謝の言葉を述べ、テーブルの上のシーツを取り除く。ドンペリが50本あらわれる。「優勝した野球チームがビールをかけ合うのであれば、 Windowsチームはドンペリだ。」という彼の約束どおりである。皆、一本ずつドンペリを手に持ち、頭から掛け合い、ラッパのみをする。シャンパンまみれになったSatoshiとKevinががっちりと握手をする。

このようなチーム運営ができる会社の凄みというを我々はもう少し理解した方がいい。

OSSの互換性

一方でOSSの場合、そのような互換性を守るという強いインセンティブは残念ながら存在しない。少なくても経済的なインセンティブはない。OSSが一社のビジネスとして開発されているわけではないので、互換性をあげて他のソフトウェアへのスイッチングコストをあげるというインセンティブがない。残念ながらOSSにはマイクロソフトがいないわけだ。
開発コミュニティが互換性の重要性をまったく知らないというわけではない。またOSSでビジネスをやっている企業等も互換性が重要だという認識はある。しかしそれに多大なコストを払ってまで互換性を維持するというインセンティブがないのである。非互換を発見するコスト、非互換の発生品時にそれを直すコスト等々は極めて大きい。だとすれば、互換性維持のコストを下げるような技術開発が重要になってくる。マイクロソフトがいない分、仕組みによって互換性を維持する。そのような仕組みが今まさに求められている。
非互換を発見するコストを下げるためにはリグレッションテストの整備などは有効な枠組みであるが開発が始まったばかりである。
OSSの互換性をどのように維持していくかはOSSの重要な課題となっている。