Q. プロジェクト作成依頼をお断りさせていただく場合もある

 Q.条件をもとに、作成いただけますでしょうか？

当院、当直表（今後シフト制）というスケジュールを作成したいです。

今週土曜日にZOOMをこちらで設定しますので、いろいろとご教示いただけますとたすかりますが、いかがでしょうか？

Ans.

申し訳ありませんが、土曜日のZOOMは、キャンセルとさせてください。

仕様をお出し頂くようお願いしたのですが、全く理解できません。

経験上、「部外者」にご自身の職場のルールを説明できないプロジェクトは必ず失敗します。申し訳ありませんが、理解できる仕様を頂かない限りお仕事はお受けできません。

＜仕様とは？＞

部外者にご自分がつくる勤務表のルールを説明してみてください。それが「仕様」です。部外者ですから、部内の暗黙ルールは何も分かっていません。何も分からない部外者に、分かるように言葉で伝えること、それが仕様になります。その仕様文書を手に入れることが出来れば、誰もが、同じく内容を理解することが出来る、違う場所で、同じ勤務ルールを再現出来る、ということになります。

仕様は、誰が受け取っても、別な解釈を生まない、ことが重要です。必要にして十分かつ正確な情報伝達文書、それが仕様になります。仕様はソフトウェアに依存しません。

＜仕様が全てのスタート＞

ある大学病院では、添付のような仕様を頂いて仕事がスタートしました。仕様とは、実現したいルールを言葉で書いたものです。(例は、添付シート参照)

この全てを実装した訳ではありませんが、お客さまとの了承を得ながら、実装し易い形に記述したのが、スケジュールナース上での制約になります。

この立ち上げには、数か月間でブラシュアップしていたと記憶しています。この期間は、お客さまとの共同開発作業で一般的なものです。仕様に基づいて実装しますが、その仕様で全てを網羅している訳ではなく暗黙知や、漏れ、意識していなかったが脳内では実装していた..等が必ずと言ってよいほど在るのが普通のプロジェクトです。当直表や勤務表というのは、実は、作成者は多くのことを考慮しており、かなり知的で複雑なことをしています。それを整理せずに、そのままとりかかることは、お互いに時間の無駄です。

このプロジェクトは、5年ほど前になりますが、現在も担当者が変わって使われ続けていると認識しています。ルールを言葉で残すことは、引継ぎの場面でも必要かと思います。

まずは、しっかりと、ルールをまとめるところから始めることをお勧めします。

また、上記プロジェクトを元にしたサンプルプロジェクト例もアップしておりますので参考になるかと思います。

https://www.nurse-scheduling-software.com/japanese/constraints_faqs/chapter23/

このスケジュールナース解も添付していますので、出力される解イメージの参考になると思います。

以上、大変失礼なことを申し上げました。

ご検討の程よろしくお願いいたします。