こんにちは、Pentagonでアプリ開発している難波です。
この記事では、デザイナーとエンジニアの皆さんに向けて、プロジェクト成功率向上のための方法についてお話しします。この記事を通じて、見積もりの精度向上とプロジェクト憲章の重要性について理解し、プロジェクトの成功率を高めましょう。
【こんな人に読んで欲しい】
- プロジェクト管理に興味があるデザイナー、エンジニア
- 転職でステップアップを考えているデザイナー、エンジニア
【この記事を読むメリット】
- 見積もりの精度を高めることで、納得感のある費用を導出できます
- プロジェクト憲章の明確にすることで、開発プロセスの実行性が高まります
- 品質向上のための具体的な手法がわかります
【結論】
見積もりの精度向上とプロジェクト憲章の明確化は、プロジェクトの品質向上に不可欠です。これらを適切に扱うことで、プロジェクトの成功に貢献できます。デザインスキルや開発スキルの向上に加え、ビジネススキルの向上も目指しましょう！
見積もり精度向上
クライアントから開発会社への発注までのプロセスは以下の通りです。
- 問い合わせ：クライアントから開発会社に対する開発案件の問い合わせ
- 商談 ：クライアントと開発会社との開発案件についての認識合わせ
- 見積もり ：商談の結果をもとに開発会社が見積もりを作成
- 発注 ：見積もりをもとにクライアントが開発会社を選定
見積もりの際には、クライアントに納得感や魅力を提供する見積もりが求められます。このため、要件に基づいて画面や機能を整理し、次の要素を検討します。
- 審査通過要素
- 工数変動要素
- 不明点QA
- 開発優先度
各要素を個別に説明します。
審査通過要素
iOS/Androidアプリであれば、審査通過に必要な要素を検討します。
工数変動要素
画面単位または機能単位にて、工数が大きく変動する要素を押さえます。
- API結合の本数
単一の画面や機能におけるAPI結合本数が多くなるほど、表示やロジックの難易度が高くなります。見積もり時点ですべてを洗い出すことは難しいため、主要なデータを送受信するAPIが見える化できると良いでしょう。 - 高機能の難易度、影響範囲
リアルタイム性が求められる機能や、アプリの様々な箇所に影響して仕様/設計/結合テストにかかる工数が多くなる機能、などがあれば洗い出しましょう。 - 技術調査の難易度
自社に知見がない技術であれば調査工数が必要となります。 - 主要機能以外の機能
EmptyState、エラー系、バリデーションなど、主要機能以外で工数に大きく影響がある要素を洗い出しましょう。
不明点QA
開発の見積もりを行う上では、技術的な点だけではなく、仕様観点での工数増大リスクもあります。次のような不明点について、見積もり時にQAとして情報を明らかにすることで、工数過不足のリスクを下げることができます。
- 機能要件から仕様が想像できないもの
- 機能間での仕様に整合がとれないもの
- クライアントのビジネスとしてデメリットを抱えた要件になっているもの
- など
開発優先度
Pentagonでは、新規アプリ開発の手法としてMVP（Minimum Viable Product：実用最小限の製品）を推奨しています。MVPのスコープに含める機能要件かどうかの判断基準として、開発優先度を設定しています。開発優先度の高いコア機能のみを対象としたMVPでの開発計画とすることで、初期費用を抑えたリリースが可能となります。また、リリース後に得られる利用者のフィードバックや、サービスの利用状況を確認することで、アプリにとって本当に必要な機能を把握することが可能となります。
これらの要素を検討することで、見積もりの精度を向上させることができます。ただし、時間をかけすぎないように注意し、開発コストへの影響を考慮しましょう。
プロジェクト憲章
Pentagonでは、プロジェクト憲章を作成してプロジェクトの方向性を関係者と共有しています。プロジェクト憲章には以下の項目が含まれます。
- プロジェクト名
- プロジェクトの目的
- プロジェクトスコープ
- ビジネス要件
- 機能要件
- 非機能要件
- 契約
- 納期
- 予算
- リスク
- プロジェクト成功条件
- プロジェクト中止条件
- プロジェクト体制
各項目の概要を説明します。
プロジェクト名
プロジェクトを識別するための名称を定義します。第三者が見た時に理解しやすい名前をつけましょう。
例）超速恋愛マッチングアプリ開発
プロジェクトの目的
プロジェクトを通じて何を達成するのかを定義します。
例）既存のサービスをスマホアプリ化し、利便性と信頼性を高めること。
プロジェクトスコープ
プロジェクトで行うこと、行わないことを明記します。
例）
- スコープ内:コア機能開発
- スコープ外:便利機能開発(次期開発以降にて計画)
ビジネス要件
クライアントが目指すビジネス上の期待値を定義します。
例）
- 競合他社との差別化のためのデザイン充実
機能要件
ビジネス要件達成に必要な機能要件を定義し、概要を記載します。
例）
- LGBTQを考慮したアカウント情報登録
- どこよりも早い恋愛マッチングを実現するための機能
非機能要件
ビジネス要件達成に必要な非機能要件を定義して概要を記載します。セキュリティ、性能、デザインといった要素が該当します。非機能要件の要素ごとにレベルを定義しておき、クライアントにレベルを選択いただくのがわかりやすいでしょう。
契約
契約の種類、概要を定義します。
納期
成果物の納期を定義します。多段階契約であれば、契約ごとの納期を定義します。
予算
開発予算を定義します。多段階契約であれば、契約ごとの予算を定義します。
リスク
プロジェクトの主要リスクと、その対策を記載します。
プロジェクト成功条件
プロジェクトにて達成すべき条件を記載します。
例）
・アプリのリリース後、3ヶ月以内に100万ダウンロード達成
・アプリのリリース後、1年以内にマッチングが月1000件成立
プロジェクト中止条件
プロジェクトを中止すべき条件を記載します。
例）
・要件が大幅に変更され、開発費用または開発期間が2倍以上になる場合（仕切り直し）
・入金ができない状況になった場合
プロジェクト体制
ステークホルダーが明らかになるよう、体制を記載します。
これらのプロジェクト憲章項目を洗い出すことで、プロジェクトの目標や進行ルールが明確になり、混乱や誤解を避けることができます。また、誰もが同じルールに従って行動するため、主観的な意見や個人の好みに左右されない客観的な判断基準が確立されます。したがって、プロジェクトを円滑に進めることができます。
まとめ
プロジェクトの成功率は見積もり精度の向上と明確なプロジェクト憲章の作成によって向上します。
クライアントや開発を担当するデザイナーやエンジニアにとって、お互いにリスクを減らした状態で開発に望めるよう、本記事で紹介した手法を取り入れてみてください！
