文化祭で使うアプリを1人で作った話

Transcript

1. 文化祭で使うアプリを1人で作った話 緒方 克哉
2. 自己紹介 名前 : 緒方 克哉（おがた かつや） 出身 : 宮崎県小林市 所属 : 大阪大学 基礎工学部 情報科学学科 B3 趣味 : 登山 旅行 サウナ 役割 : アプリケーションエンジニア 屋久島登山 地元小林市 ブルネイのビーチ
3. • ユーザーがいるサービスを要件定義から実装（運用まで）行った際に 意識したこと・学んだこと • Bizサイドとのやりとりについて学んだこと • エムニでのインターンで学んだことをどのように実装に活かしたか 伝えたいこと
4. • 文化祭で謎解きを出展するので、その解答アプリを作成したい • 謎解きは質問を答えるごとに前の問題がヒントになったりするので、その場で解 答の正誤がわかる必要がある • 運営メンバーが10人弱なので最小限の人数で運営を行う必要がある • 文化祭は3日間にわたって行われ、大体600~700人がこのアプリを用いる • 1時間に3回のセットで謎解きが行われ、1回あたり10組づつアプリを用いる 概要
5. 今回のサービスの難しいところってどこ？ 難所 • 本当に使ってもらえるのか？ • 限られた時間内で実装を行う必要がある • Bizとのコミュニケーション
6. 目指すエンジニアのスタンス
7. アンチパターン 強いBiz 実装するDev
8. • BizとDevの関係をフラットに • BizがDevにお願いするという形ではなく、Bizはユーザーの価値を追求してそれを実現する ための手段をDevに要求する • Devは本当に必要なのか？また、いつまでにできるのか、もっと良い方法がないかを提案す る • 同じ価値をもっと簡単で、長期的にみて良い方法を選択する • Dev側で責務を負うのではなく、運用でカバーできるのではないか？を考える • Devが不十分な意思決定だと思ったらBizに要求し返す • 意思決定の背景をきちんとはっきりとさせておく • 確信のある意思決定でない or ユーザー目線でない軸での意思決定は再考を促す エンジニアのスタンス
9. • 優先順位を明確に、最速で最良のものを作る • まずはDB構造を意識しながら認識を深めていく • 参加が個人だったところからグループに • 解答は複数 • 次にbackendの認識をすり合わせる • スコアの付け方 • 管理画面ではどう言った操作が考えられるか • どう言ったページの遷移が行われるか • 最後にfrontendの画面構成 • figmaでデザインを起こしてもらう • できるだけ早めに作成してFBをもらって改善する 優先順位
10. ER図
11. APIサーバー
12. 謎解き画面 CLE : https://www.cle.osaka-u.ac.jp/?new_loc=%2Fultra%2F
13. 管理画面
14. 開発環境
15. 開発環境 •Dockerを用いて簡単環境構築 • ゆくゆくはDevContainerを使いたいなぁ。。 •CIを設けて、コード品質を担保する • Frontend: Biome, Build • Backend: Ruff •エディタでも楽々開発 • BiomeとRuffを用いて保存時に自動フォーマット • npm runコマンドにして簡単実行 •OpenAPIを用いて型安全で簡単にAPI疎通をとる • こちらもnpm runコマンドにして簡単にclient更新
16. 開発環境 Source : 新卒1年目が向き合う生成AI事業の開発を加速させる技術選定
17. インフラ
18. インフラ •とにかくお金をかけない構成 • AWSの無料枠をフル活用 • できる部分はサーバーレスに • フロントエンドはpushしたら自動更新される • バックエンドは更新負荷を少しでも下げるためにECRへのpushまでをactionsで自動化 • OIDCを用いた安全なCDを作成 • ref: https://zenn.dev/miyajan/articles/github-actions-support-openid-connect • 検証のために簡単にRDSにSQLを叩けるように踏み台サーバーを用意
19. 今後の展望 • 本番3日間をどうにか成功させる • 1日目大丈夫そうだったら2,3日目は登山に行きます • バックエンドのテストを書きたい • 文化祭後の仮説検証のための開発 • 直接EC2経由でSQLを書いても良いが。。 • 時間帯ごと、人数別、問題セットごと、スコア平均 etc… • API実装？