1人でセルフハッカソンを開催してみた

こんにちは！yamaです。

この記事は [DeNA 24 新卒 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/dena-24-newgrad) の3日目の記事です。
今後、様々なジャンルの記事がアップロードされていくと思うのでぜひ登録とチェックをしてみてください！


アドベントカレンダーに向けて1人で開催、開発、発表のセルフハッカソンを行いました。
この記事では作ったものと簡単な技術の紹介・公開してからの改善などを記事にしようと思います。

## 作ったもの
何気ないツイートが炎上や問題にならなるのが怖いので、OpenAIのAPIを使って判定やコメントしてくれる「SNS炎上防止チェッカー HAKIDAME」です！

https://hakidame.yama-code.dev/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/18cb3057-d955-8c56-8b5e-2b10cf0e3efa.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/dceb1342-cb50-9367-8a41-3699b8c20ee9.png)

## モチベーション

アドベントカレンダー投稿へ向けて投稿する内容を考えていたところ、最近趣味での開発やハッカソンに参加する機会が減っていることに気がつき、1人で個人開発という名前のハッカソンをしたいと思いました。
またハッカソンで締め切りが決まるため個人開発も続きやすいかと思いました。

## レギュレーション決め

今回、ハッカソンを行うにあたってはじめにレギュレーションを決めました。
今回一人で行うので、審査基準は「客観的に評価ができる指標」が必要です。
またせっかく行うので、ハッカソンの審査基準を調べ審査の基準にないような内容や私が大事だと思うような指標を入れたいと思いました。

＜ハッカソンの審査基準＞
- 最優秀賞（1チームしかないのですが...）
記事公開までの1週間の獲得ユーザーが **100ユーザー**以上


- 優秀賞：
記事公開までの1週間の獲得ユーザーが **50ユーザー**以上


とレギュレーションを決め、期日をアドベントカレンダー投稿1週間前までとしました。
基準の数値については体感で決めているのですが、個人開発ではじめに100名以上の人に使ってもらえるプロダクトはニーズや需要があるのではないかと目標を設定しました。

## アイデア作成

上記のレギュレーションを決めたため、アイデアは

①：使ってもらう・使い続けてもらうことを視野に入れたアプリ
②：1週間以内で隙間時間に開発できるようなシンプルな構成と実装
③：そこまで使ったことない最新の技術を使う

の3つがアイデアの要件としてあがりました。
①が一番難しく、はじめに興味を持ってもらったあと

以前、別のハッカソンでプレゼンに関するアプリケーションを作成したのですが、なかなかユーザーが増えずヒヤリングを進めた際に「プレゼンを定期的にする人は少ない・多くても月1回」ということがありました。
そのため、今回作るものは日常的に行うことの中の課題を見つけることを意識しました。

日頃日常的に行うことについて考えたところ「X」を使うことがあり、社会人を見据えて発言内容についてより気をつけるべきと思っており、感情認識といった画一的なAPIを使うだけではない総合的な判別を流行りのLLMの技術を使うことでできるのではないかと思いました。

②についても「投稿をして判定する」というシンプルな仕組みとなり、③に関してもOpenAIのAPIを使ってアプリを公開したことがなかったため勉強になると思いました。

#### リーンキャンバス

アイデアをリーンキャンバスというフレームワークを使い、アイデアがどれくらい良いものかについても作りながら考えていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/b89a1e87-4bcf-c712-02b5-80a4205662df.png)

### 使用技術

技術的には「1週間で開発できる」「OpenAIのAPIのFunction Callingを使う」のみを考えていたため、クラウドにFirebaseの機能を使い、フロントエンドにはVue.jsのフレームワークのQuasar.jsを使用しました。フロントエンドのフレームワークはどの技術を使用しても問題ない条件だったのですが、「UIのコンポーネントが豊富」「Vue3に対応している」 ことを考えこのフレームワークを使用しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/cc59024c-985f-1235-5338-c3fce47025de.png)

技術的にハマった箇所について簡単に共有します。

### OpenAIのAPIのFunction Callingの注意点

指定したJSONの形式で返答を返すことができるFunction Callingsの機能を使用しました。しかし、指定した形式以外の返答が稀にあり、期待していない返答の場合の処理を考えて記載しました。
また、1度だけのリトライなども実行するようにしました。

### APIへの実行制限

無料で使えるアプリであるため、GPTを使ったアプリケーションによくみられる実行の制限をつけました。
今後の機能の追加やユーザー数と使用状況の把握するために実行の結果をFirestoreに保存しています。
今回は実行前に最新の5件の投稿を取得しそれが指定の時間内に投稿されたものかを判別しました。

## 公開後のフィードバックと改善点

公開後の1週間で様々な人にサービスを使ってもらい、アンケートやヒヤリングなどフィードバックをいただき検証と改善をしました。
以下にいただいたフィードバックの一部と改善点をまとめます。

#### 判定項目の追加

はじめにもらったフィードバックとして、判定項目を増やすとよりエンタメとして面白くなるとフィードバックをもらいました。様々なタスクを行うことができるLLMを使うメリットかと思い追加しました。

![追加した機能](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/97535eb1-bcd0-f61d-20da-f55c9bc78431.png)



#### OpenAIのAPIのBillingに関するエラー・Statusが500のエラー

OpenAIのAPIの使用量の設定の上限値を設定したのですが、上限になるとアクセスができないということがリリース直後に発生しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/229b4626-6533-77cc-c7ff-ee5e055d4a67.png)

またOpenAIのAPIから戻ってくる値によって、エラーが発生することがあり発表直後にいただいたフィードバックがこの内容のエラーが多くなってしまいました。

また、エラーメッセージが「Request failed with status code ~~」のような形式であったため、どのような行動をとった方が良いかがわからないため問い合わせやこのコメントが多かったのではないかと思います。
そのためエラーメッセージに加えて、**エラーが発生した際にどのような行動をとって欲しいか**についても記載しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/af66cf71-f344-69a5-5d83-a61069922b26.png)

また、エラーが発生した際にログを辿らないと気が付かないまま公開してしまったため、フィードバックでエラーを知りました。そのためエラーが発生した際に **Slack Bot**としてエラーが見えるように変更しました。

#### UIの修正

自分でデバックや使っている間やいただいたフィードバックの中に、「投稿する」ボタンの位置の押し間違いがあることがわかりました。

理由としては、
- 「再度チェックする」ボタンと「投稿する」ボタンが並列になっていること
- 色使いが青色で紛らわしい

ことがフィードバックとしてありました。
そのため修正で明確に「X」とわかるアイコンとボタンに変更しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/bdab0d6d-a481-ed0b-5b3c-e51f39c6ccef.png)

#### 技術以外のフィードバック

リーンキャンバスやビジネス面でもフィードバックをいただきました。
フィードバックは主に2点あり、

- リーンキャンバスのコスト体系などで **具体的な数値**を概算すること
- このサービスを使う人は **炎上を起こさない人が使うサービス**となっているのではないか

ということです。

どのようなビジネスモデルを考えるかにもよりますが、「明確なターゲットと費用対効果」があるとより説得力が増すので計算をしないといけない

また、別のフィードバックとして「衝動的な投稿が炎上しやすいと仮定すると、このサービスはそういった人には使われないのでは」とのコメントをもらい、作る前の検証がより必要と感じました。
今回様々な方にコメントをもらい、 **サービスの良い点悪い点がより明確**になりました。
1週間という制約だったので作る前にコメントをもらうことはしなかったのですが、作成の前に課題がよりわかっていると良いと思いました。

## 今回の開発で学んだこと

今回の開発で学んだことについては、

- エラーのアラートを必ず設定する
- 適切なエラーメッセージを表示する
- 様々な人にフィードバックやコメントをいただくと課題がわかる

「エラーのアラートを必ず設定する」「適切なエラーメッセージを表示する」は公開後にエラーに関するコメントが多くなってしまい、はじめからできていればよりアプリについて話せただろうと思いました。
また、フィードバックをもらったことで新しい視点や知見を得ることができ、次に活かしたり修正することができました。

## 結果

- ユーザー数： 
**40人**（2023年12月2日00:00現在）

今回ははじめに決めた基準より賞なしです...

- Google Analyticsの結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548598/3887decc-eaae-2c7b-076f-3afc497e7db4.png)


公開日が25日であるため、公開3日後の28,29日にははアクセスが少なくなっていました。
多くの人に使ってもらえて継続性のあるサービスを作るのはすごく難しいと改めて感じました。


## まとめ

今回、1人でハッカソンを行い、「HAKIDAME」というアプリを作成しました。
また、発表後にフィードバックをもらったことで課題などもわかりました。
個人開発で詰まっている方はぜひやってみてください。

明日は、[wbelucky](https://qiita.com/wbelucky)さんのアドベントカレンダーです。ぜひご覧ください！