こんにちは、こんです🦊
今日は「人時記録の継続性」をテーマに、UIとデータ設計の両面から見直しを行いました。
💥 事件発生:「UNKNOWN」なentry_idが大量発生!?
昨日の時点では「複数行入力フォーム」からの記録がうまくいっていました。
ところが、今朝から記録されたデータの中に、こんなentry_idが出現し始めたのです。
CopyEdit
20250505_UNKNOWN_UNKNOWN_UNKNOWN_03
何が起きたのか?
🔍 原因:IDではなく“表示名”をもとに検索していた
原因は、「フォームから送信される値」がIDではなく名前だったにもかかわらず、スクリプト側でID検索を行おうとしていたことにありました。
js
CopyEdit
const memberId = getId(entry.member, members, 3, 0); // ← 名前を前提にした検索
フォームとスクリプトの「データのつなぎ方」がずれていたことで、
意図しない UNKNOWN なIDが発生していたのです。
🛠 今日の修正:IDベースのフォーム構造に切り替え
この問題を解消するため、次の2点を修正しました。
✅ 1.フォーム側で「valueにID」を設定する
html
CopyEdit
<option value="M0001">山田 太郎</option>
✅ 2.スクリプト側で「そのままIDを使う」よう変更
js
CopyEdit
const memberId = entry.member; // すでにIDが来ている前提に統一
この変更により、entry_idは必ず正しいID構成(20250505_M0001_P0003_C002_01 のような形式)で生成されるようになりました。
✨ 教訓:シンプルでズレない設計こそ、継続の味方
いくら機能を増やしても、
いくらUIを整えても、
「正しいデータが記録されない」なら、意味がありません。
今回のような「マスタ連携ミス」は、DXではつきもの。
でも逆に、ID設計をきちんと整えるだけで安定性が飛躍的に上がることも、改めて実感できました。
🚀 明日以降の改善
フォーム初期値の「未選択状態」明示
氏名の自動入力(ログインベース)対応
時間入力支援UI(15分刻み+現在時刻ボタン)追加
🧠 今日のまとめ
「データが壊れない」ことは、記録文化の前提条件。
正しいID設計こそ、仕組みの柱である。
明日は「見える化」のためのヒートマップ分析に着手予定です!
#100日チャレンジ
#人時管理
#UIUX改善
#GoogleAppsScript
#業務改善
#DX実験記録
#MyHoursインスパイア
#記録文化