学校の管理システムを新しい視点からリプレースするソフトウェア開発中

福田です。私が作っているものを今日は「個人開発者 Advent Calendar」の8日目としてお送りします。なお最初に言っておきますがゴミ記事です。あしからず。

                       

開発画面

機能について

今回作っているのは学校のシステムですが、これはオールインワンかつAPIが存在する新しいソリューションです。
今搭載しているのは

  • 給食・学費・校内の自販機をまとめた決済システム
  • 出席管理
  • 成績のリアルタイム確認
  • 図書館の本の貸し出し管理
  • 学校の空き教室の貸し出し管理
  • 伝言板機能(兼メッセージングプロトコル)

です。そのほか、

  • メール確認機能
  • 課題確認・提出機能

などもリリース後搭載していこうと考えています。
最初のやつは資金決済法でしたっけ、それに引っかかる気もするのでそこは後ほどどうにかしていきます。

最終的にはソフトウェアのサイズは多分初期データベース込みで30MB程度、推奨メモリはOSなども全てコミコミで3~6GB程度になる予定でしょうか。まああまり貧相なシステムで動かすことは業務システムですし考えていません。

システム環境

システムは主にPHP+MySQL(PostgreSQLなども使えるようにする予定。後述)で動かしていますが、データベースの管理を容易にするため、主キー(UNIQUE制約付き)とJSONで管理しています。主キーを検索に使い、それで見つけたJSONで情報を読み出す仕組みです。JSONにしたのは、階層構造をより深くし、プログラム上で扱いやすくするための一種のハックです。

また、アプリケーションとデータベースを扱うものを分け、データベースは複数の種類から選択できる仕組みにしています。つまりは、同じ関数名、同じ意味を持つ引数を用意し、それを初期読み込み時に定数で振り分けるということです。そうすることで、様々なユーザーが利用しやすくなるからです。
さらに、アプリケーションと表示も分けています。アプリケーションからはデータベースをラップした関数を読み、データを取得しますが、そのアプリケーションも関数化して呼び出せるようになっています。こうしたのは、APIアクセスとHTML、すなわちブラウザアクセスを複数作らずシンプルにまとめられるようにするため&バックエンド(DBアクセスなどの処理)とフロントエンド(表示)で容易にサーバーを分けられるようにするためです。ここでMVCじゃんと思った方もいらっしゃると存じますが、アプリケーションでModelとControllerをごっちゃにしていたり、Modelがデータベースラッパとアプリケーションで重複しているので、MVCには該当しないです。MVCがいつも正義ではない!!!ここは俺様ワールドだ!!!

アプリケーションや表示は全てモジュールという単位で動いており、容易に取り外しが可能な仕組みとなっています(フロントエンドが取り外されれば当然アクセスできませんし、バックエンドだけ外したとしてもディスパッチャーがそれを認識し、全アプリーション共通のエラー構文を返してフロントエンドがそれを認識し処理するためです。

決済端末や伝言板閲覧端末はRaspberry Pi最新モデル+17インチ程度のディスプレイ+キーボードを活用し、一台1~5万円以下に抑えるつもりです。また、学生証兼決済カードにはNFCなどを利用し、決済ごとに決済用のIDを変更する仕組みとしています。

今後の展開

今後設置するエンドポイントは、まずブラウザアクセス用とAPI用エンドポイント。さらにあるのが、他校・他社連携用エンドポイントです。これについてはセキュリティの問題もあるので非常に難しいところですが、実際できたらいいなと考えています。例えば、合格発表を各学校に自動的にプッシュしたり、受験料をそこから引き落としたり、卒業した生徒の次に入学する上級学校にデータを渡す際などに楽できる点などがメリットに挙げられます。
さらに、例えばJRなどである遠距離利用の際の学生割引は現在、学校に申請書を出し、認可後にもらえる共通フォームの割引証をみどりの窓口で出さないと適用できませんが、これの申請・認可・さらに割引証確認を全部デジタル化し、ペーパーレスなどに貢献することやいちいち取りに行く手間などを削減できることなどの実用的メリットもあります。加えて、デジタル化できるため指定席券売機などでの学生割引適用切符の販売もできるようになります。ビジネスとしては僕はここら辺の機能に旨味を感じています。これについては次の項で紹介します。

プライス

ここに書いたものは売れないとは思いますが万が一もしかしたらで商用化も検討にいれていたりします。

PHPは容易にリバースエンジニアリングができるので、このパッケージ単体での儲けはあまり優先せず、先ほどいった他校・他社連携用エンドポイントの仲介をこちら側のサーバーで行ったり、クラウドサービスといったパッケージで提供することから収益を得るモデルを考えています。
さらに、アップデートなどもあらかじめ登録したエンドポイント宛にプッシュ方式で行うことにし(リモートコンソールからアップデートする)、さらにそのアップデートデータを当該バージョン、一回限り有効な公開鍵で暗号化し(=アップデートごとに公開鍵が変わる)、不正コピーがあった場合でも最低1売上は保証できるような仕組みにする予定です。

まあ、ざっくりクラウドだと1万円~∞円/月、他校・他社連携機能が200円~1000円/一回の送受信とかですかね。連携機能はひと月当たりの送受信件数に応じて割引が効かせるので幅があるという感じです。パッケージ単体はもしかしたらオープンソースにしちゃう可能性も無きにしも非ず。

競合対策

競合対策は特にないどころか、相互移行(受け入れ、転出)機能も要求に応じてこちら側から提供することで顧客満足度を上げる作戦でいます。強いて言えば機能をバンバン追加していく感じでしょう。

おしまいに

デマ判定ソフト作ってたら先越されてスラドに載ってしまい頓挫。まあこれも先越されるかパクられるかで頓挫する悪寒が。毎度毎度やろうやろう…あっ先越されてスラドに載ってやがる、ちくしょうめ!!!ってなるのでどうにかしたいです。

まあ、多分僕には落札などに参入する勇気はないので買収するかパクるかなりしてみてください。はい。一応僕は作り上げますが所詮おもちゃですから。
また、このシステムはミシガン州で実際運用されている「MISTAR」というものを参考にして計画しました。留学最高。開発に携わりたい方がいらっしゃいましたらお問い合わせフォームよりお問い合わせください。お待ちしております。

この記事は最終編集から一年以上経過しております。この記事に書かれた内容をご利用・実践される際は十分ご注意ください。

Sponsored link

コメントは受け付けていません。