こんにちは、リョウです。
最近、会員ページを改善していて、思いがけない発見がありました。
最初のきっかけは、本当に小さなことでした。
「会員ページのラベル名を変えたい。」
ただ、それを調べていくうちに、
「これって、プラグインに合わせて運営しているのではなく、自分のスクールに合わせてWordPressを育てたほうがいいんじゃないか？」
という考えに変わっていったんです。
今回は、その試行錯誤を記録として残しておこうと思います。
同じようにWordPressでオンラインスクールを運営している方の参考になれば嬉しいです。
- 1 最初の悩みは「電話番号」と「住所」
- 2 でも、更新のたびに元へ戻る
- 3 本当の問題は「ラベル」ではなかった
- 4 WordPressにはuser_metaという便利な仕組みがある
- 5 「予約システム」と「会員管理」は別物だった
- 6 僕が目指したい構成
- 7 PayPalも完全自動にしようと思った
- 8 メールアドレス問題
- 9 チケット繰越もある
- 10 だから完全自動をやめた
- 11 「半自動」が一番現実的だった
- 12 プラン管理もシステム化できる
- 13 少しずつ、自分だけの仕組みへ
- 14 WordPressの「ユーザー一覧」が、そのまま会員管理画面になる
- 15 「表示オプション」を見た瞬間に思ったこと
- 16 でも、残チケットや有効期限はどうなる？
- 17 実はここが一番大切
- 18 もしuser_metaなら最高
- 19 プラグインを改造しない
- 20 小さな改善が、大きな資産になる
- 21 まとめ
最初の悩みは「電話番号」と「住所」
RYO英会話ジムでは、予約システムとしてOLB予約システムを利用しています。
会員ページには標準で
- 電話番号
- 住所
という項目があります。
しかし、英会話スクールとして本当に表示したいのは、
- 利用プラン
- 現在のレベル
でした。
そこで最初は、Loco Translateを使って
電話番号
↓
利用プラン
住所
↓
現在のレベル
と表示だけ変更していました。
最初はこれで十分だと思っていたんです。
でも、更新のたびに元へ戻る
問題はここからでした。
プラグインをアップデートすると、
翻訳ファイルがリセットされることがあります。
そのたびに、
またLoco Translateを開いて、
同じ翻訳をやり直す。
正直、少し面倒でした。
そこで、
「functions.phpで変更できないかな？」
と思って調べ始めました。
本当の問題は「ラベル」ではなかった
いろいろ調べているうちに気づいたことがあります。
実は、
ラベル名を変えること自体は本質ではありませんでした。
本当の問題は、
プラグインが用意した項目を、本来とは違う用途で使っていること。
例えば、
phone
を
「利用プラン」
として使い、
address
を
「現在のレベル」
として使っています。
もちろん、最初はこれでも運用できます。
でも、
将来的に
- ステージ
- 学習時間
- チケット残数
- 学習目標
など増えていくことを考えると、
どこかで必ず限界が来ます。
その瞬間、
「これは設計の問題なんだ。」
と気づきました。
WordPressにはuser_metaという便利な仕組みがある
そこで教えてもらったのが、
user_meta
というWordPress標準機能でした。
これは、
ユーザーごとに自由な情報を保存できる仕組みです。
例えば、
plan_name
↓
無限プラン
current_level
↓
Stage6
lesson_ticket
↓
18
study_hours
↓
124時間
など、
好きな情報を自由に追加できます。
しかも、
これはWordPress標準機能なので、
プラグイン更新の影響をほとんど受けません。
ここで一気に視界が開けました。
「予約システム」と「会員管理」は別物だった
user_metaを知ってから、もう一つ大きな気づきがありました。
それは、
予約システムと会員管理システムは役割が違う
ということです。
最初の頃は、
「OLBだけですべて管理できないかな？」
と考えていました。
でも実際には、
OLBは名前の通り、
「予約するためのシステム」
です。
一方、僕が管理したい情報は、
- 利用プラン
- 現在のレベル
- ステージ
- 累計アウトプット時間
- チケット残数
- 学習目標
- AIによる学習分析
など。
これは予約とはほとんど関係ありません。
つまり、
予約システムに無理やり管理させようとするのではなく、
役割を分けた方がシンプルなんです。
僕が目指したい構成
今考えている理想形はこんなイメージです。
OLB予約システム
担当するもの
- レッスン予約
- キャンセル
- スケジュール管理
WordPress
担当するもの
- 会員情報
- 利用プラン
- 学習ステージ
- 学習履歴
- AI分析
- ダッシュボード
つまり、
予約はOLB。
会員管理はWordPress。
この役割分担が一番きれいだと感じています。
PayPalも完全自動にしようと思った
ここまで考えると、
次に思いついたのが
PayPalとの連携です。
理想は、
PayPal決済
↓
チケット自動追加
でした。
かなり便利そうですよね。
でも、考え始めると問題がたくさん出てきました。
メールアドレス問題
例えば、
PayPalで支払っているメールアドレスと、
会員ページに登録しているメールアドレス。
これが一致するとは限りません。
例えば、
- 家族のPayPalを使う
- 会社の経費で支払う
- 昔登録したメールアドレスを使っている
こういうケースは普通にあります。
もし、
PayPalメールだけで判断すると、
違う生徒へチケットが追加される可能性があります。
これは絶対に避けたい事故です。
チケット繰越もある
さらに、
RYO英会話ジムでは、
残チケットの繰越もあります。
例えば、
今月
残り8枚。
翌月の決済が完了。
その場合、
8枚
↓
＋20枚
↓
28枚
になるのか、
それとも、
毎月リセットなのか。
これもプランによって違います。
つまり、
単純に
「決済が終わったから20枚追加」
という処理では済まないんです。
だから完全自動をやめた
そこで、
考え方を変えました。
半自動
です。
流れはこうです。
PayPal決済
↓
Gmailへ通知
↓
WordPress管理画面
↓
対象生徒を選択
↓
承認
↓
チケット追加
たったこれだけ。
でも、
人間が最後に確認するだけで、
事故はほぼ防げます。
しかも、
僕がやる作業は
承認ボタンを押すだけ。
完全手動より圧倒的に楽です。
「半自動」が一番現実的だった
実際に考えてみると、
英会話スクールは
例外対応がとても多いです。
例えば、
- 特別にチケット追加
- キャンペーン
- 有効期限延長
- 無料体験特典
- 法人契約
- 休会対応
など。
完全自動は一見便利ですが、
こういう例外処理が苦手です。
だからこそ、
最後だけ人間が確認する
「半自動」
という仕組みが、
一番現実的なんじゃないかと考えるようになりました。
プラン管理もシステム化できる
さらに考えているのが、
プランマスターです。
例えば、
| プラン | チケット | 有効期限 |
|---|---|---|
| 月8回 | 8枚 | 30日 |
| 月12回 | 12枚 | 30日 |
| 無限プラン | 20枚 | 30日 |
| 年間プラン | 240枚 | 365日 |
という一覧を作っておけば、
承認するときは
「この生徒は月8回プラン」
と選ぶだけ。
システム側が
自動で
- チケット追加
- 有効期限更新
まで処理してくれます。
毎回計算する必要もありません。
少しずつ、自分だけの仕組みへ
今回一番大きかったのは、
「どう実装するか」
よりも、
「どう設計するか」
を考えるようになったことです。
最初は、
ラベル名を変更したいだけでした。
でもそこから、
WordPress全体の設計まで考えるようになりました。
この積み重ねが、
数年後には大きな差になる気がしています。
WordPressの「ユーザー一覧」が、そのまま会員管理画面になる
今回、もう一つ面白い発見がありました。
最初は、
「新しく管理画面を作らないといけないかな」
と思っていたんです。
でも調べてみると、
WordPressには最初から優秀な管理画面がありました。
それが、
「ユーザー一覧」
です。
普段は、
- ユーザー名
- メールアドレス
- 権限
くらいしか表示されていません。
でも、
ここに独自の項目を追加できます。
例えば、
| 生徒 | 利用プラン | 残チケット | 有効期限 | ステージ |
|---|
こんな一覧にすることも可能です。
つまり、
WordPress標準の画面を、
そのまま
生徒管理システム
へ進化させられるんです。
「表示オプション」を見た瞬間に思ったこと
実際にユーザー一覧を開いて、
右上にある
「表示オプション」
を見た瞬間、
「ここに追加できるんじゃないか？」
と思いました。
もちろん、
実際には少しプログラムを書く必要があります。
でも、
WordPressは標準で
管理画面を拡張できる仕組みが用意されています。
つまり、
わざわざ新しい管理ページを作らなくても、
既存の管理画面を自分好みに育てられるんです。
この考え方はかなり好きでした。
でも、残チケットや有効期限はどうなる？
ここで一つ疑問が出てきました。
今表示されている
- 残チケット
- 有効期限
は、
OLB予約システムをインストールしたら表示されるようになった項目です。
つまり、
これは
OLBが管理しているデータ
の可能性があります。
ということは、
まず調べるべきなのは、
OLBがどこにデータを保存しているのか。
ということです。
実はここが一番大切
例えば、
WordPressには
user_meta
という保存場所があります。
一方、
プラグイン独自の
データベーステーブルを使っている可能性もあります。
つまり、
いきなりコードを書くのではなく、
まずは
データがどこに保存されているかを調べる。
これが最優先です。
システムを作るときって、
つい実装から始めたくなるんですが、
実は
データ構造を理解すること
の方が何倍も重要なんですよね。
もしuser_metaなら最高
例えば、
チケットが
user_meta
に保存されているなら、
かなり話は簡単になります。
残チケットを取得して、
追加して、
保存。
これだけです。
プラグインを直接触る必要もありません。
逆に、
独自テーブルだった場合でも、
保存場所さえ分かれば、
更新することはできます。
つまり、
「どこに保存されているか」
さえ分かれば、
あとはプログラムで対応できます。
プラグインを改造しない
今回、
自分の中で決めたことがあります。
それは、
できるだけプラグイン本体は触らない。
ということです。
昔は、
プラグインのコードを書き換えることも考えていました。
でも、
アップデートした瞬間、
全部消えてしまいます。
これでは保守が大変です。
だから今は、
プラグインはそのまま。
WordPress側で
必要な機能だけ追加する。
この考え方の方が、
長く運営するなら絶対に楽です。
小さな改善が、大きな資産になる
今回、
たった一つの
「ラベル名を変えたい」
という話から始まりました。
でも、
気づけば、
- user_meta
- PayPal連携
- 半自動承認
- 会員管理画面
- プラン管理
- データ設計
まで考えるようになっていました。
システムって、
最初から完成形を作るものではありません。
小さな不便を一つずつ改善していくことで、
少しずつ育っていくものなんだと思います。
まとめ
今回の改善を通して、
僕が一番感じたことがあります。
それは、
「プラグインを使う」のではなく、「WordPressを育てる」という発想が大切だということです。
便利なプラグインはたくさんあります。
でも、
運営を続けていくと、
必ず
「自分のスクールだけの運用」
が出てきます。
そのときに、
プラグインへ無理やり合わせるのではなく、
WordPress標準機能を活かしながら、
自分に合った仕組みを作る。
その積み重ねが、
数年後には
誰にも真似できない運営ノウハウ
になるんじゃないかと思っています。
もしこの記事を読んで、
「WordPressってここまでできるんだ。」
と思っていただけたなら嬉しいです。
僕自身もまだ完成形ではありません。
これからも試行錯誤を重ねながら、
RYO英会話ジムだけの会員管理システムを少しずつ育てていこうと思います。
The Remote Digital Hubをもっと見る
購読すると最新の投稿がメールで送信されます。
コメントを残す