次の方法で共有

プロジェクトの開始

  • [アーティクル]

プロジェクトの開始という最初の段階では、プロジェクトの基本のリソースを割り当てます。

計画会議

プロジェクトの早い段階で、何人かの利害関係者と内容の担当者を集めてプロジェクトについて話し合い、製品計画をまとめます。 プロジェクトの性質と複雑さ、および製品成果物に基づき、参加する利害関係者を選択します。

プロジェクトの規模とその複雑さによっては、この会議に数日から数週間かかる場合もあります。

反復開発

リスク管理における重要な手法の 1 つは、プロジェクトを通常は 4 ～ 6 週間のイテレーションで計画することです。 イテレーション計画は、プロジェクト チームが開発およびテストする機能の一覧です。 各機能は、製品を使用してユーザーが実行できるタスクまたは改善されたタスクを示します。 各イテレーションの終了時に、計画された機能のデモを行います。 イテレーションによっては終了時に、一部のユーザーによるトライアルのために部分的に完成した製品をリリースする場合もあります。

それらのデモおよびトライアルから得られたフィードバックに基づいて、計画の見直しを行います。

製品計画は、主なユーザー シナリオとシステムのメイン コンポーネントを部分的にでも早い段階で試せるように調整します。

ほとんどのプロジェクトにおける最も重大なリスクの 1 つは、要件を誤って解釈してしまうことです。 要件は、開発チームだけでなく、エンド ユーザーおよび利害関係者にもよく理解されていないことがあります。 新しいシステムの導入によりビジネス アクティビティにどのような影響があるかを予測することが困難な場合があるためです。

さらに、ビジネス上のコンテキストがプロジェクト期間中に変更される場合もあり、それによって製品要件も変わります。

反復的なプロセスを使用すれば、製品のデモで見つかった要件の調整にプロジェクトの終了前に対応できるようになり、大幅な修正作業が発生することはありません。

もう 1 つの重大なリスクは、開発コストが正確に見積もられないことです。 新しい領域で作業する開発者にとっては、プラットフォームに不慣れであることも多く、プロジェクトの前に開発コストを正確に見積もることが困難である場合があります。 場合によっては、特定の実装方法が十分に機能するかどうかを判断することも難しいことがあります。 このような場合でも、各イテレーションの終了時に計画を見直すことで、チームのそれまでのイテレーションの経験を活かすことができます。 このことからも、製品計画では、各主要コンポーネントの作業を一部でも早い段階で行うようにスケジュールすると効果的です。

プロジェクトがスコープ主導か日付主導かの確認

プロジェクトによっては、納品前にすべての要件が機能するようにしなければならない場合があります。 このようなプロジェクトは、ソフトウェア プロジェクトにはほとんどありません。 実際の例としては、橋の建設が挙げられます。 橋は途中まで完成していても役に立ちません。 それに対し、適切に計画されたソフトウェア プロジェクトは途中までしか完了していなくても、一部のユーザーに配置して使用することができます。 その後に、何度かのアップグレードを経て、インクリメント方式で完成させることができます。

最初に、プロジェクトが実際にスコープ主導であるかどうかを確認します。 スコープ主導である場合は、詳細な見積もりと詳細な計画が完成するのを待ってから終了日を判断する必要があり、 それ相応の犠牲を強いられます。 計画のオーバーヘッドが増加し、見積もりが不正確だった場合に備えて予備期間を設けることで納品日が遅くなり、それによって費用が増大します。 したがって、確信が持てるまで十分に確認したうえで、スコープ主導のプロジェクトであると判断するようにしてください。 これは、純然たるソフトウェア製品またはサービスの場合よりも、複雑なシステムのエンジニアリング環境の場合に該当する可能性があります。

ほとんどのソフトウェア プロジェクトは、インクリメント方式で納品できるため、日付主導のプロジェクトです。 たとえば、コンピューター ゲームを米国の休暇シーズンにリリースする場合、10 月までには準備が完了している必要があります。 10 月に発売できなければ、ハロウィンからクリスマスにかけての販売に深刻な影響が生じます。さらに、スケジュールが 2 か月ずれ込んだ場合は、販売の機会を完全に失う可能性もあります。

プロジェクト リソースの計画

プロジェクトでは、目的の日付までに納品できるようにスタッフを配置する必要があります。 リソースがどれくらい必要かについては、以前のプロジェクトの履歴データを基に判断できます。

スタッフの要件を把握できたら、プロジェクト チームの構造、リソース レベル、および地理的な分散 (該当する場合) を明確に示したプロジェクトの組織図を作成します。 スタッフの配置に関する情報はすべてプロジェクト ポータルに保存します。

ロールと責任の定義

各プロジェクトのロールと責任を定義し、プロジェクト計画で公開します。 プロジェクトに参加する各メンバーは、プロジェクトにおける自分のロールと責任を理解する必要があります。

コミュニケーション計画の定義

プロジェクトのコミュニケーション計画を定義することは重要な作業です。 コミュニケーション経路が確立されていれば、プロジェクトの調整にかかる費用を抑えることができます。 ここで重要なのは、会議の出席者、会議を開催する頻度、およびコミュニケーション経路のほか、特定の会議の通常の出席者では解決できない懸案事項のエスカレート方法を定義することです。

適切なコミュニケーション計画を定義する目的は、プロジェクトの調整のアクティビティをできるだけ円滑に行えるようにすることと、コミュニケーション不足によって無駄な作業が発生しないようにすることです。

コミュニケーション計画は、プロジェクト ポータルに公開し、必要に応じて保守作業を行います。 コミュニケーション計画は、すべてのスタッフ (特に新しいメンバー) にとって役立つツールです。 これにより、さまざまな方法で、さまざまなチーム メンバーと、さまざまな目的で適切なコミュニケーションを行うことによって、大規模なチームがどのようにして作業を進めて完了させるかを理解することができます。

利害関係者の識別

プロジェクトにおける関連するすべての利害関係者を識別します。 主要なチーム メンバーに加え、プロジェクトの正常な実装や製品の提供後の効果に関係するビジネス担当者とテクニカル担当者も含めます。 これらの利害関係者は、ソフトウェア エンジニアリング アクティビティのアップストリームの場合もダウンストリームの場合もあります。

大まかなプロジェクト計画の作成

最初のプロジェクト計画のスケッチ バージョンを作成します。これは、開発が始まったら修正できます。 このバージョンの目的は、リソースおよびタイムスケールについてのプロジェクト スポンサーとの話し合いを進めやすくすることです。 この段階では、主要な機能とその予定納品日を大まかに決めます。 詳細については、「プロジェクト計画 (CMMI)」を参照してください。

プロジェクト計画の見直し

大まかなプロジェクト計画をプロジェクト ポータルに公開します。 計画には多くの作業が含まれますが、まだ大まかな計画であり、詳細なスケジュールはほとんど決まっていません。 これは意図的なものであり、 この段階であまり詳細に決めても後で無駄になるだけです。

要件が確定していない段階では大まかな計画のみを行って、詳細については利用できる情報が増えてから決定します。 ここでは、その情報を入手するための計画を立てます。

すべての利害関係者が参加するレビュー会議の予定を立てます。 この種のアクティビティでは、直接顔を合わせて会議を行うことが常に最善の方法です。 全面的な見直しを行って反対意見も聞き出せるように、十分な時間をとるようにしてください。

プロジェクトに対するコミットメントの確認

プロジェクトの利害関係者からプロジェクト計画に対する合意が得られたら、各利害関係者にプロジェクト計画を承認するコミットメントを求めます。

コミットメントを集約し、詳細をプロジェクト ポータルに保存します。

その他のリソース

詳細については、次の Web リソースを参照してください。