バッドノウハウからグッドラッパーへ

― 「奥が深い」システムの改善方法 ―

結城浩

「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。

目次

はじめに

高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。

有益なものを生み出さなければ「奥が深い」とも呼ばれない

もしも「奥が深い」システムが何も有益なものを生み出さなかったなら、 誰もそれをありがたがることはありません。 「奥が深い」として複雑なコマンド体系を覚えるのは、 そのシステムが何らかのよいものを生み出しているからです。 たとえばTeXなら美しい文書作成を、sendmailならば複雑なメールの配送を実現できるわけです。

複雑なシステムが何もよいものを生み出さなかったら、 それは「奥が深い」とは呼ばれず、単にみんなから嫌われ、無視されるだけのことでしょう。

バッドノウハウをグッドラッパーで隠そう

バッドノウハウがよくないのは、それが必要以上に複雑だったり(複雑そうに見えたり) コマンドの順序を厳密に守らなければならなかったり、 やりたいことをやるまえに謎の呪文を唱える(何十行もの複雑なコマンドを書くなど)必要があったりするからです。

そんなときには、 そのバッドノウハウを覆い隠すようなラッパー(wrapper)を作ることを考えましょう。 つまり、コマンド体系Xが複雑ならば、 もっとシンプルなコマンド体系Aを考え出し、 コマンドAをコマンドXに変換するような仕組みを作りましょう。 コマンドの順序をどうすべきかという知識をラッパーに持たせ、人間が順序を意識しなくてもよいようにしましょう。 また、ラッパーが自動的に謎の呪文を唱えるようにしてしまいましょう。

人間の負担を軽くするようなラッパーを作ることを考えましょう。 バッドノウハウを注意深く理解し、検討するのはラッパーを書く人が行う。 そのラッパーを使う人はバッドノウハウを苦労して理解する必要がない。 そのように発想を変えるのです。

うまいラッパーが作れたら素晴らしいことです。 バッドノウハウを隠しつつ良い部分を利用できるわけですから。 そのようなラッパーを、バッドノウハウに対応させてグッドラッパー(good wrapper)と呼んでもよいですよね。

バッドノウハウをたくさん抱えたシステム(をありがたがっている人)を見かけたときには、 それを「奥が深い症候群だ」として批判するだけではなく、 「グッドラッパーがあったらもっと良いのにね」と言ってみましょう。

複雑で「奥が深い」システムを使わなければならない状況に陥ったら、 「うんざりする」のではなく 「グッドラッパーは作れないかな?」と考えましょう。

そういえば、TeXにはLaTeXというラッパーが存在しますね。 LaTeXはグッドラッパーかな? sendmailには(sendmail.cfを作り出す)ラッパーは存在するでしょうかね。

本当によくないシステムとは

ここまで考えてくると「本当によくないシステム」の姿が見えてきます。 単にコマンド体系が複雑だ、というのはそれほど悪いシステムではない。 複雑なコマンド体系をシンプルにするラッパーを書くことができるかもしれないからです。

本当によくないシステムとは、 ラッパーを作ることができないシステム なのかもしれません。

たとえば…

よびかけ

あなたの手元にバッドノウハウがたまっているようなら、 「グッドラッパー」を考えてみませんか?

補足:Perlとバッドノウハウ

『バッドノウハウと「奥が深い症候群」』では、Perlもバッドノウハウの温床としてあげられている。 私もそれに反論するわけではないが、Perlはラッパーを書くのに便利なツールだという事実はどう考えたらよいのだろう…。 「汚い」部分に対応するためには「汚さ」が必要だということかしらん。

いろんな方からのコメント

以下、いただいたコメントから抜粋・一部編集してご紹介します。 みなさんに感謝。

てらぬしさんからのコメント:

まさに Larry Wall がそんなことを言っていたような気がします。 検索しても http://www.monitor.ca/monitor/issues/vol10iss11/lnxstuff.htmlでしか見つけられませんでしたが、"Perl is messy because the world is messy." だそうです。

向井さんからのコメント:

CFというsendmail.cfを生成するためのツールがあります。 私は使ったことがないので、 どの程度良いラッパかはわかりませんが。 しかも、ちょっと古い sendmail にしか使えなくなっているという話です。

postfix を入れると、sendmail コマンドを postfix の同名のコマンドに置き換えてしまいます。 むろん普通の sendmail コマンドとして利用可能です。 こちらの方がスマートなやりかたかもしれません。 互換性を保ちつつ、新しいものに置き換えるわけです(まあ従来の sendmail.cf は使えませんが……)。

ほそのさんから:

sendmail.cfを書くためのラッパーといえば、昔はCF、今だとsendmail.mcですね(これはあんまり「グッド」ではない気がしますが(^_^;))。 あと、ちょっと変化球ですが、Linuxのパッケージングシステム(debやrpm)も、無数のインストール手順をラップする「グッドラッパー」といえると思います。

増井さんから:

結城さんの様々な活動はいつも尊敬して拝見しているのですが、 今回のご意見にはちょっと同意できないです。 高林氏が問題としてるシステムは、 根本の思想から腐っていて糖衣を着せたぐらいではどうにもならないものであって、 ラッパーとかでなんとかなるものは批判の対象としていないと思います。 (TeX, sendmail, procmailとかは根本から腐っているものの良い例であり、 ラッパーでなんとかなるものではありません)

結城から:

なるほど。 もちろん設計が底から腐っているものというのは存在します。 ただ、高林さんの「バッドノウハウと「奥が深い症候群」」では、 そういうものに出会ったときに「どうすればよいか」までは書かれていないように思いました(2004年3月8日現在)。

「バッドノウハウ」というのは濫用されがちな表現だと思います。 「それはバッドノウハウだ」といって批判をしただけで、 思考を停止し、話を終わらせてしまう人もいるかもしれません。

結城は「グッドラッパー」という表現で、 まずいシステムに出会ったときにどう対処するか、 という「1つの方向性」を示したいと思ったのでした。

貴重なご意見をありがとうございます。

えんどうさんから:

> もしも「奥が深い」システムが何も有益なものを生み出さなかったなら、 誰もそれをありがたがることはありません。

そんなむちゃな。その対象が複雑だというだけでそれに耽溺する 人は珍しくないですが。手段が目的と化してしまっているという やつです。「奥が深い」という形容が可能な対象なら、その域に すでに届いているものだと考えるのが、より正しい現状認識だと 思います。

> 「バッドノウハウ」というのは濫用されがちな表現だと思います。

わたしも「ノウハウ」を直接の批判の対象とするのは、ミスリードを まねいたり、「バッドノウハウ」自体の権威づけになってしまったり てアレだと思います。

むしろ、そのようなものが存在している状況自体を、すなわち、「改善せずに適応」している状況を問題にするべきだと思うなり。

だいたい、ラッパーって、油断すると拘束具と化すじゃないですか、 対象とするシステムの。あくまでもテンポラリなものだという前提 でかからなければいけないと思います。ラッパーは。

結城から:

なるほど、なるほど。

途中の「改善せずに適応している状況を問題にするべき」というのは賛成です。 ただ(当然ながら)「改善するか」「適応するか」というのはトレードオフであって、 必ずどちらでなければならない、というのではないですね(えんどうさんがそう主張しているという意味ではなく)。

ラッパー(の実装)はテンポラリかもしれませんが、 ラッパーの上位インタフェースはテンポラリではない可能性があります。 まず第一弾では、ぐちゃぐちゃシステムにラッパーをかぶせてスマートに使えるようにする。 その上で、今度は上位インタフェースを保つようにしながら、 ぐちゃぐちゃシステムを根本的に改善する。 たとえば、C++のコンパイラは以前はCに変換するラッパーとして実装されていた。 …とここまで書いてから、 えんどうさんがおっしゃる「テンポラリなもの」と ほぼ同じことを言っているような気もしてきました。 というので尻すぼみですが、ここまで。

反応を感謝します。

匿名さんから:

文章の趣旨には賛成なので揚げ足取りになりますが、 『本当によくないシステムとは、ラッパーを作ることができないシステムなのかもしれません。』は微妙な表現だと思います。 本当にいいシステムというのは、ラッパーを作る必要がないと思います。 そこに例で挙げられているものは技術志向すぎるのでは?技術は利用者を含めた物語を完成させる為のもので、 もし、ボタンを押すことに必然性があり、完成されているのであればそれは構わないと思います。 もちろん、結城さんが想定されている事は非常によくわかるんですけど。

結城から:

そうですね。 ラッパーを作る必要がなければそれに越したことはないわけです。 ただ、ソフトウェアもだんだん時代にそぐわなくなってくるという可能性を頭に置いていました。 ずいぶん話を省略して書きすぎたかもしれません。 コメント感謝します。

anabisさんから:

CMUのロボット工学の教授である、金出 武雄さんが 『素人のように考え、玄人として実行する』という本で同じような問題を論じています。

反応リンク

関連リンク

更新履歴

ぜひ、感想をお送りください

あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。

あなたの名前: メール:
学年・職業など: 年齢: 男性女性
(上の情報は、いずれも未記入でかまいません)

お手数ですが、以下の問いに答えてから送信してください(迷惑書き込み防止のため)。
今年は西暦何年ですか?

何かの理由でうまく送れない場合にはメールhyuki dot mail at hyuki dot comあてにお願いします。

豊かな人生のための四つの法則