 
|
はてなキーワード: コンピュータとは
真面目系クズとよく言われる感じの性格だから、人から嫌われず、好かれずと言った感じ。
テストの成績は中の下で、ダメでもなく良いわけでもない。普通でもない、よくわかんない感じ。
学校では生徒会に所属してる。けど真面目系なので教師からは少し期待されたりするけど、どうなんだろうね。
まあコンピュータ系はプログラミングとかはRubyとか少しいじれるけど順序どおりのことしかできない,要するにクズだし、そこまでできない。ネットワーク系はWireshark使ったりしてパケット読んだりだから、頭悪い。
クラスで好きになった子がいて、まあ女の人だから正常なんだけど。
他にもショタとかそういう類の子がいいなあとか、同年代とかも,好きかもしれんなあっていうのがある。
これってどうなんだろうかなーって今まで思ってたんだけど..
クラスの人たちがお前は同性愛者だとかオカマとか(普通に男として生活してるつもり)言われて、傷ついた。
んで、そのことがクラスで広まったりしたらどうしようとか考えてるうちに嫌になった。
クラスの好きな人がそのことを知ったらこれからどう接してくれるのか、僕はどう接すればいいのか。
今は大丈夫だけど、これから色々あって、結局知れ渡ったらと考えると阿鼻叫喚。
同性愛って理解してくれないのかなあ,よくわかんないけど。
女を好きになろうと思っても好きになれない。でも好きな子はいる。でもそれじゃ...って気持ち。
男なら好きになれるし,一緒に色々できるのかもなあ..友達という一線は越えない感じになるかもしれないけど。
そういうことなので、今悩んでる。僕はゲイなのか、ホモなのか、バイなのか、ただのショタコンなのか。
ここに書いたらすっきりするかなって、僕はもう大丈夫なのかなって、心配なんだよ。
でもそんなにすっきりしない。ツッコミほしい。
こんにちは。３年前にうちから強引に「余ってるんだったらちょうだい」ともっていった黒いＤＳ、まだ動いていますか。
ちゃんとお礼するといったまま３年ですね。
ところで、今日はごめんなさいね。いつものもちネタ「私コンピュータわからないから。小学生の子供のほうが賢くて無料ダウンロードしまくり」にいっつも正論で「それ犯罪になっちゃうよ」ってかえしてしまって。必ず受けがとれる持ちネタだと思ってるんだから正論で遮られたら怒るのあたりまえですよね。本当にごめんなさい。次からは、あなたに直接いわずにちゃんと警察に通報しますね。あのＤＳも今頃不正コピーソフトを指されているのではないかと心配です。
ではもうお会いすることもないでしょうけどお元気で。
小学生のころ、水曜日の昼休みは決まって友達とコンピュータ室でゲームをするのが常だった。
もちろん今のようなゲームではない。
ちゃちなレーシングゲームと出題されたものをフィールドから探すゲームの2つだけだった。
一緒に行く友達と僕はいつもレーシングゲームばかりやっていた。
ほかにはペイントのようなツールもありそれであそんだりもした。変な絵を描いて友達と笑いあったりした。
このころに「パソコン＝おもしろいもの」という概念が自分の中で定着し、パソコンに対して強気でいられるようになった。
強気でいられる分、トラブルが起きたら両手を挙げるのではなく立ち向かうことができた。
おかげで周りからは「パソコンに詳しい」と思われた。下から見上げられるのは気持ちがよかった。
当時の僕からして主な用途といえばゲームをするか動画を見るか位であったが、
ネットサーフィンをするようになってチャットというものを知り掲示板というものも知った。
たまにテレビで目にする「２ちゃんねる」というところにいってみたりもした。
このころはかまってちゃん気質だったのでチャットや２ちゃんねるでよく実年齢をさらしたのだが、
そのたびに若い若いといわれ、うらやましがれてニヤニヤしたり馬鹿にされて本気で憤慨したりした。
いまもその当時の記憶が残っており、心の片隅で「自分はこの世界で最年少だ」と思っていると思う。
最年少と思っていた自分は、年上の人たちと並んでいると考えていた。
レベルだけ見れば平均より高い、有能な人間だと勘違いしてたところがあったかもしれない。
２０ではないが最近成人を迎えた。
２ちゃんねるをみてるとたまに中学生だの高校生だの正体を明かす人間がいる。
有名人を見れば自分より若い人なんて腐るほどいる。同年代なのに親より稼ぎまくってる人もいる。
それを見るたびに違和感を覚える。
自分が最年少ではなかったのかと。
僕が一番だったのではないのかと。
今現在の自分は、友達の中でもトップとは言えずそれは中学生のときから気づいていたが、
やっとこの年になって実感できるようになってきた。
今の自分は何かをするごとに、この違和感を感じてしまい悩んでいる。
別に１番でなくてもいいことを、それに関してで一番の人と比べて落ち込んだりする。
そしてそれをすべてインターネットの所為にすることもあった。
そして夢がある。
ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践 - 株式会社ビービッ
なんでコンテンツにカネを払うのさ？ デジタル時代のぼくらの著作権入門 - 岡田 斗司夫
競争の作法 いかに働き、投資するか (ちくま新書) - 齊藤 誠
ボリンジャー・バンド入門 ― 相対性原理が取り明かすマーケットの仕組み (ウィザード・ブックシリーズ) - ジョン・A・ボリンジャー
いかにして問題をとくか - G. ポリア
実戦ボトムアップ・マーケティング戦略 - ジャック・トラウト
ビジネスパーソンのための契約の教科書 (文春新書 834) - 福井 健策
原文：The Un-Internet by Dave Winer
こう書くのは初めてじゃない……
毎回全部書き下ろす必要はないわけで、
もはや様式美になってきた感がある。
何回繰りかえしたかとかは置いておいて、
さあ、もう一回はじめようか。
問題は「コントロール」、これに尽きる。
どういうわけか、IT企業の重役はこれを欲しがるんだけれども、
1994年、この繰り返す世界の年代記を書き始めたばかりの私はこう言った。
「私たちよりもユーザーがまた一枚上手だった。
この業界ではだいたい15年周期くらいでこういうことが起こる。
私たちが足元を見失って、ユーザーが反乱して、新しいソフトウェアビジネスが降臨する。」
そこではこうも言っている。
「ユーザーは一度コントロールを手にしたら、二度と返してくれない」。
御存じの通り、いまそれがTwitterコミュニティで起こっている。
コントロールを欲しがるというのは、別にああいった企業の重役の倫理観のせいじゃない。
短期的にはそれが最善のやりかただからだ。
ありうる道は、ユーザーに手綱をうまくかけられるか、競争に負けるかしかない。
若いころの起業家としての私であれば、そのくらいのことはわかっていたんだろうと言われるかもしれないけれども、そうじゃなかった。
簡単にコピーできるものをどうやって商売にしていいか、分からなかった。
だから、詳しくない人にはコピーできないようにするためのコントロールの方法を編み出した。
すると、私たちのソフトウェアをコピーするためのソフトウェアの市場ができあがった。
けっきょくの問題は、ユーザーは私たちの意図に反することをやろうとする人なのかどうか、ということだった。
ユーザーの皆さんは誇りのある人たちだった。
だから私もするだろうことをした。
200ドルはするそのディスクをハサミで真っ二つにしたものを入れた封筒が、次々に送られてきた。
そうやって欲しいものを手に入れた。
私はようやく、いつもこうなるんだということを思い知らされた。
今回は、Appleがユーザーをコントロールしようとする勢力の親分だ。
ユーザーを守るというAppleの説明は、ある程度までは正しい。
iPadにソフトウェアをダウンロードするとき、害が起こさないということはかなりの程度、信頼できる。
そこまでで済むんだったら、私は何も言わない。
済むはずがない。
相手には、どのソフトウェアが自分のプラットフォームで出まわってもいいかを決める権力がある。
そうなれば、言論も規制されるのは避けようがない。
その意味で、iPadプラットフォームはディズニーランドのようなものじゃないだろうか。
ディズニーランドやPixarの映画にないようなものは、そこにもない。
悲しいのは、Appleが若い世代に対する悪い見本になってしまっていることだ。
若い世代というのは、Appleみたいに「ユーザーエクスペリエンス」をコントロールしたがってそうな、
TwitterやTumblrといった、比較的小さな会社のことだ。
彼らは、自由市場の不確実さよりも自分たちの品質管理のセンスのほうが優れていると思っている。
Twitterでは、Twitterがパートナーとして指定したところのコンテンツしか表示できない。
誰にも見えないようにされている。
Tumblrはあるブラウザアドオンをおすすめしないと言い出した。
これを問題にするのはきっと、それなりの数のユーザーが使いたがったからこそだろう。
この決定は開発者だけじゃなくてユーザーまでも巻き込むことになる。
ユーザーを「教育」しなければならなくなる、というのが問題だと彼らは認めた。
あれ？ これって聞き覚えがあるような………
ということで、最後には逆の結果に落ち着くだろう。
そうならなきゃならない、
ということを、インターネットが教えてくれた。
1970年代、それはまだインターネットとは呼ばれていなかった。
その単純さと、コントロールされていないところが好きだった。
あれを載せてはいけない、これは載せてもいい、と命令する人はいなかった。
インターネットが育った周りの環境、つまりメインフレームの世界では、壁はものすごく大きかった。
個人はコンピュータを持てない。
それからループが回るたび、IT業界が持ってくるコントロールを解毒するというのが、インターネットの役割だった。
でも最後には、私たちは壁を乗り越える。
そうするとまた次の壁がやってくる。
成り上がったプラットフォームが数の力で支配しようとする。
そしてまた、おなじ過ちを犯す。
そして、おそらくいつも、インターネットが勝つ。
なんか、誰の役に立つのか分からんけど、私が高校生の頃にこういう説明があったら良かったなぁ……とふと思ったので書いてみた。
さて、大学の工学部機械工学科に入学するとしよう。基本的に機械工学科に含まれる研究分野は多い。もちろんそれには理由があるのだが、それでもほぼすべての学生が学ぶ共通の内容があり、機械工学科を卒業した学生に企業が期待するのはそれらの基礎知識である。そういう意味で機械工学は非常に実学に近いと言っても良い。
機械工学科の教員は本当に口を酸っぱくして「四力を身につけろ」と何度も何度も授業の度に言ってくる。古いタイプの教員ほどその傾向は強い。いわく、「専門分野の基礎がわかっている人間が社会では強い」、「四力が身についていなければ学科長が許しても俺が卒業させない」、云々。で、その四力というのは以下の４つの「力学」のことを指す。
機械力学というのはいわゆるニュートンの力学でいう「剛体の力学」で、弾性・塑性変形しない対象がどのように運動するかを扱う。振動工学とか解析力学とかはだいたいこの延長線上で学ぶ。高校の力学に微分積分を足した感じだと思えばいい。
熱力学はマクロで見た気体や液体の持つエネルギーを対象にする。これも微分積分やエンタルピー・エントロピーの概念を除けば高校で学べる物理とそう大差はない。次の流体力学と合わせて熱流体力学というジャンルを構成していることもある。統計力学は熱力学の延長線上で学ぶことが多いが、量子力学とともに挫折する学生が非常に多い。
流体力学はその名の通り気体と液体を合わせた流体の運動について学ぶ。航空関係の仕事がやりたいなら必須。多くの近似法を学ぶが現実にはコンピュータ・シミュレーションが用いられるのであまり細かく勉強しても役に立つ場面は少ないかもしれない。下の材料力学とは連続体力学という共通の基礎理論を持つ遠い親戚。
最後の材料力学は、弾性をもつ（＝フックの法則に従う）固体の変形が対象。建築学科とか土木工学科だと構造力学という名前で開講されているが、内容はだいたい一緒。これも多くの近似が含まれる体系で、実際にはコンピュータを使った有限要素法でシミュレーションする場面が多い。とはいえ基本を大学学部時代に学んでおくことは非常に重要。
で、これら４つの科目がどう生きてくるかというと、たとえば２０世紀における機械工学の結晶であるところのエンジンの設計なんかにはこれら全部が関わってくる。機械にかかる荷重や振動を解析し（機械力学）、エネルギー効率の高いサイクルを実現し（熱力学）、吸気と排気がスムーズに行える仕組みを作り（流体力学）、これらの条件に耐えうる材料を選ぶ（材料力学）。もちろん就職したあとにこれらすべてに関わることはないし、実際に使える高度な知識を教員が授けるわけではないが、機械の設計に際しては必須の基礎知識ばかり。とはいえ後のように四力から直接発展した研究をしているところはまれで、院試のために勉強したのに後はもう使わなくなった、なんてこともままあるわけだが……。
なお高専からの編入生が入ってくるのは２～３回生なのだが、彼らはすでに四力を身につけていることが多く、運が良ければ通常の学部生からは羨望と尊敬のまなざしを勝ち得ることができる（しかし英語ができないので研究室に入ってから苦労することが多いようだ）。
高度な数学や電磁気学であったり、機械加工や金属材料や設計に関する専門的な知識もカリキュラムに含まれることが多い。みんな大好きロボットは制御工学の範疇で、これは四力とは別に学ぶことになる。ロボット＝メカトロのもう一つの必須分野である電気電子系の講義はほとんどないので独学で学ぶ羽目になるが、微分方程式が解ければ理解にはさして問題はない。プログラミングや数値計算などの授業は開講されていることもあるしされていないこともある。とはいえ機械工学科を出てガチガチのプログラマになることはほとんどないし、教えてくれてもFORTRANか、せいぜいＣが限界である。さすがにBasicを教えているところはない。……ないと信じたい。
実習や実験がドカドカと入ってくるのは理系の宿命なのだが、特徴的なのはＣＡＤの実習。おそらく就職したら即使う（可能性がある）ので、研究室に入る前に一度経験しておくといい。もちろん実際にＣＡＤで製図するのは専門や工業高校卒だったりするのだが、そいつらをチェックしてダメ出しするのは大卒なり院卒なりの仕事になる。
四力を身につけたらいよいよ研究室に配属されることになるのだが、基本的に四力を応用した分野ならなんでも含まれるので本当に各研究室でやっていることがバラバラ。隣の研究室が何をやっているのかは全くわからない（もちろんこれは機械工学科だけではないとは思うが……）。そのため学科のイメージを統一することが難しく、どうしてもわかりやすいロボットなんかをアピールすることが多くなってしまう。とはいえそういう「わかりやすい」ことをやっている研究室は少数派で、実際は地味なシミュレーションや材料のサンプルをいじくりまわしているところが多数派である。最近は医療工学系の研究をしているところが増えたらしいが、光計測だったり材料物性だったり航空工学だったり、あるいは全然関係ないシステム工学だとか原子力工学の教員が居座っていることもあるようだ。こういう教員を食わすために機械工学第二学科（夜間向けの第二部ではない）が設立されたり、環境とかエネルギーとかが名前につく専攻が設立されたりすることがままある（昔は学科内に新しく講座を作るにはいろいろと制限があったらしい）。そういうところは（上位大学なら）ロンダ先として利用されるのが常で、そうした研究室を選んでしまった学部生はマスターの外部生の多さに面食らうことになる。
とはいえいろいろ選べるならまだマシな方で、大学によっては計測か材料かしか選べなかったり、工業高校ばりの金属加工実験を延々とやらされたりすることもある（ようだ）。やりたいことがあるならそれをやっている大学に行け、とは機械工学科志望の高校生のためにある言葉かもしれない。
そう、就職は非常にいいのだ。「学内推薦が余る」という噂を聞いたことがある人がいるかもしれないが、まぎれもない事実である（とはいえ最近は上位校の推薦でもガンガン落としまくる企業が増えたようで就職担当も頭を抱えているようだが）。機電系なる言葉が広まったのはネットが登場して以降らしいが、機電系＝機械工学系と電気電子工学系、というぜんぜん関係ない２つの学科をまとめてこう呼ぶのは、それだけこの国の製造業でこの２学科出身者が必要とされているということだろう。我らが機械工学科の後輩たちのために、これからも経済産業省には「モノづくり立国」なるわかったようでよくわからないスローガンを推進していただきたい。
inspierd by http://anond.hatelabo.jp/20110929232831
追記：あえて上位と下位の大学の事情をごっちゃにして書いているので、受験生諸君はあまり鵜呑みにせず自分でリサーチするようにお勧めする
リマインドしようにも、これを書いた人（＝自分）の学力だと読めない本だったから無理。無理ゲーだった。
第一章
1
意味論的に透明なシステムと結びついた心の概念および計算機モデルを意味する。
この主義の限界を
2
チューリングの形式化が持っている特徴
(1)物理的組織によってではなく、記号操作の形式的特性によるメカニズムの集合全体を包括
(2)そのメカニズムがいかにすれば十分に明確化された問題すべてに取り組むことができるか示している
(3)万能チューリングマシンを定義する方法を示している
⇒ 素材は重要ではなく、形式的特性が能力を原理的に保証している
フォン・ノイマンがコンピュータを設計し、1960s、ジョン・マッカーシーがLISP（プログラム言語）を開発。
⇒ 研究開発が可能に
A・ニューウェルとH・サイモンが物理記号システムという概念を提出
⇒理論的に自覚化・明確化される
3
・物理記号システム
①適切に操作可能なトークンに対して任意に意味を割り当てることができるシステムであり、
②正確にプログラミングすればこの割り当てられた意味論的内容と細かい点においても一致した仕方で行動すると信じられるようなシステム
by 1976 ニューウェル & サイモン
・強い物理記号システムの仮説
SPSS strong-physical-symbol-system
「標準的な記号アトムのフォン・ノイマン型の操作を行っている仮想機械は、一般的な知的行為を実現するための直接的かつ十分な手段を持っている」
①仮想機械
そのプログラムに我々が命令を与える機械を模倣させるような「機械」
・記号を割り当てる
・変数を束縛する
・記号列の複写、読みとり、修正
等々
③標準的な記号アトム
④一般的な知的行為を実現するための直接的で必要かつ十分な手段
そうした機械は、それを支えている特定のアーキテクチュア（その基盤になっている他の現実的もしくは仮想的機械から）まったく独立に真に知的でありうるのであり、逆に言えば他のアーキテクチュアや機械をシュミレートすることなく真に知的でありうる
４
このような主張（標準的なLISPのアトムのごちゃごちゃした操作が、知能や思考の本質を構成しうるという見解）が、ニューウェルとサイモンのものだとできる動かぬ証拠は、彼ら自身の実践。
彼らの仕事の特徴（例:BACON）
・規則あるいはヒューリスティックス（発見的手法）の直列的（経験則を用いたも多少は運が左右する⇔体系的）適用に依存している
・そうしたヒューリステイックスの大部分が、かなり高いレベルで意識的に内省可能
・選ばれた課題領域を扱う
BACON:一連のデータから科学的法則を帰納する（ケプラーの第三法則、オームの法則）
・BACONが取り組んだデータをフォーマット化下のは、人間の労苦
・BACONは十分に構造化された課題にしか取り組めない。
ケプラーの第三法則は見つけられても、ペトリシャーレのカビとバクテリアの関係からペニシリンを発見する事はできない
・BACONが展開する知識とヒューリスティックスは、人間のプロトコルや実験記録に大いに頼り、われわれが自分自身の思考について内省する思考のレベルからかなり直接的にコード化されたもの
⇒この種の思考は原初的で瞬間的なプロセスの上に後から被せられたもの。理解するということを具体的な例で説明する事には役に立たないであろう
サイモン等は、人間の思考のすべてがただ一つの種類の計算アーキテクチュアに依存すると信じている。
しかし、筆者は違う考えを持つ。サイモンとラングレイの仕事では、洞察のひらめきといったタイプの認識を表現できない。
心は、多くの仮想的アーキテクチュアからなる複雑なシステムであると考える
知的課題や、感覚運動的な課題のような、なめらかに無意識的に行われるものは無視されている
５
古典的システムは記号アトムの使用に頼り、コネクショニズムはこれを避ける。
古典主義者:意味論的に透明なシステムの構築に対して、方法論的にコミットしている人々
STS semanttically transparent system
「システムの振る舞いについての記号的な（概念レベルでの）意味論的記述と、システムの形式的な計算活動の内的に表現された対象についての投影可能な意味論的解釈との間にきちんとした写像関係の記述が可能な場合にのみ、そのシステムは意味論的に透明であるといえる」
きわめて大ざっぱにいえば、あるシステムかSTSと見なされるのは、そのアルゴリズムの記述（レベル2）における計算の対象が、概念的レベルの用語で表現されたその課題の分析の記述（レベル1）と同型である場合である。
（レベル１:計算理論:（高い抽象レベルにおいて）どのような関数が計算されるかについての考え
レベル２:表現とアルゴリズム:それを計算する（具体的な）方法
レベル３:インプリメンテーション:現実の機械において計算がいかにして肉体あるいはシリコンなどで実現されるか）
（１）古典的理論は――コネクショニズムはそうではないが――統語論と意味論を組み合わせた記号システムを仮定している
（２）もし何らかの種類の構造化された表現が利用可能であれば、それらの表現についての計算操作を、その構造に鋭敏に反応するかのような形で規定できる。
もしそのような構造が存在していなければ、（すなわち、どんな記号表現も存在していなければ、）計算操作を規定することはできない
◎要するに、古典的システムは、統語論的に構造化された記号的表現を仮定し、そうした表現の構造によって、それに適用される計算操作を規定するものである
第二章
１
ドレイファス:古典的認知主義の問題は、人間の常識的な知識を表象として再現し表現しようとする形式主義の妥当性
サール:形式的なものと志向的なものとの間に、あるいは統語論と意味論との間にギャップが認められる
この二つの種類の懸念について検討する。
２
「あなたの持っているのはそんなにいいボールじゃないわ。それを私にちょうだい。そしたら私、このキャンディーをあなたにあげるわ」
この言葉を理解するために、ミンスキーちとパペートは膨大な概念のリストをあげる。
ウィノブラードのSHRDLUでは不十分。
・フレームは、常識がうまく対処している偶発的出来事のすべてをカバーしているとは思えない（バースデーケーキに立つ黒いローソクに、フレームは対処できるか？）
・フレームからフレームへの移行を促す規則（メタフレーム？）をいつ適用すべきか、システムはどうやって知るのだろう？
ドレイファス:互いに関連しあった特徴や可能性のすべてを、文脈に依存しない事実や規則によって形式的に把握するという課題には際限がないのではないか
３
・ドレイファスの二つの主張
（１）身体問題
「このシャンプーが目に入らないようにご注意ください。もし入った場合は、ぬるま湯でよく洗ってください」
コンピュータは、身体、欲求、感情、共通言語や社会習慣も持たない。だからコンピュータは、この文章が何を洗うように言っているのか理解できない
（２）コード化
人間は自分たちを取り巻く状況がどんなものかを絶えず感じ取ることができる。
このノウハウは、何らかの知識表現言語によって、一種の知識として表現できるものなのだろうか？
AIプログラム（＝言語）が知識を表現する仕方が、現実の課題に対して根本的に不適合だと懸念する。
４
「強いAI仮説」を、サールは批判する
強いAI仮説:適切にプログラムされたコンピュータは、文字通り認知的な状態をとり、その際プログラムは人間の認知を説明するものとなる
Schank and Abelson 1977の、「ストーリーを理解するという志向的活動をシミュレートしているかに見える特別なプログラム」に対して、「中国語の部屋」を使うことで批判する。
サール:形式的に区別される要素に対する計算操作を行っているだけでは、どんなコンピュータも〈理解する〉ことはできない。したがって、そのような計算操作を規定するプログラムが、心の固有の性質について何かを示すこともあり得ない。
具体例:英語話者が英語を理解することと、中国語の部屋の操作者が中国語を「理解すること」の比較
「人間は何も理解していなくても形式的な原理に従うことができる」
以下、サールの誤りについて論じる
５
サールに対する仮想反論「脳シュミレーター説」
脳シュミレータ説：あるりプログラムが中国語を理解する実際の中国人の形式的な構造をモデル化したと仮定すると、そのときそのプログラムは間違いなく真の中国語の理解を構成したことになる
↑（サールの再反論）
（１）脳の形式的な性質は志向性を構成しない（三章にて説明）
（２）脳の形式的な性質が志向性を構成しないのは、ある種の素材だけが思考を支えることができるからである
↑（アナロジー）
光合成：光合成の形式的な記述を手に入れても、素材が違えば光合成は再現できない
では、思考をもたらすような脳の物理的性質とは？
：外因的および内因的な刺戟に対して脳に大規模な変動が引き起こされること
↑（コメント）
『中国語の部屋』が大規模な構造的変動を必要としないシステムなら、中国語の部屋による反論は無効
６
微視的機能主義
機能主義は、心的状態の本質を、
入力、内的状態の変換、出力からなるプロフィールと同一視した。
（適切なプロフィールを持つシステムはどんなものであれ、その規模や性質や構成要素にかかわれなく、当の心的状態を実現するであろう）
↑（批判）
（中国国家脳のような）心的状態を実現する見込みがないようなシステムも、「入力、内的状態の変換、出力」のプロフィールを持つシステムへと組織することは可能であるよように思われる。
こうした極端な寛大さは、機能主義の立場を掘り崩してしまいそう
・問題は、「入力、内的状態の変換、出力」の系列をどこに位置づけるか
×大まかなレベルに位置づけ
⇒感覚質の欠如、極端な寛大さ
△ライカンの「小人機能主義」
○微視的機能主義
・機能主義の批判はゲシュタルト盲に陥っているのでは Lycan 1981
：機能的な構成要素があまりにも大きい、極度に小さい、それらしくない等であるために、そうしたものからなるシステムに志向性を帰属させるという考えに抵抗するということ
（ライカン「小人機能主義」
：機能的な下位システムは、それがエージェントのために何をしているかということによって同定される）
微視的機能主義
内容や目的に関連づけからはかけ離れた用語で
記述しようとするもの
・諸関係が得られたとき、システムには大規模で柔軟な構造的変動が引き起こされ、またそれによってさまざまな創発敵的性質が得られるようになる
第三章
１
２
「民間心理学」
：自分や他人が、信じたり、希望したり、恐れたり、欲求したりしているということについての日常の理解
民間心理学は、行為・運動を説明するときに、信念や欲求という表現を用いる
「民間心理学は、人間の行動に先立つ内的原因についての素朴で原初的な科学」
３
（１）民間心理学は、偏狭な、特定の人々に限定されたような理解しか与えない。
民間心理学は、子供や狂人や外国人を前にすると、まごついてしまう
（２）民間心理学は停滞したまま、なにも生み出さず、長い間ほとんど変化も進化も発展もしていないところが他の諸科学と異なる
（３）民間心理学は、これまでのところ科学の主要部分にうまく統合されていくような徴候をまったく示していない。残念なことに民間心理学は自然を神経生理学的ないみで妥当な要素にまで分割することには関心がないようである
最近の分析哲学
：頭の状態に関する科学理論というゲームと、民間心理学というゲームを比較することが、そもそも不適当なのではないか
４
Daredevil believes that Electra is dead.
Mary hopes that Fermat's last theorem is true.
のthat以下を、心的状態の内容と言う。
心的状態が考えられる傾向
：われわれの心理学的状態が、本質的に、周囲の世界がどのような状態にあるのかということによって決まるのではなく、
われわれにとってどのように見えているかによって決まる
↓（言い換え）
我々の意識や無意識に何らかの形で影響を与えられないものはどんなものであれ、
本質的に我々の心的状態の正確な限定に関わることはあり得ない
⇒我々の心的状態が現に持っているような内容を持つものは、われわれ自身のあり方ゆえであって、
知られていないかもしれないような周囲世界の事実とは関わりがない……☆
・双生地球……☆に対して疑いを投げかける
双生地球で、「海に水がある」と発話される。
地球A：海にH2Oがある
地球B：海にXYZがある
この違い以外は同質だとする。
すると、
地球上の発話と双生地球の発話は、それぞれH2OがあるかXYZがあるかによってその真偽が決まる
（たとえば、地球Aの海にH2Oがなくて代わりにXYZがあるとしたら、地球Aでの発話は偽になる）
⇒
もし意味が真理条件を確定するのだとすれば、
自然種に関する表現（水、金、空気など）を含む陳述の意味は、
単に主体の限定的に規定可能な状態に言及するだけでは十分に説明できない……☆に反して
二つの選択肢
（１）心理学的な内的要素（地球の話し手と双生地球の話し手に共通）と、
世界関与的な外的要因（仮定上、二つの地球を越えて不変ではない（H2OとXYZ））の両方によって内容が決まるとする、意味と信念に関する合成説
（２）そういったケース（地球と双生地球のケース）は
〈心的状態の純粋に内的でまったく心理学的な要素（☆のこと）〉という観念にさえも疑いを抱かせるものであると考えることもできるだろう
プティ と マクダウェル
「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない。
しかし、
〈頭の中〉にあるものが心の状態に対して構成的関係にあると考え必要があるのだろうか？」
筆者
：あらゆる内容が根本的に世界に関与している（選択肢（２））ということが判明したとしても、
そのこと自体は必ずしも〈認知科学は心の理解に深く（ことによると構成的にではないかもしれないが）関わる研究である〉という主張を覆すものではない
その主張に対する仮想反論と、それに対する再反論をHornsbyは行った。
仮想反論
：「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」とするならば、
心的内容は限定的に規定されねばならない（自然種を指示しない）
（「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」までが、プティとマグダウェルの、「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない」に対応する。）
仮想反論の詳細
：仮定①：
二人の動作主の心的状態は、彼らの行動傾向に何らかの違いがある場合にのみ異なる
（そこに赤いボールがある、と信じなければ、ボールを投げようとは思わない）
仮定②：
行動が異なる（すなわち、行動が異なる）ためには、内的な物理的状態に何らかの違いかなければならない
結論：それゆえ、心的状態に対応する内的な物理的状態に何らかの違いがなければ、心的状態が異なるということはありえない
「（民間心理学的な心的状態を帰属させることは、限定的内容のみに関わることであるという）結論は、深刻な疑義にさらされることになる。
限定的内容といっても、それを妥当な概念として了解できるかは明らかではない」
なぜなら、
「民間心理学的な内容を（物理的状態に？）帰属させることは、身体的な動きを規定するような頭の状態についての独我論的な研究から引き出すことができるような切り口とは
まったく違った切り口で現実を切り取ることであるように思われる。
その具体的理由として、
ボールをひろうことは、「そこにボールがあると私は知っている」という心的状態と関連するが、そのときの細かな指の動きはそのような心的状態と関連するものではない。
５
筆者
：広域的内容を伴うによ伴わないにせよ、
頭の中で起こっていることに関することに関する科学的カテゴリーや分類に
きちんと還元されるなどということは
とてもあり得ないように思われる。
・民間心理学は、科学的心理学と同じゲームを行ってはいないかもしれない
→
世界を記述しない信念であり、なおかつ
ある人が同じ考えを抱いているといえるような別のケースに投影可能な述語が（科学的記述の上には）存在しないことも可能
６
民間心理学の道具立て（信念と欲求という概念によって、命題的態度を帰属せさるという道具立て）を用いて、心的状態を二者が互いに帰属させあうという日常の慣習（傍点）の目的は？
：
他人の頭の内的状態を追跡しようと試みることによって、
その人の身体の動きを予測し説明するための手段
民間心理学の主要な目的
：
世界の中で活動している仲間たちの行動を、（傍点開始）我々が（傍点終わり）理解できるようにすること
（予測したい対象であり主体である）われわれの仲間たちの四つの特徴
①世界に対する感受性、すなわち感覚や生得的な原書的概念の道具立てをわれわれと共有している
②世界をわれわれと共有している
③彼らは我々自身のもっとも根本的な関心と必要の大部分を共有している
④彼らの思考の有用性は、
（我々自身の思考と同様に、）
彼らが世界の実際の有様をたどっていることと関わっており、
彼らの思考作用が、世界の実際の有様に十分適応していると我々が（進化論的な理由から）考えるような目的と関わっている
この特徴があるので、
「～したい」という欲求さえ同じであれば、
・民間心理学は、脳の状態の違い（that かなり目の粗い、行動上の違いとしては現れてこないような）に対しては、敏感に対応しないように設計されている
・民間心理学は、個人の間の差異を覆い隠し、
さらには種の間の差異さえも覆い隠してしまう（長所であっても短所ではない）
７
筆者の見解
：私の見解では、われわれが信念を帰属させるのは、
行動の全体に一種の解釈の網をかぶせることによってである。
……関連する行動を可能にするものとしての、
根底にある物理的あるいは計算論的な構造がどのようなものであれ、
そうした構造における自然な区分に、網の結び目（すなわち信念と、欲求の特定の帰属）が
対応している必要はない。
――
ということは、Davidson（全体論者）に対するFordorの批判は、筆者の意見にも当てはまるのではないか？
<Fordor>
意識の全体論というのは、
「命題的態度の同一性――特に志向的内容――が、その認知的連関の全体によって決定される」
という考え方。
これに、Fordorは懐疑的。
（命題pの認知的連関というのは、主体がpの意味論的評価、すなわちその真偽の決定に関係するすべての命題のこと）
われわれは、信念や志向的状態を共有している。が、そのとき、すべての命題（認知的連関）を共有しているとは思えない。
信念は、その内容をそれぞれ別に持つ。
：信念がその状態を獲得するのは、脳の状態が逐一、世界と因果関係を結ぶことによってである。
「ある生物が『牛』という概念を持とうと持つまいと、その生物は『馬』という概念を持ちうる」
</Fordor>
筆者
：Fordorの間違い
全体論は、もしそうであれば、人間の心の理解が芋蔓式に進んでくれるのにという、いわば願望。
Fordorが軽蔑したものの通りに進んでくれるかは別問題。
Fordor：バラバラになったブロックを一つの全体に組み合わせるやり方が、全員同じになるはずがない。
筆者：一つのブロックの組み合わせ全体を理解するために、各人が別々のやり方でバラバラにしている
全体論という言葉の使い方が違うから、Fordorの批判は筆者には当てはまらない（という、批判をかわすための節）
７
一章３節での、チャーチランドによる民間心理学批判に、今では応答できる。
（3）に対して、
民間心理学の関心事は、他の主体の顕著の行動パターンだけを可能な限り効率的に分離することである。神経科学とつながることを目的とはしていない
（1）に対して、
民間心理学の道具としての適用範囲は、仲間。狂人の理解は、そもそも目標としていない
（2）に対して、
なので、その中核部分が時間的および地理的な次元を越えて相対的に恒常的であり続けてきたことは驚くべきことではない。
整理。
民間心理学には、きちんとした定義がある。
これまで「民間心理学」として使われてきた言葉の、新たな用語法：「素朴心理学」、「メンタリズム的な理解」
８
因果関係と、構成的関係の区別
構成的関係
：
研究の主題と何らかの形で密接に結びついているということ
因果的に関係
：
因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、
それらの要素を差し引いてもそれによって思考という観念そのものが存続しえなくなる
ということはない。
（チェス盤がなくなっても、チェスの続きは打てる。石を駒に見立てたり、口頭で）
９
・消去主義的唯物論：民間心理学が、心に関する科学に対して歪んだ影響を及ぼすのではないか。民間人は自分自身の心を知らないと、消去主義的唯物論は思っている
↑
（構成的関係）
↓
心
科学と心とを結びつける構成的関係。その得難さが二つのスタンスの対立を生んでいる。が、どちらの立場も同じく、認知という地形に同じ隆起とくぼみを見ている。
では、構成的関係とは何か。
構成的関係←→因果関係
構成的関係：研究の主題（この場合は心）と、何らかの形で概念上密接に結びついていること
因果的関係：因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、それらの要素を差し引いても、それによって思考という観念そのものが存続しえなくなるというひとはない
（駒はなくてもチェスは打てる）
Permalink | トラックバック(0) | 15:30
http://www.youtube.com/watch?v=MGt25mv4-2Q
このCM動画だけど、Googleがミクを取り上げたとかで、一部で話題。だけど、僕にはこれがGoogle衰退の一歩に思える。
Googleは、ご存知の通り、ウェブサイトに配信する広告収益で非常に大きな利益を出している。これは、開発者にとって、夢のような環境をもたらした。収益部分と製品開発が分離することで、顧客の要望に煩わされることなく、収益性を考慮することなく、コンピュータサイエンスの粋を尽くせばそれでいいという環境ができた。ぶっちゃけ、広告を貼るスペースを出しておけば、何を作っても良かった。そんな単純でないけど、例えばGoogle Docsなどは、未だに広告がない。Gmailにも、昔風な広告フッタがない(作成画面にはあるけど)。こういう環境のおかげで、ユーザも開発者も誠意だけで仕事ができた。
そこで出て来たのが、先のCMだ。これはミクが世界に広まる様子を表現したものと思っていい。でも、これ、Google ChromeのCMだって知ってた? アカウントがChromeになっているの、気づいた? このCMからChromeの良いところって理解できた?
僕はわからなかった。スキンとかアプリとか出てくるのかと思ったけど、全然出てこなかった。要するに、焦点がぼけているのだ。
僕にはこれは怖い気がする。だって、Googleは、自分たちが何をしたいのか、何を売っているのか、理解してないんだぜ? 個人のお遊びならともかく、会社の名前でCM作って、何も伝えられなかったんだぜ?
ここでひとつ思考実験する。「もしGoogleが広告収益以外で利益を得る必要が出て来た時に、どうやって収益を得ることができるのか」。検索アプリを有償化するか? 無理でしょう。無料で獲得した利用者が、いくら不可欠だからって、有償化でついてくるとは思えない。一応有償アプリの販売プラットフォームになるよう努力しているけど、結局広告収益のほうが良すぎて、力が入っているとは思えない。いわゆる「イノベーションのジレンマ」というやつだ。収益の上がりすぎている事業があるために、次なる収益探しに力が入らないのだ。現にYouTubeは広告がベタベタだ。
奇跡的過ぎる例だけど、アップルはそれをやってのけた。アップルは、元の名前を「アップルコンピュータ」と言って、要するにパソコンを作る会社だった。それで一度大当たりをして、その会社として20年パソコンに力を注いだ。で、最初の10年はともかく、あとの10年でどんどんだめになった。でも、恐らくはアップルコンピュータでパソコン以外を自分たちのコア事業にしようだなんて夢想した人はいなかっただろう(Newtonとかあるのは知っているけど、結局コアにならなかった)。そこで、ジョブズがやってのけたのは、「アップルコンピュータを パソコン以外の会社にすること」だった。音楽プレーヤーを始め、今ではモバイルの先進となっている。だから、社名から「コンピュータ」を消した。
このように、Googleが、もし広告がダメになった時に、どういうことをするのか。それをGoogleは考えていないのではないか。特に日本法人。僕には、先の焦点のボケたCMが、そういうことを考えてない、ダメなGoogleの象徴に思えてならない。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
完全な初心者の状態から勉強を始めてから大体5ヶ月でウェブサービスが完成したので何を用意したり何をどうやって勉強したらいいのか色々書いてみました。
アイデアはあるんだけど、プログラムとか難しそうで自分にはウェブサービスなんて作れないと思ってる人がいたらその敷居を少しでも低くできたらいいなあなんてと思ってます。
ちなみにボクはぼんやり１年くらいはてなブックマークにのってる記事を見ていてプログラムとかできたらいいよなあなんて思っていてようやく重い腰をあげた人です。
さらに自分は文系で数学も英語もロクにできない人なので、基本的に誰でもサイトは作れると思います。
そもそも中学生でもプログラミングができるんだから大人に出来ないわけないですよね。
これからウェブサービスを作りたいっていう方の参考になればと思います。
※自分も初心者なのでまちがってることがあったら教えてください。
●何を用意すればいいのか
※自分がWindowsなので何個かWindows向けのソフトを紹介しています。
※Macの方は申し訳ないですが、Mac向けのソフトをご自分で探してください。
(1)メモ帳
アドビのdreamweaverっていう便利なソフトがあるらしいですがお金もかかるし別に必要もないと思います。
ただのメモ帳だと使いづらいのでボクは「TeraPad」っていうフリーソフトを使っています。
例えばプログラム言語ごとに表示を切り替えると、関数とかコメント部分の色が変わって見やすくなって便利です。
・TeraPad ： http://www5f.biglobe.ne.jp/t-susumu/library/tpad.html
サイトを作っても各ブラウザごとに見え方が違うのでそれぞれ確認するために何種類かブラウザをインストールしましょう。
ボクはIEとFireFoxとChromeの３つをそれぞれ表示して確認していました。
OperaとかSafariも本当は確認しないといけないと思うんですがこの3つで十分だと思います。
(3)XAMPP
ザンプって読みます。ざっくり言うとローカル環境(自分のパソコン)でプログラムを動かす環境を作るソフトです。
いちいちサーバーにアップロードしなくても、プログラムが動くかを確認できるので便利です。
またレンタルサーバーでプログラムが暴走してしまうと迷惑がかかるらしいのであらかじめ自分のパソコンで確認するのがいいようです。
・XAMPP： http://www.apachefriends.org/jp/xampp-windows.html
(4)ドメイン
何とかドットコムっていうやつです。ネット上の住所的なやつです。example.comとかexample.netとか。
ボクはお名前.comでドメインをとりました。ドメインの個人情報を隠せる？サービスがあるのが理由です。
まあどこで取っても大して変わらないと思うので目についたところで取るといいと思います。
「.com」だったら年間1000円くらいです。長すぎるドメインはとらない方がいいかもです。
(5)サーバー
ネット上にファイルをアップロードするところです。ドメインが住所だとすると土地みたいなイメージです。
ボクはさくらインターネットさんのレンタルサーバー(スタンダードプラン)を借りています。
理由はグリーの社長さんがほめてたから。お金も月額500円なので安いです。
同じ500円だとニコニコ動画のプレミアム会員になれますね。ちなみにボクは一般会員です。
さっきファイルをアップロードとかさりげなく書きましたが、そのファイルをアップロードするソフトがFTPソフトです。
ボクはFFFTPを使っています。最初使い方がわからなくて戸惑いましたが慣れれば簡単です。
・FFFTP ： http://www2.biglobe.ne.jp/~sota/
(7)FireMobileSimulator(FireFoxのアドオン)
携帯電話のサイトを確認するには基本的に実機で確認するのが一番ですが、個人で全部そろえるのは難しいです。
そこでFireFoxのアドオンのFireMobileSimulatorという拡張機能を使って簡易的に確認するのがおすすめです。
XAMPPのようなローカルサーバでも確認することができます。
・FireMobileSimulator ： http://firemobilesimulator.org/
FireMobileSimulatorで確認できるといってもやはり見え方は違います。念のため実機で確認しましょう。
ボクはiphone使っていてそれの確認はしてるんですが、androidの友達がおらんのでまだ確認してなくて実はまだ不安だったりしてます。
上と同じようにやはり実機で確認した方がいいです。特にガラケーは見え方もそうですが、プログラムがうまく動かなかったりします。
例えば、AUだけフォームに「enctype="multipart/form-data"」を入れてると文字化けするという謎の現象が起きたり。
他にも色々あって制作に時間がかかったのは正直このガラケーのせいです。色々３キャリアで統一とかしてくれないんですかねえこれ。。。
友達のY君とMさんとNさん本当にありがとうございました。匿名ブログだけど感謝してます。
●何を勉強すればいいのか。
さて具体的に何を勉強すればいいのかわからない人がいると思いますが、以下を勉強すればウェブサービスが作れます。
ということでひとつずつ説明。
マークアップ言語っていうらしいです。プログラムじゃなくてhtmlファイルを作る言語です。
とりあえずhtmlでサイトの文書の論理構造を書いて、cssでサイトの見た目をキレイにするものだと思ってください。
適当に検索すれば勉強できるサイトがたくさん出てくるのでそこで勉強してください。
本も売ってますけど基本的なところは難しくないので買う必要はないと思います。
調べると、html5とかxhtmlとかあって戸惑うかもしれませんが、とりあえずPCとスマホなら何でもいいと思います。
(ガラケーについては各キャリアごとに対応させる必要があります。書くとすごい長くなるのでガラケー用にサイトが作りたいなら調べてみてください。)
ただhtml5が一番新しいので今後勉強される人はそれの方がいいかもしれないです。
ちなみにボクはたまたま見たサイトがxhtmlの説明だったので今回はxhtmlで作りました。
まだボクは90年代初頭のホームページみたいなデザインしかできないので偉そうなことは言えないんですが(笑)
最初はhtmlだけでサイトが作れると思っていたんですが、はてなのような動的なサイトを作るときは何かしらプログラミングする必要があります。
んで、いろいろ調べるとperlやらRubyやらJAVAやら色々でてきて一体どのプログラム言語がいいのか悩むと思いますがウェブサービスが作りたいならPHPがいいと思います。
理由はウェブに特化した言語っていうのと他に比べると簡単で勉強時間が少なくて済むらしいので。
PHPなんかで本なんか買う必要はないらしいんですが、ネットのサイトだとよく理解ができなかったので本を買いました。
以下の書籍がとてもわかりやすくていいです。おすすめです。やっぱり本は体系的にまとまってるので勉強がしやすいです。
この本の通りやっていけばとりあえずプログラムが動く感覚が得られます。
あとすごい賢そうなことをやってる感覚になるので頭がよくなったような気がしますよ（笑）
MySQLもこの本で勉強ができます。MySQLというのはデータベースで、そういうソフトです。
他にもOracleとかPostgreSQLとかあるらしいですが、
とりあえずMySQLでSQL文っていうのを勉強するとデータの検索だったり、データのアップデートだったりが数行でできたりするのですごい楽になります。
決して簡単ではないですけど、思ったより難しくはなかったっていう印象です。
自分は大抵その時理解できなくてもだいたい一晩寝てから、もう一度頭からやり直すと理解できました。
(3)Apache
ボクはさくらさんのレンタルサーバーを借りていて今回はあまりいじってないんですが例えば「.htaccess」という名前のファイルを作るとapacheの設定をいじることができます。
例えばアクセスされたくないファイルがあったらそういう指定を「.htaccess」というファイルに書いておけばアクセスされないようになります。
基本的にパソコンと同じように作ればいいです。ボクは以下の本を見て勉強しました。
「iPhone+Androidスマートフォンサイト制作入門(たにぐちまこと)」
正直ネットの情報でも十分だと思いますが一度体系的に勉強するのもいいと思います。
ガラケー向けのサイトの制作は特殊で一度頭真っ白の状態で勉強した方がいいです。それだけPCとスマホとは全然違います。
ネットにも情報はたくさんありますが、断片的なものなので以下の書籍で体系的に勉強してから補助的にネットで調べた方がいいです。
この本は実践アプリケーション集というだけあってそのまま使えるコードが収録されているのがとてもいいです。
正直PHPのプログラミング自体はそこまで難しいという印象はなかったんですが、この本に出会わなかったら多分ガラケー向けのサイトは作れなかったと思います。
もしガラケー向けのサイトが作りたいならこの本を買うのが近道だと思いますよ。
CakePHPとかSymfontとかいうのがあるらしいです。
このフレームワークを使うとあらかじめある程度のところまでできてるんで、ボクみたいに全部TeraPadで手書きしなくてもいいみたいです。。。
(2)javascript
PHPはサーバーで動作するプログラム言語ですがjavascriptはブラウザ上で動作するプログラム言語です。
非同期通信なんていうよくわかんないけど何かすごいこともできたりするらしいですよ。
●もし調べまくってもわからなかったら
もし一日中検索してもよくわからなかったらそういう時はネットの頭のいい人たちに質問しましょう。
ボクは以下のサイトで質問していました。
(1)ヤフー知恵袋
巷ではヤフー知恵遅れなんて言われてますが、コンピュータ系の質問に関してはしっかり教えてくれる人がほとんどです。
ポイントを100枚くらい使うとカテゴリマスターなんていう天才が回答してくれます。
(2)２ちゃんねる
どういうスレッドなのかよく読んで質問しないとボロクソに言われますが、２ちゃんねるなのに皆さんすごい優しく教えてくれます。
たまにケンカしてたりすることもありますがそのときはケンカが終わるまで待ちましょう。ケンカの流れで質問がスルーされたりします。
ヤフー知恵袋も２ちゃんねるもそうですけど、質問するときは自分の環境をしっかり書いて何がしたいのか、どんなエラーがでるのか明確に書きましょう。
回答する人もわからないですし、自分がほしい回答がまず来ないと思います。
あと当たり前ですが回答してくれたらお礼をしっかりいいましょうね。
●こうして出来上がったウェブサービス
こうやって今回できあがったのが６人まで登録ができる招待制のレンタル掲示板です。
「ひそり-秘密共有ネットワーク」(http://hisori.com/)です。
なんだ掲示板かよー！！とか言わないでください(笑)これでもけっこうがんばったんで。。。
そういえばサイトを作ろうと思った経緯を書いてなかったんでちょろっと書いておきます。
ボクはミクシィとツイッターをやってるんですが、一瞬その時だけ仲のよかった人の更新とか見たくなかったりするんですよね。
でもマイミクを外したりフォローを外したり小心者のボクにはできなかったりするわけです。
そもそもあーいうソーシャルって自分のキャラに一貫性をもたせないといけないから窮屈なんですよね。
例えば、会社の同僚には真面目を絵を書いたようなキャラだけど学生時代の友達には下ネタ好きのどうしようもないキャラだったりすると
マイミクやフォロワーにその会社の同僚がいたら、下ネタなんか書きたくても書けないという窮屈さがソーシャルにはあるわけです。
だったらあらかじめ人数制限しておいて、例えば同じ学生時代の人しか見ることができないサイトがあれば
下ネタだって気にしないで何でも書けるよねっていう考えに至ったわけです。
今回６人までという人数制限と招待制っていう形にしているのはそういう理由と本当に仲のいい何でも話せるグループに使ってもらいたかったからです。
んで、ネットにそういうのがなさそうだったので勉強がてら自分で作っちゃえ！ってことで今回作りました。
ちなみに何で秘密共有ネットワークなのかというと「招待制無料レンタル掲示板」だとどんなサイトかイメージがつかないと思ったからです。
じゃあ何て名前にしようかと考えた結果、秘密でも何を書いても大丈夫ですという意味を込めて「秘密共有ネットワーク」って名前にしました。
とまあ、そういうことで初心者でボクみたいな完全文系の人でもこれくらいのサイトなら作れるんで
もしプログラムとか難しそうとかそういう理由でウェブサービスの制作を躊躇してる人はぜひチャレンジしてみてださい！！
※もしサイトが変な挙動がしてるとかあったら更新報告用にツイッターのアカウントを作ったんでよかったら教えてください。
http://twitter.com/#!/hisori_com/
ではでは。。。
先日、TBSの番組「夢の扉＋」を見ていた。TBSの中で視ているのはこの番組だけだが。先日のテーマは「小さな町工場から日本の製造業を支える！」というもので、職人集団「チーム等々力」の免震テーブルの開発について綴られていた。
確かに、各職人の技術はすごい。ああいう職人技が日本を縁の下の力持ちとして支えているのも事実だと思う。例えば、新幹線の先頭ノーズはあれは職人手作業じゃなかっただろうか？
違和感を感じたのは、「職人が大学教授の求めているモノを理解出来ない」という点だった。結局番組では理系大学出身の技術者が、大学教授の要求（要件定義）を職人に分かるように図面に起こした事になっている。
それでいいんだっけ？ 図面になっている物は作れるが、図面を起こす事が出来ないということだろうか？
我々IT技術者は、顧客のまだ具体的になっていない要求をヒヤリングするところから始まり、要件定義をし、設計し、実装し、テストし、納入し、運用・保守をする。だから、顧客の専門用語や技術も分からなければならないし、情報技術も分かっていなければならないし、運用・保守コストも考えなければならない。それに情報技術は進歩が早いにもかかわらず、分野によっては製品寿命が20年とかいうのもあるから、新技術だけ知っていても話にならない。
「チーム等々力」の方々は、いい製品を作るかもしれないけれど、IT業界的に言えば、コーディングだけ、という事に。否、それでも範囲が広い。コーディングは一種の「設計」でもあるから、範囲はもっと狭い。
そういえば、ITで「制作・製造」ってどの部分を指すんでしょうね。もしかして、コンパイル・リンクしている時間だけかも。なにしろ、コーディングも設計の一部であるから。
自分は、顧客の要求をヒヤリングするところから、運用・保守まで全てに関わっている。ヒヤリングしている時点でどう実装すれば良いか、どう保守するか、保守のための実装はどうするか、を考えながら顧客と接している（ここでいう実装とは、ハードウェアも含む）。
かなりゼネコン化されているので、元請けが仕事を取ってきて、こちらに仕事を発注する事になる。その時点で、かなりの情報が欠落している。元請けの方は、顧客（この場合エンドユーザー）の専門が分からないまま受注している事が多い。その上、実装を分からずに発注してくるから、かなり困る。結局、元請けに対し、かなりの懸案事項が発生する事態となる。顧客に対してこの設計では足りないとか、設計に対し実装不可能とか。それをいちいち指摘しないとならないが、これが時間がかかる。
こういう案件がたくさん来ると、今度は実装出来る人間に限界が出てくる。なので、実装するのをさらに下層の外注ソフトハウスに出すの事になるのだが、今度はこれが、エンドユーザーの事が分からないため、なんだかよく分からないブツが上がってくる。その上、金の切れ目は縁の切れ目だから、運用保守に関しては全く考慮されていないブツ。もちろん、中には優秀な外注さんもいて、すばらしいコーディングのブツが出来上がってくる事もあるが、そういう人に出会える確率は万分の一程度か。
そこへ追い打ちをかけるように、コスト低減要求と短納期要求、仕様変更。人月の神話。
顧客の頭の中を覗く人、顧客の要求を情報技術者向けに翻訳する人、翻訳されたものを実装する人、実装されたモノをテストする人、テストし終えたモノを納入・設置する人、運用・保守する人、がそれぞれ分業・連携取れていないのが、現日本のIT産業の姿です。
最近は自社の社員も質が下がってきていて、Windowsしかいじれないとか、統合開発環境内でしかブツが作れないとか、コンピュータがどう動いているかイメージ出来ないとか、果ては、顧客の専門用語が分からない、というのもいる。ソフトハウスに至っては、作ったはいいが、作ったモノに対してデバッグ出来ないとか言い出す始末。
というわけで、就活生には、ITはお勧めしない。もし、プログラミングだけしていたいというのであれば、メーカーではなく、小さなソフトハウスに就職した方が良い。でなければ、顧客と対等（同等）の（製品）知識と、新旧情報技術に対応出来るだけの能力が必要とされるのである。
超氷河期だそうです。（これも就活ビジネスの煽り文句な気もしますが）
いや、でもまあ、確かにそうなんでしょう。周りも非正規が多いです。
「何がリーマン崩壊だよ！リーマンになれねーじゃん！」とか笑えないけど笑ってた気がします。
あのタイミングでこれはねーよ、と。
なにせFランクラス（ちょっと言い過ぎ？）の大学（校）だったので。
好きでやってたITだったので資格を取っておいたのだけが救いでした（応用情報技術者試験）
まあ、でも、終わってみればという感じです。
7、8社ほどで内定をいただきました。
ニュースでやってる、100社落ちたとかってのは余程訳があるのかなぁとか、考えたりしたもんです。
就活（笑）解禁だそうなのでメモ程度に経験を残しておこうと思います。ただ、人によっては全く参考にならない気も（笑）
1.中小のみ狙う。
1社だけ入りたかったウェブ関連の会社があったのですが（まぁ、中小ですが）、イミフな試験で落ちました。（愛と恋の違いだの何だのを書けとか書いてありましたね）
地方住まい、通勤圏内を求めていたのですが、県内にいい会社が見当たらなかったので高速で通える県外にしました。
本当は東京にでも出て、やりたい仕事をやっても良かったのですがやめました（理由は後述）
とにかく合同企業説明会（笑）でも人がいないところを狙います。
地方なんかだと地域でやってるUターン誘致の説明会とかジョブカフェのやってる説明会が狙い目です。
むしろリクなんちゃらとか、今話題のマイなんちゃらとかのは行かなくていいです。時間の無駄です。
2.話の合う人事の年齢を見つける
僕は年寄りに話を合わせるのが得意なので、年寄り人事がいる会社をさらに集中して狙いました。
若い人と話すのが得意なら若い人を狙えばいいと思います。
人気の無い企業の人事はとにかく暇なのでガンガンしゃべります。
話を聞いてくれるだけで嬉しいようです。（彼らだって暇なんだから当たり前っちゃ当たり前ですが）
3.乱発しすぎない
僕も焦っていろんな会社を手当たり次第に受けたことがありますが（最初の３社くらい）、あれはやめたほうがいいです。
時間もお金も有限です。企業をリスト化して優先順位（行きたい順だけじゃなくて入れそうなことも加味して）をつけて狙っていったほうが良いです。
4.自分を捨てる
よく言われているように、企業は技術や個性なんて求めちゃいません。
僕はある中堅ITの子会社で「僕はコンピュータが大好きです」といった直後に
「この仕事は、極端に言えばコンピュータがなくてもいい仕事だと思っています」とかなんとか言いました。（あほらしい話です）
SIerは技術者を軽視しているのが隅々まで行き渡っているのでこれであっさり受かります。（当然、蹴りましたが...）
自分の本当の考えなんて大して必要ありません。
5.なんだかんだで資格
学校名で「は？（笑）」みたいな感じでも「応用情報技術者試験受かりました（キリッ）」とかやっとけば覚えてもらえます。
中小企業だと「とりあえず一人はコイツでいいか」的な空気が会場一杯に広がります。
以上５点に気をつけると不本意な気分満点ですが、とりあえず内定しますよ。やってみてくださいね〜。
（以下蛇足）
此処から先は独り言。
僕は情報処理技術が大好きです。高校時代は文系で、心理学に興味があったのに、いつの間にか....。
実は大学（校）に入った理由は学費が安いということが一番で、ついでに興味のあるパソコンを、という気持ちだったのですが...。
大学時代は僕の人生で一番（一番は社会に出てからの今かもしれませんが）勉強した時期です。
あれほど熱中するものがなかった自分がここまでのめり込むとは思いませんでした。
OS、コンパイラ、画像処理、組み込み、データベース、ネットワーク。
何でもやりました。学校もなんだかんだで多くを学べる所でした。
実を言えば東京のベンチャーみたいな会社に憧れたりしたのです。
最先端で戦ってみたいという気持ちが今でもあります。（今はVBでサビ残して詐欺みたいなモノ作ってますからね）
ただ、長年付き合った恋人や、家族なんかのことも考え、今は地方にいます。「今は」
僕は三年は勉強期間だと思っています。社会のルールも知らないのですから。
もし、中小は嫌だとか不安だと思うのなら、こう考えてはいかがでしょうか？（あれ、独り言じゃない）
「三年間の職業訓練」
会社や社会人の方に怒られそうですね。3〜5年でやめられると中小には痛いそうですし。
でもまあ、雇った方も自己責任だし、ね。（こういう内容だと自分のブログに書けないから増田はいいと思う）
３年経てばテレワーク事情ももうちょいマシかも（さすがに無理？）
だめならこのまま人生を切り売りするか、バイト時代好きだった小売にでも転職しようかな、と考えたり。
（正直同じハードさなら小売のほうが楽しい。この業界PGはいてもプログラマいないし。OSS開発もできるからね）
だから、３年間だけ。
とりあえず昨日アマゾンから補充された、机の上に積み上げられた本を読まねば....。とりあえずトランザクション処理からにするか...。鈍器だろこれ
ウィキペディアのプログラマ、ブランドン・ハリスからのお願いをお読みください
ブランドン・ハリス (Brandon Harris, 1973-) はウィキメディア財団のシニアデザイナー。2010年からウィキペディアのユーザーインターフェイスの改良に携わる。ウィキメディア財団に入る以前には、 コンピュータエンタテイメント産業の Electronic Arts 社 に所属。独立プログラマとしては、ブラウザベースの MMOである Nexus War を単独で開発・運営した[1]。
ウィキメディア財団での主な仕事は、新規編集者獲得を目的とした一連のMediaWikiプラグイン開発、モバイル機器に焦点を当てた新しいウィキペディア用スキンの設計など[2]。
個人で開発運営した Nexus War は設備維持の費用がかさんだため2009年に閉鎖を余儀なくされたが、現在、有志によって後継ゲーム Nexus Clash [3]が運営されている。
幼少期からヘビーメタルを愛好しており、少なくとも10歳の時点でクワイエット・ライオットのMetal Healthがお気に入りだったという[4]。現在でもスレイヤー、ブラック・サバス、メタリカなどを好んで聴く[5]。
ウィキペディアなどのウィキメディアウィキ[2]やTwitter[6]、IRCでのハンドルネームは Jorm 。 北欧神話に登場する蛇、ヨルムンガンドにちなんで名づけたもの[7]。
基幹システム作ってるところなんてのは昔からある会社で、勤務条件もわりと整ってて(年配者が多すぎるから新入社員は安月給になりやすいが)、そういうところは昔から理系を取る習性がある。大昔は理学部しかコンピュータを扱えなかったという経緯があるから。
対して、すぐに起業できるような業界てのはブラックが多い。だから、すぐに起業しやすいゲーム系やWEB系はブラック率が高くなる。人が寄り付かないから給料も上げるようにもなる。
もちろん、文系理系の割合やブラックかどうかも役員次第なんだが。
おおもとの増田が投稿してるように、未経験でもOKということは誰も行きたがらない会社だった、つまりブラックで有名な会社だったということ。きちんとした会社に行ければ、んな確率も少なくなる。
業界替えたい、給料多く欲しい、体力ある、て奴はブラックでもいいんじゃないの？要は、そこで何を得て次にどうステップアップするかでしょ。
一般論として、仕事てのは何かと引き換えに給料貰ってるわけなんだから、才能がある人以外、全て美味しい所取りてのは都合よすぎると自分は思うけどね。
俺は、物心ついた頃から家にコンピュータがあり、MS-DOSも、Windows 3.1も、PC-9801も触ってた。小学校時代には市内にプロバイダーが一個しかない頃からダイヤルアップ28.8kbpsでインターネットしてたし（時代はテレホーダイ）、中学時代にはWeb制作やプログラミングを覚えてた。高校時代には自作プログラムを配布したりしてたし、大学時代には代行制作でお金もらったりもしていて、今はIT企業に勤めて2年目になる。つまり何が言いたいかと言うと、俺は昔からインドアの陰キャラの陰毛野郎で、コンピュータが友達みたいな奴だった。余暇のほとんどをコンピュータと共に過ごしたし、それはそれで楽しかった。
でもそのせいで、他のみんなが興味を持つことに対して興味を失ってしまった。テレビみないし、基礎体力づくりができてないからダイビングとかスノボとか誘われても行きたくないし、みんなでスマブラやろってなっても俺だけ弱い。俺がコンピュータに向き合っていた時間と同じだけ、他のみんなはテレビを見て話題づくりをしていたし、サッカーとかして基礎体力づくりをしていたし、スマブラの練習をしていた。対して俺は、人間ではなくコンピュータを友達に選んでいたのだ。この結論に達したとき、なんともいえぬ空虚感にさいなまれた。俺は、人と違うことを選んでしまったがために、人が楽しめることを楽しめない人間なんだ、と思いながら生きてきた。
先日、大学時代の友人の結婚披露宴に招待されて行ってきた。余興を頼まれていたので、得意のコンピュータを活かしてビデオレターを作って流してプレゼントした。披露宴と二次会の様子を趣味のデジイチで撮った写真を製本してプレゼントした。参加者に向けて写真とビデオをまとめて思い出サイトも作った。そしたら、ものすごく喜んでもらえた。あ、こんなにも喜んでもらえるんやったら、今まで俺がしてきた時間の使い方、一概に間違いと決めつけるのも良くないのかもな、と思った。生きてたら何かしら経験してるはずで、経験値を得てるんよな。できないことがあっても、できることがあったらええやんな。さ、今週もがんばって働こー！
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
何故これがわざわざ分かれているのか意味不明。各カテゴリからのホッテントリが集積したもの。
新聞の三面記事から国際記事、文化記事まで扱っている場合もあり。また2chまとめサイトが数多く見られノイズ化。
一般的な政治ニュースや国際政治ニュースから企業不祥事、ビジネス、仕事関連のTipsまで。ここも2chまとめによるノイズ多し。
いわゆる生活の知恵的な間違った意味でのライフハック、まとめになっていないまとめ記事、VIPの告白スレや発言小町、Pouchなどのネタ記事など雑多な状態。
ここはほぼカテゴリ名通り
いわゆる自然科学関連ばかりで、人文科学・社会科学(現状何故か「社会」で扱われる傾向)、芸術関連がない。
技術系、デジタルガジェット系、ネットコミュニティ、炎上見物などが混在。
ここはほぼカテゴリ名通り。
はてブ一番の問題。ほとんどが2chまとめサイト。しかも同じ話題を複数のサイトで扱っていて、ほとんどワンパターン化している。他にエロサイト、ネタ系ネットニュース、Togetterなど。SPAMも多く見られる。
はてなブックマークニュースに統合。各カテゴリのホッテントリ抽出ではなく、人力編集。
「グルメ」「衣食住」「人生」「ライフハック」に分割。ここで言うライフハックは本来の意味とは違うけど敢えて（ある意味隔離？）。
「スポーツ芸能」と「芸術文化」に再編。芸術文化では音楽や読書などを扱う。
「医療」「自然科学」「人文科学・社会科学」に再編。人文科学・社会科学では経済学・社会学・政治学・歴史などを扱う。
「IT・WEB技術」「デジタルガジェット・モバイル」「ネットウォッチ（事実上の隔離）」の再編。
そのまま
「おもしろ」「2chまとめ」「画像」「R-18」に。一部は「ネットウォッチ」に。R-18は生年月日によってフィルタリング。
というか、この古いカテゴリ分けで一体何年やってるんだろうか。他のCGMサイトなんかカテゴリ再編を割りと時代に合わせてやってるのに。
"ハッカー集団"アノニマスが、メキシコの麻薬組織につかまっていた仲間を無事奪還した、というニュースを読んだ。
"ハッカー集団"という称号から、アウトロー的な、コンピューターのハッキングを行う犯罪者の集団をイメージするけれども、アノニマスはそんなにかっこいい存在じゃないらしい。
日本の「ふたば☆ちゃんねる」と「２ちゃんねる」をモデルに作られた「4chan」に集まる暇人が自然発生的に集まってできた集団で、要は日本のVIPPERらと同じようなものだ。
しかし、今回の彼らの実行力には、脱帽した。
それにしても、日本のVIPPERや鬼女さんやはてなーと比べると、彼らには機動力・戦闘力があり、目的実現のための能力が高く、行動に一貫性があるのが羨ましい。
くらべて日本のVIPPERなどには、なぜそういう凄みがないのか……いや、凄みがないのが悪いわけじゃないけれども、彼らと同じくらいの実力がVIPPERらにはあるはずなのに、いささかアノニマスに見劣りするのが、日本人として悔しい。
余計なお世話かもしれないが、日本のネット集団が、アノニマスに負けないくらい力を発揮するための方法を考えてみた。
彼らには「アノニマス」という共通の名前で、サイエントロジーやソニーと戦ってきた歴史がある。
それに比べて日本では、VIPPERとか鬼女とかに細分化されていて、それらをくくる名前がない。
4chanの「Anonymous（アノニマス）」に当たるのは「名無しさん」だけど、これは、名前として微妙だ。
VIPPER、鬼女、はてなーの機動隊をまとめる、もっとかっこいい名前はないか？
ちなみに「匿名旅団」という名前を考えてみたんだけど、どうだろう？
2chanではお馴染みの人気作家の富樫作品の中の「幻影旅団」をイメージしている。
生存の優先順位が、原則、団員ではなく旅団そのもので、メンバー全員が戦闘狂、なんて幻影旅団の特性が匿名旅団にあってもいい。
VIPPERや鬼女さんのような、ネットでゆるく結び合った人間集団の名称としては、悪くないんじゃないか。
VIPPERや鬼女は、これまで、犯罪行為をネットで自慢したバカの会社に電凸を行ったり、個人情報を晒したりして、一定の成果を上げてきた。
しかし、花王やフジテレビ、電通のような巨大企業を相手では、力不足じゃないのか？
具体的な成果が挙げられないまま、ネットの話題はTPPへと移ろうとしている。
たぶん、これからもフジテレビや電通は、韓国から金をもらい、韓国に偏った、事実と異なる報道を続けるのだろう。
せいぜい潰せるのは個人程度で、企業が相手ではなんの痛痒も与えられないなんて、なんて無力なんだろう。
「敗北の味が知りたい」
なんてうそぶいていたって、結局それが実力だ。
ソニーに何百億という損害を与えたり、中近東の革命の際に政府機関のコンピュータに侵入したりと、アノニマスに機動力があるのは、「表現の自由」という共通の理想があるから。
人間ってのは、衣食のためだけでは実力以上の力を出せないもの。
現実以上の“理想”を実現しようとした時に、異常な実力を発揮できるもので、そのための「錦の御旗」が必要だ。
昔、堀田善衛という作家が「長い未来についての理想をもたぬものは、それをもつものの未来像のなかに編入されて行く」と書いていた。
理想という共通の目標がなければ、実行力を発揮しようにも、矛先はあちらに向いたりこちらに向いたり、散漫となり、結局何も成し遂げられないままに終わってしまう。
かといって、アノニマスと同じように「表現の自由」を理想として掲げるのも芸がないし、たぶん、誰も賛同しない。
理想は外から与えられるものではなく、自然発生的な、VIPPERや鬼女やはてなーたちの行動に共通して見いだせるものでなくては、たぶん共感は得られない。
あると思うのだ。
たとえば嫌韓。
韓国人だから嫌い、という人種差別的思想を持った人々は、２ちゃんねるには案外少ないと思う。
そうじゃなくて、韓国人の「歴史の捏造」や「自己中心的な態度」、「道徳や法律に反していても、反省せずに開き直る行動」に嫌悪感を感じる人々が多いのではないか。
そして、嫌韓に限らず、これまで炎上の対象となったものには、日本の匿名旅団の中の人々が抱える、共通の価値観に反するものへの嫌悪感があると思うのだ。
そういう価値観を、絞り込んで、改めて理想・信条とできれば、たぶん匿名旅団の戦闘力は上がる。
（内容は別の人に任せた！」）
アノニマスは「ガイ・フォークス」の仮面をかぶって、団結力を高めている。
やる夫の仮面をかぶるのもいいけど、他にあったらいいなと、ここも他人任せ。
……と、以上、思いつくままにダラダラと列挙してみた。
A Sister’s Eulogy for Steve Jobs
貧しかったので、そして父はシリアからの移民だと教えられていたので、
父については、オマル・シャリフのような人ではないかと想像していました。
裕福な人であればいいなと、いつか私たちの（いまだに家具も揃っていない）家に迎えに来てくれればいいなと思っていました。
のちに面会したとき、私は、父は理想に燃える革命家で、アラブの新世界を導く人だったのだと、
だから転送先を残さずに住所を変えてしまったのだと思い込もうとしました。
私はフェミニストでありながら、自分が愛せる、自分を愛してくれる人を長いあいだ探していました。
二十数年間、父がその人なのだろうと思っていました。
25歳になってその人に出会いました。
それが兄でした。
他の作家志望者3人と一緒に、クローゼット並の大きさの事務所で小さな雑誌の仕事をしていました。
その弁護士は、上司に健康保険をねだるような、カリフォルニアの中流階級の娘である私に、
「裕福で、著名で、あなたのお兄さんである人物の代理人だ」と名乗りました。
同僚編集者たちは騒然となりました。
それでも私は大好きなディケンズの小説の筋書きに放り込まれたようでした。
弁護士は兄の名を伝えるのを拒み、同僚たちは賭けを始めました。
一番人気の候補は、ジョン・トラボルタ。
私が密かに期待していたのはヘンリー・ジェイムズの後継者、
何の苦もなく優れた作品を生み出す、自分より才能のある作家でした。
初めて会ったとき、スティーブは私と同じ年格好で、ジーンズを履いていました。
オマル・シャリフよりもハンサムな、アラブかユダヤの顔立ちでした。
偶然にも二人ともそうするのが好きでした。
何を話したのかはあまり覚えていませんが、
とにかく友達にしようと思えるような人だと感じたのは覚えています。
私はまだオリヴェッティのタイプライターを使っていましたから。
コンピュータを一台、初めて買おうかと思っているとスティーブに言いました。
Cromemcoという名前でした。
彼は、恐ろしく美しいものを作ろうとしていると言いました。
これから、スティーブから学んだことをいくつかお伝えしたいと思います。
彼の充実した人生。
彼の病気。
彼の死。
彼は頑張って働きました。
毎日働きました。
彼は散漫の対極のような人でした。
彼は、たとえ失敗に終わるとしても、頑張ることを恥とはしませんでした。
スティーブのように聡明な人が挑戦を恥じないのであれば、私も恥じる必要はないのかもしれません。
彼はシリコンバレーの指導者500人が現職大統領を迎えるディナーのことを話してくれました。
彼は傷つきましたが、 NeXT に行って働きました。毎日働きました。
スティーブにとって最高の価値は、新規性ではなく、美しさでした。
彼は流行や小道具を好みませんでした。
自分と同世代の人が好きでした。
「ファッションとは、美しく見えるがのちに醜くなるもの。芸術とは、最初醜く見えるがのちに美しくなるもの」
スティーブはいつも、のちに美しくなるようにしようとしていました。
彼は誤解を受けるのを恐れませんでした。
パーティに招かれなかった彼は、三台目か四台目の同じ黒いスポーツカーで NeXT に通い、
あるプラットフォームを、チームとともに静かに作っていました。
それは、ティム・バーナーズ・リーがのちに、
ワールドワイドウェブを動かすプログラムのために使われることになるものでした。
愛について話す時間の長さにかけては、スティーブは女の子並でした。
愛は彼にとってこの上ない美徳であり、最高の神でした。
「独身なのか？ うちの妹とディナーはどうだい？」と声をかけました。
彼がローリンと出会った日にかけてきた電話を、今でも思い出します。
「こんなに美しくて、頭がよくて、こんな犬を飼っている人なんだけど、結婚するつもりだよ」
リードが生まれて以来、彼は止まることなく家族に愛情を注ぎ続けました。
彼はどの子にとっても実の父親でした。
リサの彼氏と、エリンの旅行と、スカートの長さと、イヴの愛馬についてやきもきしていました。
リードの卒業パーティに出席した人はみな、リードとスティーブのゆっくりとしたダンスを忘れられないでしょう。
ローリンに対する変わることのない愛が彼を生き延びさせました。
私は今も、そのことを学ぼうとしています。
彼はそのことで孤独を感じていました。
私が知るかぎり、彼の選択のほとんどは自分のまわりに巡らされた壁を壊すためのものでした。
ロスアルトスから来た中流の男が、ニュージャージーから来た中流の女に恋をする。
二人にとって、リサとリードとエリンとイヴを普通の子供として育てることは重要でした。
スティーブとローリンが一緒になったことが分かってから何年間ものあいだ、
夕食は芝生で食べていましたし、食事が野菜一種類だけだったこともありました。
一種類の野菜をたくさん。
一種類だけです。
旬の野菜。
簡単な調理。
若き億万長者でありながら、スティーブはいつも私を迎えに空港まで来てくれました。
ジーンズを履いて待っていてくれました。
「お父さんは会議中ですが、お呼びしたほうがいいですか？」と答えてくれました。
リードが毎年ハロウィンに魔女のかっこうをしたがったときには、
何年もかかりました。
同じころ建設されていた Pixar のビルはその半分の時間で完成しました。
パロアルトの家の中はどこもそんなかんじでした。
ただし、これが重要なところなのですが、その家は最初の時点ですばらしい家でした。
彼が成功を満喫しなかったというわけではありません。
何桁分か控えめではありましたが、十分満喫していていました。
その店で最高の自転車が買えるんだと自覚するのが大好きだと話していました。
そして実際、買いました。
スティーブは学びつづけるのが好きでした。
彼はある日、育ち方が違っていれば自分は数学者になっていたかもしれない、と言いました。
彼は大学について尊敬を込めて語り、スタンフォードのキャンパスを歩くのが好きでした。
最後の数年間、彼はマーク・ロスコの絵画の本を研究していました。
未来のAppleのキャンパスの壁に何があれば皆を刺激できるだろうと考えていました。
スティーブは物好きなところがありました。
イギリスと中国のバラの栽培の歴史を知り、デビッド・オースティンにお気に入りのバラがあるCEOが他にいるでしょうか？
彼はいくつものポケットにいっぱいのサプライズを持っていました。
たとえ二十年間人並み外れて近しく寄り添ったあとであっても、
きっとローリンにはこれから発見するものがあるだろうと思います。
彼が愛した歌、彼が切り抜いたポエム。
彼とは一日おきくらいに話をしていたのですが、
ニューヨークタイムズを開いて会社の特許の特集をみたとき、
こんなによくできた階段のスケッチがあったのかと驚きうれしくなりました。
四人の子と、妻と、私たちみなに囲まれて、スティーブは楽しい人生を送りました。
そしてスティーブが病気になり、私たちは彼の人生が狭い場所に圧縮されていくのを見ました。
彼は京都で手打ちそばを見つけました。
もうできませんでした。
最後には、日々の喜び、たとえばおいしい桃ですら、彼を楽しませることはできませんでした。
多くのものが失われてもなお、多くのものが残っているということでした。
兄が椅子を使って、ふたたび歩けるようになるための練習をしていたことを思い出します。
彼は肝臓移植をしたあと、一日一度、椅子の背に手を乗せ、支えにするには細すぎる足を使って立ち上がりました。
メンフィス病院の廊下で、椅子を押してナースステーションまで行って、
そこで座って一休みして、
引き返してまた歩きました。
ローリンはひざまづいて彼の目を覗きました。
彼は目を見開いて、唇を引き締めました。
彼は挑戦しました。
いつもいつも挑戦しました。
その試みの中心には愛がありました。
彼はとても直情的な人でした。
その恐ろしい時節、私は、スティーブが自分のために痛みをこらえていたのではないことを知りました。
家族を連れて世界を回り、退職したときにローリンと乗るために造っていた船の進水式。
病気になっても、彼の好み、彼の決意、彼の判断力はそのままでした。
看護婦67人を試し、優しい心があり全幅の信頼をおけると分かった三人をそばにおきました。
スティーブが慢性の肺炎を悪化させたとき、医師はすべてを、氷をも禁じました。
スティーブは普段割り込んだり自分の名前にものを言わせたりすることを嫌っていましたが、
このときだけは、少し特別な扱いをしてほしいと言いました。
「これが特別治療だよ」と私は伝えました。
彼は私のほうを向いて、「もう少し特別にしてほしい」と言いました。
挿管されて喋ることができなかったとき、彼はメモ帳を頼みました。
そしてiPadを病院のベッドに備え付けるための装置のスケッチを描きました。
妻が部屋に入って来るたび、笑みが戻るのが分かりました。
こちらを見上げて、お願いだから、と。
彼が言いたかったのは、医師の禁を破って氷を持ってきてほしいということでした。
私たちは自分が何年生きられるか知りません。
彼はプロジェクトを立ち上げ、それを完了させるようAppleにいる同僚に約束させました。
オランダの造船業者は、豪華なステンレス製の竜骨を組み、板を張るのを待っていました。
私の結婚式でそうしてくれたように、彼女たちと並んで花道に立ちたかったことでしょう。
物語の途中で。
たくさんの物語の途中で。
ガン宣告のあと何年も生きた人についてこう言うのは正しくないかもしれませんが、
スティーブの死は私たちにとって突然でした。
二人の兄弟の死から私が学んだのは、決め手はその人のあり方だということでした。
どんな生き方をしたかが、どんな死に方をするかを決めるのです。
火曜日の朝、彼はパロアルトに早く来てほしいと電話をかけてきました。
声には熱と愛情がこもっていました。
同時に、それは動き出した乗り物に荷物が引っかかってしまったかのようでした。
申し訳なさそうに、本当に申し訳なさそうに、
私たちをおいて旅に出つつあるときのようでした。
「待って。行きます。空港にタクシーで行くから。きっと着くから」
「間に合わないかもしれないから、今のうちに言っておきたいんだ」
視線をそらすことができないかのように、子供たちの目を覗き込んでいました。
昼2時まで、彼の妻は彼を支えてAppleの人と話させることができました。
そのあと、彼はもう起きていられないということがはっきりしました。
呼吸が変わりました。
つらそうに、やっとの思いで息をしていました。
彼がまた歩みを数え、より遠くへ進もうとしているのが分かりました。
これが私が学んだことです。
死がスティーブに訪れたのではありません。
彼が死を成し遂げたのです。
彼はさよならを言い、すまないと言いました。
約束したように一緒に年をとることができなくて、本当にすまない、と。
そして、もっと良い場所へ行くんだと言いました。
フィッシャー医師はその夜を越せるかどうかは五分五分だと言いました。
彼はその夜を越しました。
ローリンはベッドの横に寄り添って、息が長く途切れるたびに彼を引き寄せました。
彼女と私が互いに目を交わすと、彼は深く吐き、息が戻りました。
やらなければならないことでした。
その呼吸は困難な旅路、急峻な山道を思わせました。
山を登っているようでした。
その意志、その使命感、その強さと同時に、
美術家として理想を信じ、のちの美しさを信じる心がありました。
その数時間前に出た言葉が、スティーブの最期の言葉になりました。
船出の前、
彼は妹のパティを見て、
そして皆の肩の向こうを見ました。