〜工事進行基準とは何か？
株式会社ノークリサーチ
従来、情報システム開発は同一製品の大量生産と異なり、オートメーションによる工業化は難しいとされてきた。そのため情報システム開発のプロセスは属人的となり、SIerにとっても、ユーザ企業にとってもノウハウ蓄積が難しかった。また最近では、このようなSIerとユーザ間の認識の相違が問題となるケースも発生している。
そうした状況を受け、与えられた予算と期間で求められた品質を確保するための「SIサービス工業化」への取り組みが法制度整備とベンダ側サービス拡充の両面で進みつつある。
そこで、今回から三回の連載で「SIサービスの工業化」の最新情報を伝えると共にSIサービス工業化の時代へ向けて、ユーザ企業が学んでおくべきことについて述べていく。
「工事進行基準」という言葉をご存知だろうか？
2007年12月に企業会計基準審査委員会が発表した「工事契約に関する会計基準」（企業会計基準第15号）のことを指す。
「工事」というと、情報処理とは全く関係がないことと感じるかも知れないが、この発表は昨年から今年にかけてIT業界に大きな波紋を呼び起こしている。 そしてIT業界で業務に携わるSIerだけでなく、情報処理システムを利用するユーザにも深い関係がある。
実際、ノークリサーチが2008年11月に全国の中堅・中小企業を対象に実施した調査では約半数がこの用語を知っていると回答しており、既に活用しているユーザも1割存在している。
そこで、今回はこの工事進行基準について解説していくことにする。
企業が顧客との受託契約によって何らかの成果物を納入するといった場合、収益/費用の計上方法には大きく分けて「工事完成基準」と「工事進行基準」の二通りがある。
「工事完成基準」とは成果物が実際に納品された時点で収益と費用をまとめて計上する方法である。
一方、「工事進行基準」とは受注から納入までの期間を幾つかに区切り、その期間毎に収益と費用を計上する方法である。
受託ソフトウェア開発の場合、成果物であるプログラムは目に見えづらい。そのため構築期間の長い案件であっても、途中の段階で完成度がどれくらいなのかを評価することが難しい。
その結果、IT業界では工事進行基準ではなく、工事完成基準を採用するケースが大半だった。
ところが先に述べた2007年12月の発表によって、受託開発ソフトウェアにおいても、土木業や建設業と同様に工事進行基準を適用されるようになったのである。
まずは工事進行基準が適用される条件を確認しておこう。工事進行基準は以下の三つが満たされる情報処理システム構築案件に対して適用される。
つまり、案件全体の金額的規模が把握できており、決算日の段階でどれくらいの進み具合であるかがわかっているのであれば、先送りせずにその時点で計上して明らかにしなさいということを意味している。
ソフトウェアは目に見えにくいため、長期に渡る案件の終了間際になって追加の費用が必要になるといったケースも少なくない。工事進行基準を適用することで、そうした不採算案件の発生を未然に防ぐことができる。
当然、ユーザにとっても情報処理システム構築費用の急な増額といったトラブルを減らすことができるなどのメリットが期待できる。
この基準は義務ではないため、工事進行基準を採用しなかったからといってペナルティが課せられるわけではない。
しかし、上記三つの条件は案件管理をきちんと行っているSIerであれば当然求められる事項といえる。そのため、工事進行基準に対応すべく、案件管理の整備活動を進めるSIerが増えているのが現状だ。
かといって、ユーザ側も期間に応じてSIerに対する支払いを分割しなければならないというわけではない。工期の途中で計上された収益はSIerでは金銭債権（一定の金額給付を受けることを目的とした債権）とすることが認められている。
このように工事完成基準から工事進行基準へと移行したとしても、ユーザ側から見れば支払い条件や成果物の内容が変わるわけではない。しかし、SIer側がある程度の「区切り」を意識して情報処理システム構築を行う以上、ユーザ側にも相応の意識改革が求められてくる。
具体例を考えてみよう。
新規に顧客管理システムをSIerに委託して構築することになったとする。SIerは案件の初期段階でユーザ操作画面のサンプルを持参し、「こんな画面と動きで良いですか？」と確認を求めてくるはずだ。
従来は「何だか良くわからないけど大体良さそうだ」という簡単な確認のみで済まし、システム稼動間近あるいは実際にシステム使われ始めた後になって「これじゃ使いにくいので、もっとこうして欲しい」といった要望をSIerに投げかけるといったケースが多々見受けられた。
SIerからすれば当初確認を取ったのとは異なる仕様で再度開発作業を行うことになるため、その分はコスト超過状態となる。それを案件後半の開発費用や稼動後の保守運用費用で埋め合わせていたのである。
工事進行基準が適用されると、上記のような辻褄合わせはできなくなる。
システムの仕様を決める段階、プログラムを開発する段階、運用段階とそれぞれの段階毎にコストを明確にし、段階毎に作業をきちんと完結させる必要があるからだ。
つまり、ユーザ側にはシステム仕様を事前にきちんと確認することが求められてくるのである。
中堅・中小企業では実業務と兼任しながら情報処理システム管理に携わるケースも少なくなく、工事進行基準の適用は中堅企業にとっては負担と映るかも知れない。
また、「ビルは途中から階数を変えることなどできないが、ソフトウェアは形がない。後からいくらでも変更できるだろう」と考えるユーザも依然少なくない。
しかし、近年の業務システムは非常に複雑であり、不用意な仕様変更は業務停止トラブルへと発展しかねない。実際、そうしたユーザ側の無理な要求が引き金となって大きなトラブルへと発展した例も少なくないのである。
事前確認の段階でしっかりと仕様を確認しておけば、その後の開発や運用を迅速かつ高い品質で進めることができる。 また、事前段階でユーザとSIerが一緒になって入念に仕様確認をしておけば、後になって変更の必要が生じた場合でもシステムに悪影響を与えない方策を立案しやすくなる。
このように工事進行基準の適用は多少負担になる部分もあるが、ユーザにとっても少なからぬメリットがあるといえるだろう。
それではユーザとしては具体的に何をすれば良いのか？
まずは上に述べたように情報処理システム構築の初期段階での仕様確認をしっかり行うことが求められてくる。そのためには「今はどの段階なのか？」をユーザ側が把握できていることが必要だ。
そこで次回は情報処理システム構築案件の各段階を表す「フェーズ」について解説していくことにする。
情報処理システム開発には「要件定義」「設計」「開発」「テスト」「運用」といったステップが存在する。このステップは「フェーズ」と呼ばれ、今後ユーザが自社の情報処理システム構築を成功させ、SIerとの良好な関係を築くためには必須の知識である。
ユーザの視点からの「フェーズ」をわかりやすく解説する。
工事進行基準などのルール、そして情報処理システム開発の「フェーズ」を理解することによって、ユーザ側の情報処理システム構築スキルは大きく向上する。しかし、こうしたスキルをきちんと社内で共有しておかないと、同じミスを繰り返してしまうことになる。
ここではノウハウ蓄積と共有のノウハウについて解説していく。
