Re.Ra.Kuで使われているプログラミング言語とその選択理由 - Re.Ra.Ku アドベントカレンダー day 17

丸山です。

アドベントカレンダーも17日目、だいぶ佳境に入ってきましたね！本日は弊社ではどのようなプログラミング言語が使われていて、そこにはどのような判断が働いているのか、ということについて書いていきたいと思います。

iOSアプリケーションと Androidアプリケーションの開発言語

iOSアプリケーションとAndroidアプリケーションの開発には、Swift(古いものは一部Objective-C）、AndroidアプリケーションはJavaで書かれています。プラットフォーマー（GoogleとかAppleとか）がサポートする環境に素直に乗っている形ですね。

ネイティブアプリの開発にはそんなに選択肢があるわけではないのですが、Xamarinに乗ってC#、あるいはReactNativeでJavaScript、Kotlinを利用する、など、プラットフォーマーが公式に用意した環境以外にも選択肢があります。

公式の用意する環境に乗ると、「そもそもJavaの表現力が……」とか「NSFoundationつらくない？」とかいろいろなデメリットがある一方、そうでない環境には「慣れ親しんだ言語で書ける」とか「AndroidとiOSで一部コードを共有できる」とか「高い表現力を持つ言語で書ける」とかいろいろなメリットがあります（CocoaTouchを理解しなくていい？それは幻想です）。

一方で、プラットフォーマーが用意したものではない環境には「MSが飽きたら終わり」「Facebookが飽きたら終わり」みたいな怖さもあります。また、どこかでプラットフォーマーの用意する環境へのブリッジが必要になり、ある意味「一枚余計なレイヤー」が発生することになります。組み合わせる技術要素は多くなれば多くなるほどトラブルの原因は増えます。

そのようなことを考えると、プラットフォーマーが用意したものではない環境に乗ってしっかりと開発するためには、プラットフォーム依存のフレームワーク（CocoaTouchとかAndroidSDKとか）に対する深い理解だけではなく、その環境に対する深い理解も必要となってきます。

なので、技術選定には、このコストを支払うことができるかどうか、というのがかなり重要なポイントになってくると思います。「俺はめちゃめちゃC#が得意なんだ、C#の中身ならなんでも知ってる」という人がすでにメンバーに存在する、とか、「ReactNative？中身全部読んだよ。俺の書くJavaScriptはめちゃめちゃメンテナブルだしな」みたいな人がすでにメンバーに存在する、とか、そういう「強み」がすでにある場合ならば、このコストを支払うのは問題にならないかもしれません。あるいは、サーバーの運用などに関してもC#やnodeJSのプロフェッショナルがいて、なおかつ少ないメンバーですべてのレイヤーを見なければいけないなどの場合、一気通貫で同じ言語で開発したい、という強いモチベーションが生まれたりすることもあるでしょう。そのときには、「このコストを支払ってでも統一言語でやっていく」というのは合理的な選択になりそうです。

弊社の場合、すでにiOSのプロフェッショナルとAndroidのプロフェッショナルがメンバーにいるので、そこであえて他のプラットフォームの乗っかるということにメリットは見いだせませんでした。その為、素直に公式の環境に乗っています。個人的にはXamarin気になってはいます。

APIサーバーの開発言語

HTTPを喋ってネイティブアプリやブラウザ上のSPAアプリケーションと通信するAPIサーバーは、Scalaで書かれています。

ネイティブアプリやブラウザで動くSPAアプリケーションにはどうしても言語選択の自由の幅が少なくなりますが、サーバーサイドは何で書いても自由です（えっServerSideSwift？ちょっと勇者すぎませんかね……）。

Scalaを選択するメリットとしては、高い表現力と安全性が挙げられるでしょう。一方でデメリットとして、「むずかしい」とか「いろいろな書き方ができすぎて宗教戦争が起こりそう」とかいろいろあるのですが、幸い今のところメンバーのバランス感覚（どこまで抽象度を上げて書くのかとか）はメンバーごとに大きく乖離することはなく、「仕事で書くならだいたいこのへんがちょうどいいバランスだよね」というなんとなくの合意が取れているように思えます。

弊社のメンバーの共通の得意言語はRubyなので、Rubyで書くというのもアリっちゃアリなんですが、「技術的に尖ったメンバーを集めたい、テックな企業にしていきたい」という経営側からの要望と、私の趣味と他社での運用実績が一致した結果Scalaでやっていこうという感じになっています。実際現状の人材面を見るに、この選択は悪くなかったなあと思っています。

その他細かい部分

デプロイのスクリプトや雑な集計とかがPerlだったり、DBのマイグレーションのサポートをRubyでやっていたり、サーバー管理のための細かいツールをGolangで書いたりしています。

このあたりは「このライブラリが使いたいからこの言語を使う」という理由で言語を選択したり、「雑な集計なら雑に書き慣れてるPerlでやりたい」っていう思いだったり、「いろんな環境で動かすコマンドになるからバイナリ一枚ぺろっと置けば動いてほしい」という理由があったりします。

まとめ

弊社では様々な要求に合わせて、適材適所で様々な言語を利用してアプリケーションの開発や運用を行っています。

合理的な理由があれば新しい言語もどんどん取り入れていく環境ですので、「オッいいですね、ここはちょっと働いてみたいですね」という感じで興味のある方はぜひご連絡お待ちしております。twitter: @neko_gata_s が一番連絡つきやすいと思います。まずは飯でもいきましょう。