検証可能な計画言語ってことで、おおまかな目標のメモです。Javaのカラー本を真似してして色分けしてみました。「色」自体に意味があるのですが、これは後ほど。
ざっと見て分かるとおり、PDCA(Plan/Do/Check/Action)を元に情報の流れをチェックしています。データの流れも PDCA に順じているので、このフローを使うことになるのかなと。
■計画(Plan)
いきなり、Gantt Chart を作り始めるのは無謀なので、WBS なり、ストーリーカードなりで項目の抽出を行います。
作業項目の抽出は、主に 3 つの方法があります。
・PMBOK/WBS のようにトップダウンで
・XP/SCRUM のようにボトムアップで
・CCPM のようにエンドから
いずれにしても、「タスク抽出」という工程になりますね。このあたりは、plan なところで、抽出したタスクには、属性があります。
・作業量（人月/人日/人時間/作業ポイント/ストーリーポイント)
このタスクを実行する場合に、属人性の高さにより 3 つに分けられます。
・誰がやっても、一定時間かかる作業
・属人性がある作業（専門など）
・能力差がある作業（人依存）
属人性と能力差の例としては、
・そのプロジェクトに従事していた人であれば、○○時間で済むが、別の人をアサインすると××時間、これが「属人性」
・同じプログラミングでも、ベテランの人がやれば○○時間で済むが、新人がやれば××時間かかる、これが「能力差」
となります。属人性の場合は、年齢や経験よりも「専門性」が重視され、能力差の場合は「経験」が重視されるという形です。このあたりを加味しないと、正確なガントチャートはできませんよね、という具合です。
■実行(Do)
計画に従って実行する訳ですが、ここでは実際に実行する場合とシミュレーションする場合との 2 つに分けます。
シミュレーションの場合は、XP で言うところの「計画ゲーム」であったり「ブレーンストーミング」であったりします。
サイコロを転がしてゲーム的にやってもいいのですが、コンピュータのパワーを使ってランダム要素で、100 回ぐらいプロジェクトを稼動させれば、それなりに収束するような気もします。
このあたりは、ワインバーグ氏がシステムダイナミクスを使ったり、ゴールドラット氏が CCPM のシミュレーションをしたりしています。
■監査(Check)
進捗なり実績を入れたならば、チェックしなければ意味がありません。逆に言えば、チェックする必要の無い値ならば、観察する必要はありません、というのがデマルコの言葉です。
なので、実績に従って、進捗率を計算します。EVM でも良いし、工事進行基準でも良いし、バーンダウンチャートでも良いし、よく言われる「見える化」ってのは、ここのことですね。
■見直し(Action)
世の中のプロジェクトで一番できていないのが、この見直し/再計画です。
最初の計画からずれていてもそのまま進めてしまったり、現実と離れているにもかかわらず計画表を直さなかったり…と言いますか、計画/配員表のメンテナンスそのものに労力が掛かり過ぎるために、計画を見直さないという状態がほとんどです。現状と乖離しているわけですね。
なので、VPL(Verifiable Plan Language)では、この部分を厚く保護していきます。
・タスクの追加や削除
・配員（リソース）を調節
・スケジュール（プロジェクト期間、マイルストーン）を調節
が「手軽に」できるようにします。まぁ、少なくとも計画(Plan)と同じ程度の手間でできるようにします。
さて、これを具体的にどうするのかというのを落とし込みますか。
