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

ソフトウェアプロジェクト管理 (ソフトウェアプロジェクトかんり、) は、ソフトウェアプロジェクトを計画し導く技法および技術である。
ソフトウェアプロジェクト管理は、プロジェクト管理の一分野であり、ソフトウェアプロジェクトの計画、監視および制御を対象とする。
歴史.
ソフトウェアプロジェクト管理の歴史は、ソフトウェアの歴史と密に関係している。
1960年代に「再利用可能な解決方法」を実現するオブジェクト指向プログラミングの概念が知られ始めるより以前では、ソフトウェアは特定の用途の向けに開発され、また特定のコンピュータ向けに開発されていた。
特定用途のシステムは、コンポーネントに基づくソフトウェア工学のおかげで、他の用途に適合することができるようになった。
企業は、ソフトウェアプログラミングがハードウェアの電気回路の明細図よりも相対的に簡単であることを、すぐに理解するようになった。
そして、1970年代と1980年代にソフトウェア産業は急速に成長した。
ソフトウェアを新しく開発する作業を管理するために、企業は、有効性が証明されたプロジェクト管理手法群を、ソフトウェアプロジェクトに適用した。
しかしソフトウェアテストをする過程で、とりわけ、ユーザ仕様と出荷されたソフトウェアの間に広がるグレーゾーンに起因する混乱が発生したときに、プロジェクトのスケジュールを遅延させてしまうことが多かった。
こうした問題を回避するために、ウォーターフォールモデルとして知られるソフトウェアプロジェクト管理の手法群では、ユーザの要求仕様を出荷されるソフトウェア製品に対応づけることを、重点的に扱った。
ウォーターフォールモデルが採用されるようになってから、ソフトウェアプロジェクト管理の失敗が分析されることによって、以下のことが多くのソフトウェアプロジェクトに共通する失敗の原因として示された。
上記のうち最初の3項目は、顧客のニーズを明瞭にすることが困難であることを示している。
特定のプロジェクト管理ツールは有用でありまた必須であることが多いが、ソフトウェアプロジェクト管理において真に有効な技法は、正しい手法 (方法論、メソドロジ) を適用しその手法を支援するツールを採用することである。
なんらかの手法が適用されないのであれば、ツールの採用は無価値である。
1960年代から、いくつかのプロプライエタリなソフトウェアプロジェクト管理手法群が、ソフトウェア開発企業によりその企業自身のために開発された。
同時期に、いくつかのコンピュータコンサルティング企業もまた、彼らの顧客のために似たような手法を開発した。
ソフトウェアプロジェクト管理手法群は、こんにちにおいても、発展途上である。
しかし現在の流行は、ウォーターフォールモデルから脱却し、ソフトウェアリリースライフサイクルを模倣した、より循環的なプロジェクトリリースモデルが牽引している。
ソフトウェア開発工程.
ソフトウェア開発工程は、主にソフトウェア開発における生産側の視点と関係している。
これは、ソフトウェアツールのような技術側の視点とは対照的である。
ソフトウェア開発工程は、主にソフトウェア開発の管理を支援するために存在するのであり、ビジネス上の関心事に取り組む方向性とは異なる。
多くのソフトウェア開発工程群を、一般的なプロジェクト管理工程群と似た方法で遂行することができる。
例を示す。
プロジェクトの計画立案、監視および制御.
プロジェクトの計画率案の目的は、プロジェクトのスコープを同定し、それに付随する作業を見積り、プロジェクトのスケジュールを作成することである。
プロジェクト計画立案は、開発すべきソフトウェアを定義する要求分析に始まる。
そしてプロジェクトの完遂に向けた作業群を記述したプロジェクト計画が立案される。
プロジェクトの監視と制御の目的は、プロジェクトチームとプロジェクト管理の状況を、プロジェクトの進捗の最新の状況にあわせることである。
もしプロジェクトが計画から逸脱したら、プロジェクト管理者 (プロジェクトマネージャ) は、問題を是正するための行動をとる。
プロジェクトの監視と制御には、プロジェクトチームから進捗状況を報告する進捗会議の開催が含まれる。
変更の必要がある場合には、開発対象のソフトウェア製品を変更するために変更管理が行われる。
課題 (イシュー).
コンピューティングにおいて、課題 (イシュー) は、システムの改善を成し遂げるための作業の単位を意味する用語である。
課題は、バグの場合もあれば、要求された機能や作業の場合もあれば、文書化の欠如などの場合もある。
一例として、オフィススイート開発プロジェクトであるOpenOffice.orgは、課題管理システムBugzillaの修正バージョンをIssueZillaと名づけて使っていた (2010年9月の時点では Issue Tracker の名前で使っている) 。
時を経るにつれて問題が発生し、そして適時に修正されることは、ソフトウェアシステムが正当な状態に達するために重要であり、またソフトウェアシステム製品の出荷遅延を回避する。
重大度.
課題は、「重大度」の用語のもとで分類される。
企業ごとに重大度の定義は異なっている。
しかし共通する定義は下記のとおりである。
課題管理.
多くのソフトウェア企業では、品質保証担当者がシステムの正当性を検証する際に、課題を調査する。そして課題の解決を担当する開発者が割り当てられる。ユーザー受け入れテスト (UAT) の工程では、利用者から課題が提起されることもある。
課題は、課題管理システムもしくは欠陥追跡システムを使って広くコミュニケーションされる。
また現場によっては、電子メールやインスタントメッセンジャーが使われる。
考え方.
プロジェクト管理の一分野として、一部の人々はソフトウェア開発の管理は製造業における管理と同種であると考えている。この人々によれば、管理のスキルをもつが管理者であればプログラミングのスキルをもっていなくてもソフトウェア開発の管理は可能である。
この考え方に対して、ジョン・C・レイノルドは反論し、ソフトウェア開発はもっぱら設計の作業であり、プログラミングできないソフトウェアプロジェクト管理者は、記事を書けない新聞編集長のようなものだと主張した