このユニットのゴール
事業所の困りごとを1つ解決する業務アプリを、設計 → 実装 → テスト → 説明書 → 引き継ぎまで作りきり、発表する。
進め方の地図
| 週 | やること | 仕上がるもの |
|---|---|---|
| 1週目 | 授業1: 困りごとを聞いて、企画にする | 企画シート1枚 |
| 2週目 | 授業2: 設計 ― データから画面へ | 設計図3点 + 週計画 |
| 3〜4週目 | 実装 ― 週ごとのマイルストーン | 毎週、動くデモ |
| 5週目 | 授業3: テストと説明書 | 検査済みアプリ + 説明書 |
| 6週目 | 授業4: 引き継ぎと発表会 | 引き継ぎ完了。修了! |
授業1: 困りごとを聞いて、企画にする
良い業務アプリは、机の上ではなく現場の声から生まれます。最初の1週間は、コードを書かずに「聞く」に使います。
例題 (リードつき) | 困りごとヒアリングから企画シートへ
- スタッフに3つ質問する「毎日・毎週、手作業で繰り返している記録はありますか?」「紙やホワイトボードで管理していて、たまに困るものは?」「数えたり集計したりに時間がかかっている作業は?」― 自動化の種は、この3つの質問で見つかります。
- 候補から1つ選ぶ迷ったら定番から ― 備品の貸し出し管理 / 作業実績の記録と集計 / 清掃や戸締まりのチェック記録 / 本棚の貸し出し管理 (ユニット3の演習の実戦版) / 日報アプリの本格運用版 (ユニット5の続き)。
- 4行の企画にする「①誰の ②どんな困りごとを ③どう解決する ④完成の証拠は何か」。例: ①スタッフの ②備品の行方が分からなくなる困りごとを ③貸し出しと返却を記録するアプリで解決する ④1週間、本当に運用できたら完成。
- 機能を2つの箱に分ける「ないと成立しない機能 (最大3つ)」= MVPと、「あったらうれしい機能」に分けます。MVPだけで企画を確定し、スタッフに見せて1回削ります。
本物のデータを扱う約束: 題材が本物になると、責任も本物になります。利用者さんの個人情報 (名前・体調など) を扱う題材は避けるか、必ずスタッフと相談して匿名化 (ID化) します。コードと一緒にデータをGitHubへ上げない (.gitignoreにdbファイルを入れる) ことも、ここで覚える実務の作法です。
授業2: 設計 ― データから画面へ
バックエンドの設計は、画面からではなくデータから始めます。順番はいつも同じです ― テーブル → API (窓口) → 画面。
例題 (リードつき) | 設計図3点セット + 週計画
- テーブル設計紙に「もの」と「出来事」で表を分けます (ユニット3の型)。備品管理なら
items (id, name)とloans (id, item_id, person, lend_day, return_day)の2表です。 - 窓口の一覧「一覧を見る / 借りる / 返す / 集計を見る」のように、必要な操作を箇条書きにして、それぞれをFlaskのroute (ページかAPI) に割り当てます。
- 画面の手描きラフメイン画面1枚のラフを描きます。ユニット5の経験から、「毎日使う人が、最少クリックで終わるか」を基準にします。
- 週計画と予備週「3週目: テーブルと一覧表示 / 4週目: 書き込み系と守り / 5週目: テストと説明書」。予備の時間を最初から計画に入れるのがプロの計画です。毎日の終わりに1コミット + 明日の最初の一手メモ、も忘れずに。
実装の2週間 ― 完走のための約束
- 縦に1本通してから、横に広げる最初の2日で「1テーブル + 1画面 + 保存1本」だけの最小版を動かします。全部の土台を先に作ろうとすると、動くものがない期間が長くなり、心が折れます。
- 週の終わりに、動くデモ未完成でも、毎週スタッフに触ってもらいます。本物の利用者の「ここが押しにくい」は、どんな教科書より正確です。
- 15分ルール詰まったら、Tracebackとコードを添えてAIに相談して前へ。何を聞いたかのメモは発表の材料になります。
- 遅れたらMVPを守る削る判断は、敗北ではなく実務スキルです。削った機能は「次の版で」リストに移します。
授業3: テストと説明書
業務アプリの納品物は、コードだけではありません。「壊れない確認」と「使い方の紙」がそろって、初めて道具です。
例題 (リードつき) | 出荷前の3点セット
- 意地悪テスト表「空入力 / 数字欄に文字 / 存在しないID / 同じ操作の連打 / データゼロの初回起動」の5項目を表にして、全部試して直します。
- 利用者向け説明書 (1枚)スクリーンショット入りで「①起動の仕方 ②毎日の使い方 (3手順以内) ③困ったときの連絡先」をA4の1枚にまとめます。読み手はパソコンが得意でない人、と想定して書きます。
- 管理者向けREADMEGitHubのリポジトリに「アプリの目的 / 動かし方 (pip installから) / テーブル構成 / バックアップの仕方 (dbファイルをコピーするだけ) / よくあるトラブル」を書きます。バックアップ手順を書くのを忘れないこと ― データを預かる道具の責任です。
授業4: 引き継ぎと発表会
例題 (リードつき) | 引き継ぎの儀式
- 運用テスト1週間5週目から、アプリを実際の業務 (または業務に近いごっこ運用) で1週間使ってもらいます。出てきた不具合や要望を記録し、直せるものを直します。
- 引き継ぎミーティングスタッフに、説明書を見ながら「自分なしで」起動から日常操作までやってもらいます。あなたは口を出さずに見守り、詰まった場所を説明書に追記します。自分がいなくても回る状態が、引き継ぎの完成です。
- 発表 (5分)構成は「①困りごとと聞き取り → ②設計 (テーブル図を見せる) → ③デモ (2分) → ④運用1週間で学んだこと → ⑤次の版でやりたいこと」。運用の話ができる発表は、作品の発表ではなく仕事の報告です。
発表会 ― そして修了へ
卒業制作の提出
発表と引き継ぎを終えたら、コースのページの「コース修了のチェック」5項目を確認しましょう。全部にチェックがついたら、バックエンドコース修了です。10ヶ月前に print("こんにちは") から始めたあなたが、いまは事業所で動き続ける道具を残して卒業します。それは紛れもなく、エンジニアの仕事です。おめでとうございます。
修了後の道: Goalページの「卒業後の道」へ。データ入力の自動化・集計ツールの作成・小さな業務システムの保守は、障害者雇用や在宅の求人でも需要のある領域です。GitHubと「運用まで経験した」物語が、あなたの証明書です。
つまずきやすいポイント
「困りごとが見つからない」とき: 「困っていますか?」と聞くと、人は「特に…」と答えがちです。「昨日、紙に何かを書きましたか?」「先週、何かを数えましたか?」のように行動を聞くと、種が見つかります。それでも見つからなければ、日報アプリの本格運用版で何の問題もありません。
運用で不具合が出て落ちこんだら: 運用初週の不具合は、出るのが普通です。プロの製品でも出ます。大事なのは「記録して、直して、説明書に反映する」の一周ができること ― それを今、あなたはやっています。
発展チャレンジ (余力のある方へ)
発展チャレンジ
- 毎週月曜の朝に、先週の集計を自動でテキスト出力する「定期レポート」機能を足してみましょう (Windowsのタスクスケジューラを調べることになります)。
- 「ログイン機能はなぜ難しいのか」(パスワードの保存・セッション管理) を調べて、3行メモにまとめましょう。次に学ぶべき山の地図になります。
- 自分の10ヶ月の学習記録 (ユニット2の記録ツールのデータ) を集計して、発表の最後に「学習時間の見える化」として添えてみましょう。道具で自分を語る ― バックエンドらしい締めくくりです。