もしかするともっと昔からそうなのかもしれないが、 ここ1、2年ほど、深夜のアニメ番組が結構充実していると思う。 その昔は、深夜アニメ自体、殆どなかった。 多少アダルトっぽいのがあったような記憶もあるが、 っていつなんだと追求されるとナニだし、こだわらない。 最近は、なぜこんな時間にやっているのだ、というような内容のものが多い。 例えば、もう終わってしまったが、 「はじめの一歩」 のような格闘系とか、 終わり方に結構酷評もあった 「Hellsing」だとか、 血が画面に出てくるのはよくないとか、 何か一般人には想像できないような(してるが)条件があるのかもしれない。 これが 「ちっちゃな雪使いシュガー」や 「あずまんが大王」となると、 深夜にやる必然性が全然ないような気もする。

※ はじめの一歩: ボクシング漫画。昔は「あしたのジョー」を読んでボクサーになろうという人がいたそうだが、最近は「はじめの一歩」を読んで…だとか。 Hellsing: 吸血鬼系。 ちっちゃな雪使いシュガー: 何と言っていいか分からないが、萌え系なのだろうか?　このあたりのアニメは午後6時とかに放送していても全然おかしくない。

別に深夜アニメに凝っている訳ではないのだが、 22時～24時のアニメ番組がないために、 帰宅時間の都合で、リアルタイムで見るのはどうしても深夜になってしまう。 Bフレッツ導入前は、 インターネットでアニメを見ることができたら便利かと思ったが、 現状では、それほど見たいコンテンツはインターネットで配信されていないようで、 今後に期待したいものだ。

なぜか今のところ惰性で全部見ている深夜アニメが「ちょびっツ」である。 この作品は青年誌に連載された時点で既に話題になっていたが、 中途半端にエッチなのが珍しく深夜系に合っているようだ。 「ちょびっツ」のジャンルは何かというと、やはりSF?　 サイバー系かもしれない。 美少女型パソコン・人工知能・猫耳(?)ということで、 かなりプログラマー受けしそうな内容である。 もちろんポイントは人工知能ではなくて「美少女」の方なのだが、 見たことがない人のために蛇足しておくと、 このアニメ(コミック?)で出てくる「パソコン」は、 外見上は完全に人間的美少女という設定になっている。 人間とどうやって見分けるかというと、耳の形で分かるのである。 耳で区別するというアイデアはマルチを思い出すが、 実は定番なのだろうか?

※ ちょびっツは、CLAMP が青年誌に書くということが話題になった。 「マルチ」はTo Heart というパソコンゲームに出てくる少女型ロボット。 一番人気があったような気がする。

ともかく、 作者が作者だけに、 最後に「またかよ」系の大どんでん返しがあるのかと思って期待しているのだが、 それはそうとして、 設定とか割とアバウトな所と奥が深い描写が混在しているのが面白い。 細かい所にいろいろツッコミを入れたくなってしまう。 かなり気になったのが、 最初の方に出てくるシーンで、 居酒屋のパソコン。 「最近のパソコンは伝票のチェックもできる」という設定なのだ。 作者がどう考えたのか知る由もないが、 「今の技術力では伝票チェックができるパソコンなど作れる訳がない」 と想像したのではないか。 多分、それはその通りである。 伝票に限らず、各種のチェック機能を持っているソフトはあるけど、 途中の支援機能は別として、 実際に「チェックする」のはコンピュータではなく人間なのだ。 人間よりもコンピュータを信じるような時代はまだ来ていない。 だから、機械よりも管制官の指示を信じて飛行機が墜落したりするのである。

※ CLAMPの長編は、最後にどんでん返しがある作品がいくつかある。

で、どこにツッコミたいのか。 伝票チェックするパソコンという設定が、そもそもおかしい。 人間はミスするのが当たり前だが、パソコンはそうでもないのだ。 もちろん、センサーの誤入力は避けがたいし、 それで後の処理がおかしくなるのは、ある意味ミスではある。 にしても、伝票のチェックというのは、 紙に書かれた内容を見て、 あらかじめインプットされているデータを検算するとか、 整合性をチェックするのだと思う。 計算ミスは、最初からパソコンが計算する限りまずありえない。 データの整合性は問題になりそうだが、 さて、そのデータは一体どうやって入力したのだろうか。 わざわざ手入力したとか?

つまり、伝票チェックを任せられるようなパソコンが現実にあるなら、 そもそも最初からそのパソコンで伝票入力すればチェックの必要もないはずだ。 実はパソコンが忙しくて、レジは人間がやるしかないという設定なのか? あるいは、パソコンが入力したのを人間がチェックする、 というのならまだ分かるのだが、まあSFはSFということで。

§

7月号のコラムでちょっと紹介したUMLの話だが、 C Magazine のWeb サイトに出ている回答について。 それによれば、 自動販売機を「アイドル状態」と「入金状態」の2つの状態で表現し、 その遷移を次のように定義してあった。 アイドル状態からは、 「入金」されたら「入金状態」に遷移し、それ以外の操作は無視。 入金状態からの遷移は少しややこしいが、 「入金」されたら金額増加、「選択」されたら状態に応じて「無視」「メッセージ表示」「商品排出およびアイドル状態への遷移」のいずれかを実行。 「返却ボタン」が押されたら、入金額を返却して「アイドル状態」に遷移、 となっていた。

このロジックが微妙だということは、 1000円入れて120円のジュースを買う状況を考えてみればすぐに分かる。 もっとも、お釣りを出せば済む話なのだが、 最初の仕様に「お釣り」という概念がないのだから、これは仕方ない。 ただ、Webの回答の最初に、お釣りをどうするか最初に決めておけ、 と書いてあるので、回答した人がうっかり忘れたのかもしれない。 しかし、それはどうでもいいのである。 実際、この種のエラーは必ず発生するからだ。 むしろ、各種の問題点に対して後からどれだけ柔軟に適応できるかということが、 現場ではポイントになるのである。

ところが、私の場合どうやって回答を考えたのか暴露すると、 実は、やはりいきなりコーディングだったりする。 自販機クラスを作るとしたら一体どうなるか、という所から考えてしまうのだ。 例えば、クラスに必要な属性は何か。 実際は「属性」という発想ではなく、頭の中では「変数」と考えているのだが。 まず、状態を維持するためのプライベート変数として、 投入金額と、中に入っている品物の個数、単価、という程度あればいいか。 簡単のために品物は1種類ということにして、という感じで、 List 1 のような感じか、という所から始めてしまうのである。

---- List 1 自動販売機クラスの例 ----

class Zihanki {
private:
    int m_nMoney; // 投入金額
    int m_nZaiko; // 在庫
    int m_nTanka; // 単価
};

※ C++ である。

m_nTanka のコメントが「単価」というのは相当マヌケだし、 m_nUnitCost とでもすべきか。 なぜ投入金額だけMoneyなんだ、とか謎は多いが、 雰囲気的にはまあいいんじゃないの。 アクセサは後回しにして、処理を実現する関数は、List 2みたいな感じか。

---- List 2 メソッド ---

  public void addMoney(int nMoney); // お金を入れる。
  public void cancel(); // 返却ボタンを押す。
  public void buy(); // 品物を買う。

※ これだと Java っぽいですね。何だろ?

ここではまだ、 処理に失敗した時に呼び出し側に何か戻す、といったことは考えていない。 処理の結果を画面に出すような処理も含めて、 自動販売機側で全ての処理が完結することを想定している。 例えば、 cancel() 関数の呼び出しでは、 戻す金額を呼び出し側に返した方がいいのかもしれないが、 そういう細かいことは後で考えても多分間に合うのだ。

という感じで、要求仕様そのものを考えながらコーディングしてしまうのだが、 こういう発想は大規模なプロジェクトだと使えないし、 下位の仕様検討方法としても、ちょっとイリーガルなのかもしれない。 仕様を作るためのコーディング、と言えばいいか。 だから、コードに対応する仕様が作成中に激変することになる。 ならば、勝手に仕様を変更して自動的に最適化する機能を、 とか考えてみたりするが……。 もっと限定して、自分自身に仕様上の欠陥があるかどうか判定するソフト、 というだけでも実際動いたら凄いと思う。 そういうのがあれば、仕様設計時に、ちょっとは楽が出来るようになるかも。 というか、こんな作り方するから仕様ミスがどんどん発生するわけだが。

§

キリスト教的な発想としては、 ノーリスク、ノーリターンという状況を避ける傾向があるかもしれない。 聖書に、そういう記述があるからだ。 では他はどうかというと、 禅の世界では一日なさざれば一日食うべからず、というのがある。 何もしない人は食わせないぞと解釈をすれば、 結構厳しく感じるかもしれないが、 逆に考えると「食うつもりがなければ何もしなくていい」とも解釈できる。 どちらかというと、ノーリスク、ノーリターン系か。 もっとも、ずっと食わないと死ぬのだが。

「形あるもの必ず壊れる」という格言(定説?)もある。 これを裏返してみると、 形がなければ壊れようがない、ということになる。 そんなモノが本当にあるか。 考えてみると、ソフトウェアがそうだ。 もっとも、最初からある意味壊れたソフト、ってのは実際あるようだけど。 とりあえず、ソフトウェアはいつまでたっても壊れない。

自己成長型のソフトウェアは別である。 プログラムが自分自身を変化させることができれば、、 プログラミング時にプログラマーが想定していない状況にも対応できるかもしれない。 しかし、それは「いつかは原型を留めない失敗状態に発展するかもしれない」 というリスクを抱えることを意味する。 つまり、そのようなソフトウェアは壊れるかもしれないのである。 「ちょびっツ」を見て 「ちょっとリスキーで壊れるかもしれないソフト」 をイメージしてしまうというのも珍しいかもしれないが。

※ 余談だが、 ブログでも書いたように、 メモリ空間にランダムに値を突っ込んで走らせ、 偶然人工知能が出来るのを待つ、というアルゴリズムがあるはずだ。