09. 未対応・保留とバグ候補¶
バグ候補¶
仕様書を書く過程で、コード同士の食い違い・テストと実装の食い違い・ 仕様として不自然な挙動を見つけたものを並べます。
原則として、見つけても執筆中には直しません。 仕様書を書いている最中にアプリの動きを変えると、 「何に合わせて書いたのか」が分からなくなるためです。 直す／直さないの判断をもらってから対応します。
修正済み¶
| # | 見つけた場所 | 症状 | 直し方 |
|---|---|---|---|
| B-01 | お仕事詳細「JOB コピー」の説明文 | **公開状態** とアスタリスクがそのまま出ていた |
記号を取り除いた。画面はただの文字列として表示するため、文章に Markdown の記法を書いてはいけない |
| B-02 | 勤怠「無断欠勤を取り消す」の確認ダイアログ本文 | **打刻前の状態** と同様に出ていた |
同上 |
| B-03 | お仕事詳細の「勤務時間」 | 09:00:00 〜 17:00:00 と秒まで出ていた |
整形関数 formatTimeRange を通して 09:00〜17:00 にした |
| B-04 | S-08 アカウント設定 | カナ欄のラベルが セイ / メイ なのに、エラーは 姓カナは必須です / 名カナは必須です と出ていた | ラベルを 姓カナ / 名カナ に揃えた。ほかの画面と同じ呼び方になる |
| B-05 | S-04 予定確認 ／ C-11 応募管理 | 勤務日を過ぎた未確定の応募が「応募中」に残り続けていた | 保存している状態は変えず、表示で分けた。スタッフ側は「過去」タブへ移して 期限切れ（未確定）、クライアント側は 勤務日を過ぎています を添える |
| B-06 | 勤怠の「休憩中」 | 到達できない状態と、常に空の値から休憩時間を計算する処理が残っていた | 画面から状態表示と計算処理を削除。DB の列と選択肢は残す（下の「使われていない項目」を参照） |
| B-07 | C-13 スタッフ管理 | 説明文が 自テナントに所属するスタッフの一覧 のままで、実態（選択中の事業所のみ）と違っていた | 説明文を 選択中の事業所に所属するスタッフの一覧 に直した |
| B-08 | X-02 トップページ | / が開発の雛形のページのままだった | URL のサブドメインで出し分けるよう作り直した。雛形のロゴ・英語の文言・外部リンクは削除 |
| B-09 | X-01 招待からのスタッフ登録 ほか | 同じ項目の呼び方が画面ごとに違っていた | 姓カナ 名カナ 口座名義 翌月 パスワード（確認） に統一。主な項目のラベルを lib/constants/fieldLabels.ts にまとめ、ばらつきを検査で止めるようにした |
修正は main の 2467e65（B-01〜B-03）、59cf72b（B-04〜B-06）、
d9ba19f（B-07〜B-09）で行いました。
B-09 で横断して見つかったばらつき¶
カナだけでなく、次も揃っていませんでした。エラー文言は項目名を含むため、 ラベルがばらつくとエラーの呼び方までずれます。
| 揃える前 | 揃えた後 |
|---|---|
姓 (カナ) / 姓カナ |
姓カナ |
名 (カナ) / 名カナ |
名カナ |
口座名義 (カタカナ) / 口座名義 |
口座名義（カタカナである旨は説明文で伝える） |
次月 / 翌月 |
翌月 |
パスワード (確認) / パスワード（確認） |
パスワード（確認） |
B-05 を直すときに確認したこと（挙動は変えていません）¶
勤務日を過ぎた未確定の応募を、クライアントは確定できます。
確定の処理（confirm_application）が見ているのは次の 3 つだけで、
勤務日も応募の締切も見ていません。
- 応募が「応募中」であること
- そのスタッフが同じ時間帯の別のお仕事で確定していないこと
- 募集人数の上限を超えないこと
そのため、たとえば 1 か月前の勤務日の応募でも、いま確定すると 確定済みになり、打刻の入れ物まで作られます。 今回は表示だけを直し、この挙動はそのままにしています。
使われていない項目（B-06 の残り）¶
| 項目 | 状況 |
|---|---|
AttendanceLog.status の break（休憩中） |
この値になることはありません。画面には出しません |
AttendanceLog.break_start / break_end |
常に空です。書き込む処理がありません |
残してあるのは、消すとデータベースの作り替えが要るためです。 将来の機能 に記録しています。
B-03 を直すときに分かったこと¶
時刻を返す API には 2 種類あり、素のまま表示してよいかが画面ごとに違う 状態でした。
| 返し方 | 使っている場所 | 例 |
|---|---|---|
HH:mm に整えて返す |
スタッフ向けの一覧・詳細・当日の打刻、予実管理 | 09:00 |
| モデルの値をそのまま返す | お仕事の一覧／詳細（共通の変換） | 09:00:00 |
横断で探したところ、次も見つかったので一緒に直しました。 写しが散っていると、片方だけ直し忘れるためです。
- 整形せず素のまま出していた箇所が 4 つ（スタッフの打刻・検索・検索詳細、予実管理）
- 同じ切り詰め処理（
slice(0, 5)）の写しが 4 つ（応募管理・カレンダー・クライアント勤怠・スタッフ予定） - コピー先の日付の案内が
2026-10-13と、表記ルール（YYYY/MM/DD）から外れていた
再発しないよう、frontend/lib/utils/uiText.test.ts を追加しました。
画面のソースを走査し、(1) 文字列の中の ** (2) 整形しない時刻の表示
(3) 時刻の slice(0, 5) を見つけたらテストが落ちます。
未判断¶
いまのところありません。仕様書を書く過程で見つかった 9 件は、 すべて判断をもらって修正済みです。
将来の機能¶
| 事項 | 内容 |
|---|---|
| 休憩の打刻 | 「休憩を始める／終える」操作はありません。勤怠の 休憩中 という状態と、休憩の開始・終了を入れる場所だけがデータベースに残っています。作るときは、画面の状態表示（lib/constants/status.ts）と、スタッフの打刻画面の分岐を戻してください。いまは休憩時間を手入力で記録します |
| 限定公開の通知 | C-05 お仕事詳細 の「通知を送る」は、送った日時と人数を記録するだけです（JobVisibilityScope.notification_sent_at / notification_sent_count）。メールもアプリ内の知らせも届きません。画面には {人数}名に通知を送信しました と出るため、届いたと誤解されます。作るときは 08 メール に送信のきっかけを足してください |
| 前払い申請 | S-07 マイページ にメニューだけあり、準備中 のしるしが付いています |
まだ決まっていないこと¶
| 事項 | 状況 |
|---|---|
| 年齢・性別による公開の制限 | 法令の確認待ち。仕組み（限定公開の条件）は用意済みですが、運用に乗せる判断は保留 |
| デザイン改善案 r42（スタッフ一覧から招待を送る） | 仕様の確認待ち |
| デザイン改善案 r47（招待メールの一括送信） | 仕様の確認待ち |
| 管理画面の求人一覧 | 未着手 |
保留している作業¶
| 事項 | 状況 |
|---|---|
| 本番環境まわり（検証環境の構築、構成管理の整理、データベースの作り直し、リリース手順の変更） | すべて保留。まず今のコードが正しく動くことを優先する方針 |
既に分かっている弱点¶
| 事項 | 内容 |
|---|---|
| メールアドレスの登録有無が、ログインしなくても分かる | GET /api/users/check-email/ は誰でも呼べて {あるかどうか} を返します。氏名などは返しませんが、総当たりすれば「このサービスに登録しているか」を外から調べられます。招待の受諾とアカウント発行で必要なため、塞ぐと使い勝手が壊れます。回数制限をかける／招待リンク付きの経路に寄せる、などが対応案です |