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

ソフトウェアプロジェクト管理とは、ソフトウェアプロジェクトを計画し、主導するプロセスです。^{[ 1 ]}これはプロジェクト管理のサブ分野であり、ソフトウェアプロジェクトの計画、実装、監視、および制御を行います。

1970年代から1980年代にかけて、ソフトウェア業界は急速に成長しました。これは、コンピュータ企業がハードウェアや回路の製造に比べてソフトウェアの製造コストが比較的低いことをいち早く認識したためです。新たな開発作業を管理するために、企業は既存のプロジェクト管理手法を適用しましたが、特にユーザー仕様と納品されたソフトウェアの間の曖昧な部分で混乱が生じた際に、テスト実行中にプロジェクトスケジュールが遅れることがありました。こうした問題を回避するために、ソフトウェアプロジェクト管理手法は、ユーザーの要求と納品された製品を一致させることに重点を置くようになり、現在ではウォーターフォールモデルとして知られています。

業界が成熟するにつれて、ソフトウェアプロジェクト管理の失敗の分析により、最も一般的な原因は次のとおりであることが明らかになりました。^{[ 2 ] [ 3 ] [ 4 ]}

1. エンドユーザーの関与が不十分
2. 顧客、開発者、ユーザー、プロジェクトマネージャー間のコミュニケーション不足
3. 非現実的または明確に示されていないプロジェクト目標
4. 必要な資源の不正確な見積もり
5. システム要件と仕様が不明確または不完全である。
6. プロジェクトの状況報告が不十分
7. リスク管理の不備
8. 未成熟な技術の使用
9. プロジェクトの複雑さに対処できない
10. ずさんな開発手法
11. 利害関係者間の政治的駆け引き（例：経営陣の支援の欠如、顧客とエンドユーザー間の政治的駆け引き）
12. 商業的な圧力

上記のリストの最初の 5 つの項目は、適切なリソースによって適切なプロジェクト目標を達成できるような形でクライアントのニーズを明確にすることの難しさを示しています。特定のソフトウェア プロジェクト管理ツールは有用であり、多くの場合必要不可欠ですが、ソフトウェア プロジェクト管理の真髄は、正しい方法を適用し、その方法をサポートするツールを使用することにあります。方法がなければ、ツールは無意味です。1960 年代以降、ソフトウェアメーカーは自社用にいくつかの独自のソフトウェア プロジェクト管理方法を開発し、コンピュータ コンサルティング会社も顧客向けに同様の方法を開発してきました。今日でもソフトウェア プロジェクト管理方法は進化を続けていますが、現在の傾向はウォーターフォール モデルから、ソフトウェア開発プロセスを模倣したより循環的なプロジェクト デリバリー モデルへと移行しています。

ソフトウェア開発プロセスは、ソフトウェアツールなどの技術的な側面ではなく、ソフトウェア開発の生産的な側面に主眼を置いています。これらのプロセスは主にソフトウェア開発の管理を支援するために存在し、一般的にビジネス上の懸念事項への対応に重点を置いています。多くのソフトウェア開発プロセスは、一般的なプロジェクト管理プロセスと同様の方法で実行できます。例としては、次のものがあります。

• 対人コミュニケーションと紛争管理および解決。積極的かつ頻繁で誠実なコミュニケーションは、プロジェクトの成功確率を高め、問題のあるプロジェクトを軽減する上で最も重要な要素です。開発チームはエンドユーザーの参加を求め、開発プロセスへのユーザーの意見を奨励する必要があります。ユーザーが関与しないと、要件の誤解、変化する顧客ニーズへの無関心、クライアント側の非現実的な期待につながる可能性があります。ソフトウェア開発者、ユーザー、プロジェクトマネージャー、顧客、プロジェクトスポンサーは、定期的かつ頻繁にコミュニケーションを取る必要があります。これらの議論から得られる情報により、プロジェクトチームは強み、弱み、機会、脅威（SWOT）を分析し、その情報に基づいて行動して機会を最大限に活用し、脅威を最小限に抑えることができます。たとえ悪いニュースであっても、比較的早い段階で伝えられれば良い結果につながる可能性があります。なぜなら、問題が発見されるのが遅すぎなければ、軽減できるからです。たとえば、ユーザー、チームメンバー、その他の利害関係者との何気ない会話は、正式な会議よりも早く潜在的な問題を明らかにすることがよくあります。すべてのコミュニケーションは知的誠実さと真正性を備えている必要があり、開発作業に対する定期的かつ頻繁な質の高い批判は、冷静で敬意を払い、建設的で、非難的でも怒りに満ちたものでもない方法で行われる限り、必要不可欠です。開発者とエンドユーザー間、およびプロジェクトマネージャーとクライアント間の頻繁な非公式なコミュニケーションは、プロジェクトをエンドユーザーにとって関連性があり、有用で効果的なものに保ち、かつ完了可能な範囲内に収めるために必要です。効果的な対人コミュニケーションと紛争管理および解決は、ソフトウェアプロジェクト管理の鍵となります。いかなる方法論やプロセス改善戦略も、コミュニケーションにおける深刻な問題や対人紛争の管理の不備を克服することはできません。さらに、そのような方法論やプロセス改善戦略に関連する成果は、より良いコミュニケーションによって向上します。コミュニケーションは、チームがプロジェクト憲章を理解しているかどうか、そしてチームがその目標に向かって進歩しているかどうかに焦点を当てる必要があります。エンドユーザー、ソフトウェア開発者、プロジェクトマネージャーは、問題が深刻な事態に発展する前に問題を特定するのに役立つ、基本的で単純な質問を頻繁に行う必要があります。エンドユーザーの参加、効果的なコミュニケーション、チームワークだけでは十分ではないが、良い結果を確実にするためには必要であり、これらが欠けているとほぼ確実に悪い結果につながる。^{[ 3 ] [ 4 ] [ 5 ]}
• リスク管理とは、リスクを測定または評価し、そのリスクを管理するための戦略を策定するプロセスです。一般的に、採用される戦略には、リスクを他者に移転する、リスクを回避する、リスクによる悪影響を軽減する、特定のリスクの結果の一部または全部を受け入れる、といったものがあります。ソフトウェアプロジェクト管理におけるリスク管理は、プロジェクト開始のビジネスケースから始まります。ビジネスケースには、費用対効果分析と、プロジェクト失敗時の代替案（コンティンジェンシープラン）のリストが含まれます。
  • リスク管理の一分野として機会管理があります。これは、潜在的なリスクの結果がマイナスではなくプラスの影響を与えるという点を除けば、リスク管理とほぼ同じ意味を持ちます。理論的には同じように扱われますが、やや否定的なニュアンスを含む「リスク」ではなく「機会」という用語を使うことで、チームはプロジェクトにおけるあらゆるリスク登録から生じる可能性のあるプラスの結果、例えばスピンオフプロジェクト、予期せぬ利益、無料の追加リソースなどに焦点を当て続けることができます。
• 要件管理とは、要件を特定、引き出し、文書化、分析、追跡、優先順位付け、合意し、変更を管理し、関連する利害関係者に伝えるプロセスです。新規または変更されたコンピュータ システム^{[ 1 ]}要件管理は、要件分析を含み、ソフトウェア エンジニアリングプロセスの重要な部分です。ビジネス アナリストまたはソフトウェア開発者がクライアントのニーズまたは要件を特定し、これらの要件を特定した後、ソリューションを設計できる立場になります。
• 変更管理とは、スコープ（プロジェクト管理）の変更を特定、文書化、分析、優先順位付け、合意し、その後変更を管理し、関係する利害関係者に伝えるプロセスです。変更レベルでの要件分析を含む、新規または変更されたスコープの変更影響分析は、ソフトウェアエンジニアリングプロセスの重要な部分です。これにより、ビジネスアナリストまたはソフトウェア開発者は、クライアントの変更されたニーズまたは要件を特定します。これらの要件を特定した後、彼らはソリューションを再設計または修正することができます。理論的には、各変更はソフトウェアプロジェクトのタイムラインと予算に影響を与える可能性があるため、定義上、承認前にリスクとメリットの分析を含める必要があります。
• ソフトウェア構成管理とは、開発中のソフトウェア製品（すべてのサブ製品と変更点を含む）の範囲を特定し、文書化するプロセスであり、関連する利害関係者への情報伝達を可能にするものです。一般的に、採用されるプロセスには、バージョン管理、命名規則（プログラミング）、およびソフトウェアアーカイブに関する合意が含まれます。
• リリース管理とは、ソフトウェアのリリースを特定、文書化、優先順位付け、合意し、リリーススケジュールを管理し、関係者に伝達するプロセスです。ほとんどのソフトウェアプロジェクトでは、開発、テスト、本番という3つのソフトウェア環境にソフトウェアをリリースできます。非常に大規模なプロジェクトでは、分散したチームがユーザーにリリースする前に作業を統合する必要があるため、ユーザー受け入れテスト（UAT）にリリースする前に、単体テスト、システムテスト、統合テストなど、テスト用の環境がさらに多く存在することがよくあります。
  • リリース管理のサブセットとして注目を集めているのがデータ管理です。当然ながら、ユーザーは既知のデータに基づいてしかテストできず、「実際の」データは「本番環境」と呼ばれるソフトウェア環境にしか存在しないためです。そのため、プログラマーはテストを行うために「ダミーデータ」や「データスタブ」を作成する必要が生じます。従来は、本番システムの古いバージョンがこの目的で使用されていましたが、企業がソフトウェア開発を外部のコントリビューターにますます依存するようになるにつれ、企業データが開発チームに公開されなくなる場合があります。複雑な環境では、データセットが作成され、ソフトウェア全体のリリーススケジュールと同様に、テストリリーススケジュールに従ってテスト環境間で移行されることがあります。
• 保守とアップデートは、要件と顧客ニーズが常に関わるプロセスです。顧客は必ずバグを発見し、新機能のリクエストや、さまざまな機能の追加、さらなるアップデートを求めるでしょう。したがって、これらのリクエストすべてを確認し、顧客の要件と満足度を満たす必要があります。

プロジェクト計画の目的は、プロジェクトの範囲を特定し、必要な作業を見積もり、プロジェクトスケジュールを作成することです。プロジェクト計画は、開発するソフトウェアを定義する要件から始まります。次に、プロジェクト計画を作成し、完了に至るまでのタスクを記述します。プロジェクトの実行とは、プロジェクト計画で定義されたタスクを完了するプロセスです。

プロジェクトの監視と管理の目的は、チームと経営陣にプロジェクトの進捗状況を常に最新の状態に保つことです。プロジェクトが計画から逸脱した場合、プロジェクトマネージャーは問題を修正するための措置を講じることができます。プロジェクトの監視と管理には、チームから状況を把握するための進捗会議が含まれます。変更が必要な場合は、変更管理を使用して製品を最新の状態に保ちます。

コンピューティングにおいて、「課題」という用語は、システムの改善を達成するための作業単位を指します。^{[ 6 ]} 課題には、バグ、要求された機能、タスク、不足しているドキュメントなどが含まれます。

例えば、OpenOffice.org は、 Bugzillaの改良版をIssueZilla と呼んでいました。2010年 9 月現在彼らは自分たちのシステムを課題追跡システムと呼んでいる。^{[ 7 ]}

プロジェクト管理のサブ分野として、ソフトウェア開発の管理は、管理スキルはあってもプログラミングスキルを持たない人が行える製造業の管理に似ていると考える人もいる。ジョン・C・レイノルズはこの見解に反論し、ソフトウェア開発は完全に設計作業であると主張し、プログラミングのできないマネージャーを、文章を書くことができない新聞の編集長に例えている。^{[ 12 ]}

一般的な

• 16326:2019(E) - ISO/IEC/IEEE 国際規格 - システムおよびソフトウェアエンジニアリング - ライフサイクルプロセス - プロジェクト管理。2019年。doi : 10.1109 /IEEESTD.2019.8932690。ISBN 978-1-5044-6299-0。
• 1058-1998 - IEEEソフトウェアプロジェクト管理計画規格。1998年。doi : 10.1109 /IEEESTD.1998.88822。ISBN 978-0-7381-1448-4。
• ジャロテ、パンカジ（2002）。実践におけるソフトウェアプロジェクト管理。アディソン・ウェスリー。ISBN 0-201-73721-3。
• Murali Chemuturi、Thomas M. Cagley Jr. 他(2010)。ソフトウェアプロジェクト管理：ベストプラクティス、ツール、テクニック。J.Ross Publishing。ISBN 978-1-60427-034-1。

• ウィキメディア・コモンズにあるソフトウェアプロジェクト管理関連のメディア

• Robert Frese (2003-12-16). 「プロジェクトの成功と失敗：成功とは何か、失敗とは何か、そして成功の可能性を高めるにはどうすればよいか？」ミズーリ大学セントルイス校。2015-05-13に取得。