工事進行基準を分かりやすく解説してみよう【対応編】：顧客との契約がポイントに

[垣内郁栄，@IT]

　システムインテグレータ（SIer）や受託ソフトウェア開発企業が工事進行基準を適用する場合、どう考えて、何を改善すればいいのか。これまで「どんぶり勘定」との指摘もあった業界で、短期間で対応するのは簡単ではない。しかし、進行基準に対応することで業務の質が向上し、効率が上がるというメリットもある。「工事進行基準を分かりやすく解説しよう【基本編】」と同様に、ベリングポイントのシニアマネジャーで公認会計士の山田和延氏に解説してもらおう。

契約で完成形を顧客と合意

　ベリングポイントのシニアマネジャーで公認会計士の山田和延氏

　進行基準を適用するプロジェクトでは、まず何を行わなければならないのか。それは完成形を顧客と合意することだ。システム開発、ソフトウェア開発ではあらかじめ完成形をきっちりと決めずに、開発しながら形を固めていくことがある。しかし、これでは【基本編】で説明した3つの条件を満たすことができない。

　だが、ERPの導入など全社に対して段階的に導入するシステム開発もある。このような場合は「基本的にはステップに分けて別契約にする必要がある」（山田氏）。細かなステップで別契約にしておけば、あとになって全体の完成形が変わっても対応できる。

　契約を分けるとは単に書類上で分けるだけではなく、「その契約単位でお金をきちんともらえること」だ。その契約は別の契約内容に引きずられてはいけないし、独立していないといけない。また、仕様が変わる場合も、その仕様変更によって追加請求ができるのかを顧客側と詰めておく必要がある。契約によっては開発側がその追加費用を負担し、原価が増えるケースもあるし、顧客側が負担して収益総額が変わるケースもある。開発後の改修などのコスト負担も決める必要がある。いずれにしても契約をベースにしないと客観的な進行基準の適用はできない。

　契約は進行基準適用のポイントだ。SIerがこれまで一部で行ってきた契約方法は、進行基準では通用しなくなる公算が高い。要件定義や開発、テスト、サポート、ハードウェアを組み合わせた一式契約、複合契約はNGだ。システム開発では、要件定義や開発、テストと、段階ごとに契約を分けるのが基本。ハードウェアは納品時、保守はサービス提供期間中など、進行基準とは売上計上のタイミングが異なる。そのため一式契約や複合契約は行わずに「基本的には契約を分けるのが望ましい」（山田氏）。無償保守や正式な契約前の開発スタートも進行基準を適用する上では「厳格な手続きを必要とする」と山田氏は語る。

丸投げができなくなる

　これまで開発側の対応を説明してきたが、進行基準を適用するためには顧客側の対応も必要になる。一式契約や複合契約が不可能になるため、いわゆる「丸投げ」ができなくなる。開発側と顧客側が事前にきちんと契約を結び、開発の完成形を共有することが進行基準適用のベースになるからだ。山田氏は「少なくとも要件定義と開発は契約できちんと分ける必要がある」と指摘している。

　原価割れの赤字プロジェクトという問題もある。「原因は成果物を明確に定義していないから。金額も曖昧になり、思ったよりも工数がかかってしまう」（山田氏）ことだ。売り上げを最後に計上する工事完成基準と異なり、完成形を定義して、決算期ごとに計上する進行基準では赤字自体が減ることが予測される。しかし、突発的な事故で赤字が発生することもある。山田氏は、「進行基準でどうしても赤字が発生した場合は、分かった段階で引当金を充てるようになる。赤字が分かる体制を築く必要がある」と話す。

バケツリレー式で下請けの進捗を管理

　SIer特有の問題としてはほかに多重請負もある。あるプロジェクトに対して進行基準を適用する場合、当然下請け企業の進捗も含めて費用を管理する必要がある。多重構造になっていても、基本的には元請けは一次請けから進捗の報告を受け、一次請けは二次請けから、二次請けは三次請けから進捗の報告を受けるようなバケツリレー式で情報を管理する方法を採る。「当然、情報伝達のスピードは落ちるので伝達体制を整える必要があり、多重下請けは基本的にやりにくくなる」と山田氏は見る。

　進行基準を適用することで工期管理、労務管理が適正になりサービス残業が少なくなることが期待できる。山田氏は、業務のムラや無理を下請けが吸収する従来の仕事の仕方が進行基準によって通用しなくなり、「徐々に業界が変わっていく流れが出てくれば」と話している。

まずは社内の承認体制の確立を

　「来年4月に向けて、まずやらないといけないのは社内の承認体制だ」と山田氏は説明する。「（見積総原価や進捗度が操作可能なため）進行基準のデメリットは客観性と確実性。それをカバーするには第3者の目で承認を判断する必要がある。契約が正しいか、金額が正しいかをチェックする社内の承認体制はわりと早く構築できる」ことが理由だ。

　さらにSIerや受託ソフトウェア開発業界は「品質管理が組織的に行われていない」と指摘する。個人の能力に依存する面が強く、成果物やプロジェクトマネジメントの質に偏りが出るケースが多いという。進行基準を適用し、厳密に進捗を管理するには組織的な品質管理が必須で、山田氏は「数年かかるのは間違いないが、やっていかなければならない。組織的に管理できるようになると業界としても成熟してくる。すでに組織的な管理の取り組みを始めている建設業も参考にできるだろう」と話している。