前々回、「工事進行基準」ということを書いたが、この「工事進行基準」というのは、SI（システム・インテグレーション）案件などで、プロジェクトの進捗状況に合わせて売上を“分散計上”するという会計処理のことである。
現行は「完成基準」といってシステム開発が完了し検収書を受け取ってから売上を計上する。この「完成基準」から「工事進行基準」への変更が2009年4月から行われるというのである。この方式は、すでに建設業やプラント・エンジニアリング業の会計処理に採用されている。だから、この変更はソフトウエア業界もたいしたことではないと思いがちであるが、実は大変なインパクトを与えるのではないかと思う。
工事進行基準だと、プロジェクトが始まる前に売上と収益が確定していなくてはいけない。これは今のSIerにとってはかなり難しいことなのです。売上もさることながら、収益もですから、原価がちゃんと見積もられていなくてはいけないのだ。
いまのおおかたの会社のやり方はプロジェクトの始まる前はだいたいのことを決めておいて、終わったあとお客さんとのあうんの呼吸で売上と収益が決まるという非常にあいまいなやりかただ。だから、最初の仕様は厳密なことはしないし、きちんとお客さんの承認ももらわないでやる。
そんなことだから、必ず仕様変更や追加が発生し、これは最初の仕様に入っていたはずだとかいや入っていないだとかやり合うことになり、どっちかが泣くことになる。どちらかというとお客さんのほうが強いからSIerの方が泣くのだが、その泣いた分は下請け、孫請けにしわ寄せがいく。
なぜこういうことになっているのだろう。従来からの染み付いた悪しき慣行や業界体質という問題もあるが、ソフトウエアであるがゆえの問題もある。
どういうことかと言うと、先ほど例をあげた建設業やプラント・エンジニアリング業などでは、出来上がりのイメージがつきやすい。どんな建物やプラントができるかがだいたいあわかるので、完成品や進捗状況がつかみやすいといえる。それに対して、ソフトウエアは見えないのだ。作ってみないと分からないし、今どのあたりまで進捗しているのかもわかりずらい。ここが他の業界と大きく違うところである。
そうなるとみな口をそろえて言うのは、「顧客との厳格な契約と正確な原価見積もり，精緻なプロジェクト管理などが必要だ」となる。それができりゃ苦労しないよという声も聞こえてきそうだ。そうなんですね、今のやりかたで管理強化すればいいやとう話ではないような気がする。もっと抜本的な改革をめざし、システム開発やプロジェクト管理のやりかたをゼロベースで考え直すことが必要なのである。
すなわち、顧客の要求と仕上がりのマッチングを事前にイメージできる“もの”を持たないといけない。そのためにはコードを書いてはダメだし、変更が容易にきくようにし、素早く作り上げるということが非常に重要である。これからはそういうフレームワークを用意する必要がある。「BPWeb2.0」はそういうフレームワークなのである。
ともあれ、この「工事進行基準」への変更は、単なる会計処理の基準が変わるというだけではなく、システム開発、プロジェクト管理のやり方が大きく変わっていく、いや変わらざるを得ないようになると思う。いままで「パラダイス鎖国」を謳歌していたわが国SIerの淘汰や変革をもたらすかもしれない。そんな予感もあながちおおげさではないような気がするのである。