ソフトウェア開発におけるプロジェクト管理の「誰が」、「なぜ」、「どのように」

あなたはソフトウェア開発に挑戦しています。 将来を見据えたアイデア、詳細な要件、十分な技術的専門知識、熟練したチームが必要です。 専門のプロジェクト マネージャーが不足しているだけです。 上記の条件で、プロジェクトを完了する確率はどのくらいですか?

悲しいことに、成功の可能性はそれほど高くありません。 さまざまな調査によると、ソフトウェア開発の失敗の主な原因は、プロジェクト管理の不備にあることがほとんどです。

ソフトウェア開発プロジェクトの管理における失敗の原因となるよくある間違いは、プロジェクトの目標の変更、不十分なコミュニケーション、不十分な変更管理、不正確なコスト見積もり、未確認のリスクなどです。

したがって、プロジェクトが暴走しないようにするには、健全なプロジェクト管理を優先する必要があります。 以下では、エンタープライズ ソフトウェア ソリューション開発の専門知識を共有し、ソフトウェア開発プロジェクトの管理に関する深刻な質問に答えます。

ソフトウェア開発プロジェクトの成功にとって、プロジェクト管理はどれほど重要ですか?

要するに、非常に。

通常、ソフトウェア開発プロジェクトは非常に複雑です。 プロジェクトが成功したと見なされるためには、要件を満たし、高い実行品質を保証しながら、予定どおりに予算内で完了する必要があります。 そして、それがプロジェクトマネージャーの責任です。

したがって、ソフトウェア開発プロジェクトを管理するために専任の人材を採用することの利点は次のとおりです。

• リスクの軽減
• プロジェクト マネージャーは、効果的なリスク管理を担当します。 プロジェクトの開始時に、潜在的なリスクを計画、文書化、優先順位付けし、リスク対応戦略​​を設計します。

リスクに対応する 4 つの一般的な方法は次のとおりです。

• 回避:脅威を排除または回避する
• 緩和:脅威の可能性または影響を軽減します
• 転送:脅威を第三者に割り当てるか移動します
• 受け入れる:脅威を認め、それを解決、転送、軽減しないことを選択します。

適切なリスク対応戦略​​を考え出すために、プロジェクト マネージャーは、チームとのブレインストーミング セッションを設定したり、ストーリーボードに頼ったり、運用のすべての部分から個人にインタビューしたりすることがあります。 リスク管理戦略が手元にあれば、プロジェクト チームはリスクを予測し、タイムリーに防止することが容易になります。

• プロジェクト コストのより適切な管理
• ソフトウェア開発プロジェクトの管理では、コスト超過がよく発生します。 マージンに影響を与えるだけでなく、プロジェクトの実行能力を妨げるため、経験豊富な PM がコスト管理への最適なアプローチを考え出します。
• 彼らは、承認された範囲内で支出を維持することを目指して、プロジェクトのライフサイクル全体でコストを見積もり、予算を立て、管理します。 健全なコスト管理は、利害関係者の期待値の設定、スコープ クリープの制御、プロジェクトの ROI の向上、長期的なコストの傾向の監視にも役立ちます。
• リソースの最適利用
• ソフトウェア開発における健全なプロジェクト管理は、人員、スキル、時間、ツール、機器、およびサービスにまたがるすべてのプロジェクト リソースが調整され、効率的に利用されるようにするのに役立ちます。
• プロジェクトの発見フェーズでは、PM が必要なリソースを見積もり、割り当て、計画し、優先順位に従って配布します。 開発中、PM はリソースの使用率を追跡し、プロジェクトの完了を妨げる可能性のあるボトルネックを取り除きます。
• プロジェクト範囲のより良い管理
• ソフトウェア開発プロジェクトを管理する際の一般的な問題であるスコープ クリープは、回避することをお勧めします。 管理されていない変更は、プロジェクトのスケジュール、予算、コスト、およびリソースの割り当てに影響を与えるだけでなく、マイルストーンの達成を危うくします。
• ソフトウェア開発におけるプロジェクト管理にアプローチする PM は、変更要求手順を設定し、新しい要件ごとにそれに従うようにします。 目的は、制御されていないスコープ クリープを回避し、プロジェクトが予定どおりに予算内で提供されるようにすることです。 新しい活動が承認され、範囲に追加されると、プロジェクトのタイムラインと予算のベースラインがそれに応じて更新されます。

ソフトウェア開発におけるプロジェクト管理とは?

ソフトウェア開発におけるプロジェクト管理は、利用可能なリソースと制約を考慮して、プロジェクト活動を計画、スケジューリング、および追跡する技術です。

前述のように、ソフトウェア開発プロジェクトは非常に複雑で、複数の段階が含まれます。 プロジェクト マネージャーは、これらの段階全体でプロジェクトの実行を計画し、監督します。

Project Management Institute によると、PM の観点から見ると、ソフトウェア開発ライフ サイクルには 5 つの重要な段階があります。

• プロジェクト構想

プロジェクト構想段階の主な目標は、主要なプロジェクト目標を決定し、ビジネス ニーズを定義し、作業明細書を作成することです。 後者には、何よりも、将来のソリューションの要件とプロジェクトの配信スケジュールを含める必要があります。 通常、プロジェクトの構想には、ビジネス アナリストとプロジェクト マネージャーが主導する、すべてのプロジェクト関係者間の緊密な協力が必要です。

• プロジェクト計画

プロジェクト計画段階は、プロジェクト マネージャーとプロジェクト チームの共同作業です。 プロジェクト チームは、ソリューションの技術アーキテクチャを設計し、そのルック アンド フィールを考え出します。 次に、PM は、プロジェクト計画を考案し、作業分解構造を作成し、プロジェクト スケジュールを準備します。 この段階の最終目標は、プロジェクトの範囲を明確に理解し、プロジェクトのパフォーマンスの監視と制御の基礎を確立することです。

この段階で、PM は、コミュニケーション ツールと進捗追跡ツール、および将来の展開の計画を設定し、受け入れ基準を定義します。

• プロジェクトの立ち上げと実行

プロジェクト チームが将来のソリューションのエンジニアリングとテストに従事している間、プロジェクト マネージャーはチームのパフォーマンスを監視し、プロジェクトの作業を妨げる可能性のあるボトルネックを取り除き、チーム メンバーとプロジェクトの利害関係者の間のコミュニケーションを促進し、プロジェクトの進捗状況を文書化し、リスク トリガーを追跡し、報告します。クライアントまたは上級管理職に。

• プロジェクト受入

プロジェクトの承認段階では、ソリューションまたは一連の成果物がステージング環境に展開され、そこでベータ テストが行​​われます。 開発チームは、必要に応じて必要なキツネを提供します。 PM は、ソリューションが完全に予定どおりに提供されるようにし、提供されたソフトウェアが合意された承認基準を満たしていることを保証します。 プロジェクト受け入れ段階でのソフトウェア開発におけるプロジェクト管理の別の部分では、ユーザー ガイド、インストール手順、およびその他のプロジェクト ドキュメントの準備を扱います。

• プロジェクトの完了

プロジェクトが完了すると、プロジェクト マネージャーはレトロスペクティブ レビューを行い、そこでプロジェクト全体の浮き沈みを評価して文書化します。 また、すべてのソース コード、ソフトウェア ドキュメント、開発環境などを含む、成果物の全範囲がクライアント/製品所有者に引き渡されるようにします。

これらの重要な段階は、ソフトウェア開発プロジェクトを管理するために選択したアプローチに応じて、直線的に相互に続くか、より重複することができます。

ソフトウェア開発におけるプロジェクト管理: 一般的な方法論

最も広く使用されているソフトウェア プロジェクト管理方法論には、スクラム、カンバン (どちらもアジャイル ファミリーに属する)、およびウォーターフォールが含まれます。

ソフトウェア開発スパンにおけるプロジェクト管理のあまり一般的ではないアプローチとして、インクリメンタル開発モデル、スパイラル モデル、PRINCE2、Rational Unified Process (RUP) などがあります。

スクラム

ソフトウェア開発におけるプロジェクト管理の最も一般的なアプローチの 1 つであるスクラムは、開発プロセスを 2 ～ 4 週間のスプリントに分割します。 通常、スプリントの前には綿密な計画が立てられます。 不確実性の高いプロジェクトに適したスクラムは、機能横断的で自己組織化されたチームに依存し、観察と実験に基づく漸進的な開発のアイデアを取り入れています。

ソフトウェア開発におけるスクラムベースのプロジェクト管理は、PM 自体がないため、従来の管理とは少し異なります。 代わりに、1 人の責任はプロダクト オーナーとスクラム マスターの間で共有されます。

かんばん

かんばんの特徴は、反復が明示的に定義されていないことです。 これは、プロジェクトの範囲を視覚化し、進行中の作業を制限し、スムーズな作業の流れを確保するのに役立つ、ソフトウェア開発プロジェクトを管理するための無駄のないアプローチです。 この方法論では、チーム独自の作業プロセスを表す物理的またはデジタルのかんばんボードを使用します。

その性質上、このモデルはサポートおよび保守プロジェクトに適しています。

かんばんのもう 1 つの特徴は、進行中の作業量に制限を設けることです。 この方法論は、範囲とリソースのバランスを取ることを目的としています。 タスクは、要求されたときにプロセスにプッシュされるのではなく、利用可能な容量が許す限りプルされます。

ソフトウェア開発プロジェクトを管理する責任は、通常、Kanban に不可欠な 2 つの役割 (サービス提供マネージャーとサービス リクエスト マネージャー) の間で共有されます。 前者はワークフローの効率化を担当し、後者は主にクライアントのニーズと期待を解釈することに従事しています。

ただし、カンバン ルールに合わせて追加のチーム メンバーを雇う必要はありません。 実際には、経験豊富な PM は通常、両方の役割に適しています。

滝

アジャイル ファミリーとは対照的に、ウォーターフォール ベースのプロジェクト管理では、プロジェクトを個別の連続したフェーズに分割します。

伝統的に、前のフェーズが完全に完了すると、新しいフェーズが開始されます。 ただし、最新のウォーターフォール プロジェクトでは、ある程度の重複が許容されます。 たとえば、テスト チームが開発中に個々の機能の検証を開始することは非常に一般的です。

ソフトウェア開発プロジェクトを管理するためのウォーターフォール アプローチは、予測可能な範囲のプロジェクトではうまく機能しますが、それでも、開発チームが立ち往生し、競合他社よりも速く調整することができなくなる可能性があります。

ウォーターフォールとアジャイルのプロジェクト管理には特徴があるため、主な違いについて詳しく見ていきましょう。

ウォーターフォールとアジャイルのプロジェクト管理の違いは何ですか?

では、ウォーターフォール プロジェクトとアジャイル プロジェクトで管理手法がどのように異なるかを詳しく見てみましょう。 この 2 つを比較しているのは、他のプロジェクト管理方法論よりも一般的であり、両方のプロジェクト作業の編成方法に大きな違いがあるためです。 後者は、プロジェクト マネージャー (またはアジャイルでのそれぞれの役割) の役割と責任に影響を与えます。

プロジェクト計画

Waterfall では、構築しているものとその理由を完全に理解していなければ、先に進むことはできません。 そのため、包括的なソフトウェア要件仕様を作成することがウォーターフォール プロジェクトの最優先事項です。 通常、SRS はビジネス アナリストによって作成されます。 ただし、プロジェクト マネージャーが不在の場合は、プロジェクト マネージャーが引き継ぐことができます。

一方、アジャイルは柔軟性を高めます。 外出先で製品とプロセスの改善を導入することは、アジャイル方法論の本質です。 計画活動は通常、1 スプリント前に実行されます。 バックログは、いわゆるスプリント ゼロの間に作成されます。

スプリント ゼロでは、チームは最小限の数のユーザー ストーリーを考え出して実行可能な製品にし、必要に応じて開発用のインフラストラクチャをセットアップします。 スプリントは通常、軽量で高レベルに保たれます。

プロジェクト範囲の管理と予算編成

ウォーターフォールでは、ソリューション スコープはプロジェクト全体でそのまま維持する必要があります。 変更要求は、変更管理手順を通じて管理され、別途請求されます。 アジャイル ソフトウェア開発におけるプロジェクト管理は、スコープ管理の点でより柔軟性を提供しますが、最終的なソフトウェア コストに対するスコープ変更の影響を評価することを困難にします。 これは、プロジェクトの予算編成へのアプローチに影響します。

Waterfall では、予算はトップダウンで管理され、詳細なビジネス ケースに基づいています。 このようなアプローチにより、要件が引き出されて分析されると、現実的なコスト見積もりを出すことが可能になります。 主な欠点は、このアプローチは、不安定で不確実で曖昧な環境では機能しないことです。これは、ソフトウェア開発プロジェクトでよくあることです。

ソフトウェア開発プロジェクトのコストを管理するアジャイルの方法は、変化に敏感です。 そして、それは利点であると同時に複雑さでもあります。 アジャイルな予算編成は、プロジェクトの構造とスケジュールに合わせて調整されます。 また、スプリント構造にも従っているため、プロジェクトの予算全体に影響を与えることなく、チームが状況の変化に簡単に適応できます。 プロジェクト マネージャーは、次の計画ラウンドで支出を再調整するだけです。

プロジェクトの成果物

アジャイル ルートに進むことで、企業は反復のたびに、新しい機能やその他の成果物 (技術的なビジョン、実用的な機能、MVP など) の増分を得ることができます。

一方、従来のウォーターフォールでは、プロジェクトが終了するまで、クライアントは一貫した実用的なソリューションを実際には得られません。 本格的なテスト活動も開発プロセスの後半で実施されるため、市場投入までの時間に影響を与える可能性があります。

プロジェクト文書

ウォーターフォールによると、ソフトウェア開発プロジェクトを管理するには、適切で文書化された計画が不可欠です。 プロジェクトの要件は事前に明確にしておく必要があり、各チーム メンバーはそれを認識している必要があります。 また、各チーム メンバーは、プロジェクト内での自分の役割と、自分に期待されていることを理解する必要があります。 通常、この情報も文書化され、プロジェクト チーム間で配布されます。

ウォーターフォール チームは、進捗状況を追跡しやすくするために、開発プロセス全体を通してドキュメントを頻繁に参照します。 Waterfall に従って通常管理されるプロジェクトの長さと複雑さを考えると、これが唯一の方法です。 文書化はすべての段階で行われ、モデルの連続的な性質にもかかわらず、プロジェクトの進捗状況について全員が同じページにいることを保証します.

広範なドキュメントは、ウォーターフォールではリスク軽減に役立ちますが、アジャイルでは変更への適応性を低下させます。 したがって、アジャイル プロジェクトではドキュメントの作成が少なくなるのが一般的です。 そしてそれが作成された場合、ドキュメントは簡潔に保たれます。

しかし、一般的な誤解にもかかわらず、アジャイル手法には、チームが必要なだけ多くのドキュメントを作成することを本質的に妨げるものは何もありません。 実際、絶対に必要な書類もあります。 バックログにユーザー ストーリーを追加し、ワイヤーフレームを作成し、クライアントとのミーティングを文書化することは必須です。 アジャイルが提案するのは、文書化プロセスをより賢くし、長すぎる文書化を避けることです。

プロジェクトマネージャーの責任は何ですか？

プロジェクト マネージャーの責任も、ソフトウェア開発プロジェクトを管理するアプローチによって異なります。 PM またはそれぞれのアジャイルの役割が、プロジェクトの各段階で正確に何をするかを見てみましょう。

滝で

プロジェクト マネージャーは、すべてのウォーターフォール チームで最も重要な役割です。 彼らは、成果物の品質と、プロジェクトがスケジュールどおりに完了することに責任を負います。 彼らの主な責任には、プロジェクト活動の監督とチーム メンバーのタスクの指定が含まれます。

それでは、PM の作業範囲をフェーズに分けてみましょう。

アジャイルで

アジャイル プロジェクト マネージャーは、各スプリントのバックログ項目に優先順位を付け、開発の進捗状況を監視し、チーム内およびチームと利害関係者の間で効果的なコミュニケーションを確立します。 また、プロジェクトの各段階でリスクを監視し、開発プロセスがアジャイルの原則に準拠していることを確認します。

これは、プロジェクト マネージャーがアジャイル プロジェクトの各段階で具体的に行うことです。

プロジェクトマネージャーが注意すべき落とし穴は何ですか?

ソフトウェア開発プロジェクトの管理を成功させる鍵は、リスクを防止および回避できることです。 優れた PM が気をつけなければならないよくある落とし穴は、次のとおりです。

スコープを制御できない

特にアジャイルでは、クライアントが外出先で追加機能を要求するのが一般的であり、プロジェクトが失敗することがよくあります。 したがって、プロジェクト マネージャーは、スコープ クリープを防止するために、明確な変更管理手順を導入する必要があります。 また、変更がプロジェクトのタイムラインとリソースに与える影響について、利害関係者が同じ認識を持っていることを確認する必要もあります。

納期厳守を重視しない

たとえば、学年の開始前にリリースする必要がある教育アプリや、クリスマス セールに間に合うように展開する必要がある小売アプリなど、市場投入までの時間が厳しい要件を持つ製品を開発する場合、PM はストライキを行う必要があります。時間厳守と高品質の確保の間の適切なバランス。

彼らは、機能の優先順位付けと、各機能の提供期限の設定に余分な労力を費やす必要があります。 ロールアウト後に問題が発生しないように、品質要件も事前に定義する必要があります。

効果的なコミュニケーションを確立できない

ソフトウェア開発における効果的なプロジェクト管理には、効果的で透明性のあるコミュニケーションが必要です。 1 つを確立することは、PM の主要な責任です。 彼らは、利害関係者の決定をチームに通知し続け、すべてのプロジェクト活動、ボトルネック、および課題について利害関係者に定期的に通知する必要があります。

明確なプロセスを確立できていない

ソフトウェア開発プロセスに従うことは、チーム メンバーにとって重荷のように思えるかもしれません。 それでも、プロジェクトの仕様に合わせた明確なワークフローを設定する必要があります。 仕事を構造化し、期待を明確にします。

慣れない技術に頼る

プロジェクト マネージャーは、技術を選択する際に、エンジニアリング チームが顧客のビジネス上の問題を解決することに集中できるようにする必要があります。 また、選択した技術スタックがエンジニアリングのベスト プラクティスに沿っていることを確認する必要もあります。

テクノロジに関連するもう 1 つの落とし穴は、製品開発の初期段階でスケーラビリティの計画を立てていないことです。 したがって、スケーラビリティ要件を他の非機能要件とともに事前に定義することをお勧めします。

ロールアウト プロセスを事前に考えていない

ロールアウト プロセスは、開発の初期段階で見落とされることが多く、展開中に重大な遅延が発生します。 ソフトウェア開発における健全なプロジェクト管理には、PM がロールアウトとインストールの問題を開発プロセスの早い段階で確実に検討する必要があります。

ソフトウェア開発におけるプロジェクト管理のアプローチ方法: ITRex の視点

ITRex のリード PM である Alexander Belkavets 氏にインタビューし、ITRex でのソフトウェア プロジェクト管理へのアプローチ方法についてインタビューしました。 これが私たちが学んだことです。

クライアントに適したプロジェクト管理モデルを選択する際に、どのような要因に依存していますか?

アレクサンダー: プロジェクト管理のさまざまなアプローチを選択する背景には、多くの要因があります。 最も重要なものは、プロジェクトの範囲、予算、および市場投入までの時間です。

ゲームアプリのように、エンドユーザーに継続的に価値を生み出すために定期的に更新する必要がある製品に取り組んでいる場合、スクラムまたはスクラムのようなアプローチを当然選択します。

一方、政府機関から委託されたソフトウェア ソリューションに取り組んでいる場合 (通常、予算が固定されていることを意味します)、必要な予測可能性を確保するためにウォーターフォールのようなアプローチを選択します。 ただし、開発フェーズを小さなイテレーションに分割することは珍しくありません。 そのため、ウォーターフォールの予測可能性とアジャイルの継続的な改善とデリバリーのスピードの恩恵を受けることができるハイブリッド アプローチに頼ることがよくあります。

プロジェクト管理方法論の選択に影響を与える他の要因はありますか?

アレクサンダー: わかりました。 将来のソリューションが使用されるセクター、認証の必要性、プロセスに関与するクライアントの意欲、および他の多くの要因がプロジェクトにも影響します。

たとえば、ヘルスケア ソリューションの開発では、ウォーターフォールを選択するのが一般的です。 米国では、たとえば新しいヘルスケア機器を市場に出す前に、FDA の承認を得る必要があります。 そして、それには膨大な文書化が必要であり、アジャイルに従うことを保証することは不可能です。

プロジェクト マネージャーとしてのあなたの役割には、具体的にどのようなものがありますか? クライアントのプロジェクトを管理する上での主な目的は何ですか?

アレクサンダー: 私は、プロジェクト マネージャーとしての自分の役割を 2 つの観点から見ています。

1 つ目は、プロジェクトを管理することはリスクを管理することです。 ソフトウェア開発プロジェクトは、本質的に欠陥のある要件から、不適切な調達、変化するテクノロジー環境など、多くのリスクにさらされがちです。 この点でのプロジェクト マネージャーの主な目標は、プロジェクトに対するリスクの影響を最小限に抑え、ソフトウェアが正常に配信される可能性を最大限に高めることです。

2 番目の視点は、プロジェクトの管理は、開発、テスト、展開などの多くのプロジェクト サブシステムを調和させることを可能にする一種のインテグレーターになりつつあるということです。 PM の主な目標は、プロジェクト内のすべてのプロセスを調整して、リスクを減らし、リソースを最大限に活用することです。

プロジェクト管理への選択されたアプローチが、製品の成功を確実にする決定的な要因であることが判明したプロジェクトを思い出すことができますか?

アレクサンダー: 私たちはクライアント向けのモバイル アプリケーションを開発していましたが、スクラムでプロジェクトを開始しました。 アプリの最初のバージョンをリリースし、最初の製品メトリクスを取得した後、Kanban に切り替えることにしました。

最初のユーザーを維持するために、定期的に新機能を提供し続ける必要がありましたが、2 週間のスプリントは不要になりました。 Kanban により、スプリントの長さを新機能の複雑さに適応させることができ、平均スプリントは 3 ～ 4 週間でした。そのため、開発チームに余分なプレッシャーをかけることなく、デリバリーのペースを維持することができました。 その結果、クライアントは新しいユーザーを維持し、引き付けることができました。

アジャイル チームは自己管理できる立場にあるため、プロジェクトは専任のプロジェクト マネージャーがいなくても完了できると考えがちです。 そうですか？

アレクサンダー: 専任の PM がいない場合、1 人の責任はすべてのチーム メンバーに分散する必要があります。 バックログの優先順位付け、リソースの調達、報告、およびその他の重要な管理タスクの実行には、まだ時間を割く必要があります。 しかし、PM が不在の場合、これらのタスクは専門知識を持たない人に委任されます。 それは人材の活用を最大化するのに役立ちません。

PM なしのアプローチは、3 ～ 4 人の小規模なチームではうまくいくかもしれませんが、この数が大きくなると、専任のプロジェクト マネージャーを持つことが不可欠になります。

ソフトウェア開発プロジェクトの管理に関してまだ答えのない質問がある場合、またはプロジェクトを導く責任を経験豊富なパートナーに引き渡す意思がある場合は、ITRex にお問い合わせください。

2022 年 10 月 24 日に https://itrexgroup.com で最初に公開されました。