その見積もり、見積もりになっていません。
元旦から 今年の褒める心構えはちょっと違う と心に決めたので、今日も褒めようと思う。メンバのことではないのでそこまで自分を縛らなくてもいいのだが。
年末、ひょんなことから見積もり本を手にした。それを年末年始に掛けて読んだのだが、読んでいて辛い。見積もりを知らないエンジニアに見積もりを知って欲しい、参考にして欲しいと前書きに書かれているので、自分のようなおじさんは対象読者ではないのかもしれない。であれば、自分がそれを読み、辛く感じても良いのだろうし、対象読者の絞り込みに応じた書きっぷりとして正しい。
それを踏まえて、どう消化したか、である。
おじさんの自分は、いわゆるWeb界隈のエンジニアから見れば対極にあるSIerのエンジニアであり、マネージャである。開発部門に属すれば、引き合いに応じて多くのコストを掛けてプリセールス活動し、見積もりをする。自分で書くときも稀にあるがほとんどはメンバにやってもらう。構成や過去に資料で使えるスライドを引っ張り出すのも役目である。コストを積み上げ、営業と値付けをつける。そこまでの間にリスク識別や組織内のプロセスを回す。案件によるが、RFPや入札では時間との勝負なので、遅くまで資料作りをすることもあるし、それに掛かるレビューでは多くの関連部門の協力を乞うのである。
SIerのおじさんにとっての見積もりとは、こうした組織だったものだ。
件の本を読むと前半は基礎で、後半は事例である。多分に若いエンジニアの方々により執筆されているということを確認できる。
まず、若いうちからこうした執筆をしたということを褒めたい。自分に置き換えたら、やっていなかった。基本的に、自分より先にやっている人や自分より挑戦する人などをとても素晴らしい才能を持っていると思っている。
ワイフも色々とできる人で尊敬するのはそうしたことを幾つも持っているからである。
人は、経験したこと、得た知識からでしか言葉を紡げない。あとできることは写経になってしまう。写経も写し、自分の中に取り込み、消化し、自分の言葉で表現しなおせれば良いのである。
さて、見積もりのコンテンツの中に相見積もりとRFPを比較したコンテントがある。先に述べた自分の背景から言えば、RFPも相見積もりである。何せ、入札なのだから、応札で複数の業者が札を入れれば競争入札の体をなす。これは見積もり条件をapple to appleとして相見積もりを取りたいからそれをするのである。
1つ勉強になったのは、RFPで入札価格を発注者側が提示するということである。これまで、競争入札、RFPで入札価格の提示を見た経験はない。
検索してみると、発注者側が入札価格を提示するケースは半々で、提示することに対して賛否両論なのだという。
【記載すべきでない派】
「ベンダーの過去の経験を買うのだから，実績あるベンダーの見積もりは安くなるはず。提案の金額にはそれを反映できるはず。だから予算を記載する必要はない」（発注者）
【記載すべき派】
「少なくともどの程度の規模のものを想定しているのかをはっきりさせなければ，レベルの全く合わない競合になってしまう。ある時，A社は1000万円，B社は1億円の見積もりを持ってきたことがある」（発注者）
ただ、記載すべきではない派の方が多数なようだ。
もし知らなかったのなら、参考にして欲しい（執筆者には届かないだろうが）ことの1つに、RFPの前にRFIを行い、プロジェクト化したいテーマについて複数のベンダに情報提供と過去事例での参考価格を照会するのである。
これをインプットに発注者側である事業者はRFPを書くのである。であるから、発注者側はベンダの費用感や発注者側としてのプロジェクト全体の予算を立てるのである。さらに、複数のベンダに照会をすることで見積もり上の諸条件を揃える（抜け漏れ防止）のである。
脱線をしたので話を件の本に戻すと後半の事例の中で2つほど読みながらつらみ（あるあるでその気持ちを理解できる）を感じた。
