目次

はじめに

この本の目的
免責事項

第1章 見積もりに必要なもの(要件定義)

1.1 制作の目的
1.2 納品物
1.3 制作物の受け渡し方法
1.4 制作物要件
1.5 インフラ要件
1.6 技術要件

第2章 タスク見積もり

2.1 タスクとは?
2.2 タスクの時間見積もり
2.3 タスクを完了したあとに

第3章 若手エンジニアのための作業時間見積もり入門

3.1 はじめに
3.2 作業開始前~依頼内容の把握および確認~
3.3 作業中~作業時間の把握~
3.4 作業中から作業完了時~依頼作業状況の報告~

第4章 2点見積もりとふりかえりのススメ

4.1 2点見積もりとは?
4.2 2点見積もりの詳細
4.3 事例で見る2点見積もりの利点
4.4 2点見積もりの欠点
4.5 ふりかえりのススメ
4.6 見積もり内容と実績を記録する
4.7 実績記録における工夫の例
4.8 ふりかえりのやりかた
4.9 定期的にふりかえる
4.10 事例
4.11 おわりに

第5章 アジャイルと見積もり

5.1 技術的スパイク
5.2 バッファ
5.3 不確実性のコーン
5.4 イテレーション
5.5 ベロシティを使った見積もり
5.6 アジャイルな見積もりとふりかえり

第6章 安全マージン

6.1 はじめに
6.2 安全マージンとは
6.3 安全マージンと納期
6.4 まとめ

第7章 いわゆる相見積とRFPを比較する

7.1 RFPという手法
7.2 RFPと相見積の比較
7.3 RFPにおける提案・見積の考え方
7.4 RFPの欠点
7.5 RFPによる提案・見積の取得に向かない組織とは
7.6 まとめ

第8章 見積もり依頼の基本(小規模Projectを発注する編)

8.1 はじめに
8.2 見積依頼仕様書を作る
8.3 打ち合わせ
8.4 発注仕様書を作る
8.5 発注
8.6 納品・検収
8.7 注意事項
8.8 最後に

第9章 フリーランス(受注側)にとっての見積もり

9.1 フリーランスと会社員
9.2 自分の報酬の見積もり
9.3 実績作りというエサ
9.4 保険をかける

第10章 守備範囲外の開発の見積もり

10.1 よく知らない開発の工数見積もりを任された時には?
10.2 過去の開発でのライン数を推定し、見積もりの根拠にする

第11章 スクラムとチームと統計的見積り

11.1 見積りが苦手!
11.2 スクラムとチーム
11.3 スクラムの見積り
11.4 統計的見積り
11.5 付録: 参考文献
11.6 謝辞

第12章 見積もる前に作業を終わらせろ

12.1 技術調査の見積もりの難しさ
12.2 作業の確実性への「見積もり」
12.3 ソロプレイの集合体における見積もりの意味
12.4 見積もる前に作業を終わらせる
12.5 技術同人誌を書こう

第13章 暖かみのある見積もりをする方法

13.1 はじめに
13.2 準備編:「隣のあの人は何の業務をしているの?」
13.3 説明編:見積もりの妥当性を誰にでもわかるように示す
13.4 弁明編:見積もりから外れるときは必ず説明する
13.5 まとめ

第14章 納期と信頼

14.1 免責事項
14.2 序
14.3 破
14.4 急
14.5 まとめ

第15章 同人誌を作って見積もり体験

15.1 技術同人誌とは?
15.2 技術同人誌作成・頒布における見積もり
15.3 同人誌作成のスケジュールと工数
15.4 同人誌の収支見積
15.5 最後に

第16章 過小見積もりで炎上するプロジェクトから得られた学びと実践

16.1 概要:過⼩⾒積もりで炎上するプロジェクト
16.2 どこまで仕様を削減することができるのか?
16.3 見積もりの正確さは設計力で決まる
16.4 設計を発表しながら見積もりをするプランニングポーカー
16.5 2点見積もり法
16.6 見積もりその後のプロジェクト進行
16.7 まとめ:俺たちの戦いはこれからだ

第17章 フリーランスチームリーダーとしての見積もり失敗談

17.1 失敗したプロジェクトの帰結
17.2 私はどうすればよかったのか
17.3 失敗しないチームビジネスの例

第18章 工数見積もりアンチパターン

18.1 はじめに
18.2 アンチパターン1: リーダーの見積もりを使用する
18.3 アンチパターン2: 見積もった結果を人数で割る
18.4 アンチパターン3: 一度決めた見積もりをそのまま使い続ける
18.5 どうすれば見積もりの精度が高くなるのか?
18.6 参考文献

第19章 コンシューマーゲームの見積もり(いにしえの記憶より)

19.1 遅れが常態化する原因
19.2 遅れを取り返す行動
19.3 企画者の行動:見積もりを守る行動
19.4 企画者の行動:見積もりを守らない行動
19.5 遅れを取り返すエンジニアの行動
19.6 まとめ

第20章 見積もりきれぬ所要時間

20.1 移行の概要
20.2 作業の概要
20.3 見積もりのポイント
20.4 見積もりの落とし穴
20.5 まとめ

第21章 開発時情報が得られないケースにおいての後付けでの規模見積りについて

21.1 はじめに
21.2 そもそものソフトウェア開発コストについて
21.3 平均的な技術者のソフトウェアに関する生産性について
21.4 こういう方式で工数を算出されると困るケースにおいての抜本対策について
21.5 まとめ

第22章 建設業界の見積もり

22.1 建設業界の見積もりとは
22.2 見積の方法
22.3 見積に必要な情報
22.4 見積に関する主な法律
22.5 見積もりの内容
22.6 最後に

付録A フリーランスに必要な嗅覚

A.1 たとえば「これ簡単でしょ?」は危険サイン
A.2 見積もりは決して無料ではない

付録B 私の見積もり履歴書

B.1 私の見積もり履歴書@湊川あい@llminatoll
B.2 私の見積もり履歴書@底辺亭底辺@zeniket
B.3 私の見積もり履歴書@MzRyuKa
B.4 私の見積もり履歴書@ねむ(@nemu1986)
B.5 私の見積もり履歴書@VTRyo(3s_hv)
B.6 私の見積もり履歴書@hekitter

あとがき

はじめに

この本の目的

 この本を手にとっていただき、ありがとうございます。

 この本は、見積もりに関する様々な知見をまとめた本となっています。見積もりと一言にいっても、案件規模、立場(例えば受注側か発注側か)、案件の形態等によって全く違う形をとるでしょう。あるいは会社によっても、慣例等、違いがあり、普遍的かつ網羅的に述べることが困難であることは承知しています。

 しかし、だからこそ、他の人の事例や案件・立場による差などは見えづらい面もあります。そこで、前半には見積もりの基本を踏まえるための記事を配置しました。見積もりの手順、関連する書式とそこに盛り込むべき内容、工数や費用の見積もりの基本的なところなどについて扱っています。

 したがって、例えば新入社員が「見積もりってどうすればいいんですか?」「見積書をもらったんですがこのあとどうすれば?」「工数ってどうやってみつもったらいいんですか?」という質問をしてきたとします。そのときに、「とりあえずこの本の前半を読んで」といえるような本になるといいな、と考えています。

 またこの本の後半は、本プロジェクトに参加していただいたみなさんの体験談を(出せる範囲でぼかしつつ)集めることを主題としました。自分が行った見積りのどういう点が甘かったかや、「こんな案件があったら逃げろ」など、読み応えのある記事になっているかとおもいます。

 見積もりの基本を押さえつつ、アンチパターンとして有効活用していただけますと幸いです。

 さて、今回の企画にご参加いただきました著者の皆様、本当にありがとうございます。多数のご参加をいただきましたおかげで、内容的にも物理的にも厚い本ができました。

 また、湊川さんには、素敵な表紙をいただきました。お忙しい中本当にありがとうございます。そして表紙のみならず、巻末コラム内にコメントも頂いております。

 この本が、「見積り」という難敵に苦しめられているエンジニアの皆様のお役に立てることを祈っております。

2020年11月

編集長 親方@親方Project 拝

免責事項

 ・本書の内容は、情報提供のみを目的としております。著者一同、正確性には留意しておりますが、正確性を保証するものではありません。この本の記載内容に基づく一切の結果について、著者、編集者とも一切の責任を負いません。

 ・会社名、商品名については、一般に各社の登録商標です。TM表記等については記載しておりません。また、特定の会社、製品、案件について、不当に貶める意図はありません。

 ・本書の一部あるいは全部について、無断での複写・複製はお断りします。

第1章 見積もりに必要なもの(要件定義)

オーニシ@onishi_feuer

 一般的に、見積もりといえば「要件定義→工数見積もり→費用見積もり」という流れになります。要件定義で受発注内容を明確にし、それに基づいて工数を見積もり、制作にかかる人員と時間を含めた費用を見積もり、受注金額を算出します。この章では、その流れの最初の部分である要件定義について、具体的に何をどう定義すればいいのかを解説します。

1.1 制作の目的

 要件定義で最初すべきことは制作目的を明確にすることです。自社のWebサイトを作るとして、その目的はなんでしょうか?商品を売りたいのか、会社の宣伝をしたいのか、自社サービスなど他のページに誘導したいのかなど、様々な目的があるでしょう。また、ツールを制作するなら、同様にそのツールによって得たいご利益をはっきりさせる必要があります。業務改善ツール、社内コミュニケーションの円滑化や事務作業の削減といった目的が考えられます。

 請負の場合は受注段階で自然と目的が明確になることが多いかと思いますが、はっきりとわからない場合は発注元に制作目的をヒアリングしましょう。

 たとえばWebサイトひとつとっても、通販用のECサイトと会社の宣伝用サイトでは目的がまったく異なるため後述する要件が変わってきますし、Web記事を書くにしても商品を売るためのキラーページとブログのファンを作るためのページ、キラーページに誘導するためのページではやはり目的が異なります。後述する制作物や技術要件は、この目的に沿って定義していくため、制作目的はできる限りはっきりさせておきましょう。

1.2 納品物

 次に納品物を明確にします。

 たとえばWebサイト制作なら

 ・サイトデータ一式

 ・管理画面へのログインパスワード

 ・更新

 ・マニュアル(PDF)

 などが考えられますし、

 Webサイトのデザイン制作なら

 ・TOPページ

 ・カテゴリーページ

 ・個別記事ページ

 ・お問い合わせページ

 ・各ページのソースコード

 ・スタイルシート

 などが考えられます。

 ライターなら

 ・〇〇の記事

 ・××の記事

 ・△△の記事

 イラストレーターなら

 ・~の絵1

 ・~の絵2

 ・~の絵3

 といった具合です。

 こうしてリストアップすることで具体的な納品物がはっきりするとともに、把握ミスを防ぐことができます。

1.3 制作物の受け渡し方法

 受け渡し方法も決めておきましょう。Web制作の場合制作物はデータですが、納品方法はいくつか考えられます。

 ・クライアントのサーバーに直接アップロードして納品

 ・クラウド上にアップロードしてクライアントにダウンロードしてもらうことで納品

 ・CDやUSBメモリなどに保存して手渡しで納品

 クライアントの手に届くことが第一ですが、パスワードなど秘匿性の高いものは外部に漏れないよう扱いに注意しましょう。

1.4 制作物要件

 制作物の詳細な要件を定義します。これにはターゲットユーザーの定義、デザイン、機能、セキュリティーなどが含まれます。たとえば同人誌の表紙画像を作成するという案件があったとして、「Webサイトの作り方に関する同人誌の表紙画像を作る」だけでは要件が曖昧です。そこでクライアントとの打合せによって詳細な要件を具体化する必要があります。

 ターゲットユーザーをまったく知識のない初心者に設定するなら、デザインも初心者にとっつきやすいものにする必要があるでしょう。となると、サーバーやドメイン、ソースコードといった小難しいものを描くよりも、デスクと椅子、そしてパソコン画面にWebサイトのトップページが表示されているようなイラストの方が良さそうです。さらにターゲットユーザーが大学生や20代の会社員、40代の主婦といったように明確になっているのなら、ターゲットユーザーをイメージしたキャラクターを描くという方法もあります。

 色づかいも決めておいた方がいいでしょう。ターゲットが女子大生なら赤や青といった原色よりも桜色や水色、薄黄色など可愛いパステルカラーの方が受けがいいでしょうし、20代男性会社員がターゲットなら黒や青、緑など明確な色が好まれる傾向があるようです。1

 タイトル文字の位置や、特に目立たせたい言葉についても定義しておきましょう。たとえば「女子大生のためのWebサイト制作入門」というタイトルであれば、目立たせたい言葉は「女子大生」「Webサイト」「入門」です。複数ある場合は優先順位も付けておきましょう。それを元に、目立たせたい言葉だけ文字サイズを大きくしたり、太字にしたり、色を変えたりといったデザインを決定します。

 画像を納品する場合はサイズとファイル形式は必ず決めておく必要があります。単純にサイズが大きい分には問題ありませんが、元の画像が小さい場合は拡大すると画質が荒くなりますし、縦横比が異なる場合は画像をトリミングする必要が出てきます。また、ファイル形式は変更できることもありますが不都合が生じることもあります。

 これらの要件を定義することで、次のような具体的な制作物要件ができあがります。

 ・ターゲットユーザーは女子大生のWebサイト制作初心者

 ・女子大生のキャラクターとパソコン画面にWebサイトのトップページが表示されているイラスト

 ・桃色と薄黄色を基調とした色合い

 ・タイトルは表紙上部に配置

 ・タイトル文字のうち「女子大生」の文字サイズをもっとも大きくする

 ・タイトル文字のうち「入門」の文字サイズを2番目に大きくする

 ・タイトル文字のうち「Webサイト」の文字サイズを3番目に大きくする

 ・画像サイズは1748px×2480px

 ・ファイル形式はPNG(.png)

 最初に比べ、かなり具体的になりました。このように、要件をしっかりと定義してから制作に取り掛かればクライアントとの齟齬が生じづらいですし、工数も見積もりやすくなります。

 もちろん1回の打ち合わせでこれらを全て確定させる必要はありません。プロの漫画家さんが時短のために背景を外注するような場合はともかく、クライアントは基本的にその業務ができないから仕事として注文しているため、制作のプロではないことがほとんどです。「結果」としてこうしたい、という要望は伝えられても、そのための「手段」がわからない場合もあります。上記の例では「タイトル文字のうち『女子大生』という言葉を目立たせたい」という要望はあっても、そのための手段として文字を大きくしたり、色を変えたり、枠線で囲ったりといった手段までは思い当たらなかったり、思い当たってもどれを選べば良いデザインになるのかまでは判断できなかったりします。

 そういった場合は「目立たせる」ことだけを要件とし、手段はこちらに任せてもらうか、複数のデザインパターンを用意してクライアントに選んでもらうか決めておくと良いでしょう。少ない工数で例を提示できる場合は、2回目の打ち合わせまでにサンプルを用意するという手もあります。前述の例でいえば表紙のワイヤーフレームとラフ画を用意するといった具合です。

 Webサイトのように複雑で定義するものが多い場合は、デザイン要件とシステム要件に分けてそれぞれ定義することもあります。

1.5 インフラ要件

 WebサイトやWebアプリケーションのように納品後稼働させ続けることが前提のものに関しては、インフラ要件を定義しておきます。インフラとは、サーバーやデータセンター、ドメイン名やSSL証明書など納品物の基盤にあたる部分です。たとえば、Webサイトをレンタルサーバーで運用するにしてもレンタルサーバー業者はたくさんありますし、それぞれ月額費用や稼働率、管理画面に用意されている機能などが異なります。

1.6 技術要件

 開発言語やプラットフォーム、オープンソースソフトウェアなど制作にあたって必要な技術要件を定義します。たとえばWebサイトを作るといっても、WordPressで作るのか、Jimdoで作るのかによって必要な技術は変わってきますし、ECサイトを作るにしても楽天市場やYahoo!ショッピングなどのモール、オープンソースのEC-CUBEなどさまざまな選択肢があります。これらの選択肢の中からクライアントの要望を満たし、かつこちらの負担が少ないものを選びます。

 たとえば、私はWordPressでのサイト制作経験が多数あり、現在も自分のサイトを運営しているため、クライアントの要望が満たせるのであればWordPressを使うのがもっとも負担が少ないです。制作だけでなくその後の保守管理まで請け負うのであれば、なおさら仕様がわかっているものの方が負担は少なくなります。ただし、クライアントがサーバー代やドメイン代などのランニングコストをかけたくない場合は、無料で使えるものを提案する必要があります。

 これは営業としてのテクニックになるのですが、こちらの技術的負担が大きく、提示された予算が割に合わない場合はクライアントの要望を変えられないか交渉してみるという手もあります。クライアントの要望が「ECサイトをEC-CUBEで作りたい」というものだったとして、こちらにEC-CUBEが分かる人がいなければEC-CUBEを学習して制作するか断るかの2択で考えてしまいがちですが、クライアントの要望を整理してみると必ずしもEC-CUBEを使う必要性はない場合があります。これをクライアントに説明し、納得してもらえれば無理に慣れないソフトを使わずとも案件を請け負えます。しっかりと要件定義ができればこういった交渉の糸口ともなりえますのでクライアントが何を求めているのか、何を作ればいいのかを明確にすることは重要です。もっとも実際の現場では技術職と営業職が別れていることも多く、こういった情報を正確に伝達することが難しいのですが。

1. 筆者はカラーコーディネーターではないため色については例とお考え下さい。

試し読みはここまでです。
この続きは、製品版でお楽しみください。