困ったこと35～ 必須で難しい要件を後回し、最後に困った事態に

2024.10.21A3:生産スケジューリングの悩み相談

　夏休みの宿題で、自由研究や読書感想文など、重くてやりにくい課題が後回しになってしまい、8月の末に「どうしよう」と焦った経験はありませんか。生産スケジューラ導入プロジェクトでも、しばしば同じようなことが起こります。必須で難易度の高い要件を後回しにすることで、あとになって大きな問題に直面します。ここでは、そのような事態を避けるためのステップを記述します。

要件のリストアップと再確認

　「必須要件」とは、プロジェクトの目的達成にいかなる場合も必要不可欠のものをいいます。まずは、その必須要件を特定し、その重要度や頻度を意識してリストアップします。初めにきちんとやるべきステップで、これを怠ってはいけません。

　たとえば、工程全体でのリードタイム短縮を目的とするプロジェクトを考えてみます。段取り時間の最小化は必須要件になり得ます。一方、段取り回数の最小化はそうではないこともあります。必須でない要件は再評価し、除外することもありえます。

　リストアップされた必須要件を、以下の4つに分類します。

1. 標準機能で簡単に実現できる
2. 簡単ではないがシステム化可能
3. 「プラグイン開発」で実現する
4. システム化はあきらめて運用でカバーする

　なお、3のプラグイン開発は、結構何でもできるので、多くの要件をここに分類してしまいがちです。しかし、後々のメンテナンスのため、プログラマ確保の継続性を考慮する必要があります。外部委託する場合は、その外部リソース確保の継続性です。その条件が満たされるときだけ、プラグイン開発をしてもよいでしょう。

　また、難易度の高い要件は、要件の解決策を考える前に、要件自体が正確に記述できないことも多く、要件自体を研究する必要もあります。

スモールスタート

　重要であっても難しい要件から着手することはやめておいた方が無難です。難易度の低い分類1&2の要件から、プロトタイプ（試作品）を作成し、ステップバイステップでシステムを拡張していくことが基本です。

　最初から盛りだくさんでビッグスタートすると失敗のリスクが高まります。PoC（Proof of Concept＝概念実証）の手法を用いて、段階的に仕様を明確化し、要件定義を行うことが有効です。フィードバックを受けながら、要件の妥当性と実現可能性をチェックしていきます。

全体最適化にこだわりすぎない

　最後の方に起きる問題が、もう１つあります。計画の対象が、工場全体や長期的な設備投資計画や中期的な資材調達計画に及ぶ場合、全体最適化を目指すあまり、パフォーマンスが期待したほど上がらない、ということがあるのです。

投資対効果を常に意識し、全期間、全工程の計画にこだわらず、限られた期間や機能でも運用が可能であれば、そうした範囲で使用する決断も重要です。

　繰り返しになりますが、初めにきちんと必須要件を列挙し、分類します。簡単な要件から段階的に導入し、ステップごとに投資対効果を確認して、成果を積み上げていくことが成功への鍵です。

計画的かつ段階的なアプローチを取ることで、プロジェクトの成功率を高めることができます。これらを実行することで、最後に困った事態に直面することなく、プロジェクトを立ち上げることができるでしょう。

　関連するナレッジセンター　困った事３５　21 必須で難しい要件が後回しになって、最後になって困った事態になった

（了）