こんにちは！！miyoshiです。
モニター開発で「すごい！」「早く使ってみたい！」と言われた体験を通じて、駆け出しエンジニアとしての喜び、そしてアジャイル開発の本質に触れることができました。
この記事では、Rails × GitHubで行ったポートフォリオ開発の記録とともに、モニターさんからのフィードバックが新たなIssueを生み出す流れをご紹介します。
予約サイトのトップページ
https://gyazo.com/21ee4e650749e9b35b01a6cad2bc4638
🧑💻 背景：駆け出しエンジニアのポートフォリオ開発
「サロン向けの予約アプリ」を作っています。主な技術スタックは以下です
- フレームワーク：Ruby on Rails
- バージョン管理：Git / GitHub
- UI確認：ローカル環境 + モニター開発（実際のサロン経営者）
ISSUE7までの実装で、基本的な予約作成〜管理者側のダッシュボード表示までを完了し、ローカル環境上で確認できる状態となっていました。
🔍 モニターさんに実際に触れてもらった
予約アプリの画面をローカル環境で共有し、モニターさんに見てもらったときのやりとりが、印象的でした。
「すごい！めちゃくちゃいいね！」
「早く使ってみたい！」
この一言が、駆け出しエンジニアとして、初めて"誰かの困りごとをコードで解決した"実感につながりました。
💡 フィードバックから新しいIssueが生まれた
感動してもらったモニターさんから次の一言が、、、
「じゃあ、施術が完了したら、スタンプがたまっていくようにできる？」
あれ？？、、、これって、、、アジャイル開発ではないかな？？
- クライアントの生の声
- ユーザーの理想の体験
- 新たな課題発見
すぐにGitHub上でREADMEを更新し、次のIssueを作成。開発の方向性を柔軟に変える。これこそアジャイル型の開発の醍醐味だと感じました。
🔧 GitHub × README × Issueの管理
実際にやったこと
- モニターさんの声をそのままメモ
-
README.mdに「次の実装予定機能」として追記 -
Issueを立て、タスクに分解 - コミット＆Push
学びポイント
- READMEに「次やること」を明記すると、チーム開発にも展開しやすい
- ユーザーの声をIssueに変換する習慣が、エンジニアとしての成長に繋がる
🚀 開発のやりがいは「使ってもらえる」こと
これまでは自分の中でコードを書くことが中心でした。でも今回、リアルなユーザーの反応を聞くことで、
- コードが「機能」になる瞬間
- 機能が「感謝」につながる体験
- フィードバックが「次の改善」になる流れ
を一通り体験できました。
🔚 おわりに：駆け出しでも、喜ばれるものは作れる
完璧じゃなくてもいい。
ローカル環境でもいい。
まずは「使ってみたい」と言われるものを作ってみる。
その声こそ、次の改善を生むエネルギーになります。
この記事が、今ポートフォリオ開発をしている方や、ユーザーとのやりとりに不安を感じている駆け出しエンジニアさんの励みになれば嬉しいです。