
福岡現地研修の期間と開発期間が相まってしまい、予想以上に時間が迫っていた「大学ESG実践フォーラム」プロジェクトについて回顧を書いてみたいと思います。
「大学ESG実践フォーラム」は何?
大学ESG実践フォーラムウェブサイト
8月にある福岡現地研修の時、サービスすることを目的で企画したプロジェクトです。
学校の課題として一回同じコンセプトで作ったが、使えるツールも機能も決まっていましたので満足度の高いウェブサイトを作ることができなかったので、新しくチームを結成し、作り直してみました!自分を含めて4人のチームで私はチームリーダーとしてプロジェクトの全般的なリードとバックエンドを担当しました。
チームメンバーはこちらの通りです。💁🏻♂️

気にしていたこと
プロジェクトを進めながら気にしていたことは大きく三つです。
- Notionを使わずにプロジェクト進行
今までプロジェクトはノションで管理していましたが、今回はGithub Wiki機能を活用してみることにしました。
- スマートエディタを活用して投稿機能を実装 これまでは投稿の基本的な機能だけを実装していましたが、今回はユーザーにより満足度の高い経験を提供するために、投稿をより自由に作成できるスマートエディタを適用しました。
- JWTを使ったログイン機能開発 ログイン機能を実装する際にJWTトークンを使用しました。データの改ざんを防ぐことができ、JWTは認証に必要なすべての情報を含んでいるため、認証のための別のストレージが必要ないという点が魅力的に感じられたので採用しました。
Tip❗
技術スタック

フロントエンドは
React、TailwindCSSを、バックエンドはLaravelとMySQLを使いました。配布はDockerとNginX, AWSを使いました。担当したこと
- システム設計
- ERD, Branch戦略の設計
- 文書化
- ログイン&会員登録ページのレイアウトとAPIの実装
- メイン事業ページのレイアウトとAPIの実装
- 会員案内ページのレイアウトとAPIの実装
- 掲示板(セミナー、資料室、お知らせ広場)ページのレイアウトとAPIの実装
- 記事作成レイアウトとAPIの実装
- 管理者ページAPIの実装
- ヘッダーの実装
難しかったこと
ルート宣言の問題(フロント、バックエンドロジックに大きな問題がないのに404エラー発生)
문제가 발생하는 원인은 라우트 정의 순서에 있습니다. Laravel은 라우트를 위에서 아래로 차례대로 확인하고, 일치하는 첫 번째 라우트를 실행합니다.
라우트 정의에서
/seminars/{id}가 /seminars/total, /seminars/ongoing, /seminars/past보다 앞에 위치해 있기 때문에 이것이 문제입니다. total, ongoing, past와 같은 문자열을 {id} 파라미터로 인식하고 해당 라우트를 실행하기 때문에 404 에러가 발생합니다.따라서 해결책은 라우트 정의 순서를 변경하는 것입니다. 구체적인 값을 가진 경로(
/seminars/total, /seminars/ongoing, /seminars/past)를 상위에 배치하고, 파라미터({id})를 포함한 경로는 그 아래에 배치해야 합니다.created_at フォームの問題


public function getCreatedAtAttribute($value) { return Carbon::parse($value)->format('Y-m-d H:i:s'); }
getCreatedAtAttribute($value) 메소드는 created_at 필드의 원래 값을 받아서, Carbon 라이브러리를 사용하여 원하는 형식으로 날짜/시간을 변환합니다. 이 경우, 'Y-m-d H:i:s' 형식으로 반환하도록 설정했습니다.useEffectフックが初期レンダリング後にトークン値を設定
管理者確認Middleware
KPTを使ってまとめてみましょう
Keep
現在満足しているところ、続けてほしいところ
- スマートエディタを使ってより楽に投稿機能を実装
- JWTを使ったログインロジック実装
Problem
不便に感じる部分、改善が必要だと思う部分
- リーダーという役割の大切さ
- コミュニケーションの不在
- 役割分配の問題
- コードコンベンション未適用
- GitHub Issue、マイルストーン、プロジェクト機能を活用しなかったこと
- コードレビューX
- テストコード未作成
Try
Problemに対する解決策、次の回顧時に判別可能なもの、すぐに実行可能なもの
- 企画の最初からリーダーを選べ、プロジェクトをリードする人を決めること
- リーダーだけでなく、積極的にコミュニケーションをとり、それぞれの進捗状況を共有すること
- 企画段階で実装機能を細かく区分し、担当者を明確に指定すること
- 企画段階でコードコンベンションの必要性を共有し、企画段階で作成すること
- GitHub に内蔵された便利な機能であるIssue、マイルストーン、プロジェクト機能について改めて学習して適用すること
- 時間に追われて実施できなかったコードレビューやテストコード作成も次のプロジェクトでは適用してみたいと思います
まとめ
自分が主体的に企画して実装するようなプロジェクトではなく、実際のユーザーが存在し、依頼した顧客のニーズに合わせたプロジェクトを企画から実装まで行ったのは初めてでした。 すでに枠組みが決まっていて安定してサービスが提供されている状況だった「グローバルゾーン」とは異なり、デザインから始めてすべての部分を考慮して実装しなければならないという点が、複雑なロジックが要求されないレベルのプロジェクトであったにもかかわらず、思ったより時間がかかった主な要因の一つだと思います。
一番切実に感じたのは、リーダーの存在でした。私以外の3人のチームメート達は学校でも優秀な人材であり、福岡現地研修という大きなイベントもあったため、本プロジェクトを任された当初は、あえて私がプロジェクトを管理する必要はないと思っていましたが、それは大きな勘違いでした。😅
プロジェクトを統括する人がいないため、コミュニケーションが活発に行われず、プロジェクトの進捗状況を把握することが難しく、これは効率低下につながりました。 さらに、プロジェクトよりも他のことを優先する人員が存在し、プロジェクトがスムーズに進まず、本来なら他のチームメンバーが担当すべき部分まで急いで実装するような笑い話もありました。😂
このままではいけないと判断し、すぐにでもリーダーを名乗り、各自の状況を把握した上で、各自がやるべきことを改めて調整し、プロジェクトを無事に終えることに成功しました。


.png?table=block&id=bc8e1a2b-5ad8-4828-94cc-a4d00d7f8b09&cache=v2)
댓글