言語を指定せずに求人を出したら、応募が殺到
森氏はまず、「技術選定」という言葉の意味を再確認した。プロジェクトで効率よく、そして効果的に開発実装を進めるために、適切な技術（言語、データベース、クラウド・サービスなど）を選ぶことといった意味になる。しかし森氏は現実には別の条件も付くと言う。
「社内で作った既存のライブラリを使用すること」「社内事情のため、OSはWindows Serverにすること」「開発ベンダーを代えることはできないので、工数を確保できる言語を選ぶこと」など、過去のしがらみや技術的負債に引っ張られてしまうのが現実だ。そして、開発後の保守などを考えれば、それは仕方のないことだともいう。
ペイルドは4年前に、新事業で提供するWebサービスのサーバー・サイドの開発言語としてRustを選んだ。Rustを選んだ理由として森氏は、「高速な実行環境の実現には伸びしろがある。オブジェクトのライフタイムまで含めた、コンパイラによる高度な静的チェックが優秀であり、バグを生みにくい。traitや所有権などの現代的な機能を標準で提供している。後発の言語ならではの良さがある……」と説明したが、これは適当に言っただけだと明かす。そして、Rustを選んだ本当の理由を語り始めた。
カード事業を始めると決まり、エンジニアを募集することになったが、ペイルドが早い段階で資金調達を済ませていたせいか、求人に応募が殺到した。そして、そのときに出した求人では、言語を指定せず、入社したメンバーで決める旨を記載していた。
その後森氏は、殺到してきた応募者の面接を始めるが、1日に10人面接しても終わりが見えないような状況だった。そこで応募条件を絞ることを考え、「よし！開発言語で絞っちゃえ！」と考えてRustを選んだ。こうして、ペイルドがサーバー・サイドの開発に使用する言語がRustに決まった。
いい加減な話のようにも思えるが、ペイルドにはRustを選べる条件が部分的にではあるが整っていた。立ち上げたばかりの会社であり、「自社開発のライブラリ」などの技術的負債がなかったのだ。「当時はGitHubにOrganizationを用意したくらいだった」と森氏は振り返る。あとは、Webサービスの開発に使えて、パッケージ・マネージャーがそこそこ使えて、ジェネリクスなどの言語仕様が入っているということでRustを選んだ。
ペイルドはプログラムのエラーが極端に少ない
こうして聞くと、あまり深く考えずにパッと決めてしまったんだなと感じるかもしれない。しかし森氏はRustを選んで良かったと言う。ペイルドが提供しているクラウド管理型の法人カードサービス「paild」は、決済サービスでもある。決済サービスでは「いつでも決済できる」、つまりシステムを止めてはいけないことが当然のように求められる。
「Rustはコンパイラによる静的なチェックが非常に優秀。ペイルドはプログラムに起因するエラーが極端に少ない」と森氏はRustがもたらした利点を挙げた。
そうは言ってもRustは「枯れている」とはとても言えない言語だ。そして森氏もRustを選んだが故に苦労したこともあるとして、一つひとつ話し始めた。
まず、Rustの非同期周りの環境だ。特にランタイムの事実上標準がなかなか決まらなかったこと。有力なランタイムが複数存在し、ユーザーを奪い合っていたのだ。その結果、ライブラリによっては特定のランタイムでなければ動かないことが起こるなど、かなり苦労した。現在は「Tokio」という非同期ランタイムが事実上の標準となったが、ランタイム以外の点でも「Diesel」というORマッパーが非同期に対応していないほか、非同期なトレイトを作ろうとしても言語の標準ではその機能がないなど、まだ苦労はある。
続いて各種SDKの問題。「paild」では認証に「Auth0」というサービスを利用しているが、公式SDKがない。ほかにもいろいろな外部サービスを利用しているが、Rust向けSDKがないので、APIを直接操作するしかないという。
AWSについては、Rusoto（ラソト）という非公式SDKがあったが、ある日突然、Rusotoがメンテナンス・モードに入ってしまった。今後を心配していたが、Rusotoのメンテナの一人がAWSで働いていることを明かし、AWSに掛け合ったところ、AWSが公式SDKを提供することを発表した。しかし、その公式SDKは発表から1年近く経った現在でも開発者向けプレビューの状態にとどまっており、「本番環境では使わないように」というただし書きが外れないそうだ。「Auth0やAWSに限らず、SDKに関してはRustはまだまだ恵まれていない」と森氏はこぼす。
自社サービス開始直前にWebフレームワークが消えた
また、インターフェース記述言語（IDL：Interface Description Language）を利用したインタフェース定義でも苦労している。ペイルドではOpenAPIを利用して、サーバー・サイドとフロントエンドの間でインターフェースについて合意を取っている。
フロントエンドのコードはOpenAPIの設定ファイルから生成できるが、サーバー・サイドのRustのコードを生成させようとすると相当な手間がかかる。サーバー・サイドのコードの自動生成をあきらめて、インターフェース定義を人間が見て実装することもあるそうだ。そこで、Protocol Buffersを利用したインターフェース定義を試し始めているが、「Go言語を想定して作られている部分が多いため、Rustとの組み合わせが難しいところがある」（森氏）。
そして、森氏が最も衝撃を受けた話として挙げたのが、Rust用のWebアプリケーション・フレームワークである「Actix Web」の話だ。ペイルドではこのactix-webを利用してWebサービスを開発しているのだが、サービス開始2カ月前に、メンテナが開発終了を宣言して、リポジトリも丸ごと消えた事件が起こった。
「オープンソース・ソフトウェアである以上、当然想定できる事態ではあるが、当時はかなり心配した」と森氏は振り返る。結局、新しいメンテナが就任して、actix-webの供給体制は元に戻ったが、「枯れていないコミュニティならではの大騒ぎだった」と森氏は語る。そして、その後継メンテナは現在、ペイルドで働いている。
ここで森氏はRustエンジニアの採用について話し始めた。「Rustで開発していると言うと、エンジニアは確保できるんですか？ とよく聞かれるが、幸いなことにペイルドではRustエンジニアの採用ではそれほど苦労していない」と森氏は実情を打ち明ける。そして「言語として勢いがあるせいか、Rustを使いたいエンジニアは多い」ともいう。
ただし世間を見渡しても、本番でRustを使った経験があるエンジニアがに多数いるわけではない。では、どうしているのか。入社後2〜3週間、ひたすらRustを勉強する時間をペイルドでは提供しているそうだ。
「Rust言語に習熟しようと思うとかなりの時間が必要だが、Webアプリケーション・フレームワークを使ってWebサーバー・アプリケーションを書くなら、書き方は大体決まってくる。2〜3週間で習得できる人がほとんど」と森氏は語る。
そして森氏は、「プログラミング言語を習得することよりも、Webシステム開発の本質的な難しさを理解することの方が大切だし、大変なこと。Rustでなくても、何らかの言語でWebサービスを開発した経験がある人なら、ペイルドに入社してもそれほど苦労しない」ともいう。
ただし、ペイルドが人材についてそれほど苦労していないのは、ペイルドの開発チームがそれほど大規模なものではないからという大きな理由がある。森氏も「『来月から納期3カ月で、合計15人月調達』とかいう話になると難しいのではないか」と言う。
エンジニアなら、新しい技術を試してみたい、できれば本番で使ってみたい気持ちを抱くのは当たり前だろう。だからといって、「今回のプロジェクトでは新しい技術を採用しましょう」と提案するだけでは相手にされない。
森氏は「興味がある技術について日頃から情報を収集した方が良い。その技術のメリットだけでなく、デメリットも知っておき、提案時には両方合わせて説明できるようにすべきだろう。メリットとデメリットの両方を提示すれば、相手は判断材料ができる。そうすれば採用の可能性が少しずつ高まっていく」とエンジニアにメッセージを送って講演を締めくくった。
