アイロベックスメールマガジン　携帯版

来年、2009年の4月から、システム開発会社も「工事進行基準」会計を求められるようになりました。
日経BP社やマイクロソフトなどで、工事進行基準に関するセミナーが大流行です。
そこで、今回は「工事進行基準」について考えます。

これまでの会計処理は、「工事完成基準」会計でした。
つまり、システムが完成して、納品、お客様の検収により、売上計上してきたわけです。

もちろん、すべてのシステムやプロジェクトにおいて、作業開始から終了、売上日までが、1年間という会計期間の中に、きれいに収まってしまえば、特に問題になる処理はありません。

しかし、すべてのプロジェクトが、期末に終わっているということは、あり得ないわけです。

この場合、売上できないプロジェクトについて、つまり、当期中に売上しないプロジェクトに掛かった労務費（SEやプログラマの給料）は、仕掛品という、在庫と似た意味の、資産勘定科目を用いて計上し、売上原価とはできませんでした。

こういう会計処理を行うと、通常は、売上月（期）に多くの利益が出ることになります。

なぜなら、2年掛かりのシステム開発では、最初の期は、売上も売上原価も発生しません。
ひたすら労務費という費用がそのまま、仕掛品という資産に代わっているだけです。
それが、売上期には、売上金額が全額計上され、仕掛品が売上原価に振替えられるからなのです。

実際には、企業の経営といった側面から見れば、売上のタネは労務費だけではありません。
技術者の教育費、福利厚生費用、水道光熱費であったり、家賃であったり、営業費用なり、そのプロジェクトが、分担すべき販管費は、もっと多くあるのです。

売上を計上した期に、その売上を生んだ元となる直接の費用と、間接の費用すべてが計上されてこそ、正しい会計となるわけなのですが、そうなっていないわけです。

そこで、大規模なシステム開発があった場合には、特に利益が正しく計算されない、ということになってしまうのです。

単純に考えれば、最初の期は、利益が少なく評価され、次の期の、売上があった期に利益が過剰に評価されるということです。

しかし、システム開発では、プロジェクトによっては、納品後（検収後）に多くの問題が出ることもあるわけです。

この場合、例えば、3期に渡るプロジェクトについて、考えてみましょう。
1期目は、仕掛品計上のみなので、利益が少ない状態、2期目は、期末月に売上があったとすると、利益が大きく出る状態となります。

そして、翌月から、納品後のトラブルに追われてしまったとなると、3期目は、売上のない、原価の垂れ流しということになります。

これだけが原因というわけではないのですが、こういった会計では、外側から見た場合に、この企業が優良なのかどうかが、わかりにくくなるわけです。

また、この売上や利益の構造が良くわからないことを逆手にとり、「売上や利益をごまかす」といったことが、上場企業でも行われていることが何件か発覚しています。

・ニイウスコー
http://www.tokyo-np.co.jp/article/national/news/CK2008050102007972.html

・アスキーソリューションズ
http://www.nikkei.co.jp/news/main/20080428AT1G2700P27042008.html

・アクセス
http://www.yomiuri.co.jp/national/news/20080428-OYT1T00347.htm

一方、システム開発の仕事と、非常に似ていると言われる建設業界では、「工事進行基準」の会計が、ずっと行われてきているのです。

そこでIT企業が、投資家から、「正しい企業の業績」を判断されるためにも、グローバルスタンダードである「工事進行基準」での売上処理が求められているというわけなのでしょう。

下請だから関係ないとか、小さな案件の仕事しか行っていないから関係ないというわけではなく、わたしたちの業界の仕事が、どのように会計処理されるべきなのか、その為には、どのようなプロセスを経て、作業をしていかなければならないかを知り、実行していくことは、緊急に求められていることなのです。

前回は、工事進行基準会計が求められるようになった背景について、述べました。

長期請負工事に関する収益の計上については、これまでは「工事進行基準」または「工事完成基準」のいずれかを、選択適用することが認められてきたので、ほとんどの会社が「工事完成基準」を選択してきたわけです。

「どんぶり勘定」と呼ばれるようなシステム開発の請け方には、工事完成基準が一番合っていたというわけです。
ところが平成20年4月からは、工事進行基準に会計基準が統一されることが決定しました。

では、工事進行基準会計をどういう方法で行えばよいのでしょうか？

工事進行基準会計の先駆者である「建設業界」のシステムを得意とする、当社取締役の小幡に聞いてみました。
（以下、聞いた話です）

「建設業界では、工事進行基準における進捗度は、出来高という考え方が一般的です。
工事を請け負ったときには、工程別の実行計画と連動した、”実行予算計画の入力”を行います。
そして毎月、工事現場監督が完成度合いを、出来高（金額またはパーセンテージ）として査定し実績とするのです」

そして、こうも語ってくれました。

「しかし、工事の進捗で形あるものが出来上がっていく、ビルやプラントならともかく、
形が見えず完成できなければ意味をなさないソフトウエア開発において、出来高を明確にして、どこまで完成しているかを管理することは、非常に困難です」

「同じようにITの場合においても、各工程での成果物をあらかじめ数値で明確にしておき、設計工程であれば、ドキュメントが何ページ完成したのか、製造工程であれば、プログラムが何機能を完成したのかを
完成度合いを査定できる能力のある人間が査定することになるのだろうと思います」

なるほど、確かに成果物が何ページ、プログラムが何ステップと、予測できるのであれば、その数値を入れておいて、何パーセント出来上がったのかを測ることは出来そうです。

しかし、建設業界と違って、要件定義、基本設計、どの部分においても何ページ作ったら終わり、
何ステップ作ったから何パーセントということは予測はできません。

プログラムを大きく機能単位に数えることはできても、何ステップまでなどという予測はできそうにありません。

しかもプログラムの場合は、最後の機能が完成してみたら、「基本部分に仕様漏れがあったので、大きく改修しなければならない」ということさえあるわけです。

せいぜい、基本設計書の成果物を細かく分類して、「画面設計書」「帳票設計書」「ビジネスルール定義書」などと、分けて作業成果単位とするのでしょうか。

ところが、企業会計基準委員会（ASBJ）では、進捗を計るのに、建築業界と同様に「原価比例法」を挙げて、推薦しているのです。

----ちなみに、原価比例法とは----------------------------------------
決算日における工事進捗度を見積る方法のうち、決算日までに実施した工事に関して発生した工事原価が工事原価総額に占める割合をもって決算日における工事進捗度とする方法をいう。
（企業会計基準公開草案第20号「工事契約に関する会計基準（案）」より抜粋）
--------------------------------------------------------------------

もうおわかりでしょうが、実際の発生原価をもって進捗を知るためには、契約からして実質的な正しい見積りに沿ったものである必要があります。
契約範囲や作業分担を明確にすることが確実に必要になります。

「なんでもやります」といった営業は、あり得ないというわけです。
また、成果物も細かく精査される必要があるでしょう。

そして当然のことながら、実際の原価がそのまま進捗度になるのは危険すぎます。
原価の累計が必ずしも出来高（完成の度合い）となるわけではないからです。

そこで出来高（進捗度）の実績値を登録し、計画値と常に比較することになります。

値はパーセントでも、工数（時間）でも、金額でも良いでしょう。
つまり、信頼性をもって工事原価総額を見積ることが重要となり、そのためには、工事原価の実行予算計画が実際に発生した、出来高と比較できる形のシステムまたはツールが、
必ず必要になるわけです。

また、実行予算計画も随時、見直しが行われることが、必要になるわけです。

だからといって、予算超過してしまった増額分を、お客様に転嫁できるわけではありません。
あくまでも、システム開発の損益を、会計基準にのっとってスタンダードで処理するということが、
求められているのです。

これからは、完成基準の適用も全く無いわけではありませんが、契約書において「なぜ完成基準なのか？」の正しい記述が、必要とされるようです。

ちなみに、「日経ソリューションビジネス5月15日号」によると、元請け企業が下請けから集めるデータは2つだと言っています。

・開発のコスト
・開発作業の進捗率

これは、ほとんど元請けが必要なものと同じではありませんか？

結局、「自社と同レベルのプロジェクトマネジメント体制を求め、進捗の実態を把握するのが基本である」とも書かれています。

要するに、すべからく、システム開発会社は、この考え方に慣れ、ノウハウを身につける必要があるというわけです。

先週、東京ビックサイトで「ソフトウェア開発環境展」が開催されました。
毎年、情報収集のために訪問しているのですが、今年は、出展社数も多く、内容もずいぶん充実していたような気がします。

当社は、システムの受託開発が主な仕事となります。
システムにおいて、画面入力の作業は、非常に重要な部分を占めています。
自社の開発したシステムはいつも見ていますが、他社の仕事を見せていただいたり、操作したりする機会はそう多くはありません。
そういった意味もあって、展覧会に行って、他社が開発したシステムを見せていただくのは本当に楽しみです。

展示されている各社の画面設計を見せてもらい、簡単な質問をさせていただきます。

システムの機能もさることながら、
どんな画面設計をしているんだろうか？
デザインはどんな風に凝っているのか？
操作性は良いだろうか？
といったところが興味をもつ部分であるわけです。

当社には、専任のグラフィックデザイナがいることもあって、ソフトウェア開発会社としては、デザイン性が良いものを提供しているという自負が、多少、ありました。

しかし、今年のソフトウェア開発環境展へ行って、本当に驚きました。
各社、かなりデザイン性にも優れ、且つ、操作性も追及したものが出ていました。

特に目についたのが、Ajax(エイジャックス）※ を用いた画面プログラムでした。

-- ※Ajaxとは ------

Webブラウザに実装されているJavaScriptのHTTP通信機能を使って、Webページのリロードを伴わずにサーバとXML形式のデータのやり取りを行なって処理を進めていく対話型Webアプリケーションの実装形態。
（IT用語辞典より http://e-words.jp/w/Ajax.html）

--------------------

ご存知のように、Webブラウザ上で動くシステムにおいて、これまでは、クラサバのような画面操作性は求められていませんでした。
それは、Webプログラミングの標準といった考え方でもありました。

操作性を良くするために、FLASHを使用することを考えている会社もあるようでした。

ところが、近年、Ajaxが当たり前のように使われるようになりました。

確かにgoogleアプリケーションなどで、Ajaxに慣れてみれば、直感的に使える、操作に“ぶつ切り”の違和感がないといった良いことばかりが目につきます。

しかし、実際には、システム開発の現場、特にユーザーごとに独自のアプリケーションを開発しているような現場では、まだまだ、全面的にAjaxを使うというところには至っていません。

それは、当社においても、画面操作で、Ajaxは、一部のみ対応している、といったところだったのです。

ところがソフトウェア開発環境展に行ってみれば、右も左もAjaxだらけだったわけです。

世の中の主流が、もうそうなっているのだと、反省致しました。

結局、操作性を追及すると

・プログラム工数が掛かる
・バグが潜みやすい
・最初の画面デザインで、動きをより細かく固めておく必要がある
・どのようなことに、どの位の工数が掛かるのか、また、実現が可能なのか、分かる人が少ない

といった問題がどうしても出てきてしまうのです。

しかし、このIT業界。
そんなことを言っていられない業界でもあるわけです。

大変なことをやらずしてどうする。新しいことに挑戦せずしてどうする。

実際、最初は大変だと思っても、
経験・実績という慣れが助けてくれるのです。
そしてフレームワークをどう作っていくか、だけなんでしょう。
（簡単なことのように言いましたが・・・）

デザインの素晴らしさも同じです。

「こんなもので良いだろう」などと、ゆめゆめ思わず、常に、より良いものを追及していきたいと思うのです。
ただし、生産性は本当に大事です。
良いものであれば、どんな時間を掛けても良いということは決して有り得ません。

要するに、どうやったら無駄な時間、工数を使わずに良いものが出来るのか、です。

少なくとも、Ajaxや画面デザインは、インターネット上で、世界中の会社が作ったものを体験できるはずです。
下記に、Ajaxのデモサイトをいくつか挙げておきます。

・Ajaxのサンプルが山のようにある。サイト自体の作りもAjax。
http://Ajaxrain.com/

・ASP.NETとAjaxのサンプル集
http://jsAjax.com/SamplesByTreeView.aspx

受託開発において、画面のデザイン・操作性はどこまで追及すべきか？
それは、自社の開発レベルを上げていく挑戦でもあるのです。