前へ

次へ

プロジェクト計画を作成する

完了

プロジェクト計画を作成し、適切なリソース (時間、人材、資金) を確保して、一貫したアプローチに従って、作成するアプリの優れた品質を確保します。

自分とプロジェクト チームが達成しようとすることの明確な目標を設定し、プロジェクト チームのメンバーが同じ目標を共有することが重要です。 目標を書き留めて、アプリで達成すべきことを明確化することをお勧めします。 作成する必要がある機能、優先すべき機能に、常に注力できるようにします。 詳細については、機能と要求の優先順位付けを参照してください。

目標が野心的な場合には、プロジェクトの増分リリースへの分割を検討することをお勧めします。 増分リリースの方法論については、このモジュールの後半のセクションで説明します。

プロジェクトのスコープを定義する

必ずプロジェクトのスコープを定義し、プロジェクトで何を達成すべきかを明確化します。 プロジェクトの完了要件を定義するロードマップを明確化し、プロジェクトの対象外のもの (たとえば次のバージョンで取り組むもの) を明確にします。 プロジェクトのスコープに従って、アプリの作成時に含める機能と含めない機能が決まります。

プロジェクトのスコープを定義するには、次の制約を考慮する必要があります。

• 時間 - プロジェクトの目標を達成すべき期限を設定します。 期限は、小規模なプロジェクトでは数週間の場合もあり、大規模なプロジェクトでは数か月の場合もあります。

• 人材 - プロジェクトに投入できる人材の数を決定します。

• 予算 - 自分や同僚の時間コストを考慮する必要がある場合、または外注する必要がある場合は、予算を設定する必要があります。

• 実現可能性 - 実現のための制約がないかどうか確認します。たとえば、必要な専門知識の有無、必要なデータへのアクセス、組織が対応可能な変更の量などを確認します。

また、機能をまとまった形で提供することを検討する必要があります。 アプリのいくつかの機能が中途半端な状態では、役立ちません。 各コンポーネントがエンドツーエンドに機能する形で提供されるように計画します。 アプリにすべての新機能が備わらない場合でも、ユーザーにとって意味のあるものを提供します。 プロジェクト計画では、各フェーズで提供するものを明確化します。

推奨されるコンテンツ

詳細については、次の記事をご覧ください。

• 機能リクエストの優先順位付け

• プロジェクト チーム メンバーの特定

• プロジェクトのタスクと所有者の一覧作成

• プロジェクトのスケジュールの定義

• リスクの特定

• 経営陣からの支援と後援を得る

例: ダイビング ショップ サービス部門のソリューション

次の例では、ダイビング ショップのサービス部門でのソリューション開発を支援します。ここでは、プロジェクト計画を実行し、2 つのリリースを完了します。ソリューションのリリース 1 の追加の目標を設定します。プロジェクトのスコープを定義し、リスクを特定します。

プロジェクト計画

ソリューション全体のビジネス目標を検討した結果、それらを複数のリリースに分割して、段階的に価値を提供するようにしました。

リリース 1

ソリューションのリリース 1 の目標は次のとおりです。

• ソリューションの提供時には、デジタル システムを使ってすべてのサービス要求を作成できるようになります。

• ソリューションの提供開始から 2 週間以内に、サービス チームは毎日平均 16 件のサービス注文を完了できるようになる必要があります。

リリース 2

ソリューションのリリース 2 の目標は次のとおりです。

• すべての顧客が、システム内で製品を登録できるようになる必要があります。

• 年末までに、部門マネージャーが、週次サービス レポートにアクセスできるようになります。週次サービス レポートには、システム内の最新のすべてのサービス注文の情報が含まれます。

• 顧客は、その商品の修理のリマインダーを受け取ります。 これらのリマインダーは、商品の前年のサービス完了から 1 年が経過する日の 30 日前に毎年送信されます。

ソリューションのリリース 1 の追加の目標

ソリューションのリリース 1 の追加の目標は次のとおりです。

• ユーザーに必要なトレーニングは最小限でなければなりません。使いやすさが非常に重要です。

• ショップの店長が、サービス データを利用して、サービス顧客を対象としたマーケティング キャンペーンや販売促進を作成できるようにします。

プロジェクト スコープ

ビジネス プロセスを確認すると、4 つの主なタスクに分かれていることがわかります。

1. サービス注文を作成します。

2. サービス注文を承認します (社内で行うか、またはベンダーに外注します)。

3. サービス注文を完了します。

4. 顧客に連絡し、受け渡しをスケジュールします。

リスクを特定する

経費報告書プロジェクトに、次の表を作成しました。

リスク	リスク レベル	リスク低減の計画
書類の履歴が不十分なため、古いサービス注文のデータを安心してシステムに移動できません。	重大	請求書データを確認して、サービス注文の完了を確認します。
外部ユーザーがアクセスしてデータ入力を行う場合には、顧客と商品の関連付けでミスが発生したり、サービスや販売の機会を逃すことにつながったりする可能性があります	重大	営業チームが関与して、顧客による購入時やサービスのチェックイン時に、システムに正しい情報が入力されるようにします。

続行