このページをはてなブックマークに追加このページを含むはてなブックマーク このページをlivedoor クリップに追加このページを含むlivedoor クリップ

目次

プロジェクトマネジメント

  • 始まりはトップからでも現場からでもよいが、社内に広く普及させ、展開し、組織に定着させるスピードを考えると、トップダウンであることが必要である。
  • プロジェクトマネジメントを導入し、進化させていくときに考えるべきことは、いかにして競合他社より先にプロジェクトマネジメントを進化させていくかということである。
    • 優れたプロジェクトマネジメントは会社組織にとってよいものだけではない。顧客にとっても役立つものなのである。
  • プロジェクト管理ツールをチームビルディングコミュニケーションなどのツールとして適切に利用する。
  • プロジェクトマネジメントを導入することでプロジェクトの成功確率が上がり、利益も増える。
    • 顧客満足度の向上により、プロジェクトの受注が増えるため、利益も増えるのである。
  • プロジェクトマネジメントを進化させるものは、ナレッジ(プロジェクトでの成功や失敗の経験・教訓)である。
    • ナレッジと切り離すと、プロジェクトマネジメントは成長することをやめ、そこで留まってしまう。
    • よって、プロジェクトマネジメントを進化させていくには、ナレッジマネジメントと統合させていく必要がある。
  • 一般のプロジェクトマネジメント手法の基本は、作業を分解して、作業間の依存関係を分析し、これを管理するものである。
    • 旧来から線表として一般的に使われてきたものである。
    • WBS(Work Breakdown Structure)と呼ばれる詳細作業を構造化したものを作成する。
  • ソフトウェア作りのプロジェクトでは、段取りだけでうまくいくことはない。
    • 第1の理由は、最初からWBSを明確に定義することが難しいからである。
      • 要件の分析、設計、プログラミング、テストといった大局の流れは定義できるが、要件分析をして初めて設計の作業が見えてくるし、設計が完了してからでないとプログラム開発の部分も作業定義することができない。場合によっては、設計まで進んでから新しい要件が見えてくることもある。
      • つまり、どのような段階でも作業を明確にすることが難しい。
      • 中間的な成果物を含めて依存関係もあるから、作業間の段取りも動的に変化していく。
    • 第2の理由は、そもそもプロジェクトを定義することが難しいからである。
      • ソフトウェアは製品をリリースしたり、納品したら終わりではない。実行・稼働し続けるものであるし、そこで新たな課題も出現し、対応していく必要がある。
      • 初期構築段階や、とりあえず納品やリリースまでを一区切りのプロジェクトと見なすことはできるが、リリース後のことや、ライフサイクルをマネジメントすることの関係が大きい。

プロジェクトマネジメントと通常のマネジメントの違い

  • プロジェクトマネジメント
    • 始まりと終わりが存在する。
  • 通常のマネジメント
    • 継続を前提としており、永遠に続く。

プロジェクトマネジメントの質的変化

  • 1960年代〜1980年代
    • 伝統的プロジェクトマネジメント
      • コスト・納期・品質に注目する。
  • 1990年代以降
    • モダンプロジェクトマネジメント
      • (コスト・納期・品質に加えて)、リスク・スコープ・コミュニケーション・チームビルディングに注目する。

参考文献

  • 『プロジェクトはなぜ失敗するのか』
  • 『ソフトウェア開発はなぜ難しいのか 「人月の神話」を超えて』