方法論の二者択一は、問いの立て方が間違っている

MES導入プロジェクトで「ウォーターフォールかアジャイルか」を全体で一括して決めようとすると、どちらを選んでも無理が出ます。理由は、MESが性質の異なる作業の束だからです。

  • 後から変えると壊滅的に高くつく決定がある。データモデル(ロットの定義、実績の粒度)、設備接続方式、ERPとのインターフェース仕様。これらは反復で「作りながら考える」と、作り直しのたびに接続先すべてに影響が波及します。
  • 触ってみないと正解が分からない決定がある。現場端末の画面遷移、帳票のレイアウト、ダッシュボードの構成。これらを机上のドキュメントで凍結すると、稼働後に「使いにくい」という形で必ず請求書が回ってきます。

つまり正しい問いは「どちらの方法論か」ではなく「どの決定を先に凍結し、どの決定を反復に残すか」です。この区別はMES導入の流れで示した9ステップのうち、要件定義と設計の進め方を具体化するものです。

工程別の適性──凍結する層と反復する層

MES導入の工程を2層に分けた図。下層のデータモデル・設備接続・外部インターフェースは計画駆動で前半に凍結し、上層の画面・帳票・ダッシュボードはスプリントで反復開発する。全体をマイルストーンが貫く。 反復で作る層(スプリント2〜3週×n回) 現場端末の画面 帳票・ラベル ダッシュボード 通知・アンドン 前半で凍結する層(計画駆動・変更管理つき) データモデル 設備接続方式 ERP等の外部IF 権限・統制ルール 上層は下層のIFに依存する
MES導入における方法論のハイブリッド構成。土台となる決定は前半で凍結し、ユーザー接点は反復で作る。
工程向く進め方理由
データモデル・マスタ設計計画駆動で前半凍結全機能が依存する。変更コストが指数的に増える
設備接続計画駆動+早期の技術検証制約は設備側にあり、反復しても制約は動かない
外部インターフェース計画駆動で前半凍結相手システム側の開発・テスト日程を拘束する
統制ルール・権限計画駆動(合意形成に時間を使う)決めるのは業務側の意思であり、プロトタイプでは決まらない
現場端末の画面反復(実機・実データで2〜3周)紙のレビューでは現場は判断できない
帳票・ラベル反復実物を見て初めて要件が確定する
ダッシュボード・分析反復(稼働後も継続)見る人の行動が変わると要件も変わる

注意すべきは、反復に向く層も下の層のインターフェースに依存していることです。画面のスプリントを始める前にデータモデルが揺れていると、スプリントの成果物が毎回作り直しになります。「アジャイルで進めたのに手戻りだらけ」というプロジェクトの多くは、方法論の問題ではなく、凍結すべき層を凍結しないまま上層に着手した順序の問題です。

アジャイルを持ち込むなら、3つの条件を先に確認する

反復型を機能させるには、発注側に前提条件があります。私たちの支援経験では、次の3つが揃わないままスプリントを開始したプロジェクトは、実質的に「小刻みなウォーターフォール」に退化します。

  1. 2〜3週ごとに意思決定できる現場キーパーソンを確保できるか。 スプリントレビューに現場が出てこられないなら、反復の利点は消えます。工場の繁忙期とレビュー日程の衝突は最初に調整してください。体制の組み方はMES導入プロジェクトの体制で扱っています。
  2. 「今回のスプリントでは作らない」を言える優先順位付けの権限が一元化されているか。 現場の要望を全部受けるスプリントは計画駆動より高くつきます。
  3. 標準機能ベースで反復できる製品か。 スクラッチ開発での反復は毎回コードが増えるだけです。設定変更・ローコードで画面を組み替えられる製品でなければ、反復のコストが利点を上回ります。Fit to Standardを貫くための意思決定との相性が良いのはこのためです。

方法論は契約形態とセットでしか成立しない

見落とされがちですが、方法論の選択は契約に直結します。全体を一括請負で契約しながら画面を反復で作ることはできません。請負契約は成果物の事前確定を前提とするため、スプリントごとの仕様変更がすべて「変更管理」の対象になり、反復のたびに見積・承認のオーバーヘッドが発生するからです。

実務で機能しやすいのは、層に合わせて契約を分ける形です。

  • 凍結層(データモデル・設備接続・外部IF):成果物を定義した請負。検収基準を仕様書で明確にできるため請負に馴染みます
  • 反復層(画面・帳票):スプリント数を上限とした準委任、または「画面数×単価」のカタログ型。スプリントの打ち切り・追加を発注側が判断できる形にします
  • 統制ルールの合意形成:ベンダーではなく発注側のタスクとして社内工数を確保します。ここを外注しようとするプロジェクトは、決定が遅延して両方の層を止めます

ベンダー側の体制も確認が必要です。反復層を担当するチームが毎スプリント同じメンバーで継続できるのか、それとも都度アサインなのか。後者の場合、スプリントの半分が引き継ぎで消えます。提案段階で「反復対応可」とだけ書かれている場合は、体制表と単価テーブルまで具体化を求めてください。

よくある質問

全面的にウォーターフォールで進めるのは、もう時代遅れですか?

時代遅れとは言えません。規制産業でバリデーション文書の体系が要求される場合や、既存MESのリプレイスで要件が実質的に確定している場合は、計画駆動で通すほうが総コストは下がります。問題なのは方法論の選択そのものではなく、画面・帳票まで紙のレビューだけで凍結し、現場が実機に触れるのがテスト工程になってしまう計画です。ウォーターフォールを選ぶ場合でも、ユーザー接点だけはプロトタイプ確認の工程を挟むことを推奨します。

ベンダーが「アジャイル対応」を謳っています。どう見極めればよいですか?

3点を質問してください。①スプリントで変更できる範囲はどこまでか(マスタ構造まで変えられると言うなら、むしろ危険信号です)、②スプリントレビューの成果物は動く画面か資料か、③反復層の契約形態と、スプリント追加時の単価。この3つに具体的な回答が返らない「アジャイル対応」は、実態が計画駆動である可能性が高いといえます。

期間を短縮したいのですが、反復型にすれば速くなりますか?

なりません。反復型は「手戻りの発生場所をテスト工程から設計工程に前倒しする」手法であり、総期間の短縮を保証するものではありません。期間を決めるのは方法論よりも、意思決定の速さと例外処理の洗い出しの早さです。むしろスプリント運営のオーバーヘッド分だけ、名目上の期間は計画駆動より長く見えることもあります。短縮が目的なら、スコープを削る判断(MESのスコープをどう切るか)のほうが確実です。