見積もりについて
見積もりは単に開発費と納期を提示するだけでなく、「いつまでに何をするのか？」、「どのタイミングで何を合意しておくのか？」など作業範囲をはっきりさせておくことが大切である。
見積もりはなるべく10日以内に行うのがのぞましい。
見積もりは提案依頼書（RFP）の確認から始まり、クライアントに見積もり提案するところで終わり。
クライアントが見積もりに合意した段階でプロジェクトスタートなる。
RFPの文面の各所に返答する形で提案するという簡略方法もある。
RFPの確認から見積もり提案までの手順
- 提案依頼書(RFP)の確認
- RFPを分析
- ヒアリング資料の作成
- ヒアリング
- 見積もり
見積もりのドキュメントについて
ヒアリング資料の作成
クライアントにヒアリングを行う前にヒアリング資料を作成する。
RFPの分析を元に、開発の目的、現在のシステムの状況、運用手順などを解析し、クライアントへの質問事項をまとめる。
ヒアリング資料の種類
- ヒアリングシート
- 提案書
- 運用フロー図
- アジェンダ
ヒアリングシート
ヒアリングシートの内容の例。
- クライアントが抱える現状の問題点は？
- プロジェクトの目的は？
- プロジェクトの現状の問題点、目的、本質、現状の問題点は？
- 文書資料はあるか？運用フロー図はあるか？
- 現状の業務フローは？
- システムによる業務フローは？
- どんなシステムと似ているか？システムのステレオタイプは？
- どんな機能が必要になりそうか？
- 主要画面は？
- マスタ系の画面数は？
- 集計系の画面数は？
- データ量は？（100万件級、1000万件級は注意）
- リリース後のメンテナンス担当は？
- 自動バックアップシステムは必要か？
- 負荷がかかる箇所は？
- アクセス集中が起きそうなところはあるか？
- セキュリティのリスクは？（過去にセキュリティ的な問題が生じたことがあるか）
- 提案業務の一般的仕様は？（Facebook,レコメンド機能など）
- 検討すべきリスク、現状の大きな問題点は？（実現調査が必要な箇所）
- 現状の不明点、疑問点、あいまいな箇所は？
- 開発チーム体制/対応窓口は？
- システムを利用するユーザーの種類は？
- 想定しているユーザーの人数は？（ユーザーの種類毎）
- 予算感は？（1人月あたりの予算）
- 何人月くらいの仕事量か？
- スケジュール感と納期感は？
- DBは？
- プログラミング言語は？
- フレームワークは？
- 稼働サーバーは？
- Githubを利用するか？
- 開発手法は指定されているか？（ウォーターフォール、アジャイルなど）
- カットオーバー後の体制について（フェーズ終了後の体制）
- クライアントはこちらからの提案を希望しているか？
- クライアントはシステムについて詳しそうか？
- 期間に対してやりたいことが多すぎまいか？（分割提案は必要？）
- プロジェクトの本質は？（クライアントの依頼とシステムはマッチしているか？）
- いつまでにだれが何をするか？
- マイルストーン（節目、フェーズ）は？
提案書
クライアントが提案を求めているようであれば、実現方法を考え提案できる。
システムに詳しい立場からのビジネスを中心に提案する。ビジネスを中心にした場合、電子化しないほうが良い場合もある。
ただ、あれこれと提案候補を考えると時間がなくなるので注意。
実績あるアーキテクチャに基づいたメンテナンスしやすいシステムを提案する
運用フロー図
運用を図で表したもの。
運用フロー図をもとにヒアリングを行うと以下の利点がある。
- クライアントに説明するとき便利。
- クライアントが思い描いているフローを聞き出せる。
- 運用にかかわる人を聞き出せる。
- データの流れ、状態、アクションが分かりやすくなる。
- システム化するものとしないものを見分けられる。
運用フロー図にUMLのコミュニケーション図を用いるのもいい。
アジェンダ
アジェンダとは会議で論ずる事項が書かれた予定表のような書類。
直接クライアントに会ってヒアリングを行う場合、アジェンダに沿ってヒアリングすすめる。
アジェンダにはおおまかな質問事項と時間配分を記載する。
ヒアリング前にアジェンダをクライアントに送るようにする。
次のタスク：ヒアリング
見積もり
見積もり手順の作成
- 運用フロー図をヒアリング結果を元に更新する
- 機能一覧を作成する
- PERT法で工数算出
- 作業一覧
- 開発計画
- スケジュールを作成
- 見積書を作成
- 見積書をクライアントに提示する
機能一覧を作成
- 使いやすいユーザーインターフェースにする。
- 要件を分析しながら開発する画面、機能を洗い出し、機能一覧を抽出。
- 複雑な機能の実現方法を検討する。
- 簡易的なDB設計も行う。（ER図）
- 各機能ごとにリスクを記入する。
-
経験を頼りに工数を入力する。
3種類の工数である最速工数、標準工数、最遅工数を入力するとPERT法で工数を算出できる。
最遅工数はリスクが高い機能ほど多めに設定すること。（できればリスクが小さくなるよう事前に検証したほうがよい）
工数の単位は「人月」、日数、時間などがある。
- ブレーンストリーミングで要望実現に関するアイデアを出すこともできる。
- 優先して開発する機能と後で開発する機能を分類する。
- あいまいになっている箇所の機能提案
機能一覧の例
| 作業名 | リスク | 最速工数 | 標準工数 | 最遅工数 | 説明 |
|---|
| テストA画面 | 低 | 0.5 | 1.5 | 2.5 | マスター系画面 |
| テストB画面 | 低 | 0.5 | 1.0 | 2.0 | 通常のCRUD画面 |
| テストC機能 | 高 | 1.0 | 3.0 | 10.0 | 調査が必要な機能 |
PERT法で工数算出
工数やスケジュールの算出は難しいものである。実際、やってみないとわからないからである。
工数を見積もる方法は非常に多数存在する。その中の一つにPERT法というものがある。
PERT法
機能一覧で入力した最速工数、標準工数、最遅工数を元に工数を算出する。
算出にはPERT法を用いる。
見積もり工数 = （最速工数 ＋ ４ × 標準工数 ＋ 最遅工数） ÷ ６
工数をPERT法で算出
| 作業名 | リスク | PERT法・工数 | 最速工数 | 標準工数 | 最遅工数 | 説明 |
|---|
| テストA画面 | 低 | 1.75 | 0.5 | 1.5 | 2.5 | マスター系画面 |
| テストB画面 | 低 | 0.6 | 0.2 | 0.5 | 1.5 | 通常のCRUD画面 |
| テストC機能 | 高 | 4.3 | 1.0 | 3.0 | 10.0 | 調査が必要な機能 |
作業一覧
機能一覧から作業一覧を作成。
作業一覧には作業範囲と見積もり額を入れる。
作業範囲を明確にするという大きな役割があるのでクライアントにしっかり確認してもらうようにする。
作業範囲を決める
- やりたいことはどんどん膨らんでいくため、絞り込みの作業も必要になる。
- 優先すべきことと後回しでよいもの分ける。
- 予算内でできる機能だけを提案する。
- 力のかけどころを見極める。
- コストや納期と相談しながら作業をフェーズ分けする。
作業一覧に含めることができる作業（タスク）の例
- 画面開発
- 機能開発
- 業務改善の検討作業
- 問題の調査作業
- バッチ処理の開発
- 運用しやすい体制構築
- 「〇〇の見直し」というタスク
スケジュールの作成
PERT法で工数を算出しているので後はこの工数にそってスケジュールを作成するだけ。
予備日も入れる。
見積書の作成
IT以外の業種が使用している一般的な見積書でよい。
項目は
作業一覧を参考に作成する。