React Nativeの「(not) for you」を伝え続けた2019年を振り返る

2018年の夏に「React Nativeはメリデメ両方デカすぎて、気軽に採用すると事業や組織とのミスマッチを起こしやすいので、マッチしてるかどうか考えてから採用しましょうね」という話をしました。

blog.nkzn.info

このときは雑多に問題提起してしまったので、具体的なモデルケースを想像しづらいものになってしまっていました。

そこに課題意識を持った私は「2019年はRNにマッチしそうな事業（プロダクト）や組織（チーム）の姿を伝え続ける年にしよう」と位置付け、各所でその方針に基づいた情報発信を行いました。

人材調達の難しさに目をつけた第一弾

その第一弾として、ちょっとフライングして2018年末に公開されたのが次の記事です。

codezine.jp

• 「どうせビジネスサイドは3プラットフォーム出したいっていうじゃん」
• 「でも本当に3プラットフォームそれぞれの作法を理解してる人をそれぞれ集められるの？」
• 「UI作法（ライフサイクルとか）だけでもWebに寄せたほうが、採用するにせよ育成するにせよ楽なんじゃない？」

という切り口で導入を書かせてもらいました。これを言語化できたおかげで、良いスタートダッシュが切れたんじゃないかと思っています。

さらにターゲットを絞った第二弾

第一弾の時点では「ふーん、そういう分野もあるかもね（私には関係ないけど）」くらいの認識になりそうだったので、もう少し明確にターゲットを絞って刺しに行ったのが、第二弾のMOBILE CREW NIIGATAでの発表です。

speakerdeck.com

• 「B2B(2B)だと操作マニュアルとかユーザーサポートが必須だけど、もし楽にUIを揃えられるならサポート部門の負担がちょっと減るでしょ」
• 「できる人を外から連れてくるような人材流動性はなくて、たまたまいた器用な人を育てたほうが現実的でしょ」
• 「どうせなら潰しの効くスキルを覚えさせたいでしょ」

という切り口を追加して、「そう！　お前ら！　お前らに必要なソリューションなんだよ！」感を出してみました。

集大成の第三弾

第一弾で打ち立てた方向性を元に、第二弾で深く言語化することができましたが、技術的な詳細を見ても魅力的であることの紹介が疎かになっていました。

というわけで、技術的な特性の話題も加味した集大成として書いたのが、第三弾でエンジニアHubに寄稿した記事です。公開は2020年になりましたが、2019年の11月ごろに書いてました。

employment.en-japan.com

• 技術的なイメージが付けやすいように具体的なコードや内部実装の話も重視した
• 巨大なエコシステムの支援を得られることをイメージしやすくする
• ビジネス要件としてクロスプラットフォームが求められている現場があることを改めて強調する

この記事で気をつけたのは上記のようなところでした。悲壮感の漂っていた第二弾を裏返して、ある程度ポジティブな味付けにしたつもりです。

三部作の後書き

やっている最中は「結局ずっと同じことの話をしているけれど、読者の方は飽きないだろうか」と思っていました。しかし、こうして振り返ってみると、話題の切り口が違うのでターゲット読者も違っているし、媒体が違うので届くチャンネルも違うし、ということで、かなり広く話題提供ができたんじゃないかと思います。

全部読んでくれている人はエンジニアHubのあたりで「またこの話か」と飽き気味になっていたかもしれません。これは素直にすいませんでした。

この1年で生み出した3部作は、もちろんReact Nativeの大成を願ってのものです。しかしながら、読んだ人にはわかるとおり、「多くの人にReact Nativeを使ってほしい」というものではありません。「こんな状況の事業・組織には、React Nativeは役に立つ可能性がある（for you）」をハッキリと伝えることで、「そういう状況にない事業・組織では役に立たないかもしれない（not for you）」がある程度浮き彫りになるような作りにしたつもりです。

Android SDK + KotlinやiOS SDK + Swiftでアプリをそれぞれ作ったほうが、顧客に対して出せるバリューが大きくなるプロダクトというのは当然ありますし、それを実現するためのチームが無理せず構築できるならば、React Nativeのようなクロスプラットフォーム技術はnot for youであるはずです。無理にクロスプラットフォーム技術などという巨大なフレームワークを採用して苦しみを抱える必要はないでしょう。

ただ、世の中でそういったチームを構築できる企業というのは、そんなに多いのだろうか、という疑問を、第一弾を書きながら思ってしまったのです。

「採用は人事や経営の仕事だからITエンジニアの自分が扱うべきスコープではない」と言ってしまうのは簡単ですが、採用が上手くいっているわけでもないのにユニコーン企業の技術選択やチームビルディングだけをカーゴカルト的に真似しようとしたところで、苦しむのは自分たちなのです。

様々な事情があるとは思いますが、「（まだ）お金が潤沢にない」「（まだ）十分な数のメンバーがいない」という状況において、React Nativeはfor youなツールになりうると私は思っています。また、そういった状況になくても、純粋にReact Nativeの技術特性が事業にとって好ましいと判断されれば、時雨堂さんやDiscord iOSやNature Remoのように、腕力のある器用な人々が扱う前提で採用されることもあります。

自分が関わっている事業と組織の課題と向き合ってみて、そのロードマップの途上にReact Nativeが役立ちそうな場所があれば、採用してみることを検討してみてください。そのときに私の書いた記事たちがお役に立てたなら、検討の結果がfor meでもnot for meでも、それはとても喜ばしいことなのです。

余談：他のX-Platを扱う方々へお願い

私はReact Nativeが手に馴染んだことによって見えた景色（観点）があったので、それを言語化する目的で記事を書いています。React Nativeが他のX-Platより優れていることを示すために書いた記事は（おそらく）ありません。（極めてfor meではあるものの、優れているとは思っていません）

私はFlutterやXamarinやIonic（Capacitor）をほとんど使ったことがありません。使ったことがないもののことを偉そうに解説することはできないので、私はこれらについて、今回の三部作のような語り口で解説することができません。

しかしながら、私の書いた三部作は、多くの部分でX-Platツールに共通の観点を含んでいると思っています。

私は技術選択が大好きなので、Flutterは、Xamarinは、Ionic（Capacitor）は、その特性によってどんな事業（プロダクト）と組織（チーム）にマッチするのかを誰かが記事にしてくれたら、喜んで読みます。結果的に僕の記事と似てしまっても全然構わない（むしろdiffが際立つ）ので、読みたいのです。

というわけで、誰か記事を書いてください。私からのお願いでした。