それは仕様か？
2009年04月19日04:48
５年前僕がようやっと、しがらみだらけの会社を辞めて自由になったころ、僕はネットで文章を書き始めた。 で、何を使って文章を書こうかなと思ったとき、ブログを思いついた。 で、ネットでプログラミングについて書き始めた。 ブログを開設して３日目ぐらいで、「それは仕様か？」っていうブログを書いている子が絡んできて、論争になった。
この彼のブログのタイトル＝「それは仕様か？」っていう言葉は、プログラマにとってはとても有名な言葉で、関連した大きな論争があるのだが、これには若干説明が必要だろう。 例えば、明らかに間違った動作をしているプログラムがあったとする。 これに対してソフトウェアベンダーに苦情を言うと、それを修正する代わりに「それは仕様です。」という答えが返ってくることがある。
それは例えばこういうことだ。 Internet Explorer7 は エラー処理に変な不具合がある。 ウェブプログラムの間違いでプログラムがエラーを報告すると、Internet Explorer 7 はそれを報告しないで、無視してしまう。 Firefox にはこういう問題は無い。 これのおかげで、Firefox と Internet Explorer 7で、別なプログラムを用意する必要が出てしまう。 これはプログラマにとってとても面倒なことなのだ。 プログラマだけならず、ビジネス的に見ても、コスト的に大きな影響が現れる。 メンテナンス料が二倍かかるようになってしまうからだ。
この動作はw3cなど標準制定機関で作られた標準動作からもかけ離れている。 これは明らかに間違いなのだ。 だから、コストを二倍かけるよりは、マイクロソフトに修正してもらった方がありがたいと考えるのが、人の情というものだ。 だけど、こういう問題をマイクロソフトに報告すると、ほとんどの場合「それは仕様です。」と言って突っぱねられて、修正してもらえない。 実に不条理な思いをするのである。
「それは仕様か？」という言葉は、こういう苛立ちに対しての怒りの表現なのだ。 つまり、彼のブログのタイトルは、こういうプログラマが日常的に感じる怒りをあらわす言葉のひとつなのだ。
この子もプログラマで、頭がいい子だったが、実に子供っぽく、どうやっても自分の論理の不備を認めることができないタイプだった。 一方で相手の論理の不備を見つけると、鬼の首を取ったように勝ち誇ってしまう。
最初は彼がいう問題にいちいち付き合って、彼の意見の矛盾点をひとつひとつ説明してあげていたのだけど、彼はまったく聴く耳持たず、むしろプライドを傷つけられてエキサイトする一方だった。 彼のプライドが傷つけば傷つくほど、僕への批判が手厳しくなっていく。 僕は仕方が無いので反論するのだが、実にきりがなかった。 また、彼一人だけの為に、大変な時間を取られ始めていた。
今思えば、日本には、よくいる、いわゆる「自分しか見えない」タイプなんだと思う。 仕方なく彼の意見を尊重すると「世の中には討論できない人が多い。」と勝ち誇ったように言い始めるので、実に辟易した。 討論にならない。
最終的に僕は、日本のブログ書きには彼のような、自己主張が強いわりに自己点検力が低い子が多い、と思うにいたった。 彼のようなタイプは付き合っても時間がかかる割りに得るものが少ない。 実に徒労感を感じさせる。 それ以降、僕はこうしてmixiで文章を書くようになった。
それはともかく、何で間違いなのに「仕様」「仕様」でごり押されてしまうのだろうか。 これは技術的なものだけではなく、むしろ社会的・政治的な問題が絡んでいる。 プログラムを 「リリース」するという行動に対して、技術的にはほぼ無力なのだ。
何故そうなるのか。 これについて説明するのはとても難しいと思う。
そんななか、最近、友達のＡ君が、「仕様とバグの違い」ということについて日記を書いていたのを見つけた。 コメント欄でそれについて意見を書いてみた。 それをここに引用してみたいと思う。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ｑ：何故、明らかに間違った動作でも仕様で押し通されてしまうのか。 仕様とバグの違いは何か。
Ａ：仕様かバグかという判断は、その動作が正しいか間違っているかとはまったく無関係だ。
仕様 ： 将来にわたって絶対に変更しない、と約束した動作。
バグ ： 近日中に変更する予定の動作。 あるいは変更した動作。
一般的に言って、意外な動作をすると感じる動作であっても、その動作に依存しているプログラムが一定数以上あると仕様になることが多くないだろうか。なぜならば、既にそれがリリースされたプログラムであり、そのプログラムの動作に依存したプログラムが無数に開発されてしまった以上、それを修正するのに大変な費用が発生する場合が多いからだ。あるプログラムのある動作を見たとき、たとえ自分が本来こうあるべきだと思っても、それが既にリリースされてしまったプログラムであるばあい、変更は決して容易じゃない。 変更には膨大な犠牲を伴うのだ。プログラマが見て、それがいかに意外であっても、いかに理想的でないと感じても、その動作に依存しているプログラムが多ければ、それは仕様になる。むしろ、仕様とすべきなのだ。 その仕様を変更するということは、その仕様に依存している無数のシステムを切り捨てることと等しいからだ。
逆に、そういう動作を、常に理想的なものへとコロコロと変更するメーカーもあるが、それもまた非常に疲れさせる存在だ。マイクロソフトとか「それは仕様です」って言い切ること多くて反感買ってるけど、「それは仕様です」って突っぱねてるからこそ、今でもＤＯＳのプログラムがきちんと動いたりするわけで、それが、いちがいに悪いこととは言い切れない。逆にアップルみたいに結構コロコロと仕様を変えるメーカーもあるけど、今でも初代マックのプログラムが動く、なんていう話は聞いたことがない。なにがしという古いプログラムを動かすために、あれを入れた、あれははずした、そのソフトだけの専用マシンを作ったとか、と苦労話は絶えない。「バグか仕様か」というのはトレードオフの関係でどちらがいいとは言い切れない。
仕様というのは、基本的に、いちどリリースしてしまったら、もう二度と変えられない類の物だ。もしも安易に仕様を変更してしまうと世の中に似て非なるものがあふれてしまう。 こうなると最悪だ。ユーザーは自分の作ったシステムを正しく動かす環境をそろえる方法がわからなくなってしまう。（いわゆるＤＬＬヘルと同じことが起こる。）だから、バージョンアップがある。バージョンアップしました、ということでバージョンナンバーを増やして、リリースすることで、これが言ってみれば別物として区分している。これは仕様の変更ではない。世に、似て非なるものがあふれてしまわないように、別物としてリリースしているわけで。
つまり、ある動作をバグだ、と決断するということは、これらすべてのリスクをすべて踏まえたうえで、そのリスクを負ってでも変更する価値がある、と決断することと同じだ。そのリスクを負うべき場合っていうのは、意外と多くない。ＩＥ６は、間違った仕様のCSSを実装してひんしゅく買っていたけど、あれだって、その間違った仕様のCSSを前提条件としてシステムを作ってしまった無数の顧客を抱えているわけで、もしマイクロソフトが、その人たちに「えー、間違いだったので、変えちゃいまーす。」って言ってバーンと変更してしまったら、そりゃプログラマは気持ちがいいだろうけど、お客は決して気持ちよくないはずで。 w3cにとっては間違った仕様でも、お客にとってはその間違ったＣＳＳが正しい仕様なわけで。
「それは仕様か？」とか言って文句ばかり言っているのは、ＡＰＩを設計したことも公開したこともない、お子様プログラマだけだと僕は思うよ。
＝＝＝＝＝＝＝＝＝＝＝
もちろん、粗悪な設計でもオッケーとか、設計は重要じゃない、ということを言っているわけじゃないんだよね。 リリースされる前の設計段階では、あらゆる自体を想定して、世の中に害悪が撒き散らされないように工夫をしなければいけない。
でもプログラムっていうのは、エンジニアリング以上に政治的なものが左右することが多く、設計段階であっても時間的な問題から多くの妥協をしたりする場合が多い。 例えば、Java のインナークラスとかもそうやって時間のプレッシャーの中でできた偶然の産物だってゴスリングのブログに書いてあったのを見たことがある。ゴスリングは本当はクロージャーを作りたかったのだけど、それが時間的にできなかったのであきらめたんだそうだ。（それのおかげでどれくらい害悪が撒き散らされたか。）
他にも、HTML3.2の頃の仕様や、JavaScriptの仕様もそういう部分がある。あれだって、きちんと時間をかけて設計していたら、今、こんなに醜悪な仕様が世界中を大混乱に陥れたりはしていなかっただろうと思う。もっと最初からきちんと設計されていれば、リリースから１０年もかけてようやく、AJAXとか粋がって、プラットフォーム間の差異の調査に命をかける、命知らずの捨て駒プログラマも現れたりはしなかっただろう。ブラウザ戦争というような、知的さのかけらもない極めて野蛮な環境の中で、まったく先行きのことを考えずにリリースしたツケが今でもこうやって世の中の足かせとなって、ぶら下がっている。
JavaScriptもそうだ。 バージョン番号によって仕様を切り替えるようにして、仕様が衝突しないようにしなきゃ、とは考えてはいた。たけど、そのバージョン切り分けの実装自体がブラウザによって異なってしまい、あいまいさは極みに達した。 結局ゴチャゴチャに衝突してしまっている。
例えば、User-Agent ヘッダなんて醜悪の極致じゃないだろうか。 ブラウザが何であろうと Mozilla/x.x って書く習慣あるけど、終わっているって僕は思う。 本当に醜悪で怠惰なやり方だと僕は思う。だけど世の中には先々のことを考えてあらかじめ問題が起こらないように対処する勤勉な人よりも、後先考えずエイヤでリリースしてしまう怠惰な人のほうが圧倒的に多いので、こういう醜悪な仕様が出来上がってしまう。
最近では、ＨＴＭＬの先頭にバージョン番号を書くことで、IE版CSSとw3c版のCSSとを切り替えられるようになった、と聞いた。ずいぶんまともになったんじゃないか、と思うが、そういうバージョンきりわけの機構が３重も４重も重なっているさまは、どうみても無様だ。
歴史は繰り返す、って言うけど、こういうことは今に始まったことじゃない。 昔からそうだ。 みんなが当然のように使ってる Telnet の仕様とかも、グシャグシャだ。 Telnet はそういう中でも何十年もかけて、磨き上げられてきているので、問題が減って枯れているが、最初からもっときちんと考えていたら、もっとシンプルなプロトコルになっていただろうな、とは思う。
FTPも似たようなものだ。 いまだにタイムスタンプの文字表現に仕様のあいまいさを抱えているのに、いまだに誰もなおしていない。たいした処理は必要じゃないはずなのに、FTPサーバーやFTPクライアントを開発する際には、想像を絶する手間がかかる。これもいまだに粗悪な仕様が社会の重荷になっている例だといえる。
「それは仕様か？」と文句を言うのはたやすい。 だけど、Aくん、これらのあいまいな仕様を、全部直して、世の中でリリースされている全部のクライアントとサーバーにパッチを書いていく気合、ある？ 僕は、ない。 断言する。
リリースしてしまったらもう誰も手を加えることはできない。でも世の中のどれくらいの人がリリース前、設計段階で「いまだ発生していない問題」に対して、理解を示してお金を払ってくれるだろう。「考えすぎじゃないの？」とか「んな細かいことほっておけよ」とか「もう時間がないからサッサとリリースしろよ」とかいって、怠惰な人たちは、みんなそろって、まじめな人をつぶしにかかる。
あるプログラムをリリースして問題が起こらないのは、実に奇跡的なことだ。問題が起こらなかったプロジェクトには、必ず先々の問題をあらかじめ予測して前もって問題が起こらないように尽力していた設計者が居る。しかし起こらなかった問題というのは、誰にも見えないものだ。
もし、この混沌としたＨＴＭＬの仕様に我慢できなくなった誰かがタイムマシンに乗ってブラウザ戦争中に戻り、HTMLの仕様の設計に加わったとしたら、どうなっただろう。 世の中の人は、だれも User-Agentの苦しみを知らず、 document.elements の苦しみを知らず、border-width の苦しみを知らず、getElementByID() の苦しみを知らず、快適にプログラミングすることができただろう。 そして、それが当たり前と思って誰も感謝しなかったはずだ。
彼はタイムマシンに乗って命を懸けた冒険から現代に帰ってくる。 そして言う。 「誰のおかげで、User-Agent がきちんと管理されていると思っているんだ！」 「え？User-Agentってきちんと管理されてるのが当たり前でしょ？」 「それがきちんと管理されなかったらどうなったと思ってるんだ！」 「いや、それはまぁそれなりに何とかやってたんじゃない？ なにムキになってんの？」
人々は、こうやって失敗したから、それが間違っているということを理解した訳で、ＨＴＭＬ黎明期にそのことに気がついている人は、どこにも居なかったし、まんがいち居たとしても確実につぶされてきたわけだと思う。先々起こる問題に前もって投資する先見の明のある人というのは、極めて稀なのだ。
また、あらかじめ先々の予測をして優秀な設計をする人というのは、誰からも感謝されることは無い。 実にそんな役回りだ。何年もかけて莫大な費用をかけて、問題が一切起こらないシステムを作ったとする。 しかし、利用者は、問題が起こらなくて当たり前と考える。誰も感謝せず、Winnyとかでプログラムをタダでばら撒かれたりする。
現実問題として、手間のかからない優秀なプログラムよりも、多少問題が続発して手間のかかる「ランドローバーミニ」のようなプログラムの方がかわいがられることが圧倒的に多いものではないだろうか。
さて、それでも 「それは仕様か？」 といえる？
この彼のブログのタイトル＝「それは仕様か？」っていう言葉は、プログラマにとってはとても有名な言葉で、関連した大きな論争があるのだが、これには若干説明が必要だろう。 例えば、明らかに間違った動作をしているプログラムがあったとする。 これに対してソフトウェアベンダーに苦情を言うと、それを修正する代わりに「それは仕様です。」という答えが返ってくることがある。
それは例えばこういうことだ。 Internet Explorer7 は エラー処理に変な不具合がある。 ウェブプログラムの間違いでプログラムがエラーを報告すると、Internet Explorer 7 はそれを報告しないで、無視してしまう。 Firefox にはこういう問題は無い。 これのおかげで、Firefox と Internet Explorer 7で、別なプログラムを用意する必要が出てしまう。 これはプログラマにとってとても面倒なことなのだ。 プログラマだけならず、ビジネス的に見ても、コスト的に大きな影響が現れる。 メンテナンス料が二倍かかるようになってしまうからだ。
この動作はw3cなど標準制定機関で作られた標準動作からもかけ離れている。 これは明らかに間違いなのだ。 だから、コストを二倍かけるよりは、マイクロソフトに修正してもらった方がありがたいと考えるのが、人の情というものだ。 だけど、こういう問題をマイクロソフトに報告すると、ほとんどの場合「それは仕様です。」と言って突っぱねられて、修正してもらえない。 実に不条理な思いをするのである。
「それは仕様か？」という言葉は、こういう苛立ちに対しての怒りの表現なのだ。 つまり、彼のブログのタイトルは、こういうプログラマが日常的に感じる怒りをあらわす言葉のひとつなのだ。
この子もプログラマで、頭がいい子だったが、実に子供っぽく、どうやっても自分の論理の不備を認めることができないタイプだった。 一方で相手の論理の不備を見つけると、鬼の首を取ったように勝ち誇ってしまう。
最初は彼がいう問題にいちいち付き合って、彼の意見の矛盾点をひとつひとつ説明してあげていたのだけど、彼はまったく聴く耳持たず、むしろプライドを傷つけられてエキサイトする一方だった。 彼のプライドが傷つけば傷つくほど、僕への批判が手厳しくなっていく。 僕は仕方が無いので反論するのだが、実にきりがなかった。 また、彼一人だけの為に、大変な時間を取られ始めていた。
今思えば、日本には、よくいる、いわゆる「自分しか見えない」タイプなんだと思う。 仕方なく彼の意見を尊重すると「世の中には討論できない人が多い。」と勝ち誇ったように言い始めるので、実に辟易した。 討論にならない。
最終的に僕は、日本のブログ書きには彼のような、自己主張が強いわりに自己点検力が低い子が多い、と思うにいたった。 彼のようなタイプは付き合っても時間がかかる割りに得るものが少ない。 実に徒労感を感じさせる。 それ以降、僕はこうしてmixiで文章を書くようになった。
それはともかく、何で間違いなのに「仕様」「仕様」でごり押されてしまうのだろうか。 これは技術的なものだけではなく、むしろ社会的・政治的な問題が絡んでいる。 プログラムを 「リリース」するという行動に対して、技術的にはほぼ無力なのだ。
何故そうなるのか。 これについて説明するのはとても難しいと思う。
そんななか、最近、友達のＡ君が、「仕様とバグの違い」ということについて日記を書いていたのを見つけた。 コメント欄でそれについて意見を書いてみた。 それをここに引用してみたいと思う。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Ｑ：何故、明らかに間違った動作でも仕様で押し通されてしまうのか。 仕様とバグの違いは何か。
Ａ：仕様かバグかという判断は、その動作が正しいか間違っているかとはまったく無関係だ。
仕様 ： 将来にわたって絶対に変更しない、と約束した動作。
バグ ： 近日中に変更する予定の動作。 あるいは変更した動作。
一般的に言って、意外な動作をすると感じる動作であっても、その動作に依存しているプログラムが一定数以上あると仕様になることが多くないだろうか。なぜならば、既にそれがリリースされたプログラムであり、そのプログラムの動作に依存したプログラムが無数に開発されてしまった以上、それを修正するのに大変な費用が発生する場合が多いからだ。あるプログラムのある動作を見たとき、たとえ自分が本来こうあるべきだと思っても、それが既にリリースされてしまったプログラムであるばあい、変更は決して容易じゃない。 変更には膨大な犠牲を伴うのだ。プログラマが見て、それがいかに意外であっても、いかに理想的でないと感じても、その動作に依存しているプログラムが多ければ、それは仕様になる。むしろ、仕様とすべきなのだ。 その仕様を変更するということは、その仕様に依存している無数のシステムを切り捨てることと等しいからだ。
逆に、そういう動作を、常に理想的なものへとコロコロと変更するメーカーもあるが、それもまた非常に疲れさせる存在だ。マイクロソフトとか「それは仕様です」って言い切ること多くて反感買ってるけど、「それは仕様です」って突っぱねてるからこそ、今でもＤＯＳのプログラムがきちんと動いたりするわけで、それが、いちがいに悪いこととは言い切れない。逆にアップルみたいに結構コロコロと仕様を変えるメーカーもあるけど、今でも初代マックのプログラムが動く、なんていう話は聞いたことがない。なにがしという古いプログラムを動かすために、あれを入れた、あれははずした、そのソフトだけの専用マシンを作ったとか、と苦労話は絶えない。「バグか仕様か」というのはトレードオフの関係でどちらがいいとは言い切れない。
仕様というのは、基本的に、いちどリリースしてしまったら、もう二度と変えられない類の物だ。もしも安易に仕様を変更してしまうと世の中に似て非なるものがあふれてしまう。 こうなると最悪だ。ユーザーは自分の作ったシステムを正しく動かす環境をそろえる方法がわからなくなってしまう。（いわゆるＤＬＬヘルと同じことが起こる。）だから、バージョンアップがある。バージョンアップしました、ということでバージョンナンバーを増やして、リリースすることで、これが言ってみれば別物として区分している。これは仕様の変更ではない。世に、似て非なるものがあふれてしまわないように、別物としてリリースしているわけで。
つまり、ある動作をバグだ、と決断するということは、これらすべてのリスクをすべて踏まえたうえで、そのリスクを負ってでも変更する価値がある、と決断することと同じだ。そのリスクを負うべき場合っていうのは、意外と多くない。ＩＥ６は、間違った仕様のCSSを実装してひんしゅく買っていたけど、あれだって、その間違った仕様のCSSを前提条件としてシステムを作ってしまった無数の顧客を抱えているわけで、もしマイクロソフトが、その人たちに「えー、間違いだったので、変えちゃいまーす。」って言ってバーンと変更してしまったら、そりゃプログラマは気持ちがいいだろうけど、お客は決して気持ちよくないはずで。 w3cにとっては間違った仕様でも、お客にとってはその間違ったＣＳＳが正しい仕様なわけで。
「それは仕様か？」とか言って文句ばかり言っているのは、ＡＰＩを設計したことも公開したこともない、お子様プログラマだけだと僕は思うよ。
＝＝＝＝＝＝＝＝＝＝＝
もちろん、粗悪な設計でもオッケーとか、設計は重要じゃない、ということを言っているわけじゃないんだよね。 リリースされる前の設計段階では、あらゆる自体を想定して、世の中に害悪が撒き散らされないように工夫をしなければいけない。
でもプログラムっていうのは、エンジニアリング以上に政治的なものが左右することが多く、設計段階であっても時間的な問題から多くの妥協をしたりする場合が多い。 例えば、Java のインナークラスとかもそうやって時間のプレッシャーの中でできた偶然の産物だってゴスリングのブログに書いてあったのを見たことがある。ゴスリングは本当はクロージャーを作りたかったのだけど、それが時間的にできなかったのであきらめたんだそうだ。（それのおかげでどれくらい害悪が撒き散らされたか。）
他にも、HTML3.2の頃の仕様や、JavaScriptの仕様もそういう部分がある。あれだって、きちんと時間をかけて設計していたら、今、こんなに醜悪な仕様が世界中を大混乱に陥れたりはしていなかっただろうと思う。もっと最初からきちんと設計されていれば、リリースから１０年もかけてようやく、AJAXとか粋がって、プラットフォーム間の差異の調査に命をかける、命知らずの捨て駒プログラマも現れたりはしなかっただろう。ブラウザ戦争というような、知的さのかけらもない極めて野蛮な環境の中で、まったく先行きのことを考えずにリリースしたツケが今でもこうやって世の中の足かせとなって、ぶら下がっている。
JavaScriptもそうだ。 バージョン番号によって仕様を切り替えるようにして、仕様が衝突しないようにしなきゃ、とは考えてはいた。たけど、そのバージョン切り分けの実装自体がブラウザによって異なってしまい、あいまいさは極みに達した。 結局ゴチャゴチャに衝突してしまっている。
例えば、User-Agent ヘッダなんて醜悪の極致じゃないだろうか。 ブラウザが何であろうと Mozilla/x.x って書く習慣あるけど、終わっているって僕は思う。 本当に醜悪で怠惰なやり方だと僕は思う。だけど世の中には先々のことを考えてあらかじめ問題が起こらないように対処する勤勉な人よりも、後先考えずエイヤでリリースしてしまう怠惰な人のほうが圧倒的に多いので、こういう醜悪な仕様が出来上がってしまう。
最近では、ＨＴＭＬの先頭にバージョン番号を書くことで、IE版CSSとw3c版のCSSとを切り替えられるようになった、と聞いた。ずいぶんまともになったんじゃないか、と思うが、そういうバージョンきりわけの機構が３重も４重も重なっているさまは、どうみても無様だ。
歴史は繰り返す、って言うけど、こういうことは今に始まったことじゃない。 昔からそうだ。 みんなが当然のように使ってる Telnet の仕様とかも、グシャグシャだ。 Telnet はそういう中でも何十年もかけて、磨き上げられてきているので、問題が減って枯れているが、最初からもっときちんと考えていたら、もっとシンプルなプロトコルになっていただろうな、とは思う。
FTPも似たようなものだ。 いまだにタイムスタンプの文字表現に仕様のあいまいさを抱えているのに、いまだに誰もなおしていない。たいした処理は必要じゃないはずなのに、FTPサーバーやFTPクライアントを開発する際には、想像を絶する手間がかかる。これもいまだに粗悪な仕様が社会の重荷になっている例だといえる。
「それは仕様か？」と文句を言うのはたやすい。 だけど、Aくん、これらのあいまいな仕様を、全部直して、世の中でリリースされている全部のクライアントとサーバーにパッチを書いていく気合、ある？ 僕は、ない。 断言する。
リリースしてしまったらもう誰も手を加えることはできない。でも世の中のどれくらいの人がリリース前、設計段階で「いまだ発生していない問題」に対して、理解を示してお金を払ってくれるだろう。「考えすぎじゃないの？」とか「んな細かいことほっておけよ」とか「もう時間がないからサッサとリリースしろよ」とかいって、怠惰な人たちは、みんなそろって、まじめな人をつぶしにかかる。
あるプログラムをリリースして問題が起こらないのは、実に奇跡的なことだ。問題が起こらなかったプロジェクトには、必ず先々の問題をあらかじめ予測して前もって問題が起こらないように尽力していた設計者が居る。しかし起こらなかった問題というのは、誰にも見えないものだ。
もし、この混沌としたＨＴＭＬの仕様に我慢できなくなった誰かがタイムマシンに乗ってブラウザ戦争中に戻り、HTMLの仕様の設計に加わったとしたら、どうなっただろう。 世の中の人は、だれも User-Agentの苦しみを知らず、 document.elements の苦しみを知らず、border-width の苦しみを知らず、getElementByID() の苦しみを知らず、快適にプログラミングすることができただろう。 そして、それが当たり前と思って誰も感謝しなかったはずだ。
彼はタイムマシンに乗って命を懸けた冒険から現代に帰ってくる。 そして言う。 「誰のおかげで、User-Agent がきちんと管理されていると思っているんだ！」 「え？User-Agentってきちんと管理されてるのが当たり前でしょ？」 「それがきちんと管理されなかったらどうなったと思ってるんだ！」 「いや、それはまぁそれなりに何とかやってたんじゃない？ なにムキになってんの？」
人々は、こうやって失敗したから、それが間違っているということを理解した訳で、ＨＴＭＬ黎明期にそのことに気がついている人は、どこにも居なかったし、まんがいち居たとしても確実につぶされてきたわけだと思う。先々起こる問題に前もって投資する先見の明のある人というのは、極めて稀なのだ。
また、あらかじめ先々の予測をして優秀な設計をする人というのは、誰からも感謝されることは無い。 実にそんな役回りだ。何年もかけて莫大な費用をかけて、問題が一切起こらないシステムを作ったとする。 しかし、利用者は、問題が起こらなくて当たり前と考える。誰も感謝せず、Winnyとかでプログラムをタダでばら撒かれたりする。
現実問題として、手間のかからない優秀なプログラムよりも、多少問題が続発して手間のかかる「ランドローバーミニ」のようなプログラムの方がかわいがられることが圧倒的に多いものではないだろうか。
さて、それでも 「それは仕様か？」 といえる？
コメント一覧
ナム 2009年04月19日 05:52
>仕様 ： 将来にわたって絶対に変更しない、と約束した動作。
>バグ ： 近日中に変更する予定の動作。 あるいは変更した動作。
これ、とてもおもしろいですね。
仕様とバグという言葉を使っていなくても、コンピューター以外の業種でも、常に判断されていることだろうと思います。
自分の会社でも、ある点について、これは直した方がいいと誰かが気がついた場合、直すことについてのコストが議論されます。
直すと先々までいろいろなところに影響を及ぼすことが多いものについては、コストの点から、バグにするか仕様にするか、議論が分かれます。
仕様にすると決まると、なぜ仕様なのか、という理論構築を皆で行います。仕様としての理論が構築ができていないと、また他の誰かが同じ点についてバグと指摘してきた場合にめんどうなことになるからです。
理論構築ができあがれば、誰がなんと言ってこようが、みんなで声をそろえて、それは仕様です。となるわけです。
バグにするか仕様にするかの判断は、人間の営みにはつきものかもしれませんね。
>バグ ： 近日中に変更する予定の動作。 あるいは変更した動作。
これ、とてもおもしろいですね。
仕様とバグという言葉を使っていなくても、コンピューター以外の業種でも、常に判断されていることだろうと思います。
自分の会社でも、ある点について、これは直した方がいいと誰かが気がついた場合、直すことについてのコストが議論されます。
直すと先々までいろいろなところに影響を及ぼすことが多いものについては、コストの点から、バグにするか仕様にするか、議論が分かれます。
仕様にすると決まると、なぜ仕様なのか、という理論構築を皆で行います。仕様としての理論が構築ができていないと、また他の誰かが同じ点についてバグと指摘してきた場合にめんどうなことになるからです。
理論構築ができあがれば、誰がなんと言ってこようが、みんなで声をそろえて、それは仕様です。となるわけです。
バグにするか仕様にするかの判断は、人間の営みにはつきものかもしれませんね。
おかあつ 2009年04月19日 07:14
＞仕様とバグという言葉を使っていなくても、コンピューター以外の業種でも、常に判断されていることだろうと思います。
そうです。 変更にはコストが付きまといますから．．．。
＞バグにするか仕様にするかの判断は、人間の営みにはつきものかもしれませんね。
ま．．． しかし．．． プログラミングの世界というのはなかなか変人が多く．．． 「赤って言うと青が出る、青って言うと黄が出る。 黄って言うと黄が出る」というような、相当変なプログラムまで真顔で「仕様です」って突っぱねられちゃうこと、多いのです。 じゃぁこれつかって、どうやって赤を出せばいいってんだ！ とかなるんですが．．．。 せめて、ここで黄って言えば赤が出てくる．．．ってなってれば、間違ってても使いようがあるっていうものじゃないですか。
しかも、世の中、そういう変なプログラムをだましだまし使っているプログラマがたくさんいて、赤が出ないっていうその状態で、それぞれシステムを作ってるわけですが、これをいきなり正しく変更されちゃうと、逆に世の中が大混乱になったりして．．．。
逆に「これはバグです。」 って言われたプログラマが馬鹿正直にそれを聞いていても、あとでベンダーからはしごをはずされることもしばしばです。 そういう正直なプログラマが「赤といえば青がでる、青というと黄が出る、黄というと黄が出る」変なシステムを作っちゃって、客に、これは○○社のバグで近日中に修正予定ですから、しばらくお待ちください、とか説明していたのに、ベンダーは何年経っても一向にバグ修正しなかったりすることもしょっちゅうで．．．。
そうです。 変更にはコストが付きまといますから．．．。
＞バグにするか仕様にするかの判断は、人間の営みにはつきものかもしれませんね。
ま．．． しかし．．． プログラミングの世界というのはなかなか変人が多く．．． 「赤って言うと青が出る、青って言うと黄が出る。 黄って言うと黄が出る」というような、相当変なプログラムまで真顔で「仕様です」って突っぱねられちゃうこと、多いのです。 じゃぁこれつかって、どうやって赤を出せばいいってんだ！ とかなるんですが．．．。 せめて、ここで黄って言えば赤が出てくる．．．ってなってれば、間違ってても使いようがあるっていうものじゃないですか。
しかも、世の中、そういう変なプログラムをだましだまし使っているプログラマがたくさんいて、赤が出ないっていうその状態で、それぞれシステムを作ってるわけですが、これをいきなり正しく変更されちゃうと、逆に世の中が大混乱になったりして．．．。
逆に「これはバグです。」 って言われたプログラマが馬鹿正直にそれを聞いていても、あとでベンダーからはしごをはずされることもしばしばです。 そういう正直なプログラマが「赤といえば青がでる、青というと黄が出る、黄というと黄が出る」変なシステムを作っちゃって、客に、これは○○社のバグで近日中に修正予定ですから、しばらくお待ちください、とか説明していたのに、ベンダーは何年経っても一向にバグ修正しなかったりすることもしょっちゅうで．．．。
ナム 2009年04月19日 11:31
なるほどお。
そうすると、「赤といえば青がでる、青というと黄が出る、黄というと黄が出る」変なシステムを平気で「仕様です」って突っぱねることができる立場のプログラマーと、突っぱねられるほうのプログラマーでは、そうとうな立場の強弱があるということですよね。
突っぱねられる方のプログラマーはたまりませんね。
うちの会社もバブルのころは、お客がミスを見つけて、なんか言ってきても、わー、よく見つけましたねぇ。すごいですねぇ。ガチャリ。てな感じの対応を平気でやってましたが、今、そんなことやってたら、客の方が立場が強いので会社つぶれますわ。
そういう意味ではコンピューター業界はまだ殿様のような商売ができる状態なのだなあ、と思いました。
しかし、そんな業界で｢仕様です｣で突っぱねられちゃう方のかたがたはさぞ大変でしょうねぇ。
そうすると、「赤といえば青がでる、青というと黄が出る、黄というと黄が出る」変なシステムを平気で「仕様です」って突っぱねることができる立場のプログラマーと、突っぱねられるほうのプログラマーでは、そうとうな立場の強弱があるということですよね。
突っぱねられる方のプログラマーはたまりませんね。
うちの会社もバブルのころは、お客がミスを見つけて、なんか言ってきても、わー、よく見つけましたねぇ。すごいですねぇ。ガチャリ。てな感じの対応を平気でやってましたが、今、そんなことやってたら、客の方が立場が強いので会社つぶれますわ。
そういう意味ではコンピューター業界はまだ殿様のような商売ができる状態なのだなあ、と思いました。
しかし、そんな業界で｢仕様です｣で突っぱねられちゃう方のかたがたはさぞ大変でしょうねぇ。
おかあつ 2009年04月20日 01:58
>しかし、そんな業界で｢仕様です｣で突っぱねられちゃう方のかたがたはさぞ大変でしょうねぇ。
そうなんです。 で、涙を呑んであきらめて、青と入力されたら赤を、黄と入力されたら青を、赤を入力されたらエラーを出力するプログラムを組むわけです。 当然予定していなかった追加費用もかかります。 また、そういう涙を呑んだ人達は、ひとりではなく、何万人単位で居ることになります。
そんなある日、○○社が「この動作はバグなので修正します。」って発表したとするとどうなるでしょうか。 容易に想像がつくように、大ブーイング大会が始まります。 一方まだ開発していない人たちは追加費用がかからないので大歓迎です。
だから、○○社としては、バグを修正しても怒られる、修正しなくても怒られる、というダブルバインドに立ち向かわなければいけないわけで、大変なのです。
そうなんです。 で、涙を呑んであきらめて、青と入力されたら赤を、黄と入力されたら青を、赤を入力されたらエラーを出力するプログラムを組むわけです。 当然予定していなかった追加費用もかかります。 また、そういう涙を呑んだ人達は、ひとりではなく、何万人単位で居ることになります。
そんなある日、○○社が「この動作はバグなので修正します。」って発表したとするとどうなるでしょうか。 容易に想像がつくように、大ブーイング大会が始まります。 一方まだ開発していない人たちは追加費用がかからないので大歓迎です。
だから、○○社としては、バグを修正しても怒られる、修正しなくても怒られる、というダブルバインドに立ち向かわなければいけないわけで、大変なのです。
ナム 2009年04月20日 07:21
>だから、○○社としては、バグを修正しても怒られる、修正しなくても怒られる、というダブルバインドに立ち向かわなければいけないわけで、大変なのです。
なるほど、身動きがとれませんね。
なるほど、身動きがとれませんね。
