プロジェクトマネジメント能力を体得する方法

新規事業立ち上げの実行フェーズに欠かせないスキルにプロジェクトマネジメント能力がある。

プロジェクト管理の能力は、期限がタイトかつ複雑な仕事をこなすことで体得できる。

いわゆる「プロジェクト」である必要はない

「プロジェクト」というとシステム構築などのイメージを持つことが多いかと思うが、実は仕事の内容はなんでも良い。

じっさい僕がプロジェクト管理を身につけたのは、日立でイベント準備の事務局を担当したときだった。

イベント自体は日立製作所の社会的存在意義に比べたら、究極やってもやらなくても問題ないようなものだったが、やるとなったら準備は大変だ。

何しろ大企業だけあって関係者が多い。

自分が担当したパートだけでも100名を超える関係者がいて、多種多様なセミナーや展示の手配が求められる。

事務局というと端役だが、今にして思えば相当案件規模の大きなプロジェクトマネージャーの役割そのものだった。

新卒1年目からいくつかのイベントの進行に携わったことで、進行管理の能力は異常に高まった。

その後、ヤフーでも多数のプロジェクトを兼務で担当したが、全部合わせても日立時代のイベント単体よりむしろ複雑度は低かった。

たしかに大企業には多かれ少なかれ大企業病はある。しかし、 担当する仕事そのものの意義とそこで身につく能力はまた別 だ。

「若いうちの苦労は買ってでもしろ」というのは、こういうことを指すと思う。

プロジェクト管理能力を養える仕事の要素

プロジェクトマネージャーは経験により育つとして、どのような仕事がスキルアップに向くのだろうか。

僕の感覚では、以下のような要素からプロジェクトの複雑さを測れると思っている。

メンバー
- 関係者の頭数が多い
- 外部関係者など、連絡手段に制約が多いメンバーを含む
- メンバー間で連絡を取り合わない組織になっている
- 協力的ではないメンバーを含む
タスク
- ゴール達成までに複数の組織、部署が関わる
- あるパートを完了するために別のパートが完了しないと進められない
- 完了できるかどうか見通しが立たない

過去担当したなかで難易度が高かった案件は、上の条件をほとんど満たしていた。

ガントチャートをひいてみないと管理できないし、ひいた結果どうやってもスケジュールに納まらないことが着手前から分かったりする。

進行管理役は2種類の時を管理する

プロジェクトの進行管理は、単にガントチャートをひいて進捗を追う、というだけでは足りない。

進行管理役は2種類の相反する時間を管理する必要がある。

正常系を確保するためのリードタイム設計
- プロジェクトのうち、期間内で成果を出せる可能性が高いものを「正常系」と呼ぶと、正常系の作業に対してできることは「十分な時間を確保して予定を変えない」ことだ。プロジェクトは生き物だから刻々と状況は変わるが、成果の読めるパートは前提条件が変わらないよう配慮し続ける必要がある
異常系をなんとかし続けるネゴシエーション
- 複雑プロジェクトには成果の出ない「異常系」の作業が必ず出てくる。教科書的に考えると、異常系をなるべく小さく維持することがプロマネの仕事だと思うかもしれない。ところが、じっさいには異常系は最後まで異常なのだ。癌と生きる、ではないが、このようなタスクは早期発見して関係各所とひたすら交渉を重ねてゴールを迎えることが重要だ。

この2つの使い分けができるようになるためには、 ガントチャートの時間進行が、作業を割り振られた各担当者のリアルな心情として生々しく実感できなくてはならない 。

ガントチャートの失敗学

ガントチャート作成の失敗事例から、進行管理の初歩的な課題を学ぶケーススタディ。
異常なチャート形状から問題点を分析する。

詳細度不足で管理できていない事例

「完成」という言葉が多用されているが、実際には期間を持ったタスクは「作成」などが適切。完成はマイルストーンなどに用いる。
「デザイン完成」のラインが突出して長い。これだと約2ヶ月間の状況を追えない展開となる。中間成果物の分割やレビューなどによる、タスク分解が求められる。

中間アウトプットを意識しきれていない事例

サイト改訂では、「①文章、②画像→③HTML」のアウトプットが必要となる。上記の例では、アウトプットに合わせて、Q&A、インタビュー文、メッセージ文のそれぞれにつき、①～③のタスクを設定した方が管理しやすい。

孤立タスク乱立事例

ToDoリスト的にタスクだけ記入した例。実行可能性のない期日設定のまま放置されたため「昨日やるはずだった」以上の対策が立たなかった
確実なスケジュール見通しがないタスクについても、依存関係を設定し、現実的と思われる実行期間を設定すべき
とくに最終目標日から逆算して、特定の期日に終わっている必要のあるものについては、しっかり位置づけないと過ぎてから気づいてあわてることになる。

期限ギリギリで駆け込み対応となった事例

様々な開始時期に対して、ゴールがきれいに１時点に揃ってしまっている。事前に必要なタスクを洗い出せず、あとから次々とタスクが発覚した典型パターン。
複数の予期せぬタスクが発生した場合、全体の進捗が危うくなることが多いので、タスクの依存関係や進行リスクなどをどこかで見直すべきだった。

棚ざらし案件事例

タスクを消化しないまま寝かしていた例。もともとのタスク設定の難易度が高く、かつ優先度が低かった案件。
少なくとも着手しない期間については開始を遅らせて、他タスクの空き時期に終了マイルストーンを設定した方がベター。
直接実行することが難しい場合は、ブレークダウンして再設定した方が良い。

立案漏れからの立て直し不良事例

後続のタスクとの間に**「期間1日」のタスクが多数**割り込んだ例。当初のタスク立案時点で漏れていた項目が多数あり、全体スケジュールに押されて「今日、明日で完了させなくては」という展開に。
「業務フロー（列挙型）作成」に着手する時点でサブタスクを具体化できていなかった。「ドメイン設定～」のタスクだけをやれば完了するかのような錯覚に陥って時間を空費している。
25日の追加タスクが発見された際に、他に漏れているタスクがないかを検証する機会があったはずだが、見過ごしている。
追加タスク設定にあたり、余裕期間を考慮できていない。後からあわてて対応するタスクが本当に1日で完了するのか怪しいケース。
この例のように後から無理やり詰め込んだ場合、後続タスクへの影響が大きい可能性が高い。複数のタスクに漏れがあった場合、全体への影響を冷静に評価しなくてはならない。