久し振りにアナリシスパターンを紐解いて計画パターンを見直す

投稿日: 2011/03/22 作成者: masuda

Verifiable Plan Language(検証可能な計画言語の思索)
http://plan-language.com/

ってことで、【ネタ的に】ドメインを取って、ひとまず wordpress を立てました。

言語ってことになっていますが、UML のように記号化のところに重きを置くのではなくて、【検証可能な】というのが主題です。なので、プログラム言語自体は、F# でも C# でも何でもいいのです（ってのが目標）。当面は、私の知っている言語が対象になるので、C#, F#, Java, PHP ですねぇ。スクリプト系の言語として、Python か Ruby なんですが。多分、Python になると思います。

さて、Verifable Plan Language 略して VPL は、計画段階からプロジェクト/プロダクトのプロセスの実行までを言語化します…って、こういうと自分でも何を言っているか分からないのですがｗ、PMBOK の Planning プロセスを言語化するというのが正しいのかなぁ。WBS なり、Gantt Chart なり、IDEF0 や DFD なりと planning から design process にながっる手法はいくつかあるのですが、やっぱり「検証できない」というのが致命的だと思っています。

そう、その計画は「妥当なのか？」というの妥当性は、プロジェクトの最後にならないと分からないとう「不確実性」を抱えたままなのです。勿論、プロジェクトの初期段階では、不確実性が多いのは確かなのですが、プロジェクトの終わりになっても「同じ計画を抱えたまま」では不確実性が多いままになってしまうのが問題です。現実問題として、明日リリースできるものが手元にあるのであれば、不確実性は限りなく 0 に近いと言えるわけです(勿論、不慮の事故というのもあるんですが）。

で、この手の論証なんかは、plan-language.com のほうでやるとして(moonmile.net/blog のほうは、もっと現場に接した「技術」的なところのおすそ分けなので)、ここでは、UIDD 的に WBS を作成するプロセスをプログラミングします。って、言っても分かりづらいので、実例を。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
namespace PlanLanguage.Test
{
    public class TestGanttChart
    {
        public void MakeWBS()
        {
            // プロジェクトを作成する
            var proj = new WBSProject("WBSプロジェクトの作成");
             
            // トップダウンでWBSを作成する
            proj.CreateWBS("100", "要件定義");
            proj.CreateWBS("200", "設計工程");
            proj.CreateWBS("300", "実装工程");
            proj.CreateWBS("400", "結合試験");
            proj.CreateWBS("500", "システム試験");
            proj.CreateWBS("600", "試験運用");
 
            // ブレークダウン
            proj.WBS["100"].BreakDown("101", "機能要件");
            proj.WBS["100"].BreakDown("102", "性能要件");
            proj.WBS["100"].BreakDown("103", "開発期間");
            proj.WBS["100"].BreakDown("104", "開発規模(金額)");
            proj.WBS["100"].BreakDown("105", "開発規模(人員)");
            proj.WBS["100"].BreakDown("106", "システム概要設計");
            proj.WBS["100"].BreakDown("107", "既存システム解析");
 
            // PERT情報(期間)を設定
            proj.WBS["101"].Period = 10;
            proj.WBS["102"].Period = 10;
            proj.WBS["103"].Period = 5;
            proj.WBS["104"].Period = 5;
            // PERT情報(前後関係)を設定
            proj.TopWBS.NextTask = proj.WBS["101"];
            proj.WBS["101"].NextTask = proj.WBS["102"]; // 並行作業
            proj.WBS["101"].NextTask = proj.WBS["103"]; //
            proj.WBS["102"].NextTask = proj.WBS["104"]; // 合流
            proj.WBS["103"].NextTask = proj.WBS["104"];
            proj.WBS["104"].NextTask = proj.WBS["105"];
 
            // マイルストーンの設定
            proj.TopWBS.MileStone = new DateTime(2011, 4, 1);
 
            // リソースを設定
            proj.AddStaff("masuda", 0.5);
            proj.AddStaff("yamada", 1.0);
            proj.AddStaff("tomoaki",1.0);
             
            // ガントチャート作成
            GanttChart gc = proj.CreateGanntChart();
 
            // クリティカルパスの取得
            List<WBS> cp = proj.GetCriticalPath();
        }
    }
}

WBS(Work Break down Structure)の作り方は、各社まちまちなのでここでは解説しませんが、大まかに言えば「トップダウン」で作ります。トップにプロジェクト自身があって、下へ下へとツリー状になっていきます。WBS の良いところは(PMBOK で言われていることは)、各タスクが重複しないところです。トップダウンで分類がされているので、下層にあるタスクは重複しません。
# と同時に、「重複できない」という制限があるのですが。これは論理学的にという意味で。

手順としては、

1. 大項目の WBS を出す。
2. WBS を作業単位になるまでブレークダウンする。
3. PERT 図を作成するための、期間(period)と前後関係(relation)を設定する。
4. Gantt Chart にするために、時間軸(マイルストーンなど)を設定する。
5. リソース(人,場所,機械など)を設定
6. ガントチャートを作成

という流れになります。

# コードのほうは、Project に直接挿入しているけど、本来は Plan ですよね。
# これは後から修正。

で、ここまでは計画段階なので、この計画を基にして実行プロセスを動かします。
PMBOK では、実行プロセスは非常に薄い(進捗管理程度しかない)のですが、現場のプロジェクトとしては、

・各タスクの進捗率
・各タスクの遅延状況
・タスクの削除/追加
・再計画/スケジューリング

が必須になります。あと、人員が減ることもある(俗に言う、ウエディングリスク)ので、これを実行プロセスを言語化します。

もうひとつ、CCPM 的に、タスクの遅延確率(あるいはプロジェクトバッファ)を計算する必要があるので、全体スケジュールに影響を及ぼす可能性のあるタスク(合流タスク、あるいは障壁となるタスク)の監視を行います。

こっちの具体例はのちほど。

カテゴリー: UIDD, プロジェクト管理, Plan Language パーマリンク