共通部品が育っていった4日間

課題
1. この記事でわかること
解決できたこと
本文

課題

複数のアプリやプロダクトを同じ基盤（Framework）で作っていく場合、共通化できる部分をいつ・どうやって切り出すかで迷う。毎回そのアプリ専用に書いてしまうと後で困るし、最初から汎用化しすぎても無駄が出る。

この記事でわかること

共通部品をいつ切り出すか迷ったときの判断材料
複数アプリをまたいで初めて見えてくる、共通化のペースが変わる理由

解決できたこと

「1本作るごとに、必要になった分だけ共通部品を切り出す」というやり方が実際にどう積み重なっていったか、そして途中でペースが変わった理由が分かる。

本文

この記事だけ、扱う期間がちょっと違う

これまでの記事はどれも1〜2日分の出来事を扱っていたけど、今回は少し違う。5本のアプリを作った、4日間分（2026年7月25日〜28日）の記録をまとめて振り返っている。

理由は単純で、「共通部品がどう育っていくか」という話は、1日だけ見ていても分からないから。複数のアプリをまたいで初めて見えてくる傾向を扱うには、もう少し広い範囲で見る必要があった。

実例1: 部品は、必要になったアプリの数だけ増えていった

自分がAIと一緒に個人開発しているアプリ群（普段使いのタイマーや、ちょっとしたパズル系など全部で5本）では、ゲームのロジックを扱う共通パッケージ（app_game_engine）に、アプリを1本作るごとに新しい部品が追加されていった。

最初のアプリ（Water Sort）を作ったときに、進行状況を管理する部品（StageProgress）ができた。2本目（集中タイマー）を作ったときには、それまで無かったタイマー機能（CountdownTimer）が必要になり、追加された。4本目（Block Puzzle）では盤面管理の部品（GridBoard・ComboTracker）、5本目（Number Merge）では実績管理（AchievementProgress）とタイルスワイプ管理（MergeGrid）が追加された。

最初から「将来使うかもしれない部品」を先回りして作っていたわけじゃない。実際に必要になったタイミングで、そのアプリのために作った部品が、後から見て「ほかのアプリでも使える形」になっていた。

実例2: 3本目あたりから、部品の作り方に「型」ができていた

部品を追加するたびに、同じ作り方を踏襲するようになっていった。「1つのクラスには1つの役割だけ持たせる」というルールで、盤面管理と連続クリアのボーナス計算を別のクラスに分けたときも、「既存の部品と同じ粒度に揃えて、ほかのジャンルでも転用しやすくするため」という理由が明確にあった。

最初の部品（StageProgress）を作った時点では、まだ「型」として意識されていなかったはず。でも3つ目、4つ目を作る頃には、新しい部品を作る前に「既存の部品と同じ作り方に揃える」という判断が自然に入るようになっていた。

実例3: パターンが固まった後、増えるペースが一気に上がった

最初の部品と2つ目の部品は、1日ずつ間を置いて追加された。ところがその後に追加された部品（盤面管理・連続クリアのボーナス計算・実績管理・タイルスワイプ管理）は、いずれも同じ1日に集中して追加されている。

これは偶然ではなく、「1クラス=1責務」という型が固まったことで、新しい部品を作る判断そのものが速くなったからだと考えられる。何を作るべきか・どう作るべきかの判断に迷う時間が減った分、実際に手が動く量が増えた。共通化は、最初は遅く進んで、型が固まるほど後から加速する、という順序だったと言える。

実例4: 似ているからといって、必ず再利用できるわけじゃない

5本目のアプリ（Number Merge）を作るとき、既存の盤面管理の部品（GridBoard）が使えそうに見えた。ただ実際には、「タイルをスワイプして合体させる」という操作の仕組みが既存の部品とは根本的に違っていて、そのまま使うことはできないと判断された。無理に既存の部品を流用せず、新しい部品（MergeGrid）を新規に作ることを選んだ。

実装中には、もう1つ小さな行き違いもあった。テストを書く際に「何も置かれていない盤面は動かせる状態のはず」という前提を書いてしまったが、実際には何も置かれていない盤面は動かせるものが無いので「動かせない」が正しい振る舞いだった。これは実装のバグではなく、自分が書いたテストの前提自体が誤っていたと気づいて直したケース。

「似ているから使えるはず」という思い込みだけで判断しないこと、そして自分の書いたテストの前提も一度疑ってみること。この2つが、この場面から見えてくる。