世界史データベースは何を目指しているのか
今回のコテンラジオは、COTENの採用に関するお知らせ回です。募集職種はエンジニアと、世界史データの品質管理やデータ入力のマネジメントを担うデータマネージャーです。
深井龍之介さんは冒頭で、採用に興味がない人は飛ばしてかまわない内容だと断っています。職種の詳細は概要欄のリンク先に文章でも載せるので、それを見ながら聴くとよいとも話しています。
この回の出演者は、いつものヤンヤンさんと樋口さんではありません。COTENのCTOであるトムさんと、プロダクトマネージャーの草野ひなつさんが参加しています。
トムさんはデータ収集チームを率い、プロダクト全体の技術面を見ています。CTOという肩書きながら、バックエンドエンジニアと呼んだほうがふさわしいほど自分でコードを書いているそうです。
草野さんは、世界史データベースを使うアプリケーションにどんな機能を足すかを、ユーザーへのヒアリングをもとに決めて推進しています。そのユーザーとは、初期ユーザーとして設定されている深井さん自身だといいます。
深井さんによれば、データベース開発は全体から見ればまだ道半ばです。ただし、膨大な作業を一歩一歩着実に進めている段階にあります。
COTENの世界史データベースは、歴史情報を統一的なルールで整理し、一覧性と検索性を高めた状態で保持するものです。完成すれば、理論上はあらゆる切り口で歴史を検索できるようになります。
深井さんが挙げる例は多彩です。大器晩成型の人物だけを抜き出して時代とエリアの分布を見る、自分の人生に似た経験をした人を探す、笑える人生や悲劇のエピソードだけを出す、といった使い方が想定されています。
気温が下がった時に戦争がどうなってるかとかも見れるし、食糧危機が起こった時に政治形態がどう影響を受けてるかとかも、まあ見ようと思ったら見れる。
深井さんはこの程度の説明ならいろいろな場所でしてきたものの、一般向けに具体的な話はほとんどしてこなかったといいます。本当に説明しようとすれば5、6時間はかかり、トムさんもそれに同意しています。
日付の書き方だけで15通り以上ある世界
深井さんは世界史データベースの開発を、一般的なスタートアップのプロダクト開発よりかなり複雑なものだと見ています。時系列の異なる社会データを、どう整理して検索可能にするかというプロジェクトだからです。
その複雑さの例として深井さんが挙げたのが日付です。史料集の巻末年表を調べただけで、日付の書き方が15通り以上見つかったといいます。
「紀元前何年」「前何年」「前何年頃」「何年初頭」「何年後半」「何年代」のように、本の中での日付表記は統一されていません。そのままでは同じ系列のデータとして横に並べられないため、データベースにどう格納するかを1つずつルールとして決める必要があります。
深井さんによれば、こうした問題は日付に限らず、あらゆる情報で起きています。いま実際に悩んでいるのが、エピソード情報を検索可能にするための定義です。
たとえば曹操 ── 中国・後漢末の武将・政治家。三国時代の魏の基礎を築いた人物ですと袁紹 ── 後漢末の有力な群雄の一人。のちに官渡の戦いで曹操と争いましたが幼い頃に一緒にやんちゃをしていたという話は、史実ではなく通説ですが、エピソードの一種です。織田信長が桶狭間の戦いに単騎で走り出し、家臣が慌ててついていった話もエピソードにあたります。
何までがエピソードで、何からがエピソードじゃないかの基準がめっちゃむずくて、今。
エピソード情報の定義はまだ検討・議論の途中です。深井さんは、今回募集するデータマネージャーはこうした議論にも関わる可能性があると話しています。
トムさんは日付に関して、暦の問題を補足しています。和暦と西暦の違いだけでなく、西暦の中にもグレゴリオ暦 ── 現在世界で広く使われている太陽暦。1582年にユリウス暦から切り替えられましたと先発グレゴリオ暦があり、16世紀の途中で暦が変わっているそうです。
そのためトムさんは、1400年という表記ひとつでも、どの暦の1400年なのかを把握しておく必要があると説明します。21世紀のデータを扱う限り問題にならないことが世界史データベースでは山ほど問題になり、それを自分たちで一から解決しているといいます。
史料ごとの表記
年表だけで15通り以上の書き方がある
暦の違い
和暦・西暦に加え、16世紀に暦が切り替わっている
格納ルールの作成
表記の揺れを1つずつルール化して統一する
曖昧な国境を六角形のグリッドで描く
もう1つの大きなプロジェクトが地図画面の作成です。深井さんは、地図上でデータを見たり検索したりできることは歴史にとって有用性が高いと考えています。
地図画面で想定されているのは、年ごとの国境の推移、人物の移動、交易路などの表示です。一方で、課題も山積みだといいます。
国境ひとつをとっても、統一的なデータとしてはどこにも存在しないため、集めるところから始める必要があります。遊牧民の国境とは何か、という根本的な問いもあります。
国境線みたいなのが明確に出来上がったのは近代国家以降だから、それまでの国っていうのは面じゃなくて点なんだよね。都市単位なんだよね、基本的にはね。
都市と都市のあいだのどこが国境なのかは、実はかなり曖昧です。トムさんは、曖昧な情報を曖昧なまま扱うのはコンピューターが苦手とすることで、基本的にはピンポイントの線しか引けないと説明します。
そこで検討しているのが、エリアに幅を持たせたグリッドという考え方です。世界地図全体に蜂の巣のような六角形のブロックを敷き詰め、ブロックを色塗りする感じでエリアを選択できるようにしています。
六角形のブロックには12段階ほどの大きさがあります。深井さんによれば、最も大きいものは国レベル、最も小さいものは家3軒分ほどで、エリアによって細かくも粗くもできる技術を採用しています。
大きさを変えられることが重要なのは、地域や時代によって分かっていることの解像度がまったく違うからです。ざっくりとしか分からない地域がある一方、京都のように非常に細かく分かっている場所もあります。
このため、COTENはグリッドの集まりにデータを付与して扱う方式ならうまくいくのではないかと考えながら、地図の開発を進めています。
「歴史は解釈で分かれる」への答え
深井さんは、面白い人には面白く、つまらない人には本当につまらない話だと前置きしつつ、データの規格の重要性を説明します。膨大なデータ入力を見据え、どんなルールで統一して整理するかを決めるのが規格の話です。
規格づくりのために、COTENはLinux ── オープンソースで開発されているOSの代表例。世界中の開発者が共通の仕組みのもとで開発に参加していますやISO ── 国際標準化機構。製品や管理手法などの国際規格を定める組織ですを研究しているといいます。情報の信頼性をどう担保するかの調査も進めています。
深井さんがよく受ける質問が、「歴史は解釈で分かれるのに、どうやってファクトと認識するのか」というものです。これに対して深井さんは、哲学の視点から答えています。
歴史に限らずですね、現代に存在しているすべての情報が基本的に解釈なんだよね。とも言えるんだよね。
深井さんによれば、普段接しているニュースが本当にファクトかどうかも決めの問題です。とはいえ全部を解釈として扱えば社会が崩壊するため、どこまでをファクトとして扱うかを決める必要があります。
そのうえで深井さんは、歴史の中で解釈が分かれる情報は、自分の感覚では1割ほどしかないと話しています。9割はファクトとして扱われているといいます。
たとえば「織田信長がいた」「桶狭間の戦いがあった」「本能寺の変 ── 1582年、明智光秀が京都の本能寺で主君の織田信長を襲撃した事件があった」といった情報は、基本的に意見が分かれていません。一方で「本能寺の変がなぜ起こったか」は、大きな説だけでも4つあるとされます。
解釈が分かれる情報は、データベースなら並列に並べられます。深井さんは、本能寺の変の理由を大きく4つ並べる、始皇帝 ── 中国を初めて統一した秦の王。紀元前221年に皇帝を名乗りましたへの評価を地域ごとに示す、といった出し方を例に挙げます。
全体の9割ほど。信長の存在や本能寺の変の発生など、意見が分かれていない領域
全体の1割ほど。本能寺の変の原因や始皇帝の評価など、複数の説を並べて示す
ファクトはデータとして扱う、解釈もまあもちろんデータなんだけど、並列データとして扱うというような考え方で作ろうとしている。
トムさんは規格について、仮説のピースが一通り埋まり、それをもとに作ってみる段階に入ったと補足しています。その仮説がうまくいくかを一緒に試すのが、これから加わるエンジニアやデータマネージャーだといいます。
データベースの「四体問題」とは
深井さんは、こうした検討ができているのはCOTEN CREW ── COTENの活動を月額で支援するサポーター制度のおかげだと話しています。そのうえで、もう1つの検討中のテーマとして「データベースの四体問題」を紹介しました。
「四体問題」という名前は、中国のSF小説『三体』を好きなメンバーが付けたものです。大きく対立する2つの考え方を1つの軸と数えると、データベースには考えるべき軸が4つあるといいます。
| 論点 | 一方の考え方 | もう一方の考え方 |
|---|---|---|
| 情報の入力 | 自律分散型で多くの人に入力してもらう | トップダウンで統制する |
| データの所有 | 株式会社として所有する | 人類の共有財産として非所有にする |
| お金の扱い | 非営利で提供する | お金を取る |
| 入力メンバーへの報酬 | 非金銭報酬で報いる | 金銭報酬で払う |
所有の問題について深井さんは、普通の会社なら100%所有にするところだろうと話します。ただCOTENはパブリシティを重視しているため、非所有の領域をどう考えるかを社内で検討しています。
報酬の問題では、現在ボランティアの人にもデータ入力をしてもらっています。深井さんは、全部を金銭報酬で払えば何百億円もかかる可能性があり非現実的だと見ています。
数十億円ぐらいまでは資金調達ができるんじゃないかと僕は個人的に思っているので、そのお金で作りきれるぐらいの非金銭報酬の使い方みたいなのを考えないといけない。
トムさんは、それぞれの軸は時系列で動かしていくこともありうると補足しています。たとえば入力の方式は、いまは統制にして、時間が経つにつれて分散に移していく、という考え方です。
深井さんもこれに同意し、いま自律分散型にすると統一ルールがなくなって壊れてしまうので、現状は統制型で進めていると説明します。一方で、世界史データベースを自分たちがいつまでも統制するのはいびつだとも考えています。
あと1年半で「動く資料集」をつくる
深井さんによれば、COTENは討論を続けながら、実際に画面を作り、データも入力しています。大きなプランは、あと1年半ほどで「動的に動く資料集」を作ることです。
イメージは、学校で使う世界史の資料集をウェブ上に置き、検索や並べ替えができる形で動かせるものです。全部のデータを入れられる自信は人件費的にあまりないものの、何がしたいのか、何ができるのかを連想できるレベルのものは作れると考えています。
ただ、この目標に対して人的リソースがまったく足りていません。COTEN CREWの支援で雇えている人もいますが、それでもまだ足りない状況です。
そこでCOTENはエクイティ調達 ── 株式を発行して投資家から出資を受ける資金調達の方法を行っています。深井さんによれば、1億円弱の調達を一度行い、ポスト資本主義的な調達だったため余計に難しかったといいます。
次に予定している調達を原資として、人を増やしたいというのが今回の求人の背景です。深井さんは、いま最大のボトルネックはデータ入力時のルール整備だと話しています。
細かいところを全部喋ってたらマジで本当に終わんねえから、結構どんどん決裁権渡して決めていってもらうみたいなことをある程度はしないといけないですと。
ルールを整備し、データを入力する人員のマネジメントもする人材を、COTENはデータマネージャーと呼んでいます。もう1つの不足は開発で、CTOのトムさんが自分で手を動かさないといけないほどエンジニアが足りていません。
深井さんは、トムさんには上流工程の仕事に集中してほしいと考えています。開発は要件を細かく決める方式ではなく、アジャイル ── 短い期間で作っては見直すことを繰り返すソフトウェア開発の進め方。1回の区切りをスプリントと呼びますのスプリント式で進めているそうです。
トムさんによれば、ざっくりとした機能を考えて渡し、作ってきてもらう形で依頼しています。深井さんは、作ってきたものを編集しながら理想に近づけていくやり方だと補足しています。
フロントエンドエンジニアは数千年の年表と地図に挑む
募集職種の詳細はトムさんが説明しています。募集はフロントエンドエンジニア、バックエンドエンジニア、データマネージャーの3職種です。
世界史データベースのチームは、データを集めるデータ収集チームと、集めたデータを利用者が分析・検索・調査に使えるUIを考えるプロダクトチームの2つに分かれています。フロントエンドエンジニアはプロダクトチームに所属します。
フロントエンドエンジニアの仕事は、利用者が触る年表や地図のアプリケーションに、BDMと二人三脚で新機能を開発することです。年表はかなり作り込んだものの、地図の搭載や検索の強化、エリア別表示、並べ替え、不要な情報を隠す機能など、アイデアに対して実装の手が足りていないといいます。
使っている技術は、React ── 画面を部品の組み合わせで作るJavaScriptのライブラリ、TypeScript、GraphQLという標準的な構成です。見た目の部分にはMaterial UIやVanilla Extractを使っており、トムさんは現代的なウェブ開発をしている人には馴染みのある構成だと話しています。
COTENならではの点は、年表部分の技術へのこだわりです。一般に年表はガントチャートのようなプロジェクト管理ツールで使われますが、世界史のように何千年という時間幅を表示するライブラリはなく、自前で作ることになったといいます。
トムさんによれば、表示したいデータは数万件あり、使い勝手を考えると即座に表示する必要があるため、既存のライブラリではまったく対応できませんでした。自前の年表ではD3.js ── データを図やグラフとして描くためのJavaScriptのライブラリを使っています。
地図については、Uberが開発したDeck.gl ── 大量の地理データを地図上に高速に描くためのJavaScriptのライブラリの活用を考えています。ただ大量の地図情報を載せたときの重さはまだ検証できておらず、トムさんは検証や改善まで担えるガッツのある人に来てほしいと話しています。
バックエンドエンジニアは件数より複雑さと向き合う
バックエンドエンジニアは、会社によってはデータエンジニアと呼ばれる職種です。データソースから取り込み、統一ルールで使えるように変形するまでのデータ収集パイプライン全体を作ります。
このパイプラインには、人の手によるチェックや修正のプロセスも含まれます。技術はTypeScriptとNestJSを使った、一般的なウェブアプリケーションの構成です。
トムさんによれば、世界史データベースの量は一般企業のデータより圧倒的に少なく、これまで入れたのは10万件から100万件の間ほどです。普通のウェブサービスなら1日分にも満たない量ですが、1つ1つのデータがとても複雑だといいます。
たとえば日付には、紀元前30万年のようなものもあれば、16世紀中葉のような曖昧な言い方もあります。王朝や王、武将の名前といった固有名詞も資料ごとに表記揺れが大きく、辞書を手でメンテナンスする必要があります。
固有名詞を抜き出す技術は固有表現抽出 ── 文章から人名・地名・組織名などの固有名詞を自動で見つけ出す自然言語処理の技術。英語ではNamed Entity Recognitionと呼ばれますと呼ばれます。トムさんは、これを人手でやると大きなコストがかかるため、どう自動化するかがエンジニアリングの腕の見せ所だと話しています。
以前は難易度の高い技術が求められましたが、ChatGPTをAPIで呼び出せるようになったことで状況が変わりました。トムさんは、アイデア次第でこれまでの数分の1から数十分の1の労力でできるかもしれないと見ています。
そのためトムさんは、データが好きで、仕組み化や自動化が好きなエンジニアに来てほしいと話しています。言語は道具なので、自然言語処理ならPython、定期的なバッチならGoのように、状況に応じて変える相談も可能だといいます。
データマネージャーはITと世界史が重なる仕事
トムさんはデータマネージャーを、一言で言えば「データベースのデータのクオリティに責任を持つ人」だと説明します。すでに入っている10万件以上のデータには、単純な入力ミスやタイポが含まれています。
そうした誤りを利用者に見せてしまえば、データベースそのものが信用されなくなります。まずは人の手で細かくチェックして直しつつ、チームでデータの品質を上げる体制も考えてほしいというのがトムさんの期待です。
このためデータマネージャーには、ITへのある程度の理解が必要です。一方でトムさんは、間違いを間違いと気づくには世界史の知識が欠かせず、世界史をかなり分かっている必要があるとも話しています。
深井さんは、そんな人がいるのかという問いは自分たちにもあると認めています。そのうえで、医療系のシステムを作るときに保険点数のつき方を法律レベルで読む必要があるのと同じく、世界史も業務知識だと捉えています。
なんか3ヶ月ぐらい勉強したらだいぶ変わるから、ほんと業務知識と一緒。
トムさんによれば、応募の時点で世界史にとても詳しいことは求めていません。ただ、3か月から半年ほどの早い段階で、チームの中で一番世界史に詳しい人になってほしいという期待はあるといいます。
草野さんは、データマネージャー的な役割を自分も一部担っていると話します。日付の扱いやエピソード情報の入れ方を定義してから入力を依頼するため、まず自分で本を何冊か読み、スプレッドシートに当てはめて整理方法を確立していくそうです。
草野さんは、情報を整理するのが好きな人や、情報がきれいにハマる状態が好きな人は、データマネージャーを楽しめるのではないかと話しています。答えがなく自分で作っていく必要がある点は、難しさであり楽しさでもあるといいます。
トムさんも実際に試したところ、仮説を立ててやってみると世界史のデータには必ず例外が出てきたそうです。例外が出るたびにデータモデルを作り直す必要があるため、根気強く負けず嫌いな人が向いているとトムさんは見ています。
深井さんは、いまは人材育成のファーストステップの段階だと話します。歴史の勉強がモチベーションになる人にはぜひ応募してほしいと呼びかけています。
一方でエンジニアには、世界史の知識はそれほど求めていません。データマネージャーが整理したデータをどうシステム化するかが、エンジニアの仕事だからです。
応募はPodcastやYouTubeの概要欄から応募ページへ進めます。深井さんはハードルが高いことは認識していると話し、草野さんは「一緒にデータベース作りましょう」と呼びかけて回を締めくくりました。
まとめ
COTENの世界史データベースは、日付や暦、国境、ファクトと解釈といった、現代のデータでは起きない問題を1つずつルール化しながら着実に進んでいます。その次の段階を担う仲間として、エンジニアとデータマネージャーが募集されています。
- 世界史データベースは、歴史情報を統一ルールで整理し、誰もが多様な切り口で検索できる状態を目指している
- 日付の表記揺れや暦の違い、曖昧な国境などを、ルール作りや六角形グリッドで扱おうとしている
- 歴史情報の9割ほどはファクトとして扱い、解釈が分かれる情報は並列データとして並べる考え方をとっている
- フロントエンドは数千年規模の年表と地図、バックエンドは複雑なデータのパイプラインと自動化を担う
- データマネージャーはデータ品質に責任を持つ職種で、ITの理解に加えて、入社後に世界史を深く学ぶ姿勢が求められる



