住宅プロジェクトのクラウド化は「決定事項」の受け渡しから
着工前の打ち合わせで決めたコンセントの位置が、電気工事の発注書に反映されていない。そんな行き違いは、図面の保存先を一つにしただけでは防げない。決定事項を誰が発注内容に反映し、誰が照合するのか。そこが曖昧なままなら、資料をクラウドに集めても同じことが起きる。住宅プロジェクトでは、ファイルの共有とあわせて、次の作業に進める条件を決めておきたい。
クラウド化する対象は「資料」より「仕事の単位」で考える
一棟の住宅にも、施主との打ち合わせ、設計、見積もり、発注、施工、検査、引き渡しと、性質の違う仕事がある。すべてを一度に同じ画面へ移そうとすると、入力項目が増え、現場で使われなくなりがちだ。まずは担当者が変わる場面に絞り、次の仕事を始めるために何が必要かを洗い出す。
設備の発注なら、確定した品番に加え、色、数量、搬入予定日、設置場所、施主が確認済みかどうかが必要になる。これらを一件の発注案件に紐づければ、担当者が複数のメールや図面を見比べる手間を減らせる。ただし、検討中のカタログまで確定情報と同列に置くと、かえって判断しにくい。「検討中」「確認待ち」「確定」「手配済み」と状態を分ければ、発注に使える情報も見分けやすくなる。
工程表と判断待ちを一緒に管理する
工程表に日程は載っていても、施主の選定や行政手続きなど、着手の前提となる判断が見えないことがある。工程と判断待ちを紐づけておけば、「来週発注する」だけでなく「発注までに何を確定するか」も分かる。小規模な住宅会社なら、全工程を細かく登録する必要はない。納期に関わる選定、着工を左右する承認、次の職種を待たせる確認から扱うとよい。
判断待ちには期限と決定者を付ける
「キッチン仕様を確認」と書くだけでは、誰の返答を待っているのか分からない。判断待ちには、選択肢を示す資料、回答する人、期限、遅れた場合に影響する工程を記録する。施主が選ぶ事項と、設計者が技術面を確認する事項も分けておく。施主向けの画面で施工の可否まで判断させないためだ。
期限は催促のためだけに設けるものではない。「この日までに決まれば予定どおり発注できる」という根拠を共有するためにも使う。期限を過ぎても自動で確定扱いにはせず、担当者が代替案や工程への影響を確認する。通知は判断を促せるが、判断そのものは代行できない。
週次の確認では遅延件数より影響先を見る
定例会議で未完了の件数を読み上げるだけでは、どれを先に処理すべきか決めにくい。判断待ちの一覧には、発注、職人の手配、検査など、止まる可能性のある仕事も表示したい。洗面台の品番確定が遅れていても、納期と設置予定日に余裕があるなら、翌日必要な配線位置の確認を先に進められる。期限順だけでなく、後続工程への影響順でも見られると、現場の優先順位を付けやすい。
施主に見せる情報は社内画面と分ける
住宅会社の担当者には、見積もり依頼の進捗や協力会社との調整状況が必要だ。一方、施主が知りたいのは、何をいつまでに決めるか、決めた内容が反映されたか、次に何が起こるか。同じデータを使っていても、画面の見せ方と閲覧権限は分けて考える。
施主向けの画面は、一つの依頼ごとに「確認する資料」「回答する内容」「回答後の状態」が分かる形にしたい。長いチャットの途中に選択依頼を埋め込むと、返信があっても正式な回答か判別しづらい。家族で意見をまとめる場合は、誰が回答を送信するかを先に決め、確定後も内容を見返せるようにする。住宅購入時の比較や家族共有、入居後の管理に使うアプリの整理については、住宅購入で使うアプリの整理術でも扱っている。
施主が毎日アプリを開くとは限らない。通知には「確認してください」だけでなく、対象と期限を短く書き、詳しい内容は認証後の画面で見られるようにする。電話や対面で決まったことも担当者が記録し、施主が確認できるようにしておけば、連絡手段の違いで情報が分断されにくい。
導入前に決めたいデータの置き場所
クラウドサービスは増やせば便利になるわけではない。工程は表計算、施主との連絡はチャット、発注は別システムという構成でも運用できる。ただ、同じ項目を三か所で更新すれば食い違いが生じる。導入前に、各情報の「正本」をどこに置くか決めておきたい。
| 情報 | 正本の例 | 確認したい運用 |
|---|---|---|
| 工程の予定 | 工程管理ツール | 変更を入力する担当と更新頻度 |
| 施主の選定結果 | 承認記録を残せる案件画面 | 回答者、確定日、関連資料 |
| 発注内容 | 発注台帳 | 確定仕様との照合方法 |
| 引き渡し資料 | 住宅ごとの保管領域 | 施主への公開範囲と更新担当 |
正本を決めたからといって、すべてを一つのサービスに移す必要はない。別の場所へ転記するなら、どちらを更新の起点にするかを明示する。図面と発注台帳で名称が異なると照合しづらいため、案件番号や部屋名など、共通の識別子も揃えておく。
小さく試すなら一棟の「決定事項」から
導入試験で全社員に全機能を使ってもらうより、一棟を選び、施主の決定事項が発注まで届く流れを試すほうが問題を見つけやすい。まずは現在のメール、紙、表計算から対象となる決定事項を数件選ぶ。そのうえで、それぞれの受付、確認、確定、発注への反映を誰が担うか決める。
- 共通の登録項目を少数に絞る。名称、期限、担当、状態、関連資料から始める。
- 施主と社内担当者には、それぞれ必要な画面だけを見せて試す。
- 週一回、登録漏れや二重入力が起きた箇所を確認する。
- 発注書など、既存の成果物と内容が一致するか照合する。
試験中に見るのは、アプリを開いた回数よりも、決定済みの内容を探す時間、担当者への確認電話、発注前の差し戻しだ。厳密に数値化できなくても、起きた事例と原因を記録すれば改善箇所は見えてくる。入力が続かないときも、担当者の習熟だけを問題にしない。項目が多すぎないか、同じ内容を別の帳票に書き直していないかを確かめる。
権限と終了時の扱いまで設計する
住宅の案件情報には、施主の連絡先や間取りなど、公開範囲に注意が必要なものが含まれる。社内、協力会社、施主それぞれの閲覧・編集範囲を分け、協力会社には担当工事に必要な資料だけを渡す。担当変更や工事終了の際には権限を見直したい。共有アカウントを使い回すと誰が確認・更新したか追いにくいため、操作履歴を残せる運用が望ましい。
通信できない現場でどう使うか、誤操作した記録をどう訂正するか、サービス障害時に当日の作業をどう伝えるかも確認しておく。重要な連絡をクラウドだけに頼らず、緊急時の電話連絡先は別途持つ。将来サービスを変更する場合に備え、決定事項と添付資料を取り出せる形式や、契約終了後の保存期間も導入前に確認したい。
引き渡し時には、施工中の内部メモをそのまま施主へ公開しない。設備の型番、保証書、取扱説明書、点検に必要な記録を選び、住宅ごとの資料として整理する。たとえば給湯器の型番と保証書の保存場所を引き渡しチェック項目に加え、施主が閲覧できる状態になっているかまで担当者が確認する。入居後に問い合わせが来てから探す手間を減らせる。
