最も難しいのは、ソルバーではなく、制約プログラムですらありません。
ユーザの意図を組んで制約を作り上げていく作業です。
タイプは、二つに別れ全くサポートの不要な方とそうでない方の2極ですが、後者の場合、3ヶ月以下で物になった経験はありません。中には、半年経っても未だ、稼動すら行き着いていないプロジェクトもあります。ですので、作業時間だけで取ったとしても、10万円では殆どの場合ペイしません。(反対に、前者の方には申し訳ないので、サポートとソフト費用は別にするストアアプリ化を行います。) 後者の方にどのようなアプローチがよいのか、悩みつつも、良い開発スタイルであると感じるのは
1)ユーザ実勤務表ベースでのExcelによるやり取り(ユーザ実勤務表に制約達成度を数値化・可視化していく)
2)ユーザ希望仕様をそのまま実装しない。(ユーザ経験に基づかない新規制約は、結局実現不能が多い。思いつき制約には付き合わない。背後にある本当の制約を推し量ることが重要)
3)実勤務表作成者に評価・FBをして頂く。(上位管理者ではNG)
です。特に、思いつき制約には要注意です。「どうせ機械に生成させるのだから」という発想で、やられると、苦労して実装したとしても、他の制約とのPriorityとの兼ね合いで殆ど有効に動作しない場合が多く、ない袖は振れない・絵に描いた餅を体感するばかりか、何ヶ月経っても収束しない事態になってしまいます。実績のあるルールにこだわる理由がここにあります。
いずれにしても、ダイバーシティとか人口知能とか、そういった技術範疇ではなくて、実勤務表作成者の頭の中をいかにして整理してあげるか、これに尽きます。実担当者は、本当に色々な事に思いをはせ、気を配りながら作っています。しかし、それが系統的に整理されてはいません。その時々の思いつきに左右されることも多いです。それを一つ一つ拾い上げ、本当に必要なルールだけを制約化していくことは、骨が折れる作業です。業界の常套宣伝文句の「簡単」は、簡単ではないのです。
0 件のコメント:
コメントを投稿