 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 解らないことが解らないままの計画 | ||||||||||
|
随分と長く前置きを書いてしまいましたが結果として起こっているのは、プロジェクトマネジャーも仕様策定者（SE）も、実は何を作るのかを細かく具体的に解っていないまま、計画を立て、そもそも根拠のない計画を死守しようとしているということです。担当者としては、そうでないと顧客に怒られる、そんな感じで開発を進めているという印象が感じられます。 「第1回：プロジェクトのコストを管理するアーンド・バリュー法」で解説した「段階的詳細化」に対する理解のなさなども根は一緒です。これが何とかならない限り、業務システムの開発は常に不幸な仕事だということになりかねません。逆に言えば、これを理解しているだけで不幸は解決する可能性があるということです。それは最初にあげた例が、証明していると思います。 では、どうするかということですが、プロジェクトの初期段階を、本連載の主題であるPMBOK第3版に書かれているように進めれば良いのです。プロジェクト憲章が発行されてプロジェクトが公式にスタートしたら、最初に可能な限り、プロジェクトで何を実現しようとしているのか、スコープに関する情報を少しでも沢山集めます。「プロジェクト・スコープ記述書暫定版作成」プロセスは、前記の筆者の進め方でいえば、最初にできる限り顧客の情報を集めるタイミングを指します。 それに基づいて、業務分析から要件定義ぐらいまでを明確にした、初期段階の計画をたてます。これは、最初の「プロジェクトマネジメント計画書作成」プロセスにあたります。そして計画に基づいて、業務分析をシッカリ行います。そして業務分析の情報を元に、今回の開発では何を作るのか「要件定義」までを実施します。 「要件定義」の最終版ができあがるまでは、これの繰り返しではないでしょうか。 なぜなら、プロジェクト・スコープ記述書に記述すべき新たな要件が出続けている限りは「それは暫定版だった」ことになるからです。業務システム開発でいう「要件定義書」は、その開発で何を実現するのかを記述しているわけですから、PMBOKでいう「プロジェクト・スコープ記述書」に相当します。 「要件定義（プロジェクト・スコープ記述書）」が承認されて（暫定版から正式版となって）、何を実現するのかが明確になり、具体的なシステムの設計に取りかかれるようになって、ある意味初めて明確な根拠を持った「計画」といえるものになるはずです。筆者としては、この時点で自分が作った計画なら死守する気にもなりますが、先の例のような根拠のない計画を死守するというのは、どうしても納得が行かず、気力が湧きません。 そしてPMBOK第3版の記述は、「ただプロセスが並んでいる」のとは違い、ここまで読んでいただければ理解いただけると思いますが、筆者の経験から考えても、より成功する確率が高いプロセス構成であると実感することができました。 以上で、本連載を終了します。お読みいただきまして、ありがとうございました。ぜひ、ご意見ご感想など、お寄せ下さい。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
