ほとんどのプロジェクトが、プロジェクトマネジメントの基本的なプロセスに従っていない。「終わりよければ、すべてよし」という結果に至ればまだマシなほうで、たいていのプロジェクトは、テストプロセスでバグつぶしに追われ、運よく運用が開始されたとしても、その後で多くのトラブルに見舞われることになる。

　たとえ不確定要素が多いシステム開発であっても、古くから「段取り八分、仕上げ二分」といわれるように、十分な計画をしてさえいれば、プロジェクトにおける数多くの無理や矛盾を解消し、プロジェクトを進めていけるはずなのである。

　すでに何度も記述してきたように、プロジェクトマネジメントをKKDで行うことには無理がある。そして、マネジメントの基本を知らないままにプロジェクトが進められている中で、OJTによってマネジメントができる人材が育つわけがない。

　プロジェクトの問題をマネジメント技法の導入によって成立させようという安易な考え方がはびこっている。しかし、多くの問題は、明らかに「計画性のなさ」に起因している。計画を行わないことが、多くのトラブルを生んでいるが、プロジェクトマネジメントを行っているつもりの人間は、「業者に技術力が足りない」とばかりに無反省な状態である。確かに、システム開発に関わる技術者のレベル低下は著しいが、その半面で、プロジェクトのスキルレベルの明確な定義も、プロジェクトにおける個々のメンバが担うべき役割や責任も、明確にできていない。プロジェクトが「無計画」に進められた結果であることに変わりはないのである。

　綿密に計画することと、正確に現状を把握した上で的確な判断をすることは、プロジェクトマネジメントのイロハである。

作業内容

　作業内容が明確になっていないことで、作業の抜けが生まれる。作業の抜けに気がついたときには、作業リソースが不足していたり、その作業をするために必要な時間が残されていなかったりする。プロジェクトメンバが複数の業者によって構成され、さらに一括発注により金額が固定になっている場合には、想定外の作業に対する押しつけ合いが生まれたり、「その作業は当初要求されたものではない」とか、「想定外の作業が多数発生したために、工数が大幅にオーバーした」というような文句が出てきたりする可能性が高い。

プロジェクト体制

　プロジェクト体制における問題のほとんどは、作業内容の明確化が行われていないことに起因している。さらに、プロジェクト体制を原因とする問題が顕在化したときに、根本的な原因がプロジェクト体制に起因していることに気がつきにくい、あるいはほかに責任を転嫁しやすいという性質を持つ。体制の問題ではなく、下請け業者の能力に問題があるとみなされてしまうことが、あまりにも多いのである。

　プロジェクト計画書には、体制図が記載されており、一見するとそれぞれの役割・責任・権限が明確になっているかのように見える。しかし、実際にプロジェクトが開始されると、技術者は役割・責任・権限が明確化されていないことを認識する。

　しかし、残念なことに、プロジェクトマネージャはこれに気がつかない。あるいは気がついていても、気がつかないフリをしたままプロジェクトを進めていく。業者の扱いに慣れたプロジェクトマネージャであれば、作業内容を明確にできていないことを補うために、役割・責任・権限を不明確にしておく。役割・責任・権限は、その場の状況を見て変えていくことで、「想定外の作業」を「当初から決められていたこと」として誰かに押しつけるのである。

　しかし、このような押しつけをしても、その場しのぎの対処にしかならない。役割・責任・権限と作業内容を不明確にしておくことで、結果として作業の空白地帯が生まれたり、責任の境界がグレーになったりする。そこで発生するのが品質の低下である。誰もが当事者意識を持たないまま、いいかげんに作業し、結果責任は取らないという仕事をするのが常だ。

　作業内容が明確化されず、プロジェクトにおける個々の役割・責任・権限が決まっていないということは、適材適所に必要なスキルを持つ人材がアサインされないという、プロジェクト運営上、最も重大な問題に直面しかねない。個々の作業を明確にしていない状態では、それぞれの作業に必要なスキルの洗い出しができるわけがないのである。

　さらに、頻繁に発生するのが人的リソースの不足である。作業内容もボリュームも不明確なままに、「このくらいの人数がいれば、なんとかなるだろう」という根拠のないリソース見積もりをしている。もはやプロジェクトと呼ぶことはできず、ばくちの世界である。

スケジュール

　多くのプロジェクトでは、作業内容が不明確なことが、プロジェクト体制に問題を残し、さらにスケジュールに影響を与える。このような状況下で作られたスケジュールには、以下のような傾向がある。

• 納品期日から逆算しただけのスケジュール
• 予備日程を見込んだスケジュール
• 残業時間を見込んだスケジュール

　作業内容が不明確なままで、スケジュールが作成されるということは、プロセス区分に日程を加えたレベルのスケジュールになってしまう。基本設計は1カ月、詳細設計は半月、プログラミングは2カ月、テストは1カ月、といった具合である。納期から単に逆算しただけのスケジュールは、下手をすると実現が不可能な場合がある。実現可能性の判断ができないプロジェクトほど危険なものはないだろう。

　また、予備日程や残業時間を見込んだスケジュールは計画性がない。なぜならば、ところどころに日程上の余裕を持ったとしても、実際にどの作業で進捗が停滞するかの予測は不可能だからである。進捗管理のあるべき姿とは、予定と実績を把握し、常に変化に対応して適切なリソースの割り当てやリスケジューリングを行うことである。

進捗管理

　実現性に無理があるスケジュールでは、進捗の維持も不可能である。十分に実現可能なスケジュールであっても、実際に行われている進捗管理には問題が多い。安易な「90％完了しています」という報告は何の意味もなさないのである。「百里を行く者は九十里を半ばとす」という諺もあるように、「90％完了」の後は、なかなか進捗しない。現実には、残りのたった10％を達成するために、90％を達成したのに使った時間の倍以上の時間が必要な場合もある。

10.1. 段取りなしの現場状況 ハッピィ・エンジニアリング関連ページ

10.2. 段取り八分

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.3. 作業の明確化

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.4. ネットワーク図の作成

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.5. リソース計画

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.6. 見積もり

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.7. スケジュールの作成

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

10.8. 進捗管理

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。