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

投稿日: 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 を作成するプロセスをプログラミングします。って、言っても分かりづらいので、実例を。

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 パーマリンク