radium.png
HOME | ARCHIVE | PRODUCTS | ABOUT | RSS

XM-8 (2)

2004-06-01

040601.jpg

XM-8 の開発を担当した Heckler & Koch USA 社のウェブページでは， XM-8 のデータシートや， XM-8 と M4 カービンの性能を比較した表などが， PDF でダウンロードできるようになっている。

http://www.hk-usa.com/pages/military-le/rifles-carbines/xm8....

資料によれば，弾丸の初速は通常のカービン銃モードで 815 m/sec とされている。これは， 900 m/sec 以上の初速を持つ M4 や M16 と比較した場合に，若干威力が落ちることになる。

モジュール性のほかに挙げられる特徴としては， H&K 社独特のガス・オペレーション方式などがあるようだ。これは， M4 や M16 において用いられているようなダイレクト・ガス・オペレーション方式とは異なり，発砲時のガスが直接ボルトまで届かないようになっているため，内部機構が汚れにくくなっているとのことだ。結果的に，クリーニングの頻度は 15,000 発に１回必要な程度にまで引き下げられている。

ArmyTimes において公開されているビデオの中には，ホコリや水に対する耐性の高さをアピールしたデモンストレーションなども含まれている。

http://www.armytimes.com/story.php?s=1-292925-xm8_dust.php

砂まみれの銃を撃ってみせたり，水の満たされたドラム缶の中から取り出した銃を即座に撃ってみせたり……まるで向こうの通販番組のような分かりやすいデモだ。ともかく，安定性の高さをウリにしていることは十分に伝わってくる。

耐久性も相当に高められているようで，全部品が 20,000 発の発射にまで耐えられるように作られている。これは， M4 カービンでは 8,000 発程度で部品交換の必要があることを考えると，相当に高い耐久性であることが分かる。それでいて製造コストは $600 以下に抑えられているというのだから，非常にパフォーマンスの良い銃であることには間違いない。

XM-8 の前身であるところの OICW こと XM-29 も，相当に凄い銃だ。

http://world.guns.ru/assault/as40-e.htm

http://www.hkpro.com/oicw.htm

「従来型の小銃は既に技術的な限界点に達しており，これ以上命中率を高めるには炸裂性の弾頭を導入するしかない」という大胆な発想から， 20 ミリ口径の炸裂弾ランチャーと 5.56 ミリ NATO 弾ライフルを結合させた化け物のような銃が出来上がってしまっている。

この 20 ミリ炸裂弾の内部には電子化された雷管が内蔵されており，「標的捕捉・発砲制御システム」 (TA/FCS) から送られたデータを元に，自動的に炸裂タイミングが切り替わるようになっている。また，この TA/FCS には，他にも暗視装置やレーザー測定装置，弾道演算器などの電子機器が詰め込まれており，従来の個人携行銃とは一線を画す高度な電子化が図られている。

ただし，その極端な技術偏向の設計から製造コストは膨らむ傾向にあり，銃本体は１挺あたり $10,000 以上という非常に高価なものとなってしまっている。また，専用 20 ミリ炸裂弾は１発あたり $25 もするため，実際には単なるグレネード弾を多用せざるをえないという，意味の無い状態になってしまっている。結局のところ， 1986 年から続けられているプロジェクトにも係らず，まだ製品の完成に至っていないというのは，その辺りの設計思想のまずさがあってのことなのだろうと思う。

permalink

Go pedal to the metal (1)

2004-06-02

ブログの更新確認に利用している FeedDemon の未読数が，なかなか０にならない。年度末に仕事が忙しくなった辺りから，だんだんとチェックが追いつかなくなってきていて，今では未読数が増える一方になっている。そんな状態だから，一時期話題になった "Channel 9" も，今ではチェック対象から外してしまっている。

http://channel9.msdn.com/

Channel 9 は，ある意味画期的なサイトではあるけれど，ジャーナリスティックな色が濃く，個人的にはあまり面白味を感じられなかった。ブログ文化というよりかは，単なるニュースサイトの類に近いものであると思う。

ブログにも様々な種類があるけれど，個人的に好みなのは，やはりエッセイ的なブログだ。最近面白かった Microsoft 社員のブログと言えば， OneNote のプログラム・マネージャであるところの Chris Pratley 氏のブログだ。

http://weblogs.asp.net/chris_pratley/

一時期ポスト数が激減しており，このまま自然消滅してしまうものかと思っていたのだけれど，最近またポストの頻度が上がってきている。どうやら，現在出産休暇中であり，そこで余った時間をブログのポストに利用している，ということのようだ。

特に 4 月 27 日のポスト "Let's talk about Word" は非常に興味深い内容であり，既に 190 件ものコメントが付けられている。

http://weblogs.asp.net/chris_pratley/archive/2004/04/27/1209...

以前のポストでも明かされていたことだけれど， Pratley 氏は元セイコーエプソン社の社員であり，日本に在住していた経験がある（奥さんは日本人だそうだ）。 Microsoft 社に移ってからは，アジア版 Excel や日本語版 Word95 の開発などを担当し，現在では Word, Publisher, OneNote の３つのプロジェクトのマネジメントを担当するに至っている。

件のポストは， MS-Word が "WordStar" や "WordPerfect" のような先行アプリケーションを追い抜き，市場を独占するに至ったその過程を解説している。また，日本の「ワープロ」市場における Word の台頭の過程についても触れている。

うがった見方をすれば， Microsoft 社員の自慢話でもあるのだけれど，その内容は「堅実な戦略がいかにして市場を席巻するのか」という知見に満ちており，ある種の教訓を与えてくれるものでもある。ドキュメンタリー的な面白さもあって，一気に読み進めることができた。

permalink

Go pedal to the metal (2)

2004-06-03

件のポスト "Let's talk about Word" において Pratley 氏は，まず最初に，米国における PC 向けワードプロセッサの競争の歴史について触れ，その次に，日本市場における Word 対「一太郎」のシェア争いについて触れている。そのいずれにおいても， Microsoft 側の戦略として共通しているのは，顧客からの要望の綿密な調査を行ったことと，「顧客の望むものを実現し，顧客の嫌うものを避ける」というルールを厳守したことだ。特に後者のルールは十分に自明なものであるにも係らず， Microsoft の競合相手は，どこかで失敗を犯してしまっている。逆に Microsoft は，基本的にこれらの失敗を犯すことが無かった。結果として（他に様々な要因はあれど） Word は市場を席巻するに至っている。

件のポストの最後の方に，次のような記述がある。

一言で言えば，これが Microsoft の方法なのです。市場を理解し，顧客を理解したならば，あとは目一杯ペダルを踏み込むだけです。リリースを行った後は，顧客が何を必要としているかという点に注目し，それをフィードバックとして具現化させます。そうすれば，競合相手はリアクション・モードに入ってしまうことでしょう。そして，その競合相手が何らかの戦略的失敗を犯した場合，プレッシャーが失敗を増幅させることになるのです。

この一節からは Joel Spolspy 氏の "Fire and Motion" が連想される。

http://www.joelonsoftware.com/articles/fog0000000339.html

結局，これは「援護射撃」なのです。競合相手は，すべての時間を移植と保守に費やすこととなり，新しいフィーチャーの実装に費やす時間は無くなってしまいます。（中略） あなたは，顧客がそれを必要としているからサポートするのでしょうか？ それとも，誰かがあなたを射撃しているから，やり返さなければならないと感じているだけなのでしょうか？（中略） これは「チェックボックス・フィーチャー」に過ぎないのです。あなたはチェックボックスを塗り潰す必要があるから，そうしているのでしょう。しかし実のところ，誰もそれを必要としないでしょうし，使おうともしないでしょう。それは「援護射撃」に過ぎないのです。

Windows95 と Word95 の発売から約 10 ヶ月後に発売された「一太郎７」は，「コンポーネント」システムの導入を最大の変更点としていた。しかし実際には，それはユーザに対してアピールを行えるようなものではなく，逆に要求マシンスペックの引き上げやシステムの不安定性を招くものとなっていた。 Windows95 への対応が大幅に遅れたことも痛手となり，一太郎は次第にそのシェアを失っていくことになる。

http://www.google.com/search?q=cache:pc.watch.impress.co.jp/...

Microsoft が頑なに上位互換性を保ち続けるのも，結局は「ユーザがそれを望んでいるから」という理由に他ならない。互換性の断絶は，多くのユーザに対して不利益をもたらすことになる。 Word チームは，競合製品である WordPerfect の出力するファイルの完全なインポートを実現すべく，そのファイル形式のリバースエンジニアリングまでも行っている。また，操作性に関しても，大幅な変化が生じないよう特別な配慮が行われてきた。たとえ時代の流行がどうであれ，意味の無い進化を遂げることよりも，現状を保つことの方が，多くのユーザに対して利益をもたらすことを心得ているからだ。

permalink

Version Numbering

2004-06-04

余談だけれど，ここでひとつのトリビアがある。 Word のバージョン番号は， 1992 年の Word 2.0 から 1993 年の Word 6.0 の間に，一気に 4 も上がっている。これは当時，既にバージョン 5.1 をリリースしていた MacWord チームと統合が行われたためであるとのことだ。

僕が初めて触った Word は Windows 3.1 上で動く Word 6.0 だったのだけれど，つい最近まで 1.0 とか 2.0 とか言っていたものが，いつの間にか 6.0 になっていたものだから，ひどく不思議に感じたことをを覚えている。

Word 95 以降， Word シリーズは品名にバージョン番号を用いることを止めているようだけれど，それでも，しばし混乱を招くネーミングを繰り返してしまっているように思える。 Word 95 は "Word 7.0" の別名を持っていたし， Word 98 は MS-IME98 を売り出すために作られた日本限定バージョンだ。最近では， Office XP に含まれる Word の名称が "Word 2002" だったりして，メンテナンスの際に混乱を招いていた記憶がある。

「OfficeXP に深刻な脆弱性が見つかったそうなので，パッチを当ててください」
「僕のは Word 2002 だから問題無いですね」

素直に "Word XP" としてしまえばよかったものを……。

Microsoft のバージョン番号付けに関しては，面白い逸話がいくつかある。例えば， DirectX のバージョン番号が 3 から 5 へスキップした話などは，よく知られているものではないかと思う。

http://weblogs.asp.net/oldnewthing/archive/2004/01/22/61647....

Raymond Chen 氏によれば， DirectX 4 と DirectX 5 は同時に開発が進められていたものの，ゲーム開発者の多くは DirectX 5 のフィーチャーにしか感心を示さなかったため， DirectX 4 は急遽キャンセルされることになった……という顛末のようだ。既に両バージョンとも概要は公開されていたため，無闇な改名は混乱を招くと判断され，そのまま DirectX 5 への飛躍が行われることとなる。

もうひとつの興味深い逸話は， Win32 API の getVersion 関数にまつわる話だ。この関数は， Windows 3.1 においては "3.10" を返し， Windows 95 においては "3.95" を返す。後者が "4.0" ではなく "3.95" を返すことには，ある理由が存在する。当時，多くのコードが次のような記述によってバージョンの確認を行っていることが判明したためだ。

UINT Ver = GetVersion();
UINT MajorVersion = LOBYTE(uVer);
UINT MinorVersion = HIBYTE(uVer);
if (MajorVersion < 3 || MinorVersion < 10) {
   Error("このプログラムは Windows 3.1 以上を必要とします");
}

http://weblogs.asp.net/oldnewthing/archive/2004/02/13/72476....

一見，このコードは正しいコードであるかのように見えてしまうかもしれない。しかし実際には，このコードはバージョン "4.0" においてもエラーを返してしまう。マイナーバージョンを確認している式 "MinorVersion < 10" が否となってしまうためだ。

このバグはあまりにも広く蔓延していたため，我々は問題のあるアプリを全て修正することは諦めて，次のように決断したのです － 「もういいさ。誰かが尋ねてきたら，この Windows は "3.95" だって答えてやるんだ」

Chen 氏は， DirectX 5 が "4.05" であり， DirectX 8 が "4.08" であるのも，同様の理由によるものであるだろうと指摘している。

permalink

Cowboy Coders (1)

2004-06-07

040607.jpg

プログラムとは関係の無い事務仕事で土日を費やし，今日は今日で，日がな一日会議室でミーティングだった。会議室の椅子は仕事場の椅子よりも硬くて，ずっと座っていると肩が凝ってくる。あまり長時間居座りたくない場所だ。

一般に開発チームは，様々な種類のプレイヤーから構成される。したがって，チームそのものを理解するには，個々のプレイヤーを理解することから始めなくてはならない。では，個々のプレイヤーとは，いったいどのような尺度によって分析することができるのだろうか。

先日の Gamasutra の記事 "The Secret's in the Schedule: Bending The Mythical Man-Month" において Michael Saladino 氏は，個々の開発者の持つ性質を "skill" （技量）と "dedication" （献身）のふたつの軸によって評価しようとしている。

http://www.gamasutra.com/features/20040421/saladino_01.shtml

このふたつの軸に沿って，それぞれ「高」「低」の分類を行うと，上図のような 2 x 2 のマトリクスが構成される。このうち，「技量が低くとも献身度の高い人材」や「献身度が低くとも技量の高い人材」に関しては，その特性を理解することによって，上手く付き合っていくことが可能となる。しかし，「技量が低くて，献身度も低い人材」に関しては，厳しい判断が必要とされる。まずは献身面での改善を促してみることが必要であり，もしそれでも改善がみられないようであれば，チームから外されるべきであると述べられている。

そして最後に Saladino 氏は，両方の軸において高い能力を示す人材を「スーパースター」と呼び，その人材こそがプロジェクトにとって最も重要な存在であることを指摘している。

彼らは高い技量を持ちながら，なおかつ高いモチベーションを持つ人員であり，不可能を可能にする存在です。それは，さながら白熱する太陽のコアのような存在であり，困難な状況においてもプロジェクトの原動力となってくれることでしょう。彼らは，頼まれなくとも週末も働き続けるでしょう。彼らは，スケジュールを守るために必要とあらば寝袋を持ってくるでしょう。彼らは，他の開発者と比較して３倍の成果を上げることができるでしょう。「スーパースター」たちは，マイルストーンの遅延から我々を守る，最初で最後の防衛線となる存在なのです。

純粋に能力だけに注目してしまうと，「技量を持つ人」と「スーパースター」の違いは見え難くなってしまう。ここでの「スーパースター」は，現場を動かす実力を備えながら，かつ，製品に対する高い参加意識を持つ人々のことを指している。その意識とは，いわゆる「責任感」や「義務感」に似た性質を持っているものの，単なる「一社員としての義務感・責任感」などといったものとは，まったく異なったレベルのものが感じられる。そして，その違いこそが，「スーパースター」の本質となるものなのだろうと思う。

permalink

Cowboy Coders (2)

2004-06-08

Saladino 氏の述べるような「スーパースター」の存在が，製品の品質を大きく引き上げることがあるというのは，ひとつの事実であると思う。しかし，氏の描く「スーパースター」像は，いかにもステロタイプ的なものであり，実に危うい認識の上に成り立っているものであるように思えてならない。

果たして，週末も働き続けることが，品質を左右する要素たりえるのだろうか。あるいは，寝袋を持参して夜も帰らずに働き続けることが，品質を左右する要素たりえるのだろうか。

"Games from Within" の Noel Llopis 氏は，このようなステロタイプ的スーパースター像が信奉される文化的背景を「ヒーロー・カルチャー」として位置付け，また，その文化に居座る未熟なプログラマーたちの存在を「カウボーイ・コーダー」と呼び，揶揄している。

http://www.gamesfromwithin.com/articles/0405/000023.html

不幸なことに，「ヒーロー・カルチャー」は，ゲーム産業における社風として支配的なものとなっています。そして，この文化こそが，カウボーイたちを育む格好の土壌となっているのです。ヒーロー・カルチャーにおいては，己の努力を誇示することが，他の何にもまして評価されます。これは非常に人間的なことではあります。例えば，王国の眼前で血まみれの死闘を繰り広げ，悪のドラゴンから姫君を救い出した英雄がいたとします。あるいは，事が起きるよりも数年前にドラゴンの卵を静かに破壊し，王国に平和の年月をもたらした英雄がいたとします。さて，叙事詩の中に残されるのはどちらの英雄でしょう？ ゲーム産業の多くの企業に関しても，同じようなことが言えるのです。己の体と魂をプロジェクトに捧げようとする人々（あるいは，仕事を沢山していることをアピールするために，遅くまで職場に残っている人々）は，報酬と昇進を得ることになるのです。

Llopis 氏の執筆した他の記事も読んでみると分かるのだけれど，氏はプロジェクトに対するコミットメントの重要性を若干軽視しているきらいがあるように感じられる。それでもなお，「ヒーロー・カルチャー」がこの産業を支配しているという指摘は，ひとつの真実であると思う。

この「ヒーロー・カルチャー」や「カウボーイ・コーダー」といった概念は，ゲーム産業に限った話ではなく，ソフトウェア産業全般においても用いられる概念であるようだ。 C2 Wiki を覗いてみると，それぞれに該当する項目が用意されていることが分かる。

http://c2.com/cgi/wiki?HeroCulture

http://c2.com/cgi/wiki?CowboyCoder

permalink

Cowboy Coders (3)

2004-06-09

結局のところ重要なのは，製品やプロジェクトに対してコミットメントを行うことなのではないかと思う。

http://www.sw.nec.co.jp/individual/011.html

この「コミットメント」という語は，曖昧な意味のまま用いられることが多いのだけれど，今ここの文脈では，「参加意識」や「責任感」などというような要素を伴った深い係わり合いのことを指す。

制作の現場においては，全員が必ずしも高い参加意識を保持しているとは限らない。その点は，他の多くの産業と同様であろうと思う。特にプログラマやアーティストなどは，己の専門分野をモチベーションの拠り所としている場合が多いだろうと思うし，それ自体は決して間違ったことではないと思う。

しかし，個人としてのパフォーマンスではなく，チーム全体としてのパフォーマンスを向上させるには，チームを構成する各個人が製品およびプロジェクトに対するコミットメントを行い，「より良いものを創る」という意識の下に行動をとることが求められる。

例えば，開発中の製品に何らかの問題が見つかったとする。プログラムのバグとか，デザイン上の不備とか，コンセプトレベルでの破綻とか……まあ，何でもいい。そのような問題は常日頃から発生しうるものだ。それについて誰かに尋ねてみると，こんな反応が返ってくることがあるかもしれない ―― 「さあ，知らないね」。これは最もがっかりする反応だ。たとえその問題が己の担当とは異なる範囲のものだとしても，その問題に対して危機感を持つことができないという状態は，「製品を創造する過程に参加している」という当事者的意識が失われていることを表す。

なぜ「知らない」のだろうか。問題の原因を知らないということ自体には非が無い。「知る」という行為に対して必要以上に労力を払わなくとも制作を進めることができるようにするために「担当範囲の細分化」が行われているのだから，知らないのはもっともなことだ。しかし，先の「知らない」という受け答えには，「自分はその問題を関知する意思を持たない」という表明も含まれている。参加する意思の放棄と，責任の放棄……つまり，コミットメントの喪失が発生していると言うことができる。

何らかの問題を発見し，その問題を看過すべきでないと感じたなら，問題提起を行うべきだろうと思う。もし，「問題提起」などという行為が大げさ過ぎると感じられるようであれば，もう少し慎み深いアプローチをとってみるのも良いかもしれない。例えば，そのことについて先輩や上司と話し合ってみるとか，その程度でもいい。その相手が高い参加意識を持っている人物ならば，親身にその話を聞いてくれるだろうし，その問題が然るべき方法によって処理されるよう働きかけてくれるかもしれない。いずれにせよ，問題を放置しておくよりかは，解決される可能性はずっと高くなるはずだ。

日常の様々な場面における判断や行動が，製品やプロジェクトに対してどのような影響を与えうるだろうか……そのようなことにまで常に思考を及ばせることこそが，コミットメントの意味するものであると僕は考える。

一般に，参加意識の高さは労働量の多さに結びつくことが多いように感じられる。しかし，決して「労働量の多さ」が「高い参加意識」の必要条件となることは無い。平均的な労働量でも，十分な結果を出し，なおかつプロジェクトに対してコミットメントを行う人々は，確かに存在する。そのふたつの要素の間に相関性は無いと考えるのが正しいのではないかと思う。

以上のようなことから， Saladino 氏が使ったような「献身」という尺度は，評価の基準としてあまり適したものでないと考えられる。「献身」とは，高い参加意識を持つ人々から，必要に応じて引き出されるものであって，それ自体が当人の制作者としての性質を表すものではない。自分ならば，その代わりの尺度として「参加意識」や「コミットメント」のような概念を用いることだろうと思う。

permalink

Software Requirements and Specifications

2004-06-10

最近，書店で書籍を購入する機会が少なくなりつつある。欲しい品目があらかじめ決まっている場合は，ほとんど Amazon で済ませてしまうためだ。逆に言えば，欲しい品目が決まっていない場合は，書店で購入することになる。買い物のついでに書店に立ち寄り，ふと手にした本が良さげな内容だったりすると，その場で購入してしまうわけだ。しかし，目にした瞬間，突発的に欲しくなる本などというものも，なかなか存在しないわけで，おのずと書店を利用する機会は少なくなってしまっている。

そのような状態にあって，先日，ある本を書店で購入した。 Michael Jackson の「ソフトウェア要求と仕様」だ。

http://www.amazon.co.jp/exec/obidos/ASIN/4775302876

http://w3.shinkigensha.co.jp/books/4-7753-0287-6.html

これは，以前はトッパンから「ソフトウェア博物誌」という題名で出版されていた書籍の復刊版であるようだ（復刊版の出版元は新紀元社）。題名に興味を引かれて立ち読みしてみたところ，数ページほど読んでみただけで非常に面白そうな雰囲気が伝わってきたので，迷わずその場で購入を決めたという次第だ。

この書籍は，ソフトウェア開発の各場面において問題の分析や記述を行う際に，必要となるであろう知識を辞書的にまとめたものだ。特定の方法論に関して触れられているわけではなく，著者が役に立つと考えるアイデアや洞察の類が，書籍全体にちりばめられている。

辞書的な構成をとっているため，項目の順序に意図は無く，前から順に読み進める必要も無い。パラパラとページをめくって，気になる項目を見つけたならば，そこだけつまみ食いするような感覚で読んでいけばいい（著者もそれを勧めている）。項目の例を挙げれば，「記述」，「具象化」，「適用領域」，「反駁可能な記述」，「方法論」，「手抜き」，「ケーニヒスベルグの橋」，等々。それらの項目が，それぞれ単体でも読むことができるくらいコンパクトにまとめられていながらも，少なからず相互に関連する部分を持っており，そこからリンクを辿るように読み進めることもできるようになっている。

重要なのは，この書籍において著者が解説しようとしていることは，「問題を解くための手法」ではないということだ。特定のアルゴリズムや方法論を扱っているわけではない。問題の構造を正しく分析し，正しく理解するための基盤となる知識を与えるものだ。そして，そのことがソフトウェア開発において如何に重要であるか（あるいは，如何に見過ごされているか）ということを指摘しようとしている。

個人的に最も印象的であったのは，「デッカー」 (Dekker) の項目だ。この項目に登場する人物 Thomas Dekker 氏は，排他処理アルゴリズムの考案者として知られる人物だ。

http://www.google.co.jp/search?q=cache:www.eli.hokkai-s-u.ac...

もうひとつ，この項目に登場する「もの」がある。 1980 年代に開発された "Therac-25" と呼ばれる放射線治療器だ。この機器は，排他処理の実装に失敗していたがために，何人もの患者を被爆させ，死に追いやってしまった。以来，この "Therac-25" の過失は，医療関連のソフトウェア開発において忘れられてはならない教訓として語り継がれている。

http://www.smi.stanford.edu/people/felciano/research/humaner...

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Side_bar_1.ht...

ここで著者は，いくつもの「間違った排他処理」の例を挙げることによって，排他処理を正しく実装することが如何に難しいかという事実を伝えようとしている。一見簡単に感じられる問題でも，その奥には恐ろしいほどの複雑性が隠されていることがある。最後に Jackson 氏は，次のように述べることによって，この項目を締めくくっている。

（Dekker のアルゴリズムの改変バージョンを示して） この版は Dekker のものよりも簡単に見える。読者はこの版が正しいものだと信じられるだろうか。あるいは正しくないだろうか。その答に命をかけることはできるだろうか。少々の謙虚さが必要であろうと筆者は思う。小さな問題が難しいはずはありえないとか，数学が自分の仕事には無関係だと考えたい誘惑にかられたときには，いつでも相互排他問題を見つめなおし， Thomas Dekker のことを思い浮かべてほしい。

permalink

History of Programming Language

2004-06-11

040611.jpg

時折， "C" という名前が奇妙な響きに感じられることがある。 "C" とは，もちろん，プログラミング言語の "C" のことだ。この手の産業にかかわる人であれば，プログラマでなくとも "C" という言語の名前ぐらいは知っていることがある。プログラマは，どうやら "C" ってものでプログラムを書いているらしい。けども，その "C" ってのは，一体何なんだろう。何かの名前にしては，ずいぶんと記号的じゃないか……。

"C" という名前の由来は， C 言語の考案者の一人である Dennis Ritchie 氏が，その直前に考案した言語 "B" に由来するというのは，比較的有名な事実であろうと思う。では，その "B" という名前は，一体どこから来ているのだろうか。やはり，それ以前に "A" という言語が存在したのだろうか……この予想はちょっと外れていて，実際には BCPL - "Basic Combined Programming Language" に由来しているようだ。

http://en.wikipedia.org/wiki/B_programming_language

BCPL は CPL を扱いやすく改造したものであり， B 言語はその BCPL を簡略化した言語であるとされている。ここまでは，それなりに筋の通ったネーミングであるように感じられるのだけれど，その次に来る "B" から "C" への推移は，本当にただのユーモアでしかないようだ。

この C 言語の例をとってみただけでも分かるように，ほとんどのプログラミング言語は，その祖先として別の言語との関係を持っている。 O'Reilly が PDF 形式で配布している "History of Programming Language" のポスターは，このような言語間の関係を，単一の図表の中にまとめたものだ。

http://www.oreilly.com/news/graphics/prog_lang_poster.pdf

この図表は非常に面白い。 1954 年に生まれた Fortran を始祖として，様々な言語が発生と消滅を繰り返し，分化や統合を繰り広げた結果として，今日見られる状態となっている。その進化の過程を表したこのポスターは，さながら生物の進化系統図のような概観だ。

このポスターを紹介していた Bob Congdon 氏は，この他に， Éric Lévénez 氏の作成した図表を紹介している。どうやら，前出の O'Reilly のポスターは，この Lévénez 氏の図表を元として製作されたものであるようだ。

http://www.levenez.com/lang/

図表の中身を詳細に覗くには，こちら図表の方が都合良いかもしれない。 O'Reilly の方の図表は，全体のサイズに対して文字が小さ過ぎるため，細部を覗くことが困難になっているためだ。

こうして，プログラミング言語の進化の歴史を俯瞰してみると，今日主流となっている手続き型言語やオブジェクト指向言語の多くは， Fortran と Algol を源流としていることが分かると思う。また，僕が C の次によく利用する言語 Python は， Pascal の流れをくむオブジェクト指向言語 Modula-3 と，命令型言語 ABC の両方を先祖として持っている。

Lévénez 氏は他にも， UNIX や Windows の系統図も作成している。いずれも力作だ。

http://www.levenez.com/windows/

http://www.levenez.com/unix/

特に， UNIX の系統図の方の混沌ぶりは，見ていて非常に面白い。ただ，そのような混乱も 1990 年代の中盤には落ち着きを取り戻し，今ではそれぞれの分派が，互いに干渉することなく己の道を進むような状態となっている。

permalink

Communication

2004-06-14

スケジュールの検討と，その他の雑多なミーティングで一日が終わった。これらの作業は，制作の進行上必要な作業であるからこそやっていることには違いないのだけれど，だからと言って，本来の目的である制作を進めることができていないというのは，非常に歯痒い状況だ。労働量を増やせば解決することができるのかもしれないけれど……それは最後の手段として温存しておきたい。

ミーティングはできる限り少なくした方が良い，というのは定説だろうけども，だからと言って無闇に無くせばいいというものでもない。コミュニケーションに万能の手段は存在しない。口頭でのコミュニケーションや，メールでのコミュニケーション，ミーティングでのコミュニケーションなどは，それぞれに異なる性質を伴っており，それらを目的に応じて上手く使い分けることが，円滑なコミュニケーションを実現する上での鍵となる。

Michael Saladino 氏は，それぞれのコミュニケーションの手段には，「簡便性」 (ease of use) と「厳密性」 (thoroughness) のふたつのファクターが存在すると指摘している。

http://www.gamasutra.com/features/20040423/saladino_01.shtml

「簡便性」と「厳密性」の割合の異なる複数の手段を絡めることによって，効果的な情報の伝達が実現されます。コミュニケーションの改善は，単一のソリューションによって実現されるものではありません。細かなシステムを混合することによって，スループットに大きな変化を引き起こすことができるのです。

メールであれ何であれ，普段から流量の多いコミュニケーション手段は，情報を見過ごされる危険性が高い。メーリングリストを主なコミュニケーション手段に利用しているチームであれば，メールは最も見過ごされる可能性の高いコミュニケーション手段となるだろうし，グループウェア等の掲示板をコミュニケーション手段に利用しているチームであれば，掲示板が最も見過ごされる可能性の高いコミュニケーション手段となるだろう。そこに単純にポストを行ったとしても，もはやそれだけではコミュニケーションを行ったことにはならないというのが実情だ。

直接の口頭によるコミュニケーションは，最も素早く正確に情報の伝達を行うことのできるコミュニケーション手段だ。相手の時間を拘束してしまうという欠点はあるものの，適切に用いることができれば強力なコミュニケーション手段となる。これは，どんなに電子的なコミュニケーション手段が発達したとしても，絶対に見過ごすことのできない要素だ。自宅勤務や遠隔勤務に対して懐疑的にならざるをえないのも，こうした理由による所が大きい。コアタイム無しのスーパーフレックス制なども，同様の問題を抱えているものと考えられる。

ただし，口頭でのコミュニケーションには，それ自体が「一時的な情報の交換」でしかないという落とし穴が存在する。例えばメールによるコミュニケーションならば，その内容が相手の頭の中に伝わったかどうかはともかくとして，その情報は永続的なものとして残り続ける。これが口頭であると，最悪の場合，３歩で失われかねない。

口頭でのコミュニケーションに伴うリスクは，記憶の脆弱性のみではない。当事者が現場から居なくなってしまえば，当然の如く情報は失われてしまう。もし，その人が諸事情で退職してしまったら……あるいは，もし，その人がバスに轢かれてしまったら……これは，日常的な感覚からすれば無視してしまいたくなるような類のリスクではあるものの，決して有り得ない話では無い。

この話題に関しては， Hacknot の記事 "Oral Documentation - Not Worth the Paper It's Written On" が面白い。今回もまた Mr Ed 氏のアンチ・アジャイル節が炸裂している。

http://www.hacknot.info/hacknot/action/showEntry?eid=57

余談になるのだけれど，普段，立ち話のようなインフォーマルなやり取りにおいて決定したことを正確に記録するには，どのような手段を用いるのが適切なのだろうかと思う。多くの場合はメモ用紙や付箋紙でも十分であるものの，「うん，それじゃあ，そうしよう……１年後に」とかいう類の話を紙のメモに書き留めておいても，それはほぼ無意味だ。そういった情報の断片を，後から参照することの可能な形式によって記録することが望ましいと思う。もっとも， OneNote が，まさにそれなのかもしれないけれど……まだそのような使いこなし方を会得することはできていないというのが実情だ。

permalink

Documentation

2004-06-15

コミュニケーションの効率化を図るうえで，文書化（ドキュメンテーション）の作業を避けて通ることはできない。適切な手段によって作成された文書は，集団作業の場において情報の流量を絶対的に増加させる働きを持っている。文書を用いない直接のコミュニケーションでは，情報の流量は個人のスループットに制限され，内容の確実性は個人の記憶力に制限されてしまう。文書であればそのような制限を受けずに情報の伝達を行うことが可能となる。

直接のコミュニケーションを必要とされる場面が多過ぎると感じられるならば，その一部を文書によって代替することができないかどうか考えるべきだ。また，適切な文書を参照すれば解決することのできる問題を，直接のコミュニケーションによって解決しようとしてはいけない。それでは，文書を用意した意味が全く無くなってしまう。直接のコミュニケーションによる問題解決の素早さは十分に魅力的なものであるものの，それは確実に人的リソースを消費してしまう。直接のコミュニケーションは非常手段であることを意識すべきであると思う。

Hacknot の Mr Ed 氏は，前述のように，「口述文書」こと "Oral Documentation" の手法を痛烈に批判している。どうやら，氏自身が実際にその悪影響を被るような状況に居るらしく，半ば怨念のようなものさえ感じられるような文章となっている。

http://www.hacknot.info/hacknot/action/showEntry?eid=57

氏は，別の記事 "Six Legacy Code Antipattern" において，「口述文書」をアンチパターンのひとつとして挙げている。

http://www.hacknot.info/hacknot/action/showEntry?eid=47

「口述文書」の一部は，疲労のために散歩へ出掛けたままとなってしまう。また，ある章は病気のために参照不可能となってしまう。

また，別の記事 "Fear, Uncertainty and Design Documentation" においては，設計文書を不要とする言説に対して執拗な反駁を行っている。ちなみに，この記事の題名はもちろん FUD - "Fear, Uncertainty, and Doubt" を模したものだ。

http://www.hacknot.info/hacknot/action/showEntry?eid=46

この論証を進める上で，私はあらゆる反論（あるいは「弁明」と呼んだ方が良いかもしれない）を受けてきた。その発想と変化に富む反論の数々を完璧に記そうとすれば，ちょっとした本が一冊書けてしまうだろう。その内の主たるものを，以下に記してみよう。

* 厳しいスケジュールにあるが故に，コーディングを始めるのは早ければ早いほど良い。
* 文書はコードとの同期から急速に外れてしまう。
* 自分は，設計文書を用意する必要がある場合には，それを常に後から用意している。
* 誰も設計文書など読みやしない。
* 必要な情報はコードから直接得ることができる。
* 私はソフトウェアを書くために雇われているのであって，文書のためではない。
* 顧客は動くソフトウェアを欲しているのであって，文書ではない。
* 誰も "BDUF" (Big Design Up Front) なんて，もうやりたがらない。
* 過去のプロジェクトにおいて，そのような必要は一度も無かった。
* チームの皆は，システムがどのように設計されているか，既に知っている。
* 良い設計はコーディングを行ったときに初めて現れる。
* コードを書いてしまってから CASE ツールを利用して設計を補うのが良い方法だ。
* 私はソース全体に渡ってコメントを記している。
* コードを書いてみるまでは，ソフトウェアの動作を理解することなどはできない。

たしかに，どれも聞いたことのあるような意見ばかりだ。その内の一部は幾分の真実を含んでおりながらも，「文書を用意しなくとも良い」という理由としては不十分なものであると感じられる。

言い換えれば，上に記したような，設計文書を回避しようとする理由の数々は，次に示す本当の理由に対して理屈を付けているだけに過ぎないのだ。

* 私はドキュメントを書くのが嫌いだ。

自分が普段から気に病んでいるのは，コードと文書の同期に伴われる労力の問題だ。例えば，ライブラリのリファレンスマニュアルなどは，コード側に対して何らかの変更を加えることによって，文書との同期が失われてしまう。この同期を保つには，継続的な文書の更新が必要とされる。ひとたび文書の更新を怠れば，文書の内容は信用されなくなってしまい，誰も文書を参照しなくなってしまう。誰も参照しない文書を更新するには，相当の動機が必要とされる。結果的に，文書は加速度的に「腐って」しまう。

この問題に対する最もシンプルな解決法は，やはり「文書を用意しない」ことであろうと思う。ライブラリリファレンスのようなものであれば，むしろソースと別途に文書を用意する必要性は無いと感じる。文書を用意しなくとも，ヘッダファイルに十分な解説が入っていれば事足りるし，あるいは Doxygen などを利用すれば，ヘッダファイルからまともな文書を自動生成することが可能だ。

Mr Ed 氏も，余すことなく文書を用意すべきであると主張しているわけではない。ここで論点となっている「設計文書」とは，ライブラリリファレンスなどとは異なる存在だ。どんなシステムも，基本となる設計はそう頻繁に変更されるわけではない（むしろ，頻繁に変更されるようならば，そのこと自体が問題であると言える）。必要とされているのは，膨大な文書を継続的に更新する努力ではなく，骨格となる事実を簡潔に述べ，システムの理解に必要とされる情報を正確に伝える手際であろうと思う。

permalink

Omniscient Debugger (1)

2004-06-16

自分が未だに習得することのできていない技能のひとつに，デバッガの操作がある。さすがに覚えた方が良いだろうとは思っているのだけれど，普段からあまりデバッガを利用していないためか，いつまで経っても使いこなすことができないでいる。

デバッガを利用しない大きな理由は，コンパイラの最適化がデバッグの効かないコードを生成してしまうことにある。これが一般的な感覚であるかどうかは分からないけれど，ゲームの開発を行う過程においては，最適化オプションを最高設定にしておくことが多いと思う。一方で，デバッガは基本的に最適化を切った状態で利用するものであるから，最適化を有効にしたままデバッグを行おうとすると，非常に不安定な動作となってしまう。スタックバックトレース程度であればまだしも，ピンポイントでのブレーク指定や，関数内の自動変数の監視などは，ままならなくなってしまうことが多い。

このような場合でも，当該のソースファイルのみを「最適化無し」でコンパイルし直せば，比較的まともにデバッグを行うことが可能となる。しかし，そこでわざわざオプションを操作してコンパイルしなおすというのも，ちょっと面倒な話だ。しかも，そこまでしたとしてもうまく動いてくれない可能性は残されている。結局のところ，いわゆる「printf デバッグ」で手軽に済ませてしまうというのがよくあるパターンだ。

各種開発環境におけるデバッガの使い勝手を比較してみると， Visual C++ (Visual Studio) が圧倒的に有利であると感じられる。残念ながら，自分はあまり使う機会が無いのだけれど，こういった先進的な環境を作り出すために多大な労力が払われているという事実は，開発者の端くれとして心強いことであると思う。例えば，デバッグセッションを中断せずにコードの改変を可能とする "Edit and Continue" 機能などのように，非常に過激な機能をも実現してしまっているところが驚異的だ。

http://www.microsoft.com/japan/msdn/vs_previous/visualc/tech...

permalink

Omniscient Debugger (2)

2004-06-17

デバッガに関しては，例えば Java のように，バーチャルマシン上での動作を前提とした処理系の方が有利であるように感じられる。バーチャルマシンであれば，マシンステートの追跡を行うことが比較的容易となるためだ。ネイティブコードでは，ＣＰＵの機能をトリッキーに活用してようやく観察が可能となるようなことも，バーチャルマシンであれば，一般的なプロセス内の事象としてダイレクトに観察することが可能となる。

Bil Lewis 氏の "Omniscient Debugger" などは， Java であるからこそ実現することのできた，究極のデバッグ環境の一例であると思う。

http://www.lambdacs.com/debugger/debugger.html

この Omniscient Debugger ― 「全てを知るデバッガ」は，従来のデバッガには無かった「時間を遡る」という機能を実現した，革新的なデバッガだ。このデバッガ (ODB) では，バイトコードのステップ毎に，マシンステートに対する変更が逐一記録される。「状態の変化」を常に記録することによって，これまでプログラマにとって自由に触れることの許されなかった領域である「時間軸の操作」を，遂に操作可能なものとしてしまったということだ。

「逆ステップ」は，字面上ではささやかな機能であるものの，実際にはデバッガの利便性を大きく広げる可能性を秘めている機能であると考えられる。「逆ステップ」が可能になると，例えば，問題の発生した箇所から時間を遡り，その原因となる箇所を突き止める，というようなデバッグ手法を用いることが可能となる。従来のデバッガでは，原因となりそうな箇所の付近にブレークポイントを仕掛けておくとか，関連のありそうな変数に監視式を仕掛けておくとか，そういったパッシブな方法でしかデバッグを行うことができなかった。これが ODB であれば，よりアクティブな方法でのバグの追跡が可能となる。

明らかに指摘されうる ODB の欠点は，イベントの記録のために膨大なメモリ領域が必要とされるということだ。例えば， ODB が開発された環境である Power Mac G3 (700 MHz) においては，１イベントあたりの平均実行時間は約２マイクロ秒であるとされている。すると，僅か２０秒ほどで 2GB の物理メモリ空間が埋め尽くされてしまう計算となる。 Lewis 氏によれば，この問題は，次世代プロセッサに搭載されるであろう 64bit アドレス空間が存在すれば，物理的に改善を行うことが可能になるだろうと述べられている。

Lewis 氏は，この Omniscient Debugger の技術は，本来処理系を選ぶことはなく，例えば C/C++ に対して適用することも可能であると指摘している。ただし，デバッグの対象がネイティブコードとなると， Java のバイトコードと比較してイベント数が膨れ上がることが予想されるため，実現はやや難しくなるだろうと思う。また，外部 I/O などのように処理系から把握することの不可能な要素が存在する場合に， ODB がどのような対処を行うのかという点に関して， Lewis 氏の論文では特に触れられていなかった。

ネイティブコードに対して Omniscient Debugging を行うことは難しいとしても，例えば CLI などに対しては適用が可能なのではないかと思う。

http://msdn.microsoft.com/net/ecma/

次世代 Windows においては， C# や Managed C++ を始めとする Managed Code 環境 (CLR) が主流になると言われている。 CLR の登場によって，処理系と統合環境の間の結合はより密なものへと変化しようとしている。その際に，例えば ODB のような，革新的なデバッグ機能が搭載されることを期待している。

http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

permalink

The Two Things

2004-06-18

今週は様々な変化の起こった一週間だった。元々きわどかったスケジュールは更にきわどいものとなり，その復旧の当ても，現状では恐ろしく不透明なものとなっている。もともと切迫性の高い性分であることから，全体像が見え難くなってくると，必要以上に慌ててしまい，実際のキャパシティよりも低めに目標を見積もってしまうという癖が，自分にはある。そのような誤った見積もりを避けるためにも，できる限り早くスケジュールの確認作業に着手しなくてはならない。

しかし，今の状況はまさに，「プロジェクト管理における２つの原則」かもしれない。

プロジェクト管理における２つの原則
１．スケジュールは，大抵ずれる。
２．すなわち，スケジュールの「ずれ」をどう管理するかという話になる。

「２つの原則」 ― "The Two Things" は，経済学者の Glen Whitman 氏が編纂を行っている小ネタ集だ。

http://www.csun.edu/~dgw61315/thetwothings.html

事の始まりは，酒場での与太話にある。

数年前のこと，私はとあるバーで見知らぬ人と閑談を交わしていた。私が経済学者であることを彼に話すと，こう言い返してきた ― 「へえ……んじゃあ，経済学で言うところの『２つの原則』って，なんだい？」
私は如才無く言い返した ― 「え？」
「ほら，あれだよ……どんなもんにでもさ，本当に知らなきゃなんないことは２つぐらいしかないってやつ。ほか全部は，それの応用か，そうでなきゃ重要でないだけなんだな」
「なるほど……それじゃあ，経済学の『２つの原則』は，こんな感じかな。ひとつ，『経済とは見返りの問題である』。ふたつ，『経済にタダ飯は存在しない』」

以来 Glen 氏は，様々な分野のプロフェッションに「２つの原則」を聞いてまわり，その内容を件のページにまとめている。その多くは基本的にジョークの類であり，くだらない与太話以上の何物でもないのだけれど，その極限までに簡略化されたコンセプトは，ある側面において物事の本質をうまく捉えることに成功しているようにも感じられる。

笑いを誘おうとしている「２つの原則」は，基本的に２段オチの構図になってしまうようだ。実際には，２つの独立した事柄について触れている「２つの原則」の方が洗練されているように思える。

史学における２つの原則
１．全ての物事には前例が存在する。
２．資料は常に嘘をついているものの，我々が持ちうるものはそれだけである。
哲学の研究における２つの原則
１．誰一人として正しくない。
２．全ては相対である。
法学における２つの原則
１．誤った行いに対しては予測されうるコストを伴わなくてはならない。
２．法律は，その関与者の妥当な期待を守らなければならない。
世界征服における２つの原則
１．分割し，征服せよ。
２．冬にロシアを侵略してはならない。
ソフトウェア工学における２つの原則
１．バグの無いソフトウェアは存在しない。
２．遅延の生じているプロジェクトにマンパワーを投入すると，プロジェクトは更に遅れる。

ともかく，楽観に基づいたスケジューリングを行っている以上，どうしてもスケジュールは遅れる方向へとずれていってしまう。すると，その遅延をいかに解消するかという話に陥ってしまいやすい。遅延の生じている状況においては，本当に必要とされているものと，本当は必要とされていないものの区別を明確に行うことが肝心だ。その点に関して，如何にして速やかに関係者の合意を得るかということが，目下の課題として残されている。

permalink

Graphviz

2004-06-21

040621.png

そろそろ，土日はフルに出社するペースになってきた。先月までは死ぬほど忙しそうだった隣のセクションのプロジェクトも，数週間前にマスターアップを迎え，最近は休日出社する人もまったく見かけなくなった。人気の無い静かなオフィスの中で，独り集中して作業を行うことができるのは喜ぶべきことだけれど，空調が切れてしまっているがために，異様な暑さとなっているのが玉に瑕だ。時間外空調は日中のｘ倍の値段が付く。制作費全体からすれば些細な額ではあろうけども，些細だからと言って見過ごしてはならんというのが近頃の風潮だ。まあ，バジェットを１円でも引き下げるためだったら，どんな努力も惜しまんさね……と，汗だくになって仕事に勤しむ様は，自分の中に潜むハングリー精神を確認しているようで，奇妙に心地よい。単なる自己満足。人知れず，誰にも迷惑をかけない自己満足だったら，それも悪くはないはずだと考える。

休日の間は，平日の作業からあぶれてしまったものをフォローしつつも，平日にはやっていられないような脇道的な仕事にも手を染めてみている。例えば昨日は，以前からやってみようと考えていた階層ステートマシン構造の視覚化を行ってみた。

階層ステートマシンの構造（各ステートクラス間の依存関係）は，閉路を持たない有向グラフとして表すことができる。このようなグラフ構造を視覚化するのに便利なツールが "Graphviz" だ。

http://www.research.att.com/sw/tools/graphviz/refs.html

http://www.graphviz.org/

"Graphviz" は， AT&T の Information Visualization Research Group によって開発された，オープンソースのグラフ構造視覚化ツールだ。任意のグラフ構造を自動的に視覚化し，その結果を画像ファイルとして出力してくれる。自分は， Doxygen がこのツールを利用していることから，その存在を知った。 Doxygen では，ヘッダファイルの依存関係を視覚化するために， Graphviz の "dot" コマンドを利用しているとのことだった。

dot コマンドの入力ファイルは，実にシンプルな構造をしている。例えば，サンプルファイルの中にある「ＵＮＩＸの進化」のグラフの入力ファイルは，以下のような内容になっている。

digraph unix {
  "V7M" -> "Ultrix-11";
  "8th Edition" -> "9th Edition";
  "1 BSD" -> "2 BSD";
  "2 BSD" -> "2.8 BSD";
  "2.8 BSD" -> "Ultrix-11";
  "2.8 BSD" -> "2.9 BSD";
  "32V" -> "3 BSD";
  "3 BSD" -> "4 BSD";
  "4 BSD" -> "4.1 BSD";
  "4.1 BSD" -> "4.2 BSD";
  "4.1 BSD" -> "2.8 BSD";
...
}

http://www.research.att.com/sw/tools/graphviz/examples/

これならば自動生成することも難しくなさそうだ。 Python の re モジュール（正規表現モジュール）を利用してソースファイルの解析を行い，階層ステートマシン構造を分析し，最後にその結果を dot 形式として出力する。スクリプト言語の力をもってすれば，このようなツールを作成するのに大した手間は要されない。十数分後には，なんとか目的を適える代物が出来上がっていた。この手の「クイック・ハック」を行う瞬間は，スクリプト言語を習得していて本当に良かったと思わせてくれる瞬間でもある。

結果は上々……複雑化する一方であったステート間の関係も明確なものとなり，全体の構成のバランスを確認することも可能となった。現在のシステムでは，下位ステートを異なる上位ステートの間で共有しているから，下位ステートの仕様に変更を加える際には，そのステートがどのステートから参照されているか確認し，その関係に影響を与えうることを承知したうえで変更を行わなくてはならない。そのような場合に，この構造図は，依存関係を把握する助けとなってくれるに違いないと考えている。

permalink

Impossible Question

2004-06-22

最近は色々と，プログラム以外の用件に係ることも少なくない。その中でも人事関係の仕事は，比較的プレッシャーが高く，また，未だにコツを掴むことができていないという点において，非常に難しい部類の仕事であると感じる。自分自身や，自分に身近な人々でさえも，正確に分析することは難しいというのに，ましてや，ペラ２枚の履歴書と１５分の面接だけで，一体どれだけのことを知ることができるものだろうかと思う。

"Joel on Software" でおなじみの Joel Spolsky 氏は，記事 "The Guerrilla Guide to Interviewing" において，人事面接を行う際に重要となるポイントについて述べている。

http://www.joelonsoftware.com/articles/fog0000000073.html

氏の提示する方針は，比較的小規模なパッケージソフトウェア開発会社であるところの Fog Creek Software 社としての立場が反映されたものであり，その内容は必ずしも万人にとって参考になるものではないと感じる。 Joel 氏は，少しでも不安に感じる要素が残されているようであれば，その応募者は採用するべきでないと述べている（むしろ，そのことを最も重要な点として挙げている）。しかし，自分の例で言うならば，採用を出す・出さないという判断は，社やプロジェクトの都合が大きく反映される部分であり，応募者の絶対的な素質や能力といった部分は，その前提に対する補正値として働くというのが，多くの場面における実情であるように思える。

ただ，氏が面接において用いているという「不可能な質問」のテクニックは面白いと感じた。

３番目の質問は，「不可能な質問」だ。これは楽しい質問だ。答えられる可能性の無い質問を応募者に対して投げかけ，それがどのように扱われるかという過程を観察するものだ。「シアトルには何人の検眼士がいますか？」 「ワシントン・モニュメントの重量はは何トンありますが？」 「ロサンゼルスには何個のガソリンスタンドが存在しますか？」 「ニューヨークには何人のピアノ調音士がいますか？」
聡明な応募者ならば，自分は己の知識を試されているのではないということに気付き，即興で答えを導き出そうとするだろう。「はい，ええと，ロスの人口は７００万人ほどですから，その人々が１人あたり２．５台の車を持っているとすれば……」 もちろん，その内容が激しく間違っていたとしても構わない。重要なのは，問題に取り組む態度だ。もしかしたら，ガソリンスタンドの許容数を求めようとするかもしれない。「満タンにするには４分ぐらいかかるはずで，ひとつのガソリンスタンドには約１０個程度のポンプが装備されていて，それで，１日に１８時間ぐらい営業してるはずですから……」 あるいは，面積からそれを求めようとするかもしれない。時には，彼らの持つ創造性に驚かされることさえもある（ここにロスの電話帳は置いてないか？ と聞かれて，驚いたこともある）。それらはいずれも良い兆候だ。
それほど聡明でない応募者ならば，質問に混乱し，うろたえ始めるだろう。彼らは，まるで火星人でも見るかのごとく，あなたをただ見つめ続けることだろう。こういった場合は，彼らを導いてやる必要がある。「もしあなたがロサンゼルスほどの規模の町を創り上げるとしたら，何個ぐらいのガソリンスタンドを配置しますか？」 簡単なヒントを与えるのも良い。「ガソリンタンクを満タンにするにはどの程度の時間が掛かりますか？」 まったく聡明でない応募者の場合は，それでもなお，愚鈍にもあなたの助けを待ち続けることだろう。そのような人々は問題解決者であるとは言えない。我々は，そのような人々と共に働きたいとは思わないだろう。

このような，「自ら問題に取り組もうとする態度」と，「与えられた問題を解決する機転」は，現場において非常に重要な能力であると感じる。何をするにしても，解答までの誘導を行わなければならないようでは，マンパワーとして計上することはできても，集団としての生産性に大きく貢献することは難しい。そのような能力を，このように簡単な質問によって推し量ろうというアイデアは，なかなか面白いものであると感じた。

permalink

Full Spectrum Warrior

2004-06-23

040623.jpg

近日中にマイルストーンの予定があるため，しばらくの間は忙しい日々が続く見通しとなっている。実は最近，個人的にプレイしてみたいと考えているゲームがいくつか発売されているのだけれど，今回のマイルストーンを越えるまでは，それらのゲームもおあずけしておかなければならなさそうだ。

それらのゲームの中でも，最も注目しているのは， Pandemic Studios の "Full Spectrum Warrior" だ。

http://www.fullspectrumwarrior.com/

AI ネタ絡みで以前から注目していた製品なのだけれど，発売日未定の状態からチェックを怠っていたところ，いつの間にか完成してしまっていたようだ。北米では 6/1 に Xbox 版が発売されている。

評判のほどを調べるために，お馴染み GameRankings.com を覗いてみたところ，平均 84 ポイントという評価が付けられていた。「傑作ではないけれど，良作である」というような評価であると思う。

http://www.gamerankings.com/htmlpages2/914949.asp

ゲームの内容に関しては， GameSpot 辺りのムービーを観てみるのが分かりやすい。

http://www.gamespot.com/xbox/strategy/fullspectrumwarrior/me...

余談だけれど，最近の GameSpot は，ムービー資料が充実していて面白い。話題作にはビデオレビューも用意されており，実際に動く画面を観ながらレビュアーのコメントを聞くことができる。

"FSW" のゲーム内容に関しては，お馴染み Jamie Fristrom 氏が簡単な感想を述べている。

http://www.gamedevblog.com/2004/06/notes_on_full_s.html

このゲームは，画面写真を一瞥すると，普通の戦争モノのＴＰＳ（三人称視点シューター）のように見えてしまうかもしれない。しかし実際には，このゲームはシューターの類ではない。プレイヤーは，特定のキャラクタを直接に操作するのではなく，複数のキャラクタに対して指令を与えることによって，間接的に操作を行うことができる。どちらかと言えば，シューターよりもストラテジーに近い趣を持つゲームであるようだ。

Fristrom 氏は，このゲームを，「パズルとリソースマネジメントのゲームである」と評している。他のレビュー記事にも似たような記述を見つけることができる。 FSW のシステムを構成する最も特徴的なルールは，「物陰に身を隠している限り，弾が当たることは絶対に無い」という仕様だ。そこで，敵の攻撃に身をさらさないような物陰を選びつつ，抑制射撃と移動を交互に行うことによって敵に接近していく……というような戦略をとることになる。まさに "Fire & Motion" をシステム化した戦略ゲームであると言うことができるかもしれない。

ただ残念なことに，このゲームは北米向け Xbox 版しか発売されていない。一応，ＰＣ版の発売は９月に予定されているようだ（それ以外の機種への移植は予定されていない）。日本向け Xbox 版が発売されるという話は今のところ耳にしていないから，とりあえず９月まで待ってみる必要がありそうだ。

permalink

Compatibility (1)

2004-06-24

この世の中で，最も高度な上位互換性を実現しているソフトウェアは何かと問われれば，それは恐らく Windows ではないだろうかと，自分なら答えるだろうと思う。 Microsoft の互換性に対する執着は広く知られているものの，その陰には実に地道な努力の積み重ねが存在することは，あまり知られていないかもしれない。 Raymond Chen 氏のブログ "The Old New Thing" を読んでみれば，同社の技術者や経営陣が，互換性に対して格別の配慮を払っていることがよく分かると思う。

http://weblogs.asp.net/oldnewthing/

オペレーティング・システムの分野における上位互換性は，技術的に見て非常に難しい問題だ。たとえ，どんなに高度な技術が存在したとしても，完全な上位互換性を保つことは困難を極める。アプリケーションを作る側が勝手気ままにコードを書いてしまえば，互換性を破綻させることはいともたやすいためだ。だからと言って，アプリケーションベンダに対して特別な配慮を求めることも難しい。ベンダ側に互換性を放棄する意思があれば，その意思を受け入れざるを得ない。 Windows ロゴを取得する過程においてある程度の要求を提示することが可能であるものの，一般的には自由意志に頼らざるを得ないというのが実情なのだろうと思う。

そこで，無理にでも互換性を保つために，個々のアプリケーションに対してパッチや特殊処理を適用するということが，製品版の Windows において実際に行われている。この辺りの事情については，件のブログの記事 "Why not just block the apps that rely on undocumented behavior?" において詳しく述べられている。

http://weblogs.asp.net/oldnewthing/archive/2003/12/24/45779....

氏は， Windows における互換性への配慮の一例を知る方法として，レジストリの "Compatibility" セクションを覗いてみることを勧めている。このセクションには， Windows 3.0 から Windows 3.1 へ移行する際に障害の発生したアプリケーションが列挙されている。実際にレジストリエディタを使って覗いてみれば，実に数多くのアプリケーションがここに列挙されていることが分かると思う。中には自社製品も含まれているところがご愛嬌だけれど……ともかく， Windows の黎明期から既に，互換性に対して特別な配慮が払われていたことが，ここに示されている。

Windows 2000 と Windows XP の間の互換性に関しては，WINDOWS/AppPatch ディレクトリの中にある DLL と Appfix パッケージによってサポートが実現されている。これらのファイルの役割と， XP において実装されている互換性技術の詳細に関しては， Microsoft TechNet の記事が参考になる。

http://www.microsoft.com/japan/technet/prodtechnol/winxppro/...

実際に sysmain.sdb や apphelp.sdb の中身を覗いてみれば，やはりここにも数多くのアプリケーションが列挙されていることが分かると思う。もう近頃となっては，互換性の持つ重要性というものも一般に認識されるようになってきているのではないかと思うのだけれど（互換性を失ってしまうことは，アプリケーションベンダにとっても痛手であるはずだ），それでもなお，互換性に関する問題が解消したわけではないということが，端的に示されていると思う。

一方， Microsoft も，決して善意でこのような配慮を行っているわけではない。上位互換性を保ち続けることが，自分らのビジネスにとって如何に重要なファクターであるかということを理解しているからこそ，互換性を保ち続けてきたわけだ。互換性を保つことをやめてしまえば，多くの顧客もまた Windows のバージョンアップをやめてしまうだろう。 Chen 氏によれば，業務用アプリケーションの分野においては，今もなお多くのソフトウェアが 16 bit 環境や DOS 環境をベースとして動いているとされている。氏が， 16 bit サポートの放棄を主張する技術者達に対して「まだその時ではない」と警告を発する理由も，ここにあるということだ。

http://weblogs.asp.net/oldnewthing/archive/2004/03/01/82103....

permalink

Compatibility (2)

2004-06-25

Raymond Chen 氏の記事の中でも個人的に興味を引かれたのは， Windows の上位互換性を実現するうえで，ゲームが重要なファクターとして扱われているという事実だ。記事 "Why not just block the apps that rely on undocumented behavior?" において，氏は次のように述べている。

Windows 95 において，私の携わったアプリケーション互換性の仕事はゲーム方面に集中した。ゲームはコンシューマ・テクノロジーの分野において最も重要なファクターだ。標準的なＰＣに付属されるビデオカードの性能は年々良くなって行くだろう。何故ならゲームがそれを必要としているからだ（一方で Outlook などは，ビデオカードが秒間２０万だか２０億だかのポリゴンを描画できたとしても，まったくもって構いやしない）。そしてもし，あなたの持っているゲームが最新バージョンの Windows 上で動かなければ，恐らくあなたはアップグレードしようとは思わないだろう。

http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.a...

これは少し意外なことでもあった。当時の Microsoft がゲームの動作に関してそれほどまでの配慮を払っていたとは思いも及ばなかったからだ。このような特殊な配慮の行われた例としては， Windows 版の初代 "SimCity" を挙げることができる。元記事は Joel Spolsky 氏の "Chicken and Egg Problems" だ。

Windows 3.x 版の SimCity を書いた Jon Ross 氏が私に語ったところによれば，氏は件のゲームにおいて，解放されたばかりのメモリをリードするというバグを誤って残してしまったそうだ。これは Windows 3.x ならば問題無い。メモリはどこにも移動しないからだ。さて，ここからが素晴らしいところだ。ベータバージョンの Windows 95 を試してみたところ，案の定 SimCity は動かなかった。そこで Microsoft はバグの追跡を行い， SimCity の監視を行う特殊コードを Windows 95 に組み込んでしまった。そのコードは SimCity が動いていることを検出すると，メモリアロケータを特殊なモードへ移行させ，メモリをすぐには解放しないような設定にしてしまう。これは，後方互換性に対する執念の一例であり，これこそが人々を Windows 95 へアップグレードさせようとする要素であったわけだ。

http://www.joelonsoftware.com/articles/fog0000000054.html

この件に関しても，もちろん Microsoft が自ら善意を働かせたというわけではなく， SimCity が多くのユーザにとって重要なアプリケーションであることが予想されたからこそ，このような措置がとられたのだろうと思う。

このような個々のゲームに対する特殊対応は，上で挙げたような昔話ばかりでなく，最近でもしばしば行われている措置であるようだ。 Chen 氏のブログにある記事 "Do not underestimate the power of the game Deer Hunter" は，ゲーム "Deer Hunter 4" と Windows XP SP2 beta の間の奇妙な関係について明かしている。

昨年の１２月にリリースされた Windows XP SP2 Beta の準備期間中に，５つのバグのリストが提示された。これらのバグは非常に致命的であるがゆえに，すべて修正されるまでベータリリースを延長することはやむをえないとマネジメント陣は判断した。
そのバグリストの３番目は，こんな感じの内容だった ― 「Deer Hunter 4 が動かない」
つまり， Deer Hunter は，ベータリリースを止めるほどの力を持っていたわけだ。

http://weblogs.asp.net/oldnewthing/archive/2004/06/04/148427...

"Deer Hunter" とば，「鹿狩りゲーム」のベストセラーとして有名な，あのゲームだ。

http://www.atari.com/us/games/dh5_pc/

記事に対するコメントによれば，特殊なコピープロテクションを施していることが仇となり， SP2 Beta で動かなくなってしまったということのようだ。それにしても，「鹿狩りゲームが動かないからベータを延期」というのも， Microsoft のアプリケーション互換性に対する姿勢を端的に表しているようで面白いと思う。

permalink

Compatibility (3)

2004-06-28

Raymond Chen 氏のブログでは，他にも Windows の互換性に関連する数々の逸話が紹介されている。それらの逸話において印象的なのは，保証外の実装を行ってしまっているソフトウェアさえも互換性の対象として取り込んでしまう貪欲な姿勢だ。記事 "When Programs grovel into undocumented structures..." において氏は， Windows 9x から Windows 2000 への移行の際に不具合として浮上した幾つかの「問題」に関して触れている。

http://weblogs.asp.net/oldnewthing/archive/2003/12/23/45481....

ここに挙げられている三つの例は，いずれも相当に凶悪なハックを行ってしまっている。このような「行儀の悪い」ソフトウェアが互換性に関して問題を抱えていたとしても，それは当然のごとく開発者の責任だ。それでも， Chen 氏をはじめとする Microsoft の技術者達は，これらのソフトウェアを問題無く動かすべく多大な労力を費やしている。そうしなければ，たとえ原因は何であれ，ユーザに責められるのは Windows であるということを，十分に理解しているためだ。

もし，あなたが次バージョンの Windows にアップグレードした際に ― (a) ディスクの破損 (b) エクスプローラーの散発的なクラッシュ (c) お気に入りのプログラムの不安定化 ― のいずれかが発生した場合，あなたはプログラムを責めるだろうか？ それとも Windows を責めるだろうか？

仮に，プログラムを責めるとしよう。問題は，どのプログラムがその対象であるか，ということだ。特に，症状が (a) や (b) の場合，「何が不正なプログラムであるのか？」という問いに対する答えは明白でない。

ましてや，一般的な消費者にとってみれば，不具合の原因など全くもって明白でない。当然，疑われるのは Windows 自身であり，事情がどうであれ，次バージョンの Windows は不安定な OS として罵られることだろう。それを防ぐためであれば，不正な実装を持つソフトウェアさえも包容してしまおうというのが Microsoft の姿勢であることが分かる。

この思想と対極にあるのが Macintosh であり，そのことが，これら二つの OS の明暗を分ける要因の一つであった ― というのは， Joel Spolsky 氏の意見だ。

http://www.joelonsoftware.com/articles/APIWar.html

（Chen 氏的な思想の概要を示したうえで） 多くの開発者や技術者達は，この思想に賛同しないだろう。もし，アプリケーションが何か行儀の悪いことをしてしまっていたり，公開されていない挙動などに依存してしまっている場合，それらのアプリケーションは OS がアップグレードすると同時に断絶されてしまうべきだと考えるだろう。 Apple 社の Macintosh OS の開発者達は，常にこの見解を保ってきた。それがゆえに，初期の Mac のソフトウェアのうち，現在も動くものは非常に少なくなってしまっている。例を挙げれば，当時の開発者たちの多くは，想定されたソフトウェア割り込みを利用するのではなく，割り込みテーブルに格納されたポインタをコピーし，それを直接に呼ぶことによって，アプリケーションを速く動すことを試みていた。 Apple の公式バイブルであるところの "Inside Macintosh" には，「するべきではない」と付記されているにもかかわらず，彼らはそれをやってしまっていた。それは，実際には動いてしまうだろうし，より速く動いてしまうだろう……次のバージョンの OS がリリースされるまでは，だ。それ以降，それらのプログラムはまったく動かなくなってしまう。結果として，そのアプリケーションを製作している会社が潰れてしまったとしても（事実，ほとんどがそうなった），まあ，ご愁傷様ということだ。

コンシューマゲーム機向けのソフトウェア開発においては，「行儀の悪い」ソフトウェアの問題とは殆ど無縁であると感じられる。メーカー側から厳しいマスター要求項目が提示されるため，それを厳守しようとすれば自ずと互換性の問題は解決されなければならないわけだ。

それでも， PS2 程度まで複雑なアーキテクチャともなると，偶然に頼ってしまう部分がどうしても潜在してしまうのではないかと思えてならない。もし， DMA の終了するタイミングが少しでも違ってしまえば，あるいは，キャッシュの動作が少しでも違ってしまえば，あるいは， DVD の読み込み速度が少しでも違ってしまえば，あるいは，あるいは……。そのように考え始めると，自分らの制作しているソフトウェアが，将来の機種においても動作可能であるかどうかという点に関して，完全に確信することはできなくなってしまう。

permalink

API War

2004-06-29

そもそも，これらの互換性の話題を取り上げていたのは， Joel on Software の記事 "How Microsoft Lost the API War" だった。

http://www.joelonsoftware.com/articles/APIWar.html

この記事において Joel 氏は，近年 Windows プラットフォームの持つ優位性が徐々に失われ始めているということを， API の観点から論じようとしている。その論旨はごくありふれたものであるものの， Microsoft 社におけるキャリアを有しており，普段は親 Microsoft 的な意見も度々見られる氏が，ここであえてこのような発言を行うということに関して，興味を引かれるものがあった。いつになく長い文章となっているのは，多くの言葉を補うことによって，その発言の背景にある思考を正確に伝えようという意図があるようだ。

結局のところ，この記事において Joel 氏の言わんとしていることは， Longhorn プラットフォームの存在意義の否定であると言うことができると思う。 Microsoft は，混沌に満ち溢れた Windows アーキテクチャの世界を Longhorn アーキテクチャ (WinFX) によって一新しようとしている。埃をかぶった過去の遺産を引きずりながら歩み続けるのではなく， WinFX と CLI (Common Language Infrastructure) によって美しく統合された新しい世界を作り出そうとしている。しかし Joel 氏に言わせれば，そのような試みも，混沌の中に新たな混沌の種を植え付けようとしているだけに過ぎない。文中に登場する次の例え話が，事態を的確に表している。

話は少し逸れるが，ブログに用いられるシンジケーション配給フォーマットの，理不尽かつ政治論争にまみれた世界の行方を追っている人ならば，そこに同じものを見出すことができるだろう。 RSS は様々な異なるバージョンへと分割される一方で，不明瞭な仕様と政治論争ばかりが生み出されている。それらの問題を全て一掃するべく "Atom" と呼ばれる新たなフォーマットが作り出されたものの，それは結果として，様々なバージョンの中に Atom が加わっただけに過ぎず，不明瞭な仕様と政治論争は生み出され続けた。ある２つの対抗する勢力を統合するために新たな３つ目の要素を作り出すという行為は，結局のところ，３つの対抗する勢力を作り出すことにしかならない。これでは，何も統合されることは無いし，何も修正されることは無いのだ。

Joel 氏の論調には，実利主義に基づいた諦観の様相が垣間見える。結局のところは，デスクトップ分野において Microsoft が如何に奮闘しようとも，時代はウェブアプリケーションを受け入れる方向へと流れようとしている。ウェブアプリケーションは，様々な要素において致命的な欠点を抱えているものの，インストールに必要とされるコストをほぼ無くしているという点において，絶対的なアドバンテージを有している。多くの消費者にとってそのアドバンテージは決定的なものであり，それが故に，デスクトップアプリケーションの一部はウェブアプリケーションへと移行していくものと考えられている（その移行は既に始まっている）。そしていずれは， Win32 を基盤として繁華を極めた Windows ソフトウェア文化も，その絶対的な優位性を失うことになるだろう。

問題なのは， DOS から Windows への進歩と比較した場合に， Windows XP から Longhorn への進歩は，それほど大きなものではないということだ。恐らく，人々に新しいコンピュータとアプリケーションを買わせるほどの力は持っていないだろう……いや，もしかしたら持っているかもしれないし， Microsoft にとってみれば，そうさせる必要があるはずだ。しかし，私がこれまで目にしてきたものの中には，それを確信させるようなものは無かった。 Microsoft の行った多くの「賭け」は，外れようとしているのだ。

氏は，今はもう 1990 年代とは状況が違うのだと主張する。 90 年代においては，ＰＣの性能は日進月歩の勢いで向上し，それに伴ってアプリケーションの使いやすさも顕著に改善されていった。消費者は矢次早にＰＣを買い替え，その度に新しい Windows を購入していった。しかし，一般的なＰＣの性能が，日常の用途には十分過ぎるほどのレベルにまで行き着いてしまった今となっては，新しい Windows を購入する理由もまた存在しなくなってしまっている。氏が危惧しているのは，その「購入するに足る理由」を備えることなく，ただ過去の負債を清算するためにアーキテクチャの革新を行おうとすれば，それは無為に終わるだろうということだ。

permalink

Hashing (1)

2004-06-30

ハッシングのテクニックには，不思議な魅力があると感じることがある。ひとつには，数学的な裏付けの難しさと，もうひとつには，アルゴリズムとしての応用性の高さがある。前者はひとまず置いておくとして，後者に関しては，利用するうえで否が応でも実感することではないかと思う。ハッシュテーブルを用いた検索処理が唯一定数オーダーでの実行を可能とするというのは，アルゴリズムの基礎において習う事実であるし，他にも，メッセージダイジェストとしての応用や，フィンガープリントとしての応用など，検索以外にも用途は多岐に渡る。いずれにおいても，シンプルな処理であるにもかかわらず，非常に強力な効果を得ることができるという点が，魅力の元となっている特徴だ。

応用に問題は無いとしても，疑問として残るのは，特定のハッシュ関数に対して数学的な裏付けを行うことができない（理解することができない）という点だ。自分は，数学はよく分からないから，何をもってハッシュ関数の信頼性を計るべきなのかも，よく分からない。理想的なハッシュ関数とはどのようなものなのか？ 果たして MD5 は衝突を起こすことがあるのか？ どのようなメッセージの集合に対してならば，衝突の無いことを保証することができるのか？ あるいは，そのような前提を置くべきではないのか？

先日， Raymond Chen 氏が，自身のブログ "The Old New Thing" において，ハッシュ関数の脆弱性について触れていた。

http://blogs.msdn.com/oldnewthing/archive/2004/05/19/134937....

この記事において氏は，ハッシュ関数の衝突を故意に引き起こす方法に関して述べている。

誤って衝突を発生させることが簡単なわけではない。いつか，開発チームが MD5 の衝突を確認したという噂を聞いたことがあったが，これは単なる噂に過ぎないし，その証拠を得たわけではない。まあ恐らく，実際に起きたのは，開発チームの誰かが乗ってた MR2 が衝突したとか，そんなところなんだろう……。

それはともかくとして……氏は，どのようなハッシュ関数も，その内部ステートを初期状態に戻してしまうようなメッセージを生成する規則を得ることができれば，自在に衝突を発生させることが可能であるとしている（氏はこれを「ハッシュリセット攻撃」と呼んでいる）。しかし，その方法を利用した場合も，メッセージ長は確実に増えてしまうわけだから，ハッシュ値とともにメッセージ長も確認するようにすれば，安全性を向上させることができる。

permalink