こんにちは。
iTANでバックエンドエンジニア兼アプリエンジニアをしている岩切です。

普段はLaravelやFlutterを使いながら、機能追加や改善、障害対応などを行っています。

今回は、iTANの開発チームで大事にしている

“担当領域をあえて狭めすぎない”

という考え方について書いてみようと思います。

バックエンドエンジニアがアプリを触ることもあれば、アプリエンジニアがAPIやDB構造を見ることもあります。

簡単ではありませんが、小さいチームだからこそ助けられている考え方です。

また最近は、AIの補助によって、以前より領域をまたいで学びやすい環境になってきました。

この記事では、

• なぜ担当領域を固定しすぎないのか
• 実際どんなメリットがあるのか
• 難しさはあるのか
• AIによって何が変わったのか

について、できるだけリアルに書いてみます。

はじめに

「私はバックエンド担当です」
「私はアプリ担当です」

専門性を大事にしつつ、僕たちは “担当領域を固定しすぎない” ことを意識しています。

バックエンドエンジニアがFlutterを触ることもあるし、アプリエンジニアがAPIやDB構造を見ることもあります。

理由はシンプルで、

顧客体験は、全部つながっているからです。

なぜ担当領域を固定しすぎないのか

ユーザーがボタンを押した瞬間、その裏では

• アプリのUI
• API通信
• バックエンド処理
• DBアクセス
• エラー制御

が繋がっています。

担当が完全に分かれていると、

• アプリ側は「APIを変えてほしい」
• バックエンド側は「アプリで頑張ってほしい」

のような境界が生まれやすくなります。

もちろん役割分担は必要です。

ただ、小さいチームでは境界が増えるほど、コミュニケーションコストも増えていきます。

機能追加では、

• API仕様
• DB変更
• アプリ実装
• エラー調整

までをある程度1人で見渡せると、かなり速い。

「誰に確認するか」より先に、自分で前に進めるからです。

実際どんなメリットがある？

アプリも触れるバックエンド

バックエンドだけを見ていると、APIは「データを返すもの」になりがちです。

でも実際には、そのレスポンスは画面で使われます。

アプリも触ることで、

• UIで扱いやすいレスポンスか
• ユーザーに伝わるエラーになっているか

を意識するようになります。

特にエラー設計は変わります。

「400を返す」で終わりではなく、

• ユーザーに何を表示するか
• 再試行できるか
• どんな形で伝えるか

まで考えるようになります。

結果として、アプリ側の実装コストも下がります。

バックエンドも触れるアプリ

逆もあります。

アプリ側がバックエンド構造を理解していると、

「とりあえずAPI追加してください」

が減ります。

例えば、

• DB構造
• レスポンスサイズ
• パフォーマンス

を理解していると、

「この取得方法だと重そう」
「レスポンス構造をこうした方が良さそう」

といった判断ができるようになります。

通信・表示・UXまで含めた設計がしやすくなります。

チーム全体としてのメリット

担当範囲を少し広く見られる人が増えると、チーム全体もかなり変わります。

例えば、

• レビューできる範囲が広がる
• ボールが止まりにくい
• 緊急対応しやすい
• 属人化しにくい

小さいチームでは特に、「その人しか分からない」がリスクになります。

だからこそ、専門性を持ちながら、隣の領域にも少し踏み込めることを大事にしています。

もちろん簡単ではない

もちろん、良いことばかりではありません。

実際、

• 文脈切り替えコスト
• 学習量
• 専門性とのバランス

など、難しさもあります。

UI設計とインフラ設計では、考え方もかなり違います。

以前であれば、バックエンドエンジニアがアプリ実装を触るのはかなりハードルが高かったと思います。

ただ最近は、AIの補助によって、調査や実装の入口に立ちやすくなりました。

完全に専門外だった領域でも、

• エラー調査
• SDK理解
• 実装のたたき台作成

などを進めやすくなっています。

もちろん、AIだけで何でもできるわけではありません。

それでも、

「少し触ってみる」
「まず理解してみる」

までの距離は、以前よりかなり近くなったと感じています。

それでも今、広くプロダクトを見る価値がある

もちろん、それぞれの専門性はとても大事だと思っています。

バックエンドを深く理解している人がアプリを見るから気づけることがあるし、アプリを深く理解している人がAPIを見るから改善できることもあります。

その上で、

• 隣の領域にも興味を持てる
• 「担当外」で止まらない
• 顧客体験全体を見られる
• 一緒に学びながら前に進める

そんなチームでありたいと思っています。

最近は特に、「まず触ってみる」までのハードルが以前よりかなり下がってきました。

だからこそ今は、

“自分の強みを持ちながら、少しずつ担当範囲を広げていく”

ことが、以前よりずっと現実的になってきていると感じています。

まだまだ課題も多いチームですが、だからこそ改善できる余地もたくさんあります。

「もっとこうしたい」
「もっと良くできそう」

をチームで話しながら、実際に変えていけるフェーズです。

もし、

• プロダクト全体を見ながら開発したい
• 領域を少しずつ広げていきたい
• 小さいチームで試行錯誤したい

そんな気持ちがある方がいたら、ぜひ一度お話しできると嬉しいです。