はじめに
はじめまして、学生エンジニアのshenzelです。最新の技術をどんどん取り入れてたくさんプロダクトを作るようなつよつよエンジニア……、ではない、非公開のプロダクトをいくつか作っている程度のよわよわエンジニアです。
さて、今回お話しするのは、そんなよわよわエンジニアがたった1週間で作ったプロダクトがバズった話です。
バズった理由は、「身近な困りごとを拾ったこと」にあると考えています。だからこそ、身近な困りごとを拾って、そこで得られた学びを書きたいと思います。
想定読者
- 初学者がどんな感じで開発してるか知りたい方
- 「モノづくりしたいな……」と思いながらできていない方
ちょっと宣伝
商品名は「ぜるかなボード」です。
Boothリンクを置いておくので、記事を読み終わった後にでも見てみてください。
「スキ!」を押していただけると大変喜びます。
課題の発見
1人の知り合いの無言勢がテキストチャットでローマ字を打っていたのがきっかけでした。
なんか、「読みづらいなあ」と。
会話ペースが遅くなるのは仕方ない。
でも、この「読みづらさ」は仕組み上本来あるはずのないもの、そう思いました。
「日本語を打てる文化がない」という気づき
ふと、ノート機能を思い出す。ノート機能とは、ユーザごとに存在するメモ欄です。
相手ユーザとの初めての出会いをメモしたり、どんな人かを一言で書いたり……、という感じに使います。
私はノート機能を愛用しています。1週間で数十、数百の人と会うと、一人一人のことをどうしても忘れてしまうから。その代わりに、どんな人かを思い出せるよう、丁寧に、読みやすく、出来事や印象に残ったことを意識して書いているつもりでした。
内容は丁寧に書いてある。どんな人か、簡単に想像できる。
ただ、読みづらい。内容というより、もっと根本的な部分で。
そう。ローマ字で書かれているのです。
日本語が使えなければ読みづらいのは当然のこと。
でも、VRChatに染まった自分はそれを『当たり前の不便』として受け入れてしまっていました。
下は日本語で書いたものです。見比べると、ローマ字の読みづらさがよく分かると思います。


課題の拡大 : 既存プロダクトとの差別化
仰々しく語りましたが、こんな根本的な課題に誰も気づいていないはずがありません。もちろん既存製品が存在します。
日本語キーボードの既存プロダクト
- テキストチャットを直接送信できる日本語キーボード
- アバター仕込み型の汎用日本語キーボード
- デスクトップ画面をオーバレイで表示するアプリケーションに付属する日本語キーボード
しかし、「VR中常に使える」「VRChatのどの場面にも使える」日本語キーボードはありません。SteamVRのオーバーレイで実装すれば、特定のアプリケーションに依存しないものを作れます。これがあれば、VRChatに限らない場面で使えるからこそ、最大級の汎用性を担保できると考えました。だからこそ、自身が作る価値があると思い、作ることを決意しました。
MVPを考える
MVP(Minimum Viable product)とは、ユーザーに必要最小限の価値を提供できるプロダクトのことです。
最初から思いつく機能すべて詰め込めばいいじゃないかと思うかもしれません。しかし、いきなり機能てんこ盛りのプロダクトを作ると、時間はかかるし、いらない機能を付けてしまって使いづらいし、いいことはありません。
だからこそ、最初は規模を小さいままでも高い価値を提供できるプロダクトを考える必要があります。
プロダクトの最大価値
MVPとは、プロダクトが出せる最大級の価値から引き算して考えられます。そのため、まずはこのプロダクトが「本気」を出したときに、どんな価値を提供できるかを考えます。
開発するうちに「あれもできる」「これもできる」と増えていくものですが、開発初めに考えていたことを記します。
機能要件
-
汎用的な場面で日本語入力ができる
- 機能
- 物理キーボードと同等の機能
- 日本語入力
- 漢字変換
- 予測変換
- 物理キーボードと同等の機能
- 場面
- VRChatのテキスト入力一覧
- ワールド検索
- ステータスメッセージ変更
- テキストチャット
- VRChatのテキスト入力一覧
- 機能
- VRChat特化で入力が簡略化できる
- OSC経由でのテキストチャット直接送信機能
非機能要件
- 使いやすさ
- 必要な時にすぐ取り出せる
- 不必要な時にすぐ隠せる
- VR上で簡単に移動できる
- フローティング型
- 腕追従型
- シンプルさ
- 分かりやすい見た目
MVPを満たす設計
以上のうち、何を最初に実装するか決定します。ここでは、ユーザの需要や技術的な難易度をもとに決定します。
MVPに入れるもの
- ひらがな・カタカナ入力
- シンプルで物理キーボードに近いUI
- フローティング型
- 表示・非表示、移動、サイズ変更
導入判断例: 表示・非表示、移動、サイズ変更
ユーザにとって最低限の使いやすさとは何か、と考えた結果、これらが必要だと考えました。
表示・非表示
キーボードは入力時にのみ使えればよいものです。常に表示されていては鬱陶しくて使いたくなくなってしまうはずです。
移動、サイズ変更
ユーザが使いやすい場所で、使いやすい大きさで打てる必要があります。大きさも位置もユーザが変更できない場合、立って動き回るVR上ではとても不便です。
MVPに入れないもの
- 漢字変換・予測変換
- VRChatテキスト入力欄への直接入力
- 腕追従型
導入しない判断例: 漢字変換・予測変換
2つポイントがあります。
- 実装コストが高い
- ひらがな・カタカナだけでも、ユーザに便利さが十分に伝わる
この2点から、実装は公開後でも問題ないと考えました。
結果として以下のキーボードができました。
とてもシンプルです。
使用風景
シンプルさを追求した意図
機能を付けようと思えれば、たくさんつけられます。
しかし、不必要な機能は視覚的な情報を増やし、ユーザの負担を増やします。
初心者から上級者まで誰でも使えることを想定しています。そのため、このプロダクトで「何が出来るか」を分かりやすくするためにもシンプルを基本とした設計にしています。
1週間で出すためにやったこと
AI駆動開発
AI駆動開発とは、「何をつくるべきか」を人間が担当し、「実装」はLLMが担当する開発手法です。
私の場合は、主要な実装はclaude CLIが担当し、バグ修正はgithub copilotでgithub上でissueを出して作成してもらいました。
高速化のコツとして、issueを複数出して並列に回す方法があります。LLMがissue Bを実装している間に自分がissue Aをレビューする、という形です。
このやり方によって1週間でMVPを出せました。しかし、速度を追求する実装には落とし穴がありました。
「すぐ作る」と「雑に作る」は違う
近年 Coding Agentというのはものすごい発展をしており、文章に書いていなくても必要な機能をつけてくれたり、保守性の高いコードを記述してくれます。そのため、文章が短く、雑に書いても良さそうなものを作ってくれます。
これは、AI駆動型の開発のボトルネックがAIの性能ではなくなりつつあるということです。(もちろん諸説ありますが。)
では、ボトルネックはどこに移ったか、というと、人間からAIの伝達部分、つまりコミュニケーションになります。
AIは受け取った指示を自身の解釈で実装します。その解釈がずれていれば、ずれたまま最適な実装をしてしまいます。
私も、公開後のメジャーアップデートで痛感しました。
失敗:漢字対応
漢字実装の手順は以下の通りでした。
- 技術調査
- 「今のプログラムに漢字変換を追加したい。選択肢を出して」みたいに聞く→ライセンス・精度の面で使えるものを選択
- 実装を指示
一見良さそうに見えますが、これでは上手くいきませんでした。
なぜなら、
- UI・UXをどうするのか
- 予測変換を使うのか
- 内部的にどんなデータを保持するのか
など、すべてをCoding Agentに丸投げしてしまうからです。
得られたものは、「なんか違う」設計ばかり。
結局、細かいUI・UXの修正、内部的なリファクタリングに10程度のPRを出しました。
そのやりとりで多くの時間を使ってしまいました。
成功:OSC経由のテキストチャット送信
一方、OSC経由のテキストチャット送信では、設計駆動な開発を行いました。
具体的には、以下の通りです。
- 要件定義書の作成
- 技術調査
- 細かな仕様
- 定義書をもとに実装を指示
漢字対応との違いは、1.で明確な仕様書を作成するという点です。
- UI・UXを具体的に定義
- バックエンドの処理を具体的に定義
- アーキテクチャ設計
- クラス設計
これらをCoding Agentと対話し、曖昧な点を無くした状態で実装してもらいました。
曖昧な点をとにかくつぶすことに時間を費やし、定義書を作るのに、4時間ほどかかりましたが、実装後のバグ修正は1対話で終了しました。総合でかかった時間は圧倒的に少なくなりました。
公開とその反響
公開の告知ポストが2000RP、7500いいねと大きな反響をいただきました。DL数は公開2日ほどで2000を超えました。
裏話
この「ぜるかなボード」という名前、告知ポスト時点では決まってませんでした。
「VRで打てる日本語キーボード」という機能を打ち出した名前で出そうとしてました。バズった告知ポストに「ぜるかなボード」の名前がなかったので、初期は名前が全然広がらず、「あ~あの日本語キーボードね」といわれることが多く、しょんぼりしておりました。
公開後のXの静けさ
告知ポストでは、引用ポストで「神!」「待ってました!」と言われていましたが、いざ公開すると、まるで反響がなかったです。
いきなりですがみなさん、Xで「#ぜるかなボード」と検索してみてください。ほぼ自分のポストです(´・ω・`)
あって当たり前のものだから、使ってみたら特に語ることがなかったんだろうなと思います。
フィードバックへの対応
ありがたいことに、様々なフィードバックを頂きます。
特に多くのユーザが困っていそうな内容は積極的に修正するようにしています。
例えば、公開当初のフィードバックとして、「キーバインドを自由に設定させてほしい」というものがありました。
公開当初は割り当てのボタンは固定で変更できませんでした。これにより、他ソフトとキー割り当てが被ってしまう事態が発生してしまいました。これでは、一部のユーザが全く使えない状態になってしまいます。
これはまずい、と思い翌日にはキーバインドを変更できるようアップデートを行いました。
さいごに
身近な困りごとを解決することには強い力があります。
確かに、身近な困りごとに多くのユーザが付くかは分かりません。
もしかしたら、「たまたまバズったからそんなことが言えるんだろ」とポジショントークを疑う人がいるかもしれません。
それでも、身近な困りごとを解決する価値は揺るがないと考えています。
なぜなら、この目的で作ったプロダクトには、ユーザが誰もいない、ということは起こりえないからです。
「私が困っている」、「友達が困っている」など誰か1人でも困っている人がいればその人が最大のユーザになってくれます。(※「困っている人がいるだろう」と仮想のユーザを想像して作るのはダメです)
身近な困りごとを解決して、誰かに喜んでもらえる経験は、ユーザが一人でも付けば、大小はあれど再現性をもって体験できるはずです。
みなさんも、「作る→フィードバックを得る→改善する」のサイクルを通して、何か作ってみませんか?




