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

ソフトウェアプロジェクト管理 (ソフトウェアプロジェクトかんり、英: software project management) は、ソフトウェアプロジェクトを計画し導く技法および技術である^[1]。ソフトウェアプロジェクト管理は、プロジェクト管理の一分野であり、ソフトウェアプロジェクトの計画、監視および制御を対象とする。

歴史[編集]

ソフトウェアプロジェクト管理の歴史は、ソフトウェアの歴史と密に関係している。 1960年代に「再利用可能な解決方法」を実現するオブジェクト指向プログラミングの概念が知られ始めるより以前では、ソフトウェアは特定の用途の向けに開発され、また特定のコンピュータ向けに開発されていた。特定用途のシステムは、コンポーネントに基づくソフトウェア工学のおかげで、他の用途に適合することができるようになった。企業は、ソフトウェアプログラミングがハードウェアの電気回路の明細図よりも相対的に簡単であることを、すぐに理解するようになった。そして、1970年代と1980年代にソフトウェア産業は急速に成長した。ソフトウェアを新しく開発する作業を管理するために、企業は、有効性が証明されたプロジェクト管理手法群を、ソフトウェアプロジェクトに適用した。しかしソフトウェアテストをする過程で、とりわけ、ユーザ仕様と出荷されたソフトウェアの間に広がるグレーゾーンに起因する混乱が発生したときに、プロジェクトのスケジュールを遅延させてしまうことが多かった。こうした問題を回避するために、ウォーターフォールモデルとして知られるソフトウェアプロジェクト管理の手法群では、ユーザの要求仕様を出荷されるソフトウェア製品に対応づけることを、重点的に扱った。ウォーターフォールモデルが採用されるようになってから、ソフトウェアプロジェクト管理の失敗が分析されることによって、以下のことが多くのソフトウェアプロジェクトに共通する失敗の原因として示された。

プロジェクトの目的が非現実的もしくは不明瞭である
必要とされる資源 (リソース) の見積りが不正確である
システム要求が、よく定義されていない
リスクが管理されていない
顧客、開発者、および利用者の間でコミュニケーションが欠如している
未成熟な技術を使用する
ソフトウェアの複雑さを制御できていない
開発の実践がずさんである
プロジェクト管理が貧弱である
利害関係者 (ステークホルダー) の間の政治的問題による悪影響がある
商業的な圧力

上記のうち最初の3項目は、顧客のニーズを明瞭にすることが困難であることを示している。特定のプロジェクト管理ツールは有用でありまた必須であることが多いが、ソフトウェアプロジェクト管理において真に有効な技法は、正しい手法 (方法論、メソドロジ) を適用しその手法を支援するツールを採用することである。なんらかの手法が適用されないのであれば、ツールの採用は無価値である。 1960年代から、いくつかのプロプライエタリなソフトウェアプロジェクト管理手法群が、ソフトウェア開発企業によりその企業自身のために開発された。同時期に、いくつかのコンピュータコンサルティング企業もまた、彼らの顧客のために似たような手法を開発した。ソフトウェアプロジェクト管理手法群は、こんにちにおいても、発展途上である。しかし現在の流行は、ウォーターフォールモデルから脱却し、ソフトウェアリリースライフサイクルを模倣した、より循環的なプロジェクトリリースモデルが牽引している。

ソフトウェア開発工程[編集]

ソフトウェア開発工程は、主にソフトウェア開発における生産側の視点と関係している。これは、ソフトウェアツールのような技術側の視点とは対照的である。ソフトウェア開発工程は、主にソフトウェア開発の管理を支援するために存在するのであり、ビジネス上の関心事に取り組む方向性とは異なる。多くのソフトウェア開発工程群を、一般的なプロジェクト管理工程群と似た方法で遂行することができる。例を示す。

リスク管理は、リスクの測定やリスクアセスメントを行い、そのリスクを管理する戦略を構築する過程である。一般的には戦略として、他の人々にリスクを移管する、リスクを回避する、リスクの負の効果を低減する、特定のリスクのすべてもしくは一部分を受け入れる、などが採用される。ソフトウェアプロジェクト管理におけるリスク管理は、プロジェクトを開始するためのビジネスケースに始まる。プロジェクト開始時のリスク管理には、費用便益分析や危機管理計画 (コンティンジェンシープラン) として知られているプロジェクト失敗からの後退オプション群のリストが、含まれる。
- リスク管理のサブセットとして、「機会管理」が注目されつつある。機会管理は、潜在的リスクにはその結果として非建設的な影響よりもむしろ建設的な影響があるとすることを除くと、リスク管理と同じ意味である。リスク管理と同一の方法で理論に基づいてプロジェクトを制御するが、非建設的な用語である「リスク」よりも「機会」という用語を使うことにより、プロジェクトチームが、自分たちのプロジェクトのリスク登録簿から得られる蓋然的に建設的な結果に注目するのを支援する。建設的な結果とは、スピンオフプロジェクトや、意外な果実、自由に使える余剰資源などである。
要求管理は、要求を同定し、顧客から聞き出し、文書化し、分析し、追跡し、優先順位づけし、顧客と合意する過程であり、要求の変更を制御する過程であり、また利害関係者 (ステイクホルダ) とコミュニケーションする過程である。新しく構築するコンピュータシステムもしくは代替するコンピュータシステム^[1]の、要求分析工程を含む要求管理は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を設計する。
変更管理は、プロジェクトのスコープに対する変更を同定し、文書化し、分析し、優先順位づけし、顧客と合意する過程であり、変更を制御する過程であり、また利害関係者とコミュニケーションする過程である。新しいスコープもしくは代替スコープの変更波及分析は、変更部分の要求分析を含む。変更波及分析は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を再設計もしくは変更する。理論的には、個々の変更はソフトウェアプロジェクトの予定と経費に影響する。そのため当然に、変更に対してはその承認前に管理の一環としてリスク便益分析が行われる。
ソフトウェア構成管理は、プロジェクトのスコープそれ自身、すなわち現に存在するソフトウェア製品を同定し文書化する過程である。付随するすべての製品とすべての変更の管理も含まれる。それにより、製品と変更について利害関係者とのコミュニケーションができるようになる。一般的には、バージョン管理、命名規約の過程を含む。
リリース管理は、ソフトウェアのリリースについて同定し、文書化し、優先順位づけし、顧客と合意する過程であり、リリーススケジュールを制御する過程であり、リリースについて利害関係者とコミュニケーションする過程である。多くのソフトウェアプロジェクトでは、ソフトウェアをリリースするために、3つのソフトウェア環境を利用する。すなわち開発環境、テスト環境、および本稼働環境 (プロダクション環境) である。非常に大規模なプロジェクトでは、地理的に分散したチームが、利用者へリリースする前に、自分たちの成果物を統合する必要がある。単体テスト、システムテストおよび統合テストなどと呼ばれるテストのための環境が別途に用意され、そして利用者受け入れテスト向けにリリースされる。
- リリース管理のサブセットとして、データ管理が注目されつつある。利用者になじみのあるデータに基づくテストができるのは、明らかに利用者だけである。そして「現実の」データは本稼働環境 (プロダクション環境) と呼ばれる環境にのみ存在する。そのためプログラマたちが自分たちの成果物をテストするためには、多くの場合「ダミーデータ」や「データスタブ」を作る必要がある。慣習的に、この目的には以前のバージョンの本稼働環境のシステムが使われてきた。しかし企業がソフトウェア開発のための外部の協力者を信頼しすぎているとの理由から、本稼働環境のデータを開発チームに渡さないこともある。複合的な環境では、全体的なソフトウェアリリーススケジュールと同様に、テストリリーススケジュールにしたがってテスト環境間で移行されるデータが作られることがある。

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

プロジェクトの計画率案の目的は、プロジェクトのスコープを同定し、それに付随する作業を見積り、プロジェクトのスケジュールを作成することである。プロジェクト計画立案は、開発すべきソフトウェアを定義する要求分析に始まる。そしてプロジェクトの完遂に向けた作業群を記述したプロジェクト計画が立案される。

プロジェクトの監視と制御の目的は、プロジェクトチームとプロジェクト管理の状況を、プロジェクトの進捗の最新の状況にあわせることである。もしプロジェクトが計画から逸脱したら、プロジェクト管理者 (プロジェクトマネージャ) は、問題を是正するための行動をとる。プロジェクトの監視と制御には、プロジェクトチームから進捗状況を報告する進捗会議の開催が含まれる。変更の必要がある場合には、開発対象のソフトウェア製品を変更するために変更管理が行われる。

課題 (イシュー)[編集]

コンピューティングにおいて、課題 (イシュー) は、システムの改善を成し遂げるための作業の単位を意味する用語である。課題は、バグの場合もあれば、要求された機能や作業の場合もあれば、文書化の欠如などの場合もある。一例として、オフィススイート開発プロジェクトであるOpenOffice.orgは、課題管理システムBugzillaの修正バージョンをIssueZillaと名づけて使っていた (2010年9月の時点では Issue Tracker の名前で使っている) 。

時を経るにつれて問題が発生し、そして適時に修正されることは、ソフトウェアシステムが正当な状態に達するために重要であり、またソフトウェアシステム製品の出荷遅延を回避する。

重大度[編集]

課題は、「重大度」の用語のもとで分類される。企業ごとに重大度の定義は異なっている。しかし共通する定義は下記のとおりである。

重大 (Critical)
高い (High): このバグもしくは課題はシステムの重要な部分に影響を与える。そして通常のシステム運用に復帰できるよう修正する必要がある。
中程度 (Medium): このバグもしくは課題はシステムの重要ではない部分に影響を与える。ただしシステム運用にいくらかの影響がある。この重大度は、中核的ではないシステム要求に影響する場合に割り当てられる。
低い (Low/Fixed): このバグもしくは課題はシステムの重要ではない部分に影響を与える。システム運用への影響は軽微である。この重大度は、中核的ではない (重要ではない) システム要求に影響する場合に割り当てられる。
些細 (見た目/美醜) (Trivial-cosmetic/aesthetic): システムは正しく動く。ただし見た目は期待したとおりではない。例えば、表示要素の色がまちがっていたり、表示要素間が離れすぎていたり近づきすぎていたり、フォントサイズがまちがっていたり、誤字があったりなど。この分類の課題は、優先度の低い課題である。

課題管理[編集]

多くのソフトウェア企業^[どれ?]では、品質保証担当者がシステムの正当性を検証する際に、課題を調査する。そして課題の解決を担当する開発者が割り当てられる。ユーザー受け入れテスト (UAT) の工程では、利用者から課題が提起されることもある。

課題は、課題管理システムもしくは欠陥追跡システムを使って広くコミュニケーションされる。また現場によっては、電子メールやインスタントメッセンジャーが使われる。

考え方[編集]

プロジェクト管理の一分野として、一部の人々はソフトウェア開発の管理は製造業における管理と同種であると考えている。この人々によれば、管理のスキルをもつが管理者であればプログラミングのスキルをもっていなくてもソフトウェア開発の管理は可能である。この考え方に対して、ジョン・C・レイノルドは反論し、ソフトウェア開発はもっぱら設計の作業であり、プログラミングできないソフトウェアプロジェクト管理者は、記事を書けない新聞編集長のようなものだと主張した ^[2]。

脚注[編集]

[脚注の使い方]

^ ^a ^b Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. オリジナルの2015年2月9日時点におけるアーカイブ。
^ John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN Notices, Volume 43, Issue 11, November 2008, p.108: "Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write."

参考文献[編集]

Jalote, Pankaj (2002). Software project management in practice. Addison-Wesley. ISBN 0201737213
Murali Chemuturi, Thomas M. Cagley Jr. & (2010). Software Project Management: Best Practices, Tools and Techniques. J.Ross Publishing. ISBN 978-1604270341

外部リンク[編集]

[Stellman05-1] Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. オリジナルの2015年2月9日時点におけるアーカイブ。

[2] John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN Notices, Volume 43, Issue 11, November 2008, p.108: "Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write."

[1]

[2]