大雑把ですが、ガントチャートを IDEF0 風に分解すると、こんな図になります。
・インプット方向のタスク（前工程のタスク）がある。
・アウトプット方向のタスク（後工程のタスク）がある。
・タスクは、一定の作業量を持つ。
・タスクは、一定の作業を行うと終了する（開始と終了がある）。
・作業は、配員（人）が行う。
・配員は、一定の作業能力（属人性、能力差）を持つ。
・配員は、リソースとしての制約がある（同時に２つの場所で働けないなど）。
・タスクは、時間制約がある（無限に長い期間でやってはいけない）。
・タスクは、期間制約がある（無限に期限を延ばしてはいけない）。
・１日の時間は、24時間である（週単位の勤務時間は40時間である、など）。
ここで、前者の項目は「前提条件」であり、ある条件をクリアすると「完了」になります。RPG ゲームみたいなものです。
後者の制限は、制約条件で「ルール」になります。ルール違反をすることはできません…というか、ルール自体がないと「ルール違反」って現象がないですよね（と、現象学的な話とか）。
これだけの条件を出しておけば、プログラミング可能/検証可能になります。いわゆる XP で言うところの計画ゲームが可能です。
で、これをベースにして擬似コードを書いてみると。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | // 制約条件を設定Task.制約("40時間勤務");Task.制約("残業なし");Task.制約("リリース時期", 2012/01/01 );// 属人性, 能力差ポイントを設定Person("masuda").属人性("HP", 100 );Person("masuda").属人性("MP", 200 ); // 魔法が使えるとかPerson("tomoaki").属人性("HP", 200 ); // 体力が多いとかPerson("tomoaki").属人性("MP", 50 ); // リソース(配員)を設定Plan.リソース(Person("masuda"), 0.5 );Plan.リソース(Person("tomoaki"), 1.0 );// タスクの作業ポイントを設定Task("本タスク").作業ポイント( 200 );// 連携を設定Task("前タスク") -> Task("本タスク");Task("本タスク") -> Task("後タスク"); |
こういう風に設定しておいて、
1 2 | // ガントチャートを作成してPlan.CreateGanttChart(); |
シミュレートする場合は、こんな風に。
1 2 | // こんな風にして、100 回ほどシミュレートするPlan.Simulate(100) |
現実にプロジェクトの実績を入れる場合は、次のように。
1 2 3 4 5 6 7 8 9 10 11 12 13 | // 実績を設定Plan.Task("本タスク").実績( 100 );// タスクが無くなったら、即削除して再計画Plan.RemoveTask("削除タスク");Plan.CreateGanttChart();// タスクが増えたら、即追加して再計画Plan.AddTask("追加タスク");Plan.CreateGanttChart();// タスクが追加されたので、シミュレーションをやり直してみる。Plan.Simulate(100) |
ここで、成功確率なんかが出ると、実に「それらしい」感じになるんでうすがどうでしょう？
アジャイルが一見すると「計画」を捨てているように見えるのは、それぞれのタスク/ストーリーカードの繋がりを「視覚化」しないところにあります。これは、視覚化することによるオーバーヘッドを避ける≒コミュニケーションコストを下げる、ことに一役買っています。
なので、逆に言えば、計画を視覚化することのコストが限りなく低ければ、再計画時の情報となるので、不明確部分が減り、成功確率があがります（と予想されます）。まぁ、計画倒れとか取らぬ狸のなんとやら、というのもありますから「再計画」が絶対という訳ではありませんが、ひとつの選択肢が増えますよね、ってことで。
