1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

後輩に向けて作ったサービスにQiitaユーザーが流入した話

1
Last updated at Posted at 2026-05-17

「後輩に向けて作ったサービスに実際にQiitaユーザーが流入した話」

スクリーンショット 2026-05-17 21.19.18.png

開発中のサービスはこちら

現在開発中ですが、実際にこちらから利用できます!!
https://tatsuyaariyama.github.io/java-loop-practice/


前回、社内のJava研修カリキュラムに感じた違和感から、
初心者向けJava学習サイトを作り始めたという記事を公開しました。

正直、最初は軽い記事ネタくらいの感覚で、

「まあ、数人に見られて終わりかな」

くらいに思っていました。


kijiyou.png

ですが公開後、
Trace Room の動作確認をするために Firebase Authentication を確認したところ、社内の後輩以外にも6名の新規ユーザーがログインしてくださっていました。

これ、個人的にはかなり衝撃でした。


「記事を書く」と「人が動く」は別物だと思っていた

今まで、

  • 記事を書く
  • 開発する
  • 公開する

というのは、どちらかというと別々のものとして考えていました。

でも今回、

Qiita記事
↓
サービスへアクセス
↓
Firebase Authentication にユーザーが記録される

という流れが、実際に発生した。

しかも、自分と直接繋がりのない方々です。

これはかなり大きい経験でした。


Firebase Authentication を見ていて気づいたこと

今回、Trace Room の改善のために Firebase Authentication を確認していたのですが、

「あれ、ユーザー増えてる」

となった。

この瞬間、

「記事って、本当にサービス流入になるんだ」

を実感しました。

今までは、

  • PV
  • LGTM
  • フォロワー

みたいな数字ばかり意識していました。

でも実際に重要なのって、

“人が行動したか”

なんだなと感じました。


現在の構成

現在の構成はかなりシンプルです。

  • React
  • Firebase Authentication
  • Firestore
  • GitHub Pages

を使用しています。

Firebase を使うことで、

  • ログイン管理
  • Room Chat
  • リアルタイム同期
  • Trace Room

などをかなり高速に試せる。

個人開発だと、

「まず動かす」

までの速度はかなり重要だと感じています。


Trace Room のリアルタイム同期がかなり面白い

現在、Trace Room では全体チャットを導入しています。

Firebase Firestore の onSnapshot を使用して、

投稿
↓
リアルタイム反映

を行っています。

この「今誰かが触っている」が見える感覚、かなり面白い。


現在実装している機能

  • 全体チャット形式
  • リアルタイム同期
  • アイコン表示
  • ユーザーネーム表示
  • 自動スクロール
  • 自分の投稿のみ削除可能
  • Tracea(固定AIメンター)

など。

特に、

「自分の投稿だけ削除できる」

は最低限必要だと感じました。

リアルタイム系って、

「作る」

より、

「どう運用するか」

の方が難しい。


「初心者向けサービス」を作る難しさ

今回かなり感じたのがこれ。

初心者向けサービスって、

問題を増やせば良い

わけではない。

実際には、

「どこで止まるか」

の設計がかなり重要。

例えば、

sum += i;

を見て、

「+=って何?」

で止まる。

でも多くの学習サイトって、

「知ってる前提」

で進む。

だから今は、

  • 前提知識の可視化
  • 実行トレース再生
  • Tracea の補足
  • Room Chat

などを組み合わせて、

「別タブを何枚も開かなくても理解できる」

方向を目指しています。


AIは強力。でも「生成だけ」で終わると危ない

今回の開発では、かなりAIも活用しています。

AIは間違いなく強力です。

  • UI提案
  • コンポーネント分離
  • Firestore構成
  • 状態管理

など、生産性はかなり上がる。

でも最近かなり思うのが、

「生成されたコードを貼るだけ」

では、自分の技術力は積み上がらないということ。

例えば、

  • なぜこの構成なのか
  • なぜ onSnapshot を使うのか
  • なぜこの設計にしたのか
  • Firestoreルールは安全なのか

を説明できないと、
結局あとで詰まる。

だから最近は、AIに生成させた後に、

  • この設計のトレードオフは?
  • 他のアプローチは?
  • この実装の危険ポイントは?

を聞くようにしています。


作りながら発信することの強さ

今回かなり感じたのが、

「完成してから公開する」

より、

“作りながら発信する”

方が強いということ。

特に個人開発って、

  • 作る
  • 発信する
  • 改善する
  • ユーザーを見る

を高速で回すゲームなんだなと感じています。


最後に

正直、このサービス自体が今後どうなるかはまだ分かりません。

でも、

「発信 → 流入 → 改善」

という流れを、小規模でも実際に体験できたのはかなり大きい。

これは今後別サービスを作る時にも、確実に活きる経験だと思っています。

まだまだ開発途中ですが、
引き続き改善していきます。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?