Google カレンダーでも Outlook でも何でもいいので、皆さんのカレンダーを見てみてください。あるいはチームメンバーのスケジュールを見てみましょう。
カレンダーは便利ですが、見づらくて使いづらいものでもあります。できれば一切触りたくないでしょうが、そうも行きません。マネージャーに限らず、現場のエンジニアでさえも例外ではなく、おそらくあなたも日々自分のカレンダーのメンテナンスをしつつ、メンバーのカレンダーを眺めては調整に苦労しているはず。
なぜカレンダーはこんなにも面倒くさいのでしょうか？
答えは単純で、スケジュールという概念を、予定 のみ を扱うものであると認識しているからです。しかし実際には 予定以外の事柄もあります。
では、予定以外にどんな事柄があるでしょうか。
たとえば「勤務時間」です。グループスケジューラーでは設定画面から設定できるようになっています。9:00～17:30 に設定すると、この時間帯が勤務時間となり、この範囲外はグレーアウトされて勤務外であることが伝わります。
もし、この「勤務時間」という概念が「予定」とは区別されなかったとしたら、どうなるでしょうか。おそらく 毎日開催する定期予定として 勤務時間内を示す予定を一つ、あるいは勤務時間外を示す予定を二つつくることになります。メンテナンスも面倒ですし、表示上も鬱陶しいですよね。
このように「予定」以外の事柄として抽出し、別の扱い方をすることで、このような問題を回避できます。
より抽象化すると、スケジュールという概念をどう実装するかは複数存在するということです。すでに「予定」と「勤務時間」を示しましたが、他にもあります。
オブジェクト指向でたとえると、スケジュールはクラスで、予定や勤務時間はインスタンスのようなものです。
さて、本記事では、この捉え方に基づいて、予定や勤務時間の事柄が存在すること、またこれら事柄をどのように統一的に扱えばいいかを論じます。
まず スケジュール とは、1日24時間という時間枠のどこに何を埋めるかを定義したデータ構造を指します。
次に、スケジュールドメイン または単に ドメイン とは、スケジュールに書き込むデータの種類を指します。
こうするとスケジュールの運用をきめ細かく行えるようになります。
次にドメインの例を見ていきましょう。
予定と勤務時間についてはすでに解説しました。
モード とは、過ごし方を意味します。典型的には次の 5 つがあるでしょう。
タスク とは、個人のタスクを指します。チーム内で合意したタスクではなく、自分自身がどう解釈したかというものです。または単に個人的な用事を指します。他人には見せられないのが特徴です。以下に例を挙げます。
ここから本題です。
スケジュールを上手く扱うためには 1 ドメイン 1 枚で扱う ようにします。
つまり、上記の 4 つのドメインを例にすると、次のように 4 枚で扱うようにします。
これにより、私達は以下のメリットを得ます。
if フォーカスモード内に予定調整が来た then そのリクエストを拒否する残念ながら、スケジュールドメインの考え方を採用したカレンダーまたはグループスケジューラーはまだありません。この概念はおそらく私が開発した、新しい概念だからです。
個人用途であれば、Google カレンダーなら「1ドメイン1枚」程度なら可能です。
しかし、スケジュールドメインの本質はスケジュール間の連携にあります。やはり専用のスケジュールソフトウェアを自製しなければならないでしょう。