ここのところ、どちらかと言うと若年層向けの内容が多かった気がしますので、ほんの少しだけターゲット層をあげてみようかと思います。

で、カテゴリは「見積り」。

私たちＩＴ産業のみならず、受注生産や注文を請けてから活動する企業では、多くの場合、

　"見積り"

という作業を事前に行います。これは、契約する際に、公平性を期すため、あらかじめ「どの程度かかるか」を提示し、納得いただいたうえで契約に踏み切るための儀式のようなものです。

たまに、「値段の書かれていない高級料亭」みたいなところがありますが、一般消費者としてはハードルが高いですよね？

後でいくら請求されるか不安で、入ろうという気になれません。
最初に提示されるから、気兼ねなく利用できるのです。

そういう意味では、ＩＴサービスなどでも料金が明示されず、「お気軽にお問い合わせください」と書かれているWebサイトなどを見ると、若干ハードルが上がる気がします（気になっているから、いろいろ情報を集めたいだけなのに…）。

そういうサイトを見るたびに、個人的には機会損失量の方が大きい気がしています。実際にどの程度かかるか正確に説明できなくても、過去事例から概算どの程度かかったかはサンプルとして載せておいてもいいと思うのですが…。

まぁ、モンスターカスタマーも増えつつある昨今、誤解される可能性がほんの少しでもある情報は乗せづらいのかもしれませんね。

見積りとは

少し脱線してしまいましたが、「見積り」とは、ご存知の通り

　金額・量・期間・行動を前もって概算すること。
　あらましの計算をすること。 また、その計算。

を指します。

規模を見積もれば「規模見積り」、作業を見積もれば「作業見積り」といった具合に、数値化し、計算できるものを概算することを言います。当然ながら、「金額見積り」は、ある活動に必要とされる金額、あるいはある作業によって作成される製品の価値を金額に換算したものを見積もります。いわゆる契約前の「見積書」と言うのは金額見積りのことを指します。

実際に活動するまえにあらかじめ見積るため、「見積り」とはすべて未来予測ということになります。

ですから、100%正確ということは絶対にありません。

その後、契約する以上、よほど見積り条件に抵触することがない限り、見積り金額が増減しないように収め、結果／成果に対して対価を支払い、契約は満了します。

見積り時に予測できないケース

しかし、見積りは先ほども申し上げたように、これから起こす「未来」を予測した概算です。どんなに綿密な打ち合わせをしても、すべての未来を見通すことができないケースはままあります。

それが良い方向に向かうことであれ、悪い方向に向かうものであれ、それらは一括りに『リスク（予測できない事象）』と呼ばれています。

一般的には「悪いリスク」を検討することが多いのですが、この悪いリスク…たとえば、注文時点で、詳細な仕様が詰め切れておらず、活動開始後に進めながら決めていかなくてはならない、といった場合があります。この場合、いざ決まった時には、当初想定していたスケジュールや金額に収まらないような規模に膨れ上がっていた…と言うことも多く、ユーザー企業にとっても、開発側にとってもあまり歓迎したくない問題だったりします。

ユーザーとしても、「年度初めに想定していた予算を超える支払いはしたくない」、開発側としても、「途中まで作成したものを破棄して、作り直す作業が発生するかもしれない」といった背景があり、こうした

　進行中に変更を加える

というのは、非常によくある事例ですが、できれば避けたいリスクの代表でもあったりします。

不測の事態を見積りに加える現場

私はしたことが無いのですが、稀に見積り時にそうした不測の事態（リスク）をあらかじめ見積金額の中に積んでいるプロジェクトを見かけます。しかも、ユーザーにはその積んでいることを明確にご説明していないようなのです。

これって、要するに

　「リスクが顕在化したら、その費用に充てる
　　ただし、顕在化しなければ、余剰分はすべて利益にのせる」

と言っているのですが、こうしたプロジェクトを見かけると、色々な面から「大丈夫なのかな？」と思うことがあります。なぜなら、見積り段階で、未来にどんなリスクが発生するか、発生したリスクの規模がわからないからこそ『予測不能』なのであって、それを見積りに加えるということは予測可能と言うことですよね。

それってもうリスクじゃないんじゃないかな？と。

でも実際には、まごうこと無きリスクです。実際には予測できるわけもありませんから。

このことから何が心配なのかと言うと

　・積んだリスク分の規模はどうやって概算したのか？その根拠は？
　・リスクが顕在化しない場合に、そのまま掠め取るのはぼったくりでは？

という２点です。
まぁ、後者はユーザーに説明し、合意を得ているような内容になっていれば何も問題はないのですが、私が見たことのある過去の見積書では、内訳の各作業や成果物に細々と盛り込んであって、とても明示的に説明したもののようには見えないものがありました。

正直、それで収益を上げて、企業が潤ったとしても、いや結果的にその金額にユーザーが満足しているのであればいいのですが、少なくともその見積り方では、プロジェクトメンバーやマネージャーの力量が図れないな…と思うわけです。

企業によっては「収益性」を評価基準の軸にしていて、利益貢献などを理由に昇進、昇格、表彰などを行う企業もあると思います。しかし、この収益のあげ方は、能力、努力、成長、実績、どれにも貢献したものではありません。どちらかと言うと、詐欺に近い手法で手に入れたものです。

褒めるのはちょっと違うのではないかな？と。

まぁそんなこと言ってると、「世の中、きれいごとだけじゃない」と言われそうですが、私は少なくとも自社⇔自分、自分⇔顧客、自社⇔顧客、etc.…ステークホルダー間では理想的な関係でいたいし、そうあるように努力しているので、顧客を騙すようなことはしたくないですね。

それに、そんなことしなくても、適正価格で充分以上の収益を上げる方法はいくらでも持っていますし。

不測の事態を見積りに加えることのリスク

また、こうした「あらかじめリスクを見積りに積む」と言う手法は、それ自体が大きなリスクを産み出すということも理解しておかなくてはなりません。

まずは『見積り時』のリスクを見てみましょう。

たとえば、実際には「見込んでいたリスク」以上に、問題が顕在化してしまった場合です。

そもそも、見積りは未来予測です。
ただでさえ予測不能な事態を想定したものですから、精度は相当低いはずです。人によっては、「うーん…、1.2倍くらい積んどくか」といった、何の根拠もない見積り方をしている人もいるでしょう。

こうなると、顕在化したリスクの対応は

　①ユーザーと揉めてでも、増加分はやらない
　②ユーザーに無理を言って、増加したうちの不足分を追加請求する
　③泣き寝入りして、赤字覚悟で実施する

くらいしか選択肢がありません。

①は今後の機会損失につながるかも知れません。それに相当揉めると思います。その幾度となく行われる打合せや応対にかかる間接費の方が無駄な気がします。②は"積んでいたことを伏せていた"場合には可能かもしれません。もちろん、ユーザーの予算次第ですが、変更要求がユーザーから行われているのであれば、見込みはあります。"積んでいることをあらかじめ合意していた場合"には、難しいかも知れません。その予算枠で、ユーザー側も年度計画が進んでいて、追加予算がないかも知れないからです。「その正確な算出のためにあらかじめリスクまで積んでいたのではないのか」と逆襲を受けかねません。③はユーザーにとっては嬉しいことですが、メンバーは疲弊し、上司からは怒られ、評価は下がり、今後、日の目を見ることが無くなってしまうかもしれません。

また、管理職以上にもなると、目の前の数字ばかりを追いかけるようになる人も増えてきます。まぁ、数字＝評価とする企業も多いので、仕方がないかも知れませんが、そうなってくると、②のような対応が仮にできたとしても、後々大問題を起こすことに繋がります。それは

　予算だけ増やせても、スケジュールまで調整できなかった

という事態を巻き起こしてしまうからです。

お金ばかりしか見ていないマネージャーの場合、こうしたケースは珍しくありません。ユーザーにもユーザーの都合があって、カットオーバー（稼働開始する時期）自体はずらせない事情もあったりします。

こうなってくると、平凡なマネージャーでは、「人海戦術」か「機能削減」の２種類しか提案できなくなってしまいます。

しかし、前者の人海戦術で人を急に増やしても、過去経緯を知らなかったり、それまでのプロセスに慣れていない人では、元々いるメンバーほどのパフォーマンスが期待できません。トラブルプロジェクトが単なる算数で試算できない理由と同じです。後者は、すればするほど顧客満足度を低下させます。

こうして、完全にマネジメント起因で摘んだ状態となっていくのです。

ですから、私個人としては、見積りにリスクを積むマネージャーをあまり信用しませんし、評価もしていません。こっそり積むようであれば尚更です。

理想的な見積りは「リスクを積まない」こと

厳密には、「リスクは積めない」が正解です。

仮に一時的に収益が上がるようなことがあっても、その対価としてどんどん黒くなっていくだけな気がします。ここまで説明してきたように、見積りが未来予測のたまものである以上、その一部であるリスクの見積りも正確になるはずがありません。それを無理やり積もうとすること自体が歪なのです。

その代わり、これはあくまで私個人の主観と言うか、今まで行ってきた最適解なのですが、次のことをします。

　・プロジェクトの見積りを行うのは確定している要求分のみ
　・検討したリスク分は、ユーザー側の予算として積んでいてもらう
　・リスクが顕在化したら、都度再見積もりさせていただいて、
　　「期間」と「予算」を相談させていただく旨、契約合意する

ポイントは、私たち開発側の見積りに「リスク」を積むのではなく、ユーザーの財源上に積んでいてもらう、ということです。ユーザー側の内部調整等がどこまで進んでいるか次第ですが、あらかじめ、できるだけ多く、積んでおいてもらうと良いでしょう。

リスクが顕在化したら、都度「変更依頼管理」に基づき、当初の計画とは別に対応します。こうすることで、都度、正確に見積りをおこない、提示しても、ユーザーは財源確保が済んでいる状態ですので、調整が容易になります。

また、必ず「スケジュールにも影響を与える」ことをご理解いただき、変更を確約しておかないと、ユーザー企業内部で、勝手に崩せない状況を作られかねませんので、ここは死守しておく必要があります。

ただし、年度をまたぐような場合、工事進行基準（完了基準）など会計上の課題が生じることもありますので、

　・できれば、追加/変更は別フェーズ、別契約とさせていただく

というような調整を行い、「ちゃんと納めて、一つのプロジェクトとして終わった」状況にしておくと、きちんと売り上げ計上できるようになりますので、その点も注意しておくと良いでしょう。

なんでもそうですが、「とりあえずやってみて、やりながら調整する」と言うのは、大前提として「調整できる余力がある場合に限る」わけです。そしてその調整のしやすさと言うのは、当初の見積りや計画といった

　"準備"・"段取り"

次第だということを忘れてはならないと思います。それもなしに無鉄砲に突っ込むのは、知識労働者のすることでは無いのではないでしょうか。