whym blog

訳注：これは Wikidata: A Free Collaborative Knowledgebase by Denny Vrandečić, Markus Krötzsch (in Communications of the ACM, 2014) の日本語訳です。ウィキデータ（Wikidata）は2012年にはじまり、2015年に公式に Freebase （の一部）を引き継ぐとされる、大規模知識ベース（ナレッジベース）のひとつです。ウィキペディアおよびその姉妹プロジェクトとボランティアベースを共有しアクティブに更新されつづけていることがひとつの特徴です。本稿は Communications of ACM に掲載された解説のため、想定読者はやや技術よりの人かと思います。ウィキデータ内にも解説はいろいろありますのであわせてご覧ください。

Wikidata: A Free Collaborative Knowledgebase by Denny Vrandečić, Markus Krötzsch (in Communications of the ACM, 2014)

http://dx.doi.org/10.1145/2629489 http://korrekt.org/page/Wikidata:_A_Free_Collaborative_Knowledgebase

License

ライセンス

The article text is published under the terms of Creative Commons CC-By 3.0. The "appropriate credit" required by the license (the "By" part) should have the form of a citation of the article mentioning at least the authors, original title, journal, and year. The article is published under the ACMs hybrid open access model and will also remain freely available from ACM servers. Image copyrights are separate: Tower of Babel engraving by Isaac Basire of 1733 is out of copyright; the Reasonator screenshot (Fig. 3) includes media with various licenses and is considered Fair Use (Reasonator is created by Magnus Manske). The fonts used in the PDF are not free, we do not own any rights for them, and we do not release these fonts under CC-By.

本稿はクリエイティブ・コモンズ CC-By 3.0 の条項のもとで発行されている。このライセンス（の「By」部分）が要求する「適切な帰属表示」は、少なくとも著者・原題・ジャーナル名・発行年に言及して本稿を参照する形式をとるべきである。本稿はACMのオープンアクセスモデルのもとで発行されており、ACMサーバ上でフリーに公開されつづける。画像の著作権はそれぞれ異なる。1733年の Isaac Basire 作バベルの塔の著作権は切れている。Reasonator のスクリーンショット（図3）はさまざまなライセンスの画像を含んでおり、フェアユースと考えられる（Reasonator の作者は Magnus Manske）。PDF内のフォントはフリーではなく、著者はこれらのフォントについてなんら権利を持っておらず、CC-Byでリリースしない。

Unnoticed by most of its readers, Wikipedia1 continues to undergo dramatic changes, as its sister project Wikidata introduces a new multilingual "Wikipedia for data" (http://www.wikidata.org) to manage the factual information of the popular online encyclopedia. With Wikipedia's data becoming cleaned and integrated in a single location, opportunities arise for many new applications.

ほとんどの読者に気づかれないまま、ウィキペディア2は劇的な変化を続けている。姉妹プロジェクトであるウィキデータが、この人気あるオンライン百科事典内の事実的情報をになう新しい多言語の「データのためのウィキペディア」を導入したためだ。ウィキペディアのデータが整理され一箇所に統合されていくにつれ、新しい応用の機会が多数出現する。

Originally conceived in 2001 as a mainly text-based resource, Wikipedia 3 has collected increasing amounts of structured data, including numbers, dates, coordinates, and many types of relationships, from family trees to the taxonomy of species. It has become a resource of enormous value, with potential applications across all areas of science, technology, and culture. This development is hardly surprising, given that Wikipedia is committed to "a world in which every single human being can freely share in the sum of all knowledge," according to its vision statement (https://wikimediafoundation.org/wiki/Vision). There is no question this must include data that can be searched, analyzed, and reused.

2001年にもともとテキストベースのリソースとして想定されたウィキペディア 4 は、数値・日付・座標・家系図や生物分類等のさまざまな種類の関係など、構造化データをどんどん集めていった。科学・技術・文化のすべての領域で応用の可能性をもつ、途方もなく価値のあるリソースになった。このことは、ウィキペディアがそのヴィジョンステートメントにあるように「人類の全知識をすべての人々が共有できる世界」の実現を目指すことからして驚くべきことではない。そのなかには検索・分析・転用ができるデータもふくまれることは間違いない。

It may be surprising that Wikipedia does not provide direct access to most of it, through either query services or downloadable data exports. Actual use of the data is rare and often restricted to specific pieces of information (such as geo-tags of Wikipedia articles used in Google Maps). The reason for this striking gap between vision and reality is that Wikipedia's data is buried in 30 million Wikipedia articles in 287 languages from which extraction is inherently very difficult.

ウィキペディアのほとんどについて、クエリサービスやダウンロード可能なデータエクスポートの形で、ウィキペディア自身が直接的なアクセスを提供していないということは驚かれるかもしれない。このデータの実際の利用はまれであり、多くの場合、特定の情報（たとえば Google Maps で使われるウィキペディアの位置情報タグなど）にかぎられる。ヴィジョンと現実にこれほど深いギャップがあるのは、ウィキペディアのデータが287言語で書かれた3000万件の項目に埋まっていて、仕組み上抽出がとても難しいからだ。

This situation is unfortunate for anyone wanting to use the data but is also an increasing threat to Wikipedia's main goal of providing up-to-date, accurate, encyclopedic knowledge. The same information often appears in articles in many languages and in many articles within a single language. Population numbers for Rome, for example, can be found in English and Italian articles about Rome but also in the English article "Cities in Italy." The numbers are all different.

この状況はデータを利用しようとする人にとって不幸であるだけでなく、ウィキペディアの主要な目標である、最新の、正確な、百科事典的知識の提供をおびやかすものにもなりつつある。同じ情報がしばしば多数の言語版の項目上や、1言語版の別の項目にあらわれる。たとえばローマの人口は、ローマについての英語版とイタリア語版の項目だけでなく、英語版の「イタリアの都市」という項目にも掲載されている。これらの数値はすべてたがいに異なっている。

Wikidata aims to overcome such inconsistencies by creating new ways for Wikipedia to manage its data on a global scale; see the result at http://www.wikidata.org. The following essential design decisions characterize the Wikidata approach.

ウィキデータの目的は、グローバルな規模でウィキペディアのためのデータを管理する新しいやり方をつくり、こうした非一貫性を解決することだ。その結果が http://www.wikidata.org である。下記に示す本質的な設計上の決定がウィキデータのアプローチを特徴づけている。

Open editing. As in Wikipedia, Wikidata allows every user to extend and edit the stored information, even without creating an account. A form-based interface makes editing easy.

オープンな編集。ウィキペディアにおいてと同じように、ウィキデータに保管されたデータは全利用者が拡張し、編集できる。アカウントの作成も必要ない。フォームベースのインターフェイスがあり、編集は容易だ。

Community control. Not only is the actual data controlled by the contributor community, so, too, is the schema of the data. Contributors edit the population number of Rome but also decide whether there is such a number in the first place.

コミュニティによる管理。実際のデータが投稿者コミュニティに管理されているだけでなく、データのスキーマも同様だ。投稿者はローマの人口を編集するだけでなく、そもそもそういった数値があるかどうかの決定もする。

Plurality. It would be naive to expect global agreement on the "true" data, since many facts are disputed or simply uncertain. Wikidata allows conflicting data to coexist and provides mechanisms to organize this plurality.

多元性。事実の多くには論争があったり不確定であったりするため、「真の」データについてグローバルな合意を期待するのはナイーヴだ。ウィキデータは衝突するデータの共存をゆるし、この多元性を整理する仕組みを提供する。

Secondary data. Wikidata gathers facts published in primary sources, together with references to these sources; for example, there is no "true population of Rome" but rather a "population of Rome as published by the city of Rome in 2011."

二次データ。ウィキデータは一次情報源で公刊された事実を、それら情報源への参照とともに収集する。たとえば、「ローマの真の人口」というものはなく、「2011年にローマ市によって公刊されたローマの人口」がある。

Multilingual data. Most data is not tied to a single language; numbers, dates, and coordinates have universal meaning, so labels like "Rome" and "population" are translated into many different languages. Wikidata is multilingual by design. While Wikipedia has independent editions for each language, there is only one Wikidata site.

多言語データ。データの多くは1つの言語にひもづけられない。数値、日付、座標は普遍的な意味をもっている。「ローマ」や「人口」といったラベルは多くの異なる言語に翻訳される。ウィキデータは多言語になるよう設計されている。ウィキペディアの各言語版は独立だが、ウィキデータには1サイトしかない。

Easy access. Wikidata's goal is to allow data to be used both in Wikipedia and in external applications. Data is exported through Web services in several formats, including JavaScript Object Notation, or JSON, and Resource Description Framework, or RDF. Data is published under legal terms that allow the widest possible reuse.

アクセスの容易性。ウィキデータの目標は、ウィキペディアと外部アプリケーションの両方でデータを使えるようにすることだ。データはウェブサービスを通して、JavaScript オブジェクト記法（JSON）、リソース記述フレームワーク（RDF）など、いくつかの形式でエクスポートされる。転用の可能性を最大にする利用規定のもとでデータは公刊される。

Continuous evolution. In the best tradition of Wikipedia, Wikidata grows with its community of editors and developers and the tasks they give it. Rather than develop a perfect system to be presented to the world in a couple of years, new features are deployed incrementally and as early as possible.

継続的な進化。ウィキペディアの最良の伝統をひきづき、ウィキデータは編集者と開発者のコミュニティ、および彼らが与えるタスクとともに成長する。数年で完璧なシステムを開発して世界に発表するのではなく、新機能は逐次的にできるだけはやくデプロイされる。

These properties characterize Wikidata as a specific kind of curated database. 5

以上の特徴がウィキデータを特定の種類のキュレーションされたデータベース6にしている。

Data in Wikipedia

ウィキペディアのデータ

The value of Wikipedia's data has long been obvious, with many efforts to use it. The Wikidata approach is to crowd-source data acquisition, allowing a global community to edit the data. This extends the traditional wiki approach of allowing users to edit a website. Wiki is a Hawaiian word for fast; Ward Cunningham, who created the first wiki in 1995, used it to emphasize that his website could be changed quickly.7

ウィキペディアのデータの価値は昔から明白であり、それを利用しようと多くの努力がなされてきた。ウィキデータのアプローチはデータ獲得をクラウドソーシングにし、グローバルなコミュニティがそのデータを編集できるようにすることだ。これは、利用者がウェブサイトを編集できるようにするという伝統的なウィキのアプローチを拡張している。ウィキはハワイ語で速いという意味だ。1995年にこの言葉をつくったウォード・カニンガムは、自分のウェブサイトがすばやく変更できるということを強調するのにこの言葉をつかった8。

The most popular such system is Semantic MediaWiki, or SMW,9 which extends MediaWiki, the software used to run Wikipedia, 10 with data-management capabilities. SMW was originally proposed for Wikipedia but was quickly used on hundreds of other websites as well. Unlike Wikidata, SMW manages data as part of its textual content, thus hindering creation of a multilingual, single knowledgebase supporting all Wikimedia projects. Moreover, the data model of Wikidata is more elaborate than that of SMW, allowing users to capture more complex information. In spite of these differences, SMW has had a great influence on Wikidata, and the two projects share code for common tasks.

そのようなシステムとしてもっとも人気があるのは、ウィキペディアの運用に使われるソフトウェアである MediaWiki 11を拡張してデータ管理機能を追加する Semantic MediaWiki (SMW) だ 12。SMW はもともとはウィキペディア向けに提案されたが、すぐに何百もの他のウェブサイトにも使われるようになった。ウィキデータとは違い、SMW はデータをテキストコンテンツの一部として管理しており、このため多言語で全ウィキメディアプロジェクトをサポートする単一の知識ベースの作成には障害がある。さらに、ウィキデータのデータモデルは SMW のそれより洗練されており、利用者がより複雑な情報をとらえることができるようになっている。このような違いはあれど、SMW はウィキデータに多大な影響をもたらしており、両プロジェクトは共通のタスクに関するコードを共有している。

Other examples of free knowledgebase projects are OpenCyc and Freebase. OpenCyc is the free part of Cyc,13 which aims for a much more comprehensive and expressive representation of knowledge than Wikidata. OpenCyc is released under a free license and available to the public, but, unlike Wikidata, is not editable by the public. Freebase, acquired by Google in 2010, is an online platform that allows communities to manage structured data. 14 Objects in Freebase are classified by types that prescribe what kind of data an object can have; for example, Freebase classifies Einstein as a "musical artist" since it would otherwise not be possible to refer to recordings of his speeches. Wikidata supports the use of arbitrary properties on all objects. Other differences from Wikidata are related to multi-language support, source information, and the proprietary software used to run the site. The latter is critical for Wikipedia, which is committed to running on a fully open source software stack to allow all to fork, or copy and create one's own version of the project.

フリーな知識ベースのプロジェクトの例としては他に OpenCyc と Freebase がある。OpenCyc は Cyc15 のうちフリーな部分であり、Cyc はウィキデータよりも包括的で表現力の高い知識表現を目指している。OpenCyc はフリーなライセンスで公衆に向けてリリースされているが、ウィキデータと違って公衆が編集することはできない。2010年にグーグルに買収された Freebase はオンラインのプラッフォームであり、Freebase ではコミュニティがデータの構造を管理できる 16。Freebase 内のオブジェクトは、そのオブジェクトがどのような種類のデータを持てるかを規定する型で分類される。たとえば、Freebase はアインシュタインを「音楽家」として分類する。こうしなければ、彼の講演の録音を参照できないからである。ウィキデータは任意のプロパティを全プロジェクトで使用することをサポートしている。ウィキデータと異なる他の点は、多言語サポート、典拠情報、サイトの運用に使うプロプライエタリなソフトウェアに関連する。最後の点は、完全にオープンソースなソフトウェアの組で運用することを約束しているウィキペディアにとって重要である。そのことでウィキペディアは皆が自分のバージョンのプロジェクトをフォークし、複製し、作成できるようになっている。

Wikipedia's data is buried in 30 million Wikipedia articles in 287 languages from which extraction is inherently very difficult.

ウィキペディアのデータは287言語で書かれた3000万件の項目に埋まっていて、仕組み上抽出がとても難しい。

Other approaches to creating knowledgebases from Wikipedia have aimed at extracting data from Wikipedia, most notably DBPedia 17 and Yago, 18 that extract information from Wikipedia categories and from infoboxes, the tabular summaries in the upper-right area of many Wikipedia articles. Additional mechanisms help improve extraction quality. Yago includes temporal and spatial context information, but neither DBpedia nor Yago extract source information.

ウィキペディアから知識ベースをつくろうとするその他のアプローチはウィキペディアからデータを抽出することを目的としており、ウィキペディアのカテゴリとインフォボックス（ウィキペディア項目の多くの右上にある表形式の概要）から情報を抽出する。著名なのは DBPedia 19と Yago 20 だ。追加的な仕組みが抽出品質を高めている。Yago は時間的・空間的な文脈情報を含んでいるが、DBPedia も Yago も典拠情報を抽出していない。

Wikipedia data, obtained from these projects or through custom extraction methods, has been used to improve object search in Google's Knowledge Graph (based on Freebase) and Facebook's Open Graph and in answering engines, including Wolfram Alpha,21 Evi,22 and IBM's Watson.23 Wikipedia's geo-tags are also used by Google Maps. All these applications would benefit from up-to-date, machine-readable data exports (such as the way Google Maps shows India's Chennai district in the polar Kara Sea, next to Ushakov Island). Among these applications, Freebase and Evi are the only ones that also allow users to edit or to at least extend the data.

これらのプロジェクトか独自の抽出方法によって獲得されたウィキペディアのデータは、グーグルの（Freebase にもとづいた）Knowledge Graph や Facebook の Open Graph、また、Wolfram Apha24、Evi25、IBM の Watson26 など質問応答エンジンにおけるオブジェクト検索を改善するのに使われてきた。以上すべての応用が、最新の、機械可読なデータエクスポートから恩恵をうける（たとえばグーグルマップが shows India's Chennai district in the polar Kara Sea, next to Ushakov Island）ことになる。これら応用のうち、Freebase と Evi だけが利用者による編集か少なくともデータの拡張を許している。

A Short History of Wikidata

ウィキデータ小史

Wikimedia launched Wikidata in October 2012. Initially, features were limited, with editors only able to create items and connect them to Wikipedia articles. In January 2013, three Wikipedias—first Hungarian, then Hebrew and Italian—began to connect to Wikidata. Meanwhile, the Wikidata community had already created more than three million items. The English Wikipedia followed in February, and all Wikipedias were connected to Wikidata in March.

ウィキメディアは2012年10月にウィキデータを公開した。当初、機能は限定されており、編集者はアイテムを作成し、ウィキペディア項目同士をつなぐことしかできなかった。2013年1月、ハンガリー語版、ヘブライ語版、イタリア語版の3つのウィキペディアが、ウィキデータへの接続を開始した。その一方で、ウィキデータのコミュニティは300万アイテムをすでに作成していた。英語版ウィキペディアが2月につづき、全ウィキペディアが3月にウィキデータに接続された。

Wikidata received input from more than 40,000 contributors as of February 2014. Since May 2013, it has continuously had more than 3,500 active contributors, those making at least five edits per month. These numbers make it one of the most active Wikimedia projects.

ウィキデータは2014年2月時点で、4万人の投稿者から入力をうけている。2013年5月以降、継続的に、アクティブな投稿者（1ヶ月間に少なくとも5回編集している人）が3500人以上いる。この数値により、ウィキデータはウィキメディアプロジェクト群のうちもっとも活発なプロジェクトのひとつに位置付けられる。

In March 2013, Wikimedia introduced Lua as a scripting language for automatically creating and enriching parts of articles (such as the infoboxes mentioned earlier). Lua scripts can access Wikidata, allowing Wikipedia editors to retrieve, process, and display data.

2013年3月、ウィキメディアは項目の一部分（先に述べたインフォボックスなど）を作成しリッチにするためのスクリプト言語として Lua を導入した。Lua スクリプトはウィキデータにアクセスでき、これによりウィキペディア編集者はデータを取得、加工、表示することができる。

Many other features were introduced in 2013, and development is planned to continue for the foreseeable future.

2013年には他にも多数の機能が導入され、予測できる範囲で今後も開発は継続する予定だ。

Out of Many, One

多から一へ

The first challenge for the Wikidata community was to reconcile the 287 language editions of Wikipedia; for example, for Wikidata to be truly multilingual, the object representing "Rome" must be one and the same across all languages. Fortunately, Wikipedia already has a closely related mechanism: language links, displayed on the left side of each article, connecting articles in different languages. These links were created from user-edited text entries at the bottom of each article, leading to a quadratic number of links; for example, each of the 207 articles on Rome included a list of 206 links to all other articles on Rome—a total of 42,642 lines of text. By the end of 2012, 66 of the 287 language editions of Wikipedia included more text for language links than for actual article content.

ウィキデータのコミュニティにとって最初の難題はウィキペディア287言語版を協調させることだった。たとえば、ウィキデータが真に多言語になろうとするのであれば、「ローマ」を表すオブジェクトは全言語をつうじて1つでなければならない。幸い、ウィキペディアはこれに強く関連する仕組みをすでにもっている。各項目の左側に表示され、異なる言語のあいだで項目をつないでいる言語リンクである。これらのリンクは各項目の下部、利用者が編集するテキストから生成されており、リンクの数は二乗に比例する。たとえば、ローマについての207項目はそれぞれが他の206項目へのリンクを含んでおり、合計すれば42642行のテキストになる。2012年末までに、ウィキペディア287言語版のうち66言語版では、項目の実際の内容よりも言語リンクのほうに多くのテキストがあった。

It would clearly be better to store and manage language links in a single location, and so became Wikidata's first task. For every Wikipedia article, a page has now been created on Wikidata for managing links to related Wikipedia articles in all languages; these pages are called "items." Initially, only a limited amount of data could be stored for each item: a list of language links, a label, a list of aliases, and a one-line description. Labels, aliases, and descriptions can now be specified individually for up to 358 languages.

言語リンクを1箇所で保管し管理するほうがあきらかによい。そのためこれがウィキデータの最初のタスクになった。各ウィキペディア項目に対して、全言語のウィキペディア項目へのリンクを管理するための1個のページがウィキデータに作成されている。これらのページは「アイテム」と呼ばれる。当初、アイテムには限定された量のデータしか格納できなかった。言語リンクのリスト、ラベル、別名のリスト、1行の説明である。ラベル、別名、説明は未では最大で358言語について個別に指定することができる。

The Wikidata community has created bots to move language links from Wikipedia to Wikidata, and more than 240 million links were removed from Wikipedia. Most language links displayed on Wikipedia are served from Wikidata. It is still possible to add custom links in an article, as needed in the rare cases where links are not bi-directional; some articles refer to more general articles in other languages, while Wikidata deliberately connects pages that cover the same subject. By importing language links, Wikidata gained a huge set of initial items "grounded" in actual Wikipedia pages.

ウィキデータのコミュニティはウィキペディアからウィキデータへ言語リンクを移植するためのボットを作成し、2億4000万個以上のリンクがウィキペディアから除去された。ウィキペディアで表示される言語リンクのうちほとんどはウィキデータから供給されている。リンクが双方向的でないまれな例で必要になった場合、項目内に独自のリンクを追加することは今でも可能だ。ウィキデータが同一の主題についてのページをつなぐ設計にあっているのに対して、他言語のより広い意味の項目を参照する項目も一部にあるのである。言語リンクを移入することにより、ウィキデータは実際のウィキペディアページへの「足がかり」のあるアイテムの巨大な集合を得た。

Simple Data (Properties and Values)

単純なデータ（プロパティと値）

To store structured data beyond text labels and language links, Wikidata uses a simple data model. Data is basically described through property-value pairs; for example, the item for "Rome" might have a property "population" with value "2,777,979." Properties are objects and have their own Wikidata pages with labels, aliases, and descriptions. Unlike items, however, these pages are not linked to Wikipedia articles.

テキストのラベルと言語リンクを超えた構造化データを格納するため、ウィキデータは単純なデータモデルを使う。データは原則として、プロパティと値の対をとおして記述される。たとえば、「ローマ」は「人口」のプロパティを持ち、その値として「2777979」を持つことができる。プロパティはオブジェクトであり、個別にウィキデータのページを持ち、そこにはラベル、別名、説明がある。アイテムとは違い、これらのページはウィキペディア項目にリンクされない。

On the other hand, property pages always specify a datatype that defines which type of values the property can have. "Population" is a number; "has father" relates to another Wikidata item; and "postal code" is a string. This information is important for providing adequate user interfaces and ensuring the validity of inputs. There are only a small number of datatypes, mainly quantity, item, string, date and time, geographic coordinates, and URL. Data is international, though its display may be language-dependent; for example, the number 1,003.5 is written "1.003,5" in German and "1 003.5" in French.

その一方で、プロパティのページでは、その値がとりうる値の型を定義するデータ型が常に指定される。「人口」は数値、「父」は別のウィキデータアイテムへの関連づけ、「郵便番号」は文字列だ。この情報は適切なユーザーインターフェイスを提供するとともに入力の妥当性を確保するために重要だ。データ型の数は少ない。おもに量、アイテム、文字列、日付と時刻、地図座標、URL だ。データは国際的だが、表示は言語依存になりうる。たとえば、数値 1003.5 はドイツ語では「1.003,5」、フランス語では「1 003.5」と書かれる。

Not-So-Simple Data

単純でないデータ

Property-value pairs are too simple in many cases; for example, Wikipedia says the population of Rome was 2,651,040 "as of 2010" based on "estimations" published by the National Institute for Statistics, or Istat, in Italy (http://www.istat.it/); see Figure 1 for how Rome statistics can be represented in Wikidata. Even leaving source information aside, the information cannot be expressed easily in property-value pairs. One could use a property "estimated population in 2010" or create an item "Rome" in 2010 to specify a value for its "estimated population." However, either solution is clumsy and impractical. As suggested by Figure 1, we would like the data to contain a property "as of" with value "2010" and a property "method" with value "estimation." These property-value pairs do not refer to Rome but to the assertion that Rome has a population of 2,651,040. We thus arrive at a model where the property-value pairs assigned to items can have additional subordinate property-value pairs we call "qualifiers."

プロパティと値の対では多くの場合単純すぎる。たとえば、ウィキペディアは「2010年時点」のローマの人口をイタリアの国立統計学研究所 (Istat) の発表した「推計」によって265万1040としている。図1に、ローマの人口統計がどうウィキデータであらわされるかを示した。典拠情報を別としても、プロパティと値の対でこの情報を表現するのは簡単ではない。「2010年の推計人口」というプロパティを使ったり、「2010年のローマ」（ERRATA "Rome in 2010"）というアイテムを作り「推計人口」の値を指定したりすることはできる。しかし、どちらの解法も不恰好で非実際的だ。図1に示したように、このデータには「2012」という値のある「時点」というプロパティを入れ、「推計」という値のある「手法」というプロパティを入れるほうが好ましい。こうしたプロパティと値の対はローマに言及するのではなく、ローマに265万1040人の人口があるという主張に言及する。これにより、アイテムに付与されたプロパティと値の対が副次的なプロパティと値の対を持てる（これを「限定子」と呼ぶ）モデルに到達する。

Qualifiers can be used to state contextual information (such as the validity time for an assertion). They can also be used to encode ternary relations that elude the property-value model; for example, to say Meryl Streep played Margaret Thatcher in the movie The Iron Lady, one could add to the item of the movie a property "cast member" with value "Meryl Streep" and an additional qualifier "role = Margaret Thatcher."

限定子は（主張が成立する期間など）文脈情報を述べるのにも使える。プロパティ・値のモデルを超える三項関係を符号化するのにも使える。たとえば、メリル・ストリープが映画『鉄の女の涙』でマーガレット・サッチャーを演じたというとき、映画のアイテムに「出演者」のプロパティに「メリル・ストリープ」の値をつけて入れ、「役柄 = マーガレット・サッチャー」という限定子をつけることができる。

Such qualifiers illustrate why we adopted an extensible set of qualifiers instead of restricting ourselves to the most common qualifiers (such as for temporal information). Qualifiers in their current form are indeed an almost direct representation of data found in Wikipedia infoboxes. This solution resembles known approaches to representing context information.2728 It should not, however, be misunderstood as a workaround to represent relations of higher arity in graph-based data models, since Wikidata statements do not have a fixed (or even bounded) arity in this sense.29

このような限定子は、もっともよくある限定子（時間的情報など）だけでなく、限定子の拡張可能な集合を我々が採用したのはなぜかのよい例だ。いまある姿での限定子はまさにウィキペディアのインフォボックスでみられるデータのほぼ直接的な表現だ。この解法は文脈情報を表現する既存のアプローチと似ている3031。ただし、これは、グラフベースのモデルにあるような、多引数の関係を表現するためのその場しのぎの方法として誤解されるべきではない。ウィキデータのステートメントに、この意味での固定された（あるいは上界のある）引数の数はない32。

Wikidata also allows for two special types of statements: First, it is possible to specify that the value of a property is unknown; for example, one can say Ambrose Bierce's day of death is unknown rather than not say anything about it, clarifying he is certainly not among the living. Second, one can say a property has no value at all (such as in asserting Australia has no countries sharing its borders). It is important to distinguish this situation from the common case that information is simply incomplete. It would be wrong to consider these two cases as special values, becoming clear when considering queries that ask for items sharing the same value for a property; otherwise, one would have to conclude Australia and Iceland have a common neighbor.

ウィキデータは2種の特殊なステートメントを許容する。1つ目として、プロパティの値が未知だと指定することができる。たとえば、アンブローズ・ビアスの死亡日について、何も言わないかわりに未知だと言うことによって、彼が確実に生きていないということを明確にできる。2つ目として、プロパティの値がまったくないとも言える（たとえばオーストラリアはどの国とも国境を接していないと主張する場合など）。情報が不完全であるというよくある場合とこの状況とを区別することは重要だ。この2つの場合を特殊な値としてあつかうことは、同一の値を共有するアイテムをきく質問を想定してみればあきらかなように、間違いだ。このようにしておかなければ、オーストラリアとアイスランドが共通の隣人をもつと結論づけてしまう。

Further details on the Wikidata data model and its expression in Web Ontology Language in Resource Description Framework, or OWL/RDF, can be found in Erxleben et al. 33

ウィキデータのデータモデルおよび Web Ontology Language in Resource Description Framework (OWL/RDF) におけるその表現についての詳細は、Erxleben et al 34にある。

Citation Needed

要出典

Property assertions, possibly with qualifiers, provide a rich structure for expressing arbitrary claims. In Wikidata, every such claim can include a list of references to sources that support the claim. Including references agrees with Wikipedia's goal of being a secondary (or tertiary) source that does not publish its own research but rather gathers information published in other primary (or secondary) sources.

場合によって限定子をつけながらプロパティを宣言することは、あらゆる主張を表現するための豊かな構造を提供する。ウィキデータでは、そういった主張ひとつひとつに、その主張を支持する情報源への参照のリストをつけることができる。参考文献をつけることは、独自の研究結果を発表せず、ほかの一次（あるいは二次）情報源で発表された情報をまとめる二次（あるいは三次）情報源になるというウィキペディアの目標に適合する。

There are many ways to specify a reference, depending on whether it is a book, a curated database, a website, or something else entirely. Moreover, some sources may be represented by Wikidata items, while others are not. In this light, a reference is simply a list of property-value pairs, leaving the details of reference modeling to the community. Note Wikidata does not automatically record provenance35 but does provide for the structural representation of references.

参考文献を示す方法は多数あり、それが本であるか、編纂されたデータベースであるか、ウェブサイトであるか、まったく別の何かであるかによって違う。さらに、対応するウィキデータのアイテムがある情報源もあり、そうでない情報源もある。こうした点を踏まえて、参考文献は単純にプロパティと値の対のリストになっており、参考文献のモデル化の詳細はコミュニティにゆだねられている。ウィキデータは自動的に出所36を記録はしないが、参考文献を示すための構造的表現方法を提供することに注意してほしい。

Sources are also important as context information. Different sources often make contradictory claims, yet Wikidata intends to represent all views rather than choose one "true" claim. Combined with the context information provided by qualifiers (such as for temporal context), many statements could be stored about a single property (such as population). To help manage this plurality, Wikidata allows contributors to optionally mark statements as "preferred" (for the most relevant, current statements) or "deprecated" (for irrelevant or unverified statements). Deprecated statements may be useful to Wikidata editors, to record erroneous claims of certain sources or to keep statements that still need to be improved or verified. As with all Wikidata content, these classifications are subject to community-governed editorial processes, similar to those of Wikipedia. 37

情報源は文脈情報としても重要だ。異なる情報源が矛盾する主張をすることはよくあるが、ウィキデータはひとつの「真の」主張を選ぶのではなく、すべての観点を表現することを意図する。限定子によって提供される（時間的文脈などの）文脈情報を合わせることで、ひとつのプロパティ（たとえば人口）について多数の主張が保持できる。この多極性を管理する助けとして、ウィキデータは、投稿者があるステートメントを「優先」（もっとも重要で、最新のステートメントにこれをつける）、あるいは「非推奨」（あまり重要でない、または検証されていないステートメントにこれをつける）と印づけできるようにしている。非推奨のステートメントはウィキデータ編集者らにとっては、一部の情報源による誤った主張を記録したり、今後改善または検証される必要のあるステートメントを保持するためなどに、利用価値があるかもしれない。ウィキデータの全コンテンツそうであるように、こうした分類は、ウィキペディアと同様のコミュニティに統治された編集プロセス 38にゆだねられている。

Wikidata by the Numbers

数値でみるウィキデータ

Wikidata has grown significantly since its launch in October 2012; see the table here for key facts about its current content. It has also become the most edited Wikimedia project, with 150–500 edits per minute, or a half million per day, about three times as many as the English Wikipedia. Approximately 90% of these edits are made by bots contributors create for automating tasks, yet almost one million edits per month are still made by humans. Figure 2a shows the number of human edits during 14-day intervals. We highlight contributions of power users with more than 10 or even 100,000 edits, respectively, as of February 2014, as they account for most of the variation. The increase in March 2013 marked the official announcement of the site.

ウィキデータは2012年10月の公開以来顕著な成長をしてきた。この表を見ると現状のコンテンツに関する主な事実が分かる。ウィキデータはウィキメディアプロジェクトのなかでもっとも多く編集されるプロジェクトになった。1分間に150回から500回、1日に50万回編集されており、この数は英語版ウィキペディアのおよそ3倍だ。これら編集のうちほぼ90%は作業自動化のためにつくられた(ERRATA contributors created for)ボット投稿者による編集だが、1ヶ月にほぼ100万回の編集は人間によってなされている。図 2a は14日間の期間内の人間の編集回数を示している。10回以上（人によって10万回以上）編集しているパワーユーザーによる投稿があることを強調する。

Figure 2b shows the growth of Wikidata from its launch until February 2014. There were approximately 14.5 million items and 36 million language links. Essentially, every Wikipedia article is connected to a Wikidata item today, so these numbers grow slowly. In contrast, the number of labels, 45.6 million, as of February 2014, continues to grow; there are more labels than Wikipedia articles. Almost 10 million items have statements, and more than 30 million statements were created using more than 900 different properties. As expected, property use is skewed; the most frequent property is "instance of" P31 (5.6 million uses) for classifying items; one of the least-frequent properties is P485 (133 uses), which connects a topic (such as Johann Sebastian Bach) with the institution that archives the topic (such as the Bach-Archiv in Leipzig).

図 2b はウィキデータ公開から2014年2月までの成長を示している。1450万のアイテムと3600万の言語間リンクがある。現在では事実上全ウィキペディア項目がウィキデータに接続されているため、その数はゆっくり増えるようになっている。対照的に、ラベルの数は2014年2月時点で4560万であり、成長しつづけている。ラベルはウィキペディア項目より多い。ほぼ1000万アイテムにステートメントがあり、3000万ステートメント以上が900の異なるプロパティを使って作られている。予想されるようにプロパティの使用にはかたよりがある。もっともよく使われるのはアイテムを分類するためのP31、 「is instance of（以下の実体）」（560万箇所で使用）だ。もっとも使用箇所の少ないもののひとつはトピック（たとえばヨハン・ゼバスティアン・バッハ）と施設（たとえばライプチヒのバッハアーキフ）をつなぐ P485 だ。

The Web of Data

データのウェブ

One promising development in Wikidata is the volunteer community's reuse and integration of external identifiers from existing databases and authority controls, including the International Standard Name Identifier, or ISNI, China Academic Library and Information System, or CALIS, International Air Transport Association, or IATA, MusicBrainz for albums and performers, and North Atlantic Basin's Hurricane Database, or HURDAT. These external IDs allow applications to integrate Wikidata with data from other sources that remain under the control of the original publisher.

ウィキデータの発展のなかで有望なのはボランティア・コミュニティが外部の識別子を外部データベースと典拠コントロールから再利用し統合していることだ。そのなかには国際標準名称識別子（ISNI）、中国高等教育文献保障系統（CALIS）、国際航空運送協会（IATA）、アルバムと演奏者の MusicBrainz 、北大西洋海域ハリケーン・データベース（HURDAT）などがある。こうした外部識別子により、原発行者がコントロールする他の情報源とウィキデータとを統合するアプリケーションをつくれるようになる。

Wikidata is not the first project to reconcile identifiers and authority files from different sources. Others include the Virtual International Authority File, or VIAF, in the bibliographic domain, 39 GeoNames in the geographical domain,40 and Freebase. 41 Wikidata is linked to many of these projects yet also differs in terms of scope, scale, editorial processes, and author community.

ことなる情報源から典拠ファイルと識別子をまとめるプロジェクトはウィキデータがはじめてではない。書誌分野ではバーチャル国際典拠ファイル（VIAF）42、地理分野では GeoNames43、ほかに Freebase 44 がある。ウィキデータはこれらの多くにリンクしている一方で、収録範囲、規模、編集過程、投稿者コミュニティに違いがある。

The collected data is exposed in various ways; for example, current per-item exports are available in JSON, XML, RDF, and several other formats. Full database dumps are created at intervals and supplemented by daily diffs. All data is licensed under a Creative Commons CC0 license, thus putting the data in the public domain.

収集されたデータは様々な形で露出している。たとえば現在アイテムごとのエクスポートはJSON、XML、RDF、ほかいくつかの形式で提供されている。全体のデータベースダンプが定期的に作成され、毎日の差分で補完されている。全データがクリエイティブ・コモンズ CC0 ライセンスで使用許諾され、パブリックドメインにおかれている。

Every Wikidata entity is identified by a unique URI (such as http://www.wikidata.org/entity/Q42 for item Q42, Douglas Adams). By resolving this URI, tools are able to obtain item data in the requested format (through content negotiation). This follows Linked Data standards for data publication,45 making Wikidata part of the Semantic Web, 4647 while supporting integration of other semantic Web data sources with Wikidata.

ウィキデータのエンティティはすべてユニークなURIで識別される（たとえばダグラス・アダムズのアイテム Q42 は http://www.wikidata.org/entity/Q42 ）。URIを解決することにより、ツールは（コンテントネゴシエーションを使って）要求した形式でアイテムのデータを取得できる。これはデータ出版のためのリンクトデータの標準48に従ったものであり、ウィキデータをセマンティック・ウェブ4950の一部にし、ほかのセマンティック・ウェブのデータ源との統合を助けている。

Wikidata Applications

ウィキデータの応用

The data in Wikidata lends itself to manifold applications on very different levels of data integration.

ウィキデータにあるデータはことなるレベルのデータ統合に関して多様なアプリケーションに役立つ。

Language labels and descriptions. Wikidata provides labels and descriptions for many terms in different languages, possibly using them to present information to international audiences. Unlike common dictionaries, Wikidata covers many named entities (such as for places, chemicals, plants, and specialist terms) that may be very difficult to translate. Many data-centric views can be translated trivially term by term—think maps, shopping lists, and ingredients of dishes on a menu—assuming all items are associated with suitable Wikidata IDs. The open source JavaScript library qLabel (http://googleknowledge.github.io/qLabel/) provides this functionality for any website.

言語ラベルと説明。ウィキデータはことなる言語での多数の用語にラベルと説明を提供する。これは情報を国際的な受け手に提示するために使うことができる。普通の辞書とはちがってウィキデータは翻訳がむずかしいことのある固有名詞（地名、化学物質、植物、専門用語など）を多数収録している。データ中心的な表示のおおくは自明なやりかたで用語から用語へと翻訳できる。たとえば、適切なウィキデータIDが関連づけられたとして、地図、買い物リスト、メニュー上の料理の成分表示などだ（アイテムがすべて適切なウィキデータIDに関連付けられたとして）。オープンソースの JavaScript ライブラリ qLabel (http://googleknowledge.github.io/qLabel/) でこの機能があらゆるウェブサイトに提供される。

Identifier reuse. Item IDs can be used as language-independent identifiers to facilitate data exchange and integration across application boundaries. Referring to Wikidata items, applications can provide unambiguous definitions for the terms they use that are also the entry points to a wealth of related information. Wikidata IDs thus resemble digital object identifiers, or DOIs, but emphasize (meta)data beyond online document locations and use another social infrastructure for ID assignment. Wikidata IDs are stable: IDs do not depend on language labels; items can be deleted, though IDs are never reused; and the links to other datasets and sites further increase stability. Besides providing a large collection of IDs, Wikidata also provides the means to support contributors in selecting the right ID by displaying labels and descriptions; external applications can use the same functionality through the same API.

識別子の再利用。アイテムIDは言語非依存の識別子として利用でき、アプリケーションの境界をこえたデータ交換と統合を支援できる。ウィキデータのアイテムを参照することで、アプリケーションは用語に曖昧性のない定義をあたえることができ、その定義はゆたかな関連情報へのいりぐちともなる。この意味でウィキデータIDはデジタルオブジェクト識別子（DOI）と似ているが、文書のオンラインでの位置をこえた（メタ）データを強調しID付与のためのもうひとつの社会的基盤を使う。ウィキデータIDは安定している。つまり、言語ラベルに依存しておらず、削除はされることがあるが再利用されることはなく、ほかのデータセットへのリンクによりさらに安定性が高められる。多数のIDの集合を提供するほか、ウィキデータは投稿者が適切なIDを選ぶのを支援する手段としてラベルと説明を表示する機能を提供する。この同じ機能を外部アプリケーションも使うことができる。

Wikidata allows conflicting data to coexist and provides mechanisms to organize this plurality. ウィキデータは競合するデータを共存させることができ、この plurality を整理する仕組みを提供する。

Accessing Wikidata. The information collected by Wikidata is interesting in its own right, and many applications can be built to access it more conveniently and effectively. Applications created as of early 2014 included generic data browsers like the one in Figure 3 and special-purpose tools, including two genealogy viewers, a tree of life, a table of the elements, and various mapping tools. Applications can use the Wikidata API to browse, query, and even edit data. If simple queries are not enough, a dedicated copy of the data is needed; that copy can be obtained from regular dumps and possibly be updated in real time by mirroring edits on Wikidata. The Wikidata Toolkit, an open source Java library (https://www.mediawiki.org/wiki/Wikidata_Toolkit), provides convenient access to the dumps.

ウィキデータへのアクセス。ウィキデータが収集する情報はそれ単体で興味深く、そのアクセスを便利かつ効果的にするための多くの応用がありうる。2014年初頭までにつくられたアプリケーションには、図3 のような汎用データブラウザ、年表ビューア・生物系統樹・元素表・多様な地図ツールなど特殊目的のツールがある。アプリケーションはウィキデータAPIを使ってデータを閲覧、検索、さらに編集することさえできる。単純なクエリで不十分な場合、データの複製をとりよせる必要がある。複製は定期的なダンプで入手でき、リアルタイムのウィキデータの編集を反映することで更新することも可能だ。オープンソースの Java ライブラリ Wikidata Toolkit (https://www.mediawiki.org/wiki/Wikidata_Toolkit) はダンプへの便利なアクセスを提供する。

Enriching applications. Many applications can be enriched by embedding information from Wikidata directly into their interfaces; for example, a music player might want to fetch the portrait of the artist just being played in the audio file. Unlike earlier uses of Wikipedia data (such as in Google Maps), application developers need not extract and maintain the data themselves. Such lightweight data access is particularly attractive for mobile apps. In other cases, application developers preprocess data to integrate it into their applications; for example, it would be easy to extract a file of all German cities, together with their regions and post-code ranges, that could then be used in an application. Such derived data can be used and redistributed online or in software under any license, even in commercial contexts.

アプリケーションをリッチにする。ウィキデータから取得した情報をインターフェイスにうめこむことによってリッチになるアプリケーションは多い。たとえば、音楽プレイヤーは再生中の音楽ファイルのアーティストの写真を取得したいかもしれない。（たとえばグーグルマップなどでの）以前のウィキペディアのデータの利用とはことなり、アプリケーション開発者はデータを抽出し保守する必要がない。こうした軽量データアクセスはモバイルアプリに特に魅力的だ。ほかの場合、アプリケーション開発者はデータを前処理してアプリケーションに統合する。たとえば、あとでアプリケーション内で使うためにドイツの全都市をその地域と郵便番号つきでファイルにして抽出するは容易だ。こうした派生データはオンラインまたはソフトウェア内で、商業用途を含むあらゆるライセンスで使用・再配布することができる。

Advanced analytics. Information in Wikidata can be further analyzed to derive new insights beyond what is already revealed on the surface. An important approach in this regard is logical reasoning, where information about general relationships is used to derive additional facts; for example, Wikidata's property "grandparent" is obsolete, since its value can be inferred from values of properties "father" and "mother." If an application developer is generally interested in ancestors, then a transitive closure must be computed. Such a closure is relevant for many hierarchical, spatial, and partonomical relations. Other types of advanced analytics include statistical evaluations of both the data and the incidental metadata collected in the system; for example, a researcher can readily analyze article coverage by language,51 as well as the gender balance of persons described in Wikipedia articles.52 As in Wikipedia, Wikidata provides plenty of material for researchers to study.

高度な分析。ウィキデータの情報は表面的にあきらかになっている以上のあたらしい洞察をひきだすためにさらに分析することができる。重要なアプローチのひとつは論理的推論により、一般的な複数の関係を使ってファクトを導きだすことだ。たとえば、ウィキデータのプロパティ「祖父または祖母」は、「父」「母」のプロパティから推論できる値であるため、廃止された。アプリケーション開発者が家系図一般に興味をもっているなら、推移的閉包を計算しなければならない。こういった閉包は階層的・空間的・部分全体的な関係について重要だ。高度な分析の他の種類にはデータや付随してシステムに収集されたメタデータの統計的評価だ。たとえば、研究者は言語ごとの項目のカバー率53、ウィキペディアに記述された人物のジェンダーの均衡度合い54などを容易に分析できる。ウィキペディアとおなじように、ウィキデータは豊富な研究素材を研究者に提供する。

These are only the most obvious approaches to exploiting the data, and many as-yet unforeseen uses should be expected. Wikidata is young, and its data is far from complete. We look forward to new and innovative applications due to Wikidata and its development as a knowledgebase.55

以上はデータを利用するもっとも明白なアプローチのいくつかにすぎず、まだ知られていない利用法が多数期待される。ウィキデータは若く、そのデータは完全にはほどとおい。ウィキデータと知識ベースとしてのその発展から新しく革新的なアプリケーションが現れることを楽しみにしている56。

Prospects

展望

Features still missing include support for complex queries, which is now under development. However, in trying to predict the future of Wikidata, the development team's plans are probably less important than one would expect; for example, the biggest open questions concern the evolution and interplay of the many Wikimedia communities. Will Wikidata earn their trust? How will each of them, with its own language and culture, access, share, and co-evolve the way Wikidata is structured? And how will Wikidata respond to the demands of the communities beyond Wikipedia?

複雑なクエリのサポート（開発中）などいくつかの機能がウィキデータには欠けている。しかし、ウィキデータの将来を予測しようとするとき、開発チームの計画は思われるほどに重要ではない。たとえば、もっとも大きな未解決問題は多数のウィキメディアコミュニティの進化と相互作用に関連する。ウィキデータは彼らの信頼をえられるか？ それぞれ言語・文化のある個々のコミュニティがどのようにしてウィキデータの構造へとアクセス・共有・共進化していくのか？ ウィキペディアをこえたコミュニティの要望にウィキデータはどう答えるのか？

The influence of the volunteer community extends to technical development of the website and its underlying software. Wikidata is based on an open development process that invites contributions, while the site itself provides many extension points for user-created add-ons. The community has designed and developed features (such as article badges for featured articles, image embedding and multi-language editing). The community has also developed ways to enrich the semantics of properties by encoding (soft) constraints, as reflected in the guideline "Items should have no more than one birthplace." External tools gather this information, analyze the dataset for constraint violations, and publish the list of violations on Wikidata to allow editors to check if they are valid exceptions or errors.

ボランティアコミュニティの影響はウェブサイトとその下にあるソフトウェアの技術的発展にもおよぶ。ウィキデータは貢献を歓迎するオープンな開発プロセスにもとづいており、利用者が製作するアドオンのための拡張箇所がサイトそのものにも多数ある。コミュニティは複数の機能（たとえば秀逸な項目につけるバッジ、画像うめこみ、多言語編集など）を設計し開発した。コミュニティはプロパティの意味論をリッチにするために（ソフトな）制約をエンコードする方法を開発した。これは「アイテムはたかだか一つしか生誕地をもてない」というガイドラインに反映されている。外部ツールがこの情報を集約し、データセットを分析して制約違反をみつけ、ウィキデータに違反のリストを公開し、それらが正当な例外なのか誤りなのかを編集者がチェックできるようにしている。

These aspects of the Wikidata development process illustrate the close relationships among technical infrastructure, editorial processes, and content and the pivotal role the community plays in shaping Wikidata. However, the community is as dynamic as Wikidata itself, based not on status or membership but on the common goal of turning Wikidata into the most accurate, useful, and informative resource possible. This goal promises stability and continuity, even as it allows anyone to take part in defining the future of Wikidata.

ウィキデータ開発プロセスのこのような側面は技術基盤・編集プロセス・コンテンツ、およびウィキデータを形成する上でコミュニティがはたす重要な役割の密な関係を示している。しかし、コミュニティはウィキデータそのものとおなじように動的であり、地位や所属ではなく、ウィキデータを可能なかぎりもっとも正確・有用・情報量のある資源にしようとの目標にもとづいている。だれにでもウィキデータの将来をかたちづくることを許しながらも、この目標は安定性と連続性を約束する。

Wikipedia is by all accounts one of the most important websites today, a legacy Wikidata must live up to. In only two years, Wikidata is already an important platform for integrating information from many sources. In addition, it also aggregates large amounts of incidental metadata about its own evolution and contribution to Wikipedia. Wikidata thus has the potential to be a major resource for both research and development of new and improved applications. Wikidata, the free knowledgebase anyone can edit, may thus bring us all one step closer to a world that freely shares in the sum of all knowledge.

ウィキペディアは今日あらゆる意味でもっとも重要なウェブサイトのひとつであり、ウィキデータがうけつぐべき遺産のひとつだ。わずか2年で、ウィキデータはすでに多数の情報源からの情報を統合する重要なプラットフォームになった。くわえて、ウィキデータはそれ自身の進化とウィキペディアへの貢献に付随するメタデータを大量に集約している。このためウィキデータは新しく改善されたアプリケーションの研究にも開発にも主要な資源となる可能性がある。だれでも編集できる知識ベースであるウィキデータは、あらゆる知識の集合を自由に共有する世界へとわたしたちを一歩ちかづけてくれるのではないだろうか。

Acknowledgments

謝辞

The development team's work on Wikidata is funded through donations by the Allen Institute of Artificial Intelligence, Google, the Gordon and Betty Moore Foundation, and Yandex. Markus Krotzsch's research is supported by the German Research Foundation through the Data Integration and Access by Merging Ontologies and Databases, or DIAMOND, project (Emmy Noether grant KR 4381/1-1).

ウィキデータ開発チームの業務の資金は the Allen Institute of Artificial Intelligence, Google、the Gordon and Betty Moore Foundation、Yandex からの寄付によってまかなわれた。Markus Krotzsch の研究は Data Integration and Access by Merging Ontologies and Databases (DIAMOND) プロジェクト (Emmy Noether grant KR 4381/1-1) を通してドイツ研究振興協会に支援された。

Wikidata entity id

Wikidata エンティティ ID

This article has subsequently received its own Wikidata item Q18507561, which can be used, e.g., within references on Wikidata.

本稿はその後ウィキデータでアイテムQ18507561が割り振られた。このIDはウィキデータ内で情報源指定等に使うことができる。

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Peter Buneman , James Cheney , Wang-Chiew Tan , Stijn Vansummeren, Curated databases, Proceedings of the twenty-seventh ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376916.1376918↩

Peter Buneman , James Cheney , Wang-Chiew Tan , Stijn Vansummeren, Curated databases, Proceedings of the twenty-seventh ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376916.1376918↩

Bo Leuf , Ward Cunningham, The Wiki way: quick collaboration on the Web, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 2001↩

Bo Leuf , Ward Cunningham, The Wiki way: quick collaboration on the Web, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 2001↩

Markus Krötzsch , Denny Vrandečić , Max Völkel , Heiko Haller , Rudi Studer, Semantic Wikipedia, Web Semantics: Science, Services and Agents on the World Wide Web, v.5 n.4, p.251-261, December, 2007 http://doi.org/10.1016/j.websem.2007.09.001↩

Daniel J. Barrett, MediaWiki, O'Reilly Media, Inc., 2008↩

Daniel J. Barrett, MediaWiki, O'Reilly Media, Inc., 2008↩

Markus Krötzsch , Denny Vrandečić , Max Völkel , Heiko Haller , Rudi Studer, Semantic Wikipedia, Web Semantics: Science, Services and Agents on the World Wide Web, v.5 n.4, p.251-261, December, 2007 http://doi.org/10.1016/j.websem.2007.09.001↩

Douglas B. Lenat , R. V. Guha, Building Large Knowledge-Based Systems; Representation and Inference in the Cyc Project, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1989↩

Kurt Bollacker , Colin Evans , Praveen Paritosh , Tim Sturge , Jamie Taylor, Freebase: a collaboratively created graph database for structuring human knowledge, Proceedings of the 2008 ACM SIGMOD international conference on Management of data, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376616.1376746↩

Douglas B. Lenat , R. V. Guha, Building Large Knowledge-Based Systems; Representation and Inference in the Cyc Project, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1989↩

Kurt Bollacker , Colin Evans , Praveen Paritosh , Tim Sturge , Jamie Taylor, Freebase: a collaboratively created graph database for structuring human knowledge, Proceedings of the 2008 ACM SIGMOD international conference on Management of data, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376616.1376746↩

Christian Bizer , Jens Lehmann , Georgi Kobilarov , Sören Auer , Christian Becker , Richard Cyganiak , Sebastian Hellmann, DBpedia - A crystallization point for the Web of Data, Web Semantics: Science, Services and Agents on the World Wide Web, v.7 n.3, p.154-165, September, 2009↩

Johannes Hoffart , Fabian M. Suchanek , Klaus Berberich , Gerhard Weikum, YAGO2: A spatially and temporally enhanced knowledge base from Wikipedia, Artificial Intelligence, 194, p.28-61, January, 2013 http://doi.org/10.1016/j.artint.2012.06.001↩

Christian Bizer , Jens Lehmann , Georgi Kobilarov , Sören Auer , Christian Becker , Richard Cyganiak , Sebastian Hellmann, DBpedia - A crystallization point for the Web of Data, Web Semantics: Science, Services and Agents on the World Wide Web, v.7 n.3, p.154-165, September, 2009↩

Johannes Hoffart , Fabian M. Suchanek , Klaus Berberich , Gerhard Weikum, YAGO2: A spatially and temporally enhanced knowledge base from Wikipedia, Artificial Intelligence, 194, p.28-61, January, 2013 http://doi.org/10.1016/j.artint.2012.06.001↩

Wolfram Research. Wolfram Alpha (launched 2009); https://www.wolframalpha.com↩

Tunstall-Pedoe, W. True Knowledge: Open-domain question answering using structured knowledge and inference. AI Magazine 31, 3 (Fall 2010), 80--92.↩

Ferrucci, D.A., Brown, E.W., Chu-Carroll, J., Fan, J., Gondek, D., Kalyanpur, A., Lally, A., Murdock, J.W., Nyberg, E., Prager, J.M., Schlaefer, N., and Welty, C.A. Building Watson: An overview of the DeepQA project. AI Magazine 31, 3 (Fall 2010), 59--79.↩

Wolfram Research. Wolfram Alpha (launched 2009); https://www.wolframalpha.com↩

Tunstall-Pedoe, W. True Knowledge: Open-domain question answering using structured knowledge and inference. AI Magazine 31, 3 (Fall 2010), 80--92.↩

Ferrucci, D.A., Brown, E.W., Chu-Carroll, J., Fan, J., Gondek, D., Kalyanpur, A., Lally, A., Murdock, J.W., Nyberg, E., Prager, J.M., Schlaefer, N., and Welty, C.A. Building Watson: An overview of the DeepQA project. AI Magazine 31, 3 (Fall 2010), 59--79.↩

Guha, R.V., McCool, R., and Fikes, R. Contexts for the Semantic Web. In Proceedings of the Third International Semantic Web Conference, Vol. 3298 of LNCS, S.A. McIlraith, D. Plexousakis, and F. van Harmelen, Eds. (Hiroshima, Japan, Nov. 7--11). Springer, Berlin, 2004, 32--46.↩

MacGregor, R.M. Representing reified relations in Loom. Journal of Experimental and Theoretical Artificial Intelligence 5, 2--3 (1993), 179--183.↩

Noy, N. and Rector, A., Eds. Defining N-ary Relations on the Semantic Web. W3C Working Group Note, Apr. 12, 2006; http://www.w3.org/TR/swbp-n-aryRelations/↩

Guha, R.V., McCool, R., and Fikes, R. Contexts for the Semantic Web. In Proceedings of the Third International Semantic Web Conference, Vol. 3298 of LNCS, S.A. McIlraith, D. Plexousakis, and F. van Harmelen, Eds. (Hiroshima, Japan, Nov. 7--11). Springer, Berlin, 2004, 32--46.↩

MacGregor, R.M. Representing reified relations in Loom. Journal of Experimental and Theoretical Artificial Intelligence 5, 2--3 (1993), 179--183.↩

Noy, N. and Rector, A., Eds. Defining N-ary Relations on the Semantic Web. W3C Working Group Note, Apr. 12, 2006; http://www.w3.org/TR/swbp-n-aryRelations/↩

Erxleben, F., Günther, M., Krötzsch, M., Mendez, J., and Vrandečić, D. Introducing Wikidata to the Linked Data Web. In Proceedings of the 13th International Semantic Web Conference (Trentino, Italy, Oct. 19--23). Springer, Berlin, 2014.↩

Erxleben, F., Günther, M., Krötzsch, M., Mendez, J., and Vrandečić, D. Introducing Wikidata to the Linked Data Web. In Proceedings of the 13th International Semantic Web Conference (Trentino, Italy, Oct. 19--23). Springer, Berlin, 2014.↩

Luc Moreau, The Foundations for Provenance on the Web, Foundations and Trends in Web Science, v.2 n.2–3, p.99-241, February 2010 http://doi.org/10.1561/1800000010↩

Luc Moreau, The Foundations for Provenance on the Web, Foundations and Trends in Web Science, v.2 n.2–3, p.99-241, February 2010 http://doi.org/10.1561/1800000010↩

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Ayers, P., Matthews, C., and Yates, B. How Wikipedia Works: And How You Can Be a Part of It. No Starch Press, San Francisco, CA, 2008.↩

Bennett, R., Hengel-Dittrich, C., O'Neill, E.T., and Tillett, B.B. VIAF (Virtual International Authority File): Linking Die Deutsche Bibliothek and Library of Congress name authority files. In Proceedings of the World Library and Information Congress 72nd General Conference and Council (Seoul, South Korea, Aug. 20--24). IFLA, Den Haag, The Netherlands, 2006.↩

Unxos GmbH. GeoNames (launched 2005); http://www.geonames.org↩

Kurt Bollacker , Colin Evans , Praveen Paritosh , Tim Sturge , Jamie Taylor, Freebase: a collaboratively created graph database for structuring human knowledge, Proceedings of the 2008 ACM SIGMOD international conference on Management of data, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376616.1376746↩

Bennett, R., Hengel-Dittrich, C., O'Neill, E.T., and Tillett, B.B. VIAF (Virtual International Authority File): Linking Die Deutsche Bibliothek and Library of Congress name authority files. In Proceedings of the World Library and Information Congress 72nd General Conference and Council (Seoul, South Korea, Aug. 20--24). IFLA, Den Haag, The Netherlands, 2006.↩

Unxos GmbH. GeoNames (launched 2005); http://www.geonames.org↩

Kurt Bollacker , Colin Evans , Praveen Paritosh , Tim Sturge , Jamie Taylor, Freebase: a collaboratively created graph database for structuring human knowledge, Proceedings of the 2008 ACM SIGMOD international conference on Management of data, June 09-12, 2008, Vancouver, Canada http://doi.org/10.1145/1376616.1376746↩

Bizer, C., Heath, T., and Berners-Lee, T. Linked data: The story so far. International Journal on Semantic Web and Information Systems 5, 3 (2009), 1--22.↩

Berners-Lee, T., Hendler, J., and Lassila, O. The Semantic Web. Scientific American (May 2001), 96--101.↩

Erxleben, F., Günther, M., Krötzsch, M., Mendez, J., and Vrandečić, D. Introducing Wikidata to the Linked Data Web. In Proceedings of the 13th International Semantic Web Conference (Trentino, Italy, Oct. 19--23). Springer, Berlin, 2014.↩

Bizer, C., Heath, T., and Berners-Lee, T. Linked data: The story so far. International Journal on Semantic Web and Information Systems 5, 3 (2009), 1--22.↩

Berners-Lee, T., Hendler, J., and Lassila, O. The Semantic Web. Scientific American (May 2001), 96--101.↩

Erxleben, F., Günther, M., Krötzsch, M., Mendez, J., and Vrandečić, D. Introducing Wikidata to the Linked Data Web. In Proceedings of the 13th International Semantic Web Conference (Trentino, Italy, Oct. 19--23). Springer, Berlin, 2014.↩

Scott A. Hale, Multilinguals and Wikipedia editing, Proceedings of the 2014 ACM conference on Web science, June 23-26, 2014, Bloomington, Indiana, USA http://doi.org/10.1145/2615569.2615684↩

Klein, M. and Kyrios, A. VIAFbot and the integration of library data on Wikipedia. code{4}lib Journal 22 (Oct. 2013); http://journal.code4lib.org/articles/8964↩

Scott A. Hale, Multilinguals and Wikipedia editing, Proceedings of the 2014 ACM conference on Web science, June 23-26, 2014, Bloomington, Indiana, USA http://doi.org/10.1145/2615569.2615684↩

Klein, M. and Kyrios, A. VIAFbot and the integration of library data on Wikipedia. code{4}lib Journal 22 (Oct. 2013); http://journal.code4lib.org/articles/8964↩

Denny Vrandečić, The Rise of Wikidata, IEEE Intelligent Systems, v.28 n.4, p.90-95, July 2013 http://doi.org/10.1109/MIS.2013.119↩

訳注：以下は 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 の概観をつかんでもらえるよう、私たちはこの文書を公開することにしました。このようにした動機についてより詳しくはブログに書いてあります。

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

環境

優れた Hacker Schooler の振る舞い

助言

ペア・プログラミング

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

困難と精神の健康

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

ゲスト

Other resources 1

Contact information 2

Hacker School の沿革

翻訳

ChangeLog

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

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

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

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

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

落ち着いて！

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

環境

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

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

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

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

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

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

優れた 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 の生存はここにかかっています。

ゲスト

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

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

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

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

卒業生

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

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

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

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

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

家族

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

Hacker School の沿革

2006年秋。ニックとデイヴが Signals & Systems の授業で出会う。

2007年夏。ニックとソナリが Shakespeare in the Park 11で出会う（ソナリはニックの同僚のひとりでした）。

2008年春。ニックとデイヴが仕事の後の時間に「ビジネスミーティング」をはじめ、会社を起こす相談をしはじめる。

2010年10月。ニックとデイヴがプログラミングの仕事を辞めて、「OkCupid for jobs」を立ち上げる。

2010年6月から10月。ニックとデイヴがカリフォルニア州マウンテンビューに住み、Y Combinator プロジェクトのひとつになる。ニューヨークに戻りたいと言い、ポール・グレアムに「自己中心的」と言われる。

2010年秋。ソナリが週末にニックとデイヴといっしょに働くようになる。

2011年2月。ソナリが軽めの仕事と給料を辞め、チームにフルタイムで加わる。

2011年6月。デイヴがポール・グレアム、Sam Altman、Paul Buchheit と「ハッカーの学校」について長く話し、このアイデアに興奮してニューヨークに戻る。少数に人たちをこの「ハッカーの学校 (hacker school)」の実験に招待する（この名前は一時的なものと考えていたので、大文字にはしませんでした。「学校」と呼ぶのがいいかどうかも分かりませんでした）。

2011年7月16日。このバッチに参加するつもりでいた人のうち3分の1が開始2日前にとりやめる。

2011年7月18日。「バッチ[0]」（または2011年夏のバッチ）の初日。ニック、デイヴ、ソナリを含めて9人だけで、5週間のバッチだった。ニューヨーク大学の窓のない小さな部屋を使う。アランはこの Hacker Schooler のひとりで、まったく訳がわかっていないニックとデイヴにモナドを教えようと頑張る。ソナリが唯一の女性参加者。

2011年8月。John "workmanjj" Workman が「絶対卒業しない」を Hacker School のモットーとするよう提案。

2011年9月。第2バッチ開始。Spotify の窓のない少しだけ大きな部屋を使う。

2012年2月。Hacker Schooler 20人で第3バッチ開始。このなかにトムがいた。このバッチはハフィントン・ポストのオフィスを使った。Danielle Sucher が最初の Hacker School 卒業生になる。

2012年5月。トムとアランをこの夏のバッチを手伝う契約職員として雇う。

2012年6月。Hacker Schooler 20人で第3バッチ開始。アリソン、ザック、メアリーがこのなかにいた。このバッチは45%が女性で、Etsy のオフィスを使った。

2012年8月。トムとアランが常勤になり、ザックとアリソンが加わる。

2012年10月。Jessica McKellar、Peter Seibel、Alex Payne、Stefan Karpinski、David Nole が最初のレジデントになる。

2013年2月。マンハッタンに自分たちの場所を確保！ 米国政府がメアリーを「例外的」と認め、就労許可を出してくれる。

2013年9月。自然光いっぱいで蠅の出ない場所に引越し。

2014年4月。伝統がバッチから引き継がれやすくなるよう、オーバーラップ型のバッチに移行。

2014年6月。最初の運用専従者としてレイチェルを雇う。

翻訳

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

Changelog

2013年5月1日 – 初公開。

2013年9月19日 – 対人関係ルールを一新。

2013年9月19日 – contact information を追加。

2014年1月29日 – テキストエディタについての助言を追加。

2014年2月24日 – スペースについてのポリシーとゲストポリシーを追加。

2014年3月10日 – 学生 (student) を「Hacker Schooler」と言い換える。ゲストポリシーをさらに更新。

2014年6月30日 - 翻訳セクションを追加。 <!- June 30th, 2014 – Add translations section -->

2014年7月3日 - 第4ルール「性的ほのめかしをしない」を「差別のほのめかしをしない」に変更し、説明を一新。

2014年7月7日 - 差別的表現を除去。Hacker School の歴史を更新。

2014年7月9日 - メーリングリストシステムの詳細を更新。

2014年7月25日 - レイチェルを追加。困難のセクションを追加。

訳注：省略しました。 https://www.hackerschool.com/manual#sec-other-resources をご覧ください。 ↩︎

訳注：省略しました。 https://www.hackerschool.com/manual#sec-contact-info をご覧ください。 ↩︎

訳注：Hacker School のファシリテータ (facilitator) は有給の職員であり、Hacker Schooler たちを支援しています。 ↩︎

訳注：Hacker School では1年の決まった時期に複数人（数十人）が入学し、3ヶ月間活動します。この数十人の組のことをバッチ (batch) と呼んでいます。 ↩︎

訳注：冒頭にもありますが、本文書の想定読者は Hacker School への入学者です。 ↩︎

訳注：ファカルティ (faculty) とは Hacker School を運営・経営する人たちです。 ↩︎

訳注：ニックは Nicholas Bergson-Shilcock のこと。 ↩︎

訳注：デイヴは David Albert のこと。 ↩︎

訳注：チェックイン (checkin) とは簡単な進捗報告をしあうことです。Hacker School では1日1回小さなグループを組んでおこなわれます。 ↩︎

訳注：レジデント (resident) は Hacker School の臨時講師のようなもののようです。詳しくは https://www.hackerschool.com/residents をご覧ください。 ↩︎

前回書いたようにインターンとしての採用決定は4月上旬でした。開始日は6月上旬と決まり、それまでの期間にはいろいろと準備がありました。2ヶ月というと余裕があるようにも思えますが、実際にはビザと家探しなど意外に時間のかかる作業があったり、手続きについて調べなければならなかったりで、けっこうな時間を費やしたと思います。住居についても、紆余曲折があり難航しました。

チーム構成

8人のインターンが定量的分析、定性的分析のサブチーム1に分かれていました。どちらも（ほぼ）博士課程の大学院生で構成され、前者はコンピュータ科学や統計的分析、後者は社会学やオンラインコミュニティ分析を専門としています2。この時点では、一度だけSkypeで顔合わせ（というか声合わせ）をして、あとはほぼメールでだけ連絡をとりあっていました。メンターを合わせるて11人のうち5人は米国外（スイス、イタリア、ロシア、オランダ、日本）出身だったので、組織全体とインターンチームの規模の割には多国籍だったと思います。

仕事の準備

アカウント作成と、使う予定のツールについての調査など。ウィキメディア財団の特殊事情として、サーバー管理もコミュニティ（ボランティア）が参加してやっているという点があります。ウィキメディア財団職員もインターン生も、サーバーアカウントやコミット権限をもらうにはコミュニティの許可が必要です3。

インターン生は現地に行く前から、開始時に備えた練習として、リモートで仕事をはじめました。これはいいやり方だと思いました。たとえば、実際に試してみると、英語版ウィキペディアのMySQLデータベーステーブルを扱うのはやっかいでした。メモリを使い果たしてしまいかねないのでjoin を安易にしないことなど性能面で気にしなければならないことがたくさんあることがすぐに分かりました。必要なデータがどこにあるか、どの部分に工夫が必要になるかなどがある程度分かった状態で現地に着いたので、戸惑うことなく仕事をはじめることができました。このあたりも、データの持ち出しなどにあまり制約がないオープンな組織のいいところかもしれません。

住居

個人的に一番難航したのが住居探しです。 まわりの米国インターン経験者には住宅で困ったという話をあまり聞かないのですが、 自分はなかなかうまくいきませんでした。何かも初めてだったということのほか、ひとつには住宅事情が悪いサンフランシスコという土地柄があり、またホスト組織のウィキメディア財団が（特に米国外からの）インターン受け入れと支援に慣れていない、というのも大きかったのかなと思います。

サンフランシスコは、情報系をはじめとするインターンが多い街なので、夏だけの貸し家やアパートの部屋がけっこうあります。ただし、それ以上に借り手も多いらしく、地価は高いです。 最初は、せっかくなので全員が入れる物件を探そうとしたりもしたのですが4、一ヶ月たらずで入居したいとなるとなかなか条件の合うところが見つからず、結局は各自で部屋探しをすることになりました。craigslist とか roomorama を使っていくつも応募をしましたが、ほとんどまともな返事がありませんでした。

最終的には渡航一週間前くらいになって、月900ドル、オフィスまでバスで20分ほどのルームシェア（風呂とトイレと台所を共有）の物件を押さえることができました。最初はホテルかどこかに泊まることを覚悟しはじめていたので、このことはかなり助かりました。大家さんは近隣の大学で言語学の社会人修士をやっている人で、自分が計算言語学をやっているということろには興味を持ってもらえたようでした。

ビザ

4月下旬から、ウィキメディア財団と、ウィキメディア財団が依頼した移民関係の弁護士事務所と、 American Immigration Council とのあいだで書類のやりとりをはじめました。最終段階での政府から発行された証明書の受け取り以外、連絡手段はほぼすべて電子メールでした。こちらから書類を作って送るときにはスキャナを多用しました。

ビザ申請関係の書類は色々あり、書き方を調べるのにけっこう手間取りました5。なかでも、インターンシッププログラムとそこへの受け入れに対する認可を示す DS-2019 の取得にもっとも手間と時間がかかったようでした。「ようでした」というのは、DS-2019については自分としてはプログラムの内容や期待する獲得スキルなどについて提案するくらいで、ほとんどはウィキメディア財団の事務方と上司がやってくれたからです。これらを準備するのに4月末から5月中旬までかかったため、ビザの発行がほんとうにギリギリになってしまいました。

必要種類が揃った時点で、東京大使館の通常の処理キューだと6月頭の出発にほぼ間に合わない見込みになっていたので、5月23日に「通常の処理だと、すでに承認を受けたプログラム開始期日に間に合わないので優先してほしい」との旨で緊急予約を依頼して、5月25日に日比谷の米国大使館で面接を受けることができました。

面接はすみやかに終わりました。インターンの場合、すでに何段階か政府からの承認を得ているので、大使館面接はほとんど形式だけ、という印象でした6。名前の確認、現在の所属、インターン中の職についてのみ訊かれ、問題なく承認されました。9時半に到着したのですが、10時半には出ることができました。

その他

持ち物については、 研究留学ガイド：アメリカに持っていくもの をかなり参考にしました。

次のポストでは（ようやく）インターンシップ開始後のことを書きたいと思います。 追記：と言ったまま書いていませんでした。仕事の内容や成果物はWSoR2011 というページ群に書いてありますのでご覧ください。

それぞれ研究経験者として、オンラインコミュニティ分析の研究をしてきた Diederik van Liere 、スラブ文学・文化の研究をしてきた Maryana Pinchuk がマネジメントを担当しました。サブチーム分けはそれほどかっちりしたものではなく、各自のプロジェクトが切り替わったり進展したりするごとに、違う人と組んだり一人でやったりしました。 ↩︎

ただし厳密に分かれているというよりは、ほとんどの人は学際領域に属していいるといったほうが適切 ↩︎

とはいえ実際には、ウィキメディア財団に関係する案件は迅速に処理されることが多く、また、最近ではMediaWikiコミット権限付与処理は職員に任せられています。 ↩︎

ウィキメディア財団のオフィスがあるサンフランシスコ中心街 (Downtown) 近辺では比較的ワンルーム（ studio と呼ばれる）が多く、中心街を少し離れたあたりでは貸し家を数人で共有する形の物件（寝室だけ個室で、room share と呼ばれる）が多いようでした。後者のなかには、家全体をグループに貸しに出しているケースと、家の一部に既に住んでいる人がいて残りの部屋を貸しに出しているケースとがあり、後者の方が（少なくとも夏は）多く貸し出されているようでした。 ↩︎

基本的には政府のホームページにある情報、弁護士事務所からもらったガイドなどを参考にしました。他の情報もネット上にいろいろあるのですが、ビザ関係は手続きが頻繁に変わるらしく、かえって混乱してしまうケースがありました。 ↩︎

「ウィキメディア財団で研究インターンをする：その0 はじめに」というようなことを背景として、まず、インターンに応募し採用されるまでを書きます。筆者は、応募当時、ウィキメディア財団の関連プロジェクトで（それほど熱心でないながらも）3年活動経歴があり、情報系の博士課程の大学院生でした1。

分からないなりに「米国での仕事への応募の定石」を調べてそれに沿ってやったので、誰かの役に立つかも、と思いちょっと細かいところから書いてみます。

2011年3月上旬：応募

"Quantitative Research Fellowship" と題された募集があることを wiki-research-l の過去ログを見ていて発見しました。応募締切まで1週間もなかったので、この時点でかなり焦りながらも、必要書類である、カバーレター、 レジュメ (CV)、博士論文の要約などを書き始めました。 （なお、CV は以前作成したものを一部流用できたのであまり時間はかかりませんでした。志望動機などを書くカバーレターは当然ながら使いまわしがきかないので、ほぼすべて書き直しました）

募集時期について少し加えておくと、自分が気づくのが遅すぎたというのは置いておくとしても、このウィキメディア財団のインターンの募集はマイクロソフトなどの大企業と比べると告知からの猶予がかなり短かかったように思います。大企業は長年、定期的に募集をかけており、北米だと毎年1月前後が応募の最盛期だと聞きます。ウィキメディア財団のような小規模な組織の場合は、組織内の資金繰りの見通しがつきにくいこともあって、インターンシップの募集は不定期だったり大企業より遅かったりするのかもしれません。そもそも、このインターンシッププログラム自体がウィキメディア財団にとって初めての試みだったという事情も大きいと思いますが。

それぞれの書類について、そもそも何を書くべきかということろから調べながら書きました。そのときのメモを以下で一通り説明します。

カバーレター / 2ページ

自己紹介と募集されている job description への興味とを伝える手紙です。 論文を書くときにも吟味しろと言われるイントロダクションと同じように、自分の第一印象を決める部分であり、時間をかける価値はあると思います。 こうした手紙の書き方になじみがなかったので、文例をググりながら書き、研究室の留学生P君に何度か添削を頼みました。 正味でかけた時間はおそらく一番長かったと思います。 ここは、 job description がないとか、研究できる人でさえあればテーマは応相談、というようなインターンシップだったら、もっと比重が弱いかもしれません。

カバーレターで重要とされているのが、職位で求められていることと自分の経歴やスキルとがいかに適合しているかを説明することだそうです。 細部には立ち入らず、ややメタな視点で、自分のどこが売り込みポイントかを端的に言うのが良いとされています（詳細で客観的な経歴はCVに書く）。 長さには諸説があるようですが、米国の慣習では短くて4段落、長くて10段落（2ページ）といったところのようでした。 ほかにもネット上を探すと、長すぎても人事の人をつかれさせるだけなので要点をまとめよう、ただし素っ気なくならないようしよう、というアドバイスをよく見かけました。ただ、これはどういうところに応募しようとしているかにもよると思います。短くすべき、というのはおそらく大企業では正解ですが、小規模で知名度が（まだ）あまり高くないインターンシップの場合は、受け取る手紙の数はそれほど多くないはずなので、やや長めになってしまっても興味や意欲をアピールすることを書くならそれほど嫌がられないのではないかと思います。

自分の場合はウィキメディアコミュニティでの経験に触れるようにと指定があったので、そうしました。この辺はボランティアと深く関わるウェブ組織のウィキメディア財団らしいかんじがします。P君に査読をしてもらったときに、「このコミュニティでの経験の部分はふくらませて動機にむすびつけたほうがいい、そして個人的な思い入れを文章中の早い時点で書いたほうがいい」と指摘され、そのように直しました。結果、意気込みが伝わりやすくなったと思います。

レジュメ / 2ページ

学歴、職歴、受賞歴、スキルなどを書く書類です。 書式はさまざまありえて、とくに学歴や職歴の欄に、一つ一つの仕事や経験の中身をどれだけ書くかが悩みどころでした。一番短い形式では所属だけを書き、長い形式では、どこで何をどの程度の量・規模でやったのか、特にどんな貢献をしたかまで書くようです。 間をとって、所属＋プロジェクトの名前＋もう二言くらいで説明、というあたりがいいかと思って、そうしました。 http://jblevins.org/projects/cv-template/ を使い、TeXで組みました。 発表文献や受賞歴は日本国内の日本語のものが多かったので、英訳を付記して書きました。英語圏で知名度のない学会や賞にどれだけ意味があるか分かりませんが、書いて損するものでもないと思います。公式英語名称はないこともあるので、検索されたときに引っかかるように日本語名も書いておくべきだと思います。

博士論文の要約 / 1ページ

論文のイントロダクション部分のつもりで書きました。おそらく研究をちゃんとやっているということを伝えるべき文書だと思ったので、基本的にはあまりインターンの内容との親和性は意識せずに、そのまま書きました。一言だけ、自分の研究は文章訂正に応用できるのでウィキペディアの知的スペルチェッカとして組み込むことは将来の展望として有望かもしれない、というように触れました。

次のポストでは面接などについて書きます。

ここから何回かに分けて、ウィキペディアを運営するウィキメディア財団で3ヶ月インターン1した話を書いていきます。インターンの内容についてはすでに書いているということもあって、ここでは主に応募、選考、開始準備まわりで何をやったかを書こうと思います。

ウィキメディア財団 (Wikimedia Foundation; 略称WMF) はウィキペディアを運営している組織です。技術開発、運用、法務などすべて合わせて100名未満の非営利組織です。2011年のこれを書いている時点で唯一のオフィスはアメリカ合衆国カリフォルニア州サンフランシスコにあります2。

ウィキメディア財団の仕事は、サーバー群の管理、法務、募金活動など、ウィキペディアとその他のウィキメディアプロジェクトの裏方です。ときどき混同されますが、サイト上のコンテンツの更新や管理はWMF職員ではなく、すべてボランティアがやっています。ウィキペディアには「管理者」という仕事がありますが、ウィキメディア財団とは直接関係のない、サイト上でユーザーから信任を受けたユーザーの方々がこなしています3。

ウィキメディア財団では、2010年に策定された戦略プランに基づいて、編集者の定着率を高めるための調査や機能開発のプロジェクトがいくつも立ち上がっています。その一部として立ち上げられたのが、2011年夏の研究インターンシップでした。

インターンの仕事の中身はすべてウィキメディアのメタウィキ上のページ、 [[meta:Research:Wikimedia Summer of Research 2011]] にまとめられています。細かい説明は別の機会に譲りたいと思いますが、全体として課せられていたタスクは、英語版ウィキペディアに蓄積された編集履歴を解析し、編集者の定着率が伸びなくなった原因を探ることでした。実際にやっていた作業は、自分の場合は、編集者間で交わされる発言への感情表現タグづけ、ダンプXMLを分散処理するツールの作成などです。

自分にとってははじめての外国でのインターンシップでしたが、身の回りをみても、国外の大企業のインターンシップや国内の研究開発インターンシップに参加する人はそれほど珍しくありません。幸運なことにそうした方々の詳細で有益な報告がたくさんブログなどで公開されています。日本国外の情報系インターンや開発研究関係のインターンでは、短期間ながら開発者または研究者と同じ職務を担うという形態が多いようです。このウィキメディア財団のインターンシップも同様でした。類似するインターンシップも多いなかでこの報告が少し特別だとすれば、次の点が挙げられます。

巨大グローバル企業ではなく、小規模（職員は100名を超えない）な組織であること

ベンチャー企業とは違い、すでに長く運営されていて多数の長期ユーザーを抱えていること

非営利の、多国籍な組織であること

研究開発ではなく、研究分析の仕事であること

応募書類作成や家探しなど細かいことが書いてある（書く予定である）こと

以上を導入として、次のポストで、応募するまでを書きます。

肩書きとしては Summer Research Fellow （夏期研究フェロー）という名前がついていましたが、実際にやっていたことはいわゆるインターンです。 ↩︎

なお、WMF2番目のオフィスが2011年末をめどにインドで設立されるそうです。 ↩︎