このチック・コリアという人、ジョン・トラボルタやトム・クルーズと同様に某カルト宗教の広告塔という面もあるのですが、音楽的には本当に優れていることは否定できないと思います。

彼はこう言います「音楽で最も重要なものはリズムだ」と。この重要性に比較すれば、他のことは大した問題ではないというのです。一般的には、音楽の三大要素として、リズム・メロディー・ハーモニーなどと言われますが、彼はこの中の一つが他に比較してとりわけ重要だと主張するわけです。

これにならい、私もプログラミングにおいてとりわけ重要なものが何であるかを考えてみたのですが、それは「整理整頓」と、それと表裏一体の関係にある「制限」や「制約」であると考えました。この重要性に比較すれば、プログラミング言語の良し悪しや個々の技術の内容などは大した問題ではないようにも思えてしまえるほどです。

「モノ」の整理については、巷では収納名人でテレビでもおなじみの近藤典子さんなどが有名ですね。皆さんモノの整理整頓について、助けが必要な事情が一般にあるようです（これは、うちの場合も全く同じではあります）。

「モノ」の整理整頓がなぜ必要なのか。当然のことですが、必要なときにその「モノ」をすぐに取り出したいわけです。逆に、簡単に収納できることも必要です。取り出すのが簡単でも収納が面倒であれば、嫌になってそこに収納しなくなってしまいます。美的センスも必要ですね。眺めても見苦しくなく、あるいは普段は完全に視界から消してしまうなどです。しかし、意外に見落としがちな点かと思うのですが、整理整頓と表裏一体の関係にあるのが、「制限」あるいは「制約」です。

食器を収める棚には文房具や本やトイレットペーパーを（特別な事情のある場合は別ですが）収納してはいけないのです。ある場所をカテゴリづけし、それ専用のものとして扱わねばなりません。また、その上位のカテゴリ、例えば「台所」というカテゴリには、料理を作って出すためのものが集まらなければなりません。食器の他には、冷蔵庫、流し台などです。

さらに上位のカテゴリとして、会社であれば食堂、家庭であれば居間というカテゴリがあるでしょう。これらの「部屋」をその上位の「建物」の中にどのように収納するかも重要ですね。

このようにカテゴリは階層構造になっており、そのカテゴリ以外のものを含めてはいけないという制約を持つわけです。整理整頓とは本質的にこのようなものです。どこに何があるかがすぐにわかる整理整頓という概念と、何らの制約からも自由であることとが相反することは当然です。

オフィスビルの中に、食堂から離れたトイレの中に、オロシガネ（大根おろし）がかけてあったらどうでしょうか？美しくない上に不便で仕方がありません。何よりも、料理を作ったり食べたりする人は大変です。

この場合には、とてつもなく当たり前のことなので、別段そこに制約や制限があるようには思えません。しかし、「何をしようが俺の自由だ！」と言って、トイレの中に食器置き場を作る輩が出だしたら、「食器は食堂の外に出してはいけない」という張り紙をしなければならなくなるでしょう。

プログラム作りは、これによく似ています。というよりも、トイレの中に食器置き場を作ってしまう輩があまりにも多いのです。もちろん、プログラミングの場合、モノの例のように、その「置き場」というものが自明なわけではありません。なぜなら、プログラマは常に新しい「モノ」を作るからです。その新しいモノをどこに置くかは、もはやセンスの問題になります。このセンスの無い方は、トイレの中にオロシガネをかけてしまいます。

こういったセンスというものは、場数を踏まなければわからないものです。経験がものを言う世界なのです。おそらくこれは、一般にイメージされているプログラマ像とは異なるものだろうと思います。

プログラマというのは、プログラミング言語という英語に似た言語を使い、与えられた仕様なり何なりを満たす「文章」を作成していく、その文章というのは、コンピュータに仕事をさせるための命令の集まりである、というのが大方のイメージではないでしょうか？これはこれでその通りです。

しかし、プログラミングの本質的な部分、キモの部分は、与えられた、あるいは故意に自ら課した制約・制限の中で、物事を整理整頓していく仕事なのです。

前者のようなとらえ方をしている人は、少なくともお金をもらうことのできるプロとは言えません。

例えば、ここにプロの野球選手なり、サッカー選手なり、ゴルファーがいるとします。彼らは、もちろん猛練習をして、筋肉と運動神経を鍛えあげたことでしょうけれども、それでプロになれるのでしょうか？違うでしょう、プロとしての彼らに必要なものは最終的には精神力ではないでしょうか。いかなるプレッシャーのもとでも自らの力を完全に引き出すことのできる精神力がプロとしては必須のような気がします。

ここがプロとアマの違いだと思います。どのような世界においても、一般の方が「こういうものだろう」と想像するものや、アマチュアレベルの方が懸命に「練習」しているものとは、一つ別のものがプロの世界では存在すると思いますし、それらをなかなか言葉で現したり、教えたりすることは難しいのではないでしょうか。

ただ、簡単に言葉で表すことができるのであれば、その知識は誰でもが習得できるものであって、その程度のレベルでは（以前もこのような話を書きましたが）競争に勝つことはできないでしょう。

続きます。

しかし、インターフェースを定義すること自体が経験や技術が必要で、しかも時間のかかることです。しかし、それがなぜ必要なのか理解していない方が非常に多いのです。これは現場の技術者の中でも「プログラムの作り方」に疑問を持った方で無いとなかなか気がつきません。もちろんこの手の書籍は現代ではいくらでも出版されているのですが、システム会社の経営層はそんなものを勉強しようとはしませんし、読んだところでチンプンカンプンなのです。

そのうえ、インターフェースを定義しただけではダメなのです。今度はテスト用のツールを作成しなければなりません。例えば、本番環境では発電所から電力が供給されるのですが、何かのはずみで電圧が降下してしまったり、いきなり切れてしまったりするかもしれません。そのような事態にも対処できるように、テスト用の「発電機」はそのような事態がシミュレーションのできる機能を備えていなければなりません（あまりうまい例では無いのですが、とりあえず）。あるいは、ＣＤラジカセであれば、本番の放送局ができる前にテスト用の電波発信機が必要かもしれません。

容易に想像できるかと思いますが、このようなテスト用のツールを作成するためには、ＣＤラジカセという製品を作成する以上の労力が必要になる場合もあります。実際に、あるプログラムの機能をすべてテストするとしたら、そのテスト用のプログラムはそれ以上の大きさになる場合がありえます。

テストができるようにインターフェースを定義し、そのインターフェースに合わせたテスト用のプログラムを書くことは、大変に労力がかかることなのです。納期に間に合わないと言って、連日徹夜状態のプログラマがこんなことができるわけがありません。

つまり、これらの「芸当」ができるのは、特別待遇の技術者に限ります。最上級の優秀なプログラマがごく普通の仕事を与えられた場合か、あるいはボンクラの集団であっても、なぜか時間と金はたっぷり与えられており、少なくともそのうちの一人はこのことを理解している場合です。

つまり、テストのできるプログラムとは、この二つの条件、インターフェースによる分離がされており、テスト用ツールが備わっていることを満たすものです。一度でもこの二つの経験があれば、それまでとはプログラムの作り方が違ってきます。これらの経験者は、テストツールを作る時間がとれなくとも、少なくとも後でテストツールを作成することもあるだろうと、インターフェースによる分離を試みます。

このような経験の無いプログラマは、すべてが渾然一体となったプログラムを作成してしまいます。ここが経験者とそうでない方の違いなのです。全く同じ機能を果たすプログラムを両者とも作成できたとしても、その中身は雲泥の差があり得るのです。

世のプログラムの多くは、テストのされていない、あるいはするためのツールの無いプログラムである。これには技術・経験・工数がかかる。ユーザに提出される「お見積り」なるものには、それらを行うかどうかなど一切現れない。これが現時点でのソフトウェア産業の常識である。それは請け負った者の技術と良心にまかせられている。しかし、ソフトウェアは100%機能拡張されるものである。そのときになって初めて、テストの有無問題が首をもたげる。

具体的に「テストのできないプログラム」とはどのようなものなのか。イメージとしてとらえてもらうために、以下のような例えを考えてみました。これでもまだわかりにくいかもしれませんが、これ以上簡単にするのも難しいですね。

前回の例ではＣＤラジカセを例にとりました。これを極めて小さなプログラムとします。この小さなプログラムが集まって大規模なプログラムを構成するとします。具体的には一つの都市としましょうか。CDラジカセそのものも内部に配線があるのですが、それを動かすためには何らかの電力に接続しないといけません。その都市にある発電所に接続するとしましょう。

ここで私達の通常の常識とは異なる、とんでもないことがソフトウェアの世界では起こるのです。プログラマはＣＤラジカセと発電所を「直結」してしまいます。直接むすんで不可分のものにしてしまいます。それどころか、他のテレビや冷蔵庫なども同様に、発電所に「直結」します。この結果、発電所が稼働しないとＣＤラジカセ、テレビ、冷蔵庫を動かしてみることもできなくなるのです。全体ができてはじめて動作することができるのであって、個別の電化製品をテストすることはできません。

つまり、プログラマは「インターフェース」を定義しようとしません。この場合の「インターフェース」とは100Vの交流電源50Hzもしくは60Hzで、脱着可能なオスメスのソケットということです。

このケースでは「何でそんなこともできないのか」と思うかもしれませんが、複雑なプログラムの場合、「インターフェース」を定義するのも難しいのです。身近にある難しいインターフェースの例としては例えば、外付けハードディスクとパソコンをUSBで接続した場合の「インターフェース」はどのようなものかわかりますか？あるいは、地デジアンテナとそのチューナーの「インターフェース」はどうなっているのか説明できるでしょうか？赤外線リモコンとテレビは？

これらをきちんと定義したり説明するのは難しいのです。そして、接続するためのインターフェースをきちんと定義することができれば、それとは逆に分離することが簡単になります。先の例で言えば、ＣＤラジカセが発電所より先にできてしまった場合に、それを接続するインターフェースが定義されていれば、発電所の代わりに発電機でＣＤラジカセを動かしてみることができます。これがテストというものです。

「テストのできないプログラム」は、それができません。すべてを接続した後でないと、すべてがうまく動くことを確認できないのです。そして、あらゆるものがそのときの相互接続を前提としているため、一箇所でも配線を変更すると、その影響が多方面にわたってしまうのです。

さらにひどいことにプログラマの作る物は、CDラジカセ、テレビ、ステレオ、などという風に分離してはいません。音が出る機能と映像が出る機能という風に作ってしまうのです。この結果、理想的には、きちんと分離された製品であるのが正しいのに、それらの裏蓋を開けて床にごちゃごちゃと置かれたような代物を作成してしまうのです。そして、それが一体どのようにして発電所に接続しているのかわからないような有様になってしまいます。

たいていのプログラムは、外見は綺麗でも中身はこんなものです。それらは一切ユーザの目には触れないので、「そこに労力をかける価値は全く無い」というのが、かなり多くのシステム会社の考え方です。しかし、意識して考えている「考え方」というよりも、実際には「そんなことは考えたことも無い」というのが本当のところです。

もちろんマトモな会社もあるでしょうけど、私は見たことはありません。なぜなら、システム会社の経営層というのは、ほぼ全員がソフトウェアのことなど何一つ知らないからです。例えば、地方のソフト会社などは、大手ソフト会社に人員を派遣することで成立していますから、コネや営業の方が重要になります。技術など二の次なのです。もちろんこのような事情というのは、この業界に限らないでしょうけれども。

結局この件もかなり「社会的」な問題、つまり現代の社会で何が常識とされているのかによるかと思います。素人であるユーザの側としては、プログラムの中身のことなど知ったことではない無いというのは、その通りなのです。がしかし、「機能拡張が困難な」「バグがいつまでも直せない」という点はもっとクローズアップされてもよかろうと思います。

IT関連の雑誌やウェブの記事はとかく、「クラウドがどうした」だの「ipadでらくらくなんとか」だのと特集をし、メーカーのチョウチン記事ばかり書いていますが、その一方でこういった本質的な問題というのはほとんど放置されたままです。これも他の多くの産業と同様のものであすね。結局は「賢い消費者になりましょう」の一言で済ませられ、「自己責任」としてユーザに押し付けられているのです。

テストのできないプログラム３

例えば、CDラジカセを作るとします。ユーザが操作する部分はもちろんテストされます。各種のつまみがきちんと機能しているか、音が鳴るかなどをテストするのは当然ですね。ここではそのようなテストのことではなく、ラジカセの中身のテストです。

ラジカセの裏蓋を開けてみますと、様々な配線やモジュール（ＩＣ、コンデンサ、変圧器などなど）が並んでいます。これらを一つ一つテストできるかどうかという問題です。こういった機器の場合には、保証期間やら部品の提供期間が法律で決められています。修理を行う場合は、技術者が「どこが悪いのかすぐにわかる」と言った状態、すなわちどこをテストして、どのような結果になれば良いのかという手順が決められているものと思います。

ラジカセと違って、プログラムの場合には配線やモジュールが「悪くなる」ということはありませんから、いっけんそんなものは必要無いように思います。どれほど配線がごちゃごちゃだろうが、モジュール分けされてなかろうが、関係ないのです。一般的なユーザは裏蓋を開けてみたりしません。だから、

どんな作り方をしようが、何を使って作ろうが関係ない。ユーザの要求するものが作れればそれでいいのだ。そして素早く作れれば、なお良いのだ。

という主張をする人がたまにいますが、これはその通りのように思わされてしまいます。しかし、このような議論で抜け落ちているのが、

プログラムはＣＤラジカセとは違う。

という点です。CDラジカセの場合、それ以上の機能を要求することはできません。例えば、小さい液晶画面をつけて、ワンセグを見れるように改造しろだとか、ＤＶＤも再生できるようにしろだとか。こういう要求のある場合は、「買い直せよ」ということになるでしょう。改造する位なら、新しいものを買った方が安く済むということは誰でもわかることでしょう。

ところが、プログラムの場合、安易にこのような要求が出てくるのです。そして、ユーザの方はそれが実現できるものと当たり前のように思いこんでいます。

ここで困った問題が起こることになります。裏蓋を開けると、ごちゃごちゃの塊が出てきます。こいつをどういう風にすれば、ユーザの改造要求が実現できるのか。しかも、改造を請け負った人は、元を作った人とは違う人だったりします。こういう問題が出てくるのは、たいていの場合、技術レベルの極めて低い人が最初に適当なものを作り、そして「作り逃げ」しているケースですね。

このごちゃごちゃの塊を改造して機能を追加しろ、というのですから請け負った人は大変です。しかも、このケースならまだよいのです。世の中には、

ごちゃごちゃの上に最初の要求も満足しておらず放棄された、「途中逃げ」されたシステムというのがあまたあります。

こういうものを、引き継いでちゃんと動くようにし、なおかつ機能追加しろというのですから、それは無茶な話というものです。これは完全に「失敗」というケースですね。世のソフトウェアの６，７割はこれに当たります。最初から作り直した方が早いのです。

話を元に戻します。ここで言う、テストされていないプログラムというのは、ユーザの要求に沿ったテストがされているかどうかという話ではありません。つまり、各種つまみや音が鳴るかという話ではなく、裏蓋の中のごちゃごちゃの中身が個別にテストされているかどうかという話です。

つまり、ごちゃごちゃの塊を機能ごとに分割し、それぞれテストすることができない、あるいはテストするためのツールが揃っていないと、改造した場合に元通りの機能を持っていることが保証できないのです。そして、世に流通しているプログラム（まがりなりにも動いているプログラム）は、これを満たしていないプログラムがほとんどであると言えます。

なぜこういうことになるのでしょうか？

てっとり早くユーザの要求を満たすためには、裏蓋の中のごちゃごちゃを整理する暇などない。

というのが一つの理由であり、そして

整理したそれぞれをテストするツールを作成する暇がない。

というのがもう一つの理由です。プログラマはユーザの要求を満たすという目標に向かって邁進しますが、それを早く実現しなくてはならないため、上の二つを無視して、とにかく必要なだけの配線を引き回してしまいます。そして配線ごちゃごちゃの代物ができてしまいます。

この結果、機能単位に分割してテストすることはできません。テストはユーザに見える部分、つまみや音で判断するしかないのです。

ソフトウェアのコスト面から考えてみると、次のようなことが言えると思います。つまり、機能拡張を一切しない予定のプログラムは比較的安く済み、これを行う予定のプログラムは高くつく、ということです。

これが当然の考え方であるのに、なぜかソフトウェアの「お見積り」なるものには、このような項目は現れてきません。「将来的な機能拡張を可能にするのだから高くなります」というのが本当のところであるにも関わらず。

しかしその一方で、ソフトウェアというものは、将来的に100%機能拡張すると言ってもよいと思います。ということは、実際に機能拡張が容易にできるか否かは、最初にそれを請け負った技術者の技術レベル、あるいは「良心」に委ねられているのです。

これは今日のソフトウェアビジネスには一切現れないけれども、とても重要な点です。A社も100万、B社も100万のお見積りで、ユーザの要求を満足するソフトを開発すると言ったとします。そして実際に、満足するソフトが作成できるものとします。しかし、そこには雲泥の差がありえます。

もしＢ社が上に書いたように、整理整頓された裏蓋の中身を提供しており、それらを個別にテストするツールまで提供してきたとしたら、Ｂ社を選んだ方が圧倒的にお得です。将来的な拡張要求にも耐えられるからです。

しかし、ユーザにはこれが理解できません。裏蓋の中身を理解できないからです。相変らず、つまみと音でしかその機能を判断することができません。あとは、ＣＤラジカセの「デザイン」でしょうか。外見がよければ「良いソフト」であると勘違いします。そして結局、大した技術は無いけれども外見だけは綺麗なものを作ることができるＡ社を選んでしまうのです。

そして、私の経験上ありそうなケースとしては、Ａ社が適当な物を作って、ユーザに納品し、その改造要求が出てくると、Ｂ社に頼むというものです。Ｂ社は技術レベルが高いですから、Ａ社が適当に作ったごちゃごちゃのものを整理しながら、さらに機能拡張することができるのです。こういうことがとにかく頻繁に起こっています。

本来書きたかったことから、話が大幅にずれてしまいました。本来書きたいのは、

ごちゃごちゃの塊にならずに整理整頓された形でプログラムを構成するにはそれなりの経験と技術が必要であり、テストのためのツールを作成するにはプログラム本体を書く時間以上の時間が必要になる。

というところです。ここで大事な点としては、整理整頓とテストツールの作成は、表裏一体で切り離すことができないという点です。テストツールを作成するためには、ごちゃごちゃにならずに整理整頓する必要があるということです。また逆に、単に整理整頓しただけではダメで、どのようにすればテストができるのかを考えながら作成しなくてはいけません。

そして、それらの方法論としてもあまたあり、どの方法論を選択すればベストであるのかを事前に判断することが大前提になります。ある方法論を選択し、システムとそのテストツールを作成して行くと、それを途中で変更するのはとても困難です。

これもまた、世にあまたあるプログラミングを教えるウェブサイトや書籍では、全く言及されていません。また、上の方法論について言及されているものであっても、以下のようなことが言えるのです。

なぜそのような方法論が必要になったのか。なぜ、その方法論をわざわざ苦労してまでも導入しなければならないのか、全く説明が無い。

一つの理由としては、これを理解するには経験が必要であるからと言えるでしょう。初心者に解説したところで理解することは不可能と言えます。実際に多くのシステムを作成し、困った経験が無いと理解できないのです。また、多くのシステムを作成した、とは言っても「作り逃げ」をして「後は野となれ」ばかりでは経験になりません。作って、運用して、機能拡張要求を受け、それを実現するというサイクルを経験することが必要です。

もう少し長くなりそうですが、今日はこの辺で。。。

テストのできないプログラム２

妻の実家の九州の田舎に住んでいた頃は、ベーコンなども作っていました。豚のバラ肉塊を買ってきて塩づけし、スモークチップで何時間か炙ってやるというものです。素人仕事ではありますが、スーパーで買ってくるベーコンの数倍はおいしいのです。

さて、今日は回鍋肉の作り方について書きます。とは言っても、このブログはソフト開発に関するものなので、まぁ最後まで読んでみてください。

この料理も好きでよく作ってきました。学生時代、大学の近くに中華料理屋があり、貧乏学生としてはちょくちょくはいけなかったのですが、当時としては最高のごちそうでした。味の素などから出ているレトルトなどを買ってきては真似てはみたのですが、全くうまくいきません。

よく作るとは言っても、料理教室等に通うつもりもなくすべて自己流なのですが、それがいけなかったですね。長年にわたって失敗ばかりしていたのですが、回鍋肉をうまくつくるコツというのが、間抜けなことに、最近やっとわかってきました。とても簡単なことだったのです。

野菜と調味料を一緒にしてはいけない

ということです。そんなアホなと言われるかもしれませんが。回鍋肉の失敗の原因は（他の多くの料理にも当てはまるのですが）、野菜と調味料を混ぜてしまうことです。そうしてしまうと、野菜の水分が滲み出てしまい、ベチャベチャになってしまうのですね。そうして、せっかくの調味料（この場合は甜麺醤、豆板醤そのほか）がスープ状になってしまい、素材とうまく絡み合わないことになってしまいます。この状態でも丼飯にかければ回鍋肉丼などとごまかすこともできるのですが、気合を入れて作った本人としてはとても悲しいものがあります。

では、どうすればいいのか。事前に野菜の水分を取り去ってしまうこと、あるいは野菜から水分が出ないようにすること。このいずれかです。本格的な中華料理屋では野菜を事前に油通ししてしまいます。こうすると、野菜に火が通ると同時に油でコーティングされてしまい、調味料と出会っても、もはや水分は出てきません。あるいは、湯通しするという方法で事前に水分を抜いてしまうという方法もあるようですが、しかし効果のほどは疑問です。

一般家庭で可能な一番の方法としては「多めの油で炒める」ということになるでしょうか。ネット検索してみると、あらゆ回鍋肉のレシピが掲載されていはいるのですが、この点に言及したものはほとんどありません。

料理とは失敗です。

ご自分で料理を作られた方ならそう思うのではないでしょうか。しかし、多くの「レシピ」なるものにおいて、（特にCookpad等は人気のようですが）失敗の経験とその原因について言及したものは皆無です。これではいつまでたっても料理はうまくなりません。

皆が皆成功体験しか見たくないようです。

そろそろ何かに似てきましたね。ソフト開発も全く同じように思います。ともあれ、このケースでは失敗する原因はとても簡単なことであるのに、どういうわけかありとあらゆる「レシピ」にはそれが記述されていません。

物事を支配する根本原理を考えずに、手っ取り早く成果のみをとりたい、そのような浅はかさが失敗を生む。

と言ってはいいすぎでしょうか。どうにも書籍やネット上の「レシピ」なるものについて、常にこのような印象を持ってしまうのです。

さて、回鍋肉に話を戻します。標準的な回鍋肉の材料は、豚肉とキャベツとピーマン、それに各種調味料程度でしょう。レシピによっては、豚バラ肉の塊を買ってきて１０分煮てから切るなどの凝ったものがありますが、そんなものは好きにすれば良い話です。肝心要の部分は、野菜の水分を出さないようにすること。これにつきます。それには、野菜に先のような措置を施した上に、食べる直前まで野菜と調味料を合わせないこと。これがコツです。

ソフトウェア事情もこれによく似ているのではないかと思っているのですが、まだまとまっていないものでこの話はまた今度。

http://wiredvision.jp/news/201005/2010051322.html

この批判と同様ですが、とにもかくにもiPad（というより、その各アプリケーション）は、画面のどこをタッチすれば何が起こるのかわからず、逆に何をすれば目的が達成できるのかさっぱりわかりません。これには本当にイライラさせられます。しかし、これを言葉で説明するのは難しいですね。実際に寝起きを共にするくらい使いこんでもらわないと、この感覚はわからないかもしれません。

ただ、このUI専門家がとりあげていない（であろう）二つの使いにくさを、ここでは指摘しておきたいと思います。

一つは「指というものが非常に大きいこと」です。私の指が特に大きいのではなく、iPadに表示される内容に比較すると指が大きすぎるのです。指をマウス代わりに使って対象を指示しようとすると、逆に指がその対象を隠してしまうのです。

この点はiPad上の「指をマウス代わりに使わなければならないアプリケーション」の致命的な欠陥です。ほとんど使い物にならないと言ってもよいくらいです。例えば、表示されているテキストをコピーペーストするために範囲指定したいときなど、指がテキストを隠してしまい、どこを選択しているのかわかりません。自動で拡大鏡を表示するアプリもありますが、これはかなり間抜けな考えです。そもそも何のために指で直接指示しているのでしょうか？

あるいは、例えばあるゲームでは、自分の基地にある武器を戦闘フィールドにドラッグドロップして配置するのですが、やはり目的の場所を指が隠してしまい思った通りに置けない場合があります。

つまり、指による操作というのはマウスの代わりにはならないのです。ところがその一方で、現代のアプリケーションというのは、マウス操作で様々な複雑な処理を実現しているため、それをそのままiPad上に実現しても「使いにくいだけ」のものになり下がってしまうというわけです。

iPadというのは、CPUもメモリも通常のパソコンとは比較にならないほど貧弱ですが、それに加えて通常のパソコン用ソフトと同様の機能を搭載することもできないのです。これが、なぜ「使いやすい」のか理解に苦しみます。Appleはその答え、すなわち「ユーザインターフェース標準」というものを提供していません。

もう一点の使いにくさとしては、これも首をひねる点なのですが、根本的にそのデザインが間違っていると感じます。まずiPadは大きすぎます。このデバイスはオフィスや家庭の机の上でだけ使用することを前提としたものでは無いでしょう。もしそうであれば、ノートパソコンを使った方がよいことは明らかです。電車の中や歩きながらなど、様々なシーンで活躍することを前提としているのではないでしょうか。

ところがこれに反して、iPadは持ち歩くには大きすぎるし、重すぎます。せめてAmazonのキンドル程度にできなかったのか。さらにひどいことには、こんなに大きくて重いにも関わらず、ストラップをつける穴が無いのです。このため、手で持ちならが移動する場合は非常に気を使いますし、少しでも落とす可能性がありそうなときにはカバンにしまわなければなりません。

携帯電話でさえ、手で持ちながら歩くのであれば、ストラップを指や手首にかけるなりするのではないでしょうか。iPadはこんなことさえできないのです。

もちろんこれらの使いくさというのは、次世代機では解消されるのかもしれません。しかし、私の仕事がらみで困っていることとしては、「iPad用アプリなら使いやすいのだろう」と信じこむ方々がいることです。そういった方々は実はiPadを使ってもいないし、パソコン用のソフトも真剣には使っていないのです。

悪いのはiPadではもちろんありません。これは単に一企業の製品にすぎませんから、どのような物であっても構わないのです。根本的な問題というのは、世間の評判あるいはAppleが多額の金をかけて創り上げた「雰囲気」を鵜呑みにし、自分の目で確かめようとしない姿勢です。

必要になったらその場でささっと書いて、二度三度利用したら捨ててしまうようなプログラムにこそ向いています。

まして、「システム」というような規模のプログラム、具体的には１万行程度を超えるようなプログラムをこれらの言語で記述するのは異常とも言えます。

なぜでしょうか？

これらの言語で記述されたプログラムは、「プログラムで操作」するのが非常に難しいからです。いきなりややこしい話になってしまいましたが。

Spell Checkerというプログラムをご存知でしょうか。人間の記述した英文をチェックして、辞書に無い単語、つまり綴りの間違いを指摘してくれるプログラムです。

これと同様に、人間が記述したプログラムの間違いを自動的に検出してくれるプログラムというものがあります。「コンパイラ」というものがそういうものですし、最近ではIDE（平たく言えばエディタです）にもそういった機能が搭載されています。

これらのプログラムは、人間がプログラムを書くと、その間違いをその場で指摘してくれたりします。これは大助かりです。

しかし、機械的に間違いを指摘できるかどうかは、対象のプログラミング言語の性質によるのです。

例えば、日常的に使われる英語について、その文法を厳格に守らなければならないと言う法律を作ったらどうでしょうか？Spell Checkerは単語だけでなく、文法の間違いまで明確に指摘してくれることでしょう。しかし、何をするにも厳格に文法を守らなければならないので、小説を書くにも、メールを書くにも堅苦しくて仕方がありません。

簡単にいえば、ブロークンでもいいとする言語がLL言語（スクリプト言語）であり、厳格でなければならないとする言語がJavaやC++といった類の言語です。もちろん、これはかなり強引な例えではありますが。

前者はブロークンですから、少ない言葉で自由自在にささっと書けます。その一方で、後者は同じ処理をするのにも面倒な手続きを長々と書かなければならないのです。

これに対して、前者は機械的な処理にかけて間違いを検出するのが難しく、後者は（もちろんすべてではありませんが）間違いを発見しやすいのです。

このように、あちらを立てればこちらが立たずという状況はどこにでもあるもので、どちらが優れているか、劣っているかなどとは言えないものです。

しかし、一点言えることは、前者のような言語は巨大なシステム、あるいは複数の人間が関わって共同作業で作成していくようなシステムにはまったく向いていません。

現代ではもはや、大きなシステムの作成においては、プログラマの能力だけでそれを遂行することは不可能です。プログラム自体を検証し、間違いを発見し、さらには修正の際のアドバイスまで機械的にしてくれるツール類が欠かせなくなっています。

機械的に処理させるには、できるだけ機械に理解できるような構造を持つ言語でなければなりません。機械はまだまだ愚かですから、それを補うのは人間の役割になってしまうのです。

さて、巷ではRubyという言語が流行しており、どういうわけかこの言語のファンは「Javaなんかより、こんなに短くプログラムが書ける。Rubyはすごいんだ！」などとしきりに宣伝しているようです。また、「Rubyは日本発の技術！」（Rubyの作者は日本人）といって、作者の出身の松江市や福岡県などでも鳴り物入りで「町おこし」に利用しようとしていましたが、こういうことを聞くと非常に不安になります。

ともあれ、適材適所という言葉通り、これらの言語は「比較的規模が大きく、長く使用され、仕様変更がたびたびある」といったプログラム作りには全く向いていません。このような目的については、ダメ言語なのです。

別にどんなヒドイ時代遅れの仕様の言語であっても構わないのです。ごく一部の方々が少々使う限りにおいては。あるいは、その言語の分をわきまえた使い方であるなら。こちらに迷惑がかかるということもありませんから。

問題の本質はこういった「簡単な」言語でヘタクソなプログラムが量産されていることです。しかも、有名ネットショップに似たユーザインターフェースを無理やり作ってみたりします。そして、改修したり機能拡張するのが極めて困難なめちゃくちゃなものであっても、ユーザの方はそれを望むことです。

こういうヒドイプログラムの改修仕事にあたると本当に悲惨ですね。修正や機能拡張するより、初めから書き直した方が早いというのはよくあること、というよりほとんどすべてがそのようなケースと言っても過言ではありません。

さて、こういった状況に拍車をかけているのが、極めて日本的な「工数ビジネス」です。もちろんこれは日本のみの事情かどうかわからないのですが、おそらく日本で著しいのは間違いないところではないでしょうか。

一般的には、エンジニアを派遣する際の「時間単価」の話ですが、ここではプログラム行数の話です。

作成されるプログラムの行数が多ければ多いほど儲かるのです。そのプログラムが何のためのものなのか、あるいはプログラム自体の優劣などは全く関係ありません。とにかく量が多ければお金になります。要するにグラムいくらの世界です。おそるべきことに、質や味は全く無関係なのです。

この種の話はプログラムに限らずあることですね。学生はWikipediaをコピペしてレポートを提出し、同じく役人はWikipediaをコピペして何千万（億でしたっけ？）の仕事をでっちあげる。

同様に、プログラマも「同じようなことをするプログラムがどこかにあったなー」と、その部分からコピーして少しだけ変更し、仕事にします。工数ビジネスの元では、こうすると行数が増えるので儲かりますね。

これは作る方も楽なんです。同じようなことをするプログラムをコピーしてきてちょっとだけ変更するというのは。

プログラミングにおいて、共通の処理や概念を一箇所にまとめて一元管理する、ということはとても難しいのです。同じことをするプログラムであれば、短くする方が難しくなります。そしてそもそも、何が共通であるか、どのような共通概念が存在するのかを発見することには熟練が必要となります。

当然ですね。同じ性能のパソコンであれば、より小さい方が高いに決まってます。小さくするのは難しいのです。工数ビジネス業界では、この程度の常識も通じません。

これができない方はコピーして変更するしかありませんし、その方が楽で儲かります。かくして、ヘタクソで行数だけ多くブヨブヨと太ったプログラムが量産されていくという寸法です。

ずいぶんPHPから話が遠ざかってしまいましたが、PHPの弊害というのは単にその言語仕様という話ではありません。これは話を矮小化した、木を見て森を見ない議論です。

現代では、ありとあらゆる人間活動にソフトウェアが関わるようになってしまいました。しかし、そのほとんどの部分は熟練度の極めて低い方々が作成したものであり、将来的な機能拡張に耐えられるものでは決してありません。結局は描き直さなければならないのです。

なぜPHPはダメ言語なのか３

PHPといっても、PHP研究所のことではありません。ウェブアプリケーション、つまりブログシステム、ソーシャルネットワークシステム、ショッピングカートを作成するのによく使われる言語です。ちなみに今ご覧のwordpressというブログシステムもPHPで作成されているようです。

ちなみに、弊社ではメインの言語としてJavaを使用しています。商品スタッフIIもすべてJava言語で記述しています。

ウェブアプリケーションを作成するための人気の言語といえば、PHPのほかにはPerl、Ruby、Pythonなどというものがありますね。

大昔は主要な言語といえば、FORTRANとかCOBOL位しかなかったものですが、ソフトウェアがあらゆる場面で活躍するようになって、あらゆる言語が登場してきました。それぞれに一長一短はありますし、エンジニアによって好みが違うようです。要するに、万能な言語というものは存在しないようです。

さて、このＰＨＰ、巷ではダメ言語、クソ言語（すみません）などと言われて久しいのです。実際にこの言語はひどい仕様だと思いますし、熟練エンジニア（私のことです）から見れば全く使い物にならないと感じます。

ところが、こういった評価に反してウェブアプリケーションを作成するための言語として最も使用されている言語がPHPなのです。

これはいったい何故なのでしょうか？

PHPは非常に簡単にウェブアプリケーションを作成できるからです。

なぜ、簡単にプログラム開発ができるのに、ダメ言語なのか？おかしいですね。簡単に作れるのであれば「優秀な言語」と言えないでしょうか？しかし、プロの目から見ればこれはやっぱりダメ言語なんです。

その理由は何か？

PHPは大して経験の無いプログラマでも、素早くそこそこのウェブアプリケーションができてしまうのです。

いまやウェブアプリケーションは雨後の筍のようにあちこち存在し、そのニーズも高まる一方です。それを請け負う会社としては、猫の手も借りたい状態です。ですから、それほど経験の無いプログラマを雇ってそこそこのプログラムを作成するわけです。

それがなぜいけないのでしょうか？お客さんの要望を満たせばそれでいいのではないでしょうか？

これもまた建築を喩えにします。ここに例えばPHP工法という、大した経験の無い大工でもそこそこの家を建てることのできる工法があるとします。彼らは、この工法を使って指定した通りの家を早く建築することができます。お客さんは満足します。

しかし、プロの目から見れば、とんでも無い家です。とても長年の風雪に耐え、世代の移り変わりにつれて改造のできる家などではありません。

まず、土台がなっていない、柱の材質がなっていない、設計はデタラメ、改築も困難、とりあえず住むことができるというそれだけの家です。

大部分のPHP製のプログラムはそのような状態です。まるでプログラミングの基礎がわかっていない素人に毛の生えたような方でも、素早く、見かけだけはそれなりのアプリケーションが作成できるのです。

実際のところ、私の遭遇したPHPプログラムはそれはひどい状態で、プログラミングにおける極めて初歩的なことさえ理解していない方が記述したことがありありとわかります。

もちろん、きちんとしたプロのプログラマがPHPで作成している例もありますが、私の経験ではお話にならないような状態のプログラムばかりですし、友人の話を聞いても「PHPプログラマはレベルが極めて低い」という話ばかり聞きます。

これがいつ問題になるかと言えば、例えば以下のケースです。

• バグが出てしまった。早く修正したい
• もっと機能を拡張したい。

建築の例と同様に、これらのプログラムは上の要求にとても耐えられないのです。PHPで記述された世の中の大部分のプログラムはこんなものかと思います。つまり、PHPはウェブアプリケーションプログラマの間口を広げた代償として、粗悪なウェブアプリケーションを多数作りだしてしまったのです。

その一方で、きちんと設計されて作成の難しいウェブアプリケーションは工数が大きいと言って敬遠されているのでしょう。

まさに、悪貨は良貨を駆逐するという諺通りのことが起こっているわけです。

さて、ウェブアプリケーションでのPHPが一方の雄であれば、デスクトップアプリケーションでの雄がVisual Basic(VB)という言語でしょう。これも本当に簡単にアプリケーションが作成できるようです。そして、当然のことながら非常に粗悪な物が多いわけです。

もちろん、言語自体に罪はないのでしょう。問題は経験の浅いエンジニアに大した教育もせずに、そのような言語で簡単に製品を作らせてしまう企業側にあるわけです。

これら二つの言語に共通することと言えば、ユーザインターフェースつまり外見だけは簡単にできてしまうことです。ユーザには外見しか見えませんから、外見がキレイに素早く作成できれば、それだけでユーザはある程度満足してしまいます。

その一方で大した中身はないのです。

くれぐれも、これらの言語を使っていても立派なアプリケーションはあると思います。しかし、非常に多くの「製品」がこのような状態であるのは間違いありません。

はたして簡単なことが良いことなのでしょうか？

なぜPHPはダメ言語なのか２

ソフト会社は他の業界と同じく熾烈な競争にさらされており、他社に先んじてより高度な機能をつけなければそれに勝てないこと。なおかつ、不具合のためにユーザが損害を受けても、その責任をとらなくてよいと法的に認められていること（というよりも、その責任を規定する法律が無いこと）。

ソフト会社というのは常に「前のめり」になって開発を行っているわけです。つまり、現時点での自らの実力以上のものを作成しなければならないことが宿命となります。

しかし、それが故にソフトウェアの発展というのはすさまじいものがあります。「日進月歩」という言葉ならぬ「秒進分歩」と言われてみたり、「dog year」と言われてみたりするわけです。共に意味を検索していただくと、主に情報通信分野で使われているということがわかります。

さて、今回は「ソフトウェアはどのように難しいのか？」をまったく何も知らない方に説明しようと思います。その難しさを実感してもらえば、バグの発生が必然であることをある程度納得してもらえると思います。

ほとんどのバグというものは「プログラマ個人のちょっとした勘違い」から生まれます。もちろん、そうではない「設計上のミス」というものもありますが、これはかなり深刻なものなので、バグと称するのは微妙です。むしろ、Microsofftなどに問い合わせると、このような場合には「仕様です」と一言で片付けられてしまうようです。

「プログラム」というものをチラとでも見たことがある方は、それが文字の羅列であることはわかるでしょう。単純なプログラムの例を書いてみますと。

public static void main(String[]args) {

System.out.println(“hello, world”);

}

と、こんな調子で書いていきます。弊社製品の場合ですと、こういったものが数千ものファイルに分割され、合計で数十万行という規模になります。

こんな文字の羅列ではなくビジュアルに、つまりお絵かきソフトのように絵を書くことでプログラムができあがる、といった環境もずいぶん以前からあるのですが、こういったものは以前に書いた「ぬりえソフト」の類でしかありません。

「ぬりえ」の枠をはみ出そうとすれば、結局は文字の羅列を記述しなければなりません。

簡単にぬりえで所望のものを作れるのであれば、誰でもそれが可能なのであり、その程度のレベルでは競争に勝つことはできません。これは自明の理です。「ぬりえ」自体の性能が上がり、より高度なことができるようになったとしても、常にそれ以上のものが求められるのですから、結局「ぬりえ」では競争に勝つことはできません。

「AccessやFileMakerならビジュアルに簡単にできるじゃないか」。パソコンを少々かじった程度の、こんな方がよくおられるのですが、このような方々は単に「ぬりえ」を描いているに過ぎません。

さて、全くの素人の方にソフトウェアを説明する際の喩え話として最も効果的なのは「大河小説」かと思っています。とは言っても、その登場人物は何千にも何万にもなりえます。そこで起こる事件もそのようなレベルの数です。

このような大河小説の「作成」はどのようなものになるでしょうか？もちろん、これは人間が読むものではありません。機械が読むものです。心配しないように。

例えば、数千もの人が相互に関わりを持ち、数百もの事件が起こるような小説としましょう。数百章で構成され、数十万行から構成されるようなものとしましょう。

記述は非常に難しいものとなるでしょう。なぜでしょうか？

人間の記憶には限界があるからです。これを一人できままに書いたとすると、例えば第３２章で登場人物のAが死んだことになっているのに、第１６９章でBと話をしているなどの矛盾が出てきたりします（SF小説では無いことにしましょうか）。あるいは、第１２３章で飛行機がハワイから飛び立ったことになっているのに、第２５６章の回想シーンでは防寒服を着ていたなど。。。

なにしろ、数千人の登場人物がいるのですから、誰が何章で何をしているか、いつどこで何が起こったかなど覚えていられません。

このような間違いがよく取りざたされる例としては、映画のそれがあります。例えば、前のシーンでは壊れた車が走っているのに、次のシーンではなぜか無傷で、さらの次のシーンでは何事もなかったように壊れているなど。。。。

「映画　間違い」などで検索すると、この種のおかしな現象を指摘するサイトが見つかります。映画の場合、こんなことにならないよう、専門のスタッフがおり、例えば俳優の服装が前回撮影分と同じかなどに気を使っているはずなのですが、多額の予算をかけた映画でもこんなことが起こるわけです。

さて、日本語の文章であれば、それに加えて「てにをは」の間違いや同音異義語の間違いなどが考えられますが、プログラムの場合ではそれらの間違いはコンパイラやインタプリタといったプログラムが自動的に指摘してくれます。

自動的に指摘できない部分は「論理的な間違い」です。映画の場合と同じく、つじつまがあっているかどうかです。コンピュータは論理で動くものですが、論理が正しいことを指摘してくれることはありません。人間の提供するものが完全に論理的でなければ、完全なプログラムは作成できません。

これは途方も無い作業であるどころか、人間の限界を超えかねないことがわかるでしょう。もちろん、大規模なソフトウェアでは既に一人の人間の限界はとっくに超えているわけですが。

ソフトウェア作成とは、爆発する論理的複雑さについて、いかに一貫性を持たせられ続けることができるかという問題であって、単にプログラムという文章を書くことではありません。

もちろん、何百章もあるような大河小説的プログラムでは、全体の構想を「設計する」方、章ごとに実際の文章を書く方、章ごとに論理的な検証を行う方、全体を読んでつじつまがあっているかを調べる方などと手分けをしていくわけですが、各々の担当者における間違いはもちろん減りません。それぞれの担当者は余裕で仕事ができるわけではなく、命をすり減らすような分量の仕事をしているからです。

また、今度はそれらの方々のあいだでのコミュニケーション上で発生する間違い・勘違いが問題になってきて、さらに論理的な間違いの危険が増えます。

実際のところ、担当者が増えれば増えるほど効率は悪くなります。二倍の人間がいれば、二倍のプログラムが作成できるわけではないのです。

さらに問題なのは、「ユーザ」がきままに仕様、すなわち「あらすじ」を変更したがることです。第２９３章でCさんが死んだことにしたのに、ユーザは「かわいそうだからやめろ」と気軽に言いだします。

Cさんが第２９３章の小さなエピソードだけに登場する端役であるなら良いのですが、そうではなく、主な登場人物だとどういうことになるでしょうか？

第２９３章だけではなく、それ以前の伏線や、それ以後の影響など小説全体にわたっての修正が必要になります。Cさんに関わる他の方の行動や事件にも影響を与えます。これはほとんど、「もし日本が戦争に勝っていたら」と同じような根本的な歴史の書き換えになってしまいかねません。

ソフトウェアとは、大規模なものでは人間の限界をはるかに超えた論理のカタマリであり、それを生身の人間が一つ一つ組み立てていくものであり、さらにユーザのきままな変更要求にさらされているものなのです。