21世紀の宇宙旅行はDXで
안녕하신게라！パナソニックコネクト株式会社クラウドソリューション部の加賀です。
皆さん、DXしてますか？
「その手作業、自動化しようぜ！」「もうExcelで管理する時代じゃない！」
我が社でもそんな威勢の良い掛け声のもと、聖域なき業務改革のロケットを打ち上げるプロジェクトが発足しました。
今回お話するターゲットは、毎月発生するクレジットカードの費用処理。
秘伝のタレ.xlsmを毎月祈りながら使う前時代的な業務を、モダンな技術で華麗に自動化する。
そう、我々はExcelという惑星の重力を振り切り、輝かしいSaaSという星系へ旅立つ、
はずでした。
これは、壮大なDX宇宙旅行に挑みながらも大気圏に再突入して不時着した、しがない情シス担当の物語。アドベントカレンダーには輝かしい成功談が多いからこそ、こういう失敗談からの学びがあっても良いはずです。そうじゃないですか？
打ち上げ準備 〜我々が目指した理想の軌道〜
【As-Is】レガシーという名の地上
毎月、カード会社から全銀フォーマットとほぼ同等の形式で、謎のデータファイルが送られてきます。（CSV？それは別の星の文明ですね）
情シスが専用の古のツール（社内でZ-EDIと呼ばれています）でファイルを受信し、担当者がアクセスできるフォルダに配置します。
担当者はそのファイルを基に、Excel管理簿の秘伝マクロで処理された結果を、必死に検算していました。
月末の経理報告や部署への請求処理は、すべてが担当者による手作業と汗と努力と少しのお祈りによって成り立っていました。
文字通り「秘伝のタレ」と「神頼み」が支配する世界。ミスは頻発し、月末の担当者はいつも死んだ魚のような目をしていました。
【To-Be】自動化という名の銀河へ
我々が描いた理想の航路はこうです。
- カード会社のAPIを叩いて明細データの自動取得！（モダン！）
- クラウドETLツールやAWS Lambda/Google Apps Scriptでデータ自動加工！（ローコード！）
- 経理報告用のCSVと、請求処理用のデータを自動生成！（ノーコード！）
- 担当者はTeams通知を確認して、承認ボタンをポチるだけ！（DX！）
完璧な計画でした。この計画なら、惑星Excelの引力圏を脱出する第二宇宙速度（秒速11.2km）を遥かに超える推進力が得られると信じていました。
マルチフォーマットレコードの洗礼
しかし、我々の航路には、予測不能なアステロイドベルト（小惑星帯）が広がっていました。
まず、データソースそのものが最初の壁として立ちはだかります。
カード会社「データ取得は全銀手順（TCP/IP手順）のみです」
弊社「（絶句）」
カード会社「……え？ API？ なにそれ美味しいの？」
弊社「（白目）」
この時点で、モダンなクラウドサービスとの直接連携は絶望的。我々のDXロケットは、離陸前にいきなり燃料漏れを起こしたのです。
さらに、毎月受信しているデータファイルの中身を見て、我々は文字通り言葉を失います。（COBOLやってる方にはごく普通のことだと思いますが）
100120231026ｶ)ｳﾁｭｳﾘｮｺｳｼｮｳｼﾞ... (データ区分'1'：ヘッダレコード)
2A012023102510000ｳﾁｱｹﾞ ﾋﾖｳ... (データ区分'2'：明細レコード)
2B03202310265000ﾈｯﾄﾜｰｸ ﾘﾖｳ... (データ区分'2'：明細レコードでも種別でレイアウトが違う)
90000000015000... (データ区分'9'：トレーラレコード)
それは、ただの固定長ファイルではありませんでした。
行の先頭1バイト（データ区分）によって、後続のデータ区切り位置（レイアウト）が変化する、通称「マルチフォーマットレコード」と呼ばれる代物だったのです。
データ区分 1 なら「会社名が30byte、作成日が8byte…」
データ区分 2 で、かつ種別コード A なら「金額が10byte、摘要が20byte…」
データ区分 2 で、かつ種別コード B なら「金額が8byte、利用店コードが4byte、摘要が18byte…」
まるで、近づくたびに形を変えるアステロイドのようです。
小宇宙（コスモ）を燃やしてパースするロジックを考えてこその闘士（エンジニア）です。
古くからShift-JIS(CP932)で半角カナが使われているのは、1文字で1バイト扱いが出来るからです。現代では、文字列をUTF-8で取り扱うのが一般的となりましたが、ここではあえてUTF-8に変換せず、いわば寝た子を起こさず、バイト列のまま処理するのが良さそうです。
def parse_ancient_record(line):
record_type = line[0]
if record_type == b'1':
# ヘッダのパース処理
company_name = line[1:31].decode('shift_jis')
...
elif record_type == b'2':
detail_type = line[1:3]
if detail_type == b'A01':
# 明細Aのパース処理
amount = int(line[3:13].decode('ascii'))
...
elif detail_type == b'B03':
# 明細Bのパース処理
amount = int(line[3:11].decode('ascii'))
...
# 以下、個別の取得処理が続く
そんな折、Excel管理簿の秘伝マクロの一部に、上記とまったく同じようなVBAコードがあるのを発見してしまいます。
Access圏への不時着
API連携の夢は砕け散り、社内各部署との調整も難航し、プロジェクトの予算とスケジュールは刻一刻と過ぎていきます。
我々に残された選択肢は多くありませんでした。
「…もう、ExcelとAccessでよくない？」
誰かがつぶやいたその一言は、宇宙船の酸素供給を止めるに等しい絶望的な響きを持ちつつも、乗組員たちに不思議な安らぎを与えました。もうゴールしても良いんだよ、と。
最終的に我々がたどり着いた（不時着した）場所は、以下の通りです。
- 全銀手順で受信した謎ファイルをパースするExcel管理簿の秘伝マクロを改修し、そこからAccessのテーブルに流し込むSQLを実行する（この一点だけはDXへの熱意が残っていた）
- 【内部の請求処理】 担当者はAccessを直接開き、部署ごとの請求データを確認・処理する
- 【経理報告】 担当者はAccessクエリから取得したCSVをExcelで報告する（←結局Excel！）
…お分かりいただけたでしょうか。
我々は「脱Excel」を掲げながら、Accessデータベースという馴染み深い星系に漂流してしまったのです。UIや事務処理はAccess上に移動したものの、出力されたCSVデータを取り扱うのは、結局使い慣れたExcel。
これは脱出ではなく、せいぜい地上から少しだけ浮き上がって周回軌道に乗っただけ（第一宇宙速度）に過ぎません。Excel重力圏を抜ける第二宇宙速度には遠く及びませんでした。
不時着から見えた、次の航路
なぜ、我々はExcelの引力を振り切れなかったのか。
敗因を分析すると、身も蓋もない結論に至ります。
「費用対効果が見合わなかった」
結局のところ、この処理は毎月1回しか発生しません。
全銀手順やマルチフォーマットレコードというレガシーな手順を乗り越え、完全なWebアプリやSaaS連携まで作り込むほどの燃料（予算・工数）は、月イチ業務には見合わないと判断されました。
「Accessにデータが入れば請求処理は楽になるし、経理報告もボタン一つでCSVが出るなら、それで十分じゃない？」
経営層と現場の、ごもっともな判断でした。
DXロケットの燃料は有限です。月イチ業務の完全自動化という、あまり輝いて見えない星を目指すより、もっと頻繁で効果の大きい業務に燃料を投下すべきだ、という至極当然の結論でした。
この記事を書いている時点で、エンジニア視点での収穫もありました。現状、カード会社からのファイル授受に社内でZ-EDIと呼んでいるツール端末での処理が必須で、これが完全自動化の壁となっています。将来、この部分がAPI取得に変われば、Excel系JSライブラリ（MESCIUS社のSpreadJSやWijmoとか！）を活用してUIを移行し、VBAマクロだけをAWS LambdaやGASで実装することに注力すれば良い、という具体的な道筋が見え、少ない燃料で済みそうだという見立てを得たことは非ッ常に大きいです。
DX宇宙旅行は、目的地より航路が大事（かもしれない）
我々の「クレカ費用処理DX化」プロジェクトは、Excelの引力圏を脱出できずに終わりました。
しかし、この不時着から得られた教訓もあります。
- データソースという名の出発点をなめてはいけない
宇宙旅行の前に、まず発射台がどんな僻地にあるかを知るべきです。 - 完璧な100点より、そこそこの80点を早めに出す
限られたリソースで一定の効果を出すのが、企業内エンジニアリングの本質かもしれません。 - ExcelとAccessは、なんだかんだで地上最強のサバイバルキットであると再確認
どんな過酷でレガシーな環境でも、これらがあれば生きていけます。（DXが遠ざかる主因）
アドベントカレンダーを含め、これから「脱Excel」という壮大な旅に出る皆さんのロケットが、我々のように不時着しないことを、重力の井戸の底から祈っております。
お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。記事化するにあたり、社内事情をボカし、分かりやすさを優先するため、内容を一部脚色・簡略化しています。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。