ここまでの回は、一人の子どもを想定して書いてきました。きょうだいがいる場合、同じ仕組みをそのまま人数分にすると破綻します。
この回は、人数が増えたときに何が壊れるかと、その対処を扱います。単純に2倍になるのではなく、質が変わるというのが要点です。
1. 単純に2倍にならないもの
手間は2倍で済むものと、それ以上に増えるものがあります。後者を先に把握しておくと、設計を誤りません。
| 対象 | 増え方 | 理由 |
|---|---|---|
| 予定の件数 | 2倍 | そのまま足し算 |
| 予定の衝突 | それ以上 | 組み合わせで発生する |
| 送迎の調整 | それ以上 | 同時刻に別の場所へは行けない |
| 費用 | 2倍前後 | 学年が違えば時期がずれる |
| 情報の取り違え | 新たに発生 | 一人なら起きなかった問題 |
| 心理的な負担 | それ以上 | 比較が生まれる |
2行目と3行目が実務上いちばん効きます。予定が2つあるだけなら管理できますが、それが衝突するかどうかは組み合わせを見ないと分かりません。しかも送迎が絡むと、物理的に不可能な組み合わせが生じます。件数が増えるほど組み合わせは急激に増えるので、人が目視で確認する方式は早い段階で限界が来ます。
予定表を眺めて衝突に気づくのは、件数が増えると急に難しくなります。特に「16時に A 校で面談、16時30分に B 塾へ送迎」のような移動時間を含む不可能性は、機械的に検知しないと見落とします。
2. 共通にするもの、分けるもの
設計の基本方針は、共通にできるものは共通に、分けるべきものは明確に分けることです。
| 情報 | 扱い | 理由 |
|---|---|---|
| 予定 | 共通の器に、誰のかを明示 | 衝突を検知するため |
| 費用 | 共通の器に、誰の分か明示 | 合計と内訳の両方が要る |
| 学校・塾からの連絡 | 共通の器に、宛先を明示 | 取り違えを防ぐ |
| 学習の記録 | 分ける | 比較が生まれる |
| 成績・答案 | 必ず分ける | 最も繊細な情報 |
| 振り返りのメモ | 分ける | 本人向けの内容が違う |
上3つは共通の器に入れないと機能しません。衝突の検知も、家計の把握も、全体を見なければできない。一方、下3つは同じ場所に置くと、意図しない比較が発生します。
特に5行目。成績を並べて置くと、見る側は必ず比較します。親が比較しないと決めていても、本人が見たときに比較します。物理的に分けておくのが、最も確実な配慮です。
3. 誰の情報かを常に明示する
共通の器に入れるものについては、誰のものかが常に見える必要があります。これを怠ると取り違えが起きます。
- 1予定のタイトルに名前を入れる — 「面談」ではなく「面談（長子）」
- 2色や記号で区別する — 一覧で見たときに識別できる
- 3取り込んだプリントに宛先を付ける — どちらの学校のものか
- 4費用の記録に対象者を入れる — 後から内訳を出せる
1番目は単純ですが効きます。予定表を見たときに、誰のことか一瞬で分かる状態を保つ。省略すると、後から見返したときに判別できなくなります。
3番目は EP.03 で扱ったプリントの取り込みに関わります。 で読み取る段階で、どちらの子のものかを付ける手順を入れておかないと、後から仕分けることになります。撮る時点で置き場を分けておくのが最も簡単で、 も増えません。
4. 衝突を機械的に見つける
予定の衝突は、人が気づく前提にしないのが原則です。EP.02 で扱った衝突検知を、人数分に対応させます。
from datetime import datetime, timedeltafrom itertools import combinations
# 場所ごとの移動時間（分）。家からの往復を想定して概算で持つTRAVEL = { ("自宅", "A校"): 25, ("自宅", "B塾"): 15, ("A校", "B塾"): 30,}
def travel_minutes(a: str, b: str) -> int: if a == b: return 0 return TRAVEL.get((a, b)) or TRAVEL.get((b, a)) or 60 # 不明なら余裕を見る
def find_conflicts(events: list) -> list: """送迎が必要な予定の中から、物理的に無理な組み合わせを探す。""" problems = [] need_escort = [e for e in events if e["escort"]]
for a, b in combinations(sorted(need_escort, key=lambda e: e["start"]), 2): if a["end"] <= b["start"]: gap = (b["start"] - a["end"]).total_seconds() / 60 need = travel_minutes(a["place"], b["place"]) if gap < need: problems.append( f"{a['who']}「{a['title']}」({a['place']}) の後、" f"{b['who']}「{b['title']}」({b['place']}) まで {gap:.0f}分。" f"移動に {need}分 必要" ) else: problems.append( f"時間が重複: {a['who']}「{a['title']}」と " f"{b['who']}「{b['title']}」" ) return problems移動時間を考慮するのが要点です。単純な時間の重複だけを見ると、「16時に終わって16時30分に別の場所」という移動が間に合わない組み合わせを見逃します。
移動時間が不明な場合に余裕を見る（コード内では60分）のも意図的です。検知しすぎるほうが、見逃すよりましだからです。誤検知なら確認して無視すればよいですが、見逃すと当日に困ります。
5. 比較を生まない配慮
仕組みの話から少し離れますが、設計しだいで比較が生まれるという点は意識しておく価値があります。
| 設計 | 起きること |
|---|---|
| 成績を1つの表に並べる | 必ず比較される（本人も見る） |
| 同じ形式で管理する | 違いが目立つ形になる |
| 進捗を並べて表示する | 遅れているほうが可視化される |
| 別々に管理する | 比較するには意図的な操作が要る |
最下行が目指す形です。比較したければできるが、放っておいては比較されない。この差は大きい。データを並べておくと、見るたびに比較が発生します。
上の子の記録は、外形的な情報（費用の目安、手続きの時期、必要な準備）としては有用です。一方、学習の進み方や成績の推移をそのまま当てはめるのは避けてください。学校も本人も違います。「上の子はこの時期にこうだった」という基準は、下の子にとって重荷になります。
6. 学年がずれることの利点
負担の話が続きましたが、きょうだいがいることの利点もあります。特に学年がずれている場合です。
- 手続きの時期が分かっている — 一度経験している
- 費用の見通しが立つ — 実績があるので推測ではない（EP.05）
- 仕組みが既にある — 一から作らなくてよい
- 何が無駄だったか分かる — 前回やらなくてよかったことを省ける
4番目が大きい。一度目は何が必要か分からないので、念のためやることが増えます。二度目は、やらなくてよかったことを省ける。これは時間と費用の両方で効きます。
そのためには、一度目のときに「これは無駄だった」を記録しておく必要があります。EP.04 で扱った振り返りに、この観点を1行加えておくと、次に効きます。記録がなければ、二度目も同じ「念のため」を繰り返すことになります。数年後の自分に向けたメモだと思って残してください。
単純に2倍にならないもの（衝突・送迎・取り違え・心理的負担）を先に把握する。予定と費用は共通の器に、学習と成績は分ける。共通の器では誰のものかを常に明示する。衝突は移動時間まで含めて機械的に検知し、不明なら余裕を見る（見逃すよりまし）。そして比較が自然に発生しない配置を選んでください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。