言語化されていない業務を、システムに落とすまで――四天王寺小学校アフタースクール導入事例（第2回）

公開日 2026年11月6日導入事例

本稿では、「言語化されていない業務をどう炙り出し、受講管理・児童管理・スケジュール管理の仕組みとして実装したか」という要件定義から実装までの実務に深く踏み込む。

本連載には、以下の3つの組織が登場する。

正式名称	本文での呼称	立場
学校法人四天王寺学園（四天王寺小学校）	学園	クライアント（小学校の運営母体）
販売代理店S	代理店S	学園のITパートナー（販売代理店）
テクノピアン株式会社	テクノピアン	弊社：開発ベンダー（TechnoSMSの開発・提案を担当）

TechnoSMS編集部

スクール管理システム「TechnoSMS」を開発するTECHNOPIAN株式会社の広報。「業務をシステムに合わせるのではなく、業務のためのシステムを作る」が信条。数十社以上の導入指揮経験を活かし、徹底した要件定義によって、スクール独自の複雑な運用ルールを最適なシステムにする過程をお伝えします。

「アフタースクールやってます」――最初の説明とのギャップ

四天王寺学園が抱える課題は「Excelで行っているアフタースクールの運営をシステム化し、業務効率化をはかりたい。保護者とのやり取りを可視化した」というものだった。

しかしいざ要件定義を開始すると、以下のような複雑な運営構造を持っていた。

受講しない児童も含む、全校児童約300人の下校管理が必要
全学年対象の講座と1〜2年生限定の講座が混在
振替えができるのはEトレのみ（他講座は不可）
翌年度から運用ルールが変わる可能性がある

現場の教員から得られる情報は、どうしても断片的にならざるを得ない。テクノピアンはそれを前提に、散らばった断片を一つひとつ拾い集め、突き合わせ、業務全体の構造として組み直していった。要件は「待つもの」ではなく「引き出すもの」——このプロジェクトはその姿勢の体現だった。

業界共通言語があったから「説明しなくていい、話が早かった」

ヒアリングをスムーズに進めた最大の武器は、テクノピアンがスクール業界で積み上げてきた業務知識の蓄積である。

スクール運営には共通する業務の流れがある。講座の準備、申込受付、スケジュール調整、日々の受講管理、請求処理、そして次年度の準備。この基本的な業務フローは、多くのスクールで共通しており、詳細な説明を受けなくても認識を合わせることができた。

一方、私立小学校ならではのルール（サポートタイムの位置付け、全員対象の下校管理など）は、この共通知識を土台に積み上げる必要があった。

現場から出てくる断片的な言葉を、そのまま要件として受け取らず、業務全体の流れや運用背景を踏まえながら、「本当に実現すべきこと」は何かを整理し、システム要件へ落とし込んでいった。この作業には、スクール運営に対する業界理解が欠かせない。要件定義とは、現場の業務をシステム要件へ翻訳するプロセスなのである。

申し込みフォームの緻密な作り込み――「講座ありき」から「曜日ありき」への発想転換

本プロジェクトで実装上の大きな課題となったのが、保護者向けの申込フォームだった。一般的なスクールでは、「受講したい講座を選択する」という流れで申込みを行う。一方、四天王寺学園のアフタースクールでは、日々の下校時間を把握しなければならず、曜日ごとに下校方法を登録し、その中で受講する講座やお迎え有無、下校時間を決定する運用となっていた。

	一般的なスクール申込（講座起点）	学園のアフタースクールの申込（曜日起点）
入力の起点	受けたい講座を選ぶ	月曜日はどうしますか？
入力の流れ	受けたい講座を選ぶ ↓ 日程を選ぶ ↓ 申し込む	月曜日はどうしますか？ ↓ 火曜日は？ ↓ …（月〜金を1枚で登録）

アフタースクールを利用しない児童も含め、全児童について曜日ごとの下校予定を登録する必要がある。そのため、「講座を選んで申し込む」という標準的な申込フォームとは画面構成そのものが異なり、専用の申込フォームを設計する必要があった。

さらに、曜日ごとの選択内容に応じて入力できる項目が変わる仕組みや、誤った組み合わせで申し込めないようにする入力チェックも実装した。

制約	内容
ルール①	サポートタイムなしにアフター１は選べない
ルール②	アフター１の受講なしにアフター２は選べない
ルール③	アフター２受講後の下校時間が2択になる

これらはヒアリングで初めて出てきた「暗黙のルール」である。選択肢が連動して有効化される仕組みをシステム側に組み込み、保護者の入力ミスを根本から防いでいる。

「人間にやらせると間違いが出る」――運用負荷を下げる機能設計

学期ごとに約50講座、それぞれに開講曜日・時間帯・対象学年・定員を手入力するということは、講座作成画面とスケジュール設定画面を200回近く往復しながら、同じようなクリックとキー入力を何時間も繰り返すということである。しかも学期が変わるたびに同じ作業が発生し、入力漏れや設定ミスのリスクもつきまとう。

そこで実装したのが「スケジュールを含むコピー」機能だ。通常のコピーでは講座内容しか複製されないが、この機能ではスケジュール情報ごと複製できるため、翌学期の講座登録作業が大幅に短縮され、ヒューマンエラーも防止できる。

メールアドレスを持たない設計――「削る」判断もカスタマイズの本質

TechnoSMSの標準仕様では、マイページはメールアドレスの登録を前提としている。メールアドレスは、受講生がマイページのアカウントを取得した際のアカウント情報の通知や、パスワード変更の手続きに使われるためである。しかし学園からは「システムにメールアドレスを持たせたくない」という要望が寄せられた。

テクノピアンはこの要望を、個人情報を複数のシステムに分散して持つことを避けるための設計要件として受け止め、標準機能を意図的に削ぎ落とすカスタマイズを行った。そのうえで、メールアドレスなしでの運用を想定し、二つの代替設計を用意した。

マイページのアカウント発行にあたっては、学校と保護者への通知内容を事前にすり合わせ、システムに登録しておく
保護者がマイページのパスワードを忘れた際の問い合わせ先と対応手順を、学校側とあらかじめ取り決めておく

保護者への通知そのものは、学園がすでに運用していた連絡網システムに一本化した。メールアドレスを複数のシステムで管理するリスクを、設計の段階で取り除いている。

「標準で当たり前についている機能を、意図的に削る判断ができること」——これもカスタマイズ力の重要な側面である。機能を追加するだけがカスタマイズではない。

まとめ：業務理解こそカスタマイズ力

今回の実装内容と成果を整理する。

課題	対応	効果
全児童の下校・受講管理が必要	曜日起点の一括申込フォーム	保護者の入力ミスを防止
複雑な受講ルールの制御	入れ子バリデーションの実装	申し込み誤りをシステム側で排除
マスター登録作業が膨大	スケジュール込みコピー機能	運用負荷を大幅に軽減
個人情報の分散管理リスク	メールアドレス非保持の設計	セキュリティポリシーへの準拠