Share
Embed
オブジェクト指向で楽しい人生を送る
「オブジェクト指向」を媒介にして、プログラミング、ギリシャ哲学、パーソナルコンピュータ、メディア論まで、刺激的に感じた繋がりをコラージュしてお伝えします。
AITC - DENTSU SOKEN
June 13, 2022
Transcript
94 slides
-
4 御手洗拓真 所属: 電通国際情報サービス クロスイノベーション本部 AIトランスフォーメーションセンター 経歴: 2015年3月:慶應義塾大学総合政策学部卒(近代史・社会学専攻) 2015年4月:新卒でSBテクノロジー株式会社に入社し、 機械学習システム導入案件などを担当
2020年2月:ISIDへ中途入社 現在は、顧客支援と並行してAIを使った自社サービス開発に尽力中 業務: 機械学習システム開発・導入、自社のAIソフトウェアの開発、製品開発チームのマ ネジメント Qiita : https://qiita.com/tamitarai 趣味: コーヒー、ウィスキー、アイドルなど 略歴 -
5 最近の主なお仕事 最近のメインの業務はAI製品を開発するチームのマネジメントですが、 好きなので実装やお客様へのコンサルティングもしています お仕事の比率イメージ AI製品を開発するチームの マネジメント系業務 (実質MTGとその準備) 事務 処理
AI製品の開発 (設計など含む) 勉強会な どの資料 準備や記 事執筆 40~60% 20~40% 10% 10% -
6 大学時代やっていたこと 基本的には、人文系の勉強と、研究室のQOL改善と、アイドルオタク 一年 休学 二年 三年 四年 近代日本史系のゼミに入り、研究室を快適にしたり、勉強会したりしながら友達を作る。 ひめキュンフルーツ缶という愛媛県のローカルアイドルに出会い、一生応援することを心に誓う。
「やりたいこと見つからないし東大目指すか・・・。」と考え仮面浪人を始めるが、夏くらいで心が折れる。 一応、幸いにも仮面浪人中に近代日本史や哲学に興味を持てたので、大学でそれをやることにする。 歌が上手くなりたくてアカペラサークルに入り、1か月後に「ここは歌が上手くなりたい人が来る場所ではないのだ。」 と気づく。そして「自分はいったい大学に何をしに来たのだ。。。」と悩み、休学する。 人文系の勉強と、研究室のQOL改善と、アイドルオタクをしながら楽しく過ごす。 人文系の勉強と、研究室のQOL改善と、アイドルオタクをしながら楽しく過ごす。 -
8 研究室のQOL向上 お金がなかったので交通費を浮かせる目的で研究室に寝泊まりするようになり、 以下のようなアイテムによって生活環境改善に努めた。 炊飯器 ケーキやパンも作れて、 生活が一気に豊かに。 クッキングヒーター 火を使うと怒られるが、 クッキングヒーターなら
怒られずに鍋パができる 食料・お米など 人が来ても振舞える。 布団・寝袋 いわずもがなの必需品。 時々干さないとカビが生 えるので注意。 -
11 はじめに まず、私が本日一番お伝えしたいことは「自由な学びを楽しんでください」ということです。 学びの楽しみ方はいろいろあるとは思いますが、 私個人は、いろいろと学ぶ過程で一見関係無さそうな知識が相互に結び付き、 自分のなかでこれまで見聞したものも異なった様相をもって知覚される(=認知が更新される) 経験が学びの醍醐味だと思っています。 本日は、皆様にもなじみ深い「オブジェクト指向」を媒介にして、 プログラミング、ギリシャ哲学、パーソナルコンピュータ、メディア論まで、 私がいままで刺激的に感じた繋がりをコラージュしてお伝えします。
一つ一つの内容と、それぞれが結び付く感覚が皆様の好奇心の糧になれば幸いです。 -
16 例えば、「オブジェクト指向プログラミング」と「オブジェクト指向分析」は (特にオブジェクト指向プログラミングを学ぶときは)違うものだと捉えた方がよいという議論がある ※ 私もこれに同意します。 ちがう物だと考えた方がいい説 “1990年代には、数多くのオブジェクト指向分析・設計方法論が提唱され ました。また、OOPの仕組みが現実世界の様子とよく似ていることから、 オブジェクト指向で現実世界の様子を整理して、それをそのままプログラ ミングすればうまくいくはずだとする考え方も生まれました。
しかし、こうした考え方にはまぎらわしい落とし穴がありました。そ れは、OOPの仕組みと現実世界の様子にはよく似ているところがあるもの の、まったく同じではないことです。(中略)人間が行う仕事をオブジェ クト指向で整理し、それをそのままプログラミングしようとしても実際に はうまくいきません。” 平澤 章著『オブジェクト指向でなぜつくるのか 第三版』 非常に分かりやすくかつ実用的にオブジェクト指 向技術が解説されている名著。オブジェクト指向プ ログラミングについて説明する自身がない方は必読。 https://cdnshop.nikkeibp.co.jp/0000/catalog/S00180/S0018 0_thumb_pc.jpg -
17 一方で、「オブジェクト指向」という言葉をより汎用的に使える概念として捉えている議論もある 汎用的に使える概念なのだという説 https://www.seshop.com/static/images/product/7595/L.png “多くのオブジェクトはただそこにあって摘み取られるのを待っている。 そのようなオブジェクトはそのソフトウェアが適用される物理的な世界の ものをそのままモデル化したものである。実際、オブジェクト技術の強味 の一つはモデリングツールとしての能力にある。ソフトウェアのオブジェ クトの型(クラス)を使って物理的なオブジェクトの型をモデル化し、オ ブジェクト型の間の関係(顧客、継承)を使って、集合や特殊化などの物
理的なオブジェクトの型の間に存在する関係をモデル化する” バートランド・メイヤー著、酒匂 寛 訳 『オブジェクト指向入門 第2版』 「オブジェクト指向入門」の上巻で800P以上ある。 「品質」を目的として演繹的にオブジェクト指向の 原理について徹底的に述べている。私もまだ読んで いる途中。なお著者のメイヤーはフランス人で、本 書の記述スタイルはデカルトなどフランス近世哲学 を意識している気がする。 -
22 オブジェクト指向プログラミングには、大きく分けて2つの流れがある 「オブジェクト指向プログラミング」とは? メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの • 「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された
クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング -
23 メッセージング重視のオブジェクト指向では、 オブジェクトとは、ネットワーク上でメッセージを送り合う、独立した個別の役割を持つコンピュータのメタファー であり、現代のインターネットをプログラミングできるようなイメージ メッセージング重視のオブジェクト指向プログラミング メッセージング重視型 オブジェクト あるオブジェクトから送信されたメッセージは、送信時点ではまだ意味が確定されてお らず、受けてのオブジェクトに解釈されて初めてメッセージに意味が割り当てされる。 (これをクラス重視のオブジェクト指向プログラミングとの違いと考えるとイメージし
やすい) これを「徹底的に遅らせた割り当て(extreme late binding)」と呼ぶ。 各オブジェクトは完全に独立しているので、外部環境が変わり仕様変更が発生しても、 該当するオブジェクトだけを変更/追加をすることで柔軟に変化に対応できる 役割だけ教えてくれれば、 具体的な仕事は自分で決めて判断します! -
24 クラス重視のオブジェクト指向プログラミングでは、 オブジェクト指向とはコードを再利用し、想定外の挙動をさせないためにコードを抽象化するというコンセプト。 メッセージング重視のオブジェクト指向プログラミング クラス重視の オブジェクト 開発者視点に立ち、システムの品質を向上させながら開発を楽にするという工学的な目 的のもとに作られた。次頁に掲載する三大要素は、この目的を実現するための仕組み。 メッセージング重視のオブジェクト指向との違いは、想定外の挙動をさせないために、 「契約(コンストラクト)」によって最初にクラスの仕事を明確にすること、と考える
と分かりやすい。 最初に定義された仕事内容を途中で変えたりしません! きっちり定められた通りにやります! (※ これだけではわかりづらいので後で具体例を出します) -
25 小まとめ ⚫ 「オブジェクト指向」自体についてはよくわからないことがわかった ⚫ 「オブジェクト指向プログラミング」は「メッセージング重視」と「クラス重視」の二つの流れがある ⚫ メッセージング重視の方は、現代のインターネットのような仕組みをプログラムするイメージ。 オブジェクトがどのような仕事をするかはメッセージが届いてからではないと分からない。 ⚫
クラス重視の方は、コードを再利用しやすくしつつ、想定外の動きをさせないための言語。 オブジェクトがする仕事は最初から決まっているため、仕事の結果が保証される。 -
28 そもそも「オブジェクト指向プログラミング」から二つあることがわかった。 まずは、なじみ深い「クラス重視のオブジェクト指向」についておさらいする。 クラス重視のオブジェクト指向おさらい メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの •
「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング -
29 クラス重視オブジェクト指向プログラミングの3大要素 インスタ ンス1-A インスタ ンス1-B インスタ ンス1-C クラス(カプセル化) 継承
ポリモーフィズム クライアント (呼び出し元) FileReader クラス - 変数file - open() - close() • 変数(=データ)とメソッドをひとま とめにして外から隠蔽 • クラスを雛形に、インスタンスをたく さん作る • クラスの定義で共通している部分 をまとめる • 異なるクラスでも メソッドの呼び出し方を共通にする Readerクラス (スーパークラス) - open() - close() FileReader クラス - 変数file - open() - close() IOReader クラス - open() - close() クラス重視のオブジェクト指向は、ソフトウェアの品質向上と開発効率化のためにコードを抽象化する技法。 この目的を達成するための仕組みが、以下のオブジェクト指向の三大要素。 (※ テストでよく出ます。そして仕事でシステム作る場合も必修なので覚えておくと二度お得です。) FileReaderクラスも、 IOReaderクラスも、 open(), close()という共 通のメソッドで呼び出 せる open(), close()という二 つのクラスに共通のメ ソッドを抽象化してま とめる メソッド呼び出し 継承 継承 実現 メソッドは同じで、 変数に格納された値だ けが異なる -
30 品質と効率性を上げることを示す例題 オブジェクト指向による品質向上と開発効率化のメリットをイメージしてもらうために、 具体的な課題をもとに考えてみる ◼ 背景設定 ◼ あなたはきびなご中の給食を作る人兼 pythonの日曜プログラマー ◼
ある日、中学校の先生と生徒を管理するプログラムの一部を書いてほしいと依頼された ◼ 欲しい機能 ◼ 先生と生徒に関する情報をそれぞれのフォーマットで表示する ◼ 先生と生徒の情報を新たに登録する ◼ 先生と生徒の入力値が間違っている場合は日本語でメッセージを表示する ◼ データの制約 ◼ 生徒:名前、年齢(12歳以上15歳以下)、クラス、出席番号(1~40)のフィールドを持つ ◼ 先生:名前、年齢(18歳以上60歳以下、担当クラスのフィールドを持つ -
31 ◼ 背景設定 ◼ あなたはきびなご中の給食を作る人兼 pythonの日曜プログラマー ◼ ある日、中学校の先生と生徒を管理するプログラムの一部を書いてほしいと依頼された ◼ 欲しい機能
◼ 先生と生徒に関する情報をそれぞれのフォーマットで表示する ◼ 先生と生徒の情報を新たに登録する ◼ 先生と生徒の入力値が間違っている場合は日本語でメッセージを表示する ◼ データの制約 ◼ 生徒:名前、年齢(12歳以上15歳以下)、クラス、出席番号(1~40)のフィールドを持つ ◼ 先生:名前、年齢(18歳以上60歳以下、担当クラスのフィールドを持つ プログラマー1年目(タスクベース) プログラミング一年生がやりがちな、とりあえずタスク・機能をベースに作る関数を考えてみるというアプローチ。 print_info()関数があれ ばいいかな register()関数かな それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう -
38 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変
• 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 -
39 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変
• 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 -
40 If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変 • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要
プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) 重複 重複 重複 重複 -
41 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変
• 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 個人が趣味で作るシステムなら良いが、製品としてのソフトウェアの場合には 「再利用しづらい」「修正が大変」なコードを書くとメンテナンスが破綻し、 バグ修正以外のことができなくなりビジネスが破綻する -
42 プログラマー2年目(共通性に注目) 問題点 対応案 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる
• 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、 pirnt_info関数のif文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変 • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 他人の痛みが分かるようになったプログラマー2年目は、タスクだけではなく共通性に注目して、 他の人が辛くならないように関数を切り出す。 -
43 プログラマー2年目(共通性に注目) 対応案 プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる
• 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい -
44 プログラマー2年目(共通性に注目) 対応案 プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる
• 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい -
45 対応案 プログラマー2年目(共通性に注目) プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる
• 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい -
50 残った問題 ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ
を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない 問題点 プログラム側 呼び出す側 -
51 オブジェクト指向(クラス) 問題点 対応案 ⚫ 入力検査の処理を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする
⚫ セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない -
52 オブジェクト指向(クラス) 問題点 対応案 クラス(カプセル化)で、 データと処理をセットにする ⚫ 入力検査の処理を通ったデータに対してしか、 他の処理を適用できないようにする ⚫
データと処理のセットをたくさん複製できる ようにする ⚫ セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない -
53 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫
セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする プログラム -
54 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫
セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする プログラム -
55 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫
セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする 呼び出す側 -
62 何をしたのか? 以下の手順でコードを抽象化してクラスにまとめて隠蔽化し(=カプセル化)、 さらに呼び出すメソッドをクラスで共通にする(=ポリモーフィズム)ことで、 プログラムの品質と、開発効率を向上させた。 1. 2年目:共通している処理を抽象化して関数にする ➢ 重複を減らし、読み手の負荷を軽減 2.
オブジェクト指向:セットになるべきデータと関数をクラスとしてまとめる ➢ 利用する側は、クラスをインスタンス化して利用すること入力チェックなどを意識せずに済む ※できれば、この後さらに以下まで行えるとなお良いが、今回は割愛する • nameやageなどの変数もクラスとして定義し、入力値チェック処理をそちらに委譲する • 今後Parentクラスなどが増えることを考慮し、共通のフィールドと関数を持つスーパークラスUserを用意して継承させる -
63 ※できれば、この後さらに以下まで行えるとなお良いが、今回は割愛する • nameやageなどの変数もクラスとして定義し、入力値チェック処理をそちらに委譲する • 今後Parentクラスなどが増えることを考慮し、共通のフィールドと関数を持つスーパークラスUserを用意して継承させる 何をしたのか? まず、持つべき情報とすべき振る舞いを「抽象的なオブジェクトであるクラス」として定義し、 次に、「具象的なオブジェクトであるインスタンス」を生み出す、という思考法 1.
2年目:共通している処理を抽象化して関数にする ➢ 重複を減らし、読み手の負荷を軽減 2. オブジェクト指向:セットになるべきデータと関数をクラスとしてまとめる ➢ 利用する側は、クラスをインスタンス化して利用すること入力チェックなどを意識せずに済む 以下の手順でコードを抽象化してクラスにまとめて隠蔽化し(=カプセル化)、 さらに呼び出すメソッドをクラスで共通にする(=ポリモーフィズム)ことで、 プログラムの品質と、開発効率を向上させた。 -
65 「クラス」という仕組み自体は純粋に工学的な目的から編み出されたものだが、 よく考えてみると、「クラス→インスタンス化」という仕組みは、 現実とは逆の世界観になっていることに気づく 「抽象を具象化する」という発想 現実の人 オブジェクト指向 抽象的な 犬の概念 抽象的な犬
の概念 (クラス) プードル (インスタンス) コーギー (インスタンス) チワワ (インスタンス) -
66 プラトン (紀元前427年 - 紀元前347年) 2000年前に同じことを考えた人がいた • 古代ギリシャの哲学者 • 「イデア論」などで有名
• 一応高校の倫理でも出てくる https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%A9%E3%83%88%E3%83%B3 -
70 イデアとは何か? ある洞窟内には、我々によく似た囚人が拘束されている。 囚人は、生まれつき鎖に繋がれており洞窟の奥の壁側しか見ることしかできない。 壁には、太陽の光に照らされた動植物の人形の影だけが揺れ動いている。 生まれたときから影しか見ていないため、 囚人たちは人形の影が世界の全てだと思い込んでいる。 そのため、人形の影が消えると囚人たちは、それが世界から消えたのだと捉える。 ある日、囚人たちは鎖から解放され、初めて外の世界を目にする。 しかし、まだ目が慣れていないため、最初は眩しくて何も見ることができない。
光に目をならす訓練をすると世界が活き活きとした動植物で溢れていたことを知る。 イデアについてもう少し理解するために、有名な「洞窟の比喩」の話を聞いてみる ※ 私によるサマリです https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82% A4%E3%83%AB:Plato_-_Allegory_of_the_Cave.png -
71 洞窟の比喩が意味すること ここから、プラトンは何が言いたかったのだろうか? ⚫ 洞窟内の囚人 = 我々現実の人間 ⚫ 洞窟内の移ろいゆく影 =
現実世界のモノ ⚫ 外の世界の動植物 = イデア(理想の形) ⚫ 太陽の光 = イデアを成り立たせ現実世界にもたらしているイデア ※ プラトンはこの「全てのイデアが与る(あずかる)ところのイデア」を「善のイデア」と言ったりもした。 -
72 ⚫ 洞窟内の囚人 = 我々現実の人間 ⚫ 洞窟内の移ろいゆく影 = 現実世界のモノ ⚫
外の世界の動植物 = イデア(理想の形) ⚫ 太陽の光 = イデアを成り立たせ現実世界にもたらしているイデア 洞窟の比喩が意味すること ※ これは皆さんで考えてみてください。いろいろな人がいろいろな読み方をしています。 ちなみに、私は以下のような読み方が好きです。 「人間は、世界を活き活きと認識するための枠(=イデア)のようなものを持っているが、 その枠を使いこなすためにはある種の能力(太陽の光)が必要であり、 その能力は少しずつ訓練をして得ていくしかない」 ここから、プラトンは何が言いたかったのだろうか? ※ プラトンはこの「全てのイデアが与る(あずかる)ところのイデア」を「善のイデア」と言ったりもした。 -
73 クラス重視のオブジェクト指向とプラトン プラトンのイデア論における考え方(イデアの実体化)は、 オブジェクト指向の考え方(クラスのインスタンス化)と相似形になっているように思える。 善の イデア イデア 現実世界の モノ クラス
インスタンス Javaの new演算子 太陽の光 現実の 動植物 影 洞窟の比喩 イデア論 Java -
79 アラン・ケイ 実は、最初の方に出てきていた メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの • 「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された
クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング -
81 Dynabook構想 アラン・ケイは「誰もが使えるパーソナルコンピュータ Dynabook」を構想したが、 その構想の背後には、コンピュータを「目的達成のためのツール」ではなく、 「人々の創造性を拡張するインタラクティブなメタ・メディア(※注)」として捉える発想の転換があった。 コンピュータをこのように捉えることで、コンピュータは高価な限られた人のツールではなく 「パーソナル・コンピュータ」にならなければいけない、という考えに至った。[Kay 1977] まだMacintoshすら発売されていない1970年代にアラン・ケイが構想した「Dynabook」のモック。
20年以上後の2010年に発売されたipadを完全に先取りしているように見える Alan Kay「Personal Dynamic Media」1977 ※注) メタ・メディアとは、さまざまなメディアをシミュレートできる(つまりメタな)メディアのこと -
82 Dynabookとマクルーハン アラン・ケイがコンピュータを人間の創造性を拡張するメタ・メディアとして捉えたのは、 マクルーハンのメディア論の強い影響を受けたことによる。 例えば、「Dynabook」(dynamic:動的 + book:本)の名称も、 マクルーハンが展開したメディア論から取られている “解釈主義的な中世を科学的な社会に変えた支配的な力は印刷機であるというマクルー ハンの主張を軽視してはならない。特に、印刷機は単に本を入手しやすくしただけで
はなく、読むことを学んだ人々の思考パターンを変えたという点が重要である。 (中略) しかし、パソコンは、静的な表現を超えて動的なシミュレーションを行うことにより、 本を超えて新しい種類のルネッサンスをもたらすことを約束していた。 (中略> 私は、このノートサイズのコンピュータのアイデアを、来るべきシリコンでのマク ルーハンのメタファーを表現するために「Dynabook」と名付けた。” アラン・ケイ「ユーザーインタフェースー個人的見解」 -
83 マクルーハンとは? ⚫ カナダ人の思想家で、メディア論の最重要人物の一人だが、 学者なのかどうかは難しいところ。 ⚫ 「メディアはメッセージである」という言葉で有名。 ⚫ 1960年代にはマクルーハン・ブームが巻き起こる マーシャル・マクルーハン(1911~1980
) https://en.wikipedia.org/wiki/File:Marshall_McLuhan.jpg -
85 マクルーハンのメディア論 マクルーハンにおけるメディアとは、「メディア = テクノロジー = 身体の拡張 = 感覚の拡張」。 「メディア」というキーワードを非常に広い意味で捉えなおし、メディア論を文明論に拡張した。
車輪 足の拡張 服 皮膚の拡張 自動車 全身の拡張 メディア 身体拡張 -
86 声を出さなくても(=身体操作なしに)知識を得る ことが可能になり、「知」と「身体」が完全に分離 された。そして世界を自己から引き離して客観的に、 合理的に世界を捉える見るという文化をもたらした。 グーテンベルクの銀河系 メディア=テクノロジーのなかには、人の世界認識を変え、人類史を大きく動かしたものも存在する。 その一つが、グーテンベルクに代表される活版印刷の技術。 活版印刷によって、それまでは超エリートしか読めなかった本を誰もが読めるようになり、 以下のようなことに繋がった。(マクルーハンが言ったこと以外も含みます)
プロテスタントの誕生 国民国家の誕生 個人主義の発生 世界の分節化 本が安価に印刷されるようになったことで、 「個人で聖書を読む」という体験が可能になり、そ れによって「聖書を読むことを通じて、個人が神が 結び付く」というプロテストタントが成立した。 活版印刷によって始めて、均質な知識を多数の人に 教えられるようになった。これにより「国家」とい う非常に広い範囲の人を「国民」という同じ集団と して組織することが可能になった。 個人主義を実現するためには、「身分」を無化させ る必要がある。そしてそのためには、身分に関わら ず同じ知識を持つことが必要であり、それは活版印 刷によってはじめて可能になった。 -
87 人類史とメディアの関係 活版印刷以外にも、以下のようなメディアが人類史を決定づけてきた、という議論を展開した。 このように、マクルーハンにおけるメディアとは、それ自体がパワーを持ち社会の構造を変えてしまうもの。 主要なメディア/ テクノロジー 時代区分 世界の認識 / 感覚の在り方
会話 古代 (中世よりも前) ・ さまざまな感覚が統合されており、過去・未来・現在といった形に、時空を線形に整理する認 識はまだ一般的ではなかった。 ・人々は「いまここ」を生きるような在り方で存在していた 筆記文字技術 中世 ・ アルファベットのような表音文字の登場により、ある一定の方向に世界を秩序立てる世界認識 が生まれた。 ・人々は時空を「過去・未来・現在」という線形な流れを持ったものとして把握 印刷技術 近代 ・活版印刷によって世界を合理的に秩序立てて捉える見方が一気に広範囲に広がり、人々の均質 性がもたらされた。 ・この均質性によって、Nation(国家)が形成され、個人主義が生まれた。 電子技術 現代 ・古代のように様々な感覚が統合された時代に回帰する。 ・人々の神経が電子につながることで世界は急速に近づき、地球が一つの「村」のようになる -
89 そしてオブジェクト指向へ 私はマクルーハンの『Understanding Media』(19641年)を読んで、 あらゆるコミュニケーション・メディアについて最も重要なことは、 メッセージの受け取りは、まさにメッセージの復元であるということ だと理解しました。つまり、メディアに埋め込まれたメッセージを受 け取りたいと思う人は、まずそのメディアを内面化し、それを「引き 算」してメッセージを残せるようにしなければならないのです。「メ ディアはメッセージである」と言ったのは、「メディアを使うなら、
自分がメディアにならなければならない」という意味です。 Alan Kay「User Interface:A Personal View」1989 オブジェクトは、生物の細胞やネットワーク上の各コンピュータのようなもので、 メッセージでしか通信できないと考えました(そのため、メッセージングは最初か ら存在していましたが、プログラミング言語でメッセージングを効率的に行う方法 を見つけ出すのには時間がかかりました)。私は、データをなくしたいと思いまし た。B5000は、信じられないようなHWアーキテクチャーによって、これをほぼ実 現していました。細胞/全体コンピュータのメタファーがデータを取り除くことに なり、"<-"は単なるメッセージトークンであることに気がつきました(私はこれら の記号をすべて関数や手続きの名前だと考えていたので、このことを考えるのにか なり時間がかかりました)。(中略)私にとってのオブジェクト指向プログラミン グとは、メッセージング、状態処理のローカル保持・保護・隠蔽、あらゆるものの 極端な遅延結合だけを意味します。 Alan Kay「Dr. Alan Kay on the Meaning of “Object-Oriented Programming”」2003 マクルーハンの議論とアラン・ケイの書き物をいくつか結び付けると、アラン・ケイのオブジェクト指向においては、 「オブジェクト」とはコンピュータの比喩であり、つまりメディアであり、 したがって、オブジェクト=メディアそれ自体にメッセージが埋め込まれており、 人はそのオブジェクト=メディアを身体の一部(=内面化)として扱える必要がある、とも読めるかもしれない。 (「読める!」と断言するには資料調査が不足している。。。) -
93 おわりに 本日は「オブジェクト指向」を狂言回しとして、 プログラミングから始まり、プラトンを経て、パーソナル・コンピュータ思想と マクルーハンのメディア論までたどってきました。 私が本日このようなテーマにしたのは、実は 最後のアラン・ケイとマクルーハンのお話をしたかったからでした。 実は、私が冒頭でお伝えした「自由な学びを楽しむ」は、 アラン・ケイがやろうとしたことを、私なりに解釈したものでした。 今回、この機会を頂いたことで、私も改めてアラン・ケイの書いた論文などに触れることができ、
本当に大きな学びになりました。まことにありがとうございます。 本日の講義も皆様の自由で楽しい学びに貢献するものになったら幸いです。 -
CONFIDENTIAL 【 お 問 い 合 わ せ 先 】
X(クロス)イノベーション本部 AIトランスフォーメーションセンター 製品開発グループ 御手洗拓真 MAIL:[email protected] TEL :03-6713-6135