プロジェクト管理の第一原則

第一原則から始め、プロジェクトとは何か、そしてプロジェクトを効果的に管理する方法について包括的な理解を提供します。

Blueでは、プロジェクト管理について多くの時間を費やしています。これは私たちの業務やクライアントに提供する成果の成功にとって重要です。プロジェクト管理をしっかり理解していなければ、どうやってプロジェクト管理ソフトウェアを構築できるでしょうか？

新しいプロジェクトを始めるたびに、新機能、バックエンドエンジニアリングのアップグレード、マーケティングキャンペーン、または採用活動であれ、私たちはまずプロジェクト自体とその運営方法を分析します。そこで、豊富な経験と洞察を持つ私たちは、プロジェクト管理のいくつかの第一原則を正式にまとめることに決めました。

プロジェクトをより非公式で個人的な直感で進めることは一般的（かつ許容される）ですが、スケーラブルなアプローチとは言えず、欠点もあります。

プロジェクト

まず、プロジェクトを定義しましょう。

プロジェクトとは、特定の開始と終了を持ち、ユニークな製品、サービス、または結果を生み出すための一時的な取り組みです。これがほとんどの人がプロジェクトを考える方法です。しかし、考慮すべき他の、より正式なプロジェクトの特性もいくつかあります：

プロジェクトには有限のリソース（時間、お金、人）がある；
プロジェクトは特定の目的を達成するために行われる；
プロジェクトには定義された範囲がある（したがって、明確に行わないことがある）；
プロジェクトは不確実性とリスクの影響を受ける。

プロジェクトが何であるかをよりよく理解したので、次に第一原則に進むことができます。これは、プロジェクトが成功するために必要なコアの構成要素です。これには以下が含まれます：

プロジェクトマネージャー；
目的；
完了すべきことのリスト — これはしばしば計画と呼ばれます；
各タスクを実行するために割り当てられた人；
各タスクのタイムライン；
定期的な更新と会議のためのコミュニケーション戦略、情報が保存される場所の計画。

これらの要素は通常すべてのプロジェクトに適用され、うまく実行されれば、プロジェクト内の99%の問題を取り除きます。

プロジェクトマネージャー

プロジェクトに必要な最初のものは、プロジェクトを成功裏に完了させる責任者です。これは明白な声明のように思えるかもしれませんが、強調する価値があります。

この人がプロジェクトマネージャーです。彼らはプロジェクトの目的が達成され、プロジェクトが期限内に、予算内で、必要な品質基準に従って完了することを確保する責任があります。多くの場合、私たちの多くは訓練を受けたプロジェクトマネージャーでなくても事実上のプロジェクトマネージャーになります。もしあなたがそうなら、運が良いです、私たちはそのためのガイドを書きました！

プロジェクトマネージャーが何をすべきか、何をすべきでないかを考える価値があります。結局のところ、彼らには多くの責任があり、その責任を真剣に受け止める必要があります。

しばしば、プロジェクト管理はプロジェクト予算のかなりの部分を占めることがあります — 通常はプロジェクトのリスクに応じて2%から10%の範囲です。リスクが高いほど、物事が順調に進むようにするために、より多くのプロジェクト管理が必要です。

マネージャーであるため、プロジェクトマネージャーは他の人を通じて目標を達成する方法に焦点を当てるべきです。彼らはプロジェクトチームが効果的であり、共通の目標に向かって調和して働いていることを確保する必要があります。プロジェクトマネージャーは、全員が自分の仕事をしており、それをうまく行っていることを確認する必要があります。

プロジェクトマネージャーはまた、プロジェクトの利害関係者とのコミュニケーションを担当し、その進捗状況を更新する責任があります。

私たちがリーダーのための優先順位付けで議論したように、プロジェクトマネージャーは常に制約のポイントに焦点を当てるべきです。利害関係者に何かを承認してもらうのに時間がかかりすぎる場合、彼らはそのコミットメントを得ることに超集中する必要があります。彼らは常に自問する必要があります。「プロジェクトの目的を達成するのを妨げているのは何で、問題をできるだけ早く解決するにはどうすればよいか？」

ある意味で、プロジェクト管理はコミュニケーションと同義です。詳細なアイデアを書き留めることはプロジェクトマネージャーにとって貴重なスキルであり、必要な会議の数を大幅に減らすことができます — チームメンバーは必要な情報を自己サービスできます。

目的

プロジェクトのもう一つのコア構成要素は、プロジェクトが明確で測定可能な目的を持つ必要があることです。プロジェクトが終了したとき、結果を見てプロジェクトが目標を達成したか失敗したかを知ることは簡単であるべきです。

目的は公開され、すべてのチームメンバーがアクセスできるようにするべきです。これは重要です。なぜなら、意思決定が分散化され、各チームメンバーが自分の小さな作業を見てプロジェクトの全体的な目標にリンクできるからです。そうすれば、もし不整合があれば問題を提起したり、自分の小さなプロジェクトの領域でアプローチを変更して大きな目標に最もよく貢献することができます。

プロジェクトの目的はSMARTであるべきです：

具体的であること。 プロジェクトにはしばしば高レベルの目的があり、これはミッションやビジョンの声明のように聞こえます。悪い目的の例は「顧客サポートを改善する」です。これは具体的ではありません。「私たちはQ4の終わりまでに90%の顧客に30分以内に返信することを目指します」というようなものははるかに具体的です。
測定可能であること。 特定の目標を設定すると、一般的に測定の問題も同時に解決されます。なぜなら、目標が達成されたかどうかを評価することが容易になるからです。
達成可能であること。 目的は達成可能でなければ意味がありません。しかし、これは簡単な目的を作る理由にはなりません。良い目的には挑戦の要素が含まれているべきです — 達成可能であるが不可能または非常にありそうもないものではない。
関連性があること。 これは非常に自明に聞こえるかもしれませんが、これがどれほど頻繁に起こるかに驚くでしょう。プロジェクトの目的は、プロジェクトを行うことで達成できるものでなければなりません。特定の作業を行っているプロジェクトチームによって制御できない目的を設定することはできません。たとえば、企業の製造部門で働くチームは、顧客の店内ショッピング体験に影響を与えることはできません。
時間制約があること。 良い目的には何らかのタイミングが付随している必要があります。これは特に、やるべき作業が常に明確でない現代のソフトウェアプロジェクトでは難しい場合がありますので、タイムラインを見積もることは非常に困難です。時には、何倍も外れることがあり、それは誰の特定の責任でもありません。それでも、タイムラインを持つことで、プロジェクトの全体的な範囲が特定の範囲内に保たれます。問題を解決するのに1か月かかるのと1年かかるのでは、非常に異なる解決策が出てきます。

目的はすべてのチームメンバーに繰り返し伝えられるべきです：彼らは（比喩的に）プロジェクトマネージャーが常に目的について話すことにうんざりするべきです。進捗を追跡するリアルタイム（またはできるだけリアルタイムに近い）ダッシュボードも、すべての人が目的に向かって調整され、プロジェクトがどのように進行しているかを知るために非常に貴重です。

完了すべきことのリスト

私たちは計画を「完了すべきことのリスト」と呼ぶことを強くお勧めします。なぜなら、計画プロセスの神秘を解消するからです。

計画はしばしば推測ですが、それでも価値があります。なぜなら、計画自体のプロセスが、私たちが知っていることとまだ知らないことを明らかにするのに役立つからです。

計画を怠ると、失敗する計画を立てることになります。

計画の本質は、プロジェクトの開始から成功裏の完了までのすべてのステップの詳細なリストを作成することです。いくつかのアクションは前のステップを完了する必要があり、したがって、依存関係と呼ばれる一連のリンクされたタスクが生じることがあります。他のアクションは並行して実行でき、互いにブロックしません。

プロジェクトマネージャーは常に他のアクションをブロックしている最も重要なアクションに焦点を当てるべきです。これがプロジェクトのクリティカルパスとして知られるものを定義します。つまり、すべての依存関係が端から端まで並んでいる場合にプロジェクトを完了できる最小限の時間です。

プロジェクトの両端から計画を進めることは、効果的な計画を構築するのに非常に役立ちます。これは、最初から始めて最後に進むだけでなく、最後から始めて逆に進むことで、プロジェクトを完了し目的を達成するために必要なことを理解することを意味します。

計画プロセスを逆転させるこの最後の部分は、見逃されたタスクを明らかにすることが一般的です。

しかし、各タスクの責任者と各タスクの完了にかかる時間を理解するまで、計画プロセスは完了しません。

これらのポイントは非常に密接に関連しているため、同時にカバーされるべきです。特定のタスクの詳細を知っている専門家を関与させずに作業の見積もりを作成することはできませんし、それでもリソースに目を光らせる必要があります。個人は通常、同時に複数のことに効果的に取り組むことはできないため、プロジェクト計画にボトルネックがある可能性を理解する必要があります。これは、1人の人が割り当てられたすべてのタスクを完了できない場合、単に利用可能な時間が不足していることを意味します。

各タスクを実行するために割り当てられた人

プロジェクト内の各タスクには、そのタスクを完了する責任を持つ特定の個人が必要です。同じタスクに複数の個人が必要であることがわかった場合、タスクを区別するために十分に詳細なレベルに達していないことが多いです。

たとえば、多くの業界では設計と構築のフェーズがあります。これは製造、建設、またはソフトウェアでも同様です。これを分解して、デザイナーの特定のタスクとビルダーの特定のタスクを割り当てることができます。通常、これらの2つの分野の間で行き来があることがわかります。例は次のようになります：

デザインフェーズ1（デザイナーによる）
フィージビリティチェック1（ビルダーによる）
デザインフェーズ2（デザイナーによる）
フィージビリティチェック2（ビルダーによる）
シニアステークホルダーによるレビュー
デザインの最終化（デザイナーによる）
最終チェック（ビルダーによる）
ステークホルダーによる承認

これは、デザインフェーズの完了までデザインチームに単独で「デザインフェーズ」を割り当てるのではなく、関与するさまざまな当事者間の現実的な上下を示しています。

各タスクのタイムライン

これは計画を作成する際に最も難しい部分かもしれません — 各タスクにどれくらいの時間がかかるかをどうやって測定するのでしょうか？前述のように、タイムラインはトップダウンではなくボトムアップで作成されるべきです。これは、各項目が作業を行う人（または少なくとも知識のある同僚）によって見積もられ、これらの見積もりがすべて追加されて全体のタイムラインに計算されることを意味します。

とはいえ、詳細な見積もりが行われる前に全体の高レベルのタイムラインを持つことは有益です。なぜなら、何かにかかる時間を見積もることと、タスクを解決するための具体的なアプローチを決定することは本質的に同じだからです。

したがって、プロジェクトに寛大な高レベルのタイムラインがある場合、各専門家はそれを見積もりに考慮し、タイムラインを守るために手を抜くのではなく、長期的な解決策を最適化しようとします。プロジェクトに急いでいるタイムラインがある場合、各専門家はトレードオフを行う必要があることを知っています。

プロジェクト計画の作成中にしばしば忘れられることの1つは、利害関係者が進捗を確認し、考慮すべき決定を確認する必要があるということです。これを行う最良の方法は、同じ利害関係者のセットを含む以前のプロジェクトを見て、フィードバックを提供するための典型的なターンアラウンドタイムがどれくらいかを理解することです。

ここでのもう1つの危険は、主要な利害関係者との月次運営委員会がある場合、プロジェクトの成果物がその会議の1つに間に合わない場合に何が起こるかです。プロジェクトは次の月に利害関係者が再び集まるまで一時停止されるのか、それともその間に対処され、承認される（またはフィードバックを伴って返却される）のか？

コミュニケーション戦略

このような問題が発生すると、プロジェクト内のコミュニケーションアプローチが最も重要であることが確認されます。

通常、問題は悪い戦略があることではなく、全く戦略がないことです。そのため、コミュニケーションチャネルは非公式でアドホックな方法で開かれ、「十分に良い」が基準となります。

これの問題は、物事が常に計画通りに進むわけではないことです。人々は変わり、知識は失われ、プロジェクトが大規模になり、ますます多くの人が参加するにつれて、コミュニケーションのオーバーヘッドは急速に増加する可能性があります。

したがって、ツール自体はそれほど重要ではありません。人が10人を超える非トリビアルな数を超えてスケールするにつれて、チームワークはますます難しくなるのは事実です。

チームのコミュニケーションは、チームの人数に対して線形にスケールしません。

たとえば、2人のチームがある場合、1つのコミュニケーショントピックがあります（2人の間）。もう1人を加えると、3つのコミュニケーショントピックができます。したがって、チームのサイズが50%増加したにもかかわらず、コミュニケーショントピックは300%増加しています。

これがどのように成長するか見てみましょう：

2人のチームメンバー = 1つのコミュニケーショントピック
3人のチームメンバー = 3つのコミュニケーショントピック
5人のチームメンバー = 10のコミュニケーショントピック
8人のチームメンバー = 28のコミュニケーショントピック
10人のチームメンバー = 45のコミュニケーショントピック
15人のチームメンバー = 105のコミュニケーショントピック
20人のチームメンバー = 190のコミュニケーショントピック
30人のチームメンバー = 435のコミュニケーショントピック
50人のチームメンバー = 1,225のコミュニケーショントピック
100人のチームメンバー = 4,950のコミュニケーショントピック

これは次の式で表すことができます：

n(n-1)/2

ここで、nはプロジェクトに関与する必要がある人数です。

ご覧のとおり、この数はチームのサイズが増加するにつれて指数関数的に増加します。10人のチームがある場合、管理する必要がある潜在的なコミュニケーショントピックは45です。しかし、50人のチームがある場合、1,225の潜在的なコミュニケーショントピックがあります — それは27倍です！そして、100人のチームがある場合、4,950の可能なコミュニケーショントピックがあります — それは110倍です！

これは、単に大規模なチームの問題ではなく、個々のメンバーが同じ場所にいないチームの問題でもあることに注意することが重要です。これは、可能なコミュニケーショントピックの数がチームメンバーの物理的な近接性によって制限されないからです。

たとえば、10人のチームがあるが、彼らはすべて異なる地域にいるとします。この場合、チームメンバーが物理的に近接していなくても、管理する必要がある潜在的なコミュニケーショントピックは依然として45です。

さらに悪化する可能性があります。上記の計算は、1つのコミュニケーション手段のみを仮定しています。異なるコミュニケーション手段を考慮する場合、次のように式を書き直す必要があります：

n(n-1)/2

ここで、nはコミュニケーションチャネルの数です。

上記のコミュニケーショントピックの数を再度取得しますが、今回はnが以下で構成されていると仮定します：

メール
グループチャット
個人チャット
プロジェクト管理システム内のコメント
通話
ドキュメント内のメモ/コメント

数字を代入すると、次のようになります：

2人のチームメンバー = 6のコミュニケーショントピック
3人のチームメンバー = 18のコミュニケーショントピック
5人のチームメンバー = 60のコミュニケーショントピック
8人のチームメンバー = 168のコミュニケーショントピック
10人のチームメンバー = 270のコミュニケーショントピック
15人のチームメンバー = 630のコミュニケーショントピック
20人のチームメンバー = 1,140のコミュニケーショントピック
30人のチームメンバー = 2,610のコミュニケーショントピック
50人のチームメンバー = 7,350のコミュニケーショントピック
100人のチームメンバー = 29,700のコミュニケーショントピック

コミュニケーショントピックの数がどれほど急速に増加するかは恐ろしいことです — そして、リモートワークが現実では実用的でない大規模な会議をより容易に可能にする場合、それは両刃の剣です。

要するに、戦略は、比較的小さな数のチームメンバーでも発生する可能性のあるコミュニケーションの爆発を避けるために重要です。

「コミュニケーション戦略」というアイデアは複雑で壮大に聞こえるかもしれませんが、そうである必要はありません。重要なのは、いくつかの原則を設定し、主要なコミュニケーションチャネルを示し、場合によっては人々に何をしないべきかを伝えることです。

考慮すべきいくつかの基本的な原則：

情報をオープンに保つ。 すべてが数ヶ月または数年後に簡単に見つけられ、共有できる必要があると仮定します。プロジェクトチームのすべてのメンバーが必要な情報にアクセスできるようにし、この点を考慮してファイルやドキュメントに名前を付けるように注意します。
明確さを優先する。 新しい人がプロジェクトチームに参加することを想像してください。情報を明確かつ簡潔に文書化し、重要な決定を簡単に理解できるようにします。
会議の議事録を保管する。 すべての重要な会議が記録され、簡単に見つけられるようにします。

コミュニケーションチャネルに関しては、少ない方が良いです。以下に減らすことをお勧めします：

プロジェクト管理ソフトウェアを使用してタスク特有の議論を行う。
会議（対面またはリモート）を行い、議事録を作成し、すべてのプロジェクト会議の議事録を1か所で見つける場所を作る。
ドキュメント：これはGoogle Docs内のコメントや議論、コメントを許可する特定のツール（例：UXデザイン用のFigma）である可能性があります。

このリストにgroup chatを追加することも許容されますが、明確な目標やアジェンダがないまま、巨大な全日（毎日！）の会議になってしまう可能性があるため、注意深く管理する必要があります。

プロジェクトマネージャーはこれらのルールを明確に設定し、時折（比喩的に、文字通りではなく！）プロジェクトチームメンバーを正しくコミュニケーションさせるために叩く良い例を示す必要があります。

最後の考え

専門知識のレベルに関係なく、基礎レベルでトピックやプロセスを見直すことは常に価値があります。したがって、プロジェクト管理のテーマに深く掘り下げることで、プロジェクトを成功裏に実行するために必要な主要な第一原則を特定しました。

各プロジェクトにはプロジェクトマネージャーが必要です：彼らはプロジェクトが明確な目的を持ち、それが最終目標に到達するために完了すべきタスクに分解されていることを確保します。プロジェクトマネージャーは次に、各タスクにチームメンバーを割り当てる必要があります。チーム全体で、各個別のタスクとプロジェクト全体のタイムラインを特定できます。

問題を引き起こすのは、しばしば一見当たり前のことです。高度なテーマがより多くの注意を引く傾向があります — たとえば、コミュニケーションです。これが、プロジェクトチーム内および外部の利害関係者との間で明確に定義されたコミュニケーション戦略が必要な理由です。

プロジェクト管理は複雑なテーマであるため、これは決して包括的なガイドではありません。予算、選択肢間の対立を解決する方法、プロジェクト内での委任の範囲など、初期の概要ではカバーしていない要素がまだいくつかあります。