以前、Flask + SQLiteで「最速で作る勤怠管理MVP」の記事を書きました。
今回はその続きです。
打刻だけできる試作から一歩進めて、AIに実装を手伝ってもらいながら、勤怠一覧、月次集計、管理画面、ユーザー管理、さらに開発用のDEVツールまで追加してみました。
しかも、ここまでの土台ができるまでにかかった時間は30分足らず。
正直、かなり驚きました。
ただ、やってみて分かったのは、AIが速いこと以上に「どこを確認して、どこを直させるか」を人間が判断することの大切さです。
今回は、実際にどんな流れで勤怠アプリが育っていったのか、途中で出たエラーや修正ポイントも含めてまとめます。
以前作ったのは「最速で動く勤怠MVP」だった
以前の記事では、Flask + SQLiteでシンプルな勤怠管理システムを最速で形にすることを目的にしました。
出勤、退勤、休憩開始、休憩終了。
そして一覧表示やCSV出力まで含めて、「まず動くものを作る」ことを優先した構成です。
この時点でも学習用としては十分でしたが、実際に触ってみると、次の課題が見えてきます。
管理者向けの画面が欲しい。
ユーザー登録や編集ができない。
同じ日の再テストがやりづらい。
画面や構成をもう少し整理したい。
そこで今回は、AIに実装を手伝ってもらいながら、このMVPを少しずつ育ててみることにしました。
今回はMVPを「使いやすい形」に育ててみた
今回の狙いは、本番システムを作ることではありません。
学習用であり、ブログ用であり、デモとしても見せやすい形にすることです。
そのため、給与計算や法対応のような重い要素は入れず、次のような「アプリらしさ」が出るところを優先しました。
ログイン、打刻画面、自分の勤怠一覧、月次集計、管理者画面、ユーザー管理、開発用ツール。
このあたりが揃うと、ただの打刻サンプルではなく、「ちゃんとした小さな業務アプリ」に見えてきます。
30分足らずで追加できた機能
打刻画面
出勤、退勤、休憩開始、休憩終了の打刻に対応しました。
今日の勤務状態も画面上で分かるようになっていて、未出勤、勤務中、休憩中、退勤済みといった状態が見えるようになっています。
勤怠一覧
自分の勤怠を日付ごとに確認できる一覧画面も用意しました。
出勤時刻、退勤時刻、休憩時間、勤務時間、状態が並び、かなり見やすくなりました。
月次集計
月単位で勤務日数や総勤務時間を確認できる画面も追加されました。
打刻だけでは分かりにくい「1か月でどれくらい働いたか」が見えるのは大きいです。
管理者向け勤怠一覧
管理者は全体の勤怠を一覧で確認できます。
ユーザー名や対象月で絞り込めるので、簡単な管理画面として十分機能します。
ユーザー管理
今回かなり大きかったのがここです。
ユーザー一覧、新規登録、編集画面が追加され、表示名、権限、有効無効、パスワード再設定まで扱えるようになりました。
しかも、自分自身の管理者権限は外せない、最後の有効な管理者は無効化できない、という制御まで入っています。
このあたりは「動けばいい」では済まない部分なので、アプリとして一段階しっかりした印象になりました。
開発用DEVツール
一番おもしろかったのはこれです。
勤怠は1日1レコード前提なので、同じ日に何度も出勤からやり直したいときに困ります。
つまり、自然に再テストするには翌日を待つ必要があるわけです。
ここに対して、AIが開発用のDEVパネルを作ってきました。
本日の勤怠確認、日付指定の一括リセット、ユーザー指定のリセット、CLIからのリセット。
この機能があることで、待たずに何度でも検証できるようになりました。
これはかなり実用的でした。
実際に出たエラーと、どう切り分けたか
もちろん、一発ですべて完璧だったわけではありません。
Werkzeugが入っていなかった
最初に init_db.py を動かしたとき、Werkzeug が見つからないエラーが出ました。
これは仮想環境と requirements.txt の確認で解決しました。
CSV出力のルート名がずれていた
打刻は正常に動いていたのに、CSVボタンを押すとエラーが発生しました。
原因はテンプレート側の url_for() と、実際のルート関数名のズレでした。
ここは「打刻は成功している」「一覧にも反映されている」と切り分けられたので、CSV導線だけの問題だと判断できました。
リセット後の打刻でSQLエラーが出た
DEVツールでリセットした後に打刻すると、SQLの構文エラーが出る場面もありました。
ここは、更新処理に空の値を渡していた可能性と、そもそもリセット後の分岐が insert ではなく update に入っていた可能性を整理して見直しました。
管理画面は見えるだけでなく、URL直打ちも確認した
一般ユーザーに管理メニューが見えないだけでは不十分です。
実際にURLを直打ちしてもアクセスできないかまで確認しました。
この確認を入れておくと、見た目だけの制御ではないことが分かります。
一番おもしろかったのは「翌日まで再テストできない問題」が解決したこと
今回の開発で一番印象に残ったのは、打刻そのものよりも、開発のしづらさを解決する仕組みが自然に追加されたことです。
勤怠のように日付に依存するアプリは、テストのたびに翌日を待つわけにはいきません。
ここに対して、開発用だけのリセット画面やCLIツールが入ることで、かなり回しやすくなりました。
作るだけでなく、育てることまで含めて考えられていたのが面白かったです。
AIでアプリを作るときに、人間がやるべきこと
今回やってみて改めて感じたのは、AIはかなり速いということです。
ただ、その速さを価値に変えるには、人間側が次のことをやる必要があります。
どこまでできていて、どこが壊れているかを切り分けること。
表示の問題なのか、権限の問題なのか、保存の問題なのかを分けること。
危ない仕様を先に潰すこと。
本番用と開発用を分けること。
つまり、AIが全部やるというより、「人間が監督してAIを回す」感覚が近いです。
ここまで作って感じたこと
30分足らずでここまで形になったのは、やはりかなりインパクトがありました。
でも、本当に価値があったのは「速く作れたこと」だけではありません。
打刻だけで終わらず、一覧、集計、管理画面、ユーザー管理、DEVツールまで広がっていく中で、アプリが少しずつ「使える形」に育っていく感覚がありました。
最速で作るMVPも大事ですが、その次に何を足すとアプリらしくなるのか。
そこを体験できたのが今回の一番の収穫でした。
まとめ
AIでアプリを作ると、「こんなに早くここまで行けるのか」と驚く場面があります。
ただ、その速さを活かせるかどうかは、人間側の確認と整理にかかっているとも感じました。
今回の勤怠アプリは、打刻だけの試作から、管理機能や開発補助機能まで広がり、かなり学びの多い題材になりました。
「まずは小さく作って、AIと一緒に育てる」。
この進め方は、今後もいろいろな業務アプリで試していけそうです。
さいごに
もしこれからFlaskで小さな業務アプリを作ってみたいなら、勤怠管理はかなり良い題材だと思います。
フォーム、保存、一覧、集計、管理画面と、Webアプリの基本要素がひと通り入るからです。
今後は、この勤怠アプリをさらに整えながら、どこまで実務っぽく育てられるかも試していこうと思います。
