近畿日本鉄道株式会社 様

具体的には、まずヒヤリハットに気づいた人が紙で上長へ報告し、それを本人あるいは上長がまとめて表計算ソフトに入力する。現場は駅員や乗務員などが所属する運輸系部門の職場と、設備の保守員などが所属する技術系部門の職場で分かれており、部門ごとの拠点事務所でまとめられる。その後、本社で部門全体の集約や報告を行い、最終的に安全管理部門により全体の集計や報告が行われる。

このヒヤリハット情報は、最終的にデータ化はするものの、職場によっては紙に押印する承認フローが必要で、さらにその紙をスキャンして次のプロセスに送る必要もあった。

近鉄は近年働き手不足への懸念もあり、2022年からデジタル技術を活用した業務効率化やDX推進に取り組んできた。その一環として、こうした非効率な業務プロセスを変えるべく取り組みを始めた。

複数のシステムを比較検討した結果、近鉄が選んだのがJUST.DBだ。奥村氏はその理由を次のように話す。「各部署で自主的に開発できるように、ノーコードで使いやすいことは必須でした。そのなかでJUST.DBは、ノーコードながら複雑な承認フローにも対応し、権限も細かく設定できました。費用がユーザーアカウントごとではなく同時ログインユーザー数で決まる点も魅力でしたね」

2023年にスモールスタートでトライアル。そのプロジェクト自体は中断したが、他の業務で利用できそうだと判断したため、本格的に開発を始めた。その一つが、事故の芽となるヒヤリハット情報を共有する「事故の芽情報データベース」である。JUST.DBに移行したことで、承認フロー機能で情報を次のプロセスに回せるようになり、承認状況に応じて公開設定を行うことで他部門への情報共有も即座に行われるようになった。1人1台のPCがない部署や屋外作業があるため紙を完全に排除はできないが、一旦JUST.DBに入力すれば、それ以降のプロセスで紙は不要になる。

協力会社とのやり取りでもJUST.DBは活躍している。その一例が情報共有の仕組みだ。セキュリティ上、近鉄と協力会社の間に共有フォルダーの類は設けておらず、従来やり取りはメールで行っていた。ここでも上長の承認が必要な場合は紙に押印してスキャンといった手間がかかっていた。

この課題を解決するため、同社はJUST.DBのスペース機能を活用。スペース機能を使えば、外部組織との情報共有が可能になる専用領域を簡単に作成できる。例えば技術系部門では協力会社と、作業指示票や作業結果などのやり取りをJUST.DBで実現した。今まで表計算ソフトに手入力していた内容も、システム上で書類を作成できるようになり、加えて内容修正・変更の必要が生じた際も、承認フローが明確化され、より適正な運用ができるようになった。

さらに運輸系部門では、旅行会社からの団体旅客予約にも利用を検討している。「1日約100件の予約があるので、1件ずつのメール対応ではかなりの手間がかかっていました。また、予約内容を複数様式の台帳で管理しており、情報の一元化管理ができていない状況でした。検討中のシステムでは予約内容をJUST.DBで一括管理でき、ステータス管理が容易になります。予約内容に対する回答情報の確認作業もJUST.DBのパネルを閲覧することで可能となるため、業務の効率化が期待されています」（奥村氏）

DX推進活動を継続してきたこともあり、近年は全社でデジタル化に対する意欲が高まってきていた。そのような土壌のなか、事故の芽情報データベースなど多くの社員が利用するシステムにJUST.DBを採用したことで、社内での認知度も高まっている。「承認フローで紙の印刷や押印など面倒なことがなくなり、便利になったと感じてくれているようです。”DX＝JUST.DB”と捉える人もいて、開発人口も増えています」（奥村氏）

実際部署ごとの取り組みが増えているという。例えば技術部門では定期的に機材の点検を行っており、その記録や承認に活用。保守作業などで現地に赴く場合、自動車が必要なケースでは運転記録が義務づけられており、その報告や承認にも活用している。「これらは各部署の管理部門などで、主体的に作成しています。JUST.DBは使い勝手が良いので、現場でも取り組みやすいです」（奥村氏）

現在の開発者は全社で20名程度。「生成AIとの対話で開発を進められるJUST.DB Blueprint機能などを用いていけば、今後はより開発の敷居が下がるでしょう。さらに各部門の事例を共有したり、社内の開発者が交流できる場を設けてノウハウを共有したりして、より良いシステム構築につなげていきたいです」と、奥村氏は意欲を語った。