交通費申請は、どの会社にもある業務です。

売上を生むわけではない。

でも、必ず毎月発生する。

だからこそ、その設計思想は組織の姿勢を映します。

aciassでは交通費申請をGoogle Drive + Spreadsheetで運用していましたが、

今回、Slack完結型の仕組みに刷新しました。

単なるツール変更ではなく、

「業務のUX」と「組織構造」の見直しでもありました。

Drive運用は“間違っていない”

以前の運用は、よくある形でした。

• テンプレートになっているSpreadsheetに入力し、PDFとしてダウンロード
• 証憑とともに定められたフォルダにアップロード
• 経理が確認

仕組みとしては成立します。

ただ、いくつかの小さな摩擦がありました。

• フォルダを探す手間が発生
• PC前提の作業内容となっている
• 承認状況が曖昧

一つ一つは小さい。

しかし、積み重なると地味にストレスになります。

交通費申請は“社内プロダクト”である

交通費申請は裏方業務ですが、従業員にとっては毎月触るUIです。

ここが不親切だと、会社は“面倒を放置する組織”に見えてしまいます。

逆に整っていれば

• この会社は設計する
• 無駄を減らそうとする
• 仕組みで解決する

という印象になります。

プロダクトを作る会社である以上、

社内業務もプロダクトとして扱うべきだと考えました。

なぜSlackに寄せたのか

きっかけは、従業員からの率直なフィードバックでした。

「交通費申請がPC前提のフローになっていて、正直めんどくさいです」

Drive＋Spreadsheetの運用は、基本的にPC作業を想定しています。

• 外出先では入力しづらい
• スマホからだと操作性が悪い

申請のタイミングになって、わざわざそのためだけにPCを開くなんていうこともありえます。

一方で、Slackは日常的に開いているツールです。

PCでもスマホでも常にアクセスされている。

それなら、

• 申請作成
• 証憑アップロード
• 履歴確認
• 承認

までをSlack上で完結させたほうが、導線として合理的です。

今回のシステムは、Slackアプリとして実装しました。

「一番使われている場所に寄せる」というだけですが、業務フローの摩擦はこのレベルの設計で大きく変わります。

技術的な設計思想

構成はシンプルですが、思想は明確にしました。

• フロントはSlack Block Kit
• バックエンドはLambda（Node.js）
• データはDynamoDB Single Table設計
• ファイルはS3
• 重い処理はSQS経由で非同期化
• 帳票PDFはPuppeteerで生成

いわゆる“サーバーレス構成”です

重要だったのは技術選定よりも、状態をどう整理するかでした。

月次ステータスという“線”を引いた

今回の改善で一番大きかったのは、月次単位でステータスを管理する設計です

• draft
• submitted
• approved

この“線”を引いたことで、

• 下書きの月は自由に編集できる
• 提出後は変更できない
• 承認されたら確定

という構造が自然に成立します。

Spreadsheet運用では曖昧になりがちな部分を、明確な状態遷移にしました。

これは単なる技術設計ではなく、「どこまでが自由で、どこからが確定か」という組織の線引きでもあります。

非同期処理で“待たせない”

証憑アップロードやPDF生成は時間がかかります。

そこで、SQSを挟み非同期処理にしました

• ユーザーは待たされない
• 重い処理は裏で実行

体験としてはシンプルですが、裏側では疎結合な設計になっています。

技術的には王道ですが、“業務の待ち時間を減らす”という思想が主目的です。

組織論的に見えたこと

今回の変更で強く感じたのは、曖昧さは摩擦を生むということでした。

Drive運用は悪くない。

ただ、状態や責任の所在がぼやけやすい。

• 誰が承認したのか
• どの状態なのか
• いつ確定したのか

これが明確になるだけで、余計な確認コミュニケーションが減ります。

つまり、摩擦が減る。

“自由”には枠が必要

Slackで完結させたこと以上に重要だったのは、

• どこまで編集できるのか
• いつロックされるのか
• 誰が承認するのか

を構造として定義したことでした。

フラットな組織であっても、判断は必要です。

線を引かない自由は、結局は迷いになります。

交通費申請という小さな業務でも、組織の構造はにじみます。

経営と構造

経営は、大きな戦略だけでなく、

• 小さな摩擦を減らすこと
• 状態を明確にすること
• 説明可能な構造をつくること

の積み重ねだと思っています。

今回の交通費申請刷新は、技術的には小さなプロジェクトです。

しかし、

• Single Table設計
• 非同期アーキテクチャ
• 状態遷移の明確化
• Slack中心のUX設計

といった要素は、

プロダクト開発と同じ思想で作りました。

まとめ

DriveからSlackに変えたのは、

ツールの問題ではありません。

• 業務をプロダクトとして扱う
• 摩擦を設計で減らす
• 曖昧さを構造でなくす

という姿勢の問題です。

交通費申請は地味なテーマです。

でも、こういうところにその会社の思想が出ます。

aciassは、小さな業務でも“設計する組織”でありたいと考えています。