タスク管理システムを考えるの続き。

私の場合、目的が決まると要件開発と平行してデータ設計を行います。
プログラムはアルゴリズムとデータ構造といいますが、存在しないデータに対しての処理は書きようが無いわけで、 要件を満たすために必要なデータは何かを書き出していきます。
データはアルゴリズムを作る際に不足無いようにしなければならないので、おおざっぱなアルゴリズムの イメージもこの段階で考えておきます。 できる気がしないのであれば、見切り発車する前に考え直したほうがよいでしょう。

タスクのデータ構造

データ構造はオブジェクト指向を前提に考えます。 とはいっても、非オブジェクト指向の場合とそれほど極端には違いません。 データをまとめる分類に、処理的なまとまりも加味して考えるだけのことです。
アルゴリズムの都合でデータを作ると大抵後で痛い目を見ますので、 論理的な意味づけを元にデータを作るように気をつけています。

今回のシステムでは主役はタスクです。タスクに必要な属性を適当に挙げてみましょう。

• タスク名称、詳細な内容
• 関連するタスク(親子関係での細分化、依存関係)
• スケジューリングに必要な各種期日
• 見積工数および、積算の根拠となる値
• 実績工数、実施した人、コスト

こんな感じでしょうか。過不足があればまた修正します。

概念を再検討

ここまで特に定義も無くタスクと言ってきましたが、タスクってそもそもなんなのでしょう？

イメージとしては「人がやる仕事を可分なところで切り出したもの」といったところですが、 こいつの特徴をよく掴んでおかないと要件がまとめにくい。

タスクとして考えられるのは以下のような作業です。

• 仕様策定・変更
• コーディング
• テストケースの制定
• 自動テストの作成
• インシデントへの対応
• その他雑務

ここで、コード類はCVSやSubversionといったリポジトリで管理されることを想定しています。 仕様やテストケースは手ごろな管理ツールが無いので、この穴を埋める必要があります。 この点についてはまた別途考えましょう。

インシデントとは顧客からの問い合わせなどを意味して書いています。
問い合わせについての解答は管理する必要がありますが、 このあたりは既存のタスク管理でよく意識されており 専用の機能(発生や返答などを管理する入力欄など)がついていることが多いですね。

こう見ると、仕様作成やコーディング、インシデントなどをタスクのサブクラスとして 定義してしまいそうなところですが、これは本当でしょうか？

タスクというのは、何かしらの事物の変更というか、差分に付属するものだと思うのです。
例えばコードですが、機能ごとにタスクを作り、全体で木構造になるように作ったとします。 これは、新規作成の場合にのみ有効です。特定の機能を変更するタスクは、機能の木構造にはうまくはまりません。

つまり、コードという事物があって、そこに対する差分があるなら、それを人が行うのであるから タスクが生まれ来るのですね。新規作成は0からの差分であるだけです。
タスクは管理対象の差分と不可分である！というのが私の見解です。

抽象的な構造

抽象的には管理対象となる事物がまず存在します。

• コード
• 仕様
• テストケース
• インシデント
• 伝票
• 書籍やPCといった資産

これらは実体を持つ管理対象です。管理するといっても労働時間といったものは対象外になりますね。
これらの親となる管理対象クラスがあって、タスクはその差分、もしくは変更しようという計画に付帯します。

インシデントなどは発生と同時にタスクが起きるような側面がありますが、 発生したインシデントは台帳に付けられ履歴として連なる事物です。 新規にインシデントが発生した、なんらかの回答をしてクローズした、 という差分こそがタスクであり、インシデントそのものはタスクではないと考えます。

ですから、事務の作業も伝票に対しての変更、経理処理した/していないの変更こそがタスクとなり、 PCの資産にせよ、新規に購入した、処分したといった変更がタスクとなりうる。

そしてこれらのタスクは依存関係を加味した上で納期に間に合う範囲で自在にスケジューリングできるのです。

このような概念で設計すると、汎用的な管理機能とならないでしょうか。

抜けている概念

上記概念のタスクでは対応できないタスクが存在します。
サポートなどの電話応対、来客対応などです。

これらの作業は外的要因により強制的に発生し、スケジューリングがとても難しい。
改善活動においてこれらの特殊な作業のタスクの管理で非常に困ってしまいました。
これは上記タスクとはまったく別のクラスとして捉えなければならないことでしょう。

まだまだ続きます。