プログラミングスクールでオリジナルアプリを作る前に｜仕様・動作確認・READMEの準備

MAKE IT YOURS · アプリ制作と学習計画

読んで、試して、
自分の学びを選ぼう。

01使う場面を決める
02動作で確かめる
03判断を説明する

つくりてラボ作成の練習例・記入用シート付き

自分の条件を書き出す

登録不要の記入用CSV。Excelなどで開いて使えます。

確認シートを保存 ↓

つくるものを言えると、支援の違いを聞きやすい

スクールで自分のアプリをつくりたいときは、作品数の前に「誰が、何をできれば完成か」を決めます。教材通りの機能を再現する支援と、自分で考えた仕様の相談に乗る支援は、同じ「制作サポート」という言葉でも範囲が違うことがあります。

ここでは、読む予定の本と読み終えた本を整理するアプリを、架空の制作題材にします。採用担当者による評価や合格基準ではありません。初心者が制作の範囲を言葉にし、相談の場へ持っていくための例です。

最初の版は、一人で使う読書記録に絞る

想定する利用者は、読みたい本のメモが散らばっている自分です。「本を登録する」「未読と読了を切り替える」「読みたい本だけを表示する」を最初の範囲にします。レビュー投稿、他の人との共有、外部サービスの書誌検索は次の候補に分けます。

機能を減らす判断も記録してください。最初から共有機能を入れない理由が「まず自分のメモ整理を完成させ、使い勝手を確かめたい」なら、目的と開発範囲の関係を説明できます。実在利用者の個人情報は練習データに含めません。

最初の版は、一人で使う読書記録に絞る
設計項目	記入例
利用場面	書店で気になった本を後で探す
最初に保存する項目	題名、著者名、未読／読了
完成の条件	登録し直さず、状態を変更して一覧を絞れる
今回は含めない機能	ログイン、公開レビュー、決済
自分で決めること	空欄の扱い、一覧の順序、削除時の確認

機能名を、試せる動作へ書き換える

「登録機能がある」だけでは、空欄をどう扱うか、保存後にどこへ戻るかが曖昧です。操作前の状態、入力、期待する結果を組にしておくと、自分でも講師でも同じ条件で動作を確かめられます。

以下の結果は、この練習で決めた仕様です。すべての読書アプリが同じ動作である必要はありません。実装に合わせて都合よく期待結果を変えず、仕様を変えるなら理由も残します。

機能名を、試せる動作へ書き換える
試す操作	期待する結果
題名を空にして登録	保存されず、題名が必要と分かる案内が出る
題名を入力して登録	一覧に一件だけ増える
未読の本を読了へ変更	読了表示になる。未読のみの一覧からは外れる
登録後にページを開き直す	保存仕様に沿って記録が残る
削除確認でキャンセル	本が一覧に残る
登録が一件もない	空の理由と登録する操作が分かる

講師へ聞くことは、企画・実装・公開で分ける

企画の相談では、機能を絞る段階から見てもらえるかを確認します。実装の相談では、エラー解消だけでなく、動いているコードの設計やテストにもコメントをもらえるかを聞きましょう。

公開を目標にするなら、配信環境や費用の見積り、入力処理、公開してよいデータの範囲まで相談できるかは別項目です。この例の動作表だけで、公開アプリの安全確認が完了するわけではありません。扱うデータや機能が増えるほど、追加の検証が必要です。

テーマは指定ですか。自分の読書記録アプリを題材にできますか。
機能一覧をつくる段階で、難しすぎる部分を相談できますか。
教材にない機能の質問はどこまで対象ですか。
動くコードの読みやすさやテストもレビューしてもらえますか。
公開後に問題が出た場合、相談できる期間と範囲はどこまでですか。

READMEには、利用方法と判断の跡を残す

GitHub公式のREADME案内は、プロジェクトの説明や使い始める方法など、読む人が理解するための情報を挙げています。読書記録アプリでも、画面の画像だけでなく、目的、動かし方、制約を書きましょう。

「工夫しました」で終えず、「未読の本を探すために、状態で絞る操作を一覧の上へ置いた」のように、目的と選択をつなぎます。AIや教材を使った部分、自分で変更した部分、未対応の動作も区別すれば、説明できる範囲が明確になります。

## 何のためのアプリか
読みたい本のメモを一か所に集める。
## 最初に試す操作
本を登録 → 読了へ変更 → 未読のみ表示。
## 自分で決めたこと
共有機能は含めず、自分の記録を探す操作を優先。
## 確認したこと
動作確認シートの結果と実行日を記載。
## 制約と未対応
対応環境、保存の条件、未実装の機能を記載。
## 使用したもの
教材・ライブラリ・AIの利用範囲と、自分で変更した部分を記載。