Kon's DX Lab - Case Study

Day 34|MyHoursのUIに学ぶ。「継続できる」人時記録のための大事な一歩

Published on 2025-05-05

🔬 Case Study Summary
Problem

(ここに課題を記述)

Result

(ここに具体的な成果を記述)


Tech & Process

(ここに採用技術とプロセスを記述) コードを詳しく見る »

こんにちは、こんです🦊
今日は「人時記録の継続性」をテーマに、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インスパイア
#記録文化