ユーザーとサイト管理者の視点から積み上げ導き出す見積もり方法とは?

ユーザーとサイト管理者の視点から積み上げ導き出す見積もり方法とは?

本のまとめ

▼読んだ本は?
■システム開発のための見積りのすべてがわかる本
■佐藤 大輔さん, 畑中 貴之さん,渡邉 一夫さん
http://amzn.asia/d/awA8yZb
▼システム開発の見積もりってそもそもなに?
■システム開発を行うときの「作業量の予測」のこと
■なぜならシステム開発では人件費がほとんどのため「作業量の予測」≒「金額の予測」になるから
■見積もりを行うためには以下の順番で行う
【1】顧客が実現したいビジネス課題をヒアリング
【2】ビジネス課題を解決するために必要となる作り物を決めるのが「要件定義」
【3】要件定義には「機能要件定義」と「非機能要件定義」の2つがある
【4】ユーザーが利用する画面や、メールの通知などユーザーやサイト管理者が使う機能を決めるのが「機能要件定義」
【5】「セキュリティは厳しく」「1,000人が同時にサービスを利用する」などユーザーが直接は操作しないけど重要なことを決めるのが「非機能要件定義」
▼見積もりのときに重要な2つの契約形態って?
【1】業務委託契約
└「何人が何ヶ月作業するといくら」という人の数と、人が動く期間に基づく契約

【2】請負契約
└実際に開発を行う、全ての機能と非機能に基づく契約
└作りものに対する、完成責任を負う契約

▼見積もり金額を計算式に変えると?
■見積り金額=「工数」×「単価」+「粗利」

■工数
└人の数と、人の動く期間の合計

■単価
└動く人、ひとり辺りの金額

■粗利
└工数や単価、外注費を除いた後に残る、会社の収益

▼それぞれの人の単価っていくらぐらいにすべき?
【1】粗利は、どの産業でも「30%以上」を目標にすべき
【2】そして、ソフトウェア開発のコストはほとんどが人件費
【3】例えば、1ヶ月の給料が50万円のAさんがいる
【4】社会保障費手当などを含めると、Aさんには1ヶ月辺り役1.3倍の「65万円」がかかる
【5】その他に営業活動などを含めて、販管費が20%程度必要なため加えると「75万円」
【6】75万円から30%の粗利を目指すと、Aさんの1ヶ月の単価は結果として「107万円」くらい
▼見積もりを取っていく順番は?
【1】ユーザーやシステム管理者がシステムを利用して行うことを書き出した「ユースケース」を作る
【2】このユースケースの細かさを「粒度」と呼ぶ
【3】例えば、粒度の大きなユースケースは「会員登録ができる」などのタスクレベル
【4】粒度の大きなユースケースを、粒度の細かなユースケースに変えていく
【5】例えば、粒度の細かなユースケースは「会員情報を入力できる」「登録時に確認画面が出る」などのタスクレベル
【6】粒度を細かくした各ユースケース内のタスクに、それぞれ開発難易度や手間を書き出す
【7】それらを積み上げていくと、見積もりができあがる
【8】この積み上げ型の見積もり方法を「積算法」と呼ぶ
▼見積もりを取るときに最低限作成すべき資料は?
【1】ユースケースに基づく機能要件一覧/非機能要件一覧
└粒度を細かくした各ユースケース内のタスクを書き並べた資料
└例えば「登録済みメールアドレスでログインできる」など

【2】アーキテクチャ構成図
└WEBベースなのか、利用言語はなにか、利用するフレームワークは何かなど大枠の技術要素やインフラをまとめた資料
└例えば「AWS利用」「EC2インスタンスとRDSを2つずつ用意」など

【3】粒度の大きいフロー図(アクティビティ図)
└ユーザー、サイト管理者の動きに加え、外部システムの処理などを含めてシステムの大きな流れをまとめた資料
└例えば「1.サイト管理者が商品を登録 2.外部システムが在庫管理状況を提供 3.ユーザーが商品を選択」など

【4】マスタースケジュール
└プロジェクトの開始と終了、フェーズ単位での時間軸をまとめた資料
└見積もり時点ではスケジュールの粒度は「ログイン機能」「ユーザーメニュー機能」など機能単位
└まずは顧客要望を一旦無視して、機能単位で積み上げて作成することが大事
└自分たちだけではなく、顧客側のタスクとスケジュールも含めることが必要

【5】プロジェクト体制図
└開発会社に加え、顧客側の担当者、最終責任者、他部門を含めた体制図をつくる

▼ウォーターフォールプロジェクトのフェーズ構成って?
【1】要件定義
【2】基本設計
【3】詳細設計
【4】開発
【5】テスト
【6】リリース
▼テストにはどんな内容がある?
【1】プログラミング単位でのテスト
【2】複数のプログラムをつないで動かす機能単位のテスト
【3】複数の機能をつないでユースケースを実現するシナリオテスト
【4】ユーザーが実際に業務をイメージして作業するテスト
▼基本設計と詳細設計の違いって?
■基本設計
└例えば、ユースケース内のタスクに関して「会員情報DBを設計する」などの粒度の荒いタスクを設計する

■詳細設計
└例えば、ユースケース内のタスクに関して「会員情報画面を設計する」「会員情報入力画面を設計する」などの粒度の細かいタスクを設計する

▼見積もりやスケジュールに影響する最近の変化は?
■Seleniumのようなテストの自動化
■eclipseなどのIDE(統合開発環境)の発達
■REDMINEやBacklogなどのプロジェクト管理ツールの利用
■AWSのようなクラウド環境の利用
■JenkinsのようなCIツール、GithubやDockerを利用した開発・デプロイの自動化
▼一般的なスケジュール期間って?
■プロジェクト内の全部の投入「工数」の立方根(1/3乗)の2.4倍くらいが妥当
■例えば「投入工数=20人月の場合、スケジュールは約7ヶ月」「投入工数=50人月の場合、スケジュールは約9ヶ月」
■基本的に、根拠ないスケジュールの短縮はだめ
■研究によると、もしスケジュールを短縮する場合、もとのスケジュールの「-25%」が限界点
▼見積もり完成時のチェックポイントは?
【1】新しい要件と現行システムを比較したか?
└現状の担当者と読み合わせ、現行のシステムでできることが、できなくなっていないか確認

【2】体制図やスケジュールに顧客の役割を明示しているか?
└顧客のタスクや役割が明記されており、それぞれの会社の責任分界点が明確になっているか確認

【3】非機能要件が書き出され顧客に説明されているか?
└非機能要件の中でも、特に「パフォーマンス」「セキュリティ」「可用性(システムの稼働状況)」が明確になっているか確認

【4】開発作業以外の費目は盛り込まれているか?
└「全体のプロジェクトマネジメント費用」「インフラ費用」「ドメイン費用」「レクチャー費用」などが含まれているか確認
└プロジェクトマネジメント費用は、プロジェクト全体の「10~20%くらい」を計上することが一般的

思ったこと

どんどん複雑化していくシステム開発を行う上で、サイトユーザーやサイト管理者ができることをまとめる、ユースケースもベースとしつつ、どんな形で見積もりをまとめあげればよいかについて書かれた本でした。

ひとつのアプリケーション、ひとつのデータベースなどの簡単な構成のシステムであれば、機能に分解すること、そして非機能に分解することはさほど難しくなかったのかもしれません。

でも、アプリケーションを作るだけでもたくさんのライブラリやフレームワークが登場し、そしてAWSなどクラウド型のインフラの発展など、どんどんと急速に変化するIT業界の中では、少し前までの当たり前が、今日には非効率で非生産的な方法になっちゃうこともしばしばあります。というか、そんなんばっかりだったりします。

そんな中でも、きちんと機能や非機能に分解し、そしてアーキテクチャ構成やフロー図、体制図、スケジュールへと落とし込んでいくという基礎は全く変わんなくて、そんな地味だけど大事なことを、プロジェクトの早い段階から顧客と握ってやっていく大事さが書かれています。

もちろん見積もりについて書かれてはいるけれど、根本にあるのは、常に新しい技術に触れ、新しい技術を学び、それらを実直にきちんと積み上げて、見積もりに変えていこうぜという姿勢の話しなんだろうなと思います。

ありがとうございました!

関連する記事