設計した業務を、現場が回すまで――四天王寺小学校アフタースクール導入事例(第3回)

連載:TechnoSMS導入事例 四天王寺小学校アフタースクール(全4回)第3回
第2回では、言語化されていなかったアフタースクールの業務を要件へ翻訳し、曜日起点の申込フォームや連動する入力チェックとして「動く画面」に落とすまでを扱った。ただ、画面が動くことと、現場がその画面で毎日の業務を回せることは別の話である。本稿が記録するのは、その間にある工程だ。画面が出来上がってから本格稼働までのあいだに、学園とテクノピアンは動作確認、現地での操作トレーニング、1年生に限定したトライアル運用という三つの工程を踏んでいる。稼働後の話は第4回に譲り、本稿はこの「稼働の手前」を記録する。
本連載には、以下の3つの組織が登場する。
| 正式名称 | 本文での呼称 | 立場 |
|---|---|---|
| 学校法人四天王寺学園(四天王寺小学校) | 学園 | クライアント(小学校の運営母体) |
| 販売代理店S | 代理店S | 学園のITパートナー(販売代理店) |
| テクノピアン株式会社 | テクノピアン | 弊社:開発ベンダー(TechnoSMSの開発・提案を担当) |
この記事の要点
- 本番稼働前にステージング環境を公開し、学校側と保護者側の双方の視点から要件どおりシステムが動いているかを確認した
- 動作確認は空の画面では成立しない。1学期分の週間スケジュールを事前に登録した状態で臨んだ
- 操作トレーニングは機能の順ではなく、想定される年間の業務順で組んだ
- 全学年の同時稼働は見送り、1学期は1年生に限定して運用した。2〜6年生の申込は前年度のうちに終わっており、新システムの稼働開始と重ならないためである
- 先生の入れ替わりを前提に、トレーニング用のステージング環境は納品後も残している
実装が終わった時点では、まだ何も終わっていない

要件定義を終えたのは2025年11月。そこから2月末まで、テクノピアンはスクール管理システムTechnoSMSの設計・テスト工程に入った。第2回で扱った曜日起点の申込フォーム、選択内容が連動する入力チェック、スケジュールを含むコピー――言語化されていなかった業務を要件へ翻訳した成果が、ここでようやく「動く画面」になる。
しかし、動く画面ができたことと、現場がそれで業務を回せることは別の話だ。四天王寺小学校のアフタースクールは、在校児童約300名(1〜6年生)のうち約3分の2が受講する規模で、受講管理に加えて、受講しない児童も含めた全員の下校管理を担っている。本番稼働の初日から、先生方はこの仕組みで毎日の名簿を出さなければならない。実装完了は折り返し地点にすぎず、ここから先は「作ったものを渡す」工程ではなく「現場が回せる状態まで一緒に持っていく」工程になる。
動作確認は、見せる工程ではなく触ってもらう工程だ

本番稼働は4月を予定していた。その2ヶ月前にあたる2026年2月、オンラインで動作確認(受入テスト)を実施した。学園側からは管理職と現場の先生が参加している。
目的は冒頭で共有した。学校側と保護者側の双方の視点から動作を確認し、開発が要件どおり行われているかを確かめる工程である、と。運用イメージと保護者側の操作をダイジェストで見てもらうもので、データ登録の実演は含まない。登録データが実務上のイメージと乖離していれば申し出てほしい、その内容は翌週の操作トレーニングに反映する――戻し方まで含めて、最初に道筋を示した。
動作確認と、その翌週の操作トレーニングの成果を最大化するために、事前の準備もしている。テクノピアンは、学園から連携された2026年1学期のアフタースクール週間スケジュールをもとに、講座とスケジュールのデータを登録した状態で臨んだ。空の画面で「ここに入力すればこう動きます」と説明するのと、自校の時間割が入った画面を動かして見せるのとでは、確認の解像度がまるで違う。
入れるデータの量は加減している。1学期分をすべて登録するのは負荷が大きいため、動作確認と、その翌週の操作トレーニングで扱う範囲に合わせた量にとどめた。児童名や連絡先といった個人情報にあたるものは、当然ながらダミーデータである。
学園に公開したのはステージング環境である。この環境は検収環境を兼ねており、学園の検収完了をもって本番環境をオープンする段取りとした。
ステージング環境には、保護者が使う受講生マイページも含まれる。申込ができるアカウントとできないアカウントの両方も用意した。管理画面だけの操作では見落としてしまう確認項目が、ここにあるからだ。管理画面で登録したデータが、保護者のマイページに正しく反映されているか。たとえば2年生の保護者アカウントでログインしたとき、そこに2年生の情報しか表示されないこと。データ登録の誤りは、この突き合わせでしか見つからない。潰しておかないと、稼働後に保護者を巻き込んだ問題になる。
ここまでの進め方――実データを入れた状態で動作確認に臨むこと、そして保護者が使う受講生マイページまでステージングに開放すること――は、四天王寺学園の下校管理という要件があったから特別に行ったものではない。テクノピアンがスクール管理システムを導入するときに、他のスクールでも共通して取っている進め方である。
操作トレーニングは、機能の順ではなく業務の順で組む

動作確認の翌週、同じ2月に、大阪にある学園の会議室で操作トレーニングを実施した。形式は対面である。先生方7〜8名が並び、代理店Sも同席した。所要は約2時間。環境は動作確認で公開したステージング環境をそのまま使った。
配ったのは、機能の一覧ではない。年間の業務を時系列に並べた資料だった。
| 業務区分 | 頻度 | 主な業務の流れ |
|---|---|---|
| 準備 | 学期ごと | 講座登録 → スケジュール登録 |
| 申込み | 学期ごと | 保護者がマイページから講座を申し込む |
| 申込後調整 | 申込受付後 | 受講人数調整 → 申込み変更対応 → 申込み忘れ対応 |
| 日常業務 | 毎日 | 保護者からの連絡の参照・代理登録 → 名簿備考の入力 → 名簿出力(全体/講座)→ 出欠管理 → 振替処理 → お知らせ |
| 年次業務 | 年度末 | 新入生登録 → 2〜6年生のクラス・出席番号変更 |
学期の頭に何をして、申込を締めた後に何が起きて、毎日どの画面を開き、年度末に何を更新するのか。年間の流れに沿って、発生するシーンごとに操作を説明していく。社内で「紙芝居」と呼ぶ形式で、提案段階で運用イメージを共有するときから一貫して使ってきた作り方でもある。
この形式にすると、単体の操作説明では出てこない注意点が自然に混ざってくる。たとえば講座登録では、前提が三つ重なる。
- アフタースクールの講座だけでなく、基礎学力サポートタイムやフォローアップ教室など、お迎えに関係するものをすべて登録する
- 授業が終わったらすぐ下校する児童向けに「すぐ下校」という講座を作る。受講しない児童の下校時刻も管理する仕組みだからだ
- スケジュールが登録されていない講座はマイページに表示されないため、「すぐ下校」にもスケジュールを登録する

どれか一つを飛ばすと、下校情報を正しく案内できない。
保護者からの連絡も同じである。マイページから学校へ連絡を送れるのは受講当日の12時まで。それを過ぎると保護者は学校に電話をかけてくる。その電話を受けた先生が管理画面から代理で連絡を登録すると、開封済みの状態で記録され、保護者のマイページの連絡一覧にも表示される。トレーニングでは、この「12時を過ぎた電話」までを一つの業務シーンとして扱った。児童管理の画面から名簿出力まで、機能を横断する動きとして手を動かしてもらうためである。
資料の作り分けも意識した。サインインや画面構成、お知らせ機能といった標準機能の説明は製品のオンラインマニュアルに寄せ、年間業務の資料には学園固有の流れと注意点だけを残している。説明はステージング環境で実際に入力してもらいながら進めた。入力すれば結果がその場で一覧に反映され、自分の操作が何を変えたのかが目に見える。
そのトレーニングの場で、先生方からこんな声が出た。
「(うちの業務を)自分たちよりもよく知っているんじゃないか」
この2時間で確かめられたことは二つある。一つは、先生方が実際の画面を操作し、日々の業務をこのシステムで回せると確認できたこと。もう一つは、テクノピアンが学校の業務を正しく理解できていたことだ。先生方のこの一言は、後者の何よりの証明だった。
運用している当事者ほど、自分たちの業務を時系列に並べて眺める機会は持ちにくい。第三者が業務の順番で組み直して見せたとき、初めてそれが可視化される。
全学年の同時稼働を捨て、1年生から始めた

要件定義の段階で確認していた立ち上げ計画は、二段階だった。2〜6年生が4月から正式受講を開始し、1年生は少し遅れて1週間のお試し受講期間を挟んでから、5月に正式受講へ入る。募集は2〜6年生分を3月中に完了させる想定である。
ところが、学校のカレンダーはこの計画に対して厳しい。
学校には毎年4月に新入生が入る。裏を返せば、2年生以上の在校児童は前年度のうちに翌年度の申し込みを終えている必要がある。4月から新システムを稼働させると言っても、2年生以上の募集と申込は、検収とデータ移行が走る2月から3月のあいだに完了していなければならない。しかも3月は先生方の春休み期間にあたり、システム操作の日程を確保すること自体が難しい。
一方、1年生は事情が違う。入学して学校に慣れた頃、1ヶ月ほど経ってからアフタースクールの募集が始まる。募集から申込、日々の運用まで、最初の1周をまるごと新しい仕組みで回すことができる。
そこでテクノピアンと学園は、1学期は1年生を対象に運用する形を選んだ。全学年の同時稼働という当初の絵は、いったん捨てている。システムの完成度ではなく、学事日程の構造が稼働範囲を決めた判断である。
1年生で1学期を回した結果、評価されたのは名簿だった。名簿がすぐ出る。第1回で触れた導入前の課題――先生1名が業務に張り付き、伝達ミスが「言った・言わない」に発展していた状況――の中心にあったのが、この名簿出力である。毎日Excelで手作業をしていた工程が、検索条件を指定してボタンを押すだけになった。
「これならいける」という手応えが出たことで、2学期から全学年への展開が始まった。今まさにその状態にある。全学年に広げてから何が起きたのかは、第4回で扱う。
練習環境は、納品しても閉じない

対面で操作トレーニングができる機会は限られている。しかし、教える機会がそこで終わるわけではない。
ステージング環境は、納品後も学園に開放したままにしている。年度が替われば先生の入れ替わりがあり、新しく担当になった先生が本番データに触れる前に練習できる場所が要る。管理画面で入力した内容が受講生マイページにどう反映されるかを確かめたいときにも使えるし、修正対応を行った際の変更点を確認する環境としても機能する。
これも本事例に限った措置ではない。テクノピアンでは、契約が続いているあいだ、ステージング環境を開放し続けている。納品したらそこで閉じる、という運用は取っていない。
学校では先生の出入りが必ず起きる。特定の人が覚えている前提で運用を設計すると、その人が異動した瞬間に業務が止まる。練習環境を閉じないのは、そのための保険である。同時に、現場が自分で試せる場所を残しておけば、問い合わせる前に触って確かめられる。それだけ双方の負荷が下がる。
まとめ:実装から稼働までの4工程
| 工程 | やったこと | 狙い |
|---|---|---|
| 実装 | 要件定義の内容を動く画面にする(2025年11月〜2月末) | 設計の成果物を検証できる形にする |
| 動作確認 | 1学期分のデータを登録した状態でステージング環境を公開(稼働2ヶ月前の2月) | 学校側・保護者側の両視点で要件充足を確認する |
| 操作トレーニング | 年間業務の時系列に沿った資料で、対面・約2時間・実機操作(同じく2月・動作確認の翌週) | 機能ではなく業務として使える状態にする |
| 1年生トライアル | 1学期は1年生に限定して運用 | 学事日程に無理のない形で最初の1周を回す |
得られた要点は、次の4点である。
- 動作確認はデータを入れた状態で行う:空の画面では実務との乖離が見つからない
- 保護者側の画面も一緒に開放する:学年ごとの登録誤りは管理画面だけでは検出できない
- トレーニングは業務の順に組む:機能の順で教えると、シーンとシーンのあいだが抜け落ちる
- システム導入の立ち上げ範囲は学事日程が決める:完成度ではなく業務カレンダーが決める
第4回では、2学期からの全学年展開と、運用が始まったことで見えてきたより効率的な使い方、そこから生まれた追加開発とサポート対応の実際を扱う。
テクノピアンの導入支援は、システムを納品して終わりではない。業務の流れに沿って操作を伝え、練習できる環境を残し、いつ・どこから稼働させるかまで一緒に設計する。
「システムは入れたいが、現場が使いこなせるか不安だ」という段階からでも、ぜひお気軽にご相談いただきたい。
連載:TechnoSMS導入事例 四天王寺小学校アフタースクール(全4回)

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