動いている仕組みを、なぜわざわざ作り替えたのか 現場管理アプリ「デズラ」で考えた、設計の判断
業務改善コラム ／ 現場DX・業務アプリ ／ 読了目安：約9分
これは、私たちの本業であるAmazon・ECとは少し違う事例です。知人（建設業の親方）の「出面（でづら）管理」を、
現場管理アプリ「デズラ」（dezura.site）として作り直し、いまも私たちが運用しています。
ただし最初にお断りします。これは「導入したら〇〇が△分になりました」という成果自慢の記事ではありません。
もともとはスマホのメモで現場ごとに管理していたものを、まず私たちがスプレッドシートとGASで自動化し、それなりに回る状態にしていました。
それでも専用アプリへ作り替えたのは、なぜか――どんな手札を並べ、なぜその設計を選んだのか。私たちの考え方そのものをお見せします。
1. 出発点：メモ管理を、まず私たちがスプレッドシートで自動化した
相談をくれたのは、建設の現場を持つ知人でした。「現場の出勤管理が手間だ」という話で、当時は 現場ごとに、スマホのメモ帳で人の出入りを書き留めている状態。手元では分かっても、締めや集計はすべて手作業でした。
そこで私たちがまず作ったのが、スプレッドシートとGAS（簡単なプログラム）を組み合わせた仕組みです。
- 誰が・どの現場に・何日出たかを表計算で記録する
- 締め日が来たら、その期間ぶんを一枚のPDFに自動でまとめる
- できあがったPDFを、指定したメールアドレスへ自動で送る
これで「手書きを集計する」手間はなくなり、いったんは業務が回る状態になりました。 ――ここで普通なら「解決」です。でも私たちが次に立てた問いは、「便利になった。 でも、このまま人や現場が増えても回るんだろうか？」でした。
2. 「動く」と「続く」は別だ、という気づき
はっきり気づいたのは、別の親方から「うちのぶんも、もう一枚シートを作ってほしい」と頼まれたときでした。 やろうと思えばできます。でもそこで思ったのです。人が増えるたびにシートを足していくやり方は、すぐに管理しきれなくなると。 解くべき課題は「手間」そのものではなく、増えても続けられる構造になっていないことでした。
① 増やすと破綻する
親方や現場が増えるたびにシートを足す方式では、すぐに管理しきれない。今後ほかの人に頼まれたときの拡張性がない。
② 現場ではスマホが主役
スプレッドシートは事務所のPC前提。現場で働く人がその場でスマホからサッと記録する、という形になっていない。
③ 業界特有の事情
「人工（にんく）」という単位や、月末でない締め日など、既製の枠に収まらない部分を手作業で吸収していた。
「いま動いているか」と「人が増えても、誰でも回せるか」は、まったく別の問いです。 私たちが見ていたのは後者でした。シートを足し続けることより、誰が来てもスマホで使えて、増えても破綻しない土台に変えることが課題だったのです。
3. 手札を全部出して、却下理由まで言葉にする
課題が「増えても続けられる形にする」だと分かれば、打ち手は一つではありません。私たちはいきなり「アプリを作りましょう」とは言わず、 まず選べる手札を全部並べて、それぞれの向き・不向きを正直に書き出しました。
| 手札 | 向いている点 | 向いていない点（正直に） |
|---|---|---|
| 案A 既製の勤怠SaaSを導入 |
○ すぐ使える／自分たちで作らなくていい | × 「人工」「特殊な締め日」「元請へ書類送付」など建設特有の流れに合わない。機能が多すぎて現場が迷う |
| 案B いまの表計算を改良し続ける |
○ 慣れた形のまま／追加コストが小さい | × 一番の課題＝増やしても回る形にならない。スマホで現場入力にするのも無理がある |
| 案C 専用アプリを作る |
○ この現場の事情ちょうどに作れる／運用も私たちが引き受けられる | × 作る手間・時間がかかる。作った側が運用責任を負い続ける |
最終的に選んだのは案C（専用アプリ）でした。決め手は、課題が「機能不足」ではなく「業界特有の流れと、増えても続けられる拡張性」だった点です。 そこは既製品では埋まらず、表計算の改良でも解けない。だから作る、と決めました。 同時に「作る手間と運用責任は私たちが背負う」という案Cの弱点も、最初から引き受ける前提で進めています。 都合の良い面だけで選ばないことを、私たちはいつも大事にしています。
4. なぜその設計を選んだか（4つの判断）
アプリを作ると決めてからは、「何を載せるか」より「何を載せないか」に時間を使いました。現場の人が毎日さわるものは、単純であるほど続くからです。代表的な判断を4つ紹介します。
判断① ログインは「LINEだけ」。専用パスワードは作らない
ITに不慣れな方ほど「新しいIDとパスワードを覚える」で離脱します。そこで普段使っているLINEでそのまま入れる形にしました。 副次効果として、自前でパスワードを預からないぶん守るべきものが減り、安全面でも有利になります。
判断② 「メニューを開かない前提」で日常を回す
締め日のお知らせや明細は、LINEのメッセージとして届きます。そのボタンを押せば該当画面に直接着地し、操作を終えたらLINEに戻る。 「アプリを開いて、メニューを探して……」という動作を、日常からほぼ無くしました。下は実際のリッチメニューとお知らせの考え方を、ごく簡略にイメージにしたものです。
タップで完結するメニュー
締め日が近づくと届くお知らせ（イメージ）
ボタンから、そのまま書類づくりに進めます。 出面をまとめる →
※ 見た目はイメージ。実物は dezura.site をご覧ください。
判断③ 入力は「その場で1回だけ」。写真からも拾えるように
事務所に戻ってまとめて打ち直すのをやめ、現場で発生したその場で1タップ記録する形にしました。 手書きのメモなどは写真からも読み取れるようにし、「同じ数字を何度も書き写す」作業そのものを設計から消すことを狙っています。
判断④ ただの勤怠ではなく「損益が見える」道具にする
一つの出勤記録は、見方を変えると2つのお金につながります。取引先へ請求する金額（売上)と、働いた人へ支払う金額（原価）です。 この2つを同じ記録から扱えるようにして、単なる「出欠の記録」ではなく「いくら残るか」が見える道具を目指しました。出面管理を、経営の数字に直結させる狙いです。
5. いまの正直な状態
ここで成果の数字を並べたいところですが、あえて出しません。理由は二つあります。
- デズラはまだ、最初の知人ひとりの現場を、丁寧に支えている段階だからです。横展開はこれから少しずつ始めるところで、「広く成果が出た」と言える段階ではありません。
- 私たちが見ている指標は時短の分数ではなく、「使い続けてもらえているか」の一点だからです。途中で使われなくなった仕組みは、どんなに高機能でも失敗です。
決まっていないことも正直にお伝えします。たとえば「親方自身が現場に出たときの取り分をどう計算・表示するか」「取引先（元請）側にどこまで見せる画面を用意するか」は、 まだ設計を確定させていません。実際に使う方や同業の声を聞いてから決める、というのが私たちの進め方です。 あえて表現するなら、「まず1人に深く向き合い、満足してもらってから、その満足ごと次の人へ広げる」。地味ですが、これがいまの方針です。
6. 業種を問わない「作り替え」の型
この事例は建設の話ですが、考え方はどの業種にも当てはまります。「すでに動いている仕組みを、続く形に作り替える」ときに私たちがたどる手順を、型としてまとめます。
「動いている＝直さなくていい」を一度疑う
回っていても、特定の一人に依存していたり、後任に渡せなかったりすれば、それは弱い構造です。まず「来年も、別の人でも回るか」を問います。
課題を「手間」から「構造」へ言い換える
「面倒」の正体が、増えても回らないことなのか・現場で使えないことなのか・業界特有の事情なのかを切り分けます。打ち手は、課題の言い換え方で決まります。
手札を全部出し、却下理由まで書く
既製品・改良・自作――選べる道を並べ、それぞれの不向きまで言葉にします。良い面だけで選ばないことが、後悔しない選択につながります。
「何を載せないか」で設計する
毎日さわる人を基準に、要らない機能は削る。覚えることを減らし、「迷わず終わる」状態を最優先にします。
運用と改善は、作った側が引き受ける
「導入して終わり」にすると、現場に新しい負担が残ります。日々の運用やちょっとした手直しはこちらが背負い、相手には本業に集中してもらいます。
「いまのやり方、回ってはいるけれど不安」という方へ
特定の一人に依存している。現場で使いにくい。既製のツールが業界の事情に合わない。
そんな状態でしたら、まずは現状をお聞かせください。
高機能なツールを売り込むのではなく、そもそも作り替えるべきかから、一緒に考えます。