はじめに
ITのハイエンド技術派遣として、とある製造会社の品質管理部門に派遣された時の話です。
なぜ30個以上も作ることになったのか
BIツールだけでは解決できない
現場の課題は、単純なグラフ化やBIツールだけでは解決できませんでした。
複雑な業務仕様、統一されていないデータ構造、複数のExcelファイルやフォルダ運用など、業務ごとに異なる事情が存在していたためです。
そのため、BIツールだけでは実現できず、個別にアプリを開発する必要がありました。
DXの立ち上がり期だった
当時はDX活動がまだ十分に浸透しておらず、業務改善を進めるための仕組みも整っていませんでした。
現場には多くの課題が存在していましたが、それらを解決する手段や体制が十分ではありませんでした。
情報システム部だけでは手が回らない
情報システム部門は全社システムの運用や基幹業務を優先するため、各部署が抱える細かな困りごとや現場固有の課題まで対応することは難しい状況でした。
また、要望を出したとしても、現場自身が課題を十分に認識できていないケースもあり、本当に必要なものが出来上がるとは限りません。
その結果、現場に近い立場で課題を素早く解決するアプリが必要になりました。
作ったアプリの例
検査結果の可視化
製品検査データを集計し、不良項目別の発生状況、不良位置の分布、および製品上の不良発生箇所を可視化するダッシュボードを構築しました。
簡素化したダッシュボードイメージ
フォルダ監視による自動メール通知システムの構築と一般化
ユーザーが指定したフォルダやファイルを監視し、ファイルの追加や更新を検知すると、スクリーンショットをメール本文へ埋め込んで通知する仕組みを構築しました。
単なる通知システムではなく、誰でも通知タスクを作成できる仕組みにしたことで、非IT部門でもさまざまな業務へ展開できるようになりました。
現場の製造職人のノウハウを数値化して自動化・可視化
現場のベテランが経験や勘で選定していた金型選択を自動化しました。
また、製品と金型のズレを数値化し、視覚的に確認できるようにしました。
計画と実績の可視化
設備ごとの計画値と実績値、稼働率、サイクルタイムなどを可視化しました。
設備故障の見える化
直近の設備状態から、当日注意が必要な設備を現場へ周知する仕組みを構築しました。
また、設備ごとの故障位置ツリーマップ、生産ロスのパレート図、ヒートマップなどを用いて設備故障を可視化しました。
経験を通してよかった点
目的や本質的な課題から考える癖がついたこと
ユーザーはITに詳しくないことが多く、そもそもITで何ができるのか分からないため、要求が非常に曖昧なケースが多くありました。
むしろ、本当に必要なものはユーザーが最初に要望した内容とは異なることも少なくありませんでした。
いわゆる「ユーザーの『このボタンを追加して』をそのまま実装してはいけない」ということを強く実感しました。
自走力が身についた
ヒアリングから設計・開発・運用はもちろん、データ基盤構築、DB周りの改善、現場とIT部門の橋渡し、AI導入の企画提案まで一人で担当していたため、自走力が身についたと感じています。
また、自ら方針を決めながら進められたことは非常に良い経験でした。
その結果、広く浅く知見が広がり、T字型エンジニアの重要性にも気づくことができました。
ユーザーの感謝を直接感じられた
個人的にはこれが一番大きな収穫でした。
「こんなことができるなんて感動した」
「このアプリ売れるよ（笑）」
「めちゃくちゃ楽になった」
そんな声を直接聞けることは、大きなやりがいにつながりました。
作って分かった課題
人を動かすのが一番難しく、正論では人は動かない
ITエンジニアにはありがちだと思いますが、私自身も以前は「正論や論理があれば人を説得できる」と考えていました。
しかし実際には、正論だけでは人は動きません。
むしろ正論だけをぶつけると攻撃と受け取られ、話がこじれてしまうことさえあります。
技術力だけでなく、交流分析のようなコミュニケーション手法を学ぶ重要性も感じました。
他部署との共有が難しい
後になってから、
「そんなアプリがあったんですか？」
「それ、うちの部署でも使いたかったです」
と言われることが何度かありました。
良い仕組みを作っても、その存在を知られていなければ活用されません。
かといって、一斉メールを送ってもほとんど読まれません。
最も効果があったのは、管理者層に対して実際にデモを実施したことです。
その結果、利用者やフィードバック依頼が大幅に増加しました。
属人化のリスク
標準化やドキュメント整備は意識していましたが、難易度の高いアプリほど開発者への依存度が高くなります。
アプリが増えるほど、この問題は大きくなっていきます。
依頼が殺到する
数年が経過すると名前が部署を超えて知られるようになり、相談や依頼が私一人に集中するようになりました。
その結果、個人では対応しきれない場面も増えていきました。
もし最初からやり直すなら
情報システム部と連携した社内アプリ開発の標準化
私が作成したアプリには、リンク一覧や概要、利用方法を掲載したナビゲーションバーを標準搭載していました。
しかし、他の方が作成したアプリにはそうした仕組みがなく、相互リンクができないなど、小さな不便が徐々に表面化してきました。
そのため、アプリ開発ルールや共通仕様は早い段階で整備すべきだったと感じています。
共通ライブラリよりテンプレート化を優先する
当初は共通機能をパッケージ化していました。
しかし、社内向けの小規模アプリでは、パッケージ管理を行うよりもテンプレートプロジェクトを用意した方が運用しやすいと感じました。
フォルダ構成を最初から整理する
30個以上のアプリを運用すると、管理対象となるフォルダも大量になります。
今であれば、サーバー上のフォルダ名にポート番号を含めるなど、検索しやすいルールを最初から決めておくと思います。
結論
30個以上のアプリ開発は成功だったと思います。
そもそも見えなかったものを可視化し、業務改善を進めた結果、複数アプリの効果を積み上げると、年間2000時間以上の工数削減につながったの工数削減につながりました。
しかし、それ以上に価値があったのは、現場との対話を通じて課題を発見・改善し、「困ったらDXで解決できるかもしれない」という意識が現場に根付いたことです。
DXというとAIや最新技術に目が向きがちです。
しかし、どれだけ優れたAIツールを導入しても、現場の意識が伴わなければ活用されません。
実際には、現場の困りごとを一つずつ解決していく地道な積み重ねこそが、現場の意識向上や選択肢の拡大につながり、最終的には大きな成果につながるのだと感じています。
今後の目標
親会社との調整を経て、約半年かけてMicrosoft Azureの利用環境を整備することができました。
そのため、次の目標としてAIエージェントの企画・導入を進め、2027年4月までに実運用へつなげたいと考えています。
使用技術
- 言語：Python、VBA
- DB：SQL Server、PostgreSQL
- フレームワーク：Dash、Flask
- 開発環境：WSL、Docker
- バージョン管理：GitLab
- クラウド：Microsoft Azure（OpenAI、Microsoft Foundry）
- BI・可視化：Spotfire