【スキルアップ】システム改修見積のやり方【完全ガイド】

システム改修や導入をするときに必要となるのが工数見積。
システム開発工程としては【上流工程】に属する。
「実はあまり関わったことがないから、何をするのかよくわからない」という技術者も実は多いのではないだろうか。

契約とお金を扱う仕事のため、ある程度の年次を重ねた中堅以上の社員しか遂行できない仕事だ。
よって、見積のなんたるかを知る人は限られる。

若手は関わったことが無いどころか、自分の単価すら知らないということもあるかと思う。
あるいは、開発STEP数を算出するところだけ部分的に参加したことはあるが、見積書を作ったり金額を扱ったことはないので、自分の手を離れた後は何してるかさっぱり……という人も多いだろう。

しかし「自分もいずれ担当することになる」と考えると、何も知らないのは少し不安と思われているかもしれない。

というわけで、今回はこの工数見積を行う上での手順、背景にある概念や手続き、留意すべきことなどを解説する。

※もちろん現場によって見積書フォーマットもアプローチも異なるので、細かい部分は必ずしも一致しない。ただ、基本はどこも共通しているはず。
※ここでは保守案件などで実施する1人月～5人月程度の小規模見積を扱う。大規模構築と違い、RFP、RFI、RFQなどが正式に作成されることはあまりない。
※ただし見積の本質は規模の大小関わらずあまり変わらないはず。

システム改修見積の完全ガイド

見積の流れ

①顧客要望が出る

「こんど制度改定があるから業務を変更しなきゃ」であるとか、「業務効率が悪いところを直したい」であるとか言った形で、顧客はシステムベンダーに声をかける。特殊なものでなければ、だいたいは現行システムの保守ベンダーに依頼する。
ベンダー側から営業をかけたり、システム改善を提案するなどもトリガになるが、いずれにしても顧客内の需要が喚起されてシステム改修の要請が出る。

②ヒアリング

具体的に顧客が何を欲しているのかをよく聞き、何が要件なのか、いつまでにどの程度のものがほしいのかなどを確認する。
顧客へのヒアリングを通し業務要件を余さず引き出していく。議事録を取るのも忘れずに。

③システム調査

現行のシステムがどうなっているかを把握しなければ、業務要件をシステム改修要件に落とし込むことが出来ない。
よってシステム調査を行い、どこをどう変えたらいいのか、あるいは何かを変えることによって既存処理に悪い影響が無いかなどを確認していく。

④工数算出

どこをどう変えたらいいか、どこにどのようなコードを書き足したらいいか、何の設定を変えればいいか、といった改修内容が具体化されたら、変更STEP数をざっくりと積み上げる。実際には何行のコードになるかは書いてみないと分からないが、「こういうロジックならこれくらい」というだいたいの規模感覚は開発者であれば持っている。
変更規模（たとえばSTEP数で表す）×標準時間という計算式で、純粋な変更工数を算出する。

※標準時間とは、平均的な作業者が一定の作業をするのに要する時間のこと。

⑤見積作成

これまでの①～④で積み上げた情報を整理し、見積書に過不足なく記載する。
図表などを用いて、分かりやすく説明する。書きながら、抜け漏れが無いかや、より美しい情報整理のアプローチが無いか検討する。

⑥内部承認

自社あるいはプロジェクトチーム内の現場責任者や課長クラスなどの権限者に、見積をレビューしてもらう。このレビューの中で、見積工数の妥当性や、システム改修のリスクなどの観点から質問や指摘がされる。
不足不備があれば②～④のプロセスを繰り返す。

案件規模によっては、課長クラスだけでなく部長クラスの承認も必要となってくる。
よって、顧客はもちろんのこと、自社に対しても納得感のある見積を作る必要がある。（顧客の納得と自社の納得は若干異なる。自社内レビューのポイントは、リスクを考慮しているか、そして多少トラブルが出ても利益になるかどうか）

⑦見積提示

内部でのレビューが完了したら、晴れて顧客に見積提出となる。
見積書を提出し、顧客側で予算取りの審査などを実施してもらう。

場合によっては顧客の予算承認者（部課長クラス）に改修内容を説明することとなる。
見積書単体だけでは顧客訴求力が低い（予算案が通りにくそう）な場合は、積極的に説明の場を設けるなど、受注活動を行っていく必要がある。

ただし口頭説明すること前提で、文面がわかりづらい見積書を作るのはNG。あくまで見積単体で完結している必要がある。（「書いてないけど口頭で補足しようと思った」は言語道断。あとから納品物でトラブルになった際、見積書に不備・記載不足があったら必ずその責任を問われる）

⑧成約

顧客が見積に同意したら、発注書を貰って開発スタートとなる。
あとは見積もりした通りのものを作って納品し、納品書にサインを貰えば良い。

納品したらしたで「注文と違う！」などのクレームがあったり、待てど暮らせど入金がなかったりするトラブルもあるが、それはまた別の話。

見積書のフォーマット

「見積書」を構成する書面はいくつかある。会社や現場によって様式もバラバラだろうが、以下のようなものが最低限だと思われる。

概要説明書

顧客から要件をヒアリングした内容、あるいは制度改定であればその内容の要約、そしてシステム改修の方針や変更箇所、改修するにあたって調査した内容と結果などを、過不足なくまとめる。
開発のための方針書でもあるので、ここに抜け漏れがある（品質が低い）と開発も滞るし、顧客が望んだものも納品されないので、トラブルの原因となる。

また、前提条件で必須の文言として「見積書に書いてある以外の改修は、追加見積ですよ」という旨が書かれていなければならない。
見積に書いてあることは過不足なく納品されるべきだが、顧客から追加要望が出る場合もあるし、成果物について行き違いが出ることもある。そうした場合の対応を予め定めておくための文言となる。

工数明細書

工程ごとの成果物と、それを作るための工数。
明細には、要件定義工程、設計工程、開発工程、ジョブや権限設計工程、事務・作業管理工数といったものが、ある程度具体的にブレークダウンされた形で記載される。
抜けている作業が無いかどうか、実際にその改修が稼働することを想像しながら過不足なく記載する。

単価表

案件によっては、プログラマーだけでなく、プロマネを置いたり専門知識やスキル（語学なども含む）を持つ上位の人材を呼ぶ必要がある。こういった人々は、単にプログラミングオンリーの人材と比較すると単価が高くなる。
よって予め取り決めてある単価表に当てはめつつ、このレベルの人材を何時間投入するのでいくらです、という金額提示をする。

ちなみに、高位人材ほど一人月以下の端数工数では請けてくれなくなる。これも難しいところだ。

内部損益表（顧客には提出しない）

技術者の調達単価、売価、稼働時間、粗利といった情報を集約し、損益のチェックを行うための表。
調達単価が書かれているので当然、顧客提示などはしないものだが、内部でのレビューには必須となる。
通常、見積もった時間以上に技術者を働かせなければ、赤字が出ることはない。

工数計算の方法

改修を行うにあたって、処理内容に応じ、どの程度の追加プログラムを書けばいいのか（STEP数）を算出する。
改修規模や前後のプログラムの流れ、難易度によってプログラムの記述量は変わってくるが、だいたい経験則と部品ごとのブレークダウン（変数定義で何STEP、処理本体で何STEP、終了処理やメッセージ処理で何STEP、など）をしていけば、自ずとそれなりの精度で総STEP数が算出される。

次にSTEP数に対して標準時間を掛ける。

標準時間とは、平均的な作業者が一定の作業量をこなすのにかかる時間のことで、ここではプログラム一行書くのにどれくらいかかるかという時間の事を指す。
標準時間は、現場ごとや会社ごとで、時間量が定められている。

あとは、そこに付随工数を足しこむ。

付随工数とは、ドキュメント類を更新する作業であったり、他チームやベンダーと調整をする工数であったり、作ってみなければわからない部分に対するリスクを考慮したバッファ工数であったり様々だ。

開発は一筋縄でいくとは限らないので、こうした付随工数も当然考慮していく必要がある。

見積において重要なこと

工数計算式自体は、見積の本質ではない

見積　≠　工数計算

先述の通り、何をどう改修するかを決めれば、自ずと経験則から必要STEP数が分かるので、あとは1STEPあたりの決められた標準時間（作業者が一定の作業をするのに必要な時間）を掛ければ工数が割り出される。
その工数に、あらかじめ定められた時間当たりの単価（１時間ン千円だのン万だの）を掛け算すれば、見積が完成するわけだ。

しかし、計算式自体は見積もりの本質ではなく、いかに抜けもれを減らすか、いかに改修内容を顧客に納得いただいて予算をとるかが重要となる。

前出の見積フローでいうと、工数計算はあくまで④のステップであり、全⑧ステップあるうちの一つに過ぎない。実際には要件のヒアリングが最も高度な作業になる傾向があり（傾聴力と理解力、知識量が必要）、その要件をシステム改修にブレークダウンするのが、次いで難易度が高い。

見積作成する上で、本来は改修しなければならない箇所を見落としていたり、顧客要件を聞き落としていたり、理解不足や勘違いしていたりするのも、のちに重大な瑕疵となって返ってくる。見積者の怠慢として顧客・自社から責められることもある。こうした未来を避けるために、入念な「抜け漏れ」防止検討も必要だ。

更に、顧客に改修内容を納得いただき、予算を取っていただくための受注活動・プレゼンテーション・説明能力も重要となってくる。

多面的に考え、リスクを洗い出し、抜け漏れを防止

見積に向いている人と、向いていない人がいる。
どっちが良いというわけではないが、前者の方が優秀な人材である傾向は間違いなくある。

設計より更に上流工程と言われるだけあって、昨日まで開発実装を担当していた人にいきなり見積をしろといわれても、それは難しい。ある程度、設計や要件定義をこなしてきた経験が求められる。

見積では、あらゆる可能性を考慮しなければならない。
例えば、上司から言われた仕事をこなすという感覚では、見積を行うことは出来ない。
むしろ「上司から言われていない事」「顧客が言っていない事（言わなくても伝わっていると思っている事）」にも考えを巡らせなければならないし、また「顧客はこう言っているけど実は誤認を含んでいる情報」なども看破しなければならない。
要するに、「どこまで考慮するか」という枠組み自体を、自らの頭で設定しなければならない。

他人の言うことを素直に信じて、それに基づいて進めてしまうという素朴な人は、あまり向いていないのだ。

とはいえ、ライアーゲームをやれと言っているのでももちろんない。
論理的に、冷静に事実を積み重ねていけば良いだけなのだ。

※「他人の言うことを素直に信じて」しまう人は、論理的にその情報が正しいかどうかを自分の頭でいったん検討する工程が抜けている。厳しいようだがこういう人に見積を作らせるとレビュー時にドハマりするし、まかり間違ってレビューを通ってしまったらもっと大変なことになる。

見積においては、システムの熟知と、顧客業務の熟知の両方が必要となる。あるいは見積しながら足りない知識を補充することになる。
自分が知らなきゃそれで終わり（受注とれない、客からの信頼度は減る、よく分からないまま出そうものなら見落としがあって高確率で大赤字の赤っ恥）とくるので、非常に慎重さが求められる。

したがって普段から勉強していない人や、抜け漏れをよく指摘される人は、これもまた向かない。

あくまで見積であるため、細かいところに抜け漏れがあっても問題ない。提案工数内でカバーできる程度の追加作業であれば大したことはない。
しかし、大事なところを見落としてしまう（あるいは大事なところが何かをよくわかってない）という人は、まだ見積を任せられるレベルに達していない。

見積レビューで大事なこと

妥当性やリスクをしっかり検討してから提出すれば、レビューは通りやすい。

しかし、たまにあまり考えずに上司に提出してしまいレビューで散々に指摘される人がいる。
というかむしろ、上司のチェックを見積デバッグかなにかと捉えている人もいて、全然荒い状態で上げてきてしまう人がいる。こういう人は向いていない。

では、どこまで考えてレビューに臨めばいいかというと、「改修後に実際に運用されている姿」を詳細に想像すると、リスクの洗い出し精度が向上する。

見積書は重要証拠でもあるということ

見積書を「単なる工数計算をしたもの」という捉え方をしてしまう技術者がいる。

しかし、見積書はれっきとしたお金・受発注に関わる重要証拠であり、顧客の予算拠出の意思決定根拠でもある。
あとからトラブルになった場合は見積書の精度が必ず争点となり、それにより損害賠償の有無が決まったりもする。
したがって、後々のトラブルまで見据えた書き方をし、要件と改修内容を過不足なく記載し、「見積書に書かれていること以外は追加料金」であることも明示し、他にもあらゆるリスクを検討する。

こうしたことの必要性は、見積書を「単なる工数計算」の書面と捉えている技術者には、おそらく理解するのが難しい。自分の仕事と法廷闘争のシーンが、あまりリンクしないし、ピンと来ないからだ。

そして、技術的なこと以外にも目を向けなければならないので、たとえばプログラミングだけやっていたい技術者は嫌がる傾向のある仕事だ。（プログラマーの飯の種作りのはずなのだが）

一応、ジェイコム株大量誤発注事件など、思わぬところからベンダーの責任が問われた事例などは知っておくべきだ。

顧客にとってわかりやすく

文字情報だけでなく、図表も活用して、技術的用語も多用せず、顧客にとって最も分かりやすくするにはどうすれば良いかを考える。
それまで収集した情報を徹底的に整理し、分類し、総合的に俯瞰するという作業が必要になるので、これがかなり大変だ。
As-isのプロセスフロー図とTo-beのプロセスフロー図を併記し、どこが変わるかを赤く目立たせるなどといった基本的な作図も有効となる。

ここをなおざりにしたり、情報や図に間違いがあったりすると、それだけで顧客は発注を見合わせてしまう。

顧客にとってわかりづらいということは、改修内容への同意が取りづらいという事でもある。
改修内容は顧客自身が理解して同意しなければ、あとから「求めていたものと違う」というクレームも発生しやすくなる。顧客が納得して改修に着手するのが重要だ。

難易度の高い見積もりに遭遇した場合

分からないことが出た場合の対処法

基本的なことだが、
・わからないのにわかったふりをしない
・わからないことを恥と思わない
・わからなくても調べればきっとわかると信じる

ここを面倒だとか恥ずかしいだとかいう個人的な感情でなおざりにしてしまうと、とんでもない見積もりを作ってしまい、絶対にあとから大変なことになる。

よって「わからない」原因が自分の実力不足・知識不足だろうがなんだろうが、大変なことになるくらいなら見積は出さない方が良い。
そもそも、そういったものは一人でやる見積もりではなく、応援人員を呼んで行うべきものだ。

顧客の言っていることがわからないとき

ヒアリング会議中いろいろな話が出ると、たまに顧客の言っていることがよくわからないというときもある。
こういうときは素直に議事進行を止めてでも、素直に「わからなかったので平易な言葉で教えてください」と言うべき。

なんとなく、会議を止めると迷惑そうだからとか言う理由で、怯んで何も言えないという人も居るが、わかってないのに流してしまうことは絶対に避けるべきだ。

それよりもちゃんと無知をさらけ出すこと。
無知をさらけ出すのは技術者・コンサルとして恥ずかしいと思っている人も居るようだが、それは事前に入念な勉強をしてあった場合のみに適用される話で、「勉強もしてないのに、さりとて無知を晒すのも恥ずかしい」などというのは、そもそも迷惑なので会議に出るべきではない。（※会議というのは、出席した人全員に役割がある）

いったん素直にわからないと言えば、顧客側もそのレベルに合わせて話してくれるし、理解度を確認もしてくれるだろうし、幸運にも面倒見るのが好きなおじさんが色々教えてくれるかもしれない。（意外とそういう人はいる）

また、会議終了の直前に、ラップアップ（話した内容のまとめ、各自Todoの確認）は必ず実施する。
解散の流れになってしまいそうなときは、多少不自然でも全員を引き留めて、これを実施する。
よくわかってないのに解散されてしまい、重要情報が散逸してしまっては、困るのは見積者自身だ。

わからない部分の調べ方

本当に扱ったことがないシステム領域であるなどの理由から、まったく五里霧中という場面に遭遇することがある。（例えば制度改定。会計の事なんて全然知らないのに、システムの国際会計基準対応の要件を出された、など）

こういうときでも落ち着いて「国際会計基準」について調べるしかない。難解な条文を理解したり、あるいは解説してくれる書物などを探したり、勉強会に出てみたり。近道は無いとあきらめるしかない。

だが、絶望する必要は全くない。

『サラリーマンの悩みのほとんどはすでに学問的答えが出ている』という本がある。

じつは五里霧中だと思っていたものが、学問的にはしっかり整理されつくしたものだったという事もよくあるということだ。本屋に行って関連書籍を当たれば、意外とほしい知識が手に入ったりするものだし、腰を据えて2，3日勉強すると思わぬところから道が開けたりもする。

納期に追われ、短期的に答えを追い求める姿勢だと、この「外部の知識をじっくり当たってみる」という選択肢に驚くほど気付かなくなる。

よって、わからないのは仕方ないのでじっくり責めるという考え方が重要。

やはり普段の勉強は大事

制度改定というのは意外とよくある。直近だと消費税の増税などもあった。

普段から経済動向に触れたり、何らかの専門知識を継続的に勉強していれば、そうした制度改定があった場合でも少ない工数で理解することが出来る。普段の積み上げがモノを言う。

それが無い状態で、いきなりよくわからない制度改定の対応をしろと言われてしまうのは、先行きの見えない闇に放り込まれるようなものであり、相当なストレスとなる。

消費税増税の対応だって、会計を少しも勉強していなければ、「仮払い消費税」だの「仮受け消費税」だのといった単語が顧客から断りなく発話された時点で、冷や汗が出てきてしまうだろう。いっぽう、簿記3級のテキストの最初の20ページも読んだことがあるならば、単語の意味も分かって落ち着いて対処ができる。

勉強は普段からこつこつやっていけば、こういった「わからない部分」にも対処がしやすいというわけだ。

もちろん自力だけでなく、詳しい人に訊くのもアリだし、スポット増員で応援に入ってもらうのもアリだ。一人で抱えるのは良くない。しかしその人に頼り切ってしまうのはNGなので、やっぱり自分の仕事なら自分で調べ自分で勉強するという意識は持っていたい。

顧客予算について

保守案件の小規模追加開発というのは「顧客にとって必ずしも必要なものなのか」が常に問われる。
場合によっては、要望は出たものの、結局のところ予算が取れず案件が流れるということもある。

必要度の高いもの、たとえば費用対効果を度外視して対応しなければならないもの（制度対応や企業統制に関わるもの）は予算が出やすい。
一方、図の下に行くほど必要度が下がるので費用対効果が問われるようになり、便利機能系はほぼ予算が通らない。
メリットを享受する人が少なかったりする場合は、改修によって浮く工数が限られるので、全体最適の観点から、一部従業員の不満があってもシステム改修は見合わせることも多い。

見積工数を下げれば費用対効果面でバランスするかもしれないが、ベンダーとしてもあまり小規模だとやるメリットが無いので、一定の水準以下の工数の案件は受けない。
タクシーの短距離利用の客みたいなものだからだ。最低料金ではないが、最低工数を定めて、作業量が下回っている場合は最低工数で見積もりを出すというところもある。

ベンダーとしては、見積るうえでこうした必要度を考慮しなければならない。必要度が低く、確度が低い案件の見積もりに力を入れても、双方にとってメリットとはならないからだ。
双方にメリットのある受注活動をしていくのがポイントとなる。

見積と統制ルール

大きな会社であればあるほど、技術者の属するエンジニア部門と、営業担当の属する営業部門が分離されており、与えられている権限・分掌も異なっているはずだ。
たとえば現場レベルの技術者では、売価単価も調達単価も知らされていない場合も多い。
顧客に金額提示を出来るのは営業部門のみ、というルールを敷いているところもある。

これはある意味当然のことで、現場レベルの技術者が審査もされていない金額提示をうっかりしてしまったため、顧客内で金額だけが独り歩きし、大きなシステム開発を小さな値段でやってくれると勘違いさせてしまうということもありうるし、実際そんなトラブルは枚挙に暇がない。

見積は、社内プロセスに則り審査されたものだけを提示できる。

現場レベルにそれが一任されている場合もあるかもしれないが、それは現場レベルで扱える責任の範囲内に収まっているからで、代替の場合は会社の管理部門が単価情報を管理しているはずだ。

最後に：見積もりを上手くやるにはどうすればいい？

ここまでいろいろ書いてきたので、見積というのはとてもハードルが高く大変なことのように思われるが、やってみると意外とそうでもない。
ある程度、真面目に経験を重ねて、自分の頭を使って働いている人なら、誰でもいずれできるようになる。

ロジックをしっかり積み重ねて、各要素を丁寧に、抜け漏れなく検討していく。これを地道に遂行していくだけだ。
また、何か想定外の事や行き違いなどのトラブルが起きた時のことも考え、しっかりと対策しておく。

しかし万時を尽くした場合でも、揉めるときは揉めるので、その時は仕方ない。

システム改修見積について。
見積書に書いてある通りに作るからね？見積の要件欄に書かれてる事が要件であって、あなたが会議で「言ったはず」の事は要件ではないからね？作り始める前よく読んでね？訂正あれば成約前に言ってね？

としつこく言ったり書いたりしても揉める時は揉める。
ざんねーん☆‼️

— 残業ペンギン＠IT技術者・SAPコンサル・中小企業診断士 (@ZangyoPenguin) September 22, 2020

見積に関わるおススメ参考書のご紹介

以下のような書籍は、読んでおいて損はないので、肌に合いそうなものを選んでみては如何だろうか。とくに『人月の神話』（丸善出版）はIT技術者が読むべき名著として紹介されることが多いし、著作者自身が皮肉交じりに「ソフトウェア工学のバイブル」となっていることに触れている。

『ソフトウェア見積り　人月の暗黙知を解き明かす』日経BP

『システム開発のための見積りのすべてがわかる本』翔泳社

『ストーリーで考える「見積り」の勘所 (開発の現場セレクション)』翔泳社

『人月の神話』丸善出版

にほんブログ村