はじめに
本稿はミライトデザイン Advent Calendar 2022 の 25日目最終回です。
24日目は @FrozenVoice さんの NFTと仮想通貨とブロックチェーン でした。
NFTとか最近耳にするけどなんや？って方はぜひ読んでみてみてください。
てなわけで、普段めったに記事とかを書かない自分ですが、アドカレ最終日くらいは代表の自分も書くべきだという社内の圧力と力学の元、最終稿を担当させて頂きますのでよろしくお願いいたします。
序
今回は「見積もり」のお話しです。システム開発に携わっていると様々な「見積もり」に遭遇します。
皆さんも大なり小なり見積もりの経験があると思いますが、見積もりって難しくないですか？
私は初心者を抜け出したころから会社を経営してる現在に至るまで、いつまでたっても難しいなぁと感じています。
そこで今日はそんな難しい見積もりと少しでも仲良くなれるように、見積もりの違いを整理して見積もりに対するハードルを少しでも下げていこうと思います。
具体的には、一口に見積もりといっても様々な種類がありますので、見積もり毎にそれぞれ目的や求められているものが違います。
それらを理解する事で見積もりに対するハードルが下がるかもしれません、という趣旨になります。
残念ながらあくまでハードルが下がる程度なので難しい事に変わりはありませんが、そこはまあご愛嬌という事で。
見積もりの種類
さて、実際に見積もりにはどんなものがあるでしょうか。
大きなものから小さなものまで様々な見積もりがあると思いますが、ざっと二分すると
- 外向けの見積もり
- 内向けの見積もり
にわかれてきます。
外向けの見積もりとは、主に依頼者（社）に対して金額だったり工期だったりを示すために必要となります。
対して内向けの見積もりは主に計画を立てたりする際に必要となります。
以下、見積もり種類毎に特徴を列挙したいと思います（難易度は個人的な見解です）
難易度順でもなく思いついた順に雑多にならべます。
外向けの見積もり
業態によって目にする見積もりの種類も変わってくると思いますが、一般的によく遭遇する外向けの見積もりには以下の種類があります
人月見積もり 難易度 ★☆☆☆☆
主にSESの契約をする際に見積もりです。
目的
アサインエンジニアと単価感がプロジェクト予算と見合うかどうかの判定材料として使用されます。
見積もりという点に絞れば主に以下を確認します
見積もり受領側: 月単価がプロジェクトの予算と合っているか。その上でアサイン予定のエンジニアの費用対効果が妥当とみなせそうか。
見積もり提出側: 月単価が受入れられそうか。
概要
この見積もりは多くの場合見積もり受領側が先に単価感と共に募集をしている事が多く、見積もり提出側はそこに（単価的に）マッチしそうなエンジニアの見積もりを提出する事になります。
なので、金額自体が合わないという事は滅多になく、その金額に対してアサイン予定のエンジニアのスキルや経験がマッチするかどうかが見積もり作成のメイン作業となります。
総評
基本的に難易度は低いです。
最近は売りて市場で高騰していたりしますが、そういった市場の動向やマッチ度合いを元に算出しましょう。
概算見積もり 難易度 ★★★★★
システム開発において正式見積もりを出す前に概算での見積もりを必要とする場合が数多く存在します。
主に中～大規模案件に多く見られますが小規模でも必要となる局面もあります。
不確実性コーンで言う一番左端、実態とは0.25倍～4倍かけ離れていてもおかしくない時期の見積もりとなります。
不確実性コーン1
目的
要件定義などを経ないと正式な見積もりは出せないが、その前に事前に規模感などを知るのが目的となります。
見積もり受領側 : 主にプロジェクトを進めるか否か、予算取りの為の稟議、担当ベンダー決め、などの判断材料
見積もり提出側 : 受注した際に最低限必要となる金額や工期工数の提示
概要
難易度はかなり高いです。人によってはこれが一番苦手という方もいるかもしれません。
それは、そもそも作る物や工程、納期など見積もりに必要とする情報が圧倒的に足りない状態での見積もりとなるからです。
この見積もりが難しいのはいくつかのポイントがあります。
-
稟議材料としての観点
まず、稟議の材料となる場合、この時点での見積もりの不確実さを受領側提出側双方理解しているにも関わらず、実態としてはこの見積もりで出た数字がプロジェクト予算の上限になる事が多々あります。稟議が通った予算以上の金額を捻出する事を避けたいという思いがあるからです。
不確実と言いながらもこれが上限になるのであれば慎重にならざるを得ないですよね。 -
発注先決めとしての観点
また、担当ベンダー決め（発注先決め）としてもこの見積もりが重要になります。そして担当ベンダー決めの観点としては重要なのは金額だけではないです。
この不確実な時期の見積もり金額は受領側も参考値としてしかとらえていないケースが多いです。では、何が重要となるのでしょうか？
ここからは個人的な考えですが、概算見積もりで金額以上に重要なのはこの「限られた情報しか整理できていない段階でどのくらい分析ができているかどうか」という点だととらえています。
提供された与件や要望を元に、いかに実際の開発において発生しうる工程や機能を整理した見積もり作成ができるかがポイントとなります。
それらがより緻密な程受領側からの信頼を得られるでしょう。金額だけで決まる事もありますがそういった案件はまあ気にしない気にしない。
総評
概算見積もりは様々な意図で使用される事が多く、その目的に応じて重点を置く必要があります。
見積もり作成にあたって重要な事は、受領側がどういう意図で必要としているかを理解し作成する必要があると言えるでしょう。
ちなみに私が概算を出すときは、
- 不確実なフェーズだからといって大雑把に見積もりをせずその時にわかる範囲で可能な限り工程を分析する
- 最終的には要件定義と本見積を分けて見積もり提出する流れを希望する
- くどい位に「概算だから本見積は大幅に上下動する可能性がある」と伝える
- QCD2の観点からCostのプライオリティ次第で大幅に上下動する可能性がある
- 余裕があればmin-maxの観点で見積もりパターンを用意する
という事を意識しています。ざっくり言えば、変わるからね？変わるからね？と念押ししてます。
本見積もり 難易度 ★★★★☆
正式な見積もりです。この見積もりは金額だけでなく工期もセットで必要となる事が多いです。
算出の仕方としては主に工数を算出し、そこに単価を掛け合わせて作成する事が多いです。
目的
見積もり受領側 : 実際の予算の把握
見積もり提出側 : 予算の合意
概要
本見積は経営レイヤーの人には特に重要となります。
システム開発は小売りなどとは違い、原価に対して利ザヤを載せれば大小問わなければ必ず利益が出るというものではありません。
製造原価の大半は人件費となるわけですが、ここは工期次第で変動します。つまりそこを見誤ると受注をしたにも関わらず赤字にもなりかねません。
また、ここを曖昧にしてしまうとプロジェクト終盤で余計なトラブルを起こす原因となる事もあります。
この見積もり範囲がどこからどこまでなのかを明確にしましょう。
そのほか、エンジニアの方が良く陥りがちな点として開発工程にばかり意識がいき、他工程を見落としやすいというて罠もあります。
プロジェクト開始からリリースまでの全工程を分けて分析しましょう。
特に工程については精査が必要です。
一般的な設計・開発・テストに加えて環境構築・リリース作業・ドキュメント作成・打ち合わせ・データ移行・マネジメントなどの工程が必要ないか、またテストも一口にテストといってもUT、ITa、ITb、ST，UATなど、様々な工程があります。どのようなテストが必要となるかの相互認識はそろえておきましょう。
特にITb移行は関係各所との調整が必要な場合が多く工期算出に影響してきます。
本見積を作成する際のポイントは
- 要件定義後に見積もりをする（案件規模による）
- 設計・開発・テスト以外の工程の精査（環境構築・リリース作業・ドキュメント作成・打ち合わせ・データ移行・等々）
見積もり作成のやり方としては、一般的に見積もり可能な単位まで細分化するというやり方が一般的かと思います。
解像度が低い状態で見積もりをすると正確性に欠けるため、画面やユースケース毎にそれを構成する機能などの解像度を上げていき、見積もり可能な単位に落としていきます。
この工程で見落としていた工程や機能を見つけ出す事も多いので非常に重要な工程となります。
私が要件定義や本見積について見積もりを提出する際に常に声を大にして受領側に伝えているのは「ここに書いてある事以外何も作りません。そのくらいのつもりでご確認ください」という事です。少し言いづらい事ではありますが、一方的に思っていていても意味はないのでくどいくらいに伝えます。実際には終盤発覚した事でも柔軟に対応するのですが、あくまでそれは例外とし大前提はこの内容が全て、というスタンスでいきたいからです。
ちなみに伝え方はもっとオブラートに包んでいます。そうじゃないと嫌われます。
※ より道: バッファについて
よく見積もりに「バッファを積む」という考え方があります。
上述の不確実性コーンの図においても本見積の段階でもまだ不確実要素は多分に存在します。
その不確実性に対するリスクヘッジとして、想定した見積もりよりも〇%をバッファとして上乗せする。というやり方です。
ただ、個人的にはあまりおすすめしません。不確実なリスクがある事は間違いないですが、そこに対して漠然とした「バッファ」というもので対処しているとずっと精度の高い見積もりができなくなるからです。また、見積もり受領側にも一切のメリットはありません。それであれば正体があやふやなバッファというものを積むのではなく不確実性が高そうな工程には前提条件を付け、前提が違った場合に再度見積もりをし直す旨を双方の共通認識として行く方が良いと思います。
不可実なものを見積もることはできませんが、前提が揃っていれば見積もりは可能となるでしょう。
総評
本見積はある意味プロジェクトそのものです。
最終的に一番重要なのは覚悟です。精神論万歳。
内向けの見積もり
うち向けの見積もりは意識・無意識様々な局面で行われます。
マネージャーや上長の「いまのタスクどのくらいで終わりそう？」に対する返答も広くとらえれば見積もりと言えるでしょう。
外向けのものほど体系化されていないため、ふわっとした単位となりますが思いつく範囲でいくつか並べようと思います。
スクラムのStory Point 難易度 ★★★☆☆
概要
スクラム開発を行っているチームであれば毎スプリント毎に行っている見積もりです。
外向けの見積もりと違い金額や工期などの単位ではなく難易度や大きさに対する見積もりとなります。
目的
チームのベロシティと照らし合わせてスプリントの計画を立てる事を目的とします。
複数人で見積もる事が多いですが見積もり対象に対する想定がそれぞれずれていると有効な見積もりとは言えなくなります。
見積もるに適切なバックログの粒度と前提をそろえる事が非常に重要となります。
見積もりポーカーなどで極端に違う数字が出てきた際は前提がずれている可能性が高いので安易に平均や中央値を取るのではなく前提のすり合わせをしたうえで再度見積もりを行いましょう。
総評
「俗人性を考慮しない見積もり」という事が理解できていないと難しく感じる事がありますが、難易度としてはあまり高くないと思われます。
そもそもStoryPointをフィボナッチ数列などで行うのも、前提として正確な見積もりを期待していないという面もあるからです（3なのか4なのか、、、等を細かく論じる事の意味が少ない）
日々の作業見積もり 難易度 ★★☆☆☆
概要
一日の作業を日々計画している場合、無意識に毎日見積もりをしています。
日々の作業を計画できている人の方が仕事が総じて仕事ができる人が多い印象です。レッツ計画。
目的
個人タスクの予実管理。
概要
自分が持つ仕事を一日の中でどう配分して進めていくかを事前に計画する事にはいくつか効果があります。
まず、気分的に楽になります。一日をどう進めるかが自分の中でコントロールできていると精神衛生上落ち着く気がするからです。
また、事前に計画が立てられていると差し込みタスクを依頼された際に可能か不可能化の判断が付きやすくなるでしょう。そして一番有用なのは個人進捗の遅れに気づきやすくなり周囲のサポートを受ける手を挙げるのが早くなります。
唯一の注意点は、ここに精度を求めすぎて時間を取られない事です。
手持ちの作業などを見ながらざっくりベースで「何を何時間で終わらせよう」と5分ほどで見繕うのが大切です。
総評
困った時はお互い様。どんどん助けてもらいましょう。
まとめ
見積もり機会は大小問わず頻繁に訪れます。
最初から精度の高い見積もりをする事は困難ですが、それぞれの目的をしっかり理解した上で目的に沿った見積もりを意識する事を繰り返す事で見積もり精度も上げていくことができると思います。
もう少し色々な見積もりについてもう少し掘り下げて書こうかとも思ったのですが、これ以上盛り込んだ記事を書こうとすると、この記事を書く為に見積もった時間を大幅に越えてしまうという問題が発生していまいます。
というわけで今回は見積もり時間内で終えたいと思います。
最後に
ミライトデザインアドベントカレンダーは本稿で最終日です。
昨年に引き続き ミライトデザインのアドベントカレンダーも最終日まで無事完了しました。
自分がちょい遅れで公開した事を除けば、一日の漏れもなく最終日まで繋げられたのは参加して頂いた社内外の皆様のおかげです。
本当にありがとうございました。
また来年もよろしくお願いいたします！