7日目のゴール
7日目のテーマは
「list と append を“説明できるレベル”にすること」です。
書けるようになる、だけで終わらせずに、
なぜ list を使うのか
なぜ append という形なのか
どこで list を変えているのか
どうすればきれいに設計できるのか
を、自分の言葉で言えるところまで持っていきます。
今日は「新しいテクニック」よりも、
“1週間分を整理して、自分のものにする日”です。
1週間でやってきたことを「1枚の絵」にする
list と append の成長ストーリーを振り返る
ここまでの6日間で、あなたはこんな階段を登ってきました。
1日目
list とは何か
append で一番うしろに足す感覚
2日目
list を「アプリの記憶」として扱う
バリデーション（空文字を防ぐ）
番号つきで見やすく表示する
3日目
条件つき append（OK なものだけ入れる）
数値に変換してから list に入れる
集めたデータを使って計算する（平均など）
4日目
重複チェック
追加前の確認
追加後のフィードバック表示
5日目
関数に分けて整理する
複数の list で状態を分ける（未完了／完了）
「状態の変化」として list＋append を見る
6日目
汎用的な追加関数を作る
入力と追加ロジックを分離する
append の“その場で書き換える”性質を意識する
7日目は、
これを「ただやったこと」ではなく
“自分が説明できる考え方”として整理します。
list を「アプリの状態」として説明できるか
list は“今の世界のスナップショット”
例えば、買い物リストアプリなら
shopping_list = ["りんご", "牛乳", "卵"]
これは単なる配列ではなく、
「今この瞬間、ユーザーが買いたいと思っているものの一覧」
です。
TODO アプリなら、
todos = ["掃除する", "メール返信"]
done_todos = ["洗濯する"]
これは、
未完了のタスクの集まり
完了したタスクの集まり
という“状態の違い”を表しています。
ここで大事なのは、
「list = 状態の集まり」
という視点を持てているかどうかです。
「変数に値が入っている」ではなく、
「アプリの世界の“今”を表している」と説明できると、
設計のレベルが一段上がります。
append を「状態を変える命令」として説明できるか
append は“世界を1つだけ変える操作”
例えば、
shopping_list.append("パン")
これは、
「アプリの世界に『パン』という新しい要素が増えた」
という意味です。
TODO アプリなら、
task = todos.pop(index)
done_todos.append(task)
これは、
「未完了の世界から1つ取り出して
完了の世界に1つ足した」
という“状態の移動”です。
ここで押さえておきたいのは、
append は「新しい list を作る」のではなく
“今ある list を直接書き換える命令”
だということです。
だからこそ、
戻り値を変数に入れない
if の条件に使わない
というルールが自然に導かれます。
自分のアプリを「責任の分担」で説明してみる
役割ごとに分けて言葉にする
6日目の買い物リストアプリを例にします。
def input_text(prompt):
return input(prompt)
def add_with_rules(items, text):
if text.strip() == "":
print("空の入力は追加できません")
return False
if text in items:
print("すでにリストにあります:", text)
return False
items.append(text)
print("追加しました:", text)
return True
def show_list(items, title="現在のリスト"):
print(f"\n{title}:")
if len(items) == 0:
print(" （何も登録されていません）")
else:
for index, value in enumerate(items, start=1):
print(f" {index}: {value}")
print()
これを日本語で説明すると、こうなります。
input_text
「ユーザーから文字を1つ受け取るだけの役割」
add_with_rules
「空文字や重複をチェックし、OK なら list に append する役割」
show_list
「list の中身を、人間にとって見やすい形で表示する役割」
そして、
「list を直接触っているのはどこか？」
と聞かれたら、こう答えられます。
list を作っているのは main
list に追加しているのは add_with_rules
list を読んでいるのは show_list
この「責任の分担」を説明できることが、
初級編のゴールとしてはかなり高いレベルです。
7日目のミニ課題：「自分バージョン」を言葉から設計してみる
お題：お気に入り本リストアプリ
最後に、コードを書く前提で
“言葉だけで設計してみる”課題を出します。
テーマは「お気に入り本リストアプリ」。
やりたいことは、あなたの言葉で決めていいですが、
例えばこんな感じです。
本のタイトルを追加できる
同じタイトルは2回入れない
空文字は入れない
最後に番号つきで一覧表示する
これを、まず日本語で分解してみてください。
アプリの状態
→ お気に入り本の list
状態を変える操作
→ 本を追加する（append）
追加のルール
→ 空はダメ
→ 重複はダメ
ユーザーとのやりとり
→ input でタイトルを受け取る
→ 終了キーワードを決める（例：「終了」）
表示
→ enumerate で番号つき表示
ここまで言葉で整理できたら、
あとは今までのコードを少し書き換えるだけで
自分バージョンのアプリが作れます。
7日目のまとめ：あなたはどこまで来たか
この1週間で、あなたは
list を「ただの配列」ではなく
“アプリの状態を表す入れ物”として見られるようになり、
append を「ただの追加」ではなく
“状態を変える命令”として扱えるようになり、
入力・バリデーション・追加・表示を
“役割ごとに分けて考えられる”ようになりました。
ここから先は、
同じパターンを別の題材に何度も当てはめていくだけです。
買い物リスト
TODO リスト
お気に入り本
行きたい場所
見たい映画
どれも本質は同じです。
「何を list にするか」
「どんなルールで append するか」
この2つを言葉で説明できる限り、
あなたはもう“自分でアプリの形を考えられる人”です。
