理解度が低いシステムの見積もりをした話｜それでも精度の高い成果物を作りたい！

新しいプロジェクトに参画した際に、理解度が低いシステムの見積もり作業を行った事があります。しかも、そのシステムはドキュメント類が不足していて、調査も難航する様な代物だったのです。これなら新システムの見積もりをした方がまだマシ。今まで何度も見積もりはしていましたが、こんなに訳が分からない状態で見積もりするのは初めてでした。。。

ただ、こんな状態でもベストは尽くしたいなぁという思いも当然あり（迷惑をかけるのはメンバーですからね）、そのためにどの様にすれば良いかを検討・試行錯誤して見積もりを行いました。

今は開発に入っていますが、見積もりの想定通りにプロジェクトも進んでいます。こーいう経験て、その時は大変だけど、後になって考えると非常に良い経験だと思っています。今回はその振り返りの意味もこめて、見積もり作業のために実施した事などをまとめておきたいと思います。

この記事は以下の様な方を対象としています

・そもそも見積もりの仕方がよく分からない

・現場によって見積もりの仕方が異なるので、何が正しいか分からない

・理解度が低いシステムの見積もりの仕方が知りたい

システム開発の見積もりをする

この時に行った見積もりはごく一般的なもので、

というものです。

では実際に行った見積もりの流れを紹介していきます。

見積もりの前提

見積もりには以下の前提があります。

※対象システムについての見積もり案件が複数件あり、まずはその中から２つの案件を見積もる事にしました。最初は戸惑う事が多いだろうと予想したので、まずは要件を確認した上で。規模が小さそうなものから順番に。

見積もった結果

見積もりの結果（レビュー結果）を、あえて最初にお伝えしておきます。

これまでの見積もり作業の経験と、改めて書籍などで学んだ事を踏まえて、いくつかのポイントを押さえて見積もりを行う事にしました。その結果、一応見積もりレビューも一発ＯＫで通りました。

で、見積もり完了からほどなくして、開発に着手する事になり、一応想定通りに各フェーズの作業も完了しました。

今回は「工数」の試算までを中心とした見積もり作業だったため、作業のポイントを絞り込む事ができたのかもしれませんが。ただ、この経験で、「この方法で大丈夫なんだ。」という手ごたえの様なものも得ているので、自分が意識したポイントをこの後でシェアします。

見積もりのアウトプット

見積もりのアウトプットとなったのは以下になります。

「開発規模」に関するドキュメント

ユーザさんとの打ち合わせにて、およその規模感については話し合いができたので、その話し合いの結果を資料にまとめました。この時点では、非常にざっくりとした試算ですが、規模感のイメージを共有できればＯＫ（ユーザからもＯＫが出た）だと思います。

「実施作業・作業量」に関するドキュメント

開発を行う上で必要な作業や成果物を洗い出しました。

ここで、有識者に質問を行う＆過去の成果物資料を確認するなどして、フェーズ毎に必要な作業成果物を細かく確認しました。

この作業を洗い出す際、各作業にどの位の工数がかかるのかを想定しなければなりません。いわゆる見積もりの根拠をしっかりと決める必要があります。

具体的な作業量をイメージする事が難しかったため、

①成果物量を試算する

②それぞれの成果物の作成に必要な作業量を試算する

という順番で、「実施作業」と「作業量」の洗い出しを行いました。

大事なポイント「見積もり根拠」

作業量を見積もる際に大切なのが「根拠」です。

例えば、仕様書を修正するのであれば、

・修正行数で見積もるのか？

・修正ページ数で見積もるのか？

コード修正の場合、

・コードの削除はStep数に含むのか？含まないのか？

という事を予め決めておく必要があります。

仮に、見積もりのレビューをユーザさんに依頼した際に、ちょっと見積もりが大きすぎる。という話になった場合、根拠の考え方を変えれば、自動的に工数や金額も再試算する事ができます。

また、後々に見積もり内容を修正する際にも、元々の根拠が見えないと再試算する事ができません。

必ず、見積もりの根拠となる考え方を事前に確定させてから、細かい見積もりを行う様にしましょう。

フェーズ毎の「工数」に関するドキュメント

「作業内容」、「作業量」が分かったら、「工数」を試算する事になります。

この「工数」最終的なコストの直接の見積もり根拠となるもので、この工数の試算までが特に大事なポイントと言っても過言ではありません。※ユーザさんに提出する資料にはコストだけではなく、工数に関する資料も必ず含まれるはずです。

とはいえ、これまでの作業の中で、ある程度正確に作業内容と作業量が試算できているのであれば、妥当な工数を振り分けていけばＯＫです。

この時、各作業に振り分ける数字は、特別な理由が無い限り、過去のデータを基準にするのがベターです。その方が結果的に数字のぶれが少ないですし、ユーザさんへの説明もしやすいと思います。

■フェーズ毎の「工数」に関するドキュメント

フェーズ	アウトプット	備考
外部設計	工数・修正する仕様書の対象箇所一覧	仕様書の修正イメージサンプルを添付
詳細設計	工数	システム概要資料添付
コーディング	工数・想定step数	ソースの解析資料添付
単体テスト	工数	–
結合テスト	工数・想定ケース数	テストケースのサンプルを添付
システムテスト（リグレッションテスト含む）	工数・想定ケース数	–

細かい説明資料などはいくつか添付していますが、基本的には以上がアウトプットとして提出した内容になります。

見積もりで心がけた事

「見積もりが失敗するとプロジェクトは十中八九失敗する。」というのは有名な言葉です。開発が始まってから起こる小さな課題は都度解決する事もできますが、見積もりそのものの誤りは、プロジェクトの前提の誤りでもあるため、プロジェクトそのものの失敗に繋がってしまいます。

なるべく正しい見積もりを行う上で心がけた事を挙げておきます。

見積もりの前提を作成して事前に共有する

今回の開発には、大きな問題があり、確定していない仕様が存在していました。確定していない仕様はプロジェクトの失敗要因になりえます。

そのため、今回の見積もりでは仕様の前提（この部分は、この様な前提で見積もりをしますよ）という条件を明確に設定して、事前に関わっている人達に共有をしておきました。

もしも、前提となる仕様が変わった場合は「見積もりもやり直し」と伝える事で、後々で見積もりと要件のギャップを発生させない様にしました。

ユーザさんや関わっている人達とミーティングをしたり、連絡をしなければならないので、少し気疲れすると考える方もいますが、非常に大事な事だと思います。

調査の経緯を「ドキュメント」に残す

見積もりを実施する際には当然調査が必要になります。どの様な調査を実施したかはログとして残しておきましょう。調査の経緯も見積もりの前提にも大きく関わってくる箇所です。

もしも、見積もり結果の根拠などを問われた際に、どの様な経緯で見積もりを試算したのかは説明資料としても重要なになります。

今回、見積もりの調査の経緯をざっくりとまとめておきます。いざまとめてみると、わりとシンプルな事をやっていたのだと自分でも分かります。

■見積もりの前提

フェーズ	調査の経緯
外部設計	調査対象資料が多いため、改修要件よりキーワードを抜粋して、そのキーワードで対象となった設計書だけを対象に見積もりを実施した。 ※他にも対象があったとしても、この時点では見積もりの対象としない。
詳細設計	（外部設計同様に）キーワード検索で対象となった設計書だけを対象に見積もりを実施した。
コーディング	（外部設計同様に）キーワード検索で対象となったソースコードだけを対象に見積もりを実施した。
単体テスト	コーディングの見積もり（Step数）を基に自動で試算した。
結合テスト	以下の内容を基にテスト量を試算した。 ・過去に他の開発案件で実施したテストケース量 ・外部設計（一部詳細設計）の内容
システムテスト（リグレッションテスト含む）	結合テストの見積もり（ケース数）を基に自動で試算した。

今後に向けた改善点

とりあえず、実際の開発作業が見積もりの予定通りに進んではいるものの、見積もりをする時にさらに改善できる事がないかをまとめました。

見積もり根拠の「根拠」となる内容も資料に残す

根拠の「根拠」って意味が分からないと思うかもしれませんが、なぜその根拠で見積もる事にしたのか？という理由もドキュメントとして残しておくと、後々助かります。

その理由がまずい場合、第三者にレビューをしてもらった場合に指摘をもらえれば、その時点で修正する事ができるからです。

感情的な見積もりはしない事

若い頃に見積もりの研修で「見積もりに希望的観測や、感情を入れてはならない。」という言葉を学んだ事があります。まさにその通りだと思います。

見積もりはあくまで、現実的な数字を積み上げていくべきであって、感情的な見積もりはしてはいけません。今回は、テストケースを挙げる際に参考情報として、多少感覚値がありました。結果的には、見積もり通りのテスト数でＯＫだったのですが、本来はこの記事でも書いている様に根拠を明確にすべきです。仮に感覚値を採用するとしても、一度有識者に内容確認するなどの手続きを取るのが妥当だと思います。

まとめ

今回は理解度が低く、馴染みの無いシステムの見積もりに関する内容を記事にまとめました。

エンジニアの仕事をしていれば、見積もりの仕事は当然の様にあります。見積もりの時点で仕事の規模感を誤ってしまうと、当然プロジェクトの失敗に繋がってしまいます。

実際に見積もりの作業をする際の参考にしていただけたらと思います。