プログラムはよりシンプルに・・ユーザの要望を理解するのに大変！

https://minfo-gtech.localinfo.jp/posts/11036026

で紹介した制御フローはしっかりとの続きです。

目次

１． 試運転開始

２． 問題顕在化

３． 解決

４． まとめ

１． 試運転開始

試運転を始めました。

Good　Jobで先の問題はクリアされてました。

ユーザー側（同じ会社ですが・・）からすると中身わからないので動いて当たりまえのようでなんもなし。

２． 問題が顕在化

まずは、表示の問題・・トラッキングってなに？表示ランプの緑と赤は何を意味するの・・

ええ――今更。仕方ないので、タッチパネルアンドンの表示にコメントを追記し、運転。

すると、排出ﾓｰﾄﾞ中に＊＊したら、こうして・・・

排出ﾓｰﾄﾞ中に＊＊しても、製品長が長い場合は、製品扱いで・・

う．う．う．と修正していくと、じゃこの場合は、あの場合はと出てくる出てくる・・。

しまいには、運用が・・・。新しい機械を追加したんです。新しい使い方を教育してくださいというと以前の装置と同じように・・・

物理的に違うのだから無理だろう・・・

最後には、こちからがブチ切れモードで、そんなにいろいろ心配するならこんな機械使わなければいいだろう！使いこなせないんだから・・といってしまった。

３． 解決

結果として排出されるサイズはすべて排出する。

それ以外は、良品とする。

というシンプルな制限であとは、運用で対応する・・・午前中のデバッグは一体何だったんだろうと思うくらい簡単でシンプルになりました。

４．まとめ

制御フローよりも、ユーザーが想定するいろんなことを整理することが一番大事でした。この条件とこの条件の場合は・・・とケースで対応していくと結果、一個プログラムを変更すると関連する動作すべてを再検証する必要がでるので、試運転だけでも数十分かかる。

今回は、いろんな条件をまとめて、結果の動作を判断し、集約することで制御フローがまとまりました。

無理して、言われた通りもプログラムもできたでしょうが、デバッグ時間がかかった、不安定で運用上でも不慮の操作でバグがでることを考慮するとこのほうがよかったと思います。

ユーザーやりたい＝そのままプログラム　より、情報収集と集約して、最良も制御フローを提供するほうがよいということですね。