필사 모드: 参照コストが読めるものを決めます — 2000年前のテキストからコード探索まで

• 辞書を200回引かなければならないテキストは読めません
• Ancient Libraryがしていること
• どこから来たものかが半分です
• 形態解析を自動化した選択とその代償
• 参照コストがゼロになると変わること
• 私たちがすでに知っている同じ話
• そこで生まれる新しい失敗の仕方
• 今週やってみること
• まとめと出典

辞書を200回引かなければならないテキストは読めません

古典語を学んだことのある人はこの感覚を知っています。文法はだいたい分かり語彙もある程度たまったのに、原典を1ページ読むのに2時間かかります。理由は難しいからではなく、途切れるからです。

ある単語で詰まります。屈折した形なので辞書にそのままは出てこず、まず見出し語を推測しなければなりません。推測が当たれば辞書を開き、項目が長ければその中からこの文脈に合う語義を選びます。ここまでで30秒かかったとしましょう。そして文に戻ると前半を忘れています。もう一度読みます。

1ページにこれが200回あると、合計は時間の問題ではなくなります。作業記憶が毎回リセットされるので、文が文として組み上がりません。そうなるとそのテキストは難しいテキストではなく、読めないテキストになります。

Ancient Libraryがしていること

Ancient Libraryは、この問題ひとつを消すサイトです。ギリシア語とラテン語の原典を集めておき、テキスト内のどの単語を押しても、その場で見出し語と形態解析と辞書項目の全体を見せてくれます。

規模はサイトにそのまま表示されています。著作1,060編で、うちラテン語が293編、ギリシア語が767編、著者は140人です。ジャンル別にラテン語14個、ギリシア語16個の分類に整理されています。

辞書は古典学で標準として使われる二つです。ラテン語はLewis and Shortの1879年のラテン語辞典、ギリシア語はLiddell-Scott-Jonesの1940年第9版のギリシア語-英語辞典です。サイトは自らをWorth Mediaの公益事業だと述べています。

どこから来たものかが半分です

このサイトを見るときに見落としやすい部分が出典です。テキストはタフツ大学のPerseus Digital Libraryから来たもので、クリエイティブ・コモンズ表示-継承4.0で提供されています。二つの辞書もPerseusがデジタル化したものです。

つまりこのサイトが新しく作ったのはテキストでも辞書でもありません。数十年かけて公開されてきた資源を、ひとつの画面で1回のクリックによってつないだものです。

この構造が示唆することがあります。参照コストを消す道具はたいてい新しいデータを作りません。すでにあるデータのあいだの距離を縮めます。そしてその距離がコストのほぼ全部です。辞書は100年前にもあり、テキストは2000年前からありました。無かったのは、その二つをつなぐ0.2秒の経路でした。

形態解析を自動化した選択とその代償

見出し語と形態解析は、人が手で付けられる量ではありません。このサイトはその作業を、古典語で学習された言語モデルに任せたと述べています。古典ギリシア語にはodyCyを、ラテン語にはLatinCyを使ったと書かれています。

そしてサイトはこの選択の代償を自ら明示します。自動解析は完璧ではなく、まれな形には見出し語や解析が誤って付くことがあるという点です。

私はこの一文がこのサイトでもっとも重要な部分だと思います。自動解析の失敗は静かだからです。誤った解析は疑問符を出さず、もっともらしい格と数を見せます。初心者はそれが誤りだと気づけず、気づける人はそもそも道具をあまり必要としません。道具の利得がもっとも大きい利用者が、その道具の誤りにもっとも弱いという構造です。この事実をサイトが先に書いておいたことと書かなかったことは、利用者にとってまったく違う状況です。

参照コストがゼロになると変わること

コストが下がることとゼロになることは違います。ここで変わるのは速度ではなく、可能な作業の種類です。

辞書を30秒で引くとき、私たちは本当に詰まった単語だけを引きます。あいまいだが何となく通り過ぎられる単語は通り過ぎます。ところが参照が0.2秒になると、あいまいなものも確認するようになり、確認しているうちに自分がどこを誤解していたかが分かります。つまりコストが消えると、読み方そのものが変わります。

二つめの変化は流れです。前で見たとおり、本当の損失は30秒ではなく、その30秒のあいだに失われた文の前半でした。同じ画面のなかで答えが出れば流れが途切れず、そうすると長い文が長い文のまま残ります。

三つめは少し分かりにくいのですが、実務ではもっとも大きいものです。参照が安くなると、確認せずに通り過ぎる習慣が減ります。高い参照を前にして私たちが実際にしているのは確認ではなく推測であり、推測はだいたい当たるので誤りだと知る機会がありません。そうして固まった誤解は数か月後にまったく別の場所で表に出ます。コストを消す道具が与える利得のかなりの部分が、ここ、つまり誤ったまま固まるのを防ぐところにあります。

私たちがすでに知っている同じ話

この構造に見覚えがあるなら正解です。コードですでに同じことを経験しているからです。

識別子から定義へ移動する機能が無かった時代のコードの読み方を思い出せば分かります。関数名を見てそれがどこにあるかを探すには、ファイルツリーを漁るか全体検索をかけるしかありませんでした。そうすると今読んでいた場所を失います。だから私たちは本当に詰まったものだけを調べ、残りは名前で推測しました。

定義への移動が即座に効くようになると、コードの読み方が変わりました。見慣れないコードベースを上から下へ流し読みする代わりに、ひとつをつかんで掘り下げ続けられるようになりました。初めて見るリポジトリで1日のうちにある程度の地図を描けるようになったのは、私たちが賢くなったからではなく、参照がただになったからです。

そこで生まれる新しい失敗の仕方

同じ利得には同じ代償がついてきます。コード探索の道具も静かに間違えます。

動的言語では、定義への移動は候補が複数あるときにひとつを選びます。その選択が誤っていても、エディタは疑問符を出さずに何かのファイルを開きます。開かれたファイルがもっともらしく見えれば、私たちはそれを正解として受け取り、その上に判断を積み上げます。インターフェースと実装が複数ある場合、モンキーパッチがある場合、生成されたコードが混ざっている場合に特によくずれます。

ここから実務的な結論がひとつ出ます。自動解析に頼る道具は、自分が間違いうるという事実を利用者に見せなければなりません。 Ancient Libraryが限界を文書に書いておいたように、エディタの探索機能も候補が複数あったという事実を隠すべきではありません。ひとつを選んで静かに開いてくれるのは楽ですが、楽な分だけ、間違っていたときの発見が遅れます。

今週やってみること

この観点を自分のチームに移すなら、問うべき質問はどの道具を使うかではなく、私たちのコードベースでまだ高い参照は何かです。たいていは次の四つのうちのひとつです。

• この設定値が実際にどこで読まれるか。文字列キーでアクセスすると定義への移動が効きません。
• このAPIレスポンスのフィールドがどのコードで作られるか。サービス境界を越えると探索が途切れます。
• このエラーメッセージがどこから出るか。文字列が組み立てられていると検索で見つかりません。
• このテーブルのカラムを誰が使うか。ORMが名前を変換するとつながりが見えません。

四つの共通点は、自動探索が途切れる場所だという点です。1週間のあいだにチームのメンバーが何を探すためにSlackで聞いたかを数えれば一覧が出ます。そのうち上位二つについてだけ検索可能な形を作れば、つまり文字列キーを定数に変えたり、組み立てられたメッセージを一か所に集めたりすれば、その一度の変更がこれから先の数百回の参照を消します。

まとめと出典

道具がすることは、無かった知識を作ることではありません。すでにあるもののあいだの距離を縮めることです。ところがその距離が縮むと私たちにできることの種類が変わり、だから道具はしばしば能力の問題のように見えます。

• Ancient Library — 著作の編数と言語別の分布、クリック時に提供される情報、二つの辞書の版
• Ancient Library紹介ページ — テキストがPerseus Digital Libraryから来ている点、クリエイティブ・コモンズ表示-継承4.0の条件、odyCyとLatinCyを形態解析に使った点、自動解析が完璧ではないという明示的な限界
• 本文後半のコード探索の話は上の資料が扱う内容ではなく、私が同じ論理を開発作業に移したものです。