動いている仕組みを、なぜわざわざアプリに作り替えたのか ― 現場管理アプリ「デズラ」の設計判断

これは、うちの本業であるAmazon・ECとは少し違う事例です。知人（建設業の親方）の「出面（でづら）管理」を、現場管理アプリ「デズラ」（dezura.site）として作り直し、いまも私が運用しています。
先に言うておくと、これは「導入したら〇〇が△分になりました」という成果自慢の記事やありません。もともとはスマホのメモで現場ごとに管理していたものを、まず表計算シート（Googleスプレッドシート）と、そこに書ける簡単な自動処理で仕組み化して、それなりに回る状態にしていました。それでも専用アプリへ作り替えたのは、なぜか――どんな手札を並べて、なぜその設計にしたのか。考えた中身をそのまま書きます。

1. 出発点：メモ管理を、まず私たちがスプレッドシートで自動化した

声をかけてくれたのは、建設の現場を持つ知人でした。「現場の出勤管理が手間だ」という話で、当時は 現場ごとに、スマホのメモ帳で人の出入りを書き留めている状態。手元では分かっても、締めや集計はすべて手作業でした。

それで私がまず作ったのが、表計算シートと、そこに書ける簡単な自動処理（決まった作業をひとりでにこなす短い命令書のようなもの）を組み合わせた仕組みです。

誰が・どの現場に・何日出たかを表計算で記録する
締め日が来たら、その期間ぶんを一枚のPDFに自動でまとめる
できあがったPDFを、指定したメールアドレスへ自動で送る

これで「手書きを集計する」手間はなくなって、いったんは業務が回る状態になりました。 ――普通ならここで「解決」です。でも次に頭に浮かんだのは、「便利にはなった。 けど、このまま人や現場が増えても回るんかな？」でした。

2. 「動く」と「続く」は別だ、という気づき

はっきり気づいたのは、別の親方から「うちのぶんも、もう一枚シートを作ってほしい」と言われたときでした。やろうと思えばできます。でもそこで手が止まりました。人が増えるたびにシートを足していくやり方は、すぐに管理しきれなくなるな、と。ほんまの課題は「手間」やなくて、増えても続けられる構造になっていないことでした。

① 増やすと破綻する

親方や現場が増えるたびにシートを足す方式では、すぐに管理しきれない。今後ほかの人に頼まれたときに、広げていく余地がない。

② 現場ではスマホが主役

スプレッドシートは事務所のPC前提。現場で働く人がその場でスマホからサッと記録する、という形になっていない。

③ 業界特有の事情

「人工（にんく）」という単位や、月末でない締め日など、既製の枠に収まらない部分を手作業で吸収していた。

「いま動いているか」と「人が増えても、誰でも回せるか」は、まったく別の問いやと思ってます。私が見ていたのは後者でした。シートを足し続けるより、誰が来てもスマホで使えて、増えても破綻しない土台に変えることが本題やった。

3. 手札を全部出して、却下理由まで言葉にする

課題が「増えても続けられる形にする」やと分かれば、打ち手は一つやありません。いきなり「アプリ作りましょう」とは言わずに、まず選べる手札を全部並べて、それぞれの向き・不向きを正直に書き出しました。

手札	向いている点	向いていない点（正直に）
案A 既製の勤怠管理サービス（月額で借りて使うネットサービス）を入れる	○ すぐ使える／自分たちで作らなくていい	× 「人工」「特殊な締め日」「元請へ書類送付」など建設特有の流れに合わない。機能が多すぎて現場が迷う
案B いまの表計算を改良し続ける	○ 慣れた形のまま／追加の費用が小さい	× 一番の課題＝増やしても回る形にならない。スマホで現場入力にするのも無理がある
案C 専用アプリを作る	○ この現場の事情ちょうどに作れる／運用もうちで引き受けられる	× 作る手間・時間がかかる。作った側が運用責任を負い続ける

選んだのは案C（専用アプリ）でした。決め手は、課題が「機能不足」やなくて「業界特有の流れと、人や現場が増えても続けられるかどうか」やった点です。そこは既製品では埋まらんし、表計算の改良でも解けない。だから作る、と決めました。同時に「作る手間と運用責任はうちが背負う」という案Cの弱点も、最初から引き受ける前提で進めています。 都合の良い面だけで選ばない。これは自分に言い聞かせてることでもあります。

4. なぜその設計を選んだか（4つの判断）

アプリを作ると決めてからは、「何を載せるか」より「何を載せないか」にいちばん時間を使いました。現場の人が毎日さわるものは、単純なほど続くと思ってます。代表的な判断を4つ書きます。

判断① ログインは「LINEだけ」。専用パスワードは作らない

パソコンやスマホに慣れてない方ほど、「新しい会員番号とパスワードを覚える」の段階でやめてしまいます。なので普段使ってるLINEでそのまま入れる形にしました。おまけで、自前でパスワードを預からんぶん守るものが減って、安全面でも楽になります。

判断② 「メニューを開かない前提」で日常を回す

締め日のお知らせや明細は、LINEのメッセージで届きます。ボタンを押したらその画面に直接着地して、終わったらLINEに戻る。「アプリを開いて、メニューを探して……」という動きを、日常からほぼ無くしました。下は、実際のリッチメニュー（LINEの画面下にいつも出ているボタン一覧）とお知らせの考え方を、ごく簡単な絵にしたものです。

現場の公式LINE

タップで完結するメニュー

🕒

出面入力

🧾

経費入力

📅

出勤履歴

💬

お問い合わせ

締め日が近づくと届くお知らせ（イメージ）

まもなく締め日です

今期ぶんの出面がそろっているか、ご確認ください。
ボタンから、そのまま書類づくりに進めます。出面をまとめる →

※ 見た目はイメージ。実物は dezura.site をご覧ください。

判断③ 入力は「その場で1回だけ」。写真からも拾えるように

事務所に戻ってまとめて打ち直すのをやめて、現場で起きたその場で、画面を1回押すだけで記録できる形にしました。手書きのメモは写真からも読み取れるようにして、「同じ数字を何度も書き写す」作業そのものを設計から消すのを狙っています。書き写しは、必ずどこかで間違うので。

判断④ ただの勤怠ではなく「損益が見える」道具にする

一つの出勤記録は、見方を変えると2つのお金につながります。取引先へ請求する金額（売上)と、働いた人へ支払う金額（原価）です。この2つを同じ記録から扱えるようにして、ただの「出欠の記録」やなく「いくら残るか」が見える道具にしたかった。出面管理を、そのまま経営の数字につなげたかったんです。

5. いまの正直な状態

ほんまは、ここで成果の数字を並べたい。でも出しません。理由は二つあります。

デズラはまだ、最初の知人ひとりの現場を、丁寧に支えている段階やからです。横展開はこれから少しずつ始めるところで、「広く成果が出た」と言える段階やありません。
私が見てるのは時短の分数やなくて、「使い続けてもらえているか」の一点だからです。途中で使われへんようになった仕組みは、どんなに高機能でも失敗やと思ってます。

決まってないことも正直に書きます。たとえば「親方自身が現場に出たときの取り分をどう計算・表示するか」「取引先（元請）側にどこまで見せる画面を用意するか」は、 まだ設計を確定させていません。実際に使う方や同業の声を聞いてから決める、というやり方にしています。言葉にするなら、「まず1人に深く向き合って、満足してもらってから、その満足ごと次の人へ広げる」。地味です。笑　でも、いまはこれでいこうと思ってます。

6. 業種を問わない「作り替え」の型

これは建設の話ですが、考え方はどの業種でも同じやと思ってます。「すでに動いている仕組みを、続く形に作り替える」ときに私がたどっている手順を、型としてまとめます。

「動いている＝直さなくていい」を一度疑う

回っていても、特定の一人に依存していたり、後任に渡せなかったりしたら、それは弱い構造やと思ってます。まず「来年も、別の人でも回るか」を自分に聞きます。

課題を「手間」から「構造」へ言い換える

「面倒」の正体が、増えても回らんことなのか・現場で使えないことなのか・業界特有の事情なのかを切り分けます。打ち手は、この言い換え方でほぼ決まります。

手札を全部出し、却下理由まで書く

既製品・改良・自作――選べる道を並べて、それぞれの不向きまで言葉にします。良い面だけで選んだときほど、後で後悔しました。

「何を載せないか」で設計する

毎日さわる人を基準に、要らない機能は削る。覚えることを減らして、「迷わず終わる」状態をいちばん上に置いています。

運用と改善は、作った側が引き受ける

「導入して終わり」にすると、現場に新しい負担が残るだけです。日々の運用やちょっとした手直しはこっちが背負って、相手には本業に集中してもらう。そこまでやって仕組みやと思ってます。

「いまのやり方、回ってはいるけれど不安」という方へ

特定の一人に依存している。現場で使いにくい。既製のサービスが業界の事情に合わない。同じことで困ってる人がいたら、まず今の状態を聞かせてください。
高機能な道具を売り込むんやなくて、そもそも作り替えるべきかから一緒に考えます。

LINEで相談する

動いている仕組みを、なぜわざわざ作り替えたのか 現場管理アプリ「デズラ」で考えた、設計の判断