diff --git a/contributor/ja/02-becoming-a-contributor-article-ja.asciidoc b/contributor/ja/02-becoming-a-contributor-article-ja.asciidoc
new file mode 100644
index 00000000..1cc40750
--- /dev/null
+++ b/contributor/ja/02-becoming-a-contributor-article-ja.asciidoc
@@ -0,0 +1,69 @@
+== InnerSourceコントリビューターになる
+
+InnerSourceのコントリビューターは、通常のチームの境界外で活動し、組織のサイロを横断するリンクになります。
+そのため、彼らはこの作業をより効果あるものにするための、いくつかの共通の方法を意識する必要があります。
+
+=== マインドセットの共有
+
+それでは - あなたはチームの製品に、新しい機能を実装しています。
+この機能を動作させるためには、いくつかの機能が必要です。
+実装に直ぐに取り掛かる代わりに、少し落ち着いて考えます：この機能は一般的な課題なのだろうか？
+それは、あなたの組織の他のチームが共有するビジネスドメインで同じように直面しているものなのか？
+この機能は、あなたのプロジェクトのドメインと直交するものなのか？
+もし当てはまる場合、自分のチームを超えて見渡して：あなたのニーズにフィットするために利用したり改善できる共通のソリューションがあるのか？
+あるべきなのか？
+
+=== ソリューションを共有するメリット
+
+アフリカには、 "`早く行きたいなら一人で行きなさい。遠くに行きたいなら一緒に行きなさい`"　という諺があります。これは、ソフトウェア開発チームにも同じです。
+
+もし、早く進みたいのであれば、依存関係を壊すことは良いアイデアです。
+この欠点としては、重複した作業になることです。
+とりわけ、コアロジックを再実装する時には、重複することのコストが独立性のメリットを上回る、非常に現実的なリスクがあります。
+
+他のチームとコラボレーションすることで、開発コストを共有できます。
+オープンソースプロジェクトと同様に、あなたが一人で成し遂げられるより大きな何かを、あなたのチームが作ることを可能とします。
+
+しかし、それぞれのチームには異なるロードマップがあります！
+私は以前、共有のコンポーネントを使おうとしました - それらを再実装するよりも統合することに時間がかかりました。それらのコンポーネントは常に何か欠けてました。 -　それに、私の機能リクエストは他のチームのロードマップで優先的になることはありませんでした！
+
+従来のプロジェクトと比べると、InnerSourceのプロジェクトにはコントリビューターの役割があります。
+あなたは共通のソリューションに新しい機能があればと思うこともあるでしょう。
+コントリビューターとして、あなたにはソースコードをチェックアウトして変更を加え、改良したバージョンを利用する自由があります。
+
+あなたのタイムラインで、ホストチームでは同じ優先度を持たないバグの修正が緊急に必要になることもあるでしょう。
+コントリビューターになることで、あなた自身が行動し、ホストチームをバグ修正でサポートすることができるようになります。
+
+この作業方法は、多くの点でマインドセットの変更が必要となります： 機能やバグの修正を待つ代わりに、問題を回避する代わりに、そこには第3の解決策があります。あなたの時間や労力を費やしてInnerSourceプロジェクトにおけるあなたのニーズを確認し - それから共有されたプロジェクトに直接変更を加えます。
+そして、あなたにはコーディングスキルに加え、InnerSourceプロジェクトで成功するためのコミュニケーションスキルが必要です - あなたのニーズを明確化し、あなたのチームとホストチームの両方で機能するソリューションを実現するために。
+
+"しかし、私はプロジェクトをフォークして、そこに変更を加え、この調整のオーバーヘッドから自身を守りました！"
+確かに、プロジェクトをフォークすることは、あなたの仕事を終わらせる方法です。
+長期的な場合を除いては、これはあなたのチームがフォークしたバージョンをメンテナンスし、ホストチームが作成する新しいリリースのいずれにも、その変更を追随させる必要があるということを意味します。
+あなたの変更をホストチームにコントリビューションすることは、彼らのコンポーネントに関するより深い知識からメリットを得られるということも意味します。
+彼らは、本番でしか明らかにならないようなパッチの問題を明らかにするかも知れません。
+
+優れたコントリビュータは、作業を複製する代わりに依存関係を導入してコンポーネントを再利用することが技術的にもビジネス的にも意味がある時に、気軽に声をかけることができます。彼らは、InnerSouceコントリビューションのメリットを説明するために、マネージメントに話をすることができます。
+
+=== InnerSourceコントリビューションのスコープ
+
+では、Inner__Source__ とは、__ソース__コード だけのことなのでしょうか？
+もちろん、違います。
+もし、あなたのチームのビジネスが外部のコンポーネントに依存していたら、あなたはそれが適切にメンテナンスされ動作することを確認したいでしょう。
+InnerSouceのコントリビューターとしては、あなたはホストチームを複数の方法で支援できます。
+コンポーネントを利用している際の問題を報告することは、価値あるコントリビューションです。
+コードが期待通りに動作していないことを示すテストケースを作成したり修正することは価値があります。
+そして、ドキュメントを改善することは、他の人がそれを利用したりコントリビューションしたりするために費やす時間を少なくします。
+他のユーザをサポートすること、バグのトリアージを支援することは、価値あるコントリビューションです。
+ビルドの改善も、価値あるコントリビューションの例です。
+
+要約すると、どのようなコントリビューションでも、小さすぎるということはありません。
+これは私が https://github.com/tensorflow/models/pull/4784[tensorflow/models] に対して作成したものです。
+単純なグラフのラベル変更です。
+
+=== この記事のまとめ
+
+この記事では、コントリビュータになるために必要なことについて学びました。
+私達は共有のマインドセットを見ました。
+ソリューションを共有することのメリットについて深く掘り下げました。
+最後に、InnerSourceのコントリビューションのスコープが、一般的にどのようなものとなるかを見てみました。