プロジェクトとプロジェクトマネジメントの必要性

「プロジェクト」という言葉は、世の中でよく使われています。 しかし、本当に「プロジェクト」というものを理解して取り組んでいる企業は少なく、そのことがプロジェクトの失敗要因になっています。 ”「プロジェクトとは何か」7割の人は知らない”というネット上の記事を紹介します。 単に機能別組織や部署を括って、「プロジェクト」としての体制を明示化する。
さらに、プロジェクトマネジメントの知識(経験)のない人を「プロジェクトマネジャー」として指名する。 プロジェクトの失敗事例の多くは、プロジェクトマネジャーの知識・経験不足です。 特に、社内の機能別組織を括った組織では、コミュニケーション不足、プロジェクトの目的が曖昧で部署間の利害対立が発生する、 さらには、外部組織・専門家・有識者を加えない社内要員だけでのプロジェクト体制では、プロジェクトの最終成果での新規性に対応できず、 失敗を自ら招くのが目に見えます。
変化の激しい中で経営戦略に合わせた最終効果を達成するためのプロジェクト遂行は、製造業を中心に不得手な様です。 中小企業では、特に、プロジェクトの知識がある要員や人材育成・処遇制度は存在せず、取引先の大企業などの発注先からの 生産要請に対応して、経営を支えてきた企業では、大企業の市場環境が大きく変化したときにプロジェクトの必要性が生じます。
新製品企画・開発、新市場開拓、製造・物流などのプロセス・設備/機器の見直し、製造技術の改革、対応する営業・技術要員の 育成など、今まで企業として経験・知識のないことに対処して、プロジェクトの最終成果を達成する必要が生じます。
上記は、大企業でも製造業以外の業界でも同様です。 このため、経営(マネジメント)知識なども含む包括的な「知識駆動型プロジェクト」の取組みが企業の大小を問わず必要となります。

何か今までと異なる新たなことを実施するにあたって、プロジェクトとして明示的に立ち上げず、 プロジェクトマネジメントの知識に欠けると何が起こるか?このようなことは、よく見かけられることです。

プロジェクトとして明示的に立ち上げずプロジェクトマネジメントの知識に欠けると発生する問題の事例

プロジェクトマネジメントの知識とは!!

プロジェクトマネジメントに関する知識の基本と特定プロジェクトで特に必要な知識を共有していきます。 共有対象としての知識は下記の観点で学習・研究室や個別のプロジェクト室で整理・共有します。

  • 夢を実現する、価値提供のアイディアなどの想いを持ってそれだけだは実現できるものではありません。 それは夢実現やアイディア実現のスタートです。実現にはプロジェクトとして開始することです。
  • プロジェクトで目的とする成果は、いきなり最終成果として出来上がるものではないこと。
  • 目に見える、目に見えないつながり(プロセス、人と人、組織と組織など)により成り立つ。
  • 夢実現、価値創造のプロセスを理解できる/実践できる知識を持つこと。
  • 期間の制約のなかでメンバー間の連携・協働の知的作業を遂行する。
  • プロジェクトメンバーは、異なる組織や文化を背景にもつ様々な人で構成される。
  • 価値創造的な知的業務でありかつ不確定・不明確・未経験の要素を含む業務である。
  • 例えば、米国PMI(Project management Institute)では、10の知識領域に分けた様々な関連する知識を必要としている

CWWとしての知識駆動型プロジェクトへの取組み

CWWは、プロジェクトコーディネーターとして支援します

知識駆動型プロジェクトの展開

プロジェクトマネジメントの基本知識の共有ページ

知識駆動型プロジェクトを実践るするために役立つプロジェクトマネジメントの知識の共有を目的としています。 プロジェクトマネジメントに関する必要知識はプロジェクトごとにその内容も異なる所もあります。 まず、ここではプロジェクトの共通的な知識から整理・共有していきます。 また、プロジェクトマネジメントの体系的な知識の提供は考えていません。 具体的には下記のような観点での知識の共有を図っていきます。

  • プロジェクトでの定常的な機能別・職能別の組織体制と異なる知識として何が必要か
  • QCD,スコープの制約の中でプロジェクトの最終成果を達成するための知識共有はどうあるべきか
  • プロジェクトでは、暗黙知と形式知についてどのように取り組むか
  • デファクトとしてのプロジェクトマネジメントの知識体系をどの様に活用するか
  • 組織のプロセスとプロジェクトのプロセスの整合性をどのように図るか
  • プロジェクトの成功事例、失敗事例や外部のベストプラクティスをどの様に蓄積するか
  • プロジェクトマネジメントのスキル評価や人材育成や処遇制度をどのように整備するか
  • PMOなどの支援組織をどのように整備するか
  • プロジェクトと組織・企業内の機能別・職能別の部署との協働の仕方について
  • プロジェクトに関わる制度、標準、規約などは何をどの様に整備するか
  • プロジェクトに関わるKPIは何をどのように設定するか
  • 改善プロジェクトとイノベーションプロジェクトと何が知識として異なるか
  • プロジェクトでの直接活動メンバーとそのワークパッケージなど以外の支援活動、ロジスティックなどの重要性とその扱いについて
  • プロジェクトとプロジェクトアセスメントやプロジェクト監査について
  • プロジェクトメンバーの専門知識と個性を生かし如何にチームビルディングを行うか
  • チケット駆動型プロジェクト管理システムとネットワーク型プロジェクト管理システムによるプロジェクト管理について

以上は知識共有テーマの一例であり、上記の知識の具体的な内容を学習・研究室にて共有(限定公開)していきます。

プロジェクトマネジメントの知識

まずプロジェクト共通のプロジェクトマネジメントの知識の修得を行ないます。

分類 項目 内容
コンピテンシー 知識体系 PMI(Project Management Institute)のPMBOK(Project Management Body of Knowledge)を基本に知識共有を図ります。 他にも種々の体系がありますので継続して修得することも良いと考えます。
コンピテンシー プロジェクト・マネジャー・コンピテンシー開発(PMCD)体系 PMIが提供する体系で、プロジェクト・マネジャー・コンピテンシーは、以下の3つの次元に分類
・知識 プロジェクト・マネジャーがプロジェクト活動におけるプロセス、ツール、技法の適用に関して知っていること
・実践 プロジェクト・マネジャーがプロジェクトの要求事項を満たすために、プロジェクトマネジメントの知識を適用する方法
・人格 プロジェクト・マネジャーがプロジェクト環境の中で活動する時の行動の方法
上記の内容を具体的に組織としてどのように取組み、教育などの人材育成、制度、支援ツールの整備などに展開することが必要です。
資格 プロジェクトマネジャとしての組織内の資格 プロジェクトの規模や難易度に相応しいプロジェクト体制の確立に必要となる組織内の資格制度があります。 公的資格取得とプロジェクト経験や実績で資格認定を実施します。
組織内の資格も継続的に当該分野の知識を研鑽・向上させる努力を求めることが必要です。 このためには、1度認定しても定期的な見直しが必要となります。
人的ネットワーク 人的ネットワークの構築 組織内や各種団体などの活動を通じて、人的ネットワークを形成し必要な知識支援が得られるようにすることが大切です。 たとえば、Facebookなどで人的ネットワークを維持することも一助となります。


プロジェクトマネジメントに役立つ知識

プロジェクトは協働事業であり、個人の人格や人間力の向上がその原点となります。

分類 項目 内容
スクラム(英: Scrum) スクラムは、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。 この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。
(注)本知識は、ソフトウェア開発プロジェクトだけでなく、他の多くのプロジェクトでも有効な知識と考えます。
アジャイル アジャイル
  • アジャイルプロジェクトマネジメント
  • アジャイル開発
リーダーシップ アクションラーニング
(行動科学から学ぶ)
プロジェクトでは、決められた期限内で成果を出すことが強く求められます。 計画を如何に立案して、実践していくかがプロジェクトの要ととなります。 行動科学マネジメント、PDCAなどを学習し、身につけてプロジェクトを遂行します。
課題管理・問題点管理 問題発見手法 期限が限られているプロジェクトでは、表面的ではない「本当の問題は何か?、 致命的で発生確率の高いリスクは何か?」を捉えて、迅速に対応することが重要です。 問題の先送り、問題の表面的な対処ではより重大な事態を招く恐れがあります。 その方法論は各種あり、問題に応じて選択します。
リスク管理 変化点管理 元のものがあり、それに変更を加えるプロジェクトでは、「変更点」と「変化点」に注視し、 まず、リスク管理に適用し、さらに、設計、品質管理、レビュー時のリソースとします。 トヨタ自動車のDRBFMが著名です。
思考対応 可謬主義 「人間にとって獲得可能な知識はどれも、それが現在いかに確実な真理とみなされていようとも、 決して最終的な真理とみなすことはできず、 つねに誤りが発見され修正される可能性を残したものとしなければならない」、 という認識が必要です。 例えば、プロジェクトでは、前提条件、仮定条件などを設定しますがそれが変化する、 変更となる可能性を考慮して監視する必要があります。
思考対応 エサを食べないカマス プロジェクトは、いくつかブレークスルーをしないとプロジェクトの最終成果を達成できないケースがあります。 その時、プロジェクトの思考回路が「エサを食べないカマス」になっていないか検証してみることも必要です。 今までできないと考えたことが本当に不可能なことなのかなどを考えてみて再挑戦することも大切です。
思考対応 ゆでガエル現象 プロジェクトはそれぞれ異なるものですが、幾つかプロジェクトを経験するとどれも同じように感じて、 プロジェクトの個別特性を見逃す、軽んじることが中堅のプロジェクトマネジャ―では起こります。 また、小規模なプロジェクトでの成功体験が大規模なプロジェクトではかえって失敗につながる可能性もあります。 プロジェクトの中途半端な経験・知識が失敗を招く場合があります。
思考対応 チーム脳 三本の矢の譬え、三人寄れば文殊の知恵などと複数の知恵を集めるとより効果的・効率的なプロジェクト運営が可能となります。 しかし、プロジェクトでは異なる背景、文化、スキル、経験の知の集合の「場」ですから通常の機能別組織のようなチーム脳の 発揮の方法では、適合しない事態もあります。 そこで、プロジェクトチーム全員が一つの大きな脳として考える「チーム脳」の醸成や 個々のメンバーの脳のつながりがMAXとなるようなプロジェクト運営が必要となります。
コミュニケーション ダイアログ(対話) プロジェクト価値の実現・創造のためには、ダイアログ(対話)が必須です。自分自身がダイアログできるだけでなく、 プロジェクトメンバー同士がダイアログできるようにすることも重要です。 特に、フェース・ツー・フェースでのコミュニケーションが大切ですが、人数が多くなり、利害関係者が多くなると 本音、真実、現状を適切に把握し、対応するためには、プロジェクトマネジャー、 チームリーダーの時間の多くを 本活動に注力することになります。
留意点 知識の持つ限界 個人や組織・企業の知識の成熟度・成長度、個性・文化や関心領域、主体者・組織・企業の心の捉われ方 (無心・冷静・客観的でないこと)で同じ知識や状況を提示されても結果は変化します。 (農作物に譬えるとを活用する使用する種の品種、土壌・環境、与える肥料、その時の気候などの違いで変化する様なもの。)
⇒プロジェクトマネジメントでは、多様なメンバー、組織・企業に対応するので全て同一の対応では 機能しない。ステークホルダーマネジメント、コミュニケーションマネジメント、リスクマネジメント、品質管理 タイムマネジメントなどでもこのことに留意がいります。
留意点 知識の持つ特性 同じプロジェクトの目的からスタートしても知識の持つ限界から利用主体の特性・個性・優先選択指向・好みから、 知識の理解度、知識の活用度・知識の視野で行動・活動やプロジェクトの最終成果、出来上がる 製品・商品・サービス・システムが変化します。


プロジェクトマネジメントの留意事項

  • プロジェクトマネジメントを実施する責任者(体制と役割、責任と権限)
  • プロジェクト計画書の作成と徹底、変化時の更新・承認プロセス
  • プロジェクト進捗報告と進捗管理の方法、何の作業を実施したかではなく根拠ある進捗定量的報告・見える化と課題対応、問題点管理、リスク中心の報告と対処
  • プロジェクトマネジメントの成果の構成管理(コンフィグレーションマネジメント)と共有管理
  • ベストプラクティス、テンプレート、事例などの知的資産の蓄積と共有・活用
  • プロジェクトマネジャーの育成と処遇
  • プロジェクトマネジメント支援体制の整備と支援システムの整備
  • プロジェクトの見える化とプロジェクトの是正の連携
  • プロジェクトアセスメント、監査による検証とプロジェクトマネジメントの是正

組織・企業の多様性とプロジェクトの多様性への留意事項

プロジェクトは、常に同一のものはなく多様性に富んでいます。不確実性、リスクを含んでいます。 このため「知識駆動型プロジェクト」として、知識を共有し、ネットワークを活用して取り組んで行きます。 代表的な多様性を下記に例示します。

  • 組織・企業の成熟度(マチュリティモデル)
    • 経営品質における成熟度モデル
    • プロジェクトマネジメントにおける成熟度モデル
    • エンジニアリングにおける成熟度モデル(能力成熟度モデル統合(CMMI)、Automitive SPICEなど)
    • データマネジメントマチュリティモデル
    • ソフトウエア保証成熟度モデル(Software Assurance Maturity Model:SAMM)
    • IT活用成熟度モデルなど
    上記は個別に対応・評価するのではなく、全体を俯瞰して、自組織・企業に必要なものを選択して、更に、自組織 ・企業用に整理・統合して、具体化した内容で展開・深耕するのが良いと考えます。 プロジェクトでどのように扱うかは、学習・研究会でのテーマでもあります。
  • プロジェクトが個人、数人の少人数、中規模、大規模、グローバル、異文化など
  • WBSとその成果物の明確度(設計可能性が大)、要求仕様・要件定義が曖昧・不明確など
  • プロジェクト作業単位の粒度(WBS型(ワークパッケージが2週間以上)、チケット型(最大1週間以内の作業)など)、 WBS型のプロジェクトをチケット型の作業単位でプロジェクトマネジメントするとどうなるか?
  • パッケージ、特にERPを適用するプロジェクトと対象の業務プロセスの組合せ
  • ハードウェアの1部としてソフトウェアが小規模に開発、ハードウェアの開発より大規模な工数で開発
  • 組込みシステムでの提供製品・製品の型式・グレード・仕向け地などと組込みソフトウェアの独立性・組込み単位の関連
  • 適用技術の分類、個人技術、グループ技術、組織技術などとその保有要員との関連
  • 個人に依存して実装に差異が出る度合(小、中、大)
  • 上流の設計品質や粒度・具体的記述度合
  • 既存部品の再利用/OSS/FOSS/導入ソフト/パッケージの活用などの新規開発の割合と改造の割合
  • 信頼性要件、性能要件、外部からの攻撃、内部漏えいへの対処など
  • 設計規約、デザイン規約、実装規約、各種標準類、テンプレートなどの整備度合
  • 見積(規模/工数)プロセスと精度・信頼度
  • 契約条件・商習慣
  • スコープ、コスト、スケジュール、品質など
  • プロジェクトの「場」の雰囲気、組織・企業の文化、要員の価値感

プロジェクトマネジメントの失敗から学ぶ(例)

プロジェクトマネジメントでの失敗は、教訓として残し、その原因と対策を具体的に反映していきます。 プロセス、規約、チェックリスト、テンプレート、知識DBなどに、反映すると同時に内容も再度見直し 時間の変化に追従させます。

  • 原因分析と対応策を現場任せにしない。
  • 上位層へのエスカレーションを判断する。
  • 失敗に対する原因分析を実施させる。
  • 他に影響がないか調査させる。
  • 原因に対して対応策を立てさせる。
  • 対応策に実現性があるか見極める。
  • 対応策が計画通り実行されているか確認する。
  • 報告は言葉だけでなく、必要に応じて現地、現物、現人にて確認する。
  • 重大な失敗は、PM、PMO自身も原因究明に関与し、本当に正しい対応策かどうか判断する。
  • 受託開発プロジェクトでは、ユーザ、営業、現場との意識合わせを実施し、納品でドタバタしない。
  • リスク管理、課題管理の管理主体がマネジメント(PM)レベルか、チームレベルか分ける。

以上、例示しましたが、極めて常識的な内容ですが、プロジェクトがピークとなると疎かになりがちです。 より詳細に学習・研究室で失敗と成功のプロジェクトの教訓にて整理し、実現方式をまとめいきます。


プロジェクトマネジメントで心掛けること(例)

  • チーム間のコミュニケーションを向上させる。
  • プロジェクトマネジメントで最も難しく、問題やリスクの発生要因は、コミュニケーションマネジメントの対応です。 技術的な困難な課題も重要ですが、技術課題の解決の壁になるのがコミュニケーションの壁です。 このため、コミュニケーションに心掛けることが非常に重要です。
  • WBS間の依存関係、課題間の関連、リスク間の関係を見きわめて、クリティカルパス上にあるものは重点的に監視します。
  • WBSなど関連がチーム間にまたがるものは、欠落するWBSや役割分担が不明確なものがないか重点的に監視します。
  • 確固たるスコープを設定する。
  • 作業の優先順位のブレをなくし、ステークホルーダーとの合意形成を図る。
  • 客観的な視点から意見が出せるように訓練する。
  • 真実、本当のことを言える環境を作り、発言者に対応策を押付ける方式を取らない。
  • 立場上、発言できない内容について配慮し、オフミーティング、非公式会話を実施する。(裏事情の聴取)
  • 課題:発生した問題の対応策、問題の原因追求と対応策、ToDo:現時点でやるべき作業、リスク:将来起こる可能性のある問題、 想定外の作業の対応、などとるべくプロジェクトマネジメントが異なるので留意して臨む。
  • ’死に体’の運用ルールを蘇生させる、軌道に乗せる。PMOが主体的に運用・定着化を推進する。
    ・WBSが最新に更新されない。
    ・プロジェクト会議が作業報告であり、スケジュール・課題・リスクなどの計画との差異報告が欠如
    ・課題管理フォーマットがチーム毎にバラバラになっている。
    ・課題管理表に課題以外のゴミが混ざっている。
    ・リスク管理表が更新されない。
    ・定例会議の報告が実態とかけ離れている。
    ・ルールが硬直化して実態と遊離しても更新されない。
  • プロジェクトオーナーは、プロジェクト、PM、PMOに対して、タイムリーに助言を与える。
  • ラインマネジャーは、プロジェクトを積極的支援する。
  • 「ユーザテスト」では、ユーザがテストに十分な時間を割り当てる。

プロジェクトマネジメントとは、上記の例のように極めて常識的な内容ですが、このようなことができていない プロジェクト、組織が極めて多いのも事実です。今後更に、学習・研究室で深堀していく予定です。