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

前回の引き続きのお話ですが・・

試運転開始

試運転を始めました。

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

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

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

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

すると、排出モード中に＊＊したら、こうして・・・

排出モード中に＊＊しても、製品長が長い場合は、製品扱いで・・

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

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

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

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

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

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

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

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

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

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

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