前回に続いて、システムの受注や契約にからむ諸問題がテーマである。幅広い視点から問題点を探し、できる限りの回避策を考えておかねばならない。
 |
一般にシステムの機能とは、何らかの入力（X）を与えて、しかるべき処理Fを実行し、結果としてF（X）を出力することである。だから、入力Xを変えてみて、常に正しい結果F（X）が出力されることを検証すれば完成ということになる。
この際、Fがきちんと定義されており、かつ通常のSEやソフト開発者にとって容易に機能Fが理解できれば、出力結果F（X）の合否も簡単に判断できるので問題がない。だが、その分野の専門知識を持たないと、機能F自体を理解することができないとか、機能が複雑でどういう結果が正しいのかが簡単には分からないようなシステムでは、プログラムのテスト結果の確認に異常に時間が掛かるので、一括請負はリスクが大きすぎる。
もし結果判定の困難な案件を受注するときには、結果判定が難しい論理部分のテストは顧客に委ね、ベンダーとしては要員派遣契約でテストを手伝うという形が現実的であろう。
 |
長期間使われてきた他社システムをリプレースする場合、一見簡単に見えるバッチ処理プログラムのコンバージョンでも、その量が多ければ要注意である。変更作業自体はできても、変更されたソフトが確実に実務に使えることを確認するのが難しいからだ。確認には現行のシステム仕様が必要になるが、新規参入ベンダーは、現行の業務知識もないし、仕様書を見ようにも整備されてない。顧客に聞いても担当者が代わってしまってよく分からない。
このような状況である以上、新規参入ベンダーが、コンバージョン案件を一括請負契約で安易に引き受けるのは極めてリスクが大きいといえよう。まずは変換移行作業のみを受注し、結果の確認は顧客に頼むか、顧客の指導を受けながら、派遣契約で取り組むという段階契約にしてもらうのが安全であろう。
 |
「損をして得を取れ」といわれるように、新規顧客を獲得するために、ときに赤字案件を受注することもある。メインフレーム全盛の時代は、最初は赤字でも、その後の安定的受注の見込みが立ったので、長い目で見れば意味があった。しかし、今日のオープン時代においては、いつでも、どこのメーカー製品とでも置き換えられるため、ある顧客に戦略的安値受注でなんとか入り込めたとしても、後の受注が期待できるとは限らない。少なくとも粗利も出ないオープン・システムの受注は、戦略受注というより“無理受注”というべきであろう。
無理に受注すると、「赤字をできるだけ抑えよう」とSEは後ろ向きになりがちで、顧客にとっても不満が累積することになる。これは、双方にとってマイナスである。
 |
ある程度の赤字を覚悟してでも新しい顧客から注文を取ろうとすることは当然あってよい。だが、既存の自社ユーザーに対して、普段のサポートが不十分なために知らないうちに競合他社に攻められて、慌てて対応するといった、いわゆる「守り」のための赤字受注は問題である。
このような防衛的受注は、無理な金額のみならず無理な条件にもつながることが多く、ベンダー側が困るだけでなく、顧客の利用部門にも必ずしも満足して受け止められず、結局は良い結果にならない心配がある。
競合他社に攻められてから考えるのでなく、日ごろから顧客とのコミュニケーションに心掛け、早め早めに提案する努力が必要だ。
