« UML仕様書の読み方 | メイン | ビジネスプロセスモデリング »

科学と魔法

長い梅雨も、もうすぐ明けようかという今日この頃、 皆様いかがお過ごしでしょうか。 梅雨は最後に各地で大きな爪跡を残しているようですが、もうすぐ雨続きの日々から抜け出し、 太陽の下で過ごせるようになりますね。なりますよね?! まぁ私はもっぱら、昼間に屋外に出て過ごす時間は極僅かではありますが。

ご無沙汰しておりました(*1)、 前回 に比べて幾分静かにお送りしてみようと思っている私 "岡部" が、 不定期にお届けする雑談コーナー第2回です。

今回のテーマは「科学と魔法」です。「科学と魔法」といえばファンタジー、 そういえば最近なにかとファンタジー分野の作品が話題に上ることが多い気がします。 私も子供の頃は、分厚い本を図書館から借りてきてはよく読んでいたものです。

ソフトウェアの世界では、もっぱら科学の力が大きいように私は思っています(*2)。 科学とは、誤解を恐れずに簡潔化するならば、「記号」と「帰納」と「演繹」です。

記号

そもそも人間は、現象をありのままに知覚しているわけではないですね。 「知覚」するということは、扱うことの出来る情報の形に当てはめているということです。 良い例かは判りませんが、そうであるが故に錯覚という現象が存在するわけです。 科学(その基礎である数学(的方法))では、それをより広義に適用し、 様々な事柄を記号として扱うことで、 複雑な考察も単純化する等して進めていけるようにしているんですね。

まぁ、普段意識せず使っている「名前」だって立派な記号です。

ソフトウェアの世界は、 少なくとも今は、 その仕組みがほぼ全て見えているままですから、 記号論だらけですね。

帰納
様々な具体的な事柄から、抽象化された法則を導くことですね。 記号化して帰納することで、共通法則を軸にして、 広範囲の事柄を抽象化して扱うことが出来るようになるわけです。
演繹
帰納とは逆に、大法則から具体的な結果について導くことですね。 三段論法なんかが該当します。 つまり、各具体的な事柄に当てはめるとどうなるか? を導くわけです。

ね、ソフトウェア自体も、ソフトウェア開発も、とっても科学的な活動でしょう? 実装技術だって、モデリングだって、みんな科学の力といって過言ではありません。

でも、ソフトウェアの世界には魔法の力も登場します。 皆さんの身近なアプリケーション等にも、魔法使いが居るでしょう?

魔法使い、それは「ウィザード」です。科学的に整然と作り上げられたソフトウェアを前に、 次に何をしたら良いのか解らなくなった時、目的に合わせて色んなお膳立てをしてくれるアレです。 なにをどうやったのか教えてくれないまま、気付くとお膳立てが済んでいる、手品師みたいなアレです。

私は、先にも述べたように、ソフトウェアにおいては科学の力が大きいと思っています。 それは、ソフトウェアがそもそも科学の力に基づいて成り立っている仕組みである,、 ということからも自明と言って良いでしょう。

でも科学というのは、時に人間の論理にはマッチしないことがあるんですね。 科学の良い所は、理論立てることで広範囲の問題を統一的に扱えることですが、 そうして用意された「これだけあれば、演繹でどんな問題も解けるでしょ」というセットを用意しても、 人間の側が使いこなせないという場合が、あるんですね。

そんな時に登場する助っ人がウィザードになるわけです。 ありがちなシチュエーションであれば、目的に応じて代わりにあれこれ操作してくれるわけですね。 「どんな問題でもこのセットがあれば解決できる」と言われても、オーバースペックである場合もありますし。

これまでの常識を覆して、いっそウィザード式の操作をメインにしてソフトウェアを開発しよう、 という動きもあります。それは、ソフトウェア開発の都合ではなく、 使う人の視点に基づいたユーザーインターフェースを提供するということでもあります。 ソフトウェア開発の都合で科学的な操作セットをそのまま押し付けるのは、 エゴであり、サボリだというわけです。

他方、だからといって、何もかもウィザード式にすれば良いかというと、そうでもありません。 科学的な操作セットが役に立つ(*3)こともありますし、 少なくともソフトウェアの内部は科学的で良いと思いますから。 ただ、機能を実現する方法と、ユーザーインターフェースの提供の仕方は、 別だということですね。 ユーザーインターフェース部分がちゃんと機能実装と分離しているならば、 使用者や目的に合わせて最適なインターフェースをラッパーとして提供すればよいのですから。

そうすれば、ソフトウェア(内部)の開発は科学の力で行い、汎用的に活用できるようにもしておきながら、 ユーザーに対しては用途や目的に応じて適切なインターフェースによってそのサブセットを提供するということが出来ます。 勿論同じユーザでも、違う用途や目的に対しても活用したいということになれば、 そのときにはインターフェースを追加したり組替えたりすれば良いですし、 原理的には同じ問題を扱っている異なるアプリケーションにおいても、 内部は同じでインターフェースの違いで対応することが可能でしょう。 オブジェクト指向であるとかコンポーネントベースの開発手法にも通ずる話ですね。

というわけで、今回はソフトウェアの構造的特徴とユーザーインターフェースのあり方について、 話題にしてみたのだと思います、多分。 それでは、またいつか、第3回でお会いしましょう。

*1
元々、筆不精なんです。書くこと自体は嫌いではないんですが。 書くことは色々と自分の為にもなりますしね。
*2
「それはオマエが理系だからだろう!」とか言われてしまうと、 そうなのかも知れませんけどね。 「理系」と「文系」については、またどこかで論じてみたいですね。 違わないかに見えて違うところと、違うかに見えて違わないところが、 あったりしますよね。 いずれにせよ、そんなにはっきりと線引きがあるとは、思わないですけれども。
*3
私は、科学的な操作セットが全くなくなってしまうのは困ります。 逆にそういう操作セットさえあれば、自分で演繹して問題に対処すれば良いので、安心です^^;
岡部 太一
テクニカルデプト デベロップメントグループ
システムエンジニア

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)