倉庫管理システム刷新をめぐるSaaS・内製・現行更改の対立
物流F社は、全国12か所の倉庫を統括する倉庫管理システム（WMS）を刷新する。現行は10年前のパッケージに大量のアドオンを施したオンプレミス構成で、現場はハンディターミナルによるバーコード運用に習熟している。経営層は人件費削減と在庫可視化を掲げてクラウドSaaSへの移行を主張し、倉庫長は「繁忙期の作業が止まるリスク」と「ハンディ端末の更改費用」を理由に反対している。情報システム部は、SaaS、PaaS上でのスクラッチ開発、現行更改の3案を比較検討している。要件は、繁忙期の処理能力が現行の1.5倍、障害時の停止許容時間は2時間、RFID対応は2年以内、投資回収は5年である。予算は初年度4億円、運用費は現行比1.2倍まで許容される。ステークホルダは経営層、倉庫長12名、協力物流会社5社、監査部門である。繁忙期は年2回、それぞれ3週間続き、その間の出荷件数は平常日の約2.2倍に達する。
1. 3案を比較するための評価軸を定め、トレードオフを可視化する方法を論じよ。
Read the worked answer
評価軸の設定 要件をそのまま軸にするだけでは足りない。達成の「確度」と「自社の制御可能性」を分けて置くのが要点である。
- 繁忙期処理能力1.5倍の達成確度（実測ベンチがあるか、他社導入事例があるか）
- 停止許容2時間の実現手段（SaaSはベンダ依存で、SLAと補償の内容、復旧の可視性が問われる。自社で復旧手順を握れるのは内製・現行更改）
- RFID対応の実現時期と追加コスト
- 5年回収・運用費1.2倍以内の遵守
- 現場の運用継続性（バーコード運用の維持可否、ハンディ端末更改費、教育コスト）
- 将来の拡張性とベンダロックインの度合い
トレードオフの可視化
- 軸を「スピード・コスト」と「制御可能性・現場適合」の2面で整理し、3案の位置を図で示す。
- 定量項目は5年間のTCO表にし、感度分析（出荷量±30%、SaaS料金の値上げ、為替）を併記する。単一の点推定で比較しない。
- 定性リスクは「起きる確率×影響」で評価し、繁忙期停止のような低確率・大影響の事象は別枠で扱う。
- 結論は単一案の断定ではなく、条件付きの推奨（例：基幹はSaaS、繁忙期のピーク処理と端末制御はPaaSで補完）として提示し、どの条件が変われば判断を変えるかを明記する。
2. 合意形成の進め方と、決定を記録する方法（アーキテクチャ決定記録）について論じよ。
Read the worked answer
合意形成
- まずステークホルダを「関心」と「影響力」で整理する。経営層は投資対効果、倉庫長は現場の停止と作業量、協力物流会社は接続方法と端末、監査部門は統制と証跡に関心がある。論点を分けて対応者を変える。
- 倉庫長の反対意見を感情論として扱わない。「繁忙期に止まる」を、ピーク時の出荷件数と1時間停止あたりの損失額に換算して要件化する。数値になれば設計で答えられる。
- パイロット倉庫を1か所選び、繁忙期を含む3か月間の実証を行う。議論の材料を意見から実測データへ変えるのが最も効く。
- 監査部門には統制要件（権限分離、ログ保全、変更管理）を早期にレビューしてもらう。後工程での手戻りを防ぐ。
- 対立が解けない論点は隠さず、経営判断を仰ぐ論点として明示する。エスカレーションの期限も先に決める。
決定の記録
- 記録の型は「状況（制約と背景）」「決定内容」「検討した代替案と却下理由」「根拠となるデータ」「影響と受容したリスク」「見直し条件」の6項目とする。
- 決定者と日付を必ず残し、後から「誰が決めたか分からない」状態を避ける。
- 見直し条件（例：繁忙期の実測が要件を下回った場合、SaaSのSLAが改定された場合）を書いておくと、決定は固定化せず、変更のたびに同じ議論を繰り返さずに済む。
- 記録は設計書とは別に一覧化し、後続の更改や監査の場で参照できるようにする。