業務システムにおける課題解決ポイント 【 学習塾② 「 入退会管理 」編 】

では今日は、学習塾のシステムがカバーしなければならない ①「 入退会管理 」の機能の話をしましょう。

入退会管理の基本的な機能は、「 入会 」「 休会 」「 退会 」などの申出があったときのステータス管理ですね。

しかし これが簡単なようでいて実は非常に複雑です。

なぜなら、会員は今すぐ 入会したり 退会したり することはなく、必ず「いついつから」という予定で言ってくるからです。

逆に 予定で言ってもらわないと塾の方も困るのですが・・・。

なので、その日までは正会員だったのがその日を境に突然退会済みになったりする必要があります。

しかし 退会済みであっても、帳票は出したり、請求を出したりしなければなりませんので、完全にシステムから見えなくなっていいわけではありません。

そのあたりの制御は 業務の内容をよくお聞きして、ステータスの種類や個数、それぞれの状態によって出来ること出来ないことの整理をしないといけませんね。

そのあたりのヒアリングがやはり難しいところで、お客様はご自身でも各状態を細かく分析して 理解しているわけではありませんからね。

我々は アクティビティチャートとか、ユースケース図など を使って漏れの無いようにヒアリングをしていきますが、開発の最終段階で 漏れていたことに気付くことはよくあることです。

人間は具体性のないところでは真剣に考えられないというのは仕方の無いところだと思います。

それは、お客様の方もそうですし、我々開発者の側もそうです。

システムがある程度完成に近づいて、その画面を使っていよいよ業務を回す方法を具体的に考えたときに「あれ？こういうことができないじゃないか」と気付くことがあります。

弊社は もうこの業界で25年やってきていますので、それを 回避する方法はもちろん考えてあるのですが、テーマがブレてしまうので今回は辞めておきましょう。今回は契約などの話でなく、あくまで学習塾の業務システムの話をしましょう。

ということで、ステータスを自動的に変更するバッチプログラムというのを説明しましょうか。

通常、ユーザーが見ている、いわゆる「システム」というのは画面を持っているものがほとんどですね。

画面のことをユーザーインターフェースと呼んだりしますが、つまり画面がユーザーの思考とプログラムの繋ぎ役になっているということです。

しかし、システムには そういった画面を持たない「バッチプログラム」というのも重要で、特に入退会管理などでは必ずと言っていいほど存在します。

バッチプログラムは「ユーザーが何かを入力する」とか「ボタンを押す」とか「画面をスクロールする」とかの操作をすることなく、時間が来たら自動的に実行されます。

そういうことができないと、日付が変わったら「正会員」が「退会済み会員」になったり、「入会待ち会員」が「正会員」になったりできませんね。

毎日 オペレータの方が 深夜0時に操作することはできませんので。

バッチプログラムは いろいろな用途で使われますが、画面を持たないだけに 長い時間がかかるような処理も実行されます。

そうなるとサーバーに過負荷がかかったり、あるいは複数バッチが連携して動作する場合には 前のバッチが終わっておらずデータに不整合が起きる などの問題が生じたりします。

そのようなことの無いよう、エンジニアがしっかり設計を行う必要がありますね。
メモリ や CPU などの 負荷状況のモニタリング も欠かせません。

さて、バッチプログラムの話はこれくらいにして、入退会管理の話に戻って よりマニアックな話をしましょう。

たとえば今、Aさん という 正会員 がいたとします。

この方、今は普通に授業を受けているのですが、さて、2021年の1月にはこの人は当塾に在籍していたのか？
これをシステムで知るのはなかなか難しいところがあります。

それはまぁ 入会・休会・退会の記録を追っていけばなんとか分かるとして、では2021年の1月にこの塾には 何人の生徒がいたのか？ その中にAさんは含まれているのか？ となると相当難しいです。

難しさがわかりますかね？

そうですね。
一番単純な方法は、毎日深夜にバッチプログラムを走らせて、今日時点で在籍している全生徒のデータを保持しておくということですが、それはデータが膨大になりすぎてあまりいい方法ではありません。

またデータには「入力忘れ」「入力遅れ」というのがあって、必ずしも今在籍している生徒数が、正しい値ではないかも知れません。

まぁ 私が 25年以上開発 をしてきて、現時点での 最適解 としては、

入会、退会、休会の処理データをデータベースに溜めておくとともに、月の初めなどに管理者がオペレーター全員にデータの入力漏れがないことを確認した上で、締め処理を実行して前月の会員情報を確定させるのがよいと思います。

そうすれば、来月移行の「入会予定」の人は除外され「退会予定」の人は含めることができ、前月に在籍していた正しい会員の情報が保持されます。

いい質問ですね。
集計バッチは基本的には自動で行われるべきですが、この処理は入力漏れがないことをオペレーター全員に確認してから実行する必要があるので手動で実行するのがよいと思います。

締め処理は、責任者が手動で行い、もし万一締めを解除しなければならないときにも、その責任者が締めを解除できるように設計しておくべきでしょうね。