プロジェクトマネジメントとは、特定の目的を達成するため、スコープ（範囲）、コスト、品質、スケジュール（納期）などの要素を計画・実行・監視・制御し、限られたリソース（人・物・金）を最大限活用して成功に導くための体系的な手法・活動です。明確な「目的」と「期限」があるプロジェクトを成功させるために、進捗管理、リスク管理、コミュニケーション、リーダーシップなどが重要視されます。
画像参照：https://backlog.com/ja/blog/what-is-project-management/
プロジェクトコストマネジメント
プロジェクトコストマネジメントとは、プロジェクトの費用を見積もり、予算を設定し、プロジェクトを予算内で完了させるための一連の活動で、PMBOKでは「コストマネジメント計画」「コスト見積もり」「予算設定」「コストコントロール」の4つの主要プロセスで構成されます。QCD（品質、コスト、納期）の「C」にあたり、赤字や失敗を防ぎ、収益性を確保するために不可欠で、進捗状況の把握と調整を通じてスコープクリープ（要件の肥大化）も防ぐ役割があります。
コストマネジメントの目的
- 予算内でのプロジェクト完了:承認された予算内でプロジェクトを完遂させ、利益を確保する。
- 経済的リスクの最小化:予算超過や赤字になるリスクを回避する。
- 収益性の向上:適切な管理により、プロジェクトの経済的価値を高める。
- ステークホルダーの信頼獲得:計画通りにコスト管理を行うことで、信頼を得る。
- 将来への知見蓄積:コスト管理のノウハウを社内に蓄積し、次期プロジェクトに活かす。
PMBOKに基づく4つのプロセス
- コストマネジメント計画:コスト管理の方針やルール（見積もり、予算設定、報告方法など）を定義する。
- コスト見積もり:プロジェクトに必要な費用（人件費、材料費など）を算出する。
- 予算設定:コスト見積もりを基に、プロジェクト全体の予算（コストベースライン）を作成する。
- コストコントロール:実行中に実績と予算を比較し、差異があれば調整（変更要求など）を行い、予算内に収める。
重要なポイント
- 進捗状況の把握:責任者が常に状況を把握し、問題発生時に迅速に対応できるようにする。
- スコープクリープ対策:変更要求に対し、予算内で対応可能かを見極め、肥大化を防ぐ。
- リスクへの備え:予期せぬコスト増に対応できるよう、潜在リスクへの準備も行う。
コンティンジェンシー予備
コンティンジェンシー予備とは、プロジェクトで「既知の未知のリスク」（予測はできるが、発生するか不明な事態）が発生した際に、その対処のためにあらかじめ確保しておく予算や期間の余裕分のことです。これはPMBOK®︎（プロジェクトマネジメント知識体系ガイド）で定義され、プロジェクトマネージャーの裁量で利用でき、リスク対応計画（コンティンジェンシープラン）の実行に使われます。想定通り発生しなければ解放され、より不測の事態に備える「マネジメント予備」とは区別されます。
詳細
- 目的: 予期されるリスク（例: 手直し、一部の遅延、仕様変更の可能性など）が現実になった場合に備え、プロジェクトが計画通りに進むようにするためのバッファー（緩衝材）です。
- 対象: リスク分析によって特定され、リスク登録簿に記載される「既知の未知」（Known Unknowns）と呼ばれる事象。
- 使われ方: プロジェクトマネージャー（PM）の裁量で利用可能。リスク発生時のアクションプラン（コンティンジェンシープラン）を実行するために使われます。
- 予算: プロジェクトのコストベースライン（費用とスケジュールの基準線）に含まれることが多いです。
- 「マネジメント予備」との違い:
- コンティンジェンシー予備: 既知の未知のリスク用。PMの裁量で利用可能。
- マネジメント予備: 予期できない事態（未知の未知）用。スポンサーの承認が必要で、プロジェクト総予算には含まれるがコストベースラインには含まれない。
具体例
- 「この機能の実装で30%の確率で手直しが発生し、20時間の追加工数が必要になる」と予測した場合、その20時間分の工数や費用をコンティンジェンシー予備として確保する。
- 想定していたリスクが結局発生しなかった場合、その予備費は解放（解放）され、他の用途に転用されたり、予算に戻されたりします。
まとめると
コンティンジェンシー予備は、「もしこれが起きたら困るから、そのための準備をしておこう」という、特定のリスクに対する備えであり、プロジェクトを柔軟かつ確実に進めるために不可欠な要素です。
ファンクションポイント法（FP法）
ファンクションポイント法（FP法）とは、ソフトウェアの機能を「数」と「複雑さ」で数値化（ポイント化）し、開発規模を定量的に計測する手法です。プログラムの行数ではなく、ユーザー視点での「入出力画面」「帳票」「ファイル数」などに基づいて評価するため、依頼者との合意（コンセンサス）が得やすく、開発言語にも依存しないという特徴があり、工数見積もりやシステム比較、投資判断などに利用されます。
FP法で計測する主な機能
システム機能を大きく2つに分け、さらに5種類に分類して計測します。
- トランザクションファンクション（データ処理機能）
- 外部入力 (EI)：システムへのデータ入力。
- 外部出力 (EO)：システムからのデータ出力（帳票など）。
- 外部照会 (EQ)：データ参照（検索など）。
- データファンクション（データ保持機能）
- 内部論理ファイル (ILF)：システム内部で管理するデータ。
- 外部インターフェイスファイル (EIF)：外部システムと連携するデータ。
計測の基本的な流れ
- 機能の洗い出しと分類: 上記5種類のファンクションを洗い出す。
- 複雑さの評価: 各機能の「低・中・高」の3段階で複雑さを評価する。
- 重み付け: 複雑さに応じた点数（重み）を掛け合わせ、合計する（未調整FP：UFP）。
- 全体係数（VAF）の算出: 性能やセキュリティなど14項目の非機能要件を評価し、補正係数を求める。
- FP値の算出: UFPにVAFを掛けて、最終的なFP値を算出する。
メリット・デメリット
- メリット: 開発言語・技術に依存しない、ユーザーと共通言語で話せる、見積もりのばらつきを抑えられる。
- デメリット: 非機能要件は数値化しにくい、過去事例のない機能の評価が難しい場合がある。
COCOMO
COCOMO（ココモ）とは、Constructive Cost Model（構造的コストモデル）の略で、ソフトウェア開発の工数（必要な人員と時間）やコストを見積もるための数学的モデルです。ソフトウェアの規模（ソースコード行数など）をベースに、開発チームの能力やプロジェクトの特性といった補正係数を考慮して、客観的に開発に必要な労力や期間を算出する手法で、1981年にBarry Boehm氏が提唱し、その後COCOMO IIへと改良されています。
主な特徴
- 客観性: プログラミング言語や開発環境に左右されず、客観的な見積もりが可能です。
- 規模ベース: 予想されるソースコードの行数（規模）を基点とします。
- 補正係数: 開発者のスキル、製品の信頼性要求、ツールの利用度などを「コストドライバー」として掛け合わせ、精度を高めます。
- モデルの進化: COCOMO81の後に、より現代的な開発手法に対応したCOCOMO IIが開発されています。
仕組み（COCOMO IIの例）
- 規模の推定: 開発するソフトウェアの規模（例：ファンクションポイント数）を推定します。
- コストドライバーの評価: プロジェクトの特性に応じた17種類のコストドライバー（例：RELY、CPLXなど）を評価します。
- 工数計算: これらの値と数式（例：工数 = A × (規模)^B × EAF（努力乗数））を用いて、工数（人月）を算出します。
なぜ重要か
COCOMOを適用することで、開発プロジェクトの初期段階で必要なリソース（人員、コスト、期間）を予測し、計画を立てることが可能になります。これにより、プロジェクトの成功率を高め、リスクを軽減するのに役立ちます。
プロジェクト品質マネジメント
プロジェクト品質マネジメントとは、プロジェクトの成果物とプロセスの両方において、顧客やステークホルダーの期待に応える品質を計画・管理・改善する活動で、品質計画・品質保証・品質管理（テスト、レビュー、改善）のプロセスから成り立ち、PMBOKでも重要な知識エリアとして位置づけられています。顧客満足度向上、コスト削減、遅延防止に繋がり、品質は「検査」だけでなく「計画段階で作り込む」ことが重要とされます。
主な構成要素
- 品質計画 (Quality Planning): プロジェクトの品質目標、基準、プロセス（テスト戦略など）を定義し、品質方針を決定します。
- 品質保証 (Quality Assurance): プロジェクトプロセスが適切に実行され、品質基準を満たしているか第三者的な視点で監査・レビューし、改善を促します。
- 品質管理 (Quality Control): 成果物やプロセスを監視・測定し、品質基準との差異を特定・是正します。テストやレビュー、問題解決活動がこれにあたります。
- 品質テスト (Quality Testing): ユーザーテスト、結合テスト、性能テストなど、具体的な品質チェックを実施します。
- フィードバックと改善 (Feedback & Improvement): 品質に関するフィードバックを収集し、教訓を次のプロジェクトに活かします。
なぜ重要なのか？
- 顧客満足度の向上: 要求される品質を満たすことで信頼を獲得し、事業継続に繋がります。
- コスト削減・遅延防止: 品質問題を早期に発見し対処することで、手戻りや追加コストを防ぎます。
- プロジェクト成功率の向上: QCD（Quality, Cost, Delivery）の一つとして、プロジェクト成功の鍵となります。
成功のためのポイント
- 品質方針の明確化と共有: 経営層の関与のもと、品質方針を定め、チーム全体で共通認識を持つ。
- コミュニケーションの重視: 顧客や関係者と継続的に期待値調整を行い、透明性を確保する。
- プロセス品質への配慮: 成果物だけでなく、プロジェクトの活動自体の品質（プロセス）も改善対象とする。
- 予防の概念: 検査で発見するだけでなく、品質が低下しないように未然に防ぐ「予防」を重視する。
プロジェクト品質マネジメントは、単なるテスト作業ではなく、プロジェクト全体を成功に導くための戦略的な活動です。
システム/ソフトウェア製品の品質特性
システム/ソフトウェア製品の品質は、JIS X 25010 : 2013で下記のように定められています。
| 主特性 | 概要 |
|---|---|
| 機能適合成 | 要求された機能を正確かつ適切に提供する能力。 |
| 性能効率性 | 時間、リソース（CPU、メモリなど）データ容量に対して効率的に機能する能力。 |
| 互換性 | 他のシステムやソフトウェアと共存し、連携できる能力。 |
| 使用性 | ユーザーが容易に理解し、学習し、操作できる能力（使いやすさ）。 |
| 信頼性 | 指定された条件下で、障害や誤動作なく機能を維持し続ける能力。 |
| セキュリティ | データやシステムへの不正アクセス、改ざん、破壊を防ぐ能力（機密性、完全性など）。 |
| 保守性 | ソフトウェアを修正、改善、適応させやすい能力（変更のしやすさ）。 |
| 移植性 | 別の環境（OS、ハードウェア、フレームワークなど）へ容易に移せる能力。 |
品質評価のポイント
- 顧客満足度の重視: 単に「動く」だけでなく、「使っていて楽しい」「操作性が高い」といった顧客の心理的満足度も重要視される。
- 品質モデルの活用: これらの特性をチェックリストとして活用し、開発の各段階で品質を測定・評価する。
- 業種・用途による重点: 金融システムなら「信頼性」や「セキュリティ」、Webサービスなら「使用性」や「性能効率性」など、分野に応じて重点特性が変わる。
これらの品質特性を総合的に評価することで、より高品質で顧客ニーズに応えるシステム・ソフトウェア開発が可能になります。
QC7つ道具
QC7つ道具とは、品質管理(Quality Control)で用いられる7つの基本的な分析・改善ツールのことで、具体的にはパレート図、特性要因図、グラフ、ヒストグラム、散布図、管理図、チェックシートを指し、問題の見える化、原因分析、工程の安定化などに使われ、品質改善活動の基本となります。
7つの道具と主な用途
- チェックシート: データの収集と整理を効率的に行う。
- パレート図: 問題の重要度（優先順位）を見える化し、重点項目を特定する（例：不良原因の8割はどれか）。
- ヒストグラム: データのばらつき（分布）状況を把握する。
- 特性要因図（フィッシュボーン図）: 問題（特性）の原因を体系的に洗い出し、要因を特定する。
- グラフ: 時系列変化や比較など、データの傾向を視覚的に把握する。
- 散布図: 2つのデータの相関関係（関係性）を確認する。
- 管理図: 工程が安定しているか（異常がないか）を監視し、工程の異常を検出・確認する。
これら7つの道具を使い分けることで、品質問題の把握から原因分析、改善策の立案・実施、効果測定までの一連のプロセスを効果的に進めることができます。
プロジェクト人的資源マネジメント
プロジェクト人的資源マネジメント（Project Human Resource Management）とは、プロジェクトを成功させるために必要な「ヒト（人材）」という資源を特定、獲得、育成、管理し、適切なタイミングで適切に活用する一連の活動のことで、PMBOK®（プロジェクトマネジメント知識体系ガイド）にも含まれる重要な分野です。具体的には、必要なスキルを持つ人材の調達・配置（チーム編成）、チームメンバーの育成（研修）、パフォーマンス向上、モチベーション管理、倫理的行動の促進などが含まれ、ステークホルダー全体を対象とします。
主な目的
- 適切な資源の確保: 必要な時に、必要なスキルを持つ人材を確保する。
- チームの育成とパフォーマンス向上: 効果的なチームを構築し、メンバーの能力を引き出す。
- プロジェクトの円滑な進行: リソースの不足やミスマッチを防ぎ、手戻りや品質低下を防ぐ。
主なプロセス（PMBOK®に基づく）
- 資源マネジメント計画: プロジェクトに必要なヒト・モノ・カネの資源管理方針を定義する。
- アクティビティ資源の見積り: 各作業に必要な人的資源（人数、スキル）を具体的に見積もる。
- 資源の獲得: 必要な人材を確保し、チームを編成する（内部調達・外部調達）。
- チームの育成: チームビルディング、研修、パフォーマンス評価などを通じてチーム力を高める。
- チームのマネジメント: メンバーのモチベーション維持、対立解消、リーダーシップ発揮などを行う。
- 資源のコントロール: 資源の利用状況を監視し、計画通りに活用されているか調整する。
重要なポイント
- 対象はチームメンバーだけではない: 顧客やスポンサーなど、プロジェクトに関わる全てのステークホルダーが対象。
- 「人・モノ・環境」を包括: ヒトだけでなく、設備やツールなどの「モノ」、作業環境も「資源」として管理する。
- 計画的なアプローチ: スコープやスケジュールと連携し、WBSに基づいて計画的に実施する。
チームの活動形態
チームの活動形態を表す用語を下記に整理します。
| 用語 | 概要 |
|---|---|
| コロケーション | プロジェクトメンバーが1つの場所に集まって作業を行うこと。 |
| ウォールーム,プロジェクトルーム | コロケーション用のスペースのこと。 |
| バーチャルチーム | 離れた場所にいるメンバーで構成されているチームのこと。 |
コンフリクトマネジメント
コンフリクトマネジメントとは、組織内で発生する対立（コンフリクト）を単なる問題として終わらせず、対話を通じて原因を特定し、相互理解を深めながら建設的な解決に導き、組織の成長やイノベーションに繋げるためのマネジメント手法です。対立を避けずに前向きに捉え、Win-Winの関係を目指し、職場の活性化や離職率低下、創造性の向上などを目的とします。
コンフリクトマネジメントの目的
- 問題解決と組織の成長: 対立の背景にある本質的な問題を見つけ出し、解決策を導くことで組織全体の成長を促します。
- Win-Winの関係構築: どちらか一方が我慢するのではなく、双方にとって良い結果（Win-Win）を目指します。
- イノベーションの促進: 多様な意見や価値観の対立を統合することで、新しいアイデアや創造性を生み出します。
- 職場環境の改善: 健全なコミュニケーションを促進し、離職率の低下や定着率向上に繋げます。
主な手法・アプローチ
コンフリクトマネジメントには、状況に応じた様々なアプローチがあります。
- 協調（協力）: 双方の意見や利益を尊重し、共に解決策を探る最も望ましい方法です。
- 妥協: 双方がある程度譲歩し、落としどころを見つける方法（双方に不満が残ることも）。
- 回避: 問題解決を先送りし、一時的にその場を避ける方法（根本解決にはならない）。
- 競争（強制）: 一方が他方の意見を無視して結論を出す方法（Win-Lose）。
- 受容（適応）: 自分の意見を抑え、相手の意見を受け入れる方法（Lose-Win）。
具体的な進め方（例）
- 現状の把握と対立の認識: どのような対立が起きているか、当事者や背景を理解します。
- 原因の分析: なぜ対立が起きているのか、根本的な原因を探ります（条件の対立、認識の対立、感情の対立など）。
- 対話と意見交換: 問題に焦点を当て、個人攻撃にならないよう、双方の意見や感情を傾聴します。
- 解決策の共同検討: 双方に納得感のある解決策を、協力して見つけ出します。
- 行動計画の策定と実行: 決定した解決策を実行し、フォローアップします。
成功のためのポイント
- コミュニケーションスキル: 傾聴力、アサーティブな（率直で適切な）自己表現、建設的なフィードバックが不可欠です。
- 中立的な視点: 必要に応じて、第三者（人事、管理職、専門家など）が介入し、公正な話し合いを促します。
- 感情のマネジメント: 医療現場のように、感情的な側面も考慮し、共感と忍耐をもって対応します。
コメント