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

目次

プロジェクト

  • プロジェクトの失敗を前提に事前の対策にエネルギーを多く費やすことで、失敗する確率、または失敗による影響度を減らすことに繋がる。
    • 逆にプロジェクトは成功して当然であると考えると、事前の対策より、失敗した後の担当者への責任追及などの事後対応が中心になる。
  • プロジェクトは有期性と独自性の2つの特徴を持つ。
    • 有期性とはプロジェクトは終わりなき業務でなく、期間が決まっていて、始まりと終わりが明確に定義できる活動ということである。つまり、プロジェクトは成果物(プロジェクト活動で作り出すもの)を生み出し、終わるための活動である。
    • 独自性とはプロジェクトを遂行する組織にとって今まで実施したことがない要素が含まれていることである。
      • まったく同一の仕事を繰り返すことはルーチンワークと呼び、プロジェクトとは区別される。
  • 「規模の大きいもの=プロジェクト」ではない。
  • 過去とまったく同じプロジェクトは存在しない。
    • プロジェクトは独自性を持つからである。
    • プロジェクトマネージャやプロジェクトチームはプロジェクトの進行に合わせて、これらの不明確な事項を明確にして適切な判断を下し、未知の要素に対処していかなければならない。
  • 何らかの適切なコントロールや行動を取らない限り、プロジェクトは失敗する。
  • 複数のプロジェクトを同時に実施する会社では、優先順位や最適化を計画する必要がある。
  • 顧客の成功と、会社組織にとっての成功が同じとは限らない。
  • プロジェクトを進めるにあたっては、変更があるという前提が必要である。
  • プロジェクトの真の成功とは、プロジェクト単独の成功と会社の成功と顧客の成功を満たすことである。
  • 受注のフェーズにおいて、会社としてのプロジェクト遂行目的を明確にして文書化していれば、プロジェクトの遂行途中でプロジェクトマネージャや関係者はもっと適切な判断ができる可能性がある。
  • 誰かが気付けばよいという発想ではミスは再発する。
  • 「プロジェクトの成功とは何ですか?」という問いかけがあれば、その後の意思決定は変わるはずである。
  • プロジェクトを通じて得られる教訓とノウハウは会社の財産である。
    • そのため、ノウハウや教訓を組織的に検討する。
      • PMO(プロジェクトマネジメントオフィス)のようなプロジェクトの教訓やノウハウを蓄積する部署を作る方法が有効である。
  • スケジュールを作る対象は必ず未知の要素が含まれた計画である。適切なリスクを考慮したスケジュールにしなければならない。その結果、不可能な納期である、または納期をある程度延ばさないとできない確率が高いのであれば、それをありのまま顧客に説明すべきである。そして、顧客を交えて次の点の検討を行う。
    • 顧客の納期の余裕度
    • 納期が遅れると、顧客にどのような影響があるか
    • 確実に納期に間に合わせるために、スコープ(プロジェクトにおける仕事の範囲)を2段階に分けることが可能か
      • これらの検討にはMS Office Projectのようなスケジュールを視覚化できるソフトウェアを使用し、プロジェクターで顧客と一緒にスケジュールを見ながらシミュレーションするのが効果的である。このようにスケジュールが視覚化されれば、顧客も納期が現実的でない理由を理解しやすくなる。さらに、顧客が検討に参加することで、お互いのコミュニケーションが改善されるという副次的なメリットもある。
  • 顧客の意思決定する範囲と、それがどのような影響をプロジェクトの進行に与えるかを、できれば最初の段階で顧客に伝える。
  • トップのサポートが必要であると判断すれば、自分から必要性を説明する機会を作るなどの行動を取る必要がある。
    • 一般にプロジェクトが難しいものであればあるほど、トップの強力なサポートが必要になる。
  • プロジェクトをKKD(経験・勘・度胸)で実施すると、いつかは座礁してしまう。
  • プロジェクトの成功確率を上げるには、計画された実務でのOJTとプロジェクトマネジメントの体系的な知識の習得が必要である。
  • 顧客はプロジェクトの遂行自体を希望しているのではなく、作り出されたシステムなどの成果物がもたらす効果を期待している。
  • 成功の状態を明確に定義すれば、適切な判断を選択できるようになる。それはモチベーションの向上にも役立つ。
  • リスクマネジメントはすべてのプロジェクトで実施する。特に、新しい環境の場合ほど念入りに行う。
  • 部門横断型のプロジェクトでは、出身母体も考え方も違うメンバー相手に適切なコミュニケーションを取りながらプロジェクトを遂行する必要がある。
  • 予備費は予期せぬ事態に対応するために必要なコストである。プロジェクトの不確実性や重要度に応じて見積もりに組み込む。
  • プロジェクトマネージャはプロジェクトをスタートする前に次の事項を必ず確認しておく必要がある。
    • 実現可能であるか
    • スコープは明確であるか
    • 見積もりで見落としはないか
    • 納期は現実的であるか
  • プロジェクトに参加する会社のメンバーが集まり、次の項目を決める。
    • プロジェクトの進め方のルール
    • プロジェクト遂行で使用する用語
    • プロジェクトマネジメントの考え方
    • 役割分担と責任範囲
    • コミュニケーションの取り方
      • これらは事前のすり合わせだけでは十分ではない。実際にプロジェクトを進めていく途中で新たにわかる問題もある。定期的に上記の内容を確認したり、改定するためのミーティングを行う。このようにしてプロジェクトマネジメントの方法を調整しながらプロジェクトを進めることで、摩擦が解消され、全体のパフォーマンスは上がる。
  • プロジェクトの成功確率を向上するための重要は3要素は次の通りである。
    • プロジェクトマネジメントを組織に導入する。
    • PMOを設立する。
    • 長期的な視点で人材を育成する。
  • 米国のプロジェクトマネージャは一般に全仕事時間の75〜95%をコミュニケーションに費やしているといわれている。
  • 戦略的なプロジェクトプランを立てる。
    • ハロルド・カーズナー博士は「計画しないのは、失敗へ向けての計画である」といっている。
  • スコープとスケジュールが目標として定められているプロジェクトでは、「成果物の完成が予定より大幅に遅れてしまったが、皆で頑張り、色々なことを学べたのだからプロジェクトは成功だ」という言葉は明らかに間違いである。
    • 「成果物の完成が予定より大幅に遅れてしまったのでプロジェクトは失敗だ。しかし、皆の頑張りには感謝したい。また、プロジェクトから色々な教訓を学べたという別の成果はあった」というのは間違いではない。
  • プロジェクトの成功・失敗は、制約条件のバランスをとり、目標を達成できたかどうかによって判断される。
  • 複数の制約条件のバランスを取りながら、プロジェクトを成功に導くためには、プロジェクトマネジメントが必要である。
  • 過去の経験により熟成される勘を働かせ、最後は思い切って一歩踏み出してみる度胸が重要である。
  • プロジェクトを完了させるには、要素成果物が要求事項にしたがって完成していることが必要である。
  • どんなに綿密な計画を作ったとしても、計画通りプロジェクトが実行できることは少なく、様々な理由により変更が発生する。
    • 統合変更管理プロセスはプロジェクトの開始から終了までに発生する変更を、マネジメントすることが目的である。
  • 承認作業にかかる時間を見積もる必要がある。
  • 問合せ先がきちんと伝達されているにもかかわらず、指定された問い合わせ先以外のところに問い合わせを行うプロジェクトチームメンバーが存在する場合がある。
    • 問合せ先の人には言いにくい、言っても自分の主張が通りにくい、コミュニケーションのルートの重要性を知らないなど、理由は様々である。
  • 行うべき作業が明確で作業工数が足りないのであれば、開発メンバーを増員することは一般的によい対策である。
    • しかし短期間の作業の場合、作業への習熟に時間がかかることもあり、想定通りの作業効率を上げることができない可能性がある。

プロジェクトと定常業務の比較

共通点

  • 限られた資源という制約を受ける。
  • 人が実施する。
  • 計画・実行・コントロールの対象となる。

相違点

  • プロジェクト
    • 有期性:あり
      • 明確な始まりと終わりがある。
    • 独自性:あり
      • たとえ過去に似たような作業があったとしても、作業者・作業内容・製品などに違いがある。
  • 定常業務
    • 有期性:なし
      • 作業開始時点では、紀元が決まっていない。
    • 独自性:なし
      • 同様の作業を繰り返して実施する。

  • プロジェクト
    • 新規製品の設計・開発
    • 受注時の手順・作業を定型化する業務
    • 企業合併に伴う経路業務
  • 定常業務
    • 既存瀬品の製造
    • 定型化された手順にしたがった受注業務
    • 日々の営業活動に伴う経路業務

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

  • 始まりはトップからでも現場からでもよいが、社内に広く普及させ、展開し、組織に定着させるスピードを考えると、トップダウンであることが必要である。
  • プロジェクトマネジメントを導入し、進化させていくときに考えるべきことは、いかにして競合他社より先にプロジェクトマネジメントを進化させていくかということである。
    • 優れたプロジェクトマネジメントは会社組織にとってよいものだけではない。顧客にとっても役立つものなのである。
  • プロジェクト管理ツールをチームビルディングコミュニケーションなどのツールとして適切に利用する。
  • プロジェクトマネジメントを導入することでプロジェクトの成功確率が上がり、利益も増える。
    • 顧客満足度の向上により、プロジェクトの受注が増えるため、利益も増えるのである。
  • プロジェクトマネジメントを進化させるものは、ナレッジ(プロジェクトでの成功や失敗の経験・教訓)である。
    • ナレッジと切り離すと、プロジェクトマネジメントは成長することをやめ、そこで留まってしまう。
    • よって、プロジェクトマネジメントを進化させていくには、ナレッジマネジメントと統合させていく必要がある。

システム開発プロジェクトのリスク管理

  • リスクが発生した場合の影響度と損失の程度を予測し、損失額の大きなものから優先順位をつけて、発生を予防し、発生による被害を最小原因する対策を行う。
  • リスク管理はプロジェクトの立ち上げ時から行うべきである。
  • リスク管理を行う範囲には、スキル不足など個人に依存するものも含む。
  • 予防措置を徹底しても、想定外の事態でリスクが発生することもあるので、事後対策は必要である。

プロジェクト発足のきっかけ

  • 市場の需要
  • 組織のニーズ
  • 顧客要求
  • 技術的要素
  • 法的要件
  • 社会的ニーズ

参考文献

  • 『プロジェクトはなぜ失敗するのか』
  • 『新版 プロジェクトマネジメント標準PMBOK入門』