💨

検索条件の卒業年次を動的に計算して定数管理を不要にする設計

に公開

はじめに

ASSIGNでは、新卒就活生向けアプリ 「ASSIGN新卒」 を Flutter / Dart で開発しています。

今回、新機能として 「募集機能」 をリリースしました。募集機能は、インターンや新卒採用に関する募集情報を学生が検索・閲覧できる機能です。

本記事では、この募集機能の開発において工夫した、検索条件の卒業年次を動的に計算して定数管理を不要にする設計について紹介します。

実現したいこと

募集機能では、募集対象の卒業年次を管理する必要がありました。
実現したいことは以下の通りです。

  1. 募集カードに対象の卒業年次を表示(例:26卒
  2. 募集一覧を絞り込む検索条件として対象となり得る卒業年次を一覧表示
  3. 年度が切り替わってもコードを修正せずに卒業年次の選択肢を自動更新

    検索条件の選択画面

課題

検索条件の卒業年次を定数で持つ場合、年度が切り替わるたびに修正が必要
例:2025年時点で[2026,2027,2028,2029]を定数で持った場合、翌2026年には[2027,2028,2029,2030]への更新が必要

解決策

最終学年からの距離という概念を導入しました。
卒業年次を「西暦」ではなく「最終学年からの距離」として管理します。
これにより、現在の日時から計算して動的に卒業年次の選択肢を計算できます。

/// 最終学年からの相対的な卒業年区分を表すEnum
enum GraduationYearOffsetValue {
  finalGrade,           // 最終学年
  secondFromFinalGrade, // 1つ前
  thirdFromFinalGrade,  // 2つ前
  fourthFromFinalGrade, // 3つ前
}

extension GraduationYearOffsetValueEx on GraduationYearOffsetValue {
  int get offset => index;
}

具体的な方針

方針 理由・効果
DBには不変の値(西暦)を保存 過去データの意味が変わらない
アプリ側はEnum+現在日時で動的計算 年度切り替え時の修正不要
表示・検索ラベルはユーティリティ化 一貫性と保守性を確保

実装例

/// 卒業年の基準値(年明けに翌年卒へ切り替え)
final int baseGraduationYear = DateTime.now().year + 1;

/// Enumから卒業年(西暦)を算出
int calculateGraduationYear(GraduationYearOffsetValue year) {
  return baseGraduationYear + year.offset;
}

/// 西暦から「yy卒」に変換
String formatGraduationYear(int year) =>
    '${year.toString().substring(2)}卒';

/// 卒年ラベル一覧を生成
List<String> generateGraduationYearLabels() {
  final labels = GraduationYearOffsetValue.values
      .map((v) => formatGraduationYear(calculateGraduationYear(v)))
      .toList();
  labels.add('卒年不問');
  return labels;
}

UIでの利用例

Column(
  children: [
    // 卒年ラベル一覧を表示
    ...generateGraduationYearLabels().map((yearLabel) => CheckboxListTile(
          title: Text(yearLabel),
          value: selectedYears.contains(yearLabel),
          onChanged: (_) {
            toggleSelection(yearLabel);
          },
        )),
  ],
)

得られた効果

効果 内容
年度切り替え時に修正不要 モバイルアプリのリリースコスト削減
データの永続性確保 西暦保存により過去データの意味が変わらない
表示・検索の整合性 共通ロジックで一元生成
拡張性 選択肢数や表記変更も容易

検討した代替案

方法 問題点
学年で管理(例:B4, B3, B2, B1 年度切り替えで意味が変わり、過去データの整合性が保てない
卒業年を固定配列でコード管理(例:[2026, 2027, 2028, 2029] 年度切り替え時に手動更新が必要
卒業年をEnumで長期間定義 冗長でメンテナンス性が低下
卒業年をDBテーブル管理+API取得 柔軟だがパフォーマンスへの影響が懸念される

最後に

今回のように、長期目線で保守性と修正容易性を高める工夫を行なっています。
ASSIGN新卒の開発では、このほかにも同様の設計パターンや改善事例がいくつかありますので、今後も随時紹介していく予定です。

ASSIGN

Discussion