【事例】建設業DXプラットフォーム「POWER WORK DX」の開発

【Updated 2026-04-11｜まるごとAI顧問】CRIENの「まるごとAI顧問」は、経営者のAI学習から戦略、実装、定着までを1つのチームで一気通貫する新カテゴリーです。建設業DX「POWER WORK DX」の開発事例の背景には、顧問20社＋・案件50件＋の実践知を体系化してきた道のりがあります。分業型コンサルの限界を越え、経営の言語と実装の言語を同じ人間が繋ぐことが核心です。

建設業界は日本のGDPの約5.5%を占める巨大産業でありながら、デジタル化の遅れが深刻な業界の一つだ。私がPOWER WORK DXプロジェクトに参画したのは2024年4月。「日報を紙で書いている」「給与計算をExcelでやっている」「請求書を手書きで作っている」という現場の声を聞き、この業界にこそDXが必要だと強く感じた。

建設業DXの課題と市場機会

建設業DXとは、建設業界特有の業務プロセスをデジタル技術で効率化・自動化し、生産性と品質を向上させる取り組みのことである。国土交通省のデータによると、建設業の労働生産性は製造業の約50%にとどまっている。

POWER WORK DXが解決する課題は4つある。第一に、日報管理。現場監督が毎日紙に記入し、事務所に持ち帰ってExcelに転記するという二重作業。第二に、人員手配。職人の空き状況を電話やLINEで確認し、手動でシフトを組む非効率。第三に、給与計算。日報データと連動していないため、月末に手作業で集計。第四に、請求管理。工事ごとの原価管理が属人的で、利益率の把握に時間がかかる。

これらの課題を一つのプラットフォームで解決するのがPOWER WORK DXだ。クライアント企業は従業員200名規模の中堅建設会社。月間の管理対象は現場150件、職人800名、請求件数500件以上という規模だった。

技術選定とアーキテクチャ設計の判断

技術スタックの選定では、「現場での使いやすさ」と「開発効率」のバランスを重視した。バックエンドはPHP（Laravel）を採用。建設業界のエンジニア採用市場を考慮すると、PHPは人材確保が最も容易な言語だ。将来的にクライアント社内で開発体制を構築する際にも有利になる。

フロントエンド/モバイルアプリにはFlutterを採用した。建設現場ではiOSとAndroidの両方が使われており、クロスプラットフォーム開発は必須条件だった。Flutterにより、iOS/Androidの開発工数を40%削減できた。これは10名チームにとって大きなコスト削減だ。

インフラはAWSを選定。RDS（MySQL）、EC2、S3、CloudFrontという王道構成で、可用性99.95%を実現。月間のインフラコストは約12万円。ユーザー数800名規模でこの水準は、コストパフォーマンスとして十分に優秀だ。

10名チームのマネジメントと開発体制

チームマネジメントとは、プロジェクトの目標達成に向けてメンバーの能力を最大化し、コミュニケーションと意思決定を最適化する活動のことである。私はCTOとしてテックリードを務め、バックエンド/フロントエンド開発にも直接参加した。

10名の内訳は、テックリード（私）1名、バックエンド3名、フロントエンド/Flutter 3名、QA 2名、プロジェクトマネージャー1名。2週間スプリントのスクラム開発を採用し、毎朝15分のデイリースタンドアップで進捗を共有した。私の経験上、10名規模のチームではスクラムが最も効率的だ。20名を超えるとスケーリングフレームワーク（SAFeやLeSS）を検討すべきだが、10名なら標準スクラムで十分に機能する。

コードレビューは全プルリクエストで実施。私が最終承認者となることで、コード品質の一貫性を担保した。テストカバレッジは80%以上を維持。CI/CDパイプラインはGitHub Actions + AWS CodeDeployで構築し、デプロイ頻度は週2〜3回を実現した。

導入効果は顕著だった。日報入力時間は1日あたり30分→5分（83%削減）。人員手配の調整時間は月40時間→8時間（80%削減）。給与計算の工数は月3日→半日（83%削減）。請求書発行は月2日→2時間（87%削減）。総合的な業務効率化率は約80%に達した。

【顧問20社＋の現場から｜佐藤淳一】サービス業の顧問先では「顧客接点のどこにAIを差し込むか」で成果が決まります。フロント接客を全部AI化すると離反が起きるので、私は必ず「AI→人」と「人→AI」の二段構えで導線を設計します。20社＋の現場で見えた定着のパターンです。

よくある質問

Q: 建設業のITリテラシーが低い現場でも使えるのか？

A: UIは「スマホしか使えない職人でも使える」を基準に設計した。日報入力は3タップで完了する。導入時に2時間の説明会を実施し、初月の定着率は87%。3ヶ月後には95%に到達した。重要なのは「使いやすいUI」ではなく「使わざるを得ない仕組み」を作ること。日報を入力しないと給与に反映されないフローにすることで、自然と定着した。

Q: 既存の会計ソフトとの連携は可能か？

A: POWER WORK DXは弥生会計、freee、マネーフォワードとのCSV連携に対応している。API連携も段階的に実装中。将来的にはリアルタイム同期を実現する計画だ。

Q: 自社の建設会社でも導入できるか？

A: POWER WORK DXは従業員50名〜500名規模の建設会社を対象としている。現在はpowerwork.jpでサービスを提供中。CRIENでは建設業DXの無料相談も受け付けているので、まずは現状の業務課題をお聞かせいただきたい。

まとめ

ブランディングは一朝一夕で成果が出る施策ではないが、中長期的に見れば最も高いROIをもたらす投資だ。特にAIという競争が激しい領域では、技術力だけでなくブランド力が受注の決め手となるケースが増えている。本記事のフレームワークと計測手法を参考に、自社のブランディング戦略を構築してほしい。

建設業特有のデータ構造化の難しさ

POWER WORK DXの開発で最も難航したのは、建設現場の作業データの構造化だった。現場では日報が手書き、写真はスマホのカメラロールに散在、工程管理はExcelとホワイトボードの二重管理という状態だった。データ構造の設計だけで6週間を費やし、現場監督5名へのヒアリングを繰り返した。最終的に「現場の人が1タップで入力できる」UIと「管理者が欲しいデータが自動集計される」バックエンドの両立を実現するデータモデルに到達した。

DXプラットフォーム開発では、技術的に最適なデータ構造と現場のユーザビリティはしばしば相反する。建設業のように現場作業者のITリテラシーが多様な業界では、入力の簡便さを最優先に設計し、バックエンドで構造化する「後方統合」アプローチが有効だ。現場を訪問せずにデータモデルを設計することは絶対に避けるべきである。

建設現場のDXプラットフォームで最も重要だったUXデザイン判断

POWER WORK DXで最も議論を重ねたUXデザインの判断は「入力画面のボタン数を片手で操作できる4つ以下に制限する」という制約だった。建設現場の監督は、ヘルメットと安全帯を装着した状態で、しばしば片手に図面や工具を持ちながらスマートフォンを操作する。両手で操作できるデスクワーカー向けのUIは現場では機能しない。この制約を満たすため、情報入力を「タップで選択」中心に再設計し、テキスト入力は音声認識で代替した。結果、現場での入力完了率は97%に達し、PC入力を前提とした競合製品（完了率68%）を大幅に上回った。

建設業DXの成否は、技術の先進性ではなく「現場作業者のリアルな使用環境」への適応度で決まる。屋外の直射日光下での画面視認性、手袋装着時のタッチ操作精度、電波の不安定な現場でのオフライン対応など、開発室では気づかない要件が無数に存在する。これらの要件は、開発チームが必ず実際の建設現場を訪問し、現場監督の1日に密着して初めて発見できるものだ。

Flutterの本番運用で直面したクロスプラットフォーム特有の罠

Flutter採用で開発工数を40%圧縮できたのは事実だが、本番リリース後に想定外の問題が表面化した。Android端末のメーカー別カメラAPI挙動の差異だ。日報に添付する現場写真の撮影機能で、Samsung Galaxy S23では正常動作するがXperia 5 IVでは画像の回転情報（EXIF）が正しく保存されず、写真が横向きに表示される不具合が発生した。原因はFlutterのimage_pickerパッケージがEXIF処理をOS側に委任する設計になっていたためで、Xperia固有のカメラドライバとの相性問題だった。

修正にはEXIF情報の自前パース処理を追加する必要があり、対応に3日を要した。正直なところ、このような端末固有の問題は事前テストで発見するのが困難だ。POWER WORK DXでは利用端末のシェアを事前調査し、上位5機種での実機テストを必須工程に組み込む運用に切り替えた。クロスプラットフォーム開発の「書いて一度で動く」は理想であって、現場導入では端末ごとの動作検証を省略してはいけない。