アイデア選定からシニアフィードバックを経てMVP実装まで、プロジェクトの土台を築く過程で経験した試行錯誤と技術的挑戦の記録
入力したパスワードは秘密コメントの閲覧、修正、削除に使われます。
まだコメントがありません。
링크 정보를 불러오는 중...
グループプロジェクト3週目の週末が終わろうとしています。本来はプロジェクトがすべて終わった後に最後の振り返りを書くつもりでしたが、週ごとの振り返りを共有してくださる他のキャンパーの方々の記事から多くの助けを得たので、中間振り返りを残してみることにしました。
現在までプロジェクトは次のような流れで進んでいます。
初日は新しいチームメイトに会い、お互いに自己紹介をする時間を持ちました。リポジトリを作成し基本設定を行いましたが、日中は他のセッションがあったため、深い議論よりは軽い挨拶と方向性の共有にとどめ、翌日から本格的にテーマを決めることにしました。
各自が準備してきたアイデアを共有し、候補を絞り込みました。私は4つほどのアイデアを準備していましたが、そのほとんどが次のような理由で曖昧でした。
すでに優れたサービスが多すぎるため、プロジェクトのテーマを決めることがますます難しくなっていると感じました。
今回私がやりたかったのは、実際のユーザーがいる意味のあるサービスを作ることでもありますが、それよりももう少し「挑戦的な試み」ができるプロジェクトを経験することでした。単に実装して意味なく終わるプロジェクトは望んでおらず、その両方を満足させる方向を探したいと思っていました。
最初に持ってきたアイデアの中で、この条件を満たすものは1つほどでしたが、テーマと拡張性は良いものの、1ヶ月以上の時間を投資するには私たちのチームメンバーの力量に対して単純すぎるという悩みがありました。そんな中、休み時間に新しいアイデアが浮かび、チームメイトも肯定的に反応してくれました。
以前から私がよく使っていた2つのアプリを参考に、私たちの状況に合わせてキーワードと文脈を再構成したアイデアを作りました。これを基に、提供されたスプリント資料に合わせてアイデアを拡張・整理し、最終的なテーマを確定しました。
完全に新しいサービスとは言えませんが、チームメンバー各自の目標と方向性に合致する選択であり、結果的に全員が満足できるテーマとなりました。
링크 정보를 불러오는 중...
2日目と3日目にはコンベンションの整理に集中しました。以前のスプリントチームで使用した方式と、その時感じた長所・短所を基準に、私が準備してきたコンベンションのドラフトをチームメイトと共に修正・補完して確定しました。
これをWikiに整理しましたが、最初の週からWikiを中心にチームドキュメントを管理したことは本当に良い選択だったと感じています。プロジェクトの基本設定も終え、今回は Husky を導入してコンベンション検査とPR前のLintチェックを自動化しました。チーム全体のコード品質を維持する上で、かなり効果的な導入でした。
私たちが作成した企画書を基に、他のチームとデモおよびフィードバックの時間を持ちました。他のチームのキャンパーの方々が積極的にフィードバックをくださったおかげで、私たちが気づかなかったユーザーの視点や方向性を再点検することができました。
自分ではターゲット設定をうまくやったつもりでしたが、実際のユーザーの立場から見ると、ターゲットをもっと絞り込んで確実に拡張する余地も多いと感じました。この時間は個人的に非常に意味がありました。
良かった点
惜しかった点
2週目には私が作成したデザインを基にプロトタイプの実装に集中し、シニアフィードバックを控えてこれまでの計画を一つのドキュメントにまとめる作業を行いました。
デザインの過程で初めて Figma Make を使用してみましたが、クオリティが予想以上に高くて驚きました。以前のプロジェクトまでは画面一つひとつ直接デザインを実装していましたが、Makeを活用すると React と Tailwind ベースで構造化された結果物が得られました。
「これならフロントエンドエンジニアは必要ないのでは？」と一瞬思ったほどです。ただし、思い通りに実装されない部分は、まず Gemini と共にビジュアルガイドを作成し、Figma Make を通した後に私が再度修正する形で整理しました。
今回はプロトタイプ段階だったため、Cursor AI を活用して基本画面を素早く実装しました。もちろん、完成度の低いページは一つずつ手直しが必要でしたが、アイデアを素早く形にして確認できるという点で、非常に効率的な経験でした。
今週はチームメイトと初めてオフラインで集まりました。これまでオンラインでのチーム開発に慣れていたため、オフラインの必要性をそれほど感じていませんでしたが、オンラインなら5時間かかりそうな作業がオフラインでは2時間で終わりました。確実に集中度とスピードが違うことを体感しました。
特に、機能的要件とユーザーフローの整理に長けたチームメイトがおり、アイデアをより明確に構造化できたことも印象的でした。
週の終わりに受けたシニアフィードバックの核心は 「まだ全体の計画が曖昧だ」 ということでした。
私たちは十分に議論したつもりでしたが、チームメンバー各自が重要だと考えるポイント、実装してみたい方向、重要度が異なっていることが浮き彫りになりました。このまま進むと方向性が簡単にブレてしまいそうだという危機感も抱きました。
それまで私たちは、CSクイズの質を高めること、そしてユーザーがサービスを利用するために必要な基本ページ（メイン、クイズ、解説、マイページ、設定など）の実装に集中していました。CSクイズというドメインの特性上、問題の質がサービスの信頼性に直結すると考え、パーソナライズされた学習体験を提供するにはユーザー情報を扱うページも必須だと判断したからです。そのため、「この程度は先に作っておくべきだ」という基準で機能の優先順位を決めてきました。
しかし、シニアの方は私たちの企画書を見て、
「実装できるものばかりを選んで、少し楽な道を選びすぎているのではないか」 とフィードバックをくださいました。
これは単に基本機能を作るなという意味ではなく、今私たちが集中している要素だけでは既存のCSクイズサービスとの差別化が見えにくく、チームの力量に対して挑戦レベルが低く見える可能性があるという指摘でした。
実際、この部分は私自身もずっと悩んでいた点でした。今、実装が比較的容易な機能だけで埋めようとしていないか、この方式がチームメイトの力量を十分に活用する選択なのか、自問自答を繰り返していました。
この文脈で、シニアの方はプロジェクトに必須な機能でなくても、
私たちのチームが技術的に挑戦でき、同時にサービスをより魅力的にする 「ワオ・ポイント（Wow Point）」 は何かをまず考えてみるよう助言してくださいました。
時間が経つにつれ人は疲れるものなので、むしろ序盤に技術的に挑戦的な部分を先に実装し、他のチームにユーザーテストを受けながらアップグレードさせていく方が良いという言葉も印象的でした。マイページや設定のような機能は後からでも十分に作れるので、完成度よりも「挑戦」を優先する方向にチームの考えも少しずつ変わっていきました。
この過程で自然と出た問いが「技術的挑戦が重要か、サービスの目的が重要か」でしたが、結論はどちらかを選ぶのではなく、サービスに不可欠でありながら十分に技術的挑戦となる地点を見つけるべきだということでした。
個人的には、その地点の一つが キャラクターの活用 かもしれないとずっと考えていました。デザインとキャラクターは私にとって思い入れの深い分野なので欲が出るところですが、果たしてここに時間を投資することがプロジェクトにとって意味があるのか確信が持てず、躊躇していました。
幸いシニアフィードバックでは、私たちが差別化ポイントとしたい要素なら十分に実装する価値があり、むしろ積極的に活用してみるのが良いという言葉をいただけました。キャラクター自体は必須機能ではなくても、サービスを差別化しチームの挑戦レベルを引き上げる装置としては十分に意味があるという判断でした。
結局、このフィードバックの核心は「基本機能の実装にとどまっていると既存のサービスと似通ってしまうので、ワオ・ポイントを先に打ち出し、その上に機能を積み上げていけ」というメッセージだったと理解しました。ただ、キャラクターを2Dにするか3Dにするかという具体的な結論までは出せないまま、この悩みを抱えてインターミッションへと入ることになりました。
良かった点
惜しかった点
インターミッション期間は、予定が多く入ってしまい、思ったほど時間を確保できませんでした。深く勉強するのは難しかったです。
それでも、運良く Three.js の講義を聞く機会があり、これまで Blender だけで見ていたものをコードで実装する経験は非常に新鮮でした。自分が担当する領域であるだけに、2Dと3Dキャラクターをある程度形にしてチームに見せたいと思い、時間を投資しました。
Slackを見ると、インターミッション中も勉強会を開いて各自勉強し発表しているチームが多く、その姿を見てこのキャンプに参加できたことは本当に幸運だと感じました。同時に、自分ももっと頑張らなければならないという刺激をたくさん受けました。キャンプの終わりが近づくにつれ、今後より深く勉強するためにどのような環境を作るべきか、勉強会を立ち上げるべきかなど、個人的な悩みも多くなりました。
3週目の序盤は、久しぶりに集まったこともあり、ウォーミングアップの時間が必要でした。以前のフィードバックを総合してプロジェクトの方向性を再設定し、私たちが選択したアイデアに対して優先順位を明確に整理しました。
個人的には、報酬システムのように今すぐの実装には必要なくても、チーム全員がサービス構造を同じように理解できるように整理が必要だと考え、これを提案しました。幸い意見がまとまり、非常に意味のある議論となりました。
会議の内容が適切に記録されないことがずっと心残りだったため、今回は初めて Slackハドルのスクリプト を整理する方式を導入しました。確実に記録が残るので、以前の議論の文脈を把握するのが格段に楽になりました。
その後はMVPの範囲を基準に優先順位を確定し、2日間で素早く実装する時間を持ちました。テストや Storybook を積極的に活用したプロジェクトは初めてだったので、慣れないながらも不思議な経験でした。
個人的には、一つのPRにおけるコミット量が多すぎるという点を再認識しました。リファクタリングや細かな修正を一緒に入れてしまうため、PRが肥大化する問題が繰り返されました。以前よりコミットを細かく分ける能力は少し向上しましたが、一つのPRを明確な目的に合わせて簡潔に作る能力はまだ不足していると感じています。
イシューをどのような単位で分けるかも悩みどころです。例えば、一つのイシューで複数のコンポーネントを同時に作る必要がある時、分けると文脈が切れ、まとめるとPRが大きくなるというジレンマがありました。他の人たちがこのような状況をどう解決しているのか、もっと見て学びたいです。
今週は最終日にフロントエンドとバックエンドを連携させ、デプロイまで行いました。ところが、デモ直前まで予想以上に多くのイシューが発生し、結局開始1分前まで作業を続けることになりました。
その結果、デモではかつてないほど緊張し、発表も非常に満足のいかないものになってしまいました。知り合いが多い場だったので、より良い姿を見せたかっただけに、悔しさが大きかったです。途中で画面の問題が発生して慌ててしまい、全体的な流れがスムーズでなかったことが本当に、本当に心残りです。
来週は以下を必ず改善したいです。
また、これまでの3週間を過ごして、次のような悩みが生まれました。
以前のチームプロジェクトが途中で頓挫した経験があるだけに、今回のプロジェクトだけは必ず一つの完成した結果物を経験したいです。残りの期間、これらの考えをしっかり整理しながら、より意味のあるチーム開発を作り上げていきたいです。
