エンジニアの傾向は“なんでもやる人”から“スペシャリスト”に　Webアプリ開発の体制変化で生まれた技術選定の課題

Webアプリケーション開発は専業化が進んできている

清野隼史氏（以下、清野）：今、リプレイスの話や、こういうところを作っていくのならRails以外使ってもいいかもという話が出たので、そのままテーマ2「今後のWebアプリケーションはどうなっていくか」にいきたいと思います。そもそもRailsだけではうまく立ち行かなくなってきているのは、Webアプリケーション自体の環境の変化が大きいのかなと。

テーマに「今後」と書いていますが、これからWebアプリケーションの開発の現場や環境はどうなっていくのかを整理したいと思います。変化として大きいのは開発体制だと感じているのですが、いかがでしょうか？

櫻庭洋之氏（以下、櫻庭）：弊社では、サーバーサイドもフロントも、時にはインフラも含めて全般をやるタイプのエンジニアが多い。昔からWeb界隈は1人でなんでもやる人が多かったと思いますが、採用活動をしていると、サーバー側のスペシャリストやフロントのスペシャリストなど、細分化というか専業が進んできている気がする。

採用面においても、それぞれの領域で閉じて開発しやすい技術スタックが必要になってくるのかなと思います。昨今SaaSが盛り上がっている中で、リッチなUIやすごく体験のいいWebアプリケーションが増えると、フロント主軸のアプリケーションがより増えるだろうと理解しています。

清野：まさに今のWebアプリケーションは昔と比べてかなり要求されているレベルも高くなって、UIがリッチでパフォーマンスも早くて当然という雰囲気が漂ってきている。1人で全部を触るというよりも全員が、それぞれをしっかり作る人たちがチームとして構成される時代になってきているということでしょうか？

櫻庭：そうですね。

清野：これに関して、赤沼さんはいかがでしょうか？　実際に今、ユニファで採用を担当していると思うんですが。

赤沼寛明氏（以下、赤沼）：本当にそうだなと思います。弊社も最初にスタートしたプロダクトはRailsだけで作られています。フロントもVue.jsやReactなどは使っていなくて、Railsの仕組みの中だけでやっている。弊社の事業のドメインは保育なので、もともとすごくリッチなUIを求められていたわけではなく、シンプルでわかりやすいものが一番だったので、サーバーサイドのエンジニアがバックエンドもやりつつフロントもやっている状況でした。

しかし、我々の事業が大きくなるにつれて、フロントに対していろいろなものを提供しなければならなくなっている。提供の仕方も、モバイルアプリに対するAPIもあればWebViewというかたちで提供することもある。そうなると、もともとフロントエンドを専門的にやっていないサーバーサイドのエンジニアだけでは、フロントエンドを作りきるのが難しくなってきている。

フロントエンド専任のエンジニアが必要になってきたので、採用のターゲットも変わってくる。まるっと1つできる人より、フロントエンド専門の人を求めるようになってきた。以前に比べると、モバイルのアプリも含め、iOSやAndroidといった各職種のエンジニアを求めることが多くなってきていると思います。

その一方で、バックエンドで考えると、むしろAWSがすごく使いやすくなっていろいろなサービスが提供されてきた。サーバーサイドのエンジニアは、RailsのところだけできればというよりRailsプラスインフラ寄り（がいい）。

AWSもある程度わかっていて、単純にEC2のインスタンスの上で動かすだけではなく、AWSのサービスを活用したらどのようなアーキテクチャにできるのかも含めて考える。逆に広範囲に求められている感覚はあります。

清野：フルスタックエンジニアのフルスタックもより広がっているというか、それぞれのスペシャリストも現れてきているし、フルスタックが今まで以上にすごい要求をカバーする存在になってきているということでしょうか。

赤沼：“フルスタック”が示すものが超広範囲になってきていると思います。

清野：だからこそ分かれているところもありますよね。

開発チームの体制の変化により生まれた課題

清野：今、それぞれの領域というか技術領域で専門の人がどんどんついていく開発体制になってきているという話がありました。昔フルスタックだったところがそういう体制になった時に、開発の中で考えないといけないこと、時間を使ってでもコストを割かなければいけないこと、負債になりやすいことがあればうかがいたいのですがいかがですか？　チームの体制が変わったことによって生まれた課題をうかがえるとありがたいです。

櫻庭：僕たちのチームには、まだそんなに専門やスペシャリストチームというものがない。React、Next専門チームはいますが、それはそれで完結していて、サーバーサイドも含めてやっています。Railsで使っているデータや認証周りをNext側とどう共通化していくかという連携部分の設計は、ネックというか、難しくていつも悩んでいます。

清野：まさにフロントエンドとバックエンドの境界、今までは同じ人がやっていたので暗黙的に「こういうデータくるでしょ」と思っていたのが、最近は難しくなってきているということですよね。

櫻庭：そうですね。ドキュメント化のツールにもいろいろなエコシステムがあると思うんですが、その選定も含めて選択肢が広がっているので、それ自体も大変という。

清野：まずそこを考えることが必要になってきたということですよね。

櫻庭：そうですね。

清野：ユニファに関しては、フロント・バックエンドだけではなくアプリケーション同士もあるのではという印象ですが、どうですか？

赤沼：アプリケーション同士では、いわゆるスーパーアプリという構成になっている部分もあるので、バックエンドには独立したRailsのアプリがあります。ただし、iOSのアプリは1つになっていて、中のタグで使い分けるようになっています。

アプリの中でも、スーパーアプリの構成をどうやればいいのか。それこそ複数のエンジニアが並行して開発するにはどういう構成にしておけばいいのかについては、難しくなってきている。どういう技術を使うかを慎重に決めることが求められるとは思います。

作って捨てちゃうようなアプリや、完全に独立しているようなアプリなら、エンジニアの興味次第で「とりあえず新しいものを使ってみたい」という気持ちでトライしてみてもいいと思います。

でもいろいろなところと連携していくようなものでは、一部分だけ違うやり方をしていると、そことの連携だけ特殊なことをしなきゃいけないことになって後々負債になる。そういう意味ではある程度先も見据えて、どの構成にしておけば後々みんなが幸せになれるのかを考慮する必要があると思います。

清野：アプリケーションが複雑化していく中で、全部を全員が把握できなくなってきているという実態に対して、どううまくやっていくのかを考える必要が出てきたということですよね。

赤沼：一方で、サーバーサイドだと特に、デプロイの仕方など具体的なアーキテクチャだけでなく、運用やオペレーション的なところも含めてある程度考えないとつらいですよね。

清野：そうですね。

バックエンドの主軸を移すとしたらどんな言語やフレームワークを選ぶ？

清野：次の質問が来ています。1つ目が「Railsは、つらみがありつつもまだオワコンではないと思っていますが、みなさんがあえて今から自身のバックエンドの主軸を移すとしたら、選定する言語、フレームワークの第1候補はなんですか？」。

櫻庭：僕は仕事でやるならRuby、Railsを選ぶかもしれません。趣味として個人で選んでいいなら、今言語はRustが好きです。ほかにFirebaseは書いていてすごく楽しいのでガンガン使っていきたいなと思っていますが、仕事ではやはりRubyに戻ってきちゃいます。Rubyが好きだからではありますが、今の選択肢の中でもやはりRailsの強みはあると思うので。

清野：今の話の中のRubyやRailsを選ぶという点も、次のテーマからもう少し深掘りしたいと思うので、魅力などをうかがいます。赤沼さんいかがですか？

赤沼：私もRubyやRailsも含めて、仕事でとりあえずきちんとしたものを作るという目的であれば、やはりRubyやRailsを選ぶと思います。RubyやRailsを選択肢から外したバックエンド寄りの話で、純粋に興味として何をやってみたいかというと、Goをやってみたいですね。ほかに単純にRustなどに興味があるし、TypeScript系もふだんやれていないので興味はあります。純粋にバックエンドで考えると、Goをやっておきたい気持ちはあります。

清野：ちなみに僕もエンジニアの端くれなので、もしまた何かを選ぶとしたらRailsという印象があります。“仕事なら”ということですね。やはりRailsやRubyの魅力は仲間を集めやすいことだと思っています。

そこを極めている人もいれば、エンジニアにとっては書き始めるのにも難易度が比較的低い言語ツールだと思っている。その点、何かを立ち上げたい、何かを作りたいと思った時に仲間を集めやすいので、僕はRailsが好きです。すみません、自分語りをしてしまいました。

赤沼：コミュニティの魅力はありますよね。

サービスをまたがったトランザクションの扱いはどうしているか？

清野：次の質問は「Railsでマイクロサービスする時、サービスをまたがったトランザクションの扱いをどうしているのか気になっている」です。赤沼さんにうかがいます。

赤沼：弊社の場合は何か特殊なことをやっているわけではなく、基本的にサービス間の連携はRESTのAPIでやっているので、APIの結果から判断しています。もちろん完全には防げていないと思いますが、設計時に仮に取り出しを失敗した場合にもきちんと巻き戻せるような構成や処理の順番を考えながら実装しています。あまりスマートな回答じゃありませんが、そんな感じかなと。

清野：そこはRailsどうこうというより、どちらかというとマイクロサービスとしてのプラクティスにのっとるという感じでしょうか。

赤沼：そうですね。

（次回につづく）