palanが技術スタックを選ぶ基準

はじめに

palanではクライアントワークと自社サービス開発を行っています。
使用している技術はサーバサイドはバックエンドはRuby on Rails、AWSやFirebaseのサーバレス、Blitz.jsなどです。フロントエンドはWebはReact、アプリはReact Nativeが中心です。

割とReact Nativeが世に出回っていなかった時期から多くのアプリを開発したり、サーバレスやTypeScriptも割と初期に取り入れていますし、Blitz.jsにおいては恐らくプロダクションで動いているのは国内初では？というくらい、モダンスタックを選定する傾向にあります。

※Blitz.jsを用いて開発しているpalanKit。新規事業担当者向けのフレームワークキットサービス。

palanがどういう基準で技術スタックを選んでいるか書いていきます。

「その技術を選ぶことでどんな学びがあるか」を重視する

palanでは常に社員、チーム、組織として成長できるかを重視しています。
その為にも各プロジェクトで選んだ技術が知見になるか、学びとなるかを重視します。

基本的には自社サービスで技術的なチャレンジを行い、その知見をクライアントワークに活かすことが多いです。
※その為に自社サービスの本数は多く大小合わせると20本以上は出しています

例えば4年前、クロスプラットフォーム開発としてReact Nativeに可能性を感じ、アプリ開発自体の実績がない状況から取り組み始めました。
React Nativeではネイティブ層を一切意識しないかというとそんなことはなく、iOS、Androidのネイティブやリリース周り、またAtomic Designによるコンポーネント分割などを学習しながら開発していきました。

※React Nativeの知見とする為に開発した自社サービス「ゆるっぷる」。今では5万ユーザ以上おり、日経トレンドにも2021年のトレンド予測に上げられるほど勢いがあります。

その後にもexpoを使った開発で効率化できないか、研究する為のサービスを開発し、その後にクライアントにも提供しはじめました。

闇雲に範囲を広げることが正しいとは言えませんが、イメージとしてスタックのポートフォリオを広げながら、周辺技術も個人・チーム・会社の知見としています。

ちなみにそんなアプリ開発における新興勢力だったReact Nativeも、今ではFlutterのほうが優れている点が多いという方も増えてきましたし、だいぶ勢力図が変わってきた感じがあります。
技術の流れは本当に速いですね！

「その技術に未来があるのか」を重視する

新しい技術であれば全てが良い、というわけでは当然ないです。
その技術の設計思想や実装は、本当に今の世の中に今後広まってきていくものか？今は未熟で課題があっても、今後未来があるのか？を重視しています。

また「誰が開発しているのか」もとても重要なポイントです。
私達が使用しているAR.jsというライブラリはメインコントリビュータが居なくなってしまい、開発がストップしていた時期があります。
※結局他のコントリビュータの方々が引き継ぎ、今では安定して開発が行われています。

React NativeはFacebook社製ですし、InstagramやShopify、Discordなど名だたるアプリ開発に使われています。
開発コミュニティが盛んであればアップデートも頻繁に行われ、より良い技術を目指すことができます。

ちなみにpalanでは国内コミュニティや翻訳ドキュメントの有無は正直そこまで気にせず、むしろ英語リソースを中心に読み進めています。

「その技術は本当にクライアント（ユーザー）に価値を届けるものか」を重視する

「モダンな技術であればあるほどクライアントやユーザーが喜ぶ」なんてことはありません。
むしろメンテナンスをする技術者がいない、バグが多いなど問題点も多くあります。

技術はそれ自体が目的ではなく、あくまでも手段の1つです。
目的である「サービスや事業の成功の為にその技術が寄与できるのか」を意識しています。

React Nativeはクロスプラットフォーム開発により、（制限はあるものの）シンプルなアプリケーションであれば圧倒的に双方の開発を別々に進めるより工数が低くなるだろう、社内のスタックをJSに揃えることで安定的に価値を提供することができるだろう、と考えて取り組んできています。

自社でも全てが完全なモダンではなく、「今回のプロジェクトの構成を考えるとRailsで非SPAでいこう！」という決断も多くします。あくまでもクライアントやユーザーへの価値提供を第一に考える為です。
むしろ「SPAであることでユーザーに価値を与える」場合でない限り選択しません。

ただし、目的と手段を取り違えないようにしつつも、モダンな技術はその思考の根底に「今までの開発体験では解決できなかった問題」への解決策を含んでいることが多いです。
それが本当にクライアント（ユーザー）に価値を届けられるものか、リスクと天秤にかけながら技術を選定しています。

今モダンな技術もいつかはレガシーとなる

プロダクトライフサイクルという考え方があります。
どんなプロダクトも導入期・成長期・成熟期・衰退期という時間の流れとなります。

これが技術スタックのライフサイクルにも当てはまるのではないかと思っています。
もちろん使用される頻度が価値ではなく、コミット数やコントリビュータ数では？などあるかと思いますが、定性的なイメージの図となります。

あれだけ持て囃された例えばFlashも2020年12月31日を持って終了しましたし、Parse.comの終了なども記憶に新しいです。

一方、衰退期にあっても長く使われる技術も多くあり、例えばjQueryはWeb制作者周りでは未だに根強い人気を誇りますし、COBOLも今も多くの現場で使用されています。

レガシー＝悪では決して無いですし、むしろ出来る限り息の長い技術を使いたいとは思いますよね。

指を加えて浸透を待つのか

では「導入期や成長期はリスクが大きいので成熟期になるのを待つ」というのが正しいのでしょうか。
これは会社によってスタンスは違うと思いますが、例えばその技術スタックでの開発自体をブランディングにするのであれば、導入期の技術自体が他社の差別化要因になるかもしれません。

また多くの技術はオープンソース化されています。
「こういう周辺ライブラリが無い」や「日本語ドキュメントが無い」といった文句ばかりを言い、「だからこの技術はイケてない」と判断するのはもったいない気がします。

技術本体へのコントリビュートはもちろん、周辺ライブラリや翻訳をしたり、コミュニティを持つことも浸透への貢献です。
これが日本の企業だから、日本人だからできない、なんてことは当然なく、「この技術を育てていく」に近い感覚を持つのが大事なのではないかなと思っています。

結局最後は根性論になりますが、「その技術でやりきれるのか・やりきりたいと担当者が思えるのか」が一番大事なのかなと思っています。

最後に

palanでの技術スタックの考え方をご紹介しました。
デザインツールや思考においても同じスタンスですし、今後は事業拡大に伴いビジネス面でも同じような概念を浸透できたらと考えています。

今でもいくつかライブラリなど作ったりしていますが、いずれは自社独自のフレームワークも作れたらいいなぁとか考えています。

まだまだその域に達することはできていませんが、これらのスタンスや自社のビジョンである「世界的に、技術的に偉大な会社を創る」に共感していただける方は、ぜひ気軽に話を聞きにきてください！