twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ 未来のいつか

ブログ:未来のいつか



9月末で60歳定年退職しました

当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。その中で、日本ディジタルイクイップメント(DEC)研究開発センタという外資系の知名度のない小さい企業に新卒で入るというのは異例といえば異例かもしれない。本人はそんなことは全然思っていなかったのだが、世間ではそのようなことを思っていたかもしれない。実際、両親はDECのことを知らなかった。*1 DECでは日本語版COBOLプリプロセッサを作るのが最初の仕事だった。実用的なプログラムを作ったことがない新卒のプログラマにとってはちょうど良いサイズのプロジェクトだったと、いまだからこそ思う。 言語プロセッサを作るということは、言語仕様は明確に決まっているので、典型的なウォータフォールモデルになる。仕様が与えられ、それに基づいて設計し、実装する。実装するというのはコードを1行1行書くという地味な作業なのだが、新卒の頭でっかちなプログラマは、もっとカッコいい仕事があるに違いないと思い違いをしている。第二次人工知能のブームなので、そんなところで仕事があるといいなあと思っているんのだが、もちろんない。 最初にやったことは見よう見まねでコマンドスクリプトを駆使してビルド環境を作ることだった。生まれて初めてmakefileを書いた。makefileというのは、どのようにプログラムをコンパイルしてビルドをするかというルールを記したファイルなんだけれど、知っている人には冗長な記述だし、知らない人には、これでは説明にならない。 夜中の0時に、そのスクリプトが動き出すようなスクリプトを書いて、毎日夜中の0時からビルドプロセスが動くようにした。そのビルドプロセスは、当日変更のあったファイルを取り出してコンパイルするだけではなくて、ビルドしたのちに、テストツールを起動して、全テストを流すというものだった。 今でこそ、CI (Continuous Integration)すなわち継続的インテグレーションという名前で知られている、毎日毎日変更のあった部分をビルドしテストをするというプロセスだ。当時は夜中のビルドあるいはデイリービルドと呼んでいた。 夜中のビルドで、毎日毎日全てのテストを流す。プログラムの変更によって時としてテストで不具合を見つけることもある。既存のテストの場合、前日までOKだったのが、その日NGになった場合、当日行った変更が何らかの原因である場合が多い。今まで顕在化していなかったバグがその変更で顕在化する場合もあるし、純粋に新しいバグを埋め込んだということもある。 あるいは新規のテストを追加した場合、元のプログラムに変更がなかったとしても、そのプログラムに含まれていた不都合を新たに発見することもある。 さらには、まだ実装されていない部分のテストを書いている場合はNGが出るのだけど、実装がテストを追い越してしまう場合もある。 TDD(Test Driven Development)などという言葉がない時代のソフトウェア開発でも同様なことは行われていたのである。 ソフトウェア開発を機械力を使って加速する。ソフトウェア開発チームにはプロのプログラマーしかいない。プログラマは、プログラムを書くだけでなく開発環境の整備やテストプログラムも書く。 このCI環境での開発は言語プロセッサ開発でもデータベース管理システムの開発でもOSの開発でもそのプロセスは一緒だ。 DEC時代に学んだこと ソフトウェア開発のイロハを学んだ。プログラムを書いたらコード管理システムにチェックインする。そしてテストを書きテストをする。当たり前のことを当たり前にする。それの大切さを学んだ。 バグを発見したら、それを記録した。その記録が貴重な学びの場になった。どうやってバグを発見したかを記録する。テストで発見したり、たまたま発見したり、製品の場合は顧客が発見する場合もある。そのバグの原因は何かを記録する。いつバグを埋め込んだか。どのように修正したかを記録する。 自分たちが作っているソフトウェアなのに、自分たちがどのようにバグを作り込んでいるか、驚くほど知らないことに唖然とする。どのようにバグを発見しているかの知見も乏しい。 バグデータベースを作るだけでも学びの速度は加速する。最近のソフトウェア開発プロジェクトでは忘れられたプラクティスかもしれない。自ら学びの場を放棄しているようで勿体無いと思うが、実際はどうなのだろうか(実はよく知らない) Gitのようなコード管理システム、jenkinsのようなCI環境などがDECの開発現場にあった。 ソフトウェアの国際化 外資系コンピュータベンダにいると日本語版の開発というのは避けて通れない。本社で作られたソフトウェアが日本のことどころか、英語前提ガチガチで作られていたりして、米国以外では使うこともままならなかったりする。 ASCII7ビット前提とした作りになっていて、当時のUnixもひどかったし、C言語もひどかった。各国向けにソフトウェアを作り変えることをローカライズするとか言っていた。それをより一般化して、ソフトウェアの国際化という概念にしていくのが、1980年代から90年代である。 当時はUnicodeなどというものもなくて、AppleやXeroxの人たちが中心となって、1988年ごろにUnicodeの原型となるものが提案されたが、それはどう考えても使い物になるものではなく、各社のエンジニア達が様々な議論を経て、ISO 10646という形にまとめていく。 他社のエンジニア達と腹を割って議論するという経験を文字コードやソフトウェアの国際化を通じて行えたのは僥倖だった。 Oracle DECはコンピュータ業界を支配していたIBMに対する破壊的イノベーターでだった。70年代から80年代にかけてIBMのローエンド市場をPDP-11ないしVAX 11という16ビットないし32ビットコンピュータで徹底的に破壊していった。アメリカのコンピュータサイエンスの先端にはDECのコンピュータがあった。 IBMへ果敢に挑戦しているもう一つのグループが日本のコンピュータベンダー、日立や富士通だった。彼らはIBMメインフレーム互換マシンを製造していた。80年代のことだ。 IBMのようにハードウェア、OS、ミドルウェア、アプリケーションなど全てを一社で提供するベンダーを垂直統合型ベンダーという。時代は80年代に大きく変わった。PCの登場だ。 PCハードウェア、OS、ミドルウェア、アプリケーション、それぞれを提供するトップベンダーが登場した。それがIntelであり、Microsoftであり、Oracleなどである。 垂直統合型から水平分散型へビジネスモデルが大きく転換していったのだ。 自分はDECという垂直統合型の最後のコンピュータベンダにいた。IBMを破壊的イノベータとして破壊する立場の会社にいたのだが、自分の所属している会社がその波に飲み込まれるとは理解していなかった。 PCはおもちゃだと思っていた。Unix WorkstationはスケーラビリティーがないのでVAXの敵ではないと思っていた。OracleはDEC Rdbほどの性能もなければ機能もない、DEC Rdbは世界で1番のRDBMSだと思っていた。 そして、そのどれも間違いだったと90年代に気がつく。気がついたときにはDECの経営が傾いていた。 「イノベーションのジレンマ (―技術革新が巨大企業を滅ぼすとき (Harvard business school press))」という教科書に載っている通りである。 優秀な経営者が合理的な経営をすればするほど隘路にハマって行く。そして一度その隘路にはまり込んでしまうと二度とそこからは抜け出せない。イノベーターのジレンマである。 プログラマとしてDECで十分経験も積んだ。ソフトウェア国際化についての知見も少なからずある。文字コードについてもJIS(日本工業規格)の標準化委員会にも参加していた。SQL...
続きを読む...
 

ゲーデル、エッシャー、バッハ、第20章、六声のリチェルカーレ、訳者あとがき、訳者紹介まで読了、ダグラスRホフスタッター著、濫読日記風 2018、その15

ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版を読了した。 ゆるゆるとゲーデル、エッシャー、バッハを読む会(ゆるげぶ)で読書会をしていたゲーデル、エッシャー、バッハ(GEB)を読了をした。第20章の次の「六声のリチェルカーレ」も熟読した。 GEBは章番号が付いている本編(?)と章番号がついていない亀やアキレスや蟹が出てくる部分との図と地が織りなす二重らせんの構造をしている。まるでエッシャーの絵のようだ。無限に音階が上昇していくカノンのようだ。 地の部分があるから図が際立ち、図がなければ地の存在は意味がない。 難しい本を読んでいて、理解できないところを無意識にスルーしている自分に気がついた。同じ本をみんなで読むタイプの読書会では、それぞれの人の感想を聞けるので、自分と随分違う読み方をしている、あるいはそのような読み方があるのかという発見にいとまがない。さらに担当を決めて、その章の説明を順番でするというタイプの読書会だと、ゆるげぶはまさにそのような読書会だ、自分なりに咀嚼して理解していないと説明できないので、深い理解が得られる。というか自分の浅い理解に気が付ける。 意識していなかったのだけど、よくわからないところはうわべだけを読んでスルーしていた。説明しようとして、ハタと、あれコレってどーゆーことだと理解していないということに気がついた。理解していないことに気がつくというのは意外とありそうでない経験だ。 シェパード・トーンという無限にオクターブが上がっていくように聞こえる音律(707ページ)というのを知った。そして、映画の効果音にそれが使われるとなんとも言いようのない緊張感を醸し出すということも知った。 知らないということは簡単にわかる。知らないから。だけど理解していないということに気がつくというのはありそうでない。理解しているということは誰かに説明できれば間違っていたとしても理解はしていると言えるので意識できるが、理解していないということを知ることは難しい。 理解度テストなんていうのは日常生活では、ほとんどない。説明を誤解しているなんていうことはむしろ日常茶飯事である。しかし、自分が誤解しているということに気がつくことはほとんどない。そう考えると怖い。 なんていうことを読みながら思った次第である。...
続きを読む...
 

なぜアメリカ大陸横断を列車でしたのか

いろいろな人になぜアメリカ大陸を横断したのかと聞かれる。簡単に自分なりの答えを記しておく。 今回は鉄道(Amtrak)で横断したわけだが、最終的にはクルマで横断したいと思っている。 なんでそんな酔狂なことをするのか?したいからしたいとしか言いようがないのだけど、もうちょっと言葉を重ねてみる。小田実は「何でもみてやろう」で「ニューヨークの摩天楼とミシシッピ河とテキサスの原野を見たくてアメリカに行った」と記している。当時の日本は焼け野原で「摩天楼」は無かったし、ミシシッピ河もテキサスの原野も日本にはない。だからこそ小田実はそれを自分の目で見たかったのだと思う。*1 今回、ミシシッピ河も見たし大平原のトウモロコシ畑も見た。もちろんニューヨークの摩天楼も見た。小田実の聖地巡礼をしたかったわけではない。 大陸横断するときの時間感覚をざっくり理解したかったのである。例えば、行っても行ってもトウモロコシ畑、行っても行っても山岳地帯、走ったら走ったで国内に時差があるので、時計を調整しないといけない。東部夏時間(EDT)から中部夏時間(CDT)に調整する。同様に山岳部夏時間(MDT)、太平洋夏時間(PDT)へそれぞれ進んでいく。 行っても行ってもトウモロコシ畑だ。 そんな規模感を身体性を持って理解したかった。そしてそれはクルマで大陸横断をするための予行演習に他ならない。 行っても行っても山岳地帯。 自分の知っているアメリカは仕事を通じて知っているアメリカだ。新卒で入ったDECは東海岸の大企業(コンピュータハードウェアの製造販売会社)だし、その後転職したOracleは西海岸の大企業(ソフトウェア製造販売会社)だ。東海岸に住んだこともあるし、西海岸(シリコンバレー)にも住んだことがある。アパートの契約をして、クルマを買って、銀行口座を作って小切手でアパート代を払った経験もある。その意味で一般的な日本人よりはアメリカを知っているつもりになっている。 しかし、自分は肌感覚として、都会のIT産業というフィルターを通したアメリカしか知らないということを理解している。いまの大統領を支持し投票した人々を自分は知らない。...
続きを読む...
 

ニューヨークからサンフランシスコまで全米を鉄道で横断してみた

(地図はシカゴからサンフランシスコまで) アムトラックでニューヨークからサンフランシスコまで鉄道で横断してみた。3泊4日、乗り換え2回だ。 https://www.amtrak.com/home.html アメリカは広い。移動するだけで体力を消耗する。頭では理解しているつもりだったけど身体で理解した。 全米を列車で横断する場合、アムトラックのシカゴがハブになっているので、西海岸からならば、シアトル、サンフランシスコ、ロスアンジェルスからシカゴまで行って、そこからボストン、ニューヨーク、ワシントンDCに向かう。東海岸からならその逆だ。 今回はニューヨークからシカゴ経由でサンフランシスコまで行った。途中、Albany-Rensselaerというところでボストンから来る列車に乗り換える。時刻表だと、19:05発でシカゴに翌日の9:45に到着するので14時間40分ほどの旅になると思いきや、時差が1時間あるので、15時間40分の旅だ。 同様にシカゴからサンフランシスコ(Emeryville)までも時差が2時間あって、52時間10分の旅となる。 https://www.amtrak.com/content/dam/projects/dotcom/english/public/documents/timetables/California-Zephyr-Schedule-072017.pdf 60年前、小田実はニューヨークの摩天楼とミシシッピ河とテキサスの原野を見たくてアメリカに行った(「何でも見てやろう」10p)。当時の日本は焼け野原で「摩天楼」は無かったし、ミシシッピ河もテキサスの原野ももちろんない。だからこそ小田実はそれを自分の目で見たかったのだと思う。ベトナム戦争も始まる前の古き良き時代のアメリカをフルブライト留学生として渡米した。 今回、「何でも見てやろう」を再読しながらシカゴからサンフランシスコまで旅をした。車窓からはトウモロコシ畑が行っても行っても続いている。大平原は延々トウモロコシ畑だった。人家などは見えない。 予約方法と席の種類 https://www.amtrak.com/home.html 予約はアムトラックのWebページから行った。 サンフランシスコの場合、Emeryville, CAを選ぶ。どのクラスがいいのかよくわからなかったので、Reserved Coach Seatというのを選んだ。ChicagoからEmeryvilleで$329だった。Premiumは$821で高い。 Coach seat の場合、座席は横幅も席の間隔も広いし、リクライニングはゆったりだ。よく寝れる。 Premiumの場合はベッドみたいだ。予約した時点では、どのような座席かはよくわからなかったので値段で選んだ。 値段の差は主にベッドかリクライニングかによるのかな。前者の場合、飲み物と料理もついているようだ。飛行機のビジネスクラスとエコノミーみたいなものだと理解した。次回は試しにPremiumでもいいかもしれないと思った。 東海岸からシカゴまでは、ボストン、ニューヨーク、ワシントンDCあたりからアムトラックがある。日本からの直行便で本数が多いのはニューヨークなので、起点をそこにした。ボストンやワシントンDCなどでもよかったかもと思った。 ニューヨークからシカゴ...
続きを読む...
 

プログラマ60歳定年説、FA宣言

タイトルは釣りです、すみません。無駄に長いのでお忙しい人は、どーぞ、飛ばしちゃってください。 自分は今年の9月で満60歳になる。60歳というと多くの日本企業の御多分にもれず定年である。定年後に何をするのかしないのか、ここで簡単に記してみる。 日本の伝統的な大手企業(経団連に属するような企業)では、定年などの制度がしっかり整備されているので、先輩たちがどんな暮らしをしているかおおよそのロールモデルがある。一方で自分が今所属している企業は20年ちょっと前に創業したネット系である。規模は大企業だが相対的に若い企業なのでそもそも50代の従業員がそんなにいなくて定年退職した人も数えるくらいである。 日本において職業プログラマの世界では、特にフリーランスではなくて会社に所属している場合、35歳定年説というのが炎上系のネタとしてよく議論される。特にSI系の場合、多重下請け構造の中で歳を食ってプログラミングをしているなんていうのは、よろしくない、あるいは許されない(単価的にも能力的にも)ということがまことしやかに囁かれる。 今回ここでのお話は、そのようなことではなくて、会社の人事制度としての「定年」のお話である。若いプロフェッショナルな皆さんは自分が定年になることなどは想像するのは難しいとは思うが、人は必ず歳をとり、生きていれば誰でも60歳になる。技術系(ジェネラリストではなくエキスパートとして)で生きてきた会社員がどのような考えでどのような選択肢を持つか、あらかじめ考えておくことはあながち無駄なことではないと思う。なんかの参考になればと思う。 働き方改革とか人生100年時代とか働き方とか生き方が話題になる昨今であるが、基本的には年金制度が破綻しつつあるので、定年で仕事やめて、老後は年金で暮らすというのはもはやできませんよ、というのがその根底にある。 さて、それでは自分はどうか。子どもはすでに独立しているので、人生において生活上の固定費は低い。したがって、今の収入をあげるという強いインセンティブは少ない。昔は収入をあげたいと強く思ったものである。(生々しい数字はここでは割愛)。 大雑把に言って、次のような選択肢がある。1)雇用延長で65歳までいる。1年毎の契約社員。2)転職する。3)独立する。個人事業主となるか会社組織を立ち上げて代表になる。 日本の大企業の場合、50代がわんさかいて年功序列型賃金なので、パフォーマンスに比べて高い賃金を貰っていると言われている。企業として成長しているのであれば、それでも問題はないわけであるが、そうでない場合、どうしても定年などの制度がないと解雇が難しいので、人件費が増大して生産性が低くなる。(一般論として) 企業の本音としては、役職定年や定年制度で賃金カット、雇用調整を合法的に行いたいということである。...
続きを読む...
 

無知を楽しむ

難しい本の読書会をやっていて、ウンウン唸りながらわからないなあ〜と思う。 「ゲーデル、エッシャー、バッハ」を読んでいるのだけど、未だに深い森をさまよっているような気分で果たして見晴らしの良いところにたどり着けるのだろうかと時々不安になる。今日の読書会に、白石さんのご紹介で「敷き詰め」が好きで好きでしょうがない、日本テセレーションデザイン協会代表の荒木さんに来ていただき、GEBとの出会いとかエッシャーやテセレーションの話を伺った。*1 空間を同じの模様で敷き詰める。小学校の算数にも出てくるそうだ。算数にも美意識を導入するらしい。 図の部分と地の部分 絵は図の部分で成り立っているのではなくて地の部分があるから図が引き立つ。何かを知るということは、その地の部分も知ることになる。ああ、こんなことも知らなかったのかということを知る。無知の知だ。 現代社会では無知は罪悪だ。我々は自分の無知を隠そうとする。知ったかぶりをする。バズワードを消費してわかったつもりになる。無知に対して無自覚だ。 エッシャーの絵に魅了された人がここにいた。なぜだかわからないけどエッシャーが好きだ。そーゆー人が世界中にいるらしい。 https://ja.wikipedia.org/wiki/マウリッツ・エッシャー エッシャーの生誕100周年を記念して集まった人たちが、Bridgesという団体を作って、毎年カンファレンスを開催している。今年もストックホルムで開催するらしい。 http://bridgesmathart.org...
続きを読む...
 

不完全性定理―数学的体系のあゆみ (ちくま学芸文庫)、野崎明弘著、濫読日記風 2018、その14

不完全性定理―数学的体系のあゆみ (ちくま学芸文庫)を読んだ。 あることを好きとか嫌いとか誰でもあるのだけど、こと「数学」に関しては好き嫌いがはっきりしているような気がする。 高校時代の数学に良い思い出がなく気がつくと嫌いになっていたとか、進路を決めるときに大学入試を数学があるかないかで決めて、それが文系理系の分かれ道になったという人もいるかと思う。 好きと嫌いの軸以外にも数学が得意と不得意というのもある。ここで得意不得意というのは数学の試験の点数を取れるか取れないかという矮小化された評価軸だ。 高校時代の数学というのは、試験の問題を限られた時間内に素早く解くというスキルに特化されていて、大学入試はそのスキルを最大限に発揮する場になる。 数学の問題を解くというスキルにチューニングして行けば、じっくり考えることは時間がかかるのであまり推奨されなくて、過去問の出題パターンから効率よく正解を導き出すテクニックの取得が基本的な戦略になる。 数学のテストを解くというスキルは考えるスキルの訓練ではなくて暗記科目になる。 いいとか悪いとかではなくて受験勉強の弊害というのは結局そのようなところかと思う。 一方、それとは別に「数学」そのものを考えてみると、「抽象的な思考」を極限まで高めたものという感じになる。ものとしての「数」を触ることはできなくても、我々は概念としての「数」を理解しているし、それを扱うことができる。純粋な三角形というものは物理的には存在しないけど、概念としての三角形を思い浮かぶことはできる。...
続きを読む...
 

失踪日記2 アル中病棟、吾妻ひでお著、読了、濫読日記風 2018、その13

失踪日記2 アル中病棟を読んだ。 漫画家の吾妻ひでおがアル中になって専門病院に入院する実話をもとにした漫画。前作の締め切りをバックれて失踪してホームレスになるという「失踪日記」の続編という位置付けだが、本書を執筆するまで8年かかったのはアル中だからか。 アル中の特徴は自分はアル中じゃないと頑なに信じるところから始まる。アルコール依存症は精神病の一種なので専門家に見てもらったほうがいいのだけど本人に自覚がないので難しい。 精神的にアルコールに依存していると、ともかく酒なしではいられなくなって身体的にも依存して、幻覚や幻聴などをみるようになる。そうなると自分一人ではどうしようもないので強制的に入院して治療するしかない。やばいな。 自分の場合、 自称プロの酔っ払いが飲酒をやめた話 - 未来のいつか/hyoshiokの日記で記したように3年ほど前に、『田舎暮らしに殺されない法 (朝日文庫)』、丸山健二著、を読んだことをきっかけに、家で飲むことをやめて、2016年12月頃に禁酒した。...
続きを読む...
 

ゲーデル、エッシャー、バッハの薄い本、その2を #技術書典 に出品する

「ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版」という20世紀の古典の読書会をゆるゆるやっていて、その読書会仲間と、同人誌を昨年の秋に作った。*1、*2 そして、4月22日、秋葉原UDX アキバ・スクエアで開催予定の技術書典に同人誌「ゲーデル、エッシャー、バッハの薄い本#2」を出展する。 「ゲーデル、エッシャー、バッハ」とは一体なんなんだ。読んだ人それぞれ勝手なことを言って結論は出ないのだけど、読書会でワイワイ議論しながら読むのが楽しい。読書会の醍醐味みたいなものである。あまつさえ、それだけでは物足りないのか、同人誌まで作ってしまった。最初に作った同人誌「ゲーデル、エッシャー、バッハの薄い本」を2017年秋に開催された、技術書典というイベントに出したところ準備した100部を1時間弱で完売した。入手できなかった人たち申し訳ございません(ぺこり) 今回、売り切れた薄い本#1と書き下ろしの薄い本#2を出展する。 薄い本#2はダグラス・R・ホフスタッターさんからのメッセージ、30年以上前の日本語版編集者へのインタビュー、10章から15章までのヒッチハイクガイド、そのほかゲーデル、エッシャー、バッハ(GEB)を題材にした漫画などなど盛り沢山だ。 結局GEBとはなんなのか。 自分の回答は「生命のない物質から生命のある存在がどのように生まれるかを述べようとする個人的な試みだ」というものだ。石ころと「自分」の差はなんなのか、それを描いている作品なのだ。 GEBとは何か、その問いに答えるためにはGEBを読む必要がある。700ページを超える大著(約1000グラム)だし、一人で読むのは大変だ。そのおともに薄い本を利用して欲しい。薄い本を読むとGEBを読みたくなる。GEBを読むと薄い本を読みたくなる。そのような補完的な関係を持つように作った。...
続きを読む...
 

銃・病原菌・鉄、ジャレド・ダイアモンド著、読了、濫読日記風 2018、その12

銃・病原菌・鉄(上)、銃・病原菌・鉄(下)1万3000年にわたる人類史の謎 (草思社文庫)を読んだ。 スゴ本の中の人が選んだ、1万円で“一生モノの教養”を身につけるための5冊 - マネ会で紹介されている一冊で面白さは間違いない。 本書をひとことで表すならば「歴史は、異なる人々によって異なる経路をたどったが、それは、人々の置かれた環境の差異によるものであって、人々の生物学的な差異によるものではない」(45ページ) ヨーロッパでは文明が発達し、世界を制覇したが、それはヨーロッパ系の人々が生物学的に優れていたからではなく、たまたまその人々の置かれた環境によるものである。本書は一言でいえば、「人種による優劣という幻想」(32ページ)を打ち砕くものである。 例えば、3章で、スペイン人とインカ帝国の激突が描かれている。コロンブスがアメリカ大陸を発見して、ヨーロッパ人が新世界を植民地化した。その逆、すなわちインカ帝国の人たちがヨーロッパを植民地化することがなかったのは何故なのか?その問いに3章は答える。 ヨーロッパ人が新大陸を征服した結果、アメリカ先住民は激減した。 ヨーロッパ人とアメリカ先住民との関係におけるもっとも劇的な瞬間は、一五三二年十一月十六日にスペイン征服者ピサロとインカ皇帝アタワルパがペルー北方の高地カハマルカで出会ったときである。(122ページ)...
続きを読む...
 
1 / 71 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2018/10/09 2018年 10月 08日
  2. Today's Linux 2018/10/10 2018年 10月 09日
  3. Today's Linux 2018/10/12 2018年 10月 11日
  4. Today's Linux 2018/10/17 2018年 10月 16日
  5. Today's Linux 2018/10/18 2018年 10月 17日

Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!