業務分析、要求定義は「計画活動」

　計画活動のあるべき姿を「計画」し、実行してください。
　プロジェクト・ネットワーク図を繰り返し使って下さい。

　私自身は理解するのに随分とかかりましたが、プロジェクト・ネットワーク図を使い始めてしばらくすると、どうなるかについて、お話ししてしまいます。

　『プロジェクト・ネットワーク図を使い始めると、当然のように「計画活動のあるべき姿」を考える』様になります。

　なぜなら、ガント・チャートのように、『全く根拠が無くても今日から納期までの期間の比率分割で、見栄えのする「線表」がつくれる』ということがないからです。
　相応の情報がないと、すぐに作るのに困ります。

　面倒くさいので、さっと憶測のアクティビティで作ってしまいそうになりますが、それには全く意味がないどころか、その「計画作成時の面倒くささの優先こそが悪、全ての元凶」である事に、何回かの繰り返しで身をもって気がつくわけです。

　そんなときに、それまでのガント・チャートのみでの計画作成がいったいなんだったのか、理想像でも何でもない事に気がつき（※）、ゾッとします。しかも、どうも世の中がそれで回っているらしい事にもゾッとします。

　業務システム開発を対象とした場合、『要求定義が終わる前の設計以降のプロジェクト・ネットワーク図作成は不可能である』という事実にすぐ気がつきます。

　要求定義がキチンと終わって初めて「何を作るプロジェクトなのかが決まる」のですから、逆に言えば、それまではスケジューリングする対象が存在しないのです（なんだかもの凄く当たり前ですが...）。

　とたんに、最初の契約時に営業担当が提示した計画から、ちょっとズレただけで大騒ぎしている景色をみていて、（申し訳ないのですが）きわめて残念な眺めである事に２２，３才で業界入りたての私ですら、気がついてしまいます。「え？これをオレもやらなきゃなんないの？」
　

• 最も初期段階の計画活動で一定以上詳細にスケジューリング出来るのは「業務分析」と「要求定義」のみである。ただし、これらの活動を「徹底的に」行う計画とする
• 『「業務分析」「要求定義」までは、「システム設計」以降のスケジューリングのための「情報収集活動」である。あくまで計画活動の一環である』　という「事実」を顧客システム開発担当含め、ＩＴ業界全体の共通認識、常識とする必要がある

※　自分がプログラミングまで行わない人は、それでも分からないかもしれません。ですので、業務システム開発を業務とする企業のマネジャー以上、 トップまでは本来、『「絶対に」ヘビーなプロジェクトのプログラマを繰り返し経験「しなければならない」』と私は考えています。「実体験」以外は、あくまで「代替案」でしかありません。