モバイル開発者

この領域について

中核となる能力

• 01プラットフォームへの習熟

  各プラットフォームがアプリケーションにどう振る舞うことを期待しているかを知っていることです。画面遷移と戻る履歴の意味、アクティビティやビューコントローラのライフサイクル、権限の確認、システムの文字組みとレイアウトの作法です。これを無視したアプリは、理由を言葉にできる前に、利用者から「何かおかしい」と言われます。

• 02ネイティブとクロスプラットフォームの判断

  コードの共有が実際に何を節約するのか、抽象化がどこで漏れるのか、漏れたときにネイティブへ降りる代償は何かを理解していることです。判断は、プロダクトのうち端末連携が占める割合、二つのプラットフォームでどれだけ挙動を変える必要があるか、そして誰が保守するかで決まります。

• 03オフラインの挙動とローカルデータ

  ローカルの保存先を選び、何をどれだけ保持するかを決め、切断中の操作を待ち行列に入れ、サーバーへ届いた時点の競合を解消し、楽観的ではなく正直な状態を利用者に示すことです。同期は、モバイルアプリで最も難しい不具合が溜まる場所です。

• 04制約のある端末での性能

  起動時間、スクロールやアニメーション中の描画、メモリ逼迫とそれによる強制終了、画像のデコード、そして電池を消耗させるバックグラウンドの活動です。意味のある計測は、社内で最も新しい端末ではなく、古い中位機種から得られます。

• 05リリースの実務

  署名とプロビジョニング、ビルドの種別、バージョン管理、ベータ配布、段階的公開、ストアの掲載情報、そして特定のクライアントを引退させる必要が生じたときに更新を強制できることです。モバイルの運用リスクの多くは、アプリのコードではなくここにあります。

• 06ストア審査と方針

  各ストアが定める規則、すなわちプライバシーの開示、決済と課金の方針、権限の必要性の説明、掲載内容の要件、アカウント削除への対応の内側で作業し、審査の結果が計画上の突発事象ではなく予測可能なものになるように設計することです。

• 07通知とバックグラウンド処理

  各プラットフォームのサービスを通じたプッシュ配信、トークンの寿命管理、権限と同意、起動していない状態からの適切な画面へのディープリンク、そして遅延、まとめ実行、取り消しを行うOSを前提に書かれたバックグラウンド処理です。

• 08モバイルのアクセシビリティ

  VoiceOverとTalkBackへの対応、意味のあるラベルと要素のまとまり、利用者が設定した文字サイズや動きの低減への配慮、十分な大きさのタップ領域、そして妥当なフォーカス順序です。モバイルのアクセシビリティには固有の作法と検証手段があり、ウェブの知識は一部しか転用できません。

• 09端末とバージョンの多様性

  どのOSバージョンと画面区分を対象とするかを決め、都合のよい範囲ではなく代表的な範囲で検証し、条件分岐の迷路をつくらずに機能差を吸収することです。

よくあるご質問

よくあるご質問

ネイティブとクロスプラットフォームのどちらで構築すべきですか。

プロダクトのうち端末そのものが占める割合によります。フォーム、一覧、コンテンツが中心のアプリケーションはコード共有によく合い、二度目の実装を省ける効果は本物です。カメラ、センサー、バックグラウンドの位置情報、Bluetooth機器、負荷の高い描画を中心に据えたアプリケーションは、その節約を橋渡しのコードとプラットフォーム固有の例外処理に使うことになります。判断を分けるのは、技術より次の二点であることが多いものです。誰が保守するのか、そして両プラットフォームで体験を意味のある形で変える必要があるのか。幅広い機能一覧を一人で担うならコード共有に、端末機能中心のプロダクトを各プラットフォームの専門職が担うならネイティブに傾きます。

ウェブ開発者がReact Nativeでモバイルアプリをつくれますか。

コンポーネントの考え方と言語が引き継げるため、序盤は速く進めます。引き継げないのは、実際に問題を起こす部分です。署名とストアへの提出、権限の仕組み、ライフサイクルとバックグラウンドの制限、オフラインの挙動、プッシュ配信、そして複数端末での検証です。ここで、慣れた記法によって節約できたはずの時間を、単独のウェブエンジニアは失います。フレームワークが差を埋めてくれると期待するより、ウェブの素養に、モバイルアプリを公開し保守してきた人を組み合わせるほうが確実です。

iOSとAndroidで別々のエンジニアが必要ですか。

ネイティブで構築するなら、多くの場合は必要です。ツールチェーン、言語、作法、リリース手順が十分に異なり、両方で本物の深さを持つ人は多くありません。コードを共有して構築するなら一人で両方を担えますが、フレームワークが扱えない場面に対応できるだけの理解を、誰かが各プラットフォームについて持っている必要があります。いずれにせよ、コードが共通だから同等だと考えるのではなく、二つのプラットフォームには別々の検証と別々のリリースの注意が必要だと捉えてください。

ストア審査は開発計画にどう影響しますか。

変更の完了から利用者に届くまでの間に、自分では制御できない可変の遅れが入ります。これを織り込むチームは、予測可能な周期でリリースし、次の版をつくる間も何かを審査に出しておき、再提出せずに挙動を調整できるようリモート設定やサーバー側の切り替えを用意します。無視するチームは、障害対応の最中にこの制約を知ることになります。学ぶ時期として最悪の瞬間です。

モバイルアプリには専用のバックエンド作業が必要ですか。

ほぼ常に必要で、想定より多いのが普通です。クライアントは要求に応じて更新できないため、APIはバージョン付けし、古い呼び出し元に寛容である必要があります。通知にはトークンを保持し配信を扱うサービスが要り、オフラインの同期には単純な読み書きではなく突合を前提としたエンドポイントが要ります。モバイルエンジニアはこれらすべてに見解を持ち、多くは実装もできますが、これはサーバー側の作業であり、そのように計画されるべきです。

モバイルアプリの健全性は何で測るべきですか。

クラッシュのない利用の割合、代表的な端末での起動時間、新しいバージョンへの移行状況、そして通知などの権限を許可した利用者の割合です。ストアの評価は遅れて表れる雑音の多い指標で、方向づけには使えても診断には向きません。最も見落とされやすいのはバージョンの移行状況です。ある不具合がどれだけ長く世に残るか、そして古いクライアントをいつ安全に引退させられるかを決めるためです。

モバイル開発者は既存のエンジニアリングチームとどのように働きますか。

御社の指揮のもとで働きます。御社のロードマップ、プラットフォームに関する判断、レビューの手順、リリースの予定です。技術的な所有権は移らず、開発チームの増強は開発を丸ごと外部に委ねる形式ではありません。日々の開発の優先順位や技術的な判断はお客様のチームが管理し、Talent.IDは雇用に関する責任を担います。雇用関係、給与支払い、従業員福利厚生、タレント管理、そして継続的な従業員関係です。