RxJSのドキュメントを翻訳しながら英文資料を読む意味を考える

先日、職場でSPA開発（クライアントサイドMVCアプリ開発）の入門のための勉強会を企画した折、Angularの標準HTTPクライアントで利用されているRxJSに関して、全般的な説明を加える日本語資料がWWW上には見当たらないことに気が付きました。

[先日で要約を試みたイベントループ](https://qiita.com/mizukyf/items/17cff97493b4b8f27c68)もそうですが、プログラミング言語やフレームワークなど各種の技術的要素には、全体を俯瞰したりや哲学的な背景を知ったりすることでその理解が深まることがしばしばあります。

というわけで、12月、恒例のアドベントカレンダーを念頭に置きつつ、RxJSのファイルセットをGitHub上でforkし、そこに含まれる公式リファレンスの [概観](https://rxjs.dev/guide/overview)のセクションのうち、ユーザー開発者観点でとくに重要だろうと判断した部分をちまちまと訳出してみました。
「今更感」はありますが、少しでも皆さんの理解の役に立てれば幸い、と。

# RxJS Overview 抄訳

1. __[はじめに](https://github.com/mizukyf/rxjs/blob/master/docs_app/content/guide/overview.md)__（[原文](https://rxjs.dev/guide/overview)）
   RxJS（ないしReactiveX）に登場する重要概念と、RxJSが提供するAPIの基本的な使い方が示されています。もっとも概説的なページです。

1. __[Observables](https://github.com/mizukyf/rxjs/blob/master/docs_app/content/guide/observable.md)__（[原文](https://rxjs.dev/guide/observable)）
  RxJSが処理対象とするデータ型であり、RxJSのAPIの働き方を決定づける根本ともなるObservableを解説するページです。
  ObservableをJavaScript（TypeScript）における他の重要な仕組み─Function（通常の関数）、Iterator、Promise─と比較しながらその性質とライフサイクルを示します。

1. __[Observer](https://github.com/mizukyf/rxjs/blob/master/docs_app/content/guide/observer.md)__（[原文](https://rxjs.dev/guide/observer)）
  遅延・プッシュ型のコレクションであるObservableから値を受け取りさばくための方法について解説するページです。

1. __[Operators](https://github.com/mizukyf/rxjs/blob/master/docs_app/content/guide/operators.md)__（[原文](https://rxjs.dev/guide/operators)）
  一から新しいObservableを作成したり、既存のObservableから新しいObservableを合成したりする方法、オペレーターの使用方法を解説するページです。
  副作用がほぼなくテストしやすい小さな部品を組み合わせて大きなアプリケーションを構築するという、関数型プログラミングの思想的背景を感じさせる内容です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50571/6e8a586d-b7c8-5afc-9033-f2ae2eee6f55.png)

# 英文資料を読む意味

ところで、こうして英文の原典を読む、それも可能なら訳出しながら読むことの意義はなんでしょうか？

まず身も蓋もない話ですが「自身の仕事の生産性向上に有益」というのがあるでしょう。

他の業界でも似たようなことはあると思いますが、IT業界ではちょっと突っ込んだ調べ物をし始めるとすぐに英文に当たらざるを得ないという厳然たる事実があります：

- __情報量__ ：邦訳が流通するドキュメントはごくごく限られている。
- __速度__ ：原典が流通してから邦訳が流通するまでにタイムラグがある。
- __成熟度__ ：邦訳をできる有識者が現れるまで分野／コミュニティが成熟（人口・知識レベル）する必要がある。前述のタイムラグよりも長い期間が必要になる。
- __質的違い__ ：邦訳されるドキュメントの観点や粒度などがニーズに合ったものとは限らない。
- __カバー範囲__ ：どれだけ邦訳が活発でも原典を枯渇させるほどの量・速度に達することは現実的にありえない。ましてStackOverflowやGitHubのIssueが翻訳されるのを待っていても無駄。
- __翻訳の品質__ ：翻訳版が一字一句妥当とは必ずしも言えない。

こうした不利な状況をある程度緩和するには、原典にあたる必要があるのは言うまでもないことだと思います。
邦訳では手に入れることができない情報を、原典に当たることで手に入れることができるのです。
これはようするに生産性に直結します。

これだけでも十分という気がしますが、もう少し視点を広げてみましょう：

- __チーム貢献__ ：原典に当たって得られた知識の口伝でチームの生産性に貢献ができる。
- __育成・ステップアップ__ ：原典に当たることで理解が深まり後進育成やステップアップの土台となる。

ちょっと現金な話をすると、何かについて「知っている」こと、そして何かについて「一家言を持っている」ことは、（その「何か」にたしかな需要がある限り）そのまま周囲に与える影響力を増すことに繋がります。
結果的にあなたの意見が通りやすくなったり、有望な人材が周囲に集うようになれば、これもまた生産性に繋がります。

訳出も加えたらどうでしょう：

- __より深い理解__ ：「読む」だけではできなかった（せずに済んでいた）より深い理解ができる。
- __組織貢献__ ：チーム、会社、コミュニティへの貢献ができる（満足感、自己実現、アイデンティティ）。
- __バリュー__ ：「貢献」を公開することで自身のバリューを示すことができる（スカウトされたり）。
- __コミュニティ資産__ ：訳出することで分野／コミュニティで参照できる情報資産が増える。
- __コミュニティ人材__ ：訳出を読んでもらことで分野／コミュニティに参画できる人が増える。

分野／コミュニティのリソース（ひと・もの）が増えれば、回り回ってそれがあなたの仕事にも良い効果をもたらしてくれることもあるでしょう。
してみると、組織やキャリアの観点からすると、自分が挑戦するだけでなく、自分の同僚や部下にも挑戦を勧めることが必要ということにはならないでしょうか？

幸いにもここ数年、有名どころのプロジェクトについては、比較的よく整理され、使用語彙数や構文にある程度気配りしたドキュメントを公開する傾向が強まってきています。
翻訳を助けるオンラインの辞書も増え、機械翻訳の精度も翻訳の参考にできるくらいには良くなってきました。

まだ挑戦したことのない方は、決して楽な道ではありませんが、ここまで見てきた各種のメリットを踏まえて挑戦してみてはいかがでしょうか？
すでに挑戦されている方（私のように）は、ぜひ周囲のメンバーに誘いをかけてみてはいかがでしょうか？