連載②現場オペレーターが要件定義にいないMESは、必ず"二重運用"になる
「うちのDX、正直どうなんだろう」
25年前の論文は、DXの失敗をすべて知っていた
DX導入後、なぜ多くの企業が思うような成果につなげられないのでしょうか。
本連載では、Karl Wiegersが2000年に示した「要求開発における10の罠」をもとに、25年前から変わらないDX失敗の構造を、現代の製造DXに置き換えて紐解いていきます。
第1話では、「ペーパーレス化は要求ではない――経営のDXビジョンとMES機能要件の断絶」をテーマに、「要求」という言葉の混乱が、プロジェクトにどのような影響を与えるのかをお伝えしました。
今回は第2話。
現場オペレーターが要件定義にいないMESは、必ず"二重運用"になるをテーマに、ユーザー巻き込み不足がプロジェクトにどのような影響を与えるのかを見ていきます。
▶ 第1話はこちら👇
罠2： ユーザーの巻き込み不足(Inadequate customer involvement) — 実際のユーザーが要件定義に参加せず、開発者や代理人の想像で仕様が作られる。
Wiegersは何と言っていたのでしょうか
Wiegersが2番目に挙げた罠の書き出しは、皮肉が効いています。「うまくいかないという十分な証拠があるにもかかわらず、多くのプロジェクトは、ユーザーから開発者へ要求を伝える手段としてテレパシーを当てにしているようだ」。
症状は3つあります。
第一に、ユーザー自身が「開発者は自分たちのニーズをもう分かっているはずだ」と思い込んでいます。あるいは「要件定義のような技術的なことは自分たちの仕事ではない」と考えています。
第二に、「忙しくて要求の収集や精査に付き合う時間はない」と主張します。Wiegersはここで有名な一言を添えています。 「きちんとやる時間はないのに、やり直す時間はなぜかいつも見つかるとは、不思議なものだ」。
そして第三の、最も見つけやすい兆候が、ユーザーの代理人（ユーザー部門のマネージャー、マーケティング担当、あるいは開発者自身）が要求のインプットをすべて供給している状態です。その結果、開発者は十分な情報も現場感覚もないまま、数多くの要求判断を自分で下すことになります。
Wiegersは実例も挙げています。 あるプロジェクトでは、顧客が完成した製品を初めて目にしたのは本番導入のときで、一目見るなり「受け入れられない」と却下しました。 要件定義へのユーザー関与の不足を示す強力な、しかし手遅れで、痛みの大きい証拠です。
処方箋の核心は2つです。 まずユーザークラスの特定です。ユーザーは一枚岩ではなく、利用頻度、使う機能、アクセス権限などが異なる複数のグループに分かれます。そのすべてを洗い出します。 次に、各ユーザークラスを代表するプロダクトチャンピオンを任命することです。チャンピオンは自分のクラスの仲間から意見を集め、ユーザー要求を提供し、品質特性や優先順位の判断に関与し、プロトタイプを評価し、要求仕様書をレビューします。 社内システムの開発では特に有効な方法だとWiegersは言います。そして原文の結びは明快です。「顧客代表と開発チームの間に、協働関係を築くことに力を尽くせ。」
この論文をもとにした製薬業界の要件定義研修では、さらに踏み込んだ表現が使われています。 「ユーザーが要求の記述を面倒がるなら、そのユーザーは口で言うほどそのシステムを必要としていない、ということだ。どんな言い訳も受け入れてはいけない」。そして「スケジュールを守るという目的のために、ユーザーが関与していないことを見過ごしてはならない。よくても、悪いシステムを少し早く手に入れられるだけだ」。
DX時代の症状 - 現場は忙しいので、私が代わりに
MES導入プロジェクトの要件定義フェーズです。 会議室に集まっているのは、情報システム部、生産技術部、DX推進室、そしてベンダーです。さて、この部屋に誰がいないでしょうか。
秤量担当も、仕込みオペレーターも、包装ラインの班長も、記録をレビューする品証の実務担当者もいません。 代わりに製造部からは課長が出席していて、こう言います。
製造課長 「現場は三交替で忙しいので、要件は私がとりまとめて伝えます。だいたい分かっていますから」
DX推進室 「では現場ヒアリングは課長経由ということで。スケジュールも詰まっていますし」
ベンダー 「標準機能の画面イメージがありますので、これをベースにご確認いただければ」
こうして、実際に毎日その画面に触れる人が一人もいないまま、仕様は固まっていきます。 課長は現場出身ですが、最後にラインに立ったのは8年前です。8年前にはなかった手順、増えた品目、非公式に定着した「現場の工夫」を、課長の記憶は反映していません。 Wiegersのいう「ユーザーの代理人がすべてのインプットを供給する」状態、そのものです。
そして稼働日です。秤量室のオペレーターが初めてMESの画面を見ます。 手袋のままではタッチしにくいです。秤量値の入力欄が、実際の作業順序と逆に並んでいます。異常時に呼び出す逸脱処理の画面は、防爆エリアの端末からは3階層も深いところにあります。1週間後、現場には見慣れたものが復活します。手書きのメモとExcelです。「とりあえず紙に書いておいて、あとでまとめてMESに入力する」。二重運用の誕生です。
これがこの罠の、製造DXにおける典型的な末路です。システムは稼働しています。しかし現場は紙とExcelで仕事を回し、MESへの入力は「事後の転記作業」になります。転記ミスを減らすために入れたシステムが、新しい転記作業を生みます。しかもデータはリアルタイム性を失っているので、経営が期待した「工場の見える化」のダッシュボードには、数時間〜数日遅れの数字が並びます。 Wiegersの警告した「初めて見た日に却下される」よりも、ある意味たちが悪いといえます。却下すらされず、静かに形骸化していくからです。
なぜDXで、この罠は悪化するのでしょうか
第一に、現場が本当に忙しいのです。 三交替のラインを止めて要件定義の会議に人を出すのは、営業部門から一人借りるのとはわけが違います。「現場を巻き込め」という正論は、生産計画の前ではしばしば無力であり、だからこそ「課長がとりまとめる」という代理人方式が、悪意なく、合理的な顔をして採用されます。
第二に、DX推進室という新しい代理人が増えました。 Wiegersの時代の代理人はユーザー部門のマネージャーやITでしたが、現代はそこに「DXの専任組織」が加わりました。DX推進室は熱意も知識もありますが、多くの場合、現場の業務経験はありません。 推進室がベンダーと直接仕様を詰めるほど、プロジェクトは速く進み、そして現場から遠ざかります。速度と関与のトレードオフが、組織図によって固定化されてしまいます。
第三に、パッケージ導入の「標準に業務を合わせる」という号令が、現場の声を封じる免罪符になります。 Fit to Standardは総論として正しいといえます。しかし「標準に合わせるのだから現場に聞く必要はない」は論理の飛躍です。どの業務を標準に合わせ、どの業務は現場の制約（防爆、手袋、清浄度区分、ラインの物理配置）ゆえに合わせられないのか。 その仕分けこそ、現場にしかできない判断です。現場を呼ばずに行うFit to Standardは、単なるMisfit to Realityに終わります。
DX版の処方箋——「現場代表」を役割として設計する
Wiegersの処方箋を、三交替の工場という制約の中で実装可能な形に読み替えると、次のようになります。
1 ユーザークラスを、職種×シフトで洗い出す
秤量、仕込み、包装、保全、品証レビュー、出荷判定。MESに触れる人を役割ごとに列挙します。見落としやすいのは夜勤帯です。日勤帯にいる支援部門（生産技術、品証）が近くにいない時間帯こそ、システムは一人で使えなければなりません。夜勤のオペレーターは、独立したユーザークラスとして扱う価値があります。
2 各クラスから「現場チャンピオン」を任命し、工数を公式に確保する
Wiegersのプロダクトチャンピオンを、製造現場では「兼任のお願い」ではなく、業務として発令します。ポイントは工数の事前確保です。「月8時間、要件定義とプロトタイプ評価に充てる。その分のシフトは補充する」と生産計画に組み込みます。これを渋るなら、経営はそのプロジェクトを口で言うほど重要だとは思っていない、ということです。 Wiegersの言葉を、そのまま経営に返してよい場面です。
3 会議室ではなく、現場で要求を集める
オペレーターを会議室に呼ぶのではなく、要件定義チームがラインサイドに行きます。実際の秤量作業を観察し、「いま紙に書いたそれは、何のためのメモですか」と問います。非公式な運用・回避策こそ、要求の宝庫です。ヒアリング1時間より、観察30分のほうが多くの要求が見つかることは珍しくありません。
4 紙芝居でよいので、稼働日の前に「触ってもらう」
Wiegersはプロトタイプ評価をチャンピオンの役割に挙げています。現代のMES導入なら、標準画面のデモ機を現場の休憩室に置く、モックアップを実際の手袋で触ってもらう、テスト環境で1バッチ分の入力を通しでやってもらう。
方法はいくらでもあります。「初めて見るのが稼働日」だけは、絶対に避けます。却下は、早ければ早いほど安く済みます。
DXセルフチェック3問
要件定義の会議の出席者名簿に、日常的にその画面を操作する現場の実務者（役職者や推進室以外の人）が1人でも含まれていますか？
現場代表の参加工数は、生産計画に織り込まれた公式な業務になっていますか？（手すきのときに見ておく、という運用は「いいえ」とします。）
稼働日より前に、現場のオペレーターが実物または試作の画面を、実際の作業環境（手袋・端末・場所）で触る機会が計画されていますか？
セルフチェックの見方
3つとも「はい」
現場の関与が仕組みとして設計できています。稼働後も大きな手戻りは起きにくい状態です。
「いいえ」または「判断できない」が1つある
どこか一箇所、代理人依存が残っています。そこを起点に、紙やExcelへの"逃避"が始まりやすい状態です。
「いいえ」または「判断できない」が2つ以上ある
代理人任せのまま稼働日を迎える、典型的な二重運用の経路にすでに乗っている状態です。
セルフチェックによって課題の有無は確認できても、「では、自社では何から整理すればよいのか」までは、プロジェクトの状況によって異なります。
1問でも「いいえ」があるなら、そのMESは高い確率で二重運用への道を歩みます。システムの出来がよくても、です。要求はテレパシーでは伝わりません - 25年前のこの皮肉は、三交替の工場でこそ、最も高くつきます。
自社の場合、何から整理すればよいか迷った方へ
セルフチェックで「いいえ」や「判断できない」となった項目はありましたか？
同じ項目で迷っていても、プロジェクトの進行段階や関係者、導入するシステムによって、整理すべき内容は異なります。
個別に確認したい方は、次の内容をお送りください。
セルフチェック3問の回答
最も判断に迷った質問
まだ内容を整理できていない場合は、「何から整理すればよいか分からない」とご記載いただくだけでも構いません。
私がメールで御社の課題を回答します。
次回は 罠3「曖昧な要求」
「リアルタイムに見える化」という言葉が、なぜ検収時の紛争のもとになるのかを見ていきます。
参考資料
Karl E. Wiegers "10 Requirements Traps to Avoid," STQE Magazine, 2000年（現在は著者によりMediumで公開）https://medium.com/analysts-corner/10-requirements-traps-to-avoid-fb103bfeaaac
Donald Gause & Brian Lawrence "User-Driven Design," STQE, 1999年1/2月号（ユーザークラスの議論としてWiegersが参照）
Karl E. Wiegers『ソフトウェア要求』（日経BP）
