W-01 / FLAGSHIP
学習塾向け統合業務システム
東広島市の、とある塾 — 出席・通知・レポート・職員ポータルの段階統合
東広島市の、とある学習塾の開業準備から技術面で参画しました。QR 入退室、保護者通知、職員向けポータル、月次レポートを一つの流れにまとめ、現場の声で拡張を続けています。正式名称・所在の詳細は公開しません。
課題PROBLEM
少人数で回す塾では、入退室の記録、保護者への連絡、月次の報告が手作業になる見込みでした。事務に時間を取られれば教える時間が削られます。「誰が・何を・いつ」を仕組みに預けることが、開業前からの課題でした。
自分の役割ROLE
要件ヒアリング、業務設計、実装、デプロイ、運用改善、障害対応までを一貫して担当。職員との往復で仕様を固め、導入後の改修も継続しています。
制約CONSTRAINTS
- 既存の Google Workspace 資産を活かし、新規インフラを増やしすぎない
- 職員の IT リテラシー差を前提に、学習コストの低い操作に寄せる
- 開業期は仕様が固まりきらないまま走り出す必要がある
- 生徒・保護者の個人情報を扱うため、公開資料では塾名・住所・内部 URL を出さない
解決策SOLUTION
デスクトップの入退室アプリ、Google Apps Script による通知・ポータル、月次レポート生成を段階的に接続。入力はそのまま残し、正規化と見せ方を分けるデータ設計で、運用中の項目変更に耐える構成にしました。
判断の芯 — NARRATIVE
「最初の本番開発は、現場の会話から始まった。」
着手時点では、本番の業務アプリを開発した経験がありませんでした。出席のデスクトップアプリも、通知の仕組みも、実務で作るのは初めてでした。
コードの方針は AI と確認しながら一つずつ固めました。分からないことを調べ、選択肢を比べ、動くところまで持っていく——その相棒として AI を使いました。
中心は実装ではなく、何を作るか・何を省くか・どの運用に合わせるかです。運営者との対話で困りごとを聞き、使ってもらい、返ってきた声で直す往復が設計の本体でした。
技術はあとから覚えられます。「何を作るべきか」は現場の会話からしか出てきません。
重要な設計判断DECISIONS
NOTE 01 — 主判断
入力・正規化・見せ方を分ける
現場の入力はそのまま保存し、正規化と見せ方を分離しています。運用しながら項目を変えても過去データが壊れにくい構造にしました。
NOTE 02
入室時の3つの質問 — 気分・睡眠・来所目的
教育心理学の知見からの判断です。打刻を「今日の自分を一度言葉にする」入口に変え、記録操作に自己理解の意味を重ねています。
NOTE 03
職員が日常で触れる道具から組み立てる
なじみのあるフォームや表計算から始め、「何をどう記録するか」のイメージを一緒に固めてから統合しました。現場が覗ける場所にデータがあることで運用が続きます。
NOTE 04
月次レポートはワンクリックで
月末の集計・転記・整形を自動化し、続けられる報告は手間がない報告だけ、という前提で設計しました。
体験への効き方FOR WHOM
カードをかざし、短い質問に答えると入室完了。自分の状態を言葉にする小さな習慣がつきます。
入退室の連絡と、月末の学習の様子が届く流れを用意しています。
出席・レポートまわりの手作業を減らし、教える時間に寄せられるようにしています。
画面SCREENS
結果RESULTS
運用継続
2025年4月〜当該塾で利用
担当範囲
ヒアリング〜設計・実装・運用・改修
拡張の仕方
現場フィードバック単位で段階追加
振り返りRETROSPECTIVE
初期は「動けばよい」UI 側の導線に依存しがちな箇所がありました。到達できない機能は納品と同じだという反省から、サーバ側の認可と、運用者が状態を見られる画面を後から足しました。完了条件を「画面が動く」ではなく「現場がたどり着ける」まで含めるようにしています。
いまの位置IN OPERATION
東広島市の、とある塾で導入・運用中。出席から始まり、通知・レポート・職員ポータルへと拡張しています。シフト管理は汎用 SaaS「シフリー」として別プロダクトで提供しています（本システム専用の内製モジュールではありません）。
TECH
Python / Kivy ・ Flask ・ Google Apps Script ・ Google Forms・Sheets・Calendar・Gmail API ・ ReportLab ・ PostgreSQL ・ Claude Code