建設DXを進めようとすると、最初に製品を探したくなります。
現場管理アプリ。
施工管理システム。
写真管理。
電子黒板。
クラウドストレージ。
AI。
BIM・CIM。
さまざまな製品があり、各社のWebサイトには多くの機能が並んでいます。
そこで、
「どの製品が一番高機能か」
「機能数が多いのはどれか」
「有名な製品なら安心ではないか」
と比較したくなります。
しかし、実際の導入で重要なのは、製品の機能数そのものではありません。
その会社で現在発生している実務課題に対して、
その製品がどこまで適合するか
です。
どれだけ高機能でも、困っている業務と関係がなければ効果は限定されます。
反対に、機能が少なく見える製品でも、毎日繰り返している面倒な作業を一つ確実に減らせるなら、大きな効果が出る場合があります。
この記事では、建設DX製品を選ぶ前に整理しておきたい実務課題と、機能比較だけでは製品を選びにくい理由を整理します。
最初に「何を導入するか」を決めない
DXの相談では、
「施工管理アプリを導入したい」
「AIを使いたい」
「クラウド化したい」
と、手段から話が始まることがあります。
しかし、本来先に確認したいのは、
現在どの業務で困っているのか
です。
たとえば、
- 現場写真の整理に時間がかかる
- 日報の転記が多い
- 同じ情報を複数システムへ入力している
- Excel帳票を毎回手作業で作っている
- 協力会社との情報共有が電話中心
- 過年度成果を探すのに時間がかかる
- 提出直前の修正確認が多い
などです。
同じ「建設DX」でも、問題が違えば選ぶ手段も変わります。
写真整理が問題なら、写真管理機能が重要です。
二重入力が問題なら、APIやCSV出力、既存システムとの接続性が重要になります。
自治体独自帳票への転記が問題なら、SaaSそのものより、その後のデータ変換が重要かもしれません。
つまり、
製品選定より先に課題選定がある
ということです。
課題は「困っている」で終わらせない
「Excel作業が大変」
だけでは、まだ製品を選べる状態ではありません。
もう少し具体化します。
たとえば、
「現場で入力した点検結果を、事務所で別のExcelへ毎回転記している」
「1案件につき3時間程度かかる」
「入力内容そのものより、自治体指定様式への並べ替えが大半」
「年間を通して繰り返している」
と整理できれば、必要な機能が見えやすくなります。
逆に、
「Excelが多いからExcelをなくしたい」
だけでは、どのExcelをなくすべきか分かりません。
既存Excelの中には、
単なる二重入力。
便利な一時集計。
発注者指定成果品。
社内独自の確認表。
など、役割の違うものが混在していることがあります。
全部を同じ問題として扱うと、必要以上に大きなシステムを選ぶ原因になります。
誰が困っているのかを分ける
同じ会社でも、立場によって困っている業務は異なります。
経営者は、
- 工数
- 原価
- 人員配置
- 案件進捗
を見たいかもしれません。
現場担当者は、
- 写真
- 日報
- 図面
- 指示事項
- 協力会社との共有
を改善したいかもしれません。
建設コンサルの技術者なら、
- 点検データ
- 評価結果
- 成果品帳票
- 過年度比較
- 照査
- 電子納品
が重要になるかもしれません。
事務担当者なら、
- 請求
- 勤怠
- 契約
- 原価入力
が中心になることもあります。
この違いを整理しないまま「会社のDXツール」を選ぶと、
経営側には便利だが現場入力が増える。
現場には便利だが管理側で再入力が必要。
ということも起こり得ます。
製品を選ぶ前に、
誰の、どの業務を変えたいのか
を明確にしておく必要があります。
現在の業務フローを書く
課題を整理するときは、現在の業務を簡単に並べてみると分かりやすくなります。
たとえば、
現場で点検
↓
紙へ記入
↓
事務所でExcel入力
↓
写真整理
↓
元請確認
↓
発注者協議
↓
評価修正
↓
成果品Excel修正
↓
一覧表修正
↓
電子納品
という流れがあったとします。
この中で、
どこに時間がかかっているか。
同じ情報を何回入力しているか。
誰から誰へデータを渡しているか。
何度修正が発生するか。
を確認します。
すると、
「現場入力をデジタル化する」
だけでは全体の問題が解けない場合があることが分かります。
入力は効率化したが、その後の成果品作成は従来どおり。
あるいは、現場では便利になったが、事務所で別システムへ再入力。
という状態も考えられます。
だから製品選定では、一つの作業だけでなく、
その前後の業務まで含めて見る
ことが重要です。
機能一覧だけでは適合性が分からない
製品比較表では、
写真管理 ○
工程管理 ○
帳票出力 ○
クラウド共有 ○
AI機能 ○
のように並べることができます。
しかし、「○」の意味は製品ごとに同じとは限りません。
たとえば「帳票出力」があっても、
標準帳票だけなのか。
Excelへ出力できるのか。
CSVなのか。
自治体独自様式へ対応できるのか。
ユーザー側でカスタマイズできるのか。
によって実務上の意味は違います。
「データ出力可能」も同じです。
CSVへ出せる。
APIで取得できる。
PDFだけ出せる。
元データは外へ出せない。
では、その後の使い方が大きく変わります。
機能名だけでなく、
その機能が自社の業務フローのどこで使えるのか
まで確認する必要があります。
「できること」より「残ること」を確認する
製品説明では、当然ながら製品でできることが中心になります。
一方、導入する会社側では、
導入後に何が残るのか
も重要です。
たとえば、
現場入力は製品で完結。
写真整理も自動。
情報共有もクラウド化。
しかし最後に、
発注者指定Excelへの転記が残る。
社内基幹システムへ再入力する。
自治体独自帳票を人が修正する。
CSVを別形式へ変換する。
ということがあります。
これは製品が悪いという意味ではありません。
標準SaaSは、複数の顧客へ共通機能を提供することで価値を出します。
顧客ごと、自治体ごとの細かな独自仕様まで製品本体へ取り込むことが適切とは限りません。
その場合は、
標準部分はSaaSへ任せ、固有部分は別の手段で補完する
という設計になります。
一つの製品ですべて解決する必要はない
DXというと、
「最終的には一つのシステムへ統合した方がよい」
と考えたくなります。
しかし、必ずしもそうとは限りません。
たとえば、
基幹システムは会社全体の原価・案件管理。
現場SaaSは写真や現場情報。
Excelは自治体独自成果品。
VBAはデータ変換。
BPOは件数の少ない例外処理。
人間は技術判断。
という役割分担も考えられます。
大切なのは使用するツールの数を減らすことではなく、
同じ情報を不必要に何度も入力しないこと
です。
複数システムを使っていても、データが適切につながっていれば問題が小さい場合があります。
逆に一つの巨大システムへまとめても、現場外でExcel転記が続けば効率化しないことがあります。
SaaS以外の選択肢も残しておく
課題を整理した結果、解決方法がSaaSとは限りません。
候補には、
- SaaS
- 既存システムの設定変更
- Excel関数
- Excel VBA
- RPA
- BPO
- 個別開発
- 業務フロー変更
- 手作業のまま残す
などがあります。
毎月数百件繰り返す単純作業なら、自動化の効果が大きいかもしれません。
年に数回しか発生しない特殊処理なら、人が対応した方が安い場合もあります。
現在のやり方で十分なら、無理に変えないという選択もあります。
DXの目的は、
新しい製品を導入することではなく、
業務をより良い状態へ変えること
です。
導入前に確認したい5つの項目
製品を探し始める前に、最低限次の5項目を整理しておくと比較しやすくなります。
1. 誰の業務か
現場担当。
技術者。
管理職。
経理。
協力会社。
発注者対応。
誰の作業を改善したいのかを決めます。
2. 何に時間がかかっているか
作業名だけでなく、
入力。
転記。
検索。
確認。
修正。
情報共有。
など、具体的な動作へ分解します。
3. 何を入力し、何を出力するか
入力データは何か。
最終成果は何か。
既存システムとの受け渡しはあるか。
ここを整理します。
4. 独自仕様があるか
自治体指定帳票。
元請指定様式。
社内独自コード。
過年度データ。
特殊なExcel。
など、標準化しにくい条件を確認します。
5. 導入後に何が残りそうか
製品外で、
Excel加工。
CSV変換。
再入力。
紙。
確認作業。
技術判断。
が残らないか確認します。
この5項目が分かるだけでも、機能表の見え方がかなり変わります。
デモでは「自社の1業務」を当ててみる
製品デモを見るとき、すべての機能を理解しようとする必要はありません。
それより、
「自社で現在困っているこの作業は、この製品を使うとどう変わるか」
を具体的に当ててみます。
たとえば、
現場で写真撮影。
写真番号付与。
事務所へ共有。
Excel帳票へ反映。
発注者提出。
という一連の流れを、その製品でどう処理するか確認します。
すると、
ここまでは製品でできる。
ここからExcelが必要。
この部分はCSV出力できる。
ここは別サービスが必要。
という境界が見えてきます。
デモを見る目的は、
機能をたくさん知ることではなく、
自社業務との適合範囲を確認すること
です。
小さく試してから広げる
会社全体を一度にDXしようとすると、評価すべき条件が増えます。
まず、
一業務。
一現場。
一部署。
など小さい単位で試した方が、製品の適合性を確認しやすい場合があります。
たとえば、
写真管理だけ。
日報だけ。
一つの帳票変換だけ。
から始めます。
小規模に試せば、
本当に時間が減るか。
入力が増えていないか。
現場が使えるか。
導入後にどんな作業が残るか。
を実際に観測できます。
ここで残った問題が、次の改善対象になります。
製品選定は「製品の評価」ではなく「組み合わせの設計」
建設DX製品の比較というと、
A製品とB製品のどちらが優れているか
という話になりがちです。
しかし実務では、
A社には合うがB社には合わない。
同じ会社でも現場部門には合うが別部署では使わない。
ということがあります。
そのため重要なのは、
製品そのものに絶対的な順位を付けることではありません。
自社の課題に対して、
どこをSaaSへ任せるか。
既存システムをどこまで残すか。
Excelをどこで使うか。
外部へ委託する部分はあるか。
人間判断をどこへ残すか。
を設計することです。
つまり建設DXの製品選定は、
一番高機能な製品を探す作業ではなく、自社業務に合う役割分担を作る作業
と考えた方が整理しやすくなります。
導入後のラストワンマイルまで見ておく
製品選定時に見落としやすいのが、製品と最終成果の間です。
建設会社や建設コンサルでは、
システム上のデータだけで業務が終了しないことがあります。
最終的に、
発注者指定様式。
自治体独自Excel。
Word報告書。
CSV。
写真台帳。
電子納品用ファイル。
などへ変換する場合があります。
製品がその部分まで対応しているなら、その機能を使えばよいでしょう。
対応範囲外なら、別の方法を考えます。
この「最後に残る部分」を導入前から把握しておけば、
導入した後で、
「思ったよりExcel作業が残った」
という状態を減らしやすくなります。
製品の範囲と、実務の最終地点をつなぐ部分が、建設DXのラストワンマイルになりやすい領域です。
まとめ
建設DX製品を選ぶとき、機能比較から始めると、
高機能な製品。
有名な製品。
機能数の多い製品。
へ目が向きやすくなります。
しかし、先に整理したいのは製品ではありません。
誰が困っているのか。
どの業務に時間がかかっているのか。
何を入力し、何を成果として出すのか。
どんな独自仕様があるのか。
製品導入後にも何が残るのか。
を確認します。
そのうえで、
SaaS。
既存システム。
Excel。
BPO。
個別開発。
人間による判断。
などを組み合わせます。
建設DXでは、
「何を導入するか」より先に、「何をどう変えたいか」を決める
ことが重要です。
課題が具体的になれば、製品比較で見るべき項目も変わります。
そして製品で解けない部分が見えれば、そこが次の業務改善やラストワンマイル設計の対象になります。
ダウンロード
維持DXでは、国交省様式を対象とした橋梁点検支援ツールを無料・機能制限版として公開しています。
実際の処理イメージを確認したい方は、以下のフォームからお申し込みください。
フォーム送信後に、ダウンロード案内をお送りします。
ご注意
ダウンロードしたExcelでマクロが実行できない場合は、
右クリック → プロパティ →「許可する」 をチェック後、再度開いてください。Windowsのセキュリティ機能により、初回実行時にマクロがブロックされる場合があります。
