思想は悪くない。
Quest、Guild、Chat、Community、Growth。
言葉だけを並べると、かなり前向きに見えるでしょうか。仕事を少しゲームのように扱い、メンバーの動きが見え、経験値がたまり、次の挑戦につながっていく。机上ではきれいに回りそうでした。
ただ、実際に話していたのはもっと地味なことです。
メンバーは日常的にギルドシステムを触っているのか。
クエスト登録で迷っていないか。
カテゴリが増えたとき、あとから整理不能にならないか。
見える化が、いつの間にか監視のように受け取られないか。
このあたりで、私は少し引っかかりました。
制度は、つくった瞬間よりも、使われなくなった瞬間に本性が出ます。
検討会では、現状のギルドシステムについて、メンバーの関与がまだ限定的であり、日常的なエンゲージメントを高める必要があると整理されていました。
ここに、机上の設計だけでは見えない現実があります。
どれだけ設計思想がよくまとまっていても、それが日々の業務の中で開かれなければ、その仕組みは存在しないのとほとんど同じです。誰かがログインし、クエストを見て、登録し、進捗を残す。その小さな接触が続かない限り、制度はただの説明資料になってしまいます。
ギルドシステムが最初から「いい仕組みだから自然に使われる」と考えられていなかった点は、とても健全だったと思います。
使いたくなる理由を、運用しながら探していた。ここに、現場で制度を育てる手触りがあります。
朝の数分で触れて、迷わず入力でき、自分の仕事とつながっている感覚があるか。
ここに届かない仕組みは、静かに使われなくなり、その役目を終えてしまいます。
価値は、思想の大きさだけで決まるものではありません。
同じ検討会では、クエストカテゴリのデータ管理や、ユーザーが迷わず使えるインターフェースの必要性が強く話されていました。
クエストを登録し、分類を選び、進捗を残す。終わったあとにログを見る。
この一つひとつが少しずつ面倒だと、人はすぐに離れていきます。
思想に反対しているわけではありません。ただ、入力欄の前で止まる。どのカテゴリか分からず手が止まる。あとでやろうと思って、そのまま忘れる。
仕事の中で使う仕組みにおいて、UXは飾りではなく、制度が日常に入っていくための本質的な条件です。
人は正しいものを使う前に、使えるものを使う。
もっと言えば、使い方を考えなくて済むものを使う。
ギルドシステムを回して見えてきたのは、この当たり前の事実でした。
文化をつくる前に、まず止まらずに使えること。盛り上げる前に、詰まらないこと。
そこには、思想以前の実装論点があります。
ギルドシステムでは、MMORPGのようなゲーミフィケーションも検討されていました。
経験値、ゴールド、日課タスク、ワールドチャット、活動状況の可視化。仕事を少しだけ「続けたくなるもの」に変える工夫です。
私はこの方向性自体はかなり面白いと思いますが、少し怖さもあります。
ゲーミフィケーションの本質は、人を前に進めること。しかし、仕組みを強く設計しすぎると、理解が追いついていない人にまで参加を迫る圧力が生まれます。その結果、前に進む人を増やすはずの仕組みが、参加できない人を置き去りにする構造になってしまうかもしれません。
検討会でも、過度なプレッシャーやバーンアウトへの懸念が出ていました。ゲームの強制参加が逆効果になる事例を踏まえ、自然な参加を促す必要がありますが、ここは慎重に判断しなくてはなりません。
可視化は支援にもなり、監視にもなります。ランキングは熱量を生むことがあります。疲れを増やすこともあります。
ギルドシステムに必要だったのは、ゲームらしさを足すことだけではありませんでした。参加したくなる余白を残すこと。やらされている感じが出た瞬間に、仕組みの温度は下がります。
クエストを並べれば、仕事は見えるようになります。ただし、見えることと、業務が前に進むことは別です。
検討会では、クエスト管理のアウトプットをギルドのデータベースに自動統合すること、AI統合やGoogleカレンダー連携によって入力負荷を減らすことが話されていました。
ここに、ギルドシステムの本質的な論点があります。
クエストが増え、 誰かが受け、 進捗が動き、 完了する。
ログが残り、 次の判断に使われる。
この一連の流れがつながってはじめて、クエストは「仕事を進める仕組み」になります。
逆に、この流れが途切れた瞬間、クエストはただのタスク一覧になります。
終わった仕事が次に活きない。何を学んだのか残らない。似たような依頼が来ても、またゼロから考える。
それでは、アウトカムには届きません。
アウトカムは、クエストを登録できたことではありません。フォームが整ったことでも、一覧がきれいになったことでもありません。アウトカムとは、仕事の進め方そのものが変わった状態です。
依頼の出し方が変わり、受ける人の判断が速くなる。
過去のログが次の実行に使われ、同種の仕事を前より迷わず進められる。
そういう状態が現場に生まれて、初めてギルドシステムは「回っている」と言えるのだと思います。
ギルドシステムの世界観は豊かです。
Guild、Quest、Chat、Community、Growth。広げようと思えば、いくらでも広げられます。
ただ、運用しながら見えてきたのは、最終形を描くことよりも、今のチームで回る最小構成を持つことのほうが先だという現実でした。
1月26日の場でも、現行ツールは最終解ではなくプロトタイプであり、幅広い可能性を模索する姿勢が必要だと確認されています。新しいアイデアをすばやく試すには、開発プロセスの標準化と、本格開発へ切り替えるタイミングの見極めも必要だと話されていました。
完璧に作ってから運用する。
この考え方は、たぶん現場では重すぎます。
粗くても、まず使う。使って、詰まる。詰まった場所を見て、直す。また使う。
その繰り返しの中でしか、制度は現場に馴染みません。地図を描き切ってから歩くのではなく、歩きながら地図の間違いに気づく感覚に近いです。
ギルドシステムを回すと、ついシステム改善の話に寄りがちです。
けれど、実際に重くなるのは運営体制です。
検討会でも、部門別クエストを本格実施する前に、現行のギルド運営が本当に機能しているかを評価し、改善点を特定する必要があるとされていました。
クエストが増えたとき、今のチームで負荷に耐えられるのか。アウトカムカタログが拡大したとき、既存クライアントへの優先度が下がらないか。クライアント側の自律的な運用まで見据える必要があるのではないか。
ここは、かなり現実的な論点です。
仕組みがうまくいくと、仕事は減るどころか増えることがあります。
見えるようになるから、頼まれる。
回るようになるから、期待される。
期待されるほど、支える人に負荷が掛かる。
ギルドシステムの次の論点は、機能追加だけではなく、その成功を誰が支え、どこまでをAITが担い、どこからを現場が自律的に回すのか。
ここを曖昧にしたまま広げると、良い仕組みほど運営側を削ってしまいます。
最後に残る問いは、かなりシンプルです。
ギルドシステムは制度で終わるのか。文化になるのか。
関与が限定的なら文化にはなりませんし、UXが悪ければ続きません。
ゲーム性が強すぎれば、疲れます。
ログが次に活きなければ、ただの記録で止まります。
反対に、入力負荷が低く、日常の仕事に入り込み、自然に参加できて、残ったデータが次の判断を助けるなら、少しずつ文化に近づいていきます。
導入できたからでもなく、初回に盛り上がったからでもありません。使い続けられるか。制度と文化の境目は、たぶんそこにあります。
ギルドシステムを回して見えてきたことを一言で置くならば、
良い思想だけでは回らず、思想がなければ、改善の方向も定まらず。
AITらしさは完成した制度を持ち込むことではなく、運用しながら詰まりを見つけ、UXを直し、負荷とのバランスを取り、プロトタイプとして育て続けるところにあります。
面倒で、時間もかかり、たぶん何度も直します。
それでも、現場の判断が少し速くなる。誰かの仕事が少し見えやすくなる。終わったクエストのログが、次の一手に使われる。
その変化が残り始めたとき、ギルドシステムはただの仕組みではなくなります。
仕事の進め方そのものを、現場から少しずつ書き換えるものになるはずです。