「論理哲学論考」におけるオブジェクト指向
最近、
を読んでいて、とてもオブジェクト指向的な考え方を垣間見たのでここにまとめておく。
二.〇二三一
野矢茂樹『ウィトゲンシュタイン「論理哲学論考」を読む』
対象を捉えるたえめに、たしかに私はその外的な性質をとらえる必要はない。しかし、その内的な性質のすべてをとらえなければいけない。
ここで、「対象」というのは「論理哲学論考」（以下「論考」）においてはテクニカルタームだ。
まず、世界に起こっている事実、または起こりうる事（これを事態と呼ぶ）を何らかのカタチで表現したもの、これを「像」と呼ぶ。
「あの机の上のリンゴは赤い」
という文章があるとき、文字でリンゴと書かれているように見えるのは、僕たちが文字になれきっているせいだ。
ここでは、「このリンゴ」という対象は、「今あなたが見ているディスプレイの黒点の集まり（「このリンゴ」という文字に見える）」という「像」となって表現されている。（意味をあらわす何らかの表現であれば、像と呼ぶには十分であるが）
こんなところで、今回の説明には十分だ。（「捉える」の定義や、もっといろんな事がとても気になる人は、上記の本を読むことをお勧めする）
ここで問題となっているのは「対象」の性質を記述するために出てくる「外的」「内的」という言葉だ。
外的な性質
外的な性質とは、その性質が変化したとしても、その対象がなお同一であり続ける性質のことを言う。
たとえば、先の例で言えば机の上にあったリンゴの位置を変化させても、そのリンゴはそのリンゴだ。
また、そのリンゴが青かったらと事実に反することを想像してみても、そのリンゴはそのリンゴだ。
こんな風に「位置」だったり「色」だったり、「味」なんかもそうだ。僕たちが普通「性質」と呼ぶものは
「外的」だと考えられる。
オブジェクト指向でいえば、属性に入っている値に対応するかのようだ。
リンゴクラスのあるオブジェクトを作って、机の上に置いたとすると、オブジェクトとの属性としてはさしあたり、
- color＝赤
- location＝机の上
こんなところ。
内的な性質
外的とは逆で、内的な性質というのはその性質を持っていないとすると、同一性が失われてしまう性質を言う。
たとえば、「何らかの色を持つ」という性質がそうだ。「色を持たない」リンゴというのは想像し得ない。だから、
この性質は内的だ。という具合だ。これ以降、この内的な性質の表現を論理形式と呼び、それを『捉える』ということに
論点が移行していっている。
話をオブジェクト指向にもどすと、内的な性質というのは、オブジェクト指向の言葉でいえば、
「リンゴオブジェクトには色という属性が存在する」という風に、リンゴというクラスの構造を定義していると見ることができる。
class リンゴ{
色 color;
位置 location;
}
こんな風だ。
まだ、僕が読み進めている段階ではメタクラスの概念は出てきていないのだが、単純に考えて「論理形式の内的な性質」というのが
さしあたって、メタクラスになるかと思う。
オブジェクト指向モデリングを行うということは、諸対象の世界（ここでの対象は通常の意味）を「どう見ているか」を表現することじゃないだろうか。だとすると、世界をどうとらえるかという問いに真っ向から立ち向かっている哲学に学ぶところが多いのは共感できる。ウィトゲンシュタインの著作にもオブジェクト指向的な考えが垣間見られてとても楽しかった。
フロントローディングについて雑記
最近、僕の読んでいるブログに
「ソフトウェア開発におけるフロントローディング」
という話がよく出てくる。
フロントローディングは製造業の言葉で、製造の段階で見つかるミスをできる限り少なくするために、できる限り設計段階で作りこんでおこうというもの。
ソフトウェア開発におけるフロントローディングとは？ということを議論される際には、いわゆる
- 「ものづくり」と「ソフトウェアづくり」の違い
がよく議論される。この「作る」というところと「何を」をしぼって、
- 「もの」と「ソフトウェア」の違い
- いったい何を製造して、何を設計しているのか？という点
を中心に議論される。
この2点目についてu1rohさんは興味深い点を指摘されている。
まずソフトウェアでは製造（＝コンパイル）は完全に自動化されている。昨今はコンパイルにさほど時間がかかることも少ない。設計（＝ソースコード）に間違いがあればコンパイラが瞬時にエラーを返してくれる。
つまり、ソフトウェアにおいては設計に対する製造のコストは限りなく小さいわけで、ソフトウェアには設計工程しかないといっても過言ではないわけだ。これこそ究極のフロントローディングではないか！
ソフトウェア開発は既にフロントローディングである-u_1rohのカタチ
またこうも書かれている。
僕はソフトウェアの設計とはコーディングであってUMLではないという立場をとっている。
ソフトウェア開発は既にフロントローディングである-u_1rohのカタチ
ここでは、
「製造＝コンパイル」
「設計＝コーディング」
という見方だ。
しかし、製造（コンパイル）が極度に完成度が高く自動化された私たちは、コンパイルによってできたマシン語を「製造」しているという気持ちがあるのだろうか。私たちが書いたソースコードが、自動でマシン語に変換されるのであればソースコードを製造している事とマシン語を製造することは、コンパイラによって、ほぼ同義とされるのではないか。
僕が指摘したい点は、
これまで、「設計」→「製造」という流れで作っていたもので、
製造が完全に自動化されると、もはや製造に目を向ける必要はなくて（これは過言な気がするが）、これまで設計で出力されていたものを製造すればよい
という風に、
「製造するものの転移」
が起こると言う点だ。ソフトウェアの世界では完全にではないかもしれないが、もうすでにこの転移が起きていると考えられる。
設計工程という作業が残ったのではない。製造する対象物が転移したのだ。（と見るべきだと私は思う）
コンパイラが生まれた時点で、私たちはもはやマシン語を製造する必要はない。
作るべきなのはソースコードなのだ。
次の言葉でも述べられている
ソフトウェア開発の場合には、設計と製造が同時に進行しています。
フロントローディング2 - 銀髪の記憶
設計・製造がほとんど同時に進むというこの言葉はこういった意味からの言葉ではないかと思う。
いわゆる「ものづくり」というのは「実世界」が対象であるから「製造の完全自動化」が非常に非常に困難なため、この転移が起きにくいのだと思う。こう思うと、製造業がソフトウェア業界の力に頼る（シュミレーションなどで）のも自然に思える。
よって、「ソフトウェア開発はすでにフロントローディングだ」という意見は、賛成できる非常に興味深い意見であるものの、私たちが今ソフトウェア開発のために考えなければいけないフロントローディングはもっと先のフロントローディングなのではないだろうか。
「製造するのはソースコードだ」という立場の上でのフロントローディングだ。
この点については
が非常に面白い。
しかしながら、u1rohさんは最後に非常に魅力的な言葉でエントリーを締めくくっている。
僕は夢見ている。
ソフトウェア開発は既にフロントローディングである-u_1rohのカタチ
いつの日か、逆に製造業がソフトウェア産業から学ぶようになるのではないか。
いつの日か、今日のソフトウェア業界がTPSから学んでいるように、製造業がエクストリームプログラミングから学ぶようになるのではないか。
いつの日か、製造業のCADモデリングにテスト駆動開発が導入されるようになるのではないか。
いつの日か、ソフトウェア産業が製造業に恩返しする時が訪れるのではないだろうか、と。
u1rohさんが指摘されているように、コンパイラはマシン語を自動で生成する。
僕たちは今、どんどんソフトウェア開発の自動化の方向へすすんでいるような気がする。
様々な技術によって、製造するソースコードの量を減らす方向（自動化）へ進んでいるということだ。
「製造の自動化」
この言葉は、製造業からみたら究極的な言葉だろう。ソフトウェア開発の未来には、製造業へ恩返しできる時が待っているのではないかと僕も思う。
The Core Protocols V3.01 日本語版
以前、平鍋さんの記事で紹介されていたJim McCarthy氏のThe Core Protocols V.3.01。本家でも翻訳版を募集していたので、翻訳を行いました。
The Core Protocols V.3.03(原文)
http://www.mccarthyshow.com/wp-content/uploads/2011/02/The+Core+Protocols+3.03.pdf
The Core Protocols (Foreign Translations, 日本語訳あり)
http://www.mccarthyshow.com/download-the-core/
チームづくり＝製品づくり
だとJim McCarthy氏言い切る。
この言葉は平鍋さんの言う「ソフトは人が人のために作るものだ」という言葉にも通ずると思うが、Jimの言葉はもうすこし言わんとするところが絞られている。「チーム」こそが大切だと言っているのだ。もう一度言おう。「人」ではない、「チーム」なのだ。
最近、「マインド」という言葉をよく耳にしたり、目にしたりする。特にアジャイルな分野ではこのキーワードが踊る。良いマインドを持っている人達が集まれば、きっと効率よく、開発者たちも気分よく開発を行えるだろう。なのでそのマインドに関する知識をみなで共有する方向に向かうのとはとても理にかなっているし、筆者もアジャイルな分野は大好きだ。
「マインド」を知ることは簡単だ。
しかし、そのマインドを豊に、そしていつでも実践できるように育てるのは非常に難しい。
これはみなが認めることだと、筆者は思う。
「人の質」。
これを簡単に向上させることがどれだけ良いだろう。とりわけコミュニケーション能力についてはこれを教えるだけで十分ビジネスになっている分野だ。
この人の質を向上させることへの難しさや、ばらつきへの対策として有名なのは「開発プロセス」や「プロジェクトマネジメント」といった分野ではないだろうか。開発者たち（プロジェクト）の行っていることを、監視し、把握し、分析し、統制する。しかし、人間は抑えつけられたり、上から渡されるだけのものには、反発する。
開発は人が行う。だから、いかに開発者たちに意欲的に、快適に開発を行ってもらうか。これが大切だ。
これができたら、次は、各個人たちが連携し、シナジーを高めるような「チーム」を作ることができるとなおよいだろう。
Jim McCarthyyの著作である「ソフトウェア開発のダイナミズム」(原著Dynamics of Software Development)に興味深い一節がある。
人と人との間で真実を伝えるための媒介となるもの、それは感情である。
とても納得できる一文だ。
人と人とのコミュニケーションには必ず感情が関与する。
そのお互いの感情によって、伝えたいことが伝わらなかったり、伝わるべき内容が伝わらなかったりする。
他人の感情そのものを外からコントロールすることはできない。しかし、開発者たちの感情の起伏をガイドしたり、悪い方向に感情が爆発しないようになんとかすることならできそうだ。
これこそが今回翻訳させていただいたThe Core Protocolの本質だと筆者は考える。
このプロトコルは
- チームで活動するときに持っておくべき心構え
- チームで活動する際に生ずる様々なコミュニケーションにおいて使える対話の方法（プロトコル）
を定めている。
常にチーム全員が一定の方法に従ってコミュニケーションを行う事で、不必要な感情のやりとりを抑えられるのだ。
このプロトコルに則ってコミュニケーションを行う限り、開発者たちに不必要な感情が起こったとしても、その悪影響を小さく抑えることが可能になるだろう。
不必要な感情による悪影響が小さいということは、各開発者は常によりよい製品をつくるという目的から外れることも少なくなり、結果的に良いチームワークを生むことができるという具合だ。
筆者はこのプロトコルをまだ実践したことはないが、是非実践しているチームの効果を実体験してみたいと思う。
他の皆さんも、一度このThe Core Protocolsに目を通してみてほしいと思う。
「ソフトウェア開発のダイナミズム」(原著Dynamics of Software Development)からとても魅力的な言葉を挙げておく。
- 一見整然と組織されたうわべを剥いで見れば、深く多様な精神文化的混沌が姿を現す。そこには創造性、集団力学、むき出しの本能、技術的スタイルが無秩序に蠢（うご）めいている。画期的なものはこのカオスから生まれる。
- ソフトウェア開発責任者の真の任務は、できる限り多くの知性を集約して製品の製作に役立つ活動に投資することだ。
- 素晴らしいソフトウェアを作ることも、知的に結びついたチームなら手の届く範囲にある。と言うより、そうしたチームの手の届く範囲にしかないのだ。
- 素晴らしいソフトウェアを期限どうりに出荷しようとするなら、全員をこのゲーム（ソフトウェア開発）に没頭させねばならない。
- この本の言っている一番重要なことはわずか3点に集約できる。人々に考えさせること、そこで何を考えさせる必要があるのか、そしてその考えを現実にどう反映させるのか。これだけだ。
