Next × PlanetScale × Prisma × NextAuthでフリーランス/副業エンジニア向け稼働記録アプリを作った話
概要
Next × PlanetScale × Prisma × NextAuthを使用して、フリーランス/副業エンジニア向けの稼働記録WEBアプリを作ってリリースしました。
何をするサービスか
- 稼働表が作れて
- ボタン1つで稼働開始 / 休憩 / 稼働終了の時間を記録でき
- PDFで出力できる
サービスになります。
タイムカードをWEBアプリ化したものを想像していただけたら、わかりやすいかと思います。
作ったもの
なんで作ったか
私はフリーランスのフロントエンドエンジニアです。(自己紹介)
quintet株式会社でOneMinutesや株式会社MoneyForwardでマネーフォワードクラウド会計の開発のお手伝いをさせていただいています。
時給で働いているので、稼働時間報告書(いつ何時から何時まで働いたってのをまとめたやつ)を月末に提出するのですが、私が怠惰な人間なため、毎日スプレッドシートに記入するのをサボりがちです。
なので、月末にSlackの「稼働します」「休憩します」「稼働終わります」のメッセージの送信時間から全稼働をスプレッドシートに記入するのですが、それがめんどくさすぎるんですよね。
そのめんどくささをなんとかしたくて、このアプリを開発しました。
また、私のエンジニアとしての夢の1つに自分で考えたアプリケーションを自分で作って、それで誰かを幸せにしたいというものがあり、その実現のための第1歩です。
開発の話
スタックの選定の話
- フロントエンドフレームワーク
- Next.js(AppRouter)
- DB
- PlanetScale
- Prisma (ORM)
- 認証
- NextAuth
- CSSフレームワーク
- tailwindcss
- daisyUI
- ローカルステート管理
- jotai
を使用しています。
- jotai
Nextを採用した理由と感想
OneMinutesでNext + MUIで開発しており、慣れているからというのが第1の理由ですね。
開発始めた当初はAppRouterがstableになったばかりくらいのタイミングだったので使ってみたかったというのも理由としては大きいです。
開発当初は慣れていないこともあって、クライアントコンポーネントでasync消し忘れていてエラーが消えなかったりしていましたが、慣れたら実装しやすいと感じました。
PlanetScale + Prismaを採用した理由と感想
supabaseと悩んだのですが、使ったことのないPlanetScaleを使ってみようと思って選定しました。
なんとなくのイメージでPlanetScaleを使うならPrismaかなみたいな。あまり何も考えずに選定しました。個人的にはベタな選択だったかと思っております。
PlanetScaleのブランチはめっちゃくちゃ便利。無料だとmainが1つ、開発で1つしか作れないのが残念。
PlanetScale自体のWebサイトがかなりわかりやすいので選択としてはナイス判断だったかと思っております。
公式のドキュメントも結構充実しているので導入が簡単でした。
prismaもかなり使いやすいですね。supabaseのデータ取得APIに比べてだいぶ使いやすいと思いました。
NextAuthを採用した理由と感想
auth0と悩みましたが、無料でprismaとの連携も簡単で、最悪剥がしやすそうなという印象で選びました。これも割とベタな選択だと思っています。
導入が簡単なところが良かったですね。
基本的には公式ドキュメント通りに設定するだけで動かせるので最高でした。
tailwindcss + daisyUIを採用した理由と感想
Nextならほぼno-configで使える + daisyUIを以前にちょっと触ったことがあるというのが理由です。
MUI(JoyUI)にしようかと思っていたのですが、開発始めた当時はAppRouterに対応していない?みたいな感じだったのでやめました。
導入が簡単、デザインもそこそこおしゃれ、設定も簡単で使いやすいです。
jotaiを採用した理由と感想
recoilと悩んだのですが、recoilは使ったことがあって、keyの設定がめんどくさいなぁと感じていたので、
keyの設定が不要でほぼ同じのjotaiを採用しました。
ただ、公式ドキュメントが若干わかりにくい印象です。
まだほぼほぼ使っていないので、なんとも言えないですね。
SlackAppを作った話
上記スタックでwebアプリを開発して、一緒に飲んでた元MoneyForwardのエンジニアに見せたところ、
「こういうアプリはアプリを開くのがめんどくさくて、使わなくなるんだよね。Slackから打刻できたらいいのに」
とフィードバックをもらいました。
私もドッグフーディング中にそのことは思っていたので、「ほなやったろやないかい」とSlackAppを開発しました。
めちゃくちゃめんどくさかったし大変でしたが、エンジニア向けサービスのクライアントは全部SlackAppにする方がいいのでは?と少し思ったりしました。エンジニアはみんなSlack大好きでしょう。
結果的にはSlackAppの知見も得られたのでやって良かったと思っています。
NextでSlackAppを作ってVercelにデプロイする方法は日本語の記事がなかったのでそのうち記事にするかもしれません。
開発メンバーを増やした話
アプリケーションはある程度完成したのですが、、、
使ってもらうためにLPを作ったり、プラポリ、利用規約などの法律文書を作ったりするのがめっちゃ苦手です。
というかコード書く以外のことを基本的にしなくない人間なので、1ヶ月くらいリリースせずに放置していていたんですよね。
そんな時にココカラ勉強会の交流会に参加しました。そこでデザイナー出身のエンジニアのAkariさんとお話しする機会があり、「仕事暇なんですよねー」と言っていたので、今Webアプリケーションを作っているんですが、LP作ったり、色々手伝ってくれませんか?とお誘いしました。(もちろんお金を払っています。)
Akariさんが参加してくれて
- 放置気味だったカドレコも無事リリースできた
- 進めれる。やる気が出る。というかやらなきゃ的な意識になる
- SES系のフリーランスエンジニアとして人を雇う側の気持ちがなんとなくわかる
- アプリケーションの説明や今後のどうしていきたいかなどを話ししているうちに考えがまとまる(壁打ち相手ができる)
- アプリケーションの感想がもらえる
- アイデア出してもらえる
- LPとかロゴとか作るのが苦手なことをやってもらえる
などいいことがたくさんありました。カドレコの名前もAkariさんのアイデアから命名しています。
自分の苦手なことで詰まってアプリリリースまでできない系個人開発者の方は、誰か協力者を探して一緒にやるのがめちゃくちゃおすすめです。多少お金を払っても多分プラスになると思います。
これからも一緒に頑張っていきたいです。
おわりに
最後まで読んでくださってありがとうございました!
今後は稼働を記録できるだけでなく、
- 稼働時間をベースに請求書を発行できる機能
- 打刻漏れを防ぐための「そろそろ稼働時間ですけど、打刻してくださいよ」的な通知機能
- クライアント指定のスプレッドシートフォーマットがある時に、いい感じで貼り付けできるようにコピーする機能
などを追加して、稼働記録して、稼働時間を計算して、請求書を発行してという月末の請求書作業を簡略化できるアプリケーションにしていきます!
少しでも興味ある方、使っていただけたらめちゃくちゃ嬉しいです!
感想、フォロー、コメント、シェアなどしていただけたらめちゃくちゃ喜びます!
応援よろしくお願いします!
Discussion