本文へ移動
実装と知見

DX人材は実務で育てる。現場に合う仕組みと知識を会社に残す

#DX人材育成#システム設計#業務改善#AI活用

現場の出庫操作を題材に一緒に設計・実装し、仕組み・コード・判断理由を会社へ残して、AIによる説明資料と次の改善につなぐ流れ

DXを任される担当者は、すでに日々の業務やシステムの対応を抱えていることが少なくありません。その仕事に加えて、新しい技術を勉強する時間を確保する。現場を知る人ほど忙しいとすれば、育成を進める側も、その現実を踏まえる必要があります。

当社は、担当者とマンツーマンで実務を一緒に進め、現場に合うシステムをどう考え、構築するかを伝える方法を重視しています。いま困っている仕事を題材に、要望の整理、設計、実装、確認までを進める。その過程で得た仕組みと知識を、会社へ残します。

身につけてほしいのは、ツールの操作やプログラムの書き方に加え、現場の動きに即して、何をどこまでシステムに担わせるかを判断する視点です。

学ぶ題材を、いま必要な仕事に置く

技術を学んでも、自社の仕事でどこに使えるかが見えなければ、次の行動につながりにくいものです。実務を題材にすると、技術の選択と仕事の目的を結び付けて考えられます。

たとえば、画面に入力欄を増やすときも、「この情報は何に必要か」「誰が、いつ入力できるか」「すでに別の場所にある情報ではないか」を一緒に確かめます。実装する理由まで理解すれば、次に別の要望が出たときにも、その考え方を使えます。

マンツーマンで進めると、その人が担当する仕事や理解している範囲に合わせて、疑問が出たところで説明できます。専門的な設計・実装は当社が担いながら、担当者には要望の整理、選択肢の検討、実際の操作の確認に参加してもらう。どの作業を一緒に行うかは、役割と確保できる時間に合わせて決めます。

学ぶために通常業務を抱えたまま開発作業まで引き受けるのでは、負担が増えてしまいます。進める仕事の範囲と時間を決め、業務改善の過程に学ぶ機会を組み込むことが大切です。

出庫のために、現場からパソコンへ戻る必要があるか

在庫管理システムで出庫登録をする場面を考えてみます。工場の現場で物を取り出した後、登録のためにパソコンのある場所まで戻る。あるいは、いったん紙にメモをして、後から入力する。登録できる機能があっても、実際の作業にその手間が残るなら、操作方法を見直す余地があります。

当社では、NFCタグを利用し、Android端末で出庫に特化した操作ができる仕組みを構築しました。タグを読み取ると出庫画面へ直接進み、出庫数量を入力するだけで出庫できます。詳細な在庫管理はPCブラウザで行います。

NFCは、端末をタグに近づけて情報を読み書きするための近距離通信です。Androidの公式資料(新しいタブで開きます)でも、NFCに対応した端末によるタグの読み取り・書き込みが説明されています。実際に使う端末とタグの対応は確認する必要があります。

出庫専用にする理由

工場の現場作業者にとって、わざわざパソコンを操作することが手間になるからです。現場の端末では、必要な出庫画面へすぐ進み、数量を入力して操作を終えられるようにします。

在庫管理のすべての機能をAndroid端末へ移す必要はありません。現場で行う出庫はAndroid端末、詳細な管理はPCブラウザという役割分担にすれば、作業する場所と目的に合わせて、それぞれの操作を設計できます。

この判断を一緒に考えることで、「既存システムの画面をそのまま小さくする」という発想から、現場で必要な仕事に合わせて機能と入口を組み立てる視点へ進めます。

タグを書き込むアプリも用意する

出庫用のアプリに加え、NFCタグへ情報を書き込むアプリも作成しました。タグを読んで使う機能と、使うためのタグを準備する機能を、両方用意しています。

システムを考えるときには、利用者が操作する場面だけでなく、その操作を支える準備も対象になります。タグを誰が用意し、変更が必要になったら誰が対応するか。こうした運用まで考えることも、実務を通じて学ぶ設計の一部です。

簡単な操作を、DBの整合性で支える

Android端末の出庫操作とPCブラウザの詳細管理は、データベースで連携させます。出庫登録を管理側へ即時に反映し、意図しない二重登録や登録漏れを防ぐことが重要です。

同時出庫にも対応しています。複数の作業者が同じ在庫に対して出庫するときには、複数の更新処理が競合します。その競合を制御し、更新の消失や数量の不整合を防ぐのが、同時実行制御です。

このような設計では、出庫処理が途中までしか反映されない状態を防ぐ「原子性(新しいタブで開きます)」や、通信の再送があっても同じ出庫を重複して登録しない「冪等性(新しいタブで開きます)」も確認事項になります。タグを読めたことと、出庫登録が成立したことは別です。どの時点で登録完了とするか、失敗した場合にどう確認・再実行するかまで決めます。

現場の操作を簡単にするほど、その裏側でデータを正しく扱う設計が必要になります。画面の使いやすさと、業務の記録としての正しさを一緒に考えることが、この例から学べる点です。

情報システム部と連携し、既存の仕組みを活かす

現場から新しい要望が出たときも、既存の情報システム部や社内IT担当者と一緒に、現在のシステムやExcelが担っている仕事を確かめます。使い続ける部分、連携する部分、置き換える部分を決めたうえで進めます。

Excelには、現場で積み重ねてきた確認の仕方や業務上の判断が含まれていることがあります。項目や計算式だけを移すと、その意味を取りこぼすかもしれません。何のために使っているかを確認し、必要なものを新しい仕組みに引き継ぎます。

移行も、いきなり全体を置き換えることが前提にはなりません。対象を絞って試し、現場の操作とデータのつながりを確認しながら、少しずつ置き換えます。従来の方法と新しい方法を併用する間は、同じ記録を二重に更新しないよう、更新する場所と担当を決めます。

この過程では、担当者も「どこを変えると、ほかの仕事に影響するか」「何を確かめてから切り替えるか」を考えます。既存の仕組みを理解し、必要な変更を着実に進めること自体が、設計を学ぶ機会になります。

記録の更新元やシステム間の責任については、在庫・生産・会計のデータをつなぐ設計の記事で詳しく説明しています。

動く仕組みと、判断の理由を会社に残す

一緒に開発した仕組みは、会社が使い続け、必要なときに見直せるIT資産として残すことを重視しています。そのためには、動くシステムとコードに加えて、何を考えて作ったかも残します。

出庫の例なら、「現場の端末は出庫に絞る」「詳細管理はPCブラウザで行う」「タグの準備も運用に含める」といった判断の理由です。次の担当者がその理由を読めれば、機能を追加するときにも、何を守るべきかを検討できます。

GitHubなどでコードと文書を管理すれば、変更の履歴と、その時点での説明を一緒に残せます。残す内容は、たとえば次のようなものです。

  • システムの構成、コード、画面やデータの関係
  • 採用した方法の理由、業務上の条件、確認が必要な点
  • 操作・管理・更新の手順、不具合が起きたときの確認方法
  • 変更内容と、確認した動作・結果の記録

コードや資料の利用範囲、管理するアカウント、会社がアクセスして変更できる条件は、依頼ごとに合意します。保守や障害対応を誰が担うかも決めます。会社にファイルがあることと、運用できることをつなぐための準備です。

内製・外注の選択や権利・引継ぎの条件は、費用・依存・主導権から考えるシステムづくりの記事で扱っています。ここで重視するのは、実務を一緒に進める中で、会社側にも判断の視点と、その根拠を読める記録が残ることです。

GitHubに残したコードを、AIで設計図へ整理する

コードと記録が残っていれば、AIを使ってシステムの構成や処理を読み解き、設計図や説明資料のたたき台へ整理できます。GitHub Copilotの公式ガイド(新しいタブで開きます)でも、リポジトリのコードを参照し、構成・機能・個々の処理や変更を理解する使い方が説明されています。

出庫の仕組みなら、Androidアプリ、NFCタグの書き込みアプリ、PCブラウザの管理機能、データベースとの関係を整理する対象にできます。担当者はその説明を読み、実際のコードや操作と照合しながら、仕組みへの理解を深められます。

ただし、コードから読み取れる現在の動作と、なぜその設計にしたかは、別の情報です。現場の事情や採用しなかった方法の理由は、記録しておく必要があります。AIの説明にも誤りや不足があり得るため、GitHubの利用上の説明(新しいタブで開きます)にあるように、人が内容を確認します。

「システムはあるが、仕様書がない」。この長年の悩みに対しても、現在のコードから説明を起こし、業務上の理由を補い、次の変更に使える資料へ整える道が開けています。仕様書がないことを、仕組みを理解し直せない理由にしなくてよいのです。

そのためには、作って終わりにせず、次の運用を続けます。

  1. どのコードが現在動いている版かを明確にする。
  2. 変更の理由と、業務上の条件を記録する。
  3. 会社の情報管理ルールに従い、AIに参照させる範囲を決める。
  4. AIが作った説明をコード・動作と照合し、確認した資料を残す。
  5. 変更のたびに資料も見直し、次の担当者が使える状態を保つ。

この運用方法まで一緒に扱えば、AIによる文書化も、会社が仕組みを理解し続けるための仕事として組み込めます。

改善計画が一緒に進めること

改善計画は、現場の要望を聞き、既存の情報システム部や社内IT担当者と連携しながら、業務の整理、システムの設計・実装、段階的な移行を支援します。現在のシステムやExcelを活かし、実際の操作とデータの整合性を確かめながら進めます。

担当者と実務を一緒に進める中で、技術を選ぶ理由、業務と画面の役割分担、確認の仕方、運用方法も共有します。できあがった仕組みとコード・資料を会社に残し、次の要望にも会社側が考え、判断して関われる状態を目指します。

支援の進め方は業務の整理と仕組み化、提供範囲と費用の考え方はサービスと製品と料金で案内しています。相談では、現在の仕事、既存の仕組み、担当者が一緒に進められる範囲から確認します。

参考になったら、いいねでお知らせください。