このプロジェクトでは、多くのペア制約があります。次の仕様を実現するためです。
1)日直・宿直・宿日直は、平日の勤務を除く時間帯であり、切れ目なく常に一人が勤
務していること。30分以下の空き・重複も許されない。
2)拘束は、平日の勤務を除く時間帯であり、内科及び整形外科の常勤医師一人が自宅
待機等していること。 30分以下の空き・重複も許されない。
「切れ目なく」を保証するには、非常勤医師の早遅に起因する短時間宿直を常勤医師の誰かが行う必要があります。さらに条件として、非常勤医師の出身医局に応じて、常勤医師の誰が行うかが決まっています。そのために、次のような枠組みで制約しています。
非常勤医師が医局内科1の場合の常勤医師の対応です。「AならばB」で制約します。
以上、ペア制約について記述しました。整然と記述しているように見えますが、どちらかというと、出てきた不具合に対応するため、追加・変更を繰り返してきた結果です。
そのようなやり方でも、方法論として間違いではありません。しかし、追加変更する際に、より一般的な制約の仕方はないか?常に整理統合を意識しているところが大事な姿勢だと思います。そのようにして、仕様と制約を明確化する、文書に残しておくことがメンテナンス上必要なことです。
大変に複雑なシステムの場合、ユーザさま自身の開発協力は不可欠です。
1)出てきた解に対して、どこがいけないかを指摘すること
2)1)は、特殊ケースですが、それを一般仕様化、制約化する能力
がユーザさま側に必要になるということです。いわば、日本語のキャッチボールが出来ることが開発での必要要件となります。言葉として表現されてこなかった仕様(隠れ仕様)が顕在化され、必要な仕様が明確化される過程でもあります。お客さま自身が意識していなかった仕様が、実は重要な制約のために必要だった、ということでもあります。
そうした過程で大事だと思うのは、人の話をきちんと聞いて、それに対する適切なレスポンスをする、他人に対して、知らない前提で話をする、当たり前のことです。こうした開発でユーザ側の必要スキルは、プログラミング経験や、集合に対する理解ですらありません。日本語のキャッチボールがきちんと出来る、これに尽きると思う次第です。
0 件のコメント:
コメントを投稿