6週間のグループスプリントを通じて学んだ設計の試行錯誤、協業のノウハウ、そしてシニアからのフィードバックによる成長の記録
入力したパスワードは秘密コメントの閲覧、修正、削除に使われます。
1月1日になったら一番にすること：スプリントの振り返りを書く！
10週間の学習スプリントに続き、6週間のグループスプリントもあっという間に過ぎ去りました。久しぶりのチームプロジェクトということもあり、開始前は緊張していましたが、志を同じくする優秀なチームメイトに出会い、非常に価値のある経験を積むことができました。
グループスプリントに臨むにあたって、当初は大きなプレッシャーを感じていました。チャレンジと学習スプリントの過程で、一度も作業を完全にやり遂げた経験がなかったことや、バックエンドの領域をチームメイトのスピードに合わせてついていけるかという不安が大きかったからです。
幸いにも、成果物よりも「協業のプロセス自体」に集中しようという共通認識を持つチームメイトに出会い、共に学び、お互いのコードを理解することに重点を置いたスプリントを経験することができました。
朝から深夜まで会議が続くほど多くの対話を重ね、一つのテーマを共に設計し、レビューする過程を繰り返しました。効率的な方式だったかについては評価が分かれるかもしれませんが、すべてのメンバーが同じ文脈を共有し、衝突を直接経験しながら説明する練習を十分にできたという点では、間違いなく意味のある経験だったと思います。
フロントエンド志望の4人が集まりましたが、プロジェクトのテーマはバックエンドの比重がかなり大きいものでした。フロントエンドはUIを表現する役割に近く、核心的なロジックはバックエンドで処理することが目標だったため、設計段階で多くの困難に直面しました。非専攻者（私）が含まれるチーム構成と、設計経験の不足が重なり、試行錯誤も頻繁に起こりました。
振り返ってみると、事前にもっと要件を明確に整理し、モジュール化を徹底した状態で実装していれば、不必要に遠回りする部分を減らせたのではないかと思います。それでも、実際の実装を通じてどのような設計が問題を引き起こしたのか、再設計するなら何を変えるべきかを体感できたことは、大きな収穫でした。
次のプロジェクトでは、モジュール間の相互参照のような構造的問題を初期段階で遮断できるよう、設計段階にもっと多くの時間を投資したいと考えています。
今回のテーマは以前の課題よりもCS（コンピュータサイエンス）の基礎知識が強く求められました。設計経験とCSの理解度が共に不足していたため、チームの設計議論に積極的に寄与できなかったことは、個人的に心残りとして残っています。
フロントエンド開発者が集まったチームという特性上、UIだけでなくLint、Prettier、GitHub Project、PRルールなど、全般的なコンベンションを重要視しました。日頃からチームプロジェクトでこうした基準が守られることを願っていましたが、今回のスプリントでは比較的うまく定着させることができ、満足しています。
他のチームがHuskyやGitHub Actionsを活用してコミット、リント、テストを自動的に検証している姿を見て、次のプロジェクトではこうしたツールを導入し、チーム内の疲労度を軽減してみたいと感じました。
ありがたいことに、運営の方々が私たちのCS学習を見て、励ましの言葉を残してくださいました。
今回のグループスプリント期間中、CSクイズの運営方式が従来の週単位から3週単位に変更されました。これをどう活用するかチームで話し合い、以下のような方式で進めました。
同じ質問を毎週異なる観点から眺めることで、思考を拡張することができ、クイズの意図についても自然と深く考えるようになりました。
設計の前にCS学習を行っていればさらに役立っただろうという惜しさはありますが、明確な目標なしに進めていればここまで深く扱えなかったと思うので、全体的には非常に肯定的な経験でした。
以前のスプリントまでは実装に集中するあまり、ドキュメント化がほとんどできていませんでした。しかし、チームプロジェクトではすべてのメンバーが進捗状況を理解し、必要な時にいつでも確認できる必要があるということを痛感しました。
スクラムの記録、議事録、コンベンション、PRの内容を中心にドキュメント化を行い、序盤はNotionを中心に議事録を整理しました。
その後、他のチームの事例を参考に、Notion AIを活用した要約やADR（アーキテクチャ意思決定記録）作成方式も導入しました。特にADRは意思決定の背景が明確になるという点で印象深く、次のプロジェクトでは初期から積極的に活用したいと思いました。
リファクタリング期間にはAI機能をプロジェクトに適用する作業を担当し、関連内容をvelogにまとめてチームメンバーに共有しました。実装プロセスが複雑だったため、ドキュメント作成にも多くの時間を費やしましたが、実装方法よりも**「なぜこのように実装したのか」**をもっと明確に説明すべきだというフィードバックをいただきました。
🤔 悩み
核心を伝えながらも文脈を理解しやすいドキュメント化をどう実現するか、という悩みが残りました。
大学時代からチームプロジェクトでは一箇所に集まり、長い時間をかけて議論しながら問題を解決する方式を好んできました。ただ、チームメンバーの多くが内向的な場合、この会議方式が負担にならないかという心配もありました。
幸い、今回のチームでは長時間の会議に対する大きな不便さはありませんでしたが、今後異なる傾向のチームメイトと協力する場合に備え、より効率的なコミュニケーション方法について考えるようになりました。
チームメイトのフィードバックの中に、「まだ頭の中で結論が出ていない時、沈黙するよりも『考え中だ』『特にこだわりはない』といった意思表示をしてほしい」という意見がありました。普段、私自身も相手の反応がないと顔色を伺ってしまうタイプであるにもかかわらず、何度かこれに気づけなかったようです。
より円滑で途切れのないチームプロジェクトのために、明確な意思表示が必要であることを再認識しました。
大学での発表経験があったおかげで、デモの準備プロセスは比較的スムーズでした。チームメイトも積極的に参加してくれ、資料作成も円滑に進みました。
ただ、リファクタリング期間を含め報告書を作成する段階になって、結果をもう少し「定量的な数値」で示せればよかったという後悔が残りました。
他のチームは全般的に企業の報告書に近い形式を取っており、私たちのチームもマスタークラスの際には「良い報告書」というフィードバックをいただきましたが、開発分野では定量的な指標が含まれた報告書の方がより説得力を持つのではないかと感じました。こうした形式の報告書をより多く練習することが、今後の就職活動においても間違いなく役立つと実感しました。
また、週を追うごとにデモの時点で他のチームが把握していない作業が積み重なっていき、それをどう効果的に伝えるかという悩みも生じました。自分たちが行ったすべての作業を共有するのが良いのか、それとも一部を選別して共有するのが効果的なのか、考え続けました。
毎回のデモで受けたいフィードバックを事前に整理して臨みましたが、期待したほどのフィードバックを得られないことも多かったです。この過程で、私たちが問題状況を十分に明確に共有できていなかったのではないかと振り返ることになり、デモを通じてより良いフィードバックを引き出すための方法について考える必要性を感じました。
これまで私は、リファクタリングをコードの整理、重複の除去、単一責任の原則に基づくコンポーネントの分離、アクセシビリティの強化といった観点で主に捉えていました。しかし、他のチームのデモを見て、リファクタリングの焦点がパフォーマンス向上に合わせられているケースが多いという印象を受けました。
今回の2週間のリファクタリングを進める中で、「私たちのチームはこの過程で何を得ようとしているのか」という問いを何度も繰り返しました。私たちのチームは当初からコードレビューやコンベンションの定立がしっかりなされていたため、構造的な問題やスタイルの不一致がほとんどありませんでした。一方で、プロジェクトを交換した他のチームの場合、各自が機能実装に集中していた分、ファイル間のスタイル差や再利用性の側面で改善の余地が見られました。
こうした作業は長期的なプロジェクトでは意味がありますが、2週間という短い期間の中で数値化できる成果を作るには限界があると感じました。その結果、私たちのチームは初期には構造の整備に集中しましたが、次第にそれよりも「私たちが実際に得られる学習と結果」に焦点を当てるようになりました。
リファクタリング期間の基本ルールは「ロジックを変更せずにコードのみを改善する」ことでしたが、私たちのチームは以前のプロジェクトで完全に終わらせられなかった設計を補完する方向で、一部機能を追加する作業も並行しました。限られた時間の中で、単純なコード整理にとどまらず、プロジェクト全体の完成度を高める選択をした経験でした。
リファクタリングの終盤には、ありがたい機会に恵まれシニアフィードバックを受けることができました。これまで抱えてきた問題や悩みをドキュメントにまとめ、緊張した面持ちでフィードバックに臨みました。
今回のレビューを通じて、問題状況自体は比較的よく把握できているものの、それを「技術的な用語」で正確に説明する能力が不足していることを明確に認識しました。問題解決のプロセスを説明する際、やや抽象的な表現にとどまる傾向があり、具体性と専門性を補完する必要があるというフィードバックをいただきました。
設計とCSの基礎が自分自身で最も不足していると感じていた部分でしたが、そこを正確に指摘していただき、驚くと同時に今後何を学習すべきかという方向性がより明確になりました。
**「ある決定を下した背景とその過程を、誰もが共通して使用する用語に基づき論理的に説明する経験が十分に必要である」**という点を痛感する時間でした。
今回のシニアフィードバックはチームプロジェクト全般に対する悩みや個人的な学習の方向性が中心で、技術的な議論は相対的に少なかったのですが、他のキャンパーの方々が技術について深い質疑応答を交わしている姿を見て、もっと自分も奮起しなければならないと感じました。
今のレベルではそうした質問に十分答えるのは難しかったかもしれませんが、慣れ親しんだフロントエンド技術だけでなく、多様な技術領域を地道に、そして正確に学習し、自信を持って説明できる開発者になりたいという目標を改めて固めることができました。
シニアフィードバックとグループスプリントで感じた不足している点を踏まえ、設計関連の書籍を選定し、主体的に設計能力を養う学習プロセスを経験しようと思います。これまでは大学の授業と並行していたため、個人学習の時間を十分に確保するのが難しかったですが、これからはブーストキャンプの学習に集中できる環境になりました。
今後は毎週浮かび上がった疑問や補完が必要な部分を中心に学習し、不足している能力を体系的に埋めていきたいと考えています。
グループプロジェクトを進める中で、チームメンバーに負担をかけたくないという思いから、夜遅くまで作業する日が多かったです。しかし、こうした方式がかえって日中の集中力を低下させ、全体的な効率を損なうということも身をもって体験しました。
チャレンジ期間には睡眠を削って耐えることができましたが、メンバーシップ課程では前日の無理が翌日の学習や協業に直接影響するということをはっきりと感じました。今後はチームに貢献しつつも、個人のコンディションと生活のバランスを維持できる作業スタイルを模索し、より持続可能な協業の形を見つけていきたいです。
チームメイトと共に過ごした6週間という時間は、長いようでいて非常に短かったです。この期間中、自分にどのような部分が不足しているのか、そしてどのような点を改善すれば「一緒に働きたいチームメイト」になれるのかを肌で感じることができました。
今回の振り返りで整理した悩みと学びを忘れず、今後の成長過程にしっかりと反映させていきたいと思います。不足している点が多かった私を共に成長し導いてくれたF4 7チームのメンバーの皆さんに感謝の気持ちを伝えます。
アイデア選定からシニアフィードバックを経てMVP実装まで、プロジェクトの土台を築く過程で経験した試行錯誤と技術的挑戦の記録
ベクトルの長さを1にする「正規化」の本質を、ゲームの移動ロジックやBlenderの「Apply Scale」の事例から紐解きます。
6週間のグループスプリントを通じて学んだ設計の試行錯誤、協業のノウハウ、そしてシニアからのフィードバックによる成長の記録
Boostcampメンバーシップで経験した10週間の学習スプリントを振り返り、技術的な学び、設計の悩み、燃え尽き、そしてAI活用についてまとめた記録。
Boostcamp Challenge 期間の振り返り。毎日のミッション、CS学習、ピアフィードバック、チーム活動、そして AI と共に成長する学習方法についてまとめました。
関数型プログラミングとオブジェクト指向プログラミングの長所と短所、およびリアクトで関数型を選択した理由についての探求の記録
ネイバー・ブーストキャンプ Web・Mobile 10期 Basic 受講と問題解決力テストの体験記。
OSCCA マスター期間中に Githru プロジェクトで行った UI 改善、Issue 提案、Pull Request の経験をまとめた記録。
OSCCA チャレンジ期間に Githru プロジェクトへ参加し、Issue 提案や初めての Pull Request を経験した記録。
Open Source Contribution Academy に応募するまでの過程と Githru VSCode Extension を実際に試した感想をまとめた記録。
마지막 아티클까지 모두 확인했습니다.
オンボーディングの改善からインフラ監視、リアルタイム通信、그리고 3Dキャラクターの最適化まで、7週間にわたるグループプロジェクトの完走記録
ネイバー・ブーストキャンプ Web・Mobile 10期 Basic 受講と問題解決力テストの体験記。
ベーシックからグループプロジェクトまで、てCS知識を体得し、AIエンジニアリングと設計の本質を悟りながら成長した7ヶ月間の軌跡
