さて今回は、Hyper Estraierを利用して不可思議な現象に遭遇したものの、事件に発展する前に解決してしまったというお話です。

問題の現象を前に、自分が書いたコードに原因があるという疑いを拭えず、昨日一日中、色々と調査のようなものを行っていました。でもどうしてもHyper Estraier内の問題のように思えて、今日、思い切ってメーリングリストに質問を投稿しました。

すると...

わずか20分後には、作者の平林さんから回答が返ってきました。その中での指摘は正しく、動作設定を変更することで問題の現象も解消してしまったのです。凄い人です。感謝すると同時に感心しました。

しかし、世の中にはシャーロック・ホームズのような人がいるものです。「実に簡単なことだよ、ワトソン君」とか言われたみたいで、感心するやら、微妙に屈辱的であるやら。

人は、確固とした自らの判断基準を持たない場合、どこかに基準を委ねがちです。委ねる基準の妥当性についての判断もできない場合、さらにその妥当性判断も他人の評価を頼りにします。

そうして人は、自らの判断を放棄して、「権威」と一般的に思われる存在の判断を受け入れる傾向があります。

あの人が言っているから、あのメディアの記事だから、とか。

でも、だからこそ、ちょっと偏屈な位に何事にも一本の筋が通った考え方を持っている方がかっこいいですよね。

そのためには、経験的知識もしくは情報収集とその理解による知見の獲得を経て、演繹的推論とか論理構築を行うことが必要です。何しろ、演繹の出発点となるべき知見がないと始まりません。そのような前提を、思考のベンチマークとか言ってみると、何やらかっこよさげです。

さて、ここまでは導入で、本題は、Hyper EstraierのIndexingは本当に速いのか、 という命題に対する判断にあります。まず安易に済ませられないかと、「権威」の判断を探してみたのですが、上手く見つけられません。ということで仕方なく、ベンチマーキング、です。一本、筋を通すのです。

で、グダグダと枕だけが長い割りに、本題はとりあえず結論だけなんですが...

やっぱりHyper Estraierは速かった。

痩せた畑では豊作は期待できない、ということで、時々、肥料が欲しいと思ったりもします。
で、しばらく前に読んだ本に、いいことが書いてありました。
斉藤由多加著「ハンバーガーを待つ３分間の値段」という本で、「ほぼ日刊イトイ新聞」で連載されていたそうです。私は、連載のことも著者の斉藤さんという方のことも知りませんでしたが、斉藤さんは高名なゲームクリエーターとのことで、ゲーム「シーマン」の生みの親だそうです。
ゲームクリエーターだけに柔軟な思考が開陳されているのですが、特に印象に残った内容をいくつか、自分の思考が豊かに実るように肥料として撒いておきましょう。

「見えないものには名前をつける」
人は名付けられないとその存在を上手く認識できない、だから重要なことや人に印象づけたいことには必ず名前をつけるべきである、ということを斉藤さんは、シーマンの開発段階でのエピソードを通して述べています。
ゲーム内でシーマンが同じフレーズを繰り返してしまう現象を「バンテリン現象」と名付けて、問題の発生を開発チーム内で共有し易くしたというエピソードです。

「正確とリアル」
人間にとってのリアルとは認識にとってのリアルであって、事実の正確性とかならずしも一致しない、時にはデフォルメされたり、情報量を縮退させた方がリアルだったりする、ということを斉藤さんは、航空写真と略図の比較を通して述べています。

「お金で買えるもの情報でしか買えないもの」
貨幣価値には置換できず、情報の物々交換でしか成立しない経済活動がある、その活動基盤となる「場」を提供するサイトがWebでは生き残っている、ということを斉藤さんは、リクルートの「住宅情報」の威力なども交えて述べています。

「問題のすげかえ」
同じ現象、事実に対して、どう認識させるか、その誘導の仕方で受け止められ方は全く異なる、ということを斉藤さんは、シーマンの未熟な音声認識技術の問題を解決したエピソードを通して述べています。
このエピソードは特に考えさせられました。シーマンで使っている音声認識技術は未熟であったため、プレイヤーが話した内容を上手く認識できないことが多々あり、当初は「もう一度、言って」という感じでシーマンが聞き返すという手段を取っていたそうです。
ただ、この対策は、何度、言い直しても、「もう一度、言って」とシーマンに繰り返されるという事態にもつながり、プレイヤーが白けてしまいかねません。そこで、斉藤さんは、認識できない場合にはシーマンが逆キレしてプレイヤーを非難するという発想の転換を行いました。
その結果、責任転嫁されたプレイヤーは、シーマンに対して怒ることも、それまでのように興味を失うこともなく、逆にプレイヤー側で気を使うようになった、という実に感心させられるお話です。

なんだか、色々と考えるヒントになりそうなんですが、まだまだ収穫は先かもしれません。実りの秋が待ち遠しいです。

いえ、残念ながら、P2PとかC/SとかASPとかの話ではありません。単に未熟なプログラマーの悩みのお話です。

手法はなんでもいいのですが、例えばDIなどでプログラムをできるだけ疎結合にして部品の独立性を高める方が、利用の際まで自由度を担保できるはずです。また、例えばなんらかの定数などをプログラム内に保持するよりも、外部に保持させて変更を容易にする方が、利用の自由度、柔軟性は高まるはずです。
束縛を少なくして自由度を高めることは、やっぱりいいことのように思えます。

一方で、部品の独立性が高まると、私のような未熟者あるいは記憶力や注意力が弱い者にとっては、複数の部品が連携して実現される一連の処理のシーケンスを、きちんとトレースすることが難しくなってしまいます。
それよりも一層、深刻なのが、プログラム外で設定された事項が関係すると、途端にコンパイルチェックという庇護から外れ、実行時チェックだけの、プログラミング時には自己責任でチェックするしかない、実に厳しい世界に放り出されることです。

自由と束縛のバランスをどこに置くべきなのか、どこまで庇護を求めるべきか、自分なりの価値観を確立できていないせいで、戸惑ったりするわけです。
悟りを開かれた導師たちはどうなんだろう？

しばらく前から、情報収集に日々どれだけのコストを割くべきなのか、個人的に悩んでいます。というよりも、面倒がって情報収集の努力をほとんど放棄している自分を正当化したいだけかもしれないのですが。

コンピュータのデバイスには、メカニカルな機構を含むデバイスと純粋に電子的なデバイスがあって、通常、後者の方が圧倒的に速いと言えます。大量のデータを処理するような場合、CPUの性能的にはまだまだ余裕があるのに、磁気ディスクへの入出力がボトルネックとなってしまって、処理全体のパフォーマンスが決まってしまったりします。
もちろん、こんなことは、コンピュータシステム開発に携わる人にとっては当たり前の話なので、そのことについて語りたいわけではありません。ここからが正当化の屁理屈です。

人間の脳はCPU＋メモリに例えることができると思います。脳の記憶は必ずしも揮発性のものではないので、不揮発性のフラッシュメモリも含まれているかもしれませんが、まあ何しろ、演算と高速な情報格納と転送が可能なデバイスな訳です。
一方、コンピュータの代表的な外部記憶装置である磁気ディスクに該当するものとして、昔は紙を媒体とした書籍や雑誌やノートなどが利用されていました。そして、磁気ディスクの容量単価の劇的な低下に反比例してコンピュータの内臓ディスク容量が圧倒的に増加したように、人間にとっての外部記憶も、コンピュータの利用やWebの利用の進展に伴って、飛躍的にアクセス可能な情報量が増大しています。
多くの場合、紙媒体にしろWebなどの媒体にしろ、人は視覚を通して文字や図形などの情報を入力しています。そしてなんらかの思考結果を、咽頭や口唇の運動によって話すか、指先の運動によって筆記するかキーボード操作するかして、出力するのです。
脳内が電子的な処理で高速であるのに対し、目や指による入出力はメカニカルで格段に低速になってしまいます。ちょうどコンピュータの外部入出力装置がボトルネックとなったように、人間にとっての情報処理のボトルネックもやはり入出力装置にあるのは明らかです。

目や指とかはレガシーなデバイスかもしれませんが、代替するような仕組みを今は想像できませんし、それにあんまり想像したくもないですし。そう考えると、コンピュータの大量のデータ処理での問題と同様に、人間の場合にも、情報の入出力に追われてしまうと、高速な演算装置が性能を持て余してしまうのではないか、と。そしてそれは、資源の無駄なのではないか、と。入出力に追われるのではなく、演算装置を有効活用しなければならないのではないか、と。

などと、怠惰な自分を正当化する屁理屈で終わらせないために、ちょっとだけ、ボトルネックの解消を図る方法も考えてみましょう。例えば、生のデータを入力するのではなく、自分以外のより性能のいい演算装置を外部ライブラリとして利用したりするという方が、よりパフォーマンスが向上するのかもしれません。それは、Proxy Patternのようなものかもしれません。あるいは、P2P(Person to Person)とかフォークソノミーなのかもしれない、とも言えなくもないでしょう。

ただ、そうやって仮にパフォーマンスが最適化されたとして、それで万事めでたいのかというと、しかし、そうではないとも思うのです。それはなぜか？......続くかもしれない。

一つ前のエントリで、情報収集に追われてばっかりだと、せっかくのオツムを無駄に待機させてしまうことになっちゃうよ、という屁理屈で自らの怠惰を正当化しようとしました。
そして、自分よりも優秀な他人の頭脳を利用して、つまり他人の思考や意見などを情報として収集すればより効率的なのか、という疑問を残していました。

それは自分の限界を超える手段ではあるけれど、でもそれだけじゃあね、という思います。
ちょうど、ファスト・フードとスロー・フードのようなものではないかと思ったりするのです。つまり、他人の考えをてっとり早く吸収して利用するのはファスト・フードで、そうして吸収したものを発酵させたりしてから改めて利用するのがスロー・フード。特に、なんとかのための黄金の法則とか、そういう安易なノウハウとかが最もファスト・フードっぽいですね。
まあ、ファスト・フードが必ずしも悪いばかりではないのでしょうが、スーパーサイズ・ミーという映画があったように、ひたすら貪るのは健康的ではなさそうです。ブクブクになってしまいそうです。

RSSとかの「feed」も注目されていますし、有効なツールだとは思うものの、「feed me」とひたすら情報を貪ることは「餌付けしてくれぇ」と言っているみたいに思えたりして!?
すいません、屁理屈による自己正当化Part2でした。

かつて受託開発の SI をやっていた頃、「ユーザー」は特定少数でした。その後、パッケージ製品ベンダーに移ってみると、「ユーザー」は特定多数でした。そして、販売前の製品の開発をやっている現在、「ユーザー」は不特定未知数だったりします。

でもいつでも、「ユーザー」に満足して貰いたいと思ってきたわけです。
実装する機能セット(コード量)と開発コストの関係は、ざっくり考えれば、直線的な比例関係でしょう。現実には規模に応じて複雑度も増大して、単純な比例では済まないのかもしれませんが、まあ、コード量に応じて開発コストは確実に増大するというイメージは間違いないはずです。
一方、製品の機能セットとユーザーの満足度は、単純な比例関係ではないとように思います。
この機能実装量に対して、開発コストとユーザー満足度が異なる関数であることが、開発の妙味だったり苦しみだったりの要因となりがちなのではないかと思うのです。

まずは、満足度の最低レベルはクリアしなければなりません。そこに至るまでの状態を、仮に「サワー・スポット」と呼んでみます。
次に、最低レベルを超えると、開発すればする程にグングン満足度が上がる状態が訪れます。その状態は、「スウィート・スポット」と呼べるでしょう。
最後に、既に一定の満足度を達成して以降、開発しても開発しても、それまでとは違って満足度の向上は緩慢になる時期が訪れるはずです。なぜならば、それまでに多くのユーザの最大公約数的なニーズはほぼ満たされており、そこから先のニーズは千差万別な世界となるはずだからです。
この状態は、「ビター・スポット」と呼びたいところです。それは、酸いも甘いも噛み分けた大人の味覚です。

市場における競争という観点では、ビター・スポットに突入した体力勝負のような競合製品との差別化は避けたいところです。できるだけ、未開のフロンティアを開拓して、スウィート・スポットを享受できるに越したことはありません。
そもそも製品開発における製品の機能的な訴求力や完成度という観点でも、何しろサワー・スポットを超えてスウィート・スポットに到達すべきですし、そうすべく努力することでしょう。

でも、現実の製品開発においては、こんな便利な「ユーザー」の満足度についての道しるべはないのです。
「ユーザー」とは誰のことでしょうか？ どこにその「ユーザー」はいるのでしょうか？
もちろん、そんな「ユーザー」はどこにもいません。皆のニーズを過不足なく代表するような「ユーザー」なんてファンタジーです。
おまけに機能セットとユーザーの満足度は連続的な関数ではなく、離散的な関数です。つまりコードを1行増やせば、その分、満足度が高まるということはなく、あるコードのまとまりである機能セットを提供して初めて、満足度へ影響があるからです。
さらに、機能セットに対する満足度も個々のユーザーによって異なる可能性もありますし、そもそも実装の順序も本当は固定されている訳ではありません。

ファンタジーを追い求めて現実から乖離することは避けたいところです。また、たまたま聴こえる特定の声が正解である保障はありません。
では、どうするべきなのか。
多分、ここで、開発者のヴィジョンが問われるのだと思います。
そう言えば、しばらく前に、「ユーザー指向のもの作りに関する一考察」 というCNETのブログ記事にも、そんなようなことが書かれていました。

ヴィジョナリーは挫けちゃ駄目です。頑張るのです。

サッカー好きなので、ホントは、日本代表の選手選考や戦術などについて、言いたいことはいっぱいあるのですが、まあ、ここはそういう場ではないので...

W杯が始まる前の世論は、かなり楽天的なものだったと思います。
それこそが、日本の問題点だと思うのです。しかもそれは、今回のサッカーに限ったことではなく、例えばトリノ五輪の前の世論などにも存在していた問題点だと思えます。
そして、それはソフトウェア開発プロジェクトでもありがちな問題だと、強引に関連付けてみましょう。

その問題点とは、自分たちの都合のいい情報だけを採用し、都合の悪い情報からは目を背けてしまう傾向のことです。その結果、解決すべき問題・課題の発見の機会を逸し、対応策を講じることのないままに、最終局面で破綻が一挙に訪れることとなってしまうのです。

私がこれまでに参画したソフトウェア開発プロジェクトでも、残念ながら、こういう傾向を繰り返してしまいました。
工数の見積りや技術的な難易度についての見込みは楽天的なことが多く、進捗中のスケジュールの遅れは回復可能な、少なくともそれ以上に拡大はしないものとして報告されることが多く、何とかなるだろうという曖昧で希望的な見込みの陰でどんどん問題が深刻化していく、そういう苦い経験を思い出します。

投資行動におけるこういう情報に対するバイアス効果を、何とかと呼んだような気がするので、そもそも人間の心理としてそういう傾向があるのかもしれません。
「見える化」とは、こんな問題への処方箋のことなのでしょうか？
でも、客観的には見えるようにされて見えるはずのものなのに、見たくないものは見ない、というか主観的には見えない、という人間の不思議な心の働きは解決できないような気もするのですが...