Domínio Visualはスタートアップではない。看板業者だ。立体文字、ファサード、サインボード、屋内サイン。顧客が求めるのは架空のスプリントではなく、特定の日に現場に設置されている仕上がりだ。
本題はこうだ。現実のサービス業がExcelとノートとWhatsAppで指示をさばくのをやめ、自社仕様のデジタル基盤に移ったとき、何が起きるか。得るもの、失うもの、そしてほぼ必ず最初の試みでつまずく箇所。
エグゼクティブ・サマリー
サービス業には三つの慢性的な業務課題がある。各案件の実際の進行状況は複数の人間の頭に分散し、顧客履歴は会話の中に生き、請求は誰かの記憶に依存する。汎用ソフトはこれを解決しない。語彙がずれているからだ。解は、現場の実フローに沿って設計された基盤である。工程の物理的段階と一致するステート、研修なしで誰もが使えるインターフェース。
Domínio Visualの場合、「現地調査」から「請求」までの10ステートのモデル化、作業指示を中心に設計したMariaDBのスキーマ、そして「ユーザーは工事の最中にいる」という前提で作ったフロントエンドだ。指標ダッシュボードを眺めている人向けではない。
ビジネス側の課題
看板業は案件単位で動く。各作業指示はいくつもの物理工程を通る。現地に出向いて採寸し、レイアウトを描き、顧客承認を取り、素材を印刷または裁断し、屋外なら金属フレームを組み、工場で組み立て、設置日程を決め、現場に搬入し、設置して、ようやく請求に進む。
各工程に関わるのは別々の人間だ。採寸した営業はレイアウトを描くデザイナーではない。デザイナーは裁断機を回すオペレーターではない。現場で設置する人間が工場にいるとは限らない。そして顧客は「自分の案件、今どうなってる？」と、たまたま電話に出た誰にでも尋ねてくる。
基盤がなければ、答えは電話に出た人次第になる。全員がパズルの一片しか持たない。全体像はどこにも存在せず、分散している。
見た目以上に重要な理由
この運用には三つの隠れコストがある。どれも損益計算書に出てこないまま利益を削る。
第一に、調整コスト。1案件につき進捗確認のWhatsAppのやり取りが10〜20件発生する。進行中の30〜40案件に掛け合わせれば、本来はシステムが担うべき作業に、熟練者が毎日数時間を注いでいることになる。
第二に、やり直しコスト。履歴が一箇所に集まっていなければ、承認済みのレイアウト版が3週間前のメールに埋もれていたり、鉛筆で走り書きした採寸が誰にも読めなかったり、という理由で作業をやり直す羽目になる。
第三に、そして最も高くつくのが、未請求のコストだ。設置したのにレーダーから外れて請求されなかった案件。口頭で合意した追加工事が最終見積もりに反映されなかった案件。Aberdeen Groupの数年前の調査では、構造化されたデジタルプロセスを持たない企業は、年間売上の1〜3%を未発行・未回収の請求として失うと示唆されている。どこにも数字として表れず、静かに消えていく。
こうした業種における「デジタル基盤」とは何か
CRMではない。ERPでもない。カスタムステート付きのTrelloでもない。これらを同時に兼ねつつ、語彙だけは会社の実務と正確に一致している必要がある。
差は微妙だが決定的だ。ソフトが作業指示を「deal」「opportunity」「task」と呼ぶなら、現場は決して一貫して使わない。「OS（作業指示書）」と呼び、現場がすでに頭の中で使っているステート——現地調査、レイアウト、承認、印刷、裁断、金物、製作、設置、搬入、請求——を備えていれば、定着は即日起きる。
サービス業における受託開発の中核的な根拠はここにある。機能の問題ではない。言語の問題だ。
ビジネスにとって意味のある技術判断
ここでの技術選定はすべて、業務上のインパクトを基準にしている。開発者にとって面白いかどうかではない。
データベースは流行りのNoSQLではなく、リレーショナルのMariaDBを選んだ。作業指示は顧客、品目、履歴、請求と堅い関係を持つし、年度末に経理が問い合わせを走らせたくなったとき、SQLは多くの人が読める言語だからだ。
認証は新規ユーザーにbcrypt、既存のMD5レガシーとの互換も保っている。優雅ではない。実務的だ。既存ユーザーが移行日にパスワード再発行を強いられずに済む。これが「全員が使う」と「半数が離脱する」の分かれ目になる。
フロントエンドはNginxで配信するSPA、バックエンドはNode.jsのFastify APIだ。古典的なサーバーレンダリングのRailsアプリでも成立し得た。SPAを選んだのは具体的要件のためだ。現場で設置する担当者は、しばしば弱い回線でスマホからステートを更新する。クリックごとに完全なラウンドトリップを要求する仕組みより、ローカルステートと非同期同期を持つSPAのほうが、この文脈では確実に動く。
この一点だけが、この選択の正当化根拠だ。全員が光回線のオフィス勤務なら、従来型のアプリのほうが構築も保守も安く済んだ。
実フローのモデリング：ステートの罠
この種のビジネスをデジタル化するとき最も多い誤りは、実フローを「未着手・進行中・完了」の3〜4ステートの簡素なモデルに翻訳することだ。図面上はきれいに見えるが、現場では無用の長物になる。
Domínio Visualは10の独立ステートで運用している。各ステートが物理工程の一段階と、担当する人またはチームに対応する。
- 終了（0）— 請求後の最終ステート
- 現地調査（1）— 営業が現地に出向いて採寸
- レイアウト（2）— デザイナーが視覚案を作成
- 印刷（3）— ビニールや印刷素材
- 裁断（4）— 立体文字や硬質素材のカット
- 金物（5）— 必要に応じて金属フレーム製作
- 製作（6）— 工場での組み立て
- 設置（7）— 顧客現場での取付
- 搬入（8）— 配送物流
- 請求（9）— インボイス発行
- レイアウト承認（10）— 印刷前の顧客確認
この粒度は過剰設計ではない。各ステートは「今自分の手元にある案件はどれか」を知る必要がある特定の人に対応している。二つを一つに畳むと、その人は自分の担当でない案件まで目にすることになる。採用率は即座に落ちる。
履歴：どの機能より多くの問題を解決する目立たない機能
どの作業指示にも履歴テーブルが紐づく。ステート変更、メモ、添付ファイルは、タイムスタンプと操作者とともに記録される。
これは要件定義のときには誰も要求せず、半年後には最も使われる機能になる。技術的な解決策があるとは思われていなかった三つの業務課題を解決するからだ。
顧客からクレームの電話が来たとき、関わった人の記憶に頼らず、誰でも案件の時系列を正確に再構築できる。
社内で「誰がいつ何を言ったか」の議論になったとき、中立的な記録が数秒で決着をつける。
新しいメンバーが入ったとき、5人に聞いて回らずとも過去案件の文脈を追える。
実務上のルールはこうだ。3か月後に「あれっていつだっけ？」「あれ、誰だっけ？」という質問を生みうるものは、必ず履歴に残す。例外なく。
最初の試みでほぼ必ずつまずく箇所
この種のプロジェクトでほぼ全てに現れる失敗は、具体的に書いておく価値がある。これから踏み出す人が回避できるように。
失敗その一。請求モジュールから始めること。直感的に見える。入金に直結するから優先度が高そうだ。だが誤りだ。残りが使われていなければ、請求は従来どおりシステムの外で発行され続ける。まず作業指示の運用ステートから始めよ。請求は自然に後からついてくる。
失敗その二。構築前にチーム全員の意見を聞くこと。各人は自分のパートに最適化しようとし、結果として機能が互いに矛盾するフランケンシュタインが生まれる。業務の端から端を見渡せる経験者を1人か2人選び、動くバージョンが出てきて反応を得られるまで残りの声は無視せよ。
失敗その三。過去データを移行しないこと。直近2年分の案件がない新システムは、空のシステムだ。チームは過去を確認するために旧システムに戻り続ける。データ移行は地味で技術的で見栄えがしないが、これなしでは定着は常に部分的なものに終わる。
失敗その四。フローより前にダッシュボードを作ること。グラフは経営陣が週に一度見る。日々のフローは全員が使う。ダッシュボードがなくても機能するフローを備えた基盤は初日から有用だ。逆は違う。
あらゆるサービス業に通じる良い習慣
Domínio Visualは看板業だが、同じパターンは案件型で売る会社すべてに当てはまる。クリエイティブ代理店、建設、建築、工房、印刷会社、AVインテグレーター、イベント業者。
- 図面上きれいに見えるステートではなく、チームが頭の中で既に使っているステートをモデル化する
- 各案件の履歴は任意ではなく必須
- 移行期間中はハイブリッド認証にする。初日から全員にパスワード再発行を強いない
- 運用データにはリレーショナルDBを使う。複雑な分析が後で必要になればエクスポートで対応
- 弱い回線のスマホ利用を前提にUIを設計する。オフィスのモニター前提ではなく
- 請求は運用フローが定着してから。先ではなく
- プロジェクトには権限を持つ社内の責任者を一人。委員会ではなく
汎用ソフトか受託開発かという選択について
正しい問いは「受託は高いのか？」ではない。高い。正しい問いはこうだ。チームが毎日使い続け、3か月で離れないことに、どれだけの価値があるか。
汎用ソフト——MondayやAsana、カスタムフィールドで調整したHubSpot——は導入は安い。しかし保守はほぼ常に高くつく。ソフトの語彙を業務の語彙に頭の中で翻訳し続ける負担を、チームに強いるからだ。その翻訳は、最もシステムを使うべき瞬間——プレッシャー下、顧客が苛立っている、納期が迫っている——にちょうど破綻する。
独自語彙を持つ受託開発ソフトはこの翻訳を取り除く。初期費用は高い。しかし5年の総所有コストはほぼ常に低い。そして、自分のスキーマに業務データが構造化されて残り、サードパーティの制限付きエクスポートに依存せず参照・出力・分析できる価値は、過小評価しがたい。
これは普遍の法則ではない。立ち上げたばかりの小さなチームは、Notionか表計算を痛みが出るまで使うべきだ。痛みが出始めたときが、構築のサインだ。
セキュリティと事業継続
作業指示、顧客データ、請求履歴を扱う基盤は、すぐに事業にとってクリティカルな存在になる。そのため、サービス業が従来軽視してきた三つの規律が必要になる。
バックアップ。週次ではない。最低でも日次、理想は時間単位の増分。かつテスト済みであること。一度もテストしていないバックアップは、保証ではなく希望に過ぎない。年に少なくとも2回は別環境で完全復元を実行せよ。
HTTPSは必須。Let's Encryptによる証明書自動更新。これは2016年以降の標準だが、今もブラウザの鍵アイコンが壊れている企業が現れる。2026年に業務管理アプリをHTTPで提供する技術的理由は存在しない。
役割別アクセス制御。全員が全てを見る必要はない。営業が原価率を見る必要がなければ、見せない。設置担当が住所と時間しか必要としないなら、それだけ表示する。OWASPが数十年前から説いてきた最小権限の原則は、神経質さではなく基本的な衛生管理だ。
GDPR：自社ソフトになると何が変わるか
ポルトガルのサービス業は顧客の個人データを扱う。氏名、住所、連絡先、しばしば税番号も。GDPR第6条はこれらの処理に明確な法的根拠を要求し、第32条は適切な技術的措置を要求する。
自社ソフトはここで具体的な利点をもたらす。適切なデータ保持、意味のある箇所での仮名化、外部ベンダーのサポートチケットに頼らない削除権の実装、誰が何をしたかの監査可能なログ。汎用SaaSは理論上は全て備える。実際には、各能力は契約プランとサポートの応答速度に左右される。
実コスト：提案書には書かれないこと
この種のプロジェクトをきちんと実施すると、ほとんどの提案書が過小評価する4つのコスト項目が生じる。
初期開発は見える部分だ。アプリ構築、デザイン、テスト、本番投入。通常は初年度総コストの40〜60%。
データ移行は常に見積もり不足になる。Excel、スキャンした紙、旧システムからデータを引き出し、取り込めるよう整合的に整える作業は、どんな妥当な見積もりより時間を食う。予算の15%は確保せよ。
立ち上げ後数週間のトレーニングと伴走。稼働後の最初の2週間が、採用が根付くかどうかを決める。質問に答え、小さなバグを素早く直し、UXの細部を調整できる担当者を置けるかどうかが、「チームが採用した」と「WhatsAppに戻った」を分ける。
継続的な保守。サーバー、バックアップ、セキュリティ更新、月次の小改善。システムが壊れるまで存在しないふりをしたくなる月額費用だ。
そろそろ着手すべきサイン
手作業の管理モデルが限界に近いサービス業に現れる具体的な兆候を、軽いものから深刻なものまで並べる。
- 顧客から案件確認の電話が来るたびに、3人に聞いてからでないと答えられない
- メインのExcelを管理する人が休暇に入ったら、業務全体がスローダウンした
- 数週間前に完了した案件が、未請求のまま放置されていたことが判明する
- 社内の議論が「お前が対応すると思ってた」で終わる
- 新しいスタッフが「何がどこにあるか」を把握するのに数週間かかる
- 売上が20%伸びると、調整コストが線形ではなく指数的に悪化する
これらの兆候が2〜3つ当てはまるなら、おそらく着手の時期だ。4つ以上なら、2年前が着手の時期だった。
要点
サービス業に派手な技術は要らない。正しい語彙を使い、作業の実状態を捉え、監査可能な履歴を残し、現場のスマホで動くシステムが要る。
汎用か受託かの選択は、総所有コストと、チームによる採用の現実的な確率をめぐる判断だ。汎用は立ち上げが安い。受託は保守と利用が安い。クリティカルな運用では、受託が3〜5年のスパンでほぼ常に勝つ。
移行は、エンジニアリングというより変化マネジメントの問題だ。ソフトが完成していることは必要条件だが十分条件ではない。権限を持つ社内責任者と、本気の過去データ移行がなければ、どれほど優れたシステムも中途半端な採用に終わる。
次回の記事では逆を扱う。表計算にすべてを残し、早すぎるデジタル化の誘惑に抵抗することに意味がある局面について。すべての会社が準備できているわけではない。そしてシステムを作ることが、まず下すべき運用上の意思決定を先延ばしにする手段になることもある。