Blogブログ

1,700名の現場を変えた!搬入~施工管理をフルスクラッチでDX。多種多様な案件を扱うインフラ施工企業の課題をDX化した事例

こんにちは!広報の林です。

今回ご紹介するのは、1700名の人材が利用する某プラント工事業者様の社内システムの開発事例です。複雑な社内の管理体制に合わせてフルスクラッチで開発した今回のシステムは「こんな複雑な(管理を行う)システム、絶対他の企業では使えませんよね」と、その複雑さは先方担当者のお墨付きをいただくほど。

  • 既存のシステムでは対応できない複雑な管理をしている企業
  • レガシーな体制が残る大企業や多拠点展開企業

こんな企業様にご覧いただきたい事例です。

「うちは特殊な業界ルールがあり過ぎてシステム化は無理」と諦めている企業のご担当者様!ぜひ最後までお付き合いください。

1. なぜ、既存の物流管理システムではなく「独自のシステム」が必要だったのか

今回ご依頼いただいたのは大手のプラント工事業者様ですが「いつ、誰が、どの車で、どこに行くか」等、人と車両をセットで現場に送り込む業種は意外と多いです。物流、建設、設備、メンテナンス、ルート営業、ゴミ収集、あとは訪問医療や介護などもそうですね。

なので巷には、社内リソースを管理するシステムは多数存在していて、特に大手など管理すべきリソースが多い企業のほとんどが何かしらのシステムを導入している印象です。

しかし、今回の企業様は「部署ごとに予算や人員の管理をしている」かつ「部署をまたいだ現場への応援」が頻繁であることや、高度な技術を要する機器の運搬から設置、組み立て、調整、メンテナンスまで一気通貫で行われているため、搬入のあとに組み立てや設置などの「施工」が発生します。

「物流+建設」の要素が組み合わさったような複雑な処理が発生するため、現場の細かなルールに対応できる既製品がないという状況でした。

そこで、自社のルールにぴったりとフィットする社員が使いやすいシステムを一から開発したいというご要望をいただいたという経緯です。

2. 【課題】「誰が、どこで、何をしているか」が見えない組織の壁

今回の開発で依頼者様が解決したかったのは「誰が、どこで、何をしているか」を管理者が把握できていないという状態です。

特に中小であればまだまだ多いのが、事務所のホワイトボードや黒板で人材の配置を管理しているという状態ですね。

アナログは必ずしも悪というわけではなく、アナログが活躍する場面もあるのですが、今回のように1700名の人材や多数の車両を管理するような場合は、デジタルの方が圧倒的に管理しやすいです。

全国各地に拠点があり小~大規模なプロジェクトが同時進行で動いているにもかかわらず、現場の動きをリアルタイムで把握できないために、電話や帰社後の報告に頼っていたのが経営上の大きな課題だったんですね。

また、当該企業様では部署ごとに予算が細かく割り振られており、部署をまたいだ人員の応援があった場合にどの部署にどれだけコストを請求するかという「人工(にんく)清算」が煩雑で、各部署の担当者にとって大きな負担となっていたそうです。

さらに、社員だけでなく、車両や重機、協力会社、顧客情報など管理対象が多岐にわたり、それぞれがバラバラに管理されていたのも課題のひとつでした。

3. 【解決策】ブラウザとスマホで完結する「現場直結型」の統合管理システム

今回行った課題解決のポイントは4つ。

リアルタイム・モバイル対応

今回開発したシステムは、特別なアプリをダウンロードしなくても事前にアカウント登録を行った社員であれば、ブラウザから簡単にアクセスできます。登録した内容はリアルタイムで反映されるので、各社員の状況が一目でわかります。

また、スマホからもアクセスできるので、現場にいながら状況の確認や入力も可能に。翌日の予定を現場で確認できるのが、現場の方々からも軒並み好評でした。

現時点で情報未入力の社員を絞り込みできる「不備チェック」機能もあり、管理者がより簡単に社員の状況をモニタリングできる仕組みにしています。

アプリではなくWeb完結

ブラウザからシステムにアクセスできるという点。これって実は技術的にとても重要なポイントです。

まず、アプリの場合はユーザーがアプリを最新版に更新しない限り古いバージョンのままになり、不具合が残ることがあります。

一方、今回のようなWebシステムは、管理者がサーバー側のプログラムを書き換えるだけで全社員が強制的に最新版を使うことになり、「最新版のダウンロードをお願いします」などいちいち社員にお知らせをしなくてもいいんですね。そのため、情シスや総務にも余計な負担がかかりません。

また、ブラウザからのアクセスであれば、iOS/Android、Windows/Mac等、OSに関わらず基本的には同じように動きます。端末ごとにアプリのカスタマイズをしなくていいので、開発コストも抑えられます。

そして、なんといっても審査がありません。
iOSやAndroidのアプリストアに出すには厳しい審査があり(特にiOS)、申請してから数日〜数週間待たされることもあります。Webなら完成した瞬間に公開・修正が可能で、スピード感や保守性という点でもメリットだらけです。

管理の統合

これまでバラバラのシステムで管理していた、人材・計画・作業・車両・協力会社まで、すべて一つのシステム(ブラウザ)で管理できるようにしました。

例えば、施工については以下のフローで行われます。

ステップ 書類名(例) 主な役割・目的
① 相談 工事案件連絡書 「こんな工事を検討しているので、内容を確認してほしい」という意思表示。概算を出すための情報を共有する。
② 注文 工事依頼書 発注書や注文書の役割。「この金額と内容で正式にお願いします」という契約の証拠。言った・言わないのトラブルを防ぐ。
③ 完了 工事完了報告書 「依頼通りに終わりました」という報告。請求書を発行し、代金を支払ってもらうための根拠となる。

1から2、2から3と各工程に進む際に上長から印鑑をもらう「検印」の作業について、これまですべてアナログで行っていたものをデジタル化。社員のスケジュールや車両管理だけでなく、工事の事前連絡から報告までの共有もシステムですべて完結します。

統計・集計機能の自動化

ここが最も苦労したポイントです。

計画・作業管理で入力されたデータがそのまま統計に反映され、集計で「期間」や「自社」「自社+協力会社」のように関わった会社単位で工事案件を絞り込むことができます。

部署間の応援精算や人工管理がワンクリックで可視化される仕組みで「応援に行った時」または「応援に来てもらった時」それぞれの集計を見ることができます。

今では検証くらいならAIに手伝ってもらえそうな時代ですが、開発当時は現在のようにAIがそこまで普及していなかったこともあり「この条件で絞り込んだ際にこの数値が出れば正解」というテストデータを一から作って、吐き出された数字が合っているのか確認…みたいな泥臭い作業もやっておりました。懐かしい…。

4. 技術選定で工夫したポイント

最後に技術的な話と開発の裏話を少ししますね。今回、Web完結のシステムを作るにあたって、サーバーについては全国どこからでもアクセスできるクラウド(AWS)を採用しました。

大手であれば自社にサーバーを設置するオンプレミスを選択することも多いのですが、今後サーバーのメンテナンスなど保守性を考えての選択です。

  • TypeScript
  • PHP
  • Laravel(バックエンド)
  • Node.js
  • React(フロントエンド)
  • Docker
  • AWS(クラウド)

また、使用した技術の中で言うとReactとLaravelを使っているところがミソですかね。開発当時この2つはWebシステムの最新技術とされ注目を浴びており「画面表示速度の速さ」「開発効率と保守性の高さ」を実現させました。

画面表示速度の速さ

Reactはページ全体をリロードせずに必要な部分だけを書き換える「SPA(Single Page Application)」という処理が得意です。Webページをキャンバスに例えると、毎回キャンバスを真っ白に塗りつぶして一から新しい絵を描くのが従来だとすると、背景はそのまま流用して必要な箇所だけ消して描きかえるのがReactという感じでしょうか。

処理で言うと「家をまるごと一軒建て直す」のと「部屋の模様替えをする」くらいの差があるので、画面表示速度がとにかく速いです。アプリのようにサクサク動くので、快適に使っていただけるんですね。

開発効率と保守性の高さ

これはあまりお客様に直接関係する部分ではないのですが、Laravelにはデータベースの構造をコードで管理する「マイグレーション」という機能が備わっています。

PHPという言葉で「この項目を追加して」と注文を出せば、他のメンバーはそのオーダーを取り込んでボタンを1回押すだけで、自分の手元に全く同じデータベースを自動で再現できます。

従来はこれを誰かが手作業で設計して、頭の中にある構想をメンバーと共有して…とやっていたので、複数人で開発する際にメンバー同士で揃えておかなければならない設定が違うなんてことが発生してミスの原因になっていました。

チームメンバー全員が常に最新かつ同じデータベースを動かしていることが前提で、迷うことなく開発を進められるようになります。

まとめ(開発の裏話も)

今回ご紹介したこちらの社内システムは、4年経とうとしている今でも現役でご活用いただいております。

プロジェクトを担当したHさんに話を聞いたところ「現場で工事を行う職人さんたちが使ってくれているというのが嬉しい」とのこと。

システム導入したんだから使うって実は全然当たり前ではなくて、導入したけど使ってくれないって悩みめちゃくちゃ多いんですよ。

今回のケースは、ずっと窓口としてやりとりをしてくださったご担当者様がまさに「しごでき」でして、現場社員へシステムを使わない理由を根気よくヒアリングする→弊社に修正依頼が来る→修正対応→現場社員へ「使いやすくなったから使ってね」

このサイクルをずっと継続してやってこられて、ご担当者様の熱量がひしひしと伝わってきましたので、私たちもそれにお答えしたい一心で修正依頼にはとにかく迅速に対応する。そんな風に手を取り合って共創したケースです。

使いやすいシステムを作るのが我々のお仕事ではあるのですが、実際にそれだけでは定着は難しくて、依頼者様の熱量が現場社員の行動を変えて本当に使ってもらえるシステムになったという成功事例です。

最後まで読んでいただきありがとうございます。次回のブログもお楽しみに!

林

執筆者

Public Relations