紛争勃発に備えよ！──受け入れ検査時のトラブル対策：企業システム戦略の基礎知識（10）（2/2 ページ）

[青島 弘幸，＠IT]

“過失相殺”の概念を取り入れる

　欠陥と仕様変更は必ず発生する。欠陥の場合は、業者側に修繕義務や損害賠償責任が発生する。仕様変更の場合は、発注側に追加発注という費用負担が発生する。

　そこで両者の過失を相殺するというのは、いかがだろう。つまり、欠陥に対する損害賠償費用と仕様変更に対する追加費用を相殺するのである。できれば、問題が発生してからではなく、最初の契約時点で取り決めをしておけば、欠陥や仕様変更を抑制する効果も期待できる。

　業者にとっては、欠陥を多発すれば、本来は仕様変更で追加費用を取れるものも、取れなくなってしまう。また、発注側にとっては、欠陥に対する損害賠償を請求できるところも、仕様変更によって請求できなくなってしまう。欠陥が少なく仕様変更が多ければ、発注側に余分に費用が発生するし、欠陥が多く仕様変更が少なければ、業者側に余分に無償作業が発生する。そのようなルールを最初から分かっていれば、損しないように気を付けようというのが合理的な判断だ。

　それでも、やはり仕様変更か欠陥か、調整がつかないようなことがある。こじれてくると双方が意固地になり、もう理屈ではなくなってしまう。平行線をたどってムダな時間を浪費するより、どうしても必要な機能ならば、改修に必要な費用を折半するなどして紛争を回避する道を探った方が得策だ。とにかく、プロジェクトを前に進めて、システムを使えるようにするという本来の目的を忘れないようにしたい。

“欠陥”は業者だけの問題か？

　システム構築は住宅建築にたとえられることが多いが、この業界でも施主と建築業者間のトラブルは尽きない。昔から「家は3回建ててみないと分からない」ともいわれており、多層下請けの業界構造や悪徳業者による欠陥住宅被害などを指摘する書籍や雑誌記事も多い。

　欠陥住宅防止のポイントは、業者に任せきりにせず、主体性を持って適宜チェックを入れること、そして第三者の専門家による検査を実施することだとされている。また、業者に無知を付け込まれないように、ある程度の勉強は欠かせない。システム構築でも同様な対策が必要だ。

　欠陥が多く、トラブルの発生しているプロジェクトの要件定義書や仕様書を見ると、たいてい分かりにくい。分かりにくいだけでなく、要求事項などに矛盾があったり、一貫性に欠けていたりする。要するに、読み手に気を使っていない、独り善がりな内容なのである。自分たちの「常識」だけを前提に説明がなされており、各種の省略や暗黙の了解が散見される。そういう手合いに限って、「仕様書の書き方など、専門家ではない自分たちは勉強する必要などない」と考えていたり、自分たちが使っている業務用語の矛盾や不整合に無頓着だったりする。はなはだしきに至っては、そもそもの業務に矛盾や不明確な部分があり、しかもそれをそのままコンピュータに載せようとすること自体に無理があるということに気が付かない。業務のバグは、コンピュータ化してもバグなのである。

　「質の良い仕様書」とは、どんなものかいま一度、確認しよう。業者は、基本的にはコンピュータの専門家であって、業務・業界の専門家ではない。業者の業務知識を当てにするのは、はなはだ危険である。にもかかわらず、ユーザー企業側では主体的にシステム構築に関与せず、業者に任せきりにしているケースは少なくない。

【関連記事】
【急がば回れ──質の良い仕様書の作り方】連載：企業システム戦略の基礎知識（4）（＠IT情報マネジメント > 情報化戦略・投資）
連載：“街づくり”で理解するシステム構築入門（＠IT情報マネジメント > 企業システム構築）

第三者による監理、助言は有効

　先に述べたように建築と同様、システム構築でも第三者の専門家によるチェックは有効である。

　コンピュータの専門知識においてユーザー企業は弱者だ。例えば、ハードウェアならば業者から「レスポンスを確保するためには必要です」といわれれば、高価であるとは思いながらも購入するしかない。ソフトウェア開発でも「その機能の実現はムリです」といわれれば、あきらめざるを得ないだろう。要求仕様の漏れやミスを事前に指摘せず「仕様書どおり」に作りましたと知らん顔の業者もいる。そのように後で仕様書の漏れに気付いた場合は、やはり追加費用を用意して改修することになる。

　もちろん、業者と対等に渡り合える技術力を持つのが理想であるが、ITの高度化もあり、「餅（もち）は餅屋」と割り切ることにも利がある。ユーザー企業で本業とは関係の薄いIT技術者を、業者と同等のスキルになるまで保持・育成するのは大変なことだ。いわば建築業者と同じ知識を、施主が身に付けてから家を建てよというのと同じである。

　こうしたことを考えると、やはり第三者による監理や助言が有用だろう。これには、ユーザー企業の立場で考えつつも、業者から独立した第三者として公平な立場でのチェックと助言を与えることができ、結果としてユーザー企業と業者との良好な関係を築けるような人材が理想である。

　システム構築の企画から運用までの全工程にわたり助言を与えることができる専門家として、ITコーディネータ協会のITコーディネータ制度がある。そのほか地域振興センターなどでも、IT化支援を目的とした専門家派遣事業を展開している。こういった支援制度を利用して、業者任せではなく、主体性を持ったシステム構築を実施するべきである。

　また、このような制度を実効性のあるものにするために、建築士法や建築基準法と同等の法制度が、システム構築に対しても整備されることが望まれる。これだけ欠陥住宅ならぬ欠陥システムが社会問題化しているのであるから。

　次回は、運用試験に関して解説していこう。

【リンク】
「経営者のためのITコーディネータ活用術」ページ（ITコーディネータ協会）
「ITコーディネータ顧問制度」ページ（日本ITイノベーション協会）

著者紹介

▼著者名　青島 弘幸（あおしま ひろゆき）

「企業システム戦略家」（企業システム戦略研究会代表）

日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者）

大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。

「システム構築駆け込み寺」を運営している。

メールアドレス：[e-mail]