Backend

Androidエンジニアがバックエンドエンジニアになって感じたこと

2024/04/23

| Yuto Akaike

はじめに

こんにちは。令和トラベルエンジニアの赤池です。

この記事は、NEWT 2nd ANNIVERSARY CALENDAR DAY19として、書かせていただきます。

私は、NEWTの立ち上げから2年ほどAndroidアプリを開発してきましたが、エンジニアとしての経験の幅を広げるため、半年ほど前にNEWTのバックエンドエンジニアに転身しました。（令和トラベルは新しい領域へのチャレンジも応援してくれる環境です！）

私自身これまでの約10年はAndroidアプリ開発をメインとしてきたので、バックエンド開発に専念することに不安や困難もありましたが、先輩バックエンドエンジニアによるコードレビューや週次1on1などによるサポートをもらいながら、実践を通して新たな学びを得ていくことができました。

今回はNEWTにおけるAndroidアプリ開発とバックエンド開発との違いという側面で、この半年間で感じてきたことを共有したいと思います。

技術スタックの幅

まずはそもそもの話ですが、バックエンド開発はAndroidアプリ開発と比較して、採用し得る技術スタックの幅が圧倒的に広いです。

プログラミング言語だけで言っても、AndroidはKotlin・Java・Dart(Flutter)がほとんどですが、バックエンドはTypeScript・Go・Kotlin・Java・Ruby・PHP・Python・Rust…など多岐にわたります。さらにミドルウェア・フレームワーク・ライブラリなども入れると無数の組み合わせが存在します。

NEWTでの言語はTypeScriptを採用していますが、「前職ではGoでした」「Rubyでした」といったメンバーも多く、多様なバックボーンを持ったメンバーでチームが構成されています。これは、バックボーンの違いによる個性が必然的にコード上に現れやすくなることを意味します。

一方AndroidにはGoogleという絶対的存在があり、Googleが提供するDevelopersガイドやサンプルコードなども充実し、準拠しやすいデファクトスタンダードがある程度確立しています。よって新しいメンバーであっても共通認識が持てることが多いです。

バックエンド開発を始めた当初は、その多様性と自由度が反映されたコードベースに戸惑いを感じることもありました。しかしビジネスロジックが集約されているNEWTのバックエンド開発では、ドメイン固有の課題を解決していくことが最重要なので、正解が無い中で、自ら考えて設計・実装していくことが大事なのだと理解していきました。

Android開発では、UI（Activity）からロジックをどう切り離すか試行錯誤されてきた歴史を持ち、DIやモジュール分割なども用いて、レイヤーやフィーチャーごとで疎結合に保つことが共通認識になってきています。アーキテクチャをクリーンに保つといった感覚に慣れているエンジニアも多いと思います。

バックエンド開発においての難易度はより高くは感じますが、プラットフォームが違えど、原理原則は変わらないと思うので、Androidエンジニアが実践を通して磨いてきたアーキテクチャに対する感度は、バックエンド開発にも活かしていけるのではとも感じています。

環境への理解

バックエンドの環境は、アプリケーションの特性などに応じた多様な構成がとられます。その選択肢は広範囲に渡り、Androidエンジニアにとって未知な技術に遭遇しやすく、つまづきやすいポイントであると感じます。ですのであまり完璧は求めず、開発上必要になった段階で理解を深めていくのが良いんじゃないかなと思います。

ローカル開発環境

Android開発では大抵の場合、コーディングやビルドからエミュレータを使ったデバッグまで行えるAndroidStudioを導入します。バックエンド開発では、Dockerなどの各種ツールやコマンドによる固有の構築手順がまとめられていたりすると思います。初回構築時には特に困らないかもしれませんが、データベースのスキーマやテスト用データ、ライブラリなどの依存関係、外部サービス連携周りなどの変化に応じて、構成は自分で更新していかなければなりません。

インフラ

インフラにはGoogleCloud・AWSなどを使用している場合が多いかと思います。セキュリティや負荷分散なども考慮した構成になっていると思うので、それらを意識して実装しなければならないケースも出てきます。自らインフラ構成に変更を加える場合は、セキュリティやパフォーマンス面だけでなく、コスト感覚なども含めた視点が必要となります。

デプロイ

クライアントが利用するバックエンドAPIの場合、開発環境やステージング環境に適宜デプロイしながら開発を進めていくことも多いかと思います。本番環境に関しても、モバイルアプリと違ってリリース前の審査もなく、カスタマーがアップデートする手間もかからないので、比較的短いサイクルでリリースできます。その分CI/CDが稼働する回数も多くなるので、その速度や効率性への要求も高くなります。並列化していたりする場合は、テストコードにも考慮が求めらます。

使う側から使われる側へ

バックエンドの開発を進めるに従って、アプリケーションはネットワークを介して多数から使われる（リクエストされる）という視点に慣れていきました。

各種クライアントから

バックエンドのAPIは、Android・iOS・Webフロントなどのクライアントから利用されます。そのため、クライアント側のエンジニアが利用しやすいように連携しながらAPIを設計し、ドキュメントも作っていくことになると思います。APIに破壊的変更が入る場合は、後方互換性を担保する必要も出てきます。このあたりはアプリ開発をしていた経験が活きるポイントになります。

また、サービスの性質にもよりますが、開発効率的にビジネスロジックはバックエンドに寄せられ、その分テストなども多くなる傾向があると思います。テストを充実させることで、QAやエンジニア自身による動作確認の負担を減らすことができています。

複数のカスタマーから

モバイルアプリの場合はデバイスを保持する単一のカスタマーからの利用がほとんどですが、サーバーアプリケーションは複数のカスタマーから同時に利用されます。排他制御を理解し、トランザクションを管理しなければなりません。

また、アクセスが集中すると負荷も高まるので、無駄な処理やDBアクセスを発生させない実装や、テーブル設計における適切な正規化やインデックスなど、パフォーマンスを考慮した設計・実装をすることも重要となります。アプリ開発と比較して大きな違いとなるポイントなので、データベースやアルゴリズムに関してはできるだけ勉強しておくと良いと思います。

UI実装が無い

モバイルアプリ開発ではUI実装も大きな部分を占めますが、バックエンド開発では当然その関心度は大きく下がります。カスタマーのどんなデバイスで動作するかの考慮も要らなくなります。UIやデザインに関しての知識も必須ではなくなり（あるに越したことはないですが）、デザイナーよりエンジニア同士でのコミュニケーションが増えます。

重視される領域やコミュニケーションの仕方も多少変わるので、向き不向きや楽しく感じるかどうかの差が出やすいポイントなのかなと思います。ちなみに僕自身は、整合性とれた形で全体が動作するように作ること自体が好きなので、バックエンド開発もモバイルアプリ開発と同じくらい楽しめています。