経験・行動面接

例えば、新しい版を段階的リリースで出した翌日、特定の OS の版でクラッシュが増えたとします。状況として、クラッシュフリー率が前の版より明らかに下がり、対象は利用者の一部だったと話します。私は担当として段階的リリースを止め、Crashlytics のスタックから、新しく入れた画面の初期化で古い OS にない API を呼んでいたことを突き止めました。

その機能を Feature Flag で止めて影響をなくし、修正版を出しました。結果として、止めるまでの影響は数％の利用者にとどまりました。振り返りでは、最低の OS の版の端末をテストに足し、止める基準を手順書に書いて、誰でも同じ判断ができるようにしました。

例えば、デザイナーが一覧に大きな画像と動きのある表現を入れたいと考え、私は性能の低い端末でスクロールがカクつくと考えて意見が分かれたとします。私はまず相手の狙い（商品の魅力を伝えたい）を確かめたうえで、性能の低い端末で試作を動かし、コマ落ちの数字と動画を見せました。

そのうえで、画像は大きく見せ、動きは画面に入ったときだけにする案を一緒に作りました。結果としてデザインの狙いを保ったまま、スクロールの滑らかさの基準も満たせました。データと実物で話すことと、相手の目的を先に確かめることを大事にしています。

例えば、アプリの起動が遅いという声があり、計ってみると性能の低い端末でコールドスタートが3秒を超えていたとします。私はプロファイラーでトレースを取り、起動時にすべての SDK を初期化していることと、最初の画面のデータをメインスレッドで読んでいることを見つけました。

最初の画面に要らない SDK を後回しにし、データの読み込みを裏に移して前回のキャッシュを先に出し、Android では Baseline Profile も入れました。結果として起動時間は中央値で約4割短くなり、起動直後の離脱も減りました。改善の前後を同じ条件で計る仕組みを作ったことで、後から遅くなったときにも気づけるようになりました。

例えば、古い画面と設計が混ざり、修正のたびに別の画面が壊れるアプリを担当したとします。全部を書き直すのではなく、変更が多い画面から順に、テストを足してから新しい設計に置き換える方針をチームに提案しました。

PdM には、機能の開発の一定の割合を置き換えに使うことを、不具合の件数と修正にかかった時間の数字で説明して合意しました。半年ほどで主要な画面を置き換え、その画面まわりの不具合の報告は目に見えて減りました。負債は一度に返すより、毎回少しずつ返す仕組みにすることが大事だと考えています。

今の会社への不満ではなく、挑戦したいことを中心に話します。例えば「今の会社では1つのアプリを配信から運用まで担当し、起動時間やクラッシュ率の改善を続けてきました。次は、より多くの利用者がいるアプリで、性能やアーキテクチャの改善を大きな規模で経験したいと考えています」のように、これまでの経験と次にやりたいことをつなげます。

そのうえで、応募先のアプリを使って感じたことや、技術のブログで読んだ取り組みなど、そこでなければならない理由を具体的に加えます。

必ず用意しておきます。例えば、リリースの周期と段階的リリースの運用、クラッシュ率や起動時間をどう見ているか、iOS と Android のチームの分かれ方と、デザイナー・サーバー側との進め方、最近の大きな技術的な取り組み、入社後半年で期待されることを聞きます。

答えから、品質を仕組みで守っているか、アプリエンジニアが仕様の段階から関われるかが分かり、自分の関心の高さも伝わります。