今回は新米フロントエンドエンジニアが技術選定をやってみたらリジェクトされた話を書いていきたいと思います。まったく知らない観点が出てきたので、悲しみながら勉強をしていました。ちょっとだけRecoilの話を書いていきたいと思います。

初めに

どもども～二年目になって初めての投稿です。この投稿で30本目の投稿になる龍ちゃんです。先週はホームパーティを開催して、へべれけになっていましたね。良いサーモンを買ってきてもらったので、おいしいサーモンポッキが食べれました。メインはナチョスだったのですが、全力で余ってしまいました。ここから三食はナチョス食べてましたね。

休日に大量のお酒を飲んだので内臓としては休んでいないのですが、体は休んだので今週も頑張っていこうと思います。と言いつつ今週も終わりの金曜日に加筆しています。

さて、本題です。今回は、「技術選定で本番環境でRecoilを使いたいと言ったらリジェクトされた話」をメインで書いていきたいと思います。リジェクトという単語は心に来ますよね。しっかりとした技術選定は初めてだったのですが、自分に足りていない知見からぶん殴られました。非常に楽しかったです。

それでは順を追って記録を取ろうかと思います。

リジェクトされるまで

とりあえずプロジェクトについて振り返っていく必要があります。プロジェクトのMTGに出ていたらPoC（概念実証）という単語が出てきました。要するにデモサイトを作って欲しいとの依頼ですね。PM・バックエンド・フロントエンドそれぞれ一名ずつの少人数チームで二ヵ月弱のプロジェクトという話だったので、小規模なプロジェクトなんだな〜と思いながら参加していました。それが進んで、現行で動いているシステムとの差し替えになるという話まで進んだわけです。フロントエンド担当者が一人ということで、好きに技術選定を行っていました。プロジェクトのお話が大きくなったのを機会に技術選定の見直しを行ってレビューを依頼したことが今回の話の始まりです。

突然ですが、Reactの状態管理にどんなライブラリを使っていますか？Reduxとかが有名な話だと思うのですが、今は別の会社に移った師匠が「Recoil使いやすいよ～」と言っていた気がしたので、勉強もかねてRecoilを採用していました。Recoilのリポジトリを見てみるとAboutの欄に以下の英文が記載されています。

Recoil is an experimental state management library for React apps. It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.

https://github.com/facebookexperimental/Recoil

要約すると「実験的なライブラリだからバージョンアップしたら壊れる可能性もあるで～責任はもたんけどな！」という文になります。確かにバージョンを見てみると最新バージョンが0.7.6でセマンティックバージョンを適応されていると考えるとメジャーアップデートが来ていないということになります。ちなみにセマンティックバージョンという言葉も知らなかったのでMTGで初めて知りました。

初回は会社での立ち話相談会でした。上司と目があったんで「せっかくだから意見聞こっ！話したいし」と軽い気持ちで相談しました。すると、「今回はRecoilダメかもね〜」というジャブをもらいました。もうその一言で作り直しの規模算出が頭の中で駆け巡りましたね。作るだけなら10時間ぐらいでできるな〜と思ってました。ちなみにプロトタイプだったので、本番用に作り直すことが決まってたので作り直すことは全然問題なかったです。

でも悲しいじゃないですか？

とりあえずあきらめることができなかったので、立ち話でリジェクトされた話をSlackでも展開してみました。その時送った僕のSlackを下に置いておきますね。同じ話を二度するのも申し訳なかったんですけど立ち話だけだと、ログに残らないですからね。こういう時は口頭と文面の両方で置いておくようにしています。

状態管理ライブラリとして英語・日本語両方で調査しました。
[npm trands](https://npmtrends.com/recoil-vs-redux)では、Reduxの方が圧勝です。これはライブラリが開発された年がやはり影響大です。
追加で調査して結果では、RecoilではMeta社が開発している実験的ライブラリということは変わりません。
その一方で、Reactのエコシステムとの相性が高いのがRecoilの特徴であるようです。やはりReact18からの新機能をサポートしているのはRecoilの利点です。
状態管理としてSWRを使用するといった方法もありますが、手元の検証では

- Reactとの競合でレンダリング部分での若干のちらつき
- エラーハンドリングの正確性の担保ができない

また、SWRではキーを指定して値をキャッシュする方法で値を保持しているようです。その点でSWRで状態管理に使用することはあまり実用的ではないとの感触でした。
ちょっと実用レベルでの問題点では、状態をどこで保存するか程度しかなったですが周りの意見を聞きたいところです。
Recoilの事例では以下二点見つかりました。
- https://speakerdeck.com/uhyo/sutetoguan-li-wochao-erurecoilyun-yong-nokao-efang?slide=24
- https://engineering.linecorp.com/ja/blog/line-sec-frontend-using-recoil-to-get-a-safe-and-comfortable-state-management/

海外の言及です
- https://medium.com/geekculture/redux-vs-recoil-16fbdb0b0a52
- https://www.syncfusion.com/blogs/post/recoil-the-future-of-state-management-for-react.aspx
- https://www.imaginarycloud.com/blog/recoil-vs-redux/

これ送った後でも、「多分リジェクトされるだろうなぁ～」と思っていたらきれいな論点整理でストレートリジェクトされましたね。リジェクト原文を以下に置いておきます。

課題のポイントがずれてしまっていますね。課題は、RecoilがExperimentalという開発ステータスであることなので、龍之介さんが共有してくれた機能面、コードサイズ等々の比較に言及している情報では判断の材料にはなりえないですよね。
エンジニアがその技術を使用したいという目的は、機能面に目が行き勝ちですが、大前提として顧客のためになることが求められます。OSSを使用する場合のリスクとして、大きく3点あります。

１．開発継続性
いつ開発が終了するかはわからない。知名度の高いOSSであっても中身は1名、2名で開発されているOSSもあって、実際に急に開発終了するケースもあり。近年の超有名どころだと、yum が開発者の死去に伴い、誰もメンテできず開発終了となった。

２．不十分なサポート
バグ、脆弱性に対して修正されることが保証されない。

３．ライセンス
PJの性質にもよるが、Recoilで言えばMITなので問題にはならない。

例えば、趣味の世界であったり、自分たちのサービス開発であれば、先進的な機能を使用できるメリットを優先して、自分たちでリスクを抱えるという判断はありですが、お客さんのシステムを作るSIではあってはならない判断です。ちょっと話がそれますが、私は過去にプレビューなライブラリをあえて採用したことがあって、不具合や脆弱性があった場合、forkして自分たちでメンテするという前提で採用しました。仮にメンテするようなことになっても、そのライブラリを使用することでの開発コスト効率化の方がおそらく大きくなるという試算だったためです。実際バグが出て自分たちでメンテしましたが、ねらい通りトータルコストは下げられました。スキル、工数、覚悟が必要ではありますが、OSSを使う本質的なメリットはここです（もちろん、この判断が適切かはPJによります）。
というわけで、今回の判断のポイントは下記ですね。

Recoilの脆弱性、不具合対応時の工数は読めるか？その工数は、Recoil採用することでの開発効率の向上による削減工数と比べてどうか。
あるいは、Recoilのコミュニティが一定の開発継続性を持っていることを示す客観的な事実があるか。
ここを整理して、お客さんと交渉できる話になるかですね。この点いかがですか？

ちなみに、Recoilの開発継続性についての話をすると、
Recoilは開発ロードマップを示していないプロジェクトです。下記を見る限り、PJ自体、停滞していて、継続を危ぶむ声も出ていますが、2022年1月からMeta社のエンジニアは回答してない状態です。他エンジニアも商用に使えない、Recoil開発者の反応もないから、別ライブラリを採用したなんてやりとりもされています。
- https://github.com/facebookexperimental/Recoil/issues/691
- https://github.com/facebookexperimental/Recoil/issues/1495

もうきれいなストレートでノックダウンでしたね。もう違うインターネットにつながってるんじゃないかな？ってぐらいジャストな言及が飛んできたので納得しちゃいました。

リジェクトして初めて知ることができる「技術線的に必要な観点」ですね。ちなみにこのメッセージを理解するのに5分かかりました。5分後には、タオルが宙を舞っていたわけです。何がすごいってもし導入するならこういうリスクもあって、今回ならこういう場合なら導入できるよという部分にも言及がもらえたところですね。送った文面の返答だけで終わらないのがうちのかっこいい上司です。

せっかくの機会というか、大事な話なので、仮にRecoilをメンテできるスキルを持っていた場合にはどうなるか、という話をしておきます。
結局メンテするのに工数が発生します。その費用を誰が出すかという話でいくと、今回だとお客さんになります。請負であれば、我々の持ち出しですが（それはそれで内部にリスク抱えてよいのかという判断は社内で必要）、今回のような準委任契約の場合、我々は契約不適合責任を負わないので、Recoilに問題があって修正する場合、その費用はお客さんが負担することになります。我々がリスクのあるとわかっているExperimentalなライブラリを選定しておいて、リスクが顕在化した場合にはお客さんに費用請求というのはヤクザなビジネスですし、お客さんからすればITの専門家としてのSIOSの信頼は下がりますよね。
なので、今回の契約形態で言えば、Recoilを採用できるのは、結局のところ下記のみです。

- お客さんがリスクを認識した上でRecoil採用を承諾する。

どうあれ、お客さんのリスクになるので、我々はそのリスクをご説明した上でお客さんに判断いただくということになります。どんな時もエンジニアは説明責任を果たすことが求められます。Recoilのコミュニティが一定の開発継続性を持っていることを示す客観的な事実（リスク顕在化する確率の低さ）があるとか、開発効率の話とかは、採用を決めるポジティブな判断材料にはなるかもしれませんが、結局はお客さんのリスクでしかないので、お客さんがどう判断されるか次第です。
最後に、結局これらのリスクは、OSSを使う時点で伴うリスクなので、考え出すと3rd-party怖くて使えないなんてことにもなってくるので、誤解のないように念押しすると、世の中的にOSSを活用するのが一般化してきて、お客さん側もOSSのリスクとして承知の話です（お客さんによっては3rd-partyなライブラリを採用する基準を設けていることが多い）。ただ、Experimentalとなると、また別の話で、OSSのリスクが顕在化する確立が高まってくるので、提案するにはお客さんが納得できる説明を果たすことが前提になります。

余談ですが、近年、OSSの無視できないリスクとして、SBOMが非常に盛り上がってきていますので、この観点が採用基準に入ってくる可能性は今後高いですね。日本は遅れていますが、世界的には基準を設けているところも多い印象です。

なお、準委任については2020年の民法改正で新設された成果完成型では、完成責任と善管注意義務を負うので（請負に近くなった）、その場合は注意が必要です。Experimentalなライブラリ選定が善管注意義務違反になる可能性は十分にありますが、今回は成果完成型の準委任ではないので、従来型の工数精算の前提での話です。

どうやったら採用できるかという部分においても解説を入れてもらったので、今後の技術選定時には印刷してデスクに張っておく必要がありますね。

ちなみに僕の小さな反抗は四行分ぐらいあるんですけど、観点と論点が違うことにあとから気づいて恥ずかしくなったので載せませんw

それでは次の章で技術選定に必要な観点をまとめておこうと思います。

技術選定に必要な観点

今回の助言をまとめると以下になります。

先週、リジェクトした上司と一緒に飲んでるときに裏で「神」と呼んでいることをご本人に伝えたので、その気持ちをデザインに反映したかったのですがデザインに落とし込むことができないのでシンプルにデザインしておきました。それでは観点ごとにざっくりとライトな説明を入れていきたいと思います。

開発継続性は、採用したライブラリが「現在でも開発が続いているかどうか」・「これからも開発されるか」といった観点になります。特にフロントエンド界隈では3年ぐらいたつとトレンドが変わったりすることもあり開発のスピードが重要になります。というか5年前の日本だと「React VS Vue」みたいな話を見ていた気がしたのですが、最近はReact一強なんじゃないかという感じになっていたりしますね。おんなじReactを使っていてもバージョンの違いで設計方法が違うという話もあるみたいです。それだけ開発が続いているかどうか、メンテが継続的にされているかどうかといった話は重要になるそうです。

サポートの有無は、公式のリファレンスが充実していることだけでなくコミュニティが活発であるかどうかも重要であるようです。GitHubのスター数やIsuueの数でコミュニティが盛り上がっていることが図ることができます。コミュニティが盛り上がっていれば同じ問題にあたっているエンジニアがいる可能性がありますし、問題が起きてどこかに書き込めば強つよエンジニアが救ってくれる可能性がぐんと上がります。もしなかったら、公式のソースを読み込まないといけないという地獄が始まってしまいますね。自作ライブラリで地獄に陥るSIerの話はどこかで聞きましたね（確か飲み友達の先輩ですね）。

ライセンスは、有償か無償かどうかといった話ですね。勝手に使ってしまったら問題になるのでライセンスと著作権はしっかり気にしておきましょう。

最後に説明責任になります。これは今回痛感させられましたね。トヨタ自動車では5つのWhyを重ねるそうです。でも観点を間違えると想定していないところからぶん殴られるので、論点だけは間違えないように話さないといけませんね。技術選定で説明をするためには、ほかのライブラリについても同様のレベルでの調査が必要とのことです。説明するための調査なので、エンジニアには調査と説明がつきものということで頑張っていきましょう。

リジェクトされてからの動き

とりあえず、金曜日にジャブを打ったときに上司を二人飲み会に誘っておきましたね。やはり戦う前にはご褒美を用意しておくべきです。さて、技術的な話を書いておきます。

Recoilは状態管理の話だったのですが、それの対比で出てくるのはReduxになります。とりあえず、Reduxの評判だけ調べておきましたね。やみふかーい記事が多く出てきていましたね。

なので、ライブラリを選定するために前提の見直しを行いました。プロジェクトでどういった場面で状態管理が必要かということですね。そこから考えたこととしては、そんなにがっつり状態管理する場面は存在しないということに行きつきました。基本的にAPIから取得した情報をほかのところでも使えるようにしたいだけだったので、データフェッチライブラリで用が足りそうということです。

という訳でリジェクトされそ～とか思って出したSlackの前にデータフェッチライブラリであるSWRの技術検証をある程度終わらせておいた僕はすごく偉いということですね。

終わりに

いや～今週はブログをなかなか書くことができない週でした。ですが、くそみたいな文章でも書き続けることが必要だと思っています。内容が悲しい内容だったので気分が乗らなかったことも関係しているかもしれませんね。なかなか勉強になる内容だったので、また一つ心に刻んでいくことが増えました。これからも勉強をしていきましょう。

ちなみに僕のブログにこの上司が出てくるのは2回目ですね。コードレビューをしていただいた上司です。そのうちこれだけでシリーズ書けるんじゃないかな？とも思っています。ちなみにもう一人、めちゃめちゃお世話になっていて大好きな直属の上司がいるのですが、技術的なことよりも人生やプロジェクトの進め方について話す機会が多いので、ブログのネタに昇華しにくいのですよね。そのうち一緒に飲みに行った記録でも出しますw

とりあえず、今関わっているプロジェクトを全力で解消していく必要がありますね。やはりプロジェクトに関わることで技術力は上がっていきますね。最近はTailwindばかり書いていたので、書くスピードがすごく上がっていきます。心は徐々に疲弊していくのですけどね。

まぁ泣いてもコードは作られないですからね。でも最近はGitHub Copilotを使えば楽にコードを書ける説があるので、ちょっと検証しますね。

まぁ心のうちを書いてないでコードを書きましょう。ではまた～