2006年08月05日
システム開発契約
以前勤務していた会社で、僕の所属するチームは、連結会計とか予算管理といった経営管理業務に特化した上で、要件定義からシステム開発・運用サポートまでのサービスを一貫して提供するというビジネスをしていた。コンサルティング会社の事業としては、すこし変り種だが、収益性も十分良く、楽しい仕事だった。
その中で、お客様との契約にあたっても自分たちで色々な工夫をしていた。
まず、プロジェクトが大きければ、いくつかに分割する。このとき、要件定義・基本設計・開発といったフェーズを切るのではなく、経営者や主管部署の目に映る価値に従って分割する。タテに切るのではなくヨコに切る訳だ。たとえば、管理連結会計システムの導入であれば、�〃郤，任亮太嗜�結の実現�∋匆饉劼隆雋乾轡好謄爐箸寮楝貝�制度連結との差異調整を支援する仕組みの導入�ね住擦力�結処理のシステム支援、といった具合である（これは一例であり、同じ領域でも場合によって分け方は異なる）。そうした上で、これらのゴールをひとつずつ段階的に実現するシナリオ（＝全体計画）を描き、その中の第一ステップについてだけ契約するのである。お客様としては経営者から「全部で結局ナンボになんねん」と問われるので、すべてを実現した場合の総投資額を提案書に記載することもあるが、これは概算でありあくまで参考値であることを明記する。契約はあくまで第一ステップだけにする。第一ステップの投資額が全体投資の中でかなり小さな割合を占める水準（たとえば３分の１とか５分の１）になるように、プロジェクトを分割することがポイントだ。
次に、第一ステップの契約内容だが、ここでのポイントは、�ー存修任�る自信のある見積り金額を提示する反面、�△修慮�積り金額は契約上のコミットメントでは無いことをはっきり示す、ということである。この段階でシステム要件が緻密に定まっていることはほとんどなく、工数とコストについては厳密には積算できないので、以前の経験を踏まえ今回の特有な要素も考慮したうえで見積もる。とはいえこれは、「参考値」ではなく意思の入った数字である。過去の経験からみてこの金額で収めることができるということに、受注側である僕たちがまず自信を持っている必要があるし、お客様にもそういう数字であることを理解して頂く。その一方、契約書上では、工数とコストはコミットメントではなく、上下にブレた場合には実績精算することを明記する。「事実上のコミットメント」だが「契約上のコミットメント」ではない、ということだ。自信があるなら契約書上もコミットすればいいじゃないかと思われるかもしれないが、それをあえてしないところがこの方式のミソである。
この簡単なスキームが、たいていの場合うまく機能する。まずお客様の視点に立つと、小さな初期投資でビジネス上の意味がある成果を挙げることができる点がメリットの第一である。なんといっても経営者や他部門に説明し易い。また、小規模の投資でスタートすればリスクを小さくすることができるし、後で軌道修正するのも容易だ。じっさい、上記のスキームを採ったケースでは、第二ステップ以降について、当初提案したステップが粛々と実行されていくことはまず無く、ひとつのステップが終わるごとに次以降のステップを見直す（お客様が見直したくなる）ことの方が普通である。
次にもっと大事なのは、お客様の視点からみて我々の側が一生懸命働くだろうと信頼できる仕組みがビルトインされているということである。総投資額が大きくて、第一ステップではその一部を発注するに過ぎないと我々が知っているということをお客様が知っている。だからお客様としては、第二ステップ以降も受注すべく、第一ステップで良い仕事をしようと我々が努力するであろうことを（実際、そうなのだが）信頼できるのだ。お客様からすれば、第一ステップの契約金額が固定されていないことについては不安も感じるが、あえて当初の見積もりを超えて実績工数をどんどん上積みし、お客様の信頼を失い第二ステップ以降を失注するという「暴挙」を我々がとるだろうか、と考えればその不安も緩和される。
逆に我々の視点に立つとどうだろう。まったく未知のお客様と仕事をすることは我々にとってもリスクのあることだ。あまり規模の大きくない第一ステップで、このお客様と働くということはどんな感じがするものか、確かめてみることができる。これがメリットの第一だ。次に、せいいっぱい良い仕事をすることが次の仕事につながるのだという認識が我々の中で育てられる。これは働く者として幸福なことだと思うし、組織が健全な方向に育つことの支えになる。最後に、契約金額が固定されていないということは、仕様とスコープについてお客様といつでも話し合える枠組みが用意されていることでもある。実現しようとしているビジネス価値にあまり関係のないところで仕様やスコープが膨れ上がっていると我々が感じたときには率直にその旨を話し合える。また、お客様が、個々のシステム仕様ではなく達成すべきビジネス価値にフォーカスして下さることに、我々の側としても確信がもてる。こういったわけで、このスキームは全体として、お客様と我々のチームのベクトルを合わせ、信頼関係を育むことに役立つのである。
なんだ、こんなやり方なら簡単だと思われるかもしれない。実際にやってみると、お客様のビジネス価値の視点からプロジェクトを分割するという部分がなかなか難しいことに気付いて頂けるだろう。また、第一ステップの見積もりもかなり難度が高い。お客様からのRFPにしたがって積算するのではなく、これくらいの仕様で、これくらいの工数・コストで出来るだろうということを相当の確信度で見通す必要があるからだ。だから契約書の細かい条件の詰めには手がかからない反面、その前の段階では手数がかかるし経験も要る。しかし、僕としてはリスクの負担について契約書上で細かく細かく記述していくことよりも、こちらに時間とコストを掛けた方が生産的だと感じるのだ。最近、システム関係の雑誌などを読むと、契約書を厳密化していく流れがあるように感じられる。僕もそれ自体には反対ではない。ある種のことがらについては、契約書作成時点で十分な検討をすれば実行時のリスクを減らせる。こういったことがらについては十分検討して、契約書に織り込むべきだろう。しかしそうではなく、契約時点でいくら緻密に文言をひねってもリスクの総和が減らないようなことがらもある。この種のことがらについては、ゼロサム・ゲームの世界でどちらがリスクを負担するかというせめぎ合いはほどほどにしておいて、なんとかプラスサム・ゲームに転化できないか、という視点が必要なんじゃないのかなあと思うのである。
