プロジェクト・リーダーの心得

2010年9月6日(月)
横山 弘典

プロジェクト管理の基本を言葉で説明することは、実はそれほど難しくありません。PMBOK(Project Management Body of Knowledge)やCMM(Capability Maturity Model)のようなベスト・プラクティス集を参照すれば、理屈を理解することは可能だと考えます。ただ、理屈を理解したとしても、実際にいざ実践となった場合に、途端に難しくなるのが現実です。

連載の第1回では、若手のプロジェクト・リーダーを対象に、筆者が現場で培った、リーダーとして実践すべき心得について解説します。

筆者が考えるプロジェクト管理の要素とは、(1)プロジェクトの方向付け、(2)資源の最適配分、(3)人の動かし方、の3つです。以下では、それぞれについて細かく説明します。

(1)プロジェクトの方向付け

「プロジェクトの方向付け」とは、簡単に言うと"戦略"です。

プロジェクトのゴールは、システムを利用するユーザーが「システムを導入する目的」を理解して、「描いているビジョン」を達成することです。このためには、外部環境や内部環境を分析し、成功への方向付けを決める必要があります。これらの内容は、要件定義のフェーズで、ユーザーに対して詳細なヒアリングを行って決めていきます。

図1: プロジェクトの目的例(クリックで拡大)

この「方向付け」をどうするかによって、プロジェクトの命運、ひいてはユーザーのビジネスの命運が決まります。方向付けが正しく行われることは、プロジェクトが成功するかどうかの最低必要条件です。

リーダーが方向付けを誤った場合、どんなに優秀なメンバーがいても、プロジェクトを成功させることはできません。なぜならば、「プロジェクト管理」を行うためには、正しい方向付けができていることが大前提だからです。

方向付けが誤っているのに、適切なプロジェクト管理が実施されてしまうケースがあります。この場合は、目も当てられません。品質、納期、コストのすべてが満たせている「使えない」システムができあがってしまうのです。まさに本末転倒です。

「方向付け」の、具体的な例を考えてみましょう。方向付けとは、「誰が何をやり、何をやらないか、を決めること」です。ここでは、(a)システム概要図と(b)WBS(Work Breakdown Structure)を使います。

図2: システム概要図(クリックで拡大)

(a)システム概要図では、ユーザーの業務全体を図として表すことが大切です。全体の概要図を描いた後で、自分たちのチームがかかわるべきシステム化範囲を明確にします。大規模なプロジェクトになればなるほど、この作業の必要性が増していきます。

図3: WBS(クリックで拡大)

(b)さらに、WBSを使ってタスクを洗い出します。大切なポイントは、プロジェクト・リーダーが「何をやるか、やらないか」を正しく判断できる能力を持っていることです。WBSは、ユーザーのRFP(Request For Proposal)やヒアリング要件に基付いて作成しますが、ここでは、「やること」だけでなく「やらないこと」も明確にする必要があります。

これらのビジョンは、ユーザーとの間だけでなく、プロジェクト・メンバーとの間でも共有しておく必要があります。

株式会社システムインテグレータ 開発本部 ECソリューション開発部

1982年9月1日生まれ。株式会社システムインテグレータ勤務。ECソリューション開発部所属。地元宮崎と芋焼酎をこよなく愛するシステム・エンジニア。現在はコンシューマ向けの多言語ECサイト構築に携わる。少しでも世の中を便利にできるWebサービスを作るべく日々奮闘中。
 

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています