システム開発において、顧客とベンダーとの間で見積や契約を取り交わす時の注意点について今回解説したいと思います。
システム開発の現場では、日々大なり小なり見積作業というものが発生しています。また、契約についても準委任契約と請負契約がありますが（両者についての解説は省くこととします）、これらを使い分けています。そうした中で、工数見積時や契約締結時に私がこれまで困ったことをまとめていきたいと思います。
ぜひ、皆さんが同じようなことに陥らないようにしてもらえたらと思い、書き留めたいと思います。
この記事を読んでわかること
見積工数を提示する時に注意すべきことがわかる
結論
この記事で伝えたいことは一言でいえば、
どんな時であっても、見積するときはリスク費（工数）を忘れるな！！！
です。
リスク費（工数）を見積時に忘れるとどんなことが起きるのか、案件開始から契約締結までに現場で起きている会話と共にぜひ見ていっていただければと思います。
案件開始前
案件発生！概算見積を提示する
今回取り上げる現場は、特に顧客との関係性が長く、ベンダーが顧客に入り込み客先分室にて日々大なり小なりの開発案件を回しているような現場をイメージしてみてください。
こういう現場は大抵の場合、営業は契約上の事務作業のみを担っているようなケースが多いです。
そうした場合、顧客からの新しい案件依頼は大抵日々の打合せの中で発生したり、営業を通さずに開発リーダなどに直接相談されたりすることがほとんどです。
さて、そうした場合、往々にして顧客からは概算でこの案件の見積をしてくれないか？と依頼を受けます。
概算見積の提示
見積依頼を受けたベンダーは忙しい中、寝る時間を削って見積をします。
しかし、大抵の場合は、必要な情報が出揃っていなかったり、要求事項がフワフワしていたり、まともに調査している時間はなかったりと、精度の高い見積はできないことが多いです。
それでも何とかして前提条件を付けて見積を出します。
この時、ベンダーと顧客の間で、要員単価の相場を暗黙的に認識しあっています。
そのため、顧客はベンダーから工数を聞いただけで、この見積をもとに社内で稟議をかけて予算を取ります。
もし、営業がちゃんと間に入っている場合には、工数での見積提示ではなく、金額での見積提示も一緒に行うでしょうが、大抵の場合、この段階で営業が入ることはなく、あくまで現場レベルでの会話という位置づけで仕事は進んでいきます。
案件開始
プロジェクト計画・要件定義開始時
いよいよ案件が始まります。
まずはプロジェクト計画及び要件定義工程ということで、こちらは準委任契約での締結を行います。
そうこうして、なんとか要件定義は計画通りに進んだとしましょう。
（もし、要件定義がうまく進まなかった場合でも、正当な理由があれば準委任契約であるため旨を張って追加工数の請求や期間の延長をしましょう。）
要件定義終盤
要件定義が進むとスコープが明確になり、設計工程以降の契約締結となります。
多くの場合、顧客はベンダー側に責任を持たせるために、「スコープが確定したのだから」という理由で準委任契約ではなく、請負契約での締結を要求してきます。
ベンダーは要件定義の内容をもとに見積を行い、設計以降の工数を提示します。
請負契約締結
いよいよ契約のタイミングとなり、ベンダーは契約書を提示します。
この時、ベンダーとしては完成責任のリスクをとって追加費用を確保したとしましょう。
すると、当然一度提示してしまった工数から算出される金額との差分が発生していまいます。
ベンダーとしての気持ちはすごくよくわかりますが、これには顧客も納得ができません。
結果的に、無理矢理押し通すこともできず、ベンダーはリスク費を乗せることができないまま請負契約を締結することが多いです。
そして、プロジェクトがうまくいかなくなったとしてもリスク費に頼ることができないし、請負契約のため追加工数の調達もできないし、といった具合でデスマーチの音が聞こえ始めます。
どこに問題があったのか？
リスク費は最初から考慮しましょう
さあ、ここまででどこに問題があったでしょうか。
そうです、見積時の工数提示段階で考慮していなかったリスク費を契約時にいきなり上乗せしたことです。
要件定義工程と同様に準委任契約での開発であれば、時間に対して対価を受け取るという考え方のため、追加工数が必要になれば、その分顧客に対して請求することができます。そのため、杓子定規にいえば準委任契約ではリスク費を乗せる必要はありませんし、乗せてはいけません。
しかし、請負契約であれば完成責任を負います。そのため、当然その分のリスク費は乗せておきたいというのがベンダーとしての本音です（むしろ乗せるべきです）。
仮にリスク費を請負契約の場合に乗せないとなると、準委任契約から請負契約に契約形態が変わってリスクが増えたにもかかわらず、、その分の費用をベンダーが確保できないことになります。これでは、単に顧客が有利な契約にしかなりません。
とはいえ、リスク費という存在はかなり厄介で、顧客にとってみれば美味しくありません。絶対に必要とは限らないお金まで取られているという感覚になるからです。私たちが食事に行った際に、料理を作る過程で失敗するかもしれないから１人前以上に食材を用意します。その分のお代もお願いします。と言われたらどうでしょうか。良い気はしませんし、そもそもミスなくやってくれと思うのが自然でしょう。
仮にその必要性を理解したとしても、リスク費をどれだけ準備するかという結論は一生つきません。顧客は最低限度のリスク費を求めますし、ベンダーは最も悲観的に考え、取れるだけのリスク費を確保したいと思います。そのため、折り合いはつかず、平行線のままです。そのため、リスク費はお互い認識はしてるものの、表向きには出さないというのが通例です。
しかし、食事の例は極端とはいえ、ベンダーにとってシステム開発におけるリスク費は必須です。
そのため、顧客も請負契約にするということは、完成責任をベンダーに負わせたり、ベンダー管理工数を削減できたりするといったメリットを享受する一方で、その分費用が高くなるという理解を持って契約すべきかと思います。（今回の例では、顧客が悪いというよりは、ベンダー側の見積提示が良くなかったですが）
良い顧客であれば、「請負契約になる分、リスク費が後から乗っかるのは仕方ないね」と言ってくれるかもしれませんが、まずそんなことはないと思っておいた方が良いでしょう。
また、遡れば、概算見積提示の段階でもリスク費を考慮していません。そのため、10人月（要件定義の結果、正当に12人月になったとしても）という数字が常にベースラインとなってしまいます。概算見積の段階からリスク費を考慮していれば、契約の段階で揉めるようなことはなかったと思います。
とはいえ、実際の現場では、請負契約でいくか、準委任契約のままいくかはがなかなか決まらなかったり、日々の見積算定の時間もなかなか取れなかったりという様々な原因が重なり、見積を提示するときにはリスク費をそこまで考慮することができないことが多いです。（考慮したとしてもリスク費まで精緻に見積ることはできないため、あとから変動しがちです。）
すると、日ごろから、つまり準委任契約の段階でもリスク費を乗せていくことになります。ただ、それでは全体的に費用が高くなることにも繋がり、顧客にとっても嬉しくはありません。また、本来の準委任契約の姿ではありません。また、実際の現場ではリスク工数を取らないで済むようなすごく軽微な案件があるのも事実です。
そのため、日ごろの見積工数の提示の段階でいかにリスク費を乗せつつも、いい塩梅で提示できるかが、腕の見せ所です。
単価が筒抜けだと面倒なことが多い・・・
仕事上、契約書には人月単価（売値）を記載するため、単価を隠しておくことは不可能かと思います。そのため、普段から準委任契約での契約をしているような場合は、双方でだいたいの単価感が筒抜けです。そのため、工数＝金額に直結してしまいます。すると、工数を提示した時点で実質的には金額も透けており、後から工数を据え置きしてリスク費分だけ金額だけを増やすということができません。
だからといって、工数を増やすのであれば、それ相応の追加作業や追加要件が明らかでなければ追加できません。
もし、普段から準委任契約を締結しているような顧客ではなければ、リスク費分を単価に上乗せるする（転嫁する）ことで逃げることができたかもしれません。請負契約だけの顧客や一見さんの顧客であれば、言い方は悪いですが、単価をその時々で誤魔化すことができます。
とはいえ、そういった顧客の方が少ないでしょう。仮に請負契約だけの顧客があったとしても、何度も取引があれば自ずと単価感は透けてきます。
そのため、見積は”一度出したら最後”、引き返すことはできないという気持ちで提示すべきです。
最後に
見積作業というのは
お金にならないのに、時間だけ使う、にもかかわらずミスをすると後から苦しい思いをする
という、本当にベンダーを悩ます作業のNo１だと思います。
そんな見積作業をするときに、この記事を思い出して、リスク費、リスク工数の存在を決して忘れず、準委任契約であろうと、請負契約であろうと、適切なバランス感覚のもとで仕事ができたらいいなと思います。（自戒の念を込めて）
コメント