published
published
author
authorDisplayName
Ryuichi Fukami
category
backend
mainImage
publishedAt
Sep 16, 2025
slug
rick-ios-to-backend
tags
backend
こんにちは！令和トラベルにて旅行アプリ「NEWT (ニュート)」の開発をしているRickです。
2024年4月に入社して以来、ずっとiOSエンジニアとしてアプリ開発に携わってきました。そして2025年6月から、iOSエンジニアを兼務しつつ、Backendエンジニアに転向することになりました。
現在では、業務時間の9割以上をBackendエンジニアとして過ごしています。ホテル事業に注力するチームにおいて、新規プロダクトの開発と、それに伴うNEWT本体の連携部分の開発を担当しています。
本記事では、私がなぜこの決断をしたのか、そして実際にどのように事業に貢献しようとしているのかについて紹介します。
AI時代に突入し、キャリアの方向性を再検討している方も少なくないと思います。アプリエンジニアに限らず、そういった方々の参考になれば幸いです。
これまでのキャリア
これまでのキャリアを振り返ると、学生時代から数えてiOSエンジニアとして7年目に入りました。令和トラベルでは、約1年半にわたり旅行アプリ「NEWT」のiOS開発に携わっています。
弊社では、全社KPIをもとに細分化された目標ごとにチームが編成されており、私はそのうちの約10名で構成されたチームのScrum Leaderとして開発をリードしてきました。
また、以下のような技術的取り組みや改善にも積極的に取り組んできました。
.png?table=block&id=f262d6a1-91ec-440a-93b0-7bd254c10c1d&cache=v2)
私は大学生時代にiOSアプリ開発を始めました。
「身近な家族や友人が日常的に使うものをつくって、その人たちの人生に直接的に貢献できたら幸せだな。iPhoneを使っている人が多いから、iOSアプリを通して使いやすいサービスを届けたい」——そんな想いがきっかけです。
その後、前職では動画配信サービス「ABEMA」の開発を担当し、iOSエンジニアとして経験を積んできました。では、なぜそんな私がバックエンド領域にも挑戦しようと考えたのか。その理由を紹介していきます。
Backendエンジニアへ転向するモチベーション
複雑なドメインの解決
エンジニアの価値は様々な形で発揮されると思いますが、その一つが「複雑なドメインにおける課題解決」です。
日常や業務の中で課題を発見し、それをどう改善し、より良いものにしていくかを試行錯誤するには、対象ドメインに対する深い理解と考察が求められます。
入社前から覚悟していましたが、旅行ドメインでは料金計算や予約フローなど、想像以上に複雑な業務をシステムに落とし込む必要があります。
こうした複雑なロジックは、バックエンド側で処理されることが多いと思います。
近年では、Backends for Frontends（以下 BFF）という考え方に沿って、より多くのロジックをバックエンドに集約し、開発効率や保守性を高めるサービスが増えている印象です。
（※NEWT自体は BFF を採用しているわけではありませんが、ビジネスロジックの多くがバックエンドに集約されています。）
旅行ドメインや世界情勢、カスタマートレンドとともに日々変化する課題を解析し、（PMの責務と重なる部分もありますが）自らがそれを紐解いていきたいと考えるようになりました。
少し前の記事にはなりますが、旅行ドメインの複雑さについて触れている以下の記事もぜひ読んでみてください。
事業貢献の幅を広げる柔軟性の獲得
スタートアップにおいて事業を展開する中で、注力すべきポイントは常に変化していきます。
たとえば、上期はホテル事業に注力していたのに対し、下期はツアー事業にも力を入れる、といった具合です。
スタートアップでは、開発リソースの配分に制限が生じることも少なくありません。バックエンドの開発が多く求められるタイミングではBackendエンジニアとして、クライアントサイドの開発が多いタイミングではiOSエンジニアとして動けると、優先度の高い課題解決に対するリソースの制約を減らせます。
また、バックエンドとクライアントサイドの開発を両方経験することで、システム全体の理解が深まり、あらゆる課題に対してより柔軟に対応できるようになります。会社が本来取り組むべき課題に対して、リソース不足のために優先度を落とすことがないよう、貢献の幅を広げていけたらと考えています。
サービス全体のアーキテクチャを改善する
サービス開発では、クライアントやバックエンドなど各領域でより良い設計を目指すことはとても重要ですが、それと同時にサービス全体のアーキテクチャや各領域間のやり取りの方法についても、継続的に改善していく必要があります。
単一の領域だけで最適化を図るのではなく、全体を俯瞰した視点を持つことで、各領域が相互に補完し合い、より堅牢で拡張性の高いサービスを実現できます。
そこで、普段担当している領域以外の理解を深めることは、単なる知識の拡張にとどまらず、サービス全体の構造や依存関係を把握し、改善点を見つける上で非常に役立ちます。クライアントサイドとバックエンドの両方に触れることで、設計上の課題や潜在的なボトルネックを早期に発見でき、チームとして効率的かつ一貫性のある開発を進めることが可能になります。
このように、各領域での深い理解と全体を俯瞰する視点を両立させることが、サービス全体の品質向上や開発効率の改善につながると考えています。
あたらしい領域へのチャレンジ
アプリ開発では、以下のようにアプリならではの事柄を追求できる面白さがあります。
- アーキテクチャの改善
- SwiftやKotlin等の言語の扱い
- 洗練された UI / UX の実現
- 低遅延動画プレイヤーのための設計
- アプリならではのSDKを使った処理
- 課金処理における正確なトランザクション処理
- etc…
上記内容のように、得意分野を軸に幅や深さを追求することは非常に意義がありますが、私は自分にとってあたらしいことを学ぶこと自体にも大きな高揚感を感じます。
バックエンド開発で得た知見をアプリ開発に応用することで、仕組みやチーム作りに新たなスパイスを加えられる点も魅力です。
AI時代に備える
近頃、社員数わずか10名前後の企業が年商数億ドルを達成する事例を目にすることが増えてきました。こうした企業では、フロントエンドとバックエンドの両方を担当するエンジニア、フルスタックエンジニアが活躍しています。
AI時代の進展に伴い、このような小規模で高い成果を上げる企業はさらに増えることが予想されます。その中で、将来的に解決したいあたらしいドメインを見つけた際に、少しでも自身が貢献できる可能性を高めておきたいと考えるようになりました。
また、以下の記事でも言及されているように、幅と深さの両方を獲得することが、これまで以上に重要だと自分も考えています。
加えて、後述するように、AIの進化によって「幅広い領域への挑戦」や「深い専門性の習得」が従来よりも取り組みやすいものになってきていると感じています。
社内での異動の流れ
入社当初から、チャンスがあればバックエンド領域に挑戦したいという希望を伝えていました。
入社から約1年が経った頃、ホテル事業で社外連携を含むあたらしいプロジェクトが立ち上がり、必達の締め切りが設定されたことにより、Backendエンジニアの需要が高まったのが転機となりました。
一方で、元々担当していたツアー事業は、頼れるメンバーも増え、自分が抜けても十分に機能する体制が整っていました。こうした背景から、数週間で自走できることを期待されつつ、バックエンドチームへの異動が決定しました。
異なる職種に挑戦できる会社は決して多くないと感じています。そんな中で、自分の挑戦を受け入れ、期待とともに任せてくれた会社への感謝も強く感じています。
この経験を踏まえ、今後もし職種転向を希望するメンバーが現れた際に少しでも役立つよう、次のセクションではスムーズに職種転向するためのポイントを紹介したいと思います。
職種転向するにあたってやって良かったこと
期待役割を理解し、それを超えていくことを意識する
エンジニアの真価は、「中長期に渡って影響を及ぼすものの意思決定」に現れると考えています。その意思決定の結果が、将来の開発効率や事業の可能性に影響を与えるからです。
しかし、転向した直後だとそのような意思決定をするのは簡単ではありません。そこで実際に、会社はどういう期待を込めて自分をバックエンドエンジニアに転向させたかを思い出してみます。
目標必達のプロジェクトにおいて、エンジニアの数が足りていなかったため、マンパワーを増やしたいという期待のもとでした。つまり、アウトプット量そのものが自分に求められていたものだったということです。
では、どうやってそれを実現するか。行き着いた答えは「AIをメンターにつける」でした。
AIをメンターにつけ、スピードで貢献する
プログラミングを行うエンジニアは、（感覚的な評価ではありますが）もともと「早くて当たり前」な存在だと思います。
多くの場合、命令通りに動いてくれるコンピューターと対話しながら、自分の得意分野である開発を進めているからです。特に機能開発を行っている場面では、その傾向がより強く感じられます。
そのため私は、育成・チームビルディングといった領域、採用・交渉力・相手の感情を動かすことが求められる職種に強いリスペクトを抱いています。なぜなら、それらは自分だけでコントロールできず、相手の状況や環境によって結果が大きく左右される可能性を秘めているからです。
だからこそ、対人コミュニケーションをより要する領域においてこそ再現性を高め、安定して成果を出せるようになりたいと考えています。
少し脱線しましたが、改めて「スピード」は当たり前の要素でありつつも、とても価値のあることだと感じています。なぜなら、カスタマーはそのスピードに価値を感じ、それ自体が競合優位性を生み出し、事業の成長スピードに直結する重要な要素だからです。
弊社では、そんなスピードを重視して「GO FAST」というValueを掲げています。
Backendエンジニアに転向したての自分が、どうやってスピードを獲得できるか？
それはAIの活用でした。ChatGPT や Claude といった AI モデルや Agent の登場・進化により、英語学習・プログラミング学習・自炊メニューの提案など、あらゆる分野で難易度が下がり、従来あった障壁が次々と取り除かれました。
自分は、多くのAgentを使い分けることはせず、ChatGPTとClaude Codeをメインで使っています。
- 仕様整理 : ChatGPT
- 一般知識の理解を深める : ChatGPT
- 既存コードの解説 : ChatGPT・Claude Code
- コーディング・Git作業 : Claude Code
とはいえ、いきなりAIコーディングを始めるのではなく、仕様や既存実装について、AIと伴走しながら理解を深めます。
AIを活用する際は工夫も取り入れています。たとえば Claude Code を使用する場合、output-styles の設定をしておくのがおすすめです。これによりアウトプットと同時に Tips が提示され、学習を促してくれます。そこで得た知識をもとにオリジナルのドキュメントを参照すれば、周辺知識のキャッチアップや本質的な理解につなげられます。
とはいえ、転向後の最初の約2週間は、一定の負荷を受け入れ、AI Agentによるコーディングをあえて制限していました。なぜなら、その期間の試行錯誤が、中長期的にはスピードに繋がると考えたからです。
これまでiOSエンジニアとして実際に開発してきた経験があるからこそ、触ろうとしているAPIがクライアントでどのように使われるのかを意識できます。
さらに、新規で作る場合には「どういうSchemaであればクライアントにとって使いやすいか」を考えながら開発できるため、クライアントとバックエンド間での意思決定スピードを大きく縮められていると感じます。
PRの数が必ずしも成果と相関するとは限らないですが、転向してから約2ヶ月半で200を超えるPRをmergeしていました。AIの活用と同時に、本質的理解を怠らないこと、また、メンバーの助けの結果だと感じています。
得意とする領域では、自分が居なくても回る状況を作る
職域を拡大すれば、当然ながら元いたチームに割ける時間は減ります。人によっては、ほとんどゼロになる場合もあるでしょう。
そのときに重要なのは、自分が居たことで生まれていた生産性を、いかにして維持するかという責任を果たすことだと考えています。なぜなら、多くの場合、その転向は元いたチームメンバーの後押しや応援、そして頑張りがあってこそ成り立っているからです。
具体例を1つご紹介すると、 Claude が PR 上でレビューする際のガイドライン を作成し、自分やチームの考えをもとに AI がレビューできる状態を整えました。結果として、レビューする側の負荷も、レビューを依頼する側の負荷も削減でき、Win-Win の状態を実現できました。
さらに、これは愚直な取り組みですが、週に数回、30分ほどメンバーと一緒に作業する時間を設けていました。「困っていることはありますか？」という問いかけだけでは見つけにくい落とし穴や課題も、こうした場を通じて早期に発見することができました。
自信のある領域こそ、自分がそこに居なくても上手く回る組織・チームの状態を整えることが重要だと考えています。
改めて、負荷を許容しつつも私の挑戦を受け入れてくれたメンバーとその決断をしてくださった会社には、感謝の気持ちが絶えません。期待を超える成果で恩返しができればと思っています。
これから挑戦したいこと
データを実際に触るBackendエンジニアだからこそ見つけられる「カスタマーが抱える課題」「事業の伸び代」があります。
データを紐解き、課題の発見から解決までを一貫して行う挑戦をしていきたいと考えています。
ここ数ヶ月は、新機能・既存機能における簡単なテーブル設計からAPI開発、少しのパフォーマンスチューニングを経験してきました。今後は、カスタマーのUXや売上向上に直結するパフォーマンス改善やデータ設計に加え、インフラ周りまで担当範囲を広げられればと思っています。
まとめ
いかがでしたか？
AI時代において、新たな領域にチャレンジしたいと考える方は少なくないと思います。そういった方々にとって、少しでも参考になれば幸いです。
転向して実感したのは、AI時代において職域を制限する壁が大きく減ったということです。少しでも自分の可能性を広げたいと思っている方がいるのであれば、ぜひ挑戦していってほしいなと思います。
社内でも、複数領域で動けるメンバーを育てる動きが進んでいます。
実際、以下のような挑戦例があります：
- iOSエンジニア → Backendエンジニア
- Frontendエンジニア → Backendエンジニア
- iOSエンジニア ↔︎ Androidエンジニア
- QAエンジニア → PM
AI時代だからこそ、こうした挑戦は以前よりも実現しやすくなっています。
このチャンスを仲間と掴み、そこで得た知見を共有することで、チームビルディングやプロジェクト運営にも新たな価値が生まれるでしょう。
最後に宣伝
AI時代において、NEWTのエンジニアがどう過ごしているかの一例が垣間見えたかと思います。
常に変化し続ける旅行ドメインにチャレンジするスタートアップだからこそ、重要視するポイントがあり、その中で試行錯誤しながらどうサービスを伸ばしていくかを考える特有の面白さがあります。
NEWTには、未だ成長の余地が多分にあります。
将来、さらに複雑になり得るプロダクト要件に対して、どんな技術をどう使えばカスタマーにより良い旅行体験を提供できるかを、一緒に考えていきたい仲間を募集しています。
私のように旅好きなメンバーが多い会社ではありますが、もちろんそうでないメンバーもたくさんいますし、大歓迎です！
スタートアップの事業グロースにコミットしたい、社会やカスタマーに価値提供できるプロダクトに携わりたい、など、令和トラベルにジョインする理由はさまざまです。
旅行が好きかどうかに関わらず、ミッションやビジョン、テクノロジーで実現しようとしている世界観に少しでも興味を持っていただけたら、ぜひ一度お話させてください！
令和トラベルでは一緒に働く仲間を募集しています
絶賛、会社としてのフェーズ・人数ともに急激に変化しています。
そんな中、多様なバックグラウンドを持つメンバーが集まってプロダクトを進化させようとしているため、正直カオスに見える瞬間が垣間見える場面も少なくありません。しかし、そういう状況下で終わりなきミッションの達成を追い続ける過程では、何にも変えられない経験や成長が得られると思います。
みなさんも、NEWTを操縦する一員として、ともに世界を旅しませんか？ 🌍
この記事を読んで令和トラベル・NEWTに少しでも興味をお持ちいただけましたら、ご連絡お待ちしています！
令和トラベル主催イベントも毎月開催しています！
令和トラベルでは、このように技術的な知識や知見・成果を共有するLT会を毎月実施しています。発表テーマや令和トラベルに興味をお持ちいただいた方は、誰でも気軽に参加いただけます。
9月の『NEWT Tech Talk vo.16』は、”AI × Backend” がテーマ！
9月の「NEWT Tech Talk」は、MOSH株式会社・Nstock株式会社・令和トラベルの3社による共同開催です！それぞれの開発現場で、AIをどのようにBackend開発に組み込み、開発の効率化を実現しているのかについて深掘りします。
「AI×Backend −実用化を支える技術と効率化の現在地」と題して、実務での取り組みを交えながら、MOSH株式会社からGenta Kaneyamaさん、Nstock株式会社からKiyoshi Tanakaさん、そして株式会社令和トラベルからtaniigoの3名がLT式で発表を行います！
そのほか、毎月開催している技術発信イベントについては、connpass にてメンバー登録して最新情報をお見逃しなく！
それでは次回のブログもお楽しみに！Have a nice trip！！
