ビジネスとしてのソフトウェア開発？

　ソフトウェア開発案件を外部の開発業者に任せたいとき，スコープの確認は大変重要であることを再認識させられた．発注者側が開発仕様書を書いたとしても，それが伝わらない事態というのがある．発注者としてのわれわれが当然の作業と思っていたことが，開発業者では当然ではないらしい．よくSLA（サービスレベルアグリーメント）が重要というが，作業前にこれをよく決定しておかないといけない．しかし，事前の決定といってもやはり決定事項というのは変更される場合や追加される場合，後で明示される場合は多々あって，最終的にはあらかじめの契約金額に対してどれだけ誠実にワークをしたかということをもって，発注者も開発者も納得してプロジェクトを終了するということに尽きるのであろう．
　これがビジネスのこととなった時，どうも性善説では語れない何かがあるのかもしれない．開発業者は意図して誤解を生じさせてプロジェクトを混乱させ，また平然とプロジェクトを立て直す．発注者側の意思決定は，プロジェクトが終了するまで続く．発注者側の意思決定は包括的にはプログラムのような形式的完全系を細部までは持っていないので，必ずどこかで不整合が生じる．この不整合を顧客のミスだと指摘して，追加作業として位置付けて追加料金を請求する．これを受け入れない顧客は，顧客の目的である最終プロダクトを調達できない．当然だが，プロジェクトがとん挫すれば開発者も契約不履行で料金を請求できない．さて，このビジネススタイルは一般的なものとなり得るのか．長期的に見た場合には，このようなビジネススタイルは顧客への信頼を失い，ブランドの低下をもたらすのではないか．

仕事の切り分け

　ソフトウェアを開発するときの仕事の切り分けについて考えてみる．我々はいわゆるサービス提供者として位置づけられているので，基本的にはサービスの仕様を決定することが主たる仕事となる．サービスをどう実現するかは，それをうけて開発する業者に任される．しかしながら，時間的制約から，われわれ自らがサービスを構成するシステムをいくつかに切り分けて複数の業者に同時間的に発注を行うことがある．これにかかる大きな制約は，国の税金を使った事業である場合の金額規模に応じた事務処理の量に起因する．金額が大きくなれば受注者の公平性を担保するために，より発注手続きに時間をかける．システム開発そのものが大規模・短納期を要求するならば，いっそのこといくつかに仕事を分割してしまえばそれで容易に大規模と短納期を実現できると思うかもしれない．ところが，ソフトウェアシステムは，分割すればするほどシステムインテグレートにかかる労力を増大させてしまう．
　ことの複雑さは，仕事によって切り分けられたサブシステム同士をどのようにつなぐか，つなぐとしたらどの業者がサブシステム間インタフェースの接続方法に対して責任を持つのかということのネゴシエーションを要求する．我々の経験では，ネゴシエーションは，仕事の押し付け合いとなるのがどうも基本的な展開らしい．融通をきかせるというのは，ビジネス上個々の業者間ではありえなく，むしろ仕事を分割した発注者しかそのインセンティブを働かすことができないのかもしれない．
　発注者サイドとして，分割した仕事のインテグレーションをどのように実現するのか，その役割分担方法は2つある．ひとつは発注者自らがインテグレーションに必要な設計に手をかける方法，もうひとつはもっともシステムインテグレートを高次のレベルで実現する仕事を担う業者が行う方法である．いずれにしても発注者がネゴシエーションの主導権を発揮しなければならない．