【マイレース開発記録(6)】phase設計の試行錯誤　　　　　　　　　　　　　　　　　　　　　　

“速さ”だけでは足りなかった

ユリウス日と天体計算が安定し、
スピードのロジックもある程度形になりました。

けれど、レースを動かしてみると違和感がありました。

確かに順位は変わる。
でも、どこか単調。

私はこのアプリを、

「流れ」だけでなく
「リズム」も見えるもの

にしたかったはずでした。

そこで必要になったのが、phase（フェーズ）設計です。

フェーズとは何か

フェーズとは、周期の中での“位置”です。

例えば、

• 月の周期（約29.5日）
• 火星の周期（約687日）

といった周期を持つ天体は、
常にぐるぐると回り続けています。

この「何周目のどの位置か」を
0〜1の値に正規化したものがフェーズです。

私はまず、非常に単純な式を書きました。

Python

def calc_phase(days, period):
return (days % period) / period

理論的にはきれいです。

• 周期の中の現在位置
• 常に0〜1の範囲

しかし、ここからが試行錯誤の始まりでした。

どの周期を使うのか

最初は、すべてのテーマを月フェーズで統一しようとしました。

しかし、それでは動きが似通ってしまいます。

そこで分けました。

• 恋愛・健康 → 月（29.5日）
• 勝負・仕事 → 火星（687日）

こうすることで、

• 短期的な揺れ
• 長期的な流れ

を同時に表現できるようになりました。

ここでようやく、

外の流れ（スピード）× 内側のリズム（フェーズ）

という構造が安定しました。

フェーズをどう“動き”に変えるか

フェーズは0〜1の数値です。

しかしそのままでは面白くありません。

私はそれを「ジャンプ」に変換しました。

Python

rhythm = (phase - 0.5) * 2

これで値は -1.0 〜 +1.0 の範囲になります。

さらに補正をかけます。

Python

return -rhythm * 0.15

これが「ゴール直前のジャンプ補正」です。

ただし、ここも簡単ではありませんでした。

補正値の迷走

最初は ±0.3 にしていました。

すると、

• 順位がフェーズに引きずられすぎる
• スピードの意味が薄れる

次に ±0.05 にすると、

• ほとんど差が出ない
• ジャンプが体感できない

最終的に ±0.15 に落ち着きました。

ここで私が学んだのは、

数式の正しさより、体験の自然さ

が重要だということです。

ロジックは正しくても、
ユーザーが「しっくり来ない」と意味がない。

閾値の設計

フェーズから「跳ねているかどうか」を判定するために、

Python

phase > 0.65

という閾値を設けました。

これもかなり試しました。

• 0.5 だと頻繁に跳ねすぎる
• 0.8 だとほとんど跳ねない

0.65 に落ち着いたのは、

• 適度に変化がある
• でも暴れすぎない

というバランスを取れたからです。

設計とは、

美しい式を作ることではなく、
振る舞いを調整することだと実感しました。

迷走から安定へ

phase設計では、

• 周期の選定
• 正規化
• 値域変換
• 補正値調整
• 閾値設計

と、想像以上に多くの検討が必要でした。

私は発達特性の影響で、

• 数式にこだわりすぎる
• 一部を最適化しすぎる
• 全体バランスを見失う

傾向があります。

しかし今回は、

AIとの対話を通じて、

• いま何を最適化しているのか
• 目的は何か
• ユーザー体験に寄与しているか

を常に言語化しました。

その結果、

理論と体験のバランスを取る設計にたどり着けました。

次回予告

12月1日から始まった設計フェーズ。

• 思想を整理し
• ロジックを迷走し
• 天体計算に詰まり
• 時間概念と格闘し
• 周期をモデル化した

ここまでで、ようやく
設計の土台が完成しました。

次の記事では、バックエンド実装とAPI設計に入っていきます。

【マイレース開発記録(7)】Flask API設計

ロジックが“概念”から“コード”へと固定される過程を書いていきます。