やっているはずのプロジェクト管理ができていないのはなぜ？

プロジェクトの状況に管理者が疑問を覚えるのは、主に進捗の確認を行っている時です。特定の課題やタスクのスケジュールに遅れが見られたり、複数の課題、タスクの進捗のバランスが取れていないと感じる時、プロジェクトの全体像を見直さなくてはいけないのではないかと不安を感じます。あるいは、問題のありそうな課題やタスクもはっきりしない状態での、漠然とした違和感のような感想であることも少なくはないでしょう。

そのタイミング以前に、メンバーからアラートや疑問が上がってくることはほとんどありません。スクラムでプロジェクトの全体像やスケジュールを共有していたとしても、それぞれのメンバーには目の前の課題、タスクの遂行の優先度が高く、個々の課題が予定通り進んでいなければ、それを自身の問題として解決することに多くの注意を払っているからです。

プロジェクト管理者が、全体像とその進行に、計画と自身の経験に基づいた観察に注力していることで、プロジェクトのささやかなほころびにいち早く気づくことが可能になります。しかし、管理者はプロジェクト進行に違和感を抱き、自身に対しアラートを発した時点で、その原因究明と解決に悩まなくてはならなくなります。

これまでの自身の成功体験や、企業内で共有されている別プロジェクトの経験との比較に基づいて構築したはずのプロジェクトの、どこにそうしたほころびが発生しうるのかを知ろうとします。原因となりそうなものは、プロジェクトによって様々ですが、当該プロジェクト以前の企業としての問題である可能性もあります。

例えば、コミュニケーション不足と情報共有の欠如が、部門間や関係会社との間に存在していれば、不十分なコミュニケーションや、不適切な情報の共有不足から、プロジェクトの進捗や課題を把握しきれない状況が生まれます。その結果、タスクの重複や抜け漏れが発生し、プロジェクト管理は難しくなります。

一方、プロジェクト管理の現場で、プロジェクト内のタスクやアクティビティが適切に追跡されていなかったり、優先順位が明確でなかったりした際に、メンバー間での仕事の進め方が乱れ、重要なステップが見逃されたり、スケジュールに間に合わないケースが発生します。

あるいは、プロジェクトメンバーのメンタルの状態が原因になって不都合が生じる可能性もあります。サービスや製品の高機能化によって、業務プロセスが複雑になってきたときに、新しいツールやこれまで使用していなかったプロセスの導入によって、問題の解決を図るのは正しいアプローチです。しかし、変化を嫌う心理的傾向から、こうした導入に対して抵抗感が発生することがあります。結果として、一部の従来のやり方を変えない人たちの影響でプロジェクト全体に問題が及ぶことが考えられます。

こうした多様な原因を一挙に解決できる手段はありませんが、どの場合でも管理者がステークホルダーにそうした原因を説明できるかどうかは重要です。冒頭に書いた漠然とした不安だけでは、不十分です。管理者が問題を言語化しなくてはプロジェクトの状況を改善することは不可能です。

言語化するためには、自身の経験と思考だけでは不十分ですが、関係するメンバーに尋ねてもなかなか有効な回答が返ってこないケースが多くあります。そのため、プロジェクトの現状を可視化・分析し、客観的な視点の獲得を手助けするツールが必要になります。

使用しているプロジェクト管理ツールは、現在進行しているプロジェクトが必要としているスピードと機能に合わせてアップデートされているでしょうか？　プロジェクト管理手法もそれを実現するためのツールも、常に進歩しています。過去の成功体験を基に、従来から使用していたツールを使い続けることで、現在のプロジェクトに求められているビジネススピードに追随できなくなっている可能性はないでしょうか？

電子メールや紙の文書中心のコミュニケーションや、ガントチャートを偏重してリソース管理や進捗追跡が機能しなかったりといった従来型のツールでは、プロジェクトの状況を視覚化し、メンバーや会社サイドに説明するための言語化に時間がかかってしまうリスクがあります。

ONES Projectは、標準的なダッシュボード（下図参照）の中にも多くのツールをウィジェットとして入れ込み、さらに、コンポーネントを追加することで、可視化と多面的な分析を可能にしています。このため、プロジェクトに問題が起こりそうな場面でも、さまざまな角度から状況を把握し、解決に必要なアクションを関係者に説明していくことができます。

機械メーカーのB社では、生産部門ごとにそれぞれが開発・生産する製品に合わせて、独自にプロジェクト管理ツールを選択していました。このため、部門間の異動時に管理手法と管理ツールに慣れるために時間がかかるなどの不都合がありました。

こうした非効率を取り除くために社内の生産性改善委員会で管理ツールの統一について話し合いを重ねていましたが、各部門は業務に合わせてツールを選択した経緯があり、他部門が使用しているツールに乗り換える際の学習の手間などに強い抵抗を示していました。そこで、各部門がプロジェクト管理ツールに求める機能の洗い出しを行い、その全てを満たすツールを広く探しました。この結果、アジャイルにもウォーターフォールにも対応可能なONES Projectを全部門で新たに導入することが提案されましたが、各部門の激しい抵抗は予想されていました。

ところが、委員会の報告が上がったタイミングで、二つの生産部門合同で開発しなければならないプロジェクトが立ち上がることになり、スケジュールもタイトであったことから、この二部門でONES Projectを試験導入、その使用結果を元に全社導入を判断することになりました。

テンプレートをチュートリアルとして習得できるONES Projectは導入ハードルが低く、多様なウィジェットで両部門のプロジェクト進行の特徴的な部分を相互に理解、共有することができたため、合同プロジェクトは順調に進み、スケジュールも遵守できました。

委員会ではプロジェクト進行を観察し、双方が従来の別々の管理ツールを使用した場合に発生したであろうリスクについても盛り込んだレポートを提出、ONES Projectの全社導入が決定しました。

個別のプロジェクトの進行も、企業はビジネスの一環として常にサポートするわけですが、そこに齟齬を生じさせないためには、プロジェクト側と企業側の対話が必要です。プロジェクト管理ツールはプロジェクトの進捗を可視化しプロジェクト管理者とメンバーの目的意識を一致させるだけでなく、プロジェクト管理者と企業サイドの対話をスムーズに行うための共通の理解基盤を提供する必要があります。

プロジェクト管理ツールを単なる進捗管理ツールと捉えていたのでは、十分にビジネス活用しているとは言えません。ステークホルダーに対し、可視化、分析、説明を実現できるツールの選択が重要です。ONES Projectの多様なウィジェットとコンポーネントを使用すれば、プロジェクト管理者以外にも、プロジェクトの理解を促し、企業としてのより有効なサポートも獲得できるでしょう。それによりプロジェクトの成功はさらに近づくはずです。