ソフトウェアプロジェクト管理

ソフトウェアプロジェクト管理

ソフトウェアプロジェクト管理は、ソフトウェアプロジェクトを計画し、導くための技法と技術です。プロジェクト管理の一分野であり、ソフトウェア開発特有の課題に対応します。この分野は、ソフトウェアの歴史とともに発展し、現在も進化し続けています。

歴史

ソフトウェアプロジェクト管理の歴史は、ソフトウェア開発の歴史と密接に関わっています。初期のソフトウェアは特定の用途やコンピュータ向けに開発されていましたが、オブジェクト指向プログラミングの概念が登場し、ソフトウェアの再利用が可能になりました。

1970年代から1980年代にかけてソフトウェア産業が急速に成長し、プロジェクト管理の手法がソフトウェア開発にも適用されるようになりました。しかし、ユーザー仕様と実際のソフトウェアとの間に生じるずれから、スケジュール遅延が頻発しました。これを解決するために、ウォーターフォールモデルが導入され、ユーザー要求仕様とソフトウェア製品の対応付けに重点が置かれました。

ウォーターフォールモデルの採用後、プロジェクトの失敗原因が分析され、以下のような問題点が明らかになりました。

プロジェクトの目的が不明確または非現実的
リソース見積もりの不正確さ
システム要求の定義不足
リスク管理の欠如
コミュニケーション不足
未成熟な技術の利用
ソフトウェアの複雑さの制御不能
ずさんな開発実践
貧弱なプロジェクト管理
利害関係者間の政治的問題
商業的圧力

これらの問題点から、顧客のニーズを明確化することの重要性が認識されました。効果的なプロジェクト管理には、適切な手法の適用とそれを支援するツールの採用が不可欠です。手法がなければ、ツールの価値は限定的です。

近年では、ウォーターフォールモデルから、より循環的なプロジェクトリリースモデルへの移行が進んでいます。

ソフトウェア開発工程

ソフトウェア開発工程は、ソフトウェア開発の生産側の視点に関わるもので、技術側の視点とは異なります。主な目的はソフトウェア開発の管理を支援することで、ビジネス上の関心事とは異なる方向性を持っています。

多くのソフトウェア開発工程は、一般的なプロジェクト管理工程と同様の手法で遂行できます。

リスク管理

リスク管理は、リスクの測定、評価を行い、管理戦略を立てるプロセスです。リスク移転、リスク回避、リスクの負の効果の低減、リスクの受容などが戦略として採用されます。

ソフトウェアプロジェクト管理におけるリスク管理は、プロジェクト開始時のビジネスケースから始まります。リスク管理には、費用便益分析や、プロジェクト失敗からの撤退オプションが含まれます。また、「機会管理」という考え方もあります。これは、潜在的なリスクに建設的な影響がある場合にリスク管理と同様にプロジェクトを制御する手法です。「リスク」ではなく「機会」という用語を使うことで、プロジェクトチームがより建設的な結果に注目できます。

要求管理

要求管理は、顧客からの要求を特定、収集、文書化、分析し、優先順位付けし、合意するプロセスです。また、要求の変更を管理し、利害関係者とコミュニケーションを取ることも含まれます。要求管理は、新規または代替のコンピュータシステムの要求分析を含む重要な作業です。

変更管理

変更管理は、プロジェクトスコープに対する変更を特定、文書化、分析し、優先順位付けし、合意するプロセスです。また、変更を管理し、利害関係者とコミュニケーションを取ることも含まれます。スコープ変更の波及分析は、変更部分の要求分析を含み、ソフトウェア開発において重要な作業です。

ソフトウェア構成管理

ソフトウェア構成管理は、プロジェクトスコープ、つまり既存のソフトウェア製品を特定し文書化するプロセスです。製品とすべての変更を管理し、利害関係者とコミュニケーションを取ることも含まれます。一般的には、バージョン管理や命名規則が含まれます。

リリース管理

リリース管理は、ソフトウェアのリリースを特定、文書化、優先順位付けし、合意するプロセスです。リリーススケジュールを管理し、利害関係者とコミュニケーションを取ることも含まれます。多くのプロジェクトでは、開発環境、テスト環境、本番環境の3つの環境を使用します。大規模なプロジェクトでは、成果物を統合するためにテスト環境が用意され、ユーザー受け入れテストにリリースされます。

データ管理もリリース管理のサブセットとして重要です。テストは現実のデータに基づいて行う必要があり、本番環境にのみ存在します。そのため、開発者はダミーデータを作成する必要があります。

プロジェクトの計画立案、監視および制御

プロジェクトの計画立案の目的は、プロジェクトのスコープを特定し、作業を見積もり、スケジュールを作成することです。計画は、開発すべきソフトウェアを定義する要求分析から始まります。

プロジェクトの監視と制御の目的は、プロジェクトチームとプロジェクト管理の状況を、プロジェクトの進捗状況に合わせて最新の状態に保つことです。計画から逸脱した場合は、問題を是正するための行動をとります。これには、プロジェクトチームからの進捗状況を報告する進捗会議が含まれます。

課題 (イシュー)

ソフトウェア開発における課題（イシュー）とは、システムの改善を達成するための作業単位を指します。課題は、バグ、要求された機能、または文書化の欠如などの場合があります。課題は、システムが正常な状態に達するために重要であり、出荷の遅延を回避するために適切なタイミングで修正される必要があります。

重大度

課題は、その重大度に応じて分類されます。重大度の定義は企業によって異なりますが、一般的な分類は次のとおりです。

重大 (Critical): システムの重要な部分に影響し、正常な運用を回復するために修正が必要です。
高い (High): システムの重要な部分に影響します。
中程度 (Medium): システムの重要ではない部分に影響しますが、システム運用に多少の影響があります。
低い (Low/Fixed): システムの重要ではない部分に影響し、システム運用への影響は軽微です。
些細 (見た目/美醜) (Trivial-cosmetic/aesthetic): システムは正しく動作しますが、表示要素の色やレイアウトなどに問題があります。

課題管理

多くのソフトウェア企業では、品質保証担当者がシステムの正当性を検証する際に課題を調査し、開発者が解決を担当します。ユーザー受け入れテスト(UAT)中にユーザーから提起される課題もあります。課題は、課題管理システムやバグ追跡システムを使用して広く伝えられます。電子メールやインスタントメッセンジャーを使用することもあります。

考え方

プロジェクト管理の一分野として、ソフトウェア開発の管理は製造業における管理と同種であると考える人もいます。この人々は、プログラミングのスキルがなくても、管理スキルがあればソフトウェア開発を管理できると主張します。

これに対し、ジョン・C・レイノルドは、ソフトウェア開発は設計作業であり、プログラミングできないソフトウェアプロジェクト管理者は、記事を書けない新聞編集長のようなものだと反論しています。

ソフトウェアプロジェクト管理は、ソフトウェア開発の成功に不可欠な分野であり、その重要性は今後も増していくでしょう。

もう一度検索