Zenn
🗂

見積りは見積もる前から始まっている(書評『システム開発のための見積りのすべてがわかる本』)

2023/09/23に公開
技術書
書評
要件定義
見積
idea

概要

本の特徴

  • 簡単
  • 見積りの基本が書いてる
    • そもそも見積りとは？とか
    • FP法など従来の見積手法とか
  • 近年の開発環境の変化を考慮した記述がある
    • 第8章など
  • 具体的な事例が載っている
    • 第9章
    • FP法やUP法など従来的な見積方法について、筆者の見解に基づき近年の開発に適用する事例を載せている

アジャイルの見積りに特化しているわけでもなく、見積りの原理・原則に徹している本でもない。
基本は押さえつつ、実践的な側面から見積手法について解説している本である。

大事に思ったポイント

  • 要件定義が大事
    • 開発プロセスが変わってもやることは同じ
  • 時間が許せば複数の見積手法で見積もってみて、差異を確認し見積り精度を上げる

書評

翔泳社から出版されている『システム開発のための見積りのすべてがわかる本』を読んだ。
https://www.shoeisha.co.jp/book/detail/9784798156491

本書は2018年に初版第1刷が発行され、手元にあるのは2022年初版第3刷のものである。
著者は株式会社オープントーン代表取締役社長の佐藤大輔(第1部、第2部執筆)、
株式会社オープントーン取締役兼ITエンジニアリング事業部兼観光ビッグデータ事業部部長の畑中貴之(第3部第8章一部、第9章執筆)、
官公庁システム構築などの経験があるエンジニアの渡邉一夫(第3部第8章一部執筆)の3名となっている。
巻末のプロフィールに書かれている通り、3名ともシステム開発の経験が豊富で、
本書には彼らの経験知が散りばめられており、実践的な内容となっている。
分量は256ページとそこまで多くなく、内容もわかりやすい。初学者からベテランまで参考にできそうな本である。

第1部は見積りの基本について扱っている。
まず第1章で、そもそも見積りとは何なのかを述べ、一般的な見積りの方法として積み上げ法、
ファンクションポイント法について解説している。

第2章では積み上げ法を使用して具体的に見積りを行う手法を解説している。
見積りをする際に最低限必要な資料が記載されており、これらの資料は見積方法に依存しないため、
どのようなプロジェクトであっても参考になるかと思われる。

  • 見積りをする際に最低限必要な資料(p.34):
    • 機能(非機能)要件一覧
    • アーキテクチャ構成図
    • 粒度大きめのフロー図
    • プロジェクト体制図
    • スケジュール

図や表にすることで、顧客や開発メンバーとの情報共有が可能になるだけでなく、
見積り範囲の提示も可能になります。
(p.34)

上記のスケジュールには、フェーズ単位で記載されている粒度の大きいマスタースケジュールと、
実際のタスクを配置した開発スケジュールがある。

  • マスタースケジュール作成のポイント:

    その際にポイントとなるのが、
    最初のマスタースケジュールは顧客要望をいったん無視して要件をフェーズごとに機能単位で積み上げて作成することです。
    見積りの際には事前に顧客の希望納期が提示されていることがあります。
    しかし、顧客の設定している希望納期はビジネス的な事情により決定している場合がほとんどです。
    そのため、実際の機能の数や工数とは何の関係もありません。
    (p.42)

  • 開発スケジュール作成のポイント:

    このとき、最初に「開発サイドから見た最適プラン」を作成します。
    そうしないとコストを下げたい営業サイドの要望や、早くリリースしたいユーザーサイドの要望に
    強く引きずられて正しい見積りにならないからです。
    (p.52)

    実際の進め方としては、最初はバッファを含めて見積りを行い、作業スケジュールを作成して構いません。
    結果、エンジニア自身も驚くほど膨大な工数になるので、改めて「どんなリスクか」を確認して減らしていきましょう。
    (p.54)

第3章ではプロジェクトリーダーとしてチームの作業を見積もる方法について解説している。
見積り作成時には担当者の名指しは難しいので、ロールと人数だけを想定してタスクにひも付け、
計画を作成する。その際、マルチロールになってもシングルタスクになるように
スケジューリングすることがコツだという。

ロールとタスクをスケジュールに割り付けるコツは、
マルチロールになってもシングルタスクになるようにスケジューリングすることです。
1人の人に複数のタスクが割り当てられているマルチタスク下では進捗の計測が難しくなります。
Bタスクを進めるためにAタスクが止まっていることなどが頻発し、
タスク全体が進んでいるのか止まっているのかがわからなくなります。
特に見積りを作成するような計画段階からマルチタスクになっているようなケースでは、
コストかスケジュールに無理があるプランといえます。マルチタスクになっている
タスクやフェーズを見直して、見積り(スケジューリング)をし直すべきといえます。
(p.62)

また、「タスクの粒度とタスクごとのおおよその工数基準を定めておく」(p.64)必要があるという。
メンバーの生産性についてはチームとしての練度や、メンバー同士のお互いに対する理解度が影響している。
チームリーダーはそれを加味してスケジューリングする。顧客のタスクも忘れず盛り込んでおく(Q&A対応など)。
マスタースケジュールが作成できたら、それをもとに顧客の希望納期に添えるように調整していく。

このとき忘れてはならないことは、金額は値引くことができても工数(時間)を削ることはできない
ことです。
...
なので繰り返しになりますが、「希望納期」から計画を作るのではなく、
あくまで要件から起こしたマスタースケジュールを希望納期に近づけるようにタスクを減らし、
トレードオフしていきましょう。
(p.68)

第4章では受注に向けた見積りを実際に行う方法について解説している。
特に序盤の節について、本書の中ではビジネスサイド寄りの内容となっている章である。
私はこの章で扱われるような内容の業務を日常的に行っているわけではないため
正当な評価を下すことはできないのだが、以下に記す見積りの進め方、
見積り完成時のチェックポイントで確認するべき点は、
ロールに限らず多くの人の参考になるのではないかと思われる。

  • 見積りの進め方(p.80より引用):
    1. 要件を抽出しユースケースを作成する
    2. 要件を満たすための機能要件・非機能要件を抽出する
    3. 非機能要件を満たすアーキテクチャ構成図を作成する
    4. フロー図を作成しながら要件を機能の中分類程度まで掘り下げる
    5. 現状の業務・システムとの整合性を確認する
    6. システムの規模やミッションクリティカル性を検討し、フェーズを決める
    7. 要件とフェーズをあわせてタスクを抽出する
    8. タスクごとに見積りを集計する
    9. タスクごとの見積工数を反映しながらスケジュールに配置し、マスタースケジュールを作成する
    10. 必要な要因規模を検討し体制図を作成する
    11. 見積りをレビューしチェックポイントを確認する
  • 見積り完成時のチェックポイント(p.96より引用):
    1. 要件を現行業務と比較したか？
    2. 体制図やスケジュールに顧客の役割を明記しているか？
    3. 非機能要件が書き出され顧客に説明されているか？
    4. 開発作業以外の費目は盛り込まれているか？
    5. 値引きの要望への対処は適切か？

第2部ではこれまで研究が重ねられてきた見積手法や方法論について解説している。
第5章ではソフトウェア工学的視点での見積りついて、以前と現在の状況の変化を説明している。
見積りの研究は1960年代から主にIBMや米国の政府機関により始められた。
見積りについて、顧客の関心がかつては金額であったのに対し、近年では工期の削減に変化している。
しかし工期の削減は慎重に行うべきだ。工期短縮率が30%以上になると急速にプロジェクトの失敗率が上がるという報告もある。
工期短縮について章末のコラムでは以下のことが述べられていた。

システム開発の工期短縮の肝は、要件や基本設計など上流工程のスピードの速さと効率です。
つまり、開発会社によるプログラミングやテストのリソースの強化だけではほとんど実現できません。
...
これまで納品が間に合わないときや、工期の短縮要望が強いときは、システム開発業界では
プログラミングやテストなどの後工程で「人をかき集める」ことで対処してきました。
しかし、不具合や仕様修正のコストは後工程ほど何倍にも膨らみます。つまり後工程で、
開発会社の要員体制強化による、工期を縮める努力は非常に効率の悪い取り組みです。
したがって、要件定義チームや設計工程のユーザー側のレビュー体制を強化するほうが
はるかに効率的な取り組みになります。工期短縮の要望には何より顧客体制の強化を中心とした
上流工程の迅速化に取り組みましょう。
(p.118)

第6章ではファンクションポイント法(FP法)による見積手法が、
第7章ではユースケースポイント法(UP法)による見積手法が解説されている。
どちらの手法も伝統的な見積方法だが、時代の変化に伴い
近年のシステム開発の実態とマッチしなくなってきている。
そこで本章では、筆者の見解に基づき、近年のシステム開発の実態にマッチするように
アレンジしたものが紹介される。

第3部では現代のクラウド時代のシステム開発の実態にあわせた見積方法の解説を行っている。
第8章では反復開発、自動単体テスト、Git、サーバー管理、DevOps、スマートフォン、AIなど
これまでになかった技術要素に対する見積方法について説明している。
第9章では筆者が実際に実施したシステム開発事例を取り上げて、どのように見積りを進めたかを紹介している。
事例として以下の2つが取り上げられている。

  • アジャイルプロセスとインフラにクラウド(AWS)を活用したシステム開発の事例
  • ミッションクリティカルなWebを用いた業務管理システムの開発事例

各章末にはコラムが記載されており、こちらも具体的な業務をベースにした筆者の見解が述べられており、
参考にできそうだ。

見積り手法の具体的なノウハウや考慮するべきポイントなど、参考にできる内容は多いが、
個人的に特に学びになったのは、要件定義の重要性を再認識できたことだ。
第6章末のコラムは見積手法の選定の仕方が書かれており、筆者は、時間的に可能であれば
2つの方法で見積もってみることを推奨している。手法によって得意・不得意があるので
その点をレビューすることでより精度を高められるからだ。しかし真に重要なことは
要件定義をしっかりやることだと私は受け取った。コラムの内容を一部引用する。

実際、どの方法でも要件定義を行うことと、その見える化までは同じです。
また、見積で一番手間がかかるのは顧客のヒアリングを含む機能要件定義、
次が非機能要件定義です。その際に必要なフロー図や体制図、スケジュールなどの資料も
手法が変わっても同じように作成します。そのため、2つの手法を使って比較してみること自体は
それほど困難ではありません。
(p.142)

どの見積手法を使うかに限らず共通の手順として要件定義は実施される。逆にいえば、
要件定義が十分にできていなければ、精度の高い見積りはできない。
本書のメインテーマは見積りであるため、要件定義についてはそこまで詳しい記述はない。
要件定義についての本も読みたいと思った。

参考文献

Discussion