人員配置は最適化問題として定義できるのかー物流現場で見えた、意思決定支援との接続ー
物流現場の人員配置は、出荷量、締切、作業順序、スタッフのスキル、欠員対応など、複数の条件が同時に絡む判断業務である。
しかし実際には、その判断はベテランの経験や勘に依存しやすく、言語化も共有も難しい。
私はこの属人的な領域を、どこまで構造化できるのかを確かめるために、人員配置の簡易プロトタイプを試作した。
最初は、人員配置は最適化問題として定義可能ではないかと考えていた。
実際、必要工数、人数不足、時間帯別需要、スキル制約、作業順序、締切条件といった要素には、
目的関数・制約条件・変数として整理できる構造が相当程度ある。
そこでまず、翌日の物量予測と作業別生産性から必要工数と不足人数を算出し、その次に15分刻みでスタッフ別の配置表を出力する形で検証を進めた。
ただ、試作を通じて見えてきたのは、
人員配置は最適化問題として定義可能である一方で、
現場においては制約条件や例外の不完全性が大きく、
単一の最適解を一発で出すことだけでは不十分だという点だった。
重要だったのは、出力の崩れを手がかりに、
抜けていた制約条件や優先順位を発見し、
比較可能な形で意思決定を支援できる状態をつくることだった。
この経験から、人員配置は単なる最適化問題というより、暗黙知を構造化し、判断を支援する設計対象として捉えた方が実態に近いと感じるようになった。
プロトタイプの第一段階：必要工数と不足人数を出す
最初に作ったのは、複雑な配置表そのものではない。
まず必要だったのは、
明日、何時間足りないのか
を見えるようにすることだった。
そこで入力に置いたのは、たとえば次のような情報である。
翌日の入荷・出荷予測
クライアント別の物量見込み
バッチ別の出荷件数・PCS予測
作業別の標準生産性
固定で必要な付帯作業時間
自社スタッフの勤務可能時間
これらをもとに、各作業の必要工数を算出し、自社スタッフの稼働可能時間と比較した。
その結果として出したのは、
作業別の必要工数
総不足時間
派遣で補うべき必要人数
である。
つまり、
需要量 ÷ 生産性 = 必要時間
という構造で、まず需給の差を見えるようにした。
この段階の問題は、まず需要と供給の差を把握するための計算問題として整理できる。
・目的：作業別の必要工数と総不足時間を把握すること
・入力条件：物量予測、作業別生産性、固定作業時間、自社スタッフの勤務可能時間
・算出対象：作業別必要工数、総不足時間、派遣で補うべき必要人数
つまり第一段階では、配置そのものを決める前に、
需給ギャップを比較可能な形に置き換えることが主題だった。
この段階だけでも、
「なんとなく足りない」
「今日は重そう」
「たぶん2人くらい必要」
という感覚的な会話を、比較可能な情報に置き換えられる。
通常日と欠員日でどこが崩れるか、どの時間帯に不足が集中するか、といった比較ができるようになる。
ただし、不足人数が分かるだけでは現場は回らない。
本当に難しいのは、その先の配置だった。
プロトタイプの第二段階：15分刻みで配置を出力する
不足工数が分かっても、実際に誰をどこへ置くかはまだ決まらない。
そこで次の段階では、入力条件を増やした。
ここで初めて、人員配置は
時間帯ごとの人員割当を変数とする配置問題として扱うことができるようになる。
・目的：工程全体の滞留や締切遅延を抑えること
・制約条件：勤務時間、スキル、フロア、休憩、作業順序、締切条件
・変数：各時間帯における各スタッフの担当作業
追加で扱ったのは、たとえば次のような情報である。
スタッフごとの勤務時間
フロア配置
スキルマップ
休憩時間
作業順序
午前中完了必須などの締切条件
派遣に任せる作業の優先ルール
欠員時の前提条件
これらを踏まえて、プロトタイプでは15分刻みで各スタッフに作業を割り当てた配置表を出力した。
さらに、通常ケースだけでなく、
全員出勤ケース
派遣1名欠員ケース
のような条件差も入れ、どこにしわ寄せが出るかを比較できるようにした。
出力として見たかったのは、
誰が
どの時間帯に
どの作業を
どのフロアで担当するか
という配置そのものと、
どこで人手が不足するか
どの工程が詰まるか
欠員時にどこが先に崩れるか
という崩れ方だった。
人員配置は、単なる工数問題ではなく、
時間・順序・スキル・場所をまたいだ意思決定問題
であることが、この段階ではっきりした。
生成AIを使ったのは、正解を出すためではなく制約を発見するためだった
今回の試作で、生成AIは最適解を自動で出す装置として使ったわけではない。
むしろ役に立ったのは、ベテランの頭の中にある断片的な判断を、外に出し、並べ替え、条件として整理する補助としてだった。
現場の判断は、最初から整理されたルールではない。
「この時間帯は危ない」
「この作業はこの人でないと崩れる」
「この波の前にここを空けたい」
「欠員時は優先順位が変わる」
といった断片が、状況ごとに重なっている。
そこで生成AIに、現場ルールや判断の断片を文章で渡し、
何が制約条件か
何が優先順位か
何が例外ルールか
どこに矛盾や抜けがあるか
を整理させながら、何度も往復した。
重要なのは、使える配置が最初から一発で出力されたわけではなかったことだ。
最初の出力は、現場感覚から見ると不自然で、守るべき順序が抜けていたり、実際には崩れる組み合わせがそのまま割り当てられていたりした。
しかし、その“使えなさ”がむしろ重要だった。
出力を確認するたびに、
何の制約が抜けていたのか
どの優先順位が明示されていなかったのか
どの例外条件を入れるべきだったのか
を考え直すことになったからだ。
つまりこの試作は、配置を自動生成する作業というより、
出力の崩れを手がかりに、暗黙知の中に埋もれていた判断条件を発見していく学習過程
だった。
人が違和感を見つけ、AIが条件に言い換え、再度出力し、また崩れ方を見る。
この往復を通じて、現場で「経験が必要」とされていた判断の一部は、制約条件、優先順位、例外ルールとして共有可能な形にできることが見えてきた。
この試作で価値があったのは、配置案そのものより「なぜ崩れるか」を説明できることだった
試作前は、人員配置を最適化できるかどうかが主題だと思っていた。
だが実際にやってみると、価値の中心は少し違っていた。
本当に重要だったのは、
何が不足しているか
どこが詰まるか
誰が欠けるとどこが崩れるか
どの条件を優先すると何が犠牲になるか
を事前に見えるようにすることだった。
必要だったのは、唯一の正解を出すことではなく、
判断の前提を並べて比較できること
だったのである。
実際には、配置案そのものよりも、
「なぜこの案だと崩れるのか」を説明できること
の方が価値が大きかった。
この意味で、人員配置プロトタイプの役割は、最適化エンジンというより意思決定支援ツールに近かった。
さらに重要だったのは、その前段にある設計だった。
どの作業量を記録するのか。
どの粒度で時間を区切るのか。
どの制約を固定条件として置くのか。
結果として何が起きたかをどう振り返るのか。
ここで言う思考ログ設計とは、単なる記録や振り返りではない。
判断時の前提、制約、優先順位、結果を、次の意思決定で再利用できる形にして残す設計のことである。
現場オペレーションは、最適化問題として定義しつつ、
その前提となる制約条件や例外を構造化し、
意思決定に接続する設計が求められる領域であると考えている。
その意味で、本試作は、
現場の暗黙知を最適化可能な形に翻訳し、
実運用に接続するための基礎的な実装であった。
【関連記事】
