 |
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| なぜプロジェクト管理技術は必要なのか | ||||||||||
|
システム開発プロジェクトを管理・遂行していくのは、大変に骨の折れる仕事です。見積もり手法1つを取ってみても、KKD法、FP法、COCOMO2、機能一覧法（積み上げ式）、LOC（Lines Of Code：プログラム行数）式など、思いつくままにあげても相当な数に上ります。 さらに、最新の見積もり手法もキャッチアップしていくならば、先ごろ日本情報システム・ユーザー協会が発表した「システム開発プロジェクトの標準工期は投入人月の立方根の2.4倍」といった内容も考慮に入れていく必要があるでしょう。また、実務でのプロジェクト見積もりとなると、見積もり提出期限という制約や顧客からのRFP資料の不足など、様々なリスク要因が追加されていることも珍しくありません。 見積もりはプロジェクト管理の一部に過ぎません。しかし、いまだどのシステム開発プロジェクトにもあてはまるような方法論がないことが、さらにシステム管理というタスクを強大なモンスターにみせているのではないでしょうか。 このような困難な状況に立ち向かうためのプロジェクト管理技術は「羅針盤」とでもいうべき存在です。しかも、さらに複雑な要素が組み合わせられるべき技術のため「羅針盤（システムカットオーバーのイメージ共有）」と「スタッフ管理（進捗管理など）」「海の潮目読み能力（ステークホルダーの見極め、要件の整理）」などを総合した「航海術」とでもいうべきものが、今日の「システム開発プロジェクト管理」技術の本質だといえるでしょう。 この技術を十全に活用することができれば、システム開発プロジェクトを成功に導くための大きな力となります。だからこそ、プロジェクト管理技術は必要とされているのです。 |
||||||||||
| プロジェクト管理は「お客様に対するサービス業」 | ||||||||||
|
本連載は対象読者として「プロジェクト管理を少し経験したことがある」あるいは「これから行う」「興味がある」という方々を想定しています。読者の中には、コーチングやPMBOK資格の勉強をはじめとした、いわゆるプロジェクトマネージャ（以下、PM）やプロジェクトリーダ（以下、PL）の業務研修を受けた方もいらっしゃるでしょう。 そういった方々なら、実地で起こり得る様々な事象に対応する力を身につけるには、一朝一夕では実現できないと感じているのではないでしょうか。 その答えの1つは、このシステム開発におけるプロジェクト管理という仕事が「お客様に対するサービス業」であるという点です。そこには「お客様の業務要件を正しくヒアリング、最適な課題解決ソリューションを提案」かつ「メンバーの進捗管理、課題解決をサポート」し、「原価や納期も管理して、予定通りに収めなければならない」という、どれ1つ取っても一筋縄ではいかないミッションを複数同時に遂行する必要があるのです。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
