使われない機能をいつ、どう削るか — Rork 製アプリの機能棚卸しと安全な撤去の設計

使用率を測る最小実装 — イベントを増やさず、パラメータで分ける

機能の使用率を測るとき、機能ごとに専用イベントを作るのは避けています。分析画面がイベントだらけになり、半年後に見返せなくなるからです。

イベントは feature_use の1本に固定し、どの機能かはパラメータで分けます。次のコードは「計測対象の機能を型で固定し、利用回数を月次で集計できるようにする」ための最小実装です。

// featureUsage.ts — 機能利用の計測（イベント1本 + パラメータ方式）
import AsyncStorage from '@react-native-async-storage/async-storage';
import analytics from '@react-native-firebase/analytics';
 
// 計測対象の機能を型で固定する（タイポと野良イベントを防ぐ）
export type FeatureId =
  | 'slideshow'
  | 'favorite_export'
  | 'double_wallpaper'
  | 'search_filter'
  | 'widget_config';
 
const KEY_PREFIX = 'feature_usage_v1';
 
function monthKey(date = new Date()): string {
  const y = date.getFullYear();
  const m = String(date.getMonth() + 1).padStart(2, '0');
  return `${KEY_PREFIX}:${y}-${m}`;
}
 
export async function trackFeatureUse(id: FeatureId): Promise<void> {
  try {
    // 1) 集計基盤へ送る（イベント名は固定・機能名はパラメータ）
    await analytics().logEvent('feature_use', { feature_id: id });
 
    // 2) 端末ローカルにも月次カウントを残す（デバッグメニューでの確認用）
    const key = monthKey();
    const raw = await AsyncStorage.getItem(key);
    const counts: Record<string, number> = raw ? JSON.parse(raw) : {};
    counts[id] = (counts[id] ?? 0) + 1;
    await AsyncStorage.setItem(key, JSON.stringify(counts));
  } catch {
    // 計測の失敗でアプリ本体を止めない
  }
}

呼び出しは、機能の「入口」に1行だけ置きます。

const openSlideshow = () => {
  trackFeatureUse('slideshow');
  router.push('/slideshow');
};

なぜ入口1点だけなのか。撤去判断に必要なのは「その機能を開いた人の割合」だけだからです。機能内部の細かな操作まで測り始めると、計測自体が維持コストになります。

集計側では feature_use イベントを feature_id で分解し、月間アクティブユーザーに対する利用者の割合を出します。私は30日利用率1%を、最初に引く線にしています。

イベント設計を型で守る方法は Rork製6アプリで分析イベントを型で守る — 共有イベント層の設計メモ に詳しくまとめています。

削る・残す・隠すの判断基準

計測が1〜2ヶ月たまったら、判断に移ります。私が使っている基準は、利用率だけの一軸ではありません。

• 30日利用率が1%未満で、利用者の使用頻度も低い — 撤去候補です。誰のためにも機能していません
• 利用率は1%未満だが、使う人はほぼ毎日使う — 残します。ただしメニューの一等地からは外し、設定画面の奥へ移します。少数のヘビーユーザーに支えられた機能は、レビューへの影響が利用率の見た目より大きいためです
• 利用率は低いが、ストアの訴求素材に使っている — スクリーンショットや説明文との整合を先に解消してから判断します
• 利用率にかかわらず、OS 更新のたびに壊れる — 撤去か作り直しの二択にします。中途半端な延命がいちばん高くつきます

スライドショー機能は1つ目に該当しました。30日利用率 0.7%、利用者の起動回数も月2回未満。一方で、同じく利用率1%前後だった2画面分割の壁紙設定は、使う人が週5回以上使っていたため、導線を奥へ移して残しています。

数字は判断を支えますが、最後の一押しは「自分がこの機能の保守を続けたいか」です。個人開発では、開発者の気力も有限のリソースのうちだと考えています。

三段階で取り下げる — Remote Config による撤去フロー

消すと決めた機能も、次のバージョンでいきなり消すことはしません。三段階に分けます。

1. deprecated（告知期） — 導線に「まもなく終了」のバッジを出し、機能を開いたときに終了予定を知らせます。期間は2〜4週間
2. removed（導線撤去） — メニューから導線を消します。コードはまだ残します
3. コード削除 — 次のストア配信で、コードと依存パッケージを物理的に削除します

段階を Remote Config で制御しておくと、ストア配信を待たずに進められ、問題があれば即座に巻き戻せます。

// useFeatureStage.ts — Remote Config で機能の段階を制御する
import { useEffect, useState } from 'react';
import remoteConfig from '@react-native-firebase/remote-config';
 
export type FeatureStage = 'active' | 'deprecated' | 'removed';
 
export function useFeatureStage(featureKey: string): FeatureStage {
  const [stage, setStage] = useState<FeatureStage>('active');
 
  useEffect(() => {
    remoteConfig()
      .fetchAndActivate()
      .then(() => {
        const value = remoteConfig()
          .getValue(`stage_${featureKey}`)
          .asString();
        if (value === 'deprecated' || value === 'removed') {
          setStage(value);
        }
      })
      .catch(() => {
        // 取得失敗時は active のまま — ネットワーク起因で機能を消さない
      });
  }, [featureKey]);
 
  return stage;
}

導線側は、この段階を見て描画を切り替えます。

const stage = useFeatureStage('slideshow');
 
if (stage === 'removed') {
  return null; // メニューに出さない（コードはまだ残っている）
}
 
if (stage === 'deprecated') {
  return (
    <MenuItem
      label="スライドショー"
      badge="まもなく終了"
      onPress={openSlideshowWithSunsetNotice}
    />
  );
}
 
return <MenuItem label="スライドショー" onPress={openSlideshow} />;

なぜ三段階にするのか。一気に消すと、低利用率の機能でも「ある日突然消えた」という不信感がレビューに表れるからです。deprecated 期間を置いてから消す運用にしてからは、6アプリ通算で、撤去起因の星1レビューを受けたことがありません。

取得失敗時に active へ倒す設計も大切です。逆向きに倒すと、機内モードのユーザーから機能が消えます。デフォルト値は必ず「現状維持」側に置きます。

撤去時の落とし穴 — 導線の外にある残骸

メニューから導線を消しても、機能への入口はまだ残っています。私が実際に踏んだものを順に挙げます。

ディープリンクとウィジェット。過去のお知らせ通知やウィジェットから、撤去済み画面への直接遷移が残っていることがあります。ルーティングの入口で受け止め、黙ってクラッシュさせずにホームへ逃がします。

// 撤去済み画面への遷移要求はホームへ逃がす
if (route === 'slideshow' && stage !== 'active') {
  router.replace('/');
  showToast('スライドショー機能は提供を終了しました');
  return;
}

保存データ。再生間隔やプレイリストのような機能専用のデータは、コード削除と同時に「読む者のいない孤児データ」になります。容量は小さくても、マイグレーション処理が古いキーを参照し続けていると、後々の調査で混乱します。私は、コード削除の2バージョン後にストレージからも消す運用にしています。

ストア掲載情報。スクリーンショットや説明文に撤去済みの機能が写っていると、ユーザーの誤解を招くだけでなく、審査での指摘対象にもなります。撤去リリースの申請前に、App Store と Google Play 両方の掲載素材の棚卸しをセットで行います。

リリースノート。機能削除には触れずに済ませたくなりますが、私は1行だけ正直に書く派です。「スライドショー機能の提供を終了しました。ご利用いただいていた方には申し訳ありません」。隠して気づかれるより、先に伝えるほうが、結果としてレビューは荒れませんでした。

消した後に測る — 撤去の成否は「変化のなさ」で確認する

撤去は、消して終わりではありません。30日ほど、4つの数字を見ます。

• 関連クラッシュの件数。ゼロになっているはずです
• サポート問い合わせとレビューでの言及。スライドショーの場合は問い合わせ2件、うち復活要望が1件でした
• リテンションと DAU。変化がなければ成功です。下がった場合は、計測に表れないヘビーユーザーを見落としています
• 依存パッケージとビルドサイズ。スリープ抑制用の依存を1つ外せました

撤去の成功は、派手な改善ではなく「何も起きないこと」で確認します。リテンションが変わらず、クラッシュが減り、検証時間が短くなる。地味ですが、これが機能棚卸しの利益です。

浮いた時間は、使われている機能に回します。スライドショーの保守に使っていた時間で、利用率の高い検索まわりの改善を2件出せました。利用率45%の機能への投資は、0.7%への投資よりはるかに確実に返ってきます。

最初の一歩は、計測でも設計でもなく、書き出すことです。今週、ご自身のアプリの機能を10個書き出して、それぞれを最後に触った日を思い出してみてください。3ヶ月以上前の機能がひとつでもあれば、この手順の出番です。

機能を「消す」話を最後まで読んでくださった方は、きっとアプリを長く育てようとしている方だと思います。あなたのアプリの棚卸しが、良い整理になりますように。