訳注：以下は Hacker School User’s Manual (July 25th, 2014) の日本語訳です。Hacker School の許諾を得てここに公開しています。他の利用については Hacker School におたずねください。CC-BY-SA は適用されません。 This is a translation of Hacker School User’s Manual (July 25th, 2014), published with permission of Hacker School. For any other uses of the text, please ask them. It’s NOT under CC-BY-SA.

この文書について

本取扱説明書は入学を許可された Hacker Schooler たちが Hacker School を知り理解するための文書です。外部の人たちにも Hacker School の概観をつかんでもらえるよう、私たちはこの文書を公開することにしました。このようにした動機についてより詳しくはブログに書いてあります。

1. 普通でない実験へようこそ
2. 環境
3. 優れた Hacker Schooler の振る舞い
4. 助言
5. ペア・プログラミング
6. ここに書くべきかどうか議論のあったやっかいな項目
7. 困難と精神の健康
8. 就職、求人、資金の出どころ
9. ゲスト
10. Other resources ¹
11. Contact information ²
12. Hacker School の沿革
13. 翻訳
14. ChangeLog

普通でない実験へようこそ

Hacker School は他のどの場所とも違います。この説明書は、皆さんがここになじみ、最高の成果を発揮するための手助けとして設計されました。

Hacker School の特徴的な点のひとつに、ほぼ自律的であることが挙げられます。在学中にあなたがやるべきこと、学ぶべきことなどを指示する人はいないということです（ただし対人関係ルールはいくつかあります）。自律性は Hacker School の核に刻みこまれています。このため、Hacker School には成績も試験もカリキュラムも授業すらもありません。これは、興味あるものを探す自由を与えられたとき人はもっともよく学べるという信念から来ています。

Hacker School には何も中身がないというわけではありません。ファシリテータ³がいて、どのバッチ⁴のどの人も、よりよく学べるよう助けてくれます。2011年夏からつづいているこれまでの Hacker School の運営のなかで、どういった戦略がどういった人にうまく働くかを私たちは学びました。

ファシリテータにくわえて、同じバッチに参加している他のひとたちも助けになります。Hacker Schooler たちの経歴は非常に多彩です。プログラミングをはじめてから数ヶ月しかたっていないという人も来ています。それは、Python を学びながらプログラミングの考えかたの基本をつかもうとしているような人かもしれません。いっぽう、Hacker School にはプログラミング職の経験が数年以上ある人も来ています。それは、コンピュータ科学の学士号をもっていて、自分がはじめたものの十分な時間をとれずにいたオープンソースのプロジェクトにのめりこみたいと思っている人かもしれません。

落ち着いて！

経験の量に関係なく、あなたは今回のバッチにプラスの影響をあたえるであろうと判断できたため、入学を許可されました。Hacker School での活動はあなたをプログラマとして飛躍的に成長させてくれるはずです。このことはとても重要なので、繰り返しておきます：ここにいる人はみな、私たちがいてほしいと考えたから、ここにいます。これを読んでいるのなら⁵、同じバッチにいる他の人の知識が自分より多いとか少ないとかいうことを気にするのはやめてください。私たちがここにいてほしいと思ったから、私たちが信じられるような人だったから、みなさんはここにいるのです。

環境

Hacker School が他とちがうもうひとつの点は、あたえられる集中の程度です。たったひとつのことに集中でき割り込みの入るらない時間をこれだけ大きくとれることはあまりありません。仕事でも、ほとんどの人は複数の任務と優先事項にとりくまなければなりません。

理想的には、 Hacker School ではそうはなりません。成長のみちすじにある障害物をできるだけとりのぞくことが私たちの目標のひとつです。よりよいプログラマになるために3ヶ月の期間をあたえることは、その大きな一部です。

（いくつかバッチで見られた面白い現象があります。Hacker School には対人関係ハックという側面もかなりあるようです。数か月プログラミングをするためだけに仕事を辞めてしまう人は、いるかもしれませんが、おかしな人だとみなされることが多いでしょう。Hacker School に行くことは、3か月間家でじっとしていることよりもずっと社会的によく受け入れられるようです。もちろん、あなたが友人や家族から「最近一体何をしているの」と聞かれたとき楽に答えられるというだけではないメリットを Hacker School は提供できているつもりではありますが。）

恐怖

私たちが取り除こうとするもうひとつの壁は恐怖です。恐怖は教育にとってもっとも悪質な妨害だと私たちは考えています。世界のほとんど、特に学校と仕事で、人はバカに見えるのを恐れます。この恐怖はしばしば、「これはどういう仕組みなの？」あるいは単に「なぜ？」という大切な質問をすることから私たちを遠ざけてしまいます。それだけでなく、「分からない」と言うことからも遠ざけてしまいます。これにより、多くの人は、核となる概念を中途半端に、もしくは全く取り違えて理解し、混乱してしまいます。プログラミングでは特に有害です。こうした誤解は組み合わさっていき、時間が経つにつれ、それを認め対処するのがどんどん難しく、恥ずかしくなるからです。

インポスター症候群

次のような現象がよく知られているのはごぞんじですか？ 非常に有能な人物が、自分は詐欺師であり、勝ち得たものにふさわしくない、と感じることがあります。仕事でも（「あの面接に受かったなんて。きっと無能さがバレてすぐに首にされちゃう」）、学校でも（「まわりはみな自分より頭がいい学生ばかりだ。自分は運で受かっただけだ」）、よくみられます。こういった現象をインポスター症候群といいます。

このため、Hacker School では「知らない」「分からない」といった言葉はポジティブに捉えられます。それは、あなたが新しいことを学び、他の人が助けに入る（あるいはその逆をする）きっかけなのです。

対人関係ルール

学習への障害をなくすためのもうひとつの手立ては、わずかな対人関係ルールをもうけることです。ルールは軽量指向で、通常明文化されない社会規範を明文化するものです。ここにあるルールの大半は「わがままにならない」「嫌がられることをしない」ということに行き着きます。もちろん、わざと無神経になったり嫌がられることをしたりする人はほとんどいませんから、わがままになるなと命じるのは生産的な戦略ではありません。そこで私たちは、生産的で楽しい学習環境をおびやかすと考えられる特定の振舞いを制限するために、以下の対人関係ルールをつくりました。

驚く振りをしない

1番目のルールは、誰かが何かを知らなかったとき、驚く振りをしてはいけないということです。これは技術的なこと（「え？！ スタックも知らないなんて嘘でしょ！」）にも、技術的でないこと（「RMSが誰かも知らないの？！」）にも当てはまります。驚く振りをすることは人間関係にも教育にも全く益がありません。人が驚く振りをするのは、自分の気分を良くし相手の気分を悪くするためであることがよくあります。そのように意図していなかったとしても、そのような効果をもたらすことが常です。おそらく予想がつくでしょうが、このルールは、「知らない」「分からない」をためらわせないことが重要だという私たちの信念と強く結びついています。

「正確には症候群」禁止

「正確には症候群」(well-actually) とは、誰かがほとんど正しい―ただし完全に正しくはない―ことを言ったとき、「あーそれは、正確に言うなら……」と言って細かい訂正をすることです。こういった訂正は、それが会話の実質に関係なかったとき、特に不愉快です。Hacker School は真理を求める場所ではない、厳密性を気にしない、というわけではありません。私たちの経験上、「正確には症候群」のほとんどは誇示行動であり、真理の探求ではないのです。（これを「well-actually」と命名してくれたのは Miguel de Icaza です。）

横から指図をしない

他の人たちが一緒になって問題に取り組んでいるのが聞こえたとき、遠くから散発的にアドバイスを投げてはいけません。「船頭多くして」の状況になりかねないことも理由のひとつですが、より重要なのは、会話に中途半端に参加するのは失礼であり撹乱になるからです。助けを差し伸べたり、助言をしたり、会話に参加したりするのが悪いというわけではありません。どれも奨励されます。ただ、人を助けたかったり人と一緒に取り組もうとするなら、散発的に横槍を入れるのでなく、全面的に身を入れるべきなのです。

差別のほのめかしをしない

対人関係ルールの最後は性差別、人種差別、同性愛嫌悪、トランスジェンダー嫌悪、その他偏見等につながるほのめかしの禁止です。このルールはほかのルールとちがい、特定の具体的なパターンではなくある種類の振る舞いに関するものです。

一定の種類の人への差別のほのめかしを Hacker School で見たら、その発言をした人にそのことを公開または非公開の場で伝えること、あるいはファカルティ⁶に指摘を頼むことができます。そのあとは、議論の続きがあれば公開の場を使わずにするようお願いしています。あなたが第三者であり、その発言の何が偏見にあたるか分からなかったときは、遠慮なくファカルティに聞いてください。「X という発言は同性愛差別じゃない！」と言うのはやめてください。同様に、誤ちをおかした人に追い討ちをかけるのもやめてください。「差別のほのめかしをしない」の「ほのめかし」は、その発言のどこが悪かったのかだれにでも明白であるとはかぎらないということを意味しています。

私たちは Hacker School ができるかぎり不寛容のすくない場所であるようにしたいと思っています。ですから、性差別、人種差別を Hacker School のそとで見たとき、それを持ち込まないでください。たとえば、どこかの技術者 Y さんが最近侮辱的な発言をしたことについての議論をメーリングリストではじめるのはやめてください。

Hacker School で性差別や人種差別について公開の議論をしないのはなぜでしょうか？ こういった話題が多くの人にとって、特に不幸な環境にいた人にとって、気を散らす大きな要因になるからです。Hacker School では、気を散らすものごとをできるだけ取り除き、皆がプログラミングに集中できるようにしたいと思っています。こういった問題を議論する場所は世界にたくさんありますが、こういった話題を避けられる場所は少なく貴重です。私たちは Hacker School をそのひとつにしたいと思っています。

なぜ対人関係ルールがあるのか

ここでの目標は Hacker School をうっとうしいルールでいっぱいにすることではなく、誰かを「悪人」としてこん棒でなぐれるようにすることでもありません。以上のルールは、快適で生産的で大胆なコミュニティを全員でつくれるようにするために設計されています。

「いま、驚く振りしたよね」「いまのは微妙な差別だ」と言われても、心配しないでください。謝罪して、ちょっと反省して、切り替えて次のことをしてください。「人としての善悪」だとか「Hacker Schooler としての善悪」だとかに関わるわけではありません。すでに述べたように、上記のルールは軽量指向です。誰もが一度はやったことがあります。実際、「正確には症候群」の方針をとりいれたのはそもそも、ニック⁷とデイヴ⁸が頻繁に「正確には症候群」になってしまっていたからです。

優れた Hacker Schooler の振る舞い

私たちが信じる方針は3つあります。方針に沿っている人は、Hacker School を順調にすごせるでしょう。

徹底する。自分のコードがなぜ、どうやって動くかを理解する。使っている道具を理解する。（Sinatra や Flask のような）フレームワークを使うなら、使い方をおぼえるだけでは表面をなぞっているにすぎません。より深く、どのように動くかを知りましょう。

志を高く。Hacker School に来たのは優れたプログラマになるためです。高みにたどりつくのは大変です。Hacker School で働く人はみな高みにたどりつこうとしています。まだたどりつけていないと思っています。

進捗をふりかえる。プログラミングがうまくなっていだけでなく、学ぶこともうまくなりましょう。ふりかえりの仕方は人によってちがいますが、基本的な2つの方法を私たちは推奨しています。ひとつめは、ブログを書くこと。誰にも読まれないとしても、書くことは自分のあたまのなかの概念を結晶化させ、理解を深めるのに役立ちます。ふたつめは、コードレビューをしてもらうこと。フィードバックと助言がもらえれば、改善していくのが楽になります。

助言

お待たせしました。次に説明するのは、おそらくあなたがこれを読んでいる本当の理由です。つまり、Hacker School ではなにをして過ごせばよいのか？

答えは人によって大きくことなりますが、一般には次のように自問するのがよいでしょう。Hacker School での3ヶ月間を自分の人生でもっとも生産的で教育的な3ヶ月間にするためにはどうすればよいのか？

ここにある助言について

ここにある助言はおもに、 Hacker School での活動をとおして発見したことを集めたものです。助言はどれも教義としてあつかうべきではなく、変わる可能性があります。ここにない戦略が自分によく効いたとしたら、すばらしいことです。（ただし、この文書の将来の版にとりこめるように、それをぜひ共有してください） ある人によく効く方法が全員によく効くとはかぎらないのです。

プログラミングにあまり慣れていない人向け

• 言語を決めてそこから離れない。Python か Ruby がおそらく最適です。JavaScript その他も大丈夫です。
• 学習しやすいテキストエディタを選んでそこから離れない。どれを選ぶのがいいか分からなかったときは、Sublime Text なら強力で直感的で Mac、Windows、Linux で使えます。
• Rails や Django のような巨大フレームワークは、その言語の概要がつかめてくるまでは触らないようにしましょう。
• コードをたくさん書く。具体的にどういうコードを書くかは、たくさん書くことと比べればあまり重要ではありません。
• 「完璧」なプロジェクトを選べたか心配しない。プロジェクト選択に関しては、完璧が良質の敵になってしまうことはよくあります。
• 自分のコードを定期的にレビューしてもらう。自分がとりくんでいる言語をよく知っている人にしてもらうのが理想的です。
• ペア・プログラミングをする。自分がとりくんでいる言語をよく知っている人にしてもらうのが理想的です。
• 自分のコードについてのメンタルモデルを確立する。
• 体系的にデバッグをするようになる。
• 小さなプログラムをいちからつくる。
• 段階的にむずかしい問題にとりくむ。1時間で終わるであろうプロジェクトをまず書き、つぎに半日、つぎに1日、つぎに2日、と。
• 道具に慣れる。ただし、ヤクの毛刈りに熱中しすぎないようにしましょう。git、GitHub、テキストエディタ、デバッガの使い方をおぼえましょう。
• 集中をみだされない。

言語を1つ以上習得している人向け

• 2番目（もしくは3番目）の言語を身につける。できれば、自分がよく知っている言語とまったく違うものをえらびましょう。（たとえば Python を知っている人なら、Ruby の前に Go、C、Scheme を学んだほうがおそらく効果的です。）
• 自分のコードを定期的にレビューしてもらう。
• 他の人のコードを定期的にレビューする。
• ペア・プログラミングをする。自分よりレベルの高い人とでも、自分より経験の少ない人とでもたくさんのことを学べます。（説明をさせられることで自分の理解を深め、明確にすることができます）
• 自分がずっと怖がっていたことをみつける（たとえばマルチスレッド・プログラミングなど）。そして、（実はそれに興味があったとして、）それを学びましょう。
• 集中をみだされない。

経験豊富な人向け

• オープンソースのプロジェクトに貢献する。とくに、定評があり、コードが高品質なものをえらびましょう。
• 自分でオープンソースのプロジェクトをはじめてみる。たとえば、自分が不満をもっていたことを自分で解決したり、これまでに何度も書いたコードをライブラリにしたりするのも一案です。
• 上記に書かれているようなことを継続する。優秀なプログラマにコードレビューをしてもらったり、共同作業をしたりましょう。Hacker School の中や外でそういう人がみつからないときは、よろこんでお手伝いします。
• 集中をみだされない。

ペア・プログラミング

Hacker School 卒業生ほとんどはバッチのうちにもっとペア・プログラミングをしておけばよかったと言います。私たちは第1バッチでこのことを学び、以降どのバッチでも説明しています。それでも、もっとペアすればよかったと Hacker School を終えてから漏らす人は多いです。

ペア・プログラミングとは

ペア・プログラミングとは1台のコンピュータにむかって2人で同じコードにとりくむことを言います。重要なのは、1台のコンピュータというところです。ペア・プログラミングは積極的に共同作業をすることであり、2人で同じプロジェクトにとりくんだり、席を並べたりするだけのことではありません。

どの瞬間にも、ひとりが「ドライバー」（driver）になり、もうひとりが「ナヴィゲーター」（navigator）になります。ドライバーはキーボードのまえに座って実際にコードを書く人です。ナヴィゲーターはドライバーのとなりに座って同じスクリーンを見ます。ナヴィゲーターの仕事はアイデアを説明し、ドライバーに指示し、いま書かれているコードがプロジェクト全体でどう位置付けられるかを考えることです。ドライバーとナヴィゲーターの役割は定期的に、少なくとも2時間に1度、できればもっと頻繁に交代すべきです。交代することで知識の移転がやりやすくなります。両方がドライバーをすることで中がどうなっているかをそれぞれがつかみ、両方のやる気を持続させることができます。

壁にぶつかることもあります。たとえば、ふたりのどちらも理解できない概念にいきあたったり、どんなライブラリを使えばいいか分からなくなったりという場合です。こうしたとき、ペアを一旦やめてもかまいません。そうするときは、「どのライブラリがいいか、おたがい15分かけて調査してみよう。終わったら結果を報告しあおう」というように時間を決めてください。重要なのは、一旦ペアをやめ、決まった時間になったらペアにもどると明示的に合意することです。一見ペアをしているような振りをしながら実はとなりで作業しているだけという状況だけは避けてください。これは起こりやすい状況で、分かっていながら何時間も無駄にすることになってしまいがちです。

ペアをすることの利点はいくつかあります。ひとつは目の前のタスクに両者を集中させてくれることです。ひとりで作業しているときは、（たとえばメールを受けたり、面白そうな新しい JavaScript フレームワークをみつけたりして）集中をみだされることがよくあります。誰かがとなりに座っていて自分のスクリーンを見ているときには、Gmail に画面を切り替えるのにずっと大きな抵抗を感じます。ペアがうまくいくと、片方が他方の集中を助けるという生産的なフィードバックがもたらされます。

もうひとつの利点は、たくさんの小さな誤り（タイプミス、セミコロン忘れ、変数名のまち）をナヴィゲーター役がすぐにみつけられるということです。バグは埋めこまれた瞬間に駆除するのが、それ以降のどの瞬間よりも楽であるため、これは最終的には大きな利益になります。それに、有名なことばですが、たくさんの目があれば、バグはすべてつぶせるのです。

ペア・プログラミングは知識をうまく移転させてくれ、言語の習得からエディタの選択、コマンドラインの小技まで様々な効果があります。

それに、楽しいですよ。

ペア・プログラミングをする前に確認すること

ペア・プログラミングをはじめる前に、両者が似た（あるいは、少なくとも両立可能な）目標をもっていることを確かめるとよいでしょう。ひとりが Python を学ぶことを目標にしていて、もうひとりがあるバグをできるだけ早くつぶすことを目標にしているという場合、摩擦が生じることがあります。お互いの考えがおおむね一致していれば、あるいは少なくとも互いのやろうとしていることを知っていれば、お互いの目的を達成できる可能性がたかくなります。

ここに書くべきかどうか議論のあったやっかいな項目

私たちは Hacker School に来たい人全員に来てもらいたいと思っています。また、Hacker School での活動と時間が全員に楽しく、生産的で、充実したものであってほしいと思っています。

ここにいる人たちが「すべき」こと、「すべきでない」ことをすべて列挙したいとは思っていません（また、できません）。そのかわり、全員が責任と敬意をそなえた大人だとみなし、そのように振る舞い行き違いが起こっても乗り越えられると信頼します。

それでも、人は複雑で、分別ある人のあいだでも何が敬意ある振舞いかについては意見が分かれることがあります。いかに世界を単純化し現実のわずらわしい細部を捨象しようとしても、このやっかいな事実は成立しつづけます。

そのため、Hacker School で個人個人がどのように振る舞うよう期待されているか、彼らがなぜこの場にいるべきか（いるべきでないか）を、このセクションに書いておくことにしました。

まずはもっとも重要なこと：あなたがここに来たのは、自分が来たいと思ったからであるべきであり、ほかの誰かにそう言われたからであるべきではありません。その誰かが両親であっても、上司であっても、社長であっても、同じです。そうでない理由でここに来るほど、人生は長くありません。

プログラマとして腕をあげたいから、プログラミングやプログラミングに関する事柄に大半の時間を割きから、というのがここに来る主な理由であるべきです。

ですから、ある朝起きて Hacker School が人生のこの瞬間、自分のいたい場所ではないと気づいたら（あるいは志願したときに思っていたような場所でないと気づいたら）、相談してください。あなたには合わなかったということになったとしても、私たちは傷つけられたとは思いません。

誰でもみな、うまく集中できないことはあります。バッチ中のある時点で、うまく集中できないということはきっと起こるでしょう。これは普通のことです。ただし、そういうときに、他のひとの集中をさまたげることはしないでください。

ちょっと曖昧すぎませんか。もう少し具体的には？

そうですね、自分のことは自分でする、話し手には礼儀正しくする、日中の Hacker School 内では無関係な話をしない（週末の計画を話したり休憩したりしたいなら、コーヒーを飲みに出かけてください）、ということになるでしょう。ですが、こういったことはもうよく知っていると思います。ただ、同僚を尊重し、成熟した大人として振る舞ってください。

困難と精神の健康

Hacker School は誰でもすばらしい時間が過ごせ、完璧に生産的で、すぐに友人が作れる場所であると思われることがあります。現実には、いつもすばらしいわけではありません。Hacker Schooler たちがなにに苦戦するかを認識し、あらゆる問題や感情について皆がコミュニティからの支援を求めるよう奨励するためにこのセクションがあります。あなたが応募を考えていて、こうしたことのいずれかを心配しているのであれば、このセクションを Hacker School への応募を抑止するものではなく支援の表明として受け取ってくもらえればと思います。

Hacker Schooler は孤独になることがあります。Hacker School に来るために友人や家族から離れている人もいます。ここで友人を新しく作るには時間とエネルギーがかかります。これほど多くの新しい人たちに会うことで圧倒されていることがあります。Hacker Schooler は自分の子供やその他大切な人たちと過ごせなくなっていることを申し訳なく思うことがあります。長距離通学やぎりぎりのスケジュールをしている人は、仕事の後の楽しみから疎外されているように感じることがあります。

Hacker Schooler は自分以外の全員が自分よりずっと生産的だと感じることがあります（これは多くの場合インポスター症候群の証拠です）。とても調子のよい人だけが目につきやすくなりがちですが、実際には生産性はだれでも上がったり下がったりの繰り返しです。

Hacker Schooler は決まりがないために困難を感じることがあります。決まりのある環境から来た人は、合わせていくのは最初は難しいものだと思っておいてください。

Hacker Schooler は鬱など精神の健康に関して困難を感じることがあります。頭がよく、やる気を自分から出すことができる人も、精神健康上の問題がおきることがあり、それに対処するために助けをもとめることは何ら恥ではありません。

あなたが Hacker School で困難を感じているとしたら、それはあなただけではありません。ファシリテータに相談したり、 Hacker School 内部のチャットで会話したり、専門家に助けをもとめたりするという手があります。それが Hacker School に入って最初の日であれ、卒業して何年もたってからであれ、Hacker School のコミュニティはあなたを助けようとしています。

就職、求人、資金の出どころ

Hacker School が存在できるのは、色々な企業が採用活動のためにお金を払ってくれるからです。この資金がなければ、Hacker School は存在できませんし、正直に言っておけば、私たちはいつどの時点でも経済危機のぎりぎりのところで踏みとどまっています（まあ、冗談ですが。ある意味）。Hacker School の運営方法はだいたい次のようにまとめることができます。採用活動のために Hacker School を運営することはしません。Hacker School を運営するために採用活動はします。世界のほとんどは（とくにネットのトロルは）こういう発言を信用しません。それはかまいませんが、あなたに信じてもらうことは重要です。まだ信じられのであれば、バッチが終わるまでには信じてもらえるよう願っています。

（お金をたっぷりかせぐ気がないという訳ではありません。いつかそうできたらと思っています。適正な金額の給料を支払うためだけでも、いずれ現在よりはるかに多くの資金が必要になるでしょう。）

では、どうやって資金をかせぐのか？ いまのところ、いくつかの企業と採用活動の協定をむすんでいて、Hacker School 卒業生が1人採用されるたびに、90日以上勤務をつづけられた場合に、賞与をのぞいた初年の給料の25%が私たちに支払われます。つねにこう単純ではなく、支払ってもらえなかったり低い額しかもらえなかったりというやっかいな特殊例もありますが、おおむねこんなところです。

企業が卒業生に紹介される手順は進化しつづけています。過去には、提携している企業のプログラマを招待して、なぜその企業では働きやすいのかを説明してもらう「ジョブフェア」を催したこともありました。通常は夕食と飲み物を提供し、全員が出会って話す機会を提供します。

企業に hackerschool.com のアカウントも発行することもしています。これにより企業はみなさんのプロフィールをみて、連絡をとり、会って話すつもりがあるか聞くことができます。同様に、みなさんは企業のプロフィールをみて、連絡をとり、会って話すつもりがあるか聞くことができます

Hacker School のプロフィール欄で「企業に見せる」のチェックボックスをオンにしておくと、提携している企業があなたの情報（GitHub、プロジェクトなど）を見られるようになります。オフにしておくと、企業からは見られなくなります（他のHacker Schooler からは常に見られます）。ここをオンにしておいてもらえると、Hacker School は非常にたすかります。

時期

通常、バッチの最後2、3週になるまで、就職のことは考えないようおすすめしています。次の仕事を考えはじめるとそれがすぐに最大の関心事になってしまい、プログラマとしての腕をあげることが最大の関心事でなくなってしまい、ここで過ごす時間から得られる成果が減ってしまうからです。

（ただし、就職のことがストレスになったり、頭から離れなくなってしまったときは、もっと早い時点で相談してもらってもかまいません。ファシリテータに聞くか、ジョブチームにメールしてください。）

職をさがしに出掛けなくても、Hacker School にいるあいだに就職の機会がやってくることがありえますし、実際きます。友人がスタートアップに参加しないかと声をかけてきたり、リクルータが連絡をとってきたりします（Hacker Schooler だけを対象にしているリクルータもいます）。ミートアップでたまたま会った人があなたを雇おうとするかもしれません。

Hacker School のあとに職につこうと思っていない人は、それはそれでかまいません。バッチの直後かそのしばらくあとでプログラミングの職につくつもりであれば、できるだけ私たちを通して職についてください。Hacker School の生存はここにかかっています。

ゲスト

「ゲストをつれてきてもいいですか」という質問については、短く答えると「ノー」です。

私たちの目標は学びをみちびく安全な環境をつくることです。見慣れない人が出たり入ったりすることはその実現をむずかしくします。チェックイン⁹のときに紹介されていなければそれが倍加します。

Hacker School で会う人のうち、その回のバッチの参加者でない人は4種類に分かれます。卒業生、Hacker School を強化する非常に優れたプログラマ（たとえばレジデント¹⁰や講演者）、提携先企業からきたハッカー、明示的に招待された Hacker Schooler 候補者、です。こうした人については事前に告知し、チェックインのときに紹介され、その日は1日滞在してもらい、私たちの対人関係ルールを知ってもらい、できるだけ邪魔にならないように努力しています。例外を認めることもありますが、普通でない状況のときだけです。

高圧的に聞こえるかもしれませんが、そのような意図はありません。以上のポリシーについて質問があれば、ぜひお聞かせください。

卒業生

卒業生は毎週木曜日の終日、コーディングをしに来てもかまいません。

卒業生は Hacker School の営業時間外（月曜から金曜の午前10時から午後7時以外）にも歓迎されます。この時間、Hacker School のスペースはプログラミングのほか、社交イベントにも使えます。ゲストを受け入れると具体的に告知されたイベントでなければ、ゲストは許可されません。ゲストを受け入れるイベントかどうかは、ファカルティの一存により決まり、事前に告知されます。ゲストを受け入れる社交イベントのときはいつでも最低1人のファカルティが出席します。ゲストは対人関係ルールを遵守しなければなりません。

Hacker School の全員にお願いしているのと同様に、ここにいるあいだはオープンソース・ソフトウェアにとりくむようお願いしています（他のひととペア・プログラミングができず、他のひとに共有できないプロプライエタリ・ソフトウェアの作業をしてはいけません）。また、誰がきているのか他の Hacker Schooler に分かってもらえるよう、チェックインとZulip上で自己紹介するようお願いしています。

くわえて、市外の卒業生は木曜日に都合がつかない場合は他の日の訪問も歓迎されます。ニューヨークにくる予定のある卒業生の方は、ぜひおしらせください。お待ちしています。

卒業生のほとんどはスペースの鍵をもっていません。Hacker School コミュニティでの追加の役割を果たすと同意した少数の卒業生は鍵をもっています。

家族

あなたが現在のバッチの参加者で、直接の家族やパートナーに Hacker School を少しだけ見せたいときは、営業時間外にしてください。訪問は短くし、その場にいるほかの人に気をつかい、ゲストとは常に行動をともにしてください。

Hacker School の沿革

1. 2006年秋。ニックとデイヴが Signals & Systems の授業で出会う。
2. 2007年夏。ニックとソナリが Shakespeare in the Park ¹¹で出会う（ソナリはニックの同僚のひとりでした）。
3. 2008年春。ニックとデイヴが仕事の後の時間に「ビジネスミーティング」をはじめ、会社を起こす相談をしはじめる。
4. 2010年10月。ニックとデイヴがプログラミングの仕事を辞めて、「OkCupid for jobs」を立ち上げる。
5. 2010年6月から10月。ニックとデイヴがカリフォルニア州マウンテンビューに住み、Y Combinator プロジェクトのひとつになる。ニューヨークに戻りたいと言い、ポール・グレアムに「自己中心的」と言われる。
6. 2010年秋。ソナリが週末にニックとデイヴといっしょに働くようになる。
7. 2011年2月。ソナリが軽めの仕事と給料を辞め、チームにフルタイムで加わる。
8. 2011年6月。デイヴがポール・グレアム、Sam Altman、Paul Buchheit と「ハッカーの学校」について長く話し、このアイデアに興奮してニューヨークに戻る。少数に人たちをこの「ハッカーの学校 (hacker school)」の実験に招待する（この名前は一時的なものと考えていたので、大文字にはしませんでした。「学校」と呼ぶのがいいかどうかも分かりませんでした）。
9. 2011年7月16日。このバッチに参加するつもりでいた人のうち3分の1が開始2日前にとりやめる。
10. 2011年7月18日。「バッチ[0]」（または2011年夏のバッチ）の初日。ニック、デイヴ、ソナリを含めて9人だけで、5週間のバッチだった。ニューヨーク大学の窓のない小さな部屋を使う。アランはこの Hacker Schooler のひとりで、まったく訳がわかっていないニックとデイヴにモナドを教えようと頑張る。ソナリが唯一の女性参加者。
11. 2011年8月。John “workmanjj” Workman が「絶対卒業しない」を Hacker School のモットーとするよう提案。
12. 2011年9月。第2バッチ開始。Spotify の窓のない少しだけ大きな部屋を使う。
13. 2012年2月。Hacker Schooler 20人で第3バッチ開始。このなかにトムがいた。このバッチはハフィントン・ポストのオフィスを使った。Danielle Sucher が最初の Hacker School 卒業生になる。
14. 2012年5月。トムとアランをこの夏のバッチを手伝う契約職員として雇う。
15. 2012年6月。Hacker Schooler 20人で第3バッチ開始。アリソン、ザック、メアリーがこのなかにいた。このバッチは45%が女性で、Etsy のオフィスを使った。
16. 2012年8月。トムとアランが常勤になり、ザックとアリソンが加わる。
17. 2012年10月。Jessica McKellar、Peter Seibel、Alex Payne、Stefan Karpinski、David Nole が最初のレジデントになる。
18. 2013年2月。マンハッタンに自分たちの場所を確保！ 米国政府がメアリーを「例外的」と認め、就労許可を出してくれる。
19. 2013年9月。自然光いっぱいで蠅の出ない場所に引越し。
20. 2014年4月。伝統がバッチから引き継がれやすくなるよう、オーバーラップ型のバッチに移行。
21. 2014年6月。最初の運用専従者としてレイチェルを雇う。

翻訳

Yusuke Matsubara がHacker Schoolの許可のもとでHacker School 取扱説明書の日本語訳をしてくれました。どうもありがとう。

Changelog

1. 2013年5月1日 – 初公開。
2. 2013年9月19日 – 対人関係ルールを一新。
3. 2013年9月19日 – contact information を追加。
4. 2014年1月29日 – テキストエディタについての助言を追加。
5. 2014年2月24日 – スペースについてのポリシーとゲストポリシーを追加。
6. 2014年3月10日 – 学生 (student) を「Hacker Schooler」と言い換える。ゲストポリシーをさらに更新。
7. 2014年6月30日 - 翻訳セクションを追加。
8. 2014年7月3日 - 第4ルール「性的ほのめかしをしない」を「差別のほのめかしをしない」に変更し、説明を一新。
9. 2014年7月7日 - 差別的表現を除去。Hacker School の歴史を更新。
10. 2014年7月9日 - メーリングリストシステムの詳細を更新。
11. 2014年7月25日 - レイチェルを追加。困難のセクションを追加。