データ化エンジニアとしての1年を振り返る

■イベント
23新卒エンジニア 1年間の振り返りLT会
https://uniquevision.connpass.com/event/311006/

■発表者
Digitization部 Bill One Entry Group 清⽔勇祐

■Digitization部エンジニア 採用情報
https://media.sansan-engineering.com/digitization

Transcript

1. Sansan株式会社 部署 名前 データ化エンジニアとしての 1年を振り返る Sansan技術本部 Sansan技術本部 Digitization部 Bill One Entry Group 清⽔ 勇祐
2. 清⽔ 勇祐 Sansan株式会社 技術本部 Digitization部 Bill One Entry グループ 2023年にSansan株式会社に新卒⼊社し、データ化で事業を⽀える Digitization部にて請求書のデータ化システムの開発に従事。 dotfilesを愛でるのが⽣きがい。 { “editor”: “Neovim”, “terminal”: “Alacritty”, “language”: { “primary”: [“Typescript”], “dabbles”: [“Go”, “Lua”, “Python”, “Dart”] }
3. - プロダクトを通してデータ化の価値を提供している - クオリティー・コスト・デリバリー（QCD）のバランスにひたすら向き合う Digitization部とは？ 2
4. - 新規機能の開発だけでなくクオリティー改善やコスト削減など 運⽤的な側⾯も強い - その中でもメインで取り組んだ⽇付の表記揺れ対策について紹介 QCD改善 3
5. 請求書の⽇付はいろいろな形式で記⼊される - 全⾓or半⾓、⻄暦or和暦、アラビア数字or漢数字 などで表記が揺れる - 例）2024/3/19, 令和6年3⽉19⽇, ⼆〇⼆四年三⽉⼗九⽇ etc… - ⽇本式だけではなくUS式・UK式などもありえる - 例）19.3.2024, 3/19/2024, Mar 19 2024 - 表記ミスしている可能性もありえる - 例）2024年3⽉91⽇ 請求書の表記揺れ これらの表記揺れを吸収したい & 不正な⽇付は納品したくない
6. 10 12 2023 ⽇付フォーマットその1
7. - 与えられた情報だけではフォーマットを⼀意に決められない - US式(MM/dd/yyyy) → 2023年10⽉12⽇ - UK式(dd/MM/yyyy) → 2023年12⽉10⽇ - 別途現在の⽇時と照らし合わせて優先度判断する必要がある 正解 ⽇付フォーマットその1 10 12 2023 判別不能
8. 5年10⽉末⽇ ⽇付フォーマットその2
9. - ⽇本式だと判断できる場合和暦の可能性もある - 令和5年10⽉31⽇ ＞ 2005年10⽉31⽇ - 末⽇は⽉によって⽇にちが変わる 正解 ⽇付フォーマットその2 5年10⽉末⽇ 2023年10⽉31⽇（令和5年10⽉31⽇）
10. 29.2.2567 ⽇付フォーマットその3
11. - 仏暦で解釈できる場合そちらを優先する （仏暦2567年 = ⻄暦2024年） - 仏暦2567年は閏年なので2⽉29⽇は正しい⽇付として データ化できる 正解 ⽇付フォーマットその3 29.2.2567 2567年2⽉29⽇
12. - 仏暦は⻄暦+543年（仏暦2567年 = ⻄暦2024年） - 同じ仏暦でも国によっては更に1年ずれている*1 - 仏暦の閏⽇をDate型で単純にパースしようとすると不正な⽇付になる - 2567年2⽉29⽇ → 2567年3⽉1⽇ or Invalid Date (Error) - ⻄暦ではなく仏暦の情報を保持できるDate型があるといいが… - ⽇付として正しいかどうかの判断は個別に⾏う必要がある 仏暦の閏年 *1 釈迦入滅を0年とするか1年とするかの違い
13. - クオリティーだけでなくコストやデリバリーも改善点はある - Bill Oneを使えるユーザのキャパシティーはデータ化できる請求書の キャパシティーで決まる - 請求書をアップロードすれば完璧にデータ化されることを当たり前に 提供し続けられるようにQCDの改善を続ける さいごに
14. VSCode使いしかいないチームに新卒1年⽬のVimmerはどう馴染んだのか？ 興味のある⽅ぜひお話しましょう！ Appendix