情報サービス産業における経営上の問題点
情報サービス産業
取引慣行が経営行動や会計に対して大きな影響を与えている
経営活動の不確実性を高め、会計の機能を正しく作用することを妨げる可能性が高い
Ⅰ 会計が抱える問題と経営が抱える問題の整理
『情報サービスの財務･会計を巡る研究会』の設立趣旨
情報サービス産業における適切な開示をいかに行うかを議論し、もってどう産業における会計基準のあり方について提案を行うこと
既存の会計手続きを情報サービス産業の経営活動に照らし合わせて整理し直し、経営状態を十分に反映させることができる会計原則を整理して提案すること
会計
経営の写像
実行された経営活動を会計数値に置き換えることによって、各種の利害関係者に経営成績（および財政状態）の実態を開示しようとするもの
開示された会計情報が不適切である原因
①悪意をもって真実の状態をまげて報告を行う場合
→会計の問題ではなく、むしろ経営上の内部統制の問題
②実際の活動を適切に会計数値に置き換えるための会計基準あるいは会計原則が完備されていない場合
→情報サービス産業における取引形態と、これを開示するための会計制度が不整合を起こしているような場合
⇒会計制度を拡充したり、さまざまな会計原則を適用しやすいように整理していけばよい
＊情報サービス産業の経営の特殊性
契約が締結される前にシステムやソフトの開発が開始されることが多い
↓この場合
当該開発のために支出された費用
棚卸資産とされるのか費用あるいは損失とされるのか
→システムの開発契約が結ばれるまで確定しない
＊副次的な問題
売上高を基準とした競争
→収益性を度外視した受注が行われている可能性
⇒情報サービス産業の業績を悪化させ、また売上を過大に計上するために不正が行われる可能性を生むといった問題の源泉となる
③開示する実体が不鮮明、経営自体が不健全
→会計フィールドの問題ではないことが多数ある
Ⅱ 情報サービス産業における取引慣行
情報サービス産業におけるシステムの開発手順
システムの方向性･システム化計画が策定された後に要件定義
↓
これにもとづいてシステム使用が決定
↓
システム仕様が決まれば、ソフトウェア仕様が定まる
↓
プログラミングの開始・完了
↓
ソフトウェア仕様を満たしているかどうかについてソフトウェアテストが行われる
↓
要件定義について要求が正しく実行できるか否かについて運用テストが実施
↓
最終的にシステム全体の評価が行われる
それぞれのステップごとに、定義された機能や仕様が満たされているかどうかを確認
→不十分
1つ前のステップに差し戻しが行われていく
問題点の原因
原点となる要件定義が曖昧にしか行われないことがあまりにも多い
情報サービス産業
ユーザーが持つ希望というのは極めて漠然としたもの
製造業
ユーザーが製品に対して求める機能あるいは役割は明確
例）製造用の設備機械を購入する場合
どのような製品をどの程度のコストをかけてどのくらいのスピードで生産を行うか
→発注をかける際に明確になっている
情報システムの場合
こうした点は明確ではなく、漠然とこうしたことができればいいという程度のもの
→ベンダー側がそれを解釈しながらソフトあるいはプログラムレベルに落とし込んでいく
＊両者の解釈が異なる
システムテストや運用テストでNGが生じて差し戻しが起こり、これによって工数の増加やこれに伴うコストアップが生じる
＊システム開発が進んだ段階で、ユーザー側から新たな要件や仕様が追加掲示される
→付加したりシステム全体において調整を行うことによって、やはり追加工数が生じたりコストが発生する
問題を増幅
要件定義が曖昧
→契約が締結されることなくシステム開発が一部開始されてしまう
原因）
納期が非常に厳しいこと
契約が締結されることなくシステム開発が一部開始されてしまうこと
慣行
システム開発のために支出された金額が仕掛品となるのか、あるいは将来の損失となってしまうのかも明確ではなくなってしまう
物的財である製品
製品開発段階において原価企画が行われている
→この考え方は情報サービス産業にも同様に適用されなければならない
原価企画の考え方
「市場思考の原価計算」のプロセス
市場が求めている製品の定義を行い、その製品の価格を予測し、目標利益を控除して製品レベルの目標原価を計算する
情報サービス産業
原価企画活動と生産活動が時間的に近接して行われる
製品と情報システム
有形と無形という差はあるが、
→基本的にはこのようなプロセスをとりながら減価の作りこみを行うことが求められる
情報サービス産業
システムの要件定義すら曖昧に営業が注文をとってしまうことも少なくない
要件定義ができず、製品仕様が固まらなければ
製品レベルの目標原価も決定できない
売上高は確保できても利益なき受注になることもある
製品の全貌が明らかにならなければ
製品全体の原価を予測することも計算することもできない
製品のパーツの原価を予測することもできない
Ⅲ 情報サービス産業の経営に対する提言
取引形態に依拠する問題
必ずしもベンダーの行動のみから発生するものではない
１．ユーザーがすべきこと
①ITは業務のサポート･システムであることを認識しなければならない。
②事業戦略とその遂行方法を予め決定し、事業戦略遂行のために必要なITのファンクションを定義しなければならない
③②にもとづいて要件定義およびシステムの仕様の定義をベンダーと共同で行い、ITに対して行わせたいことはユーザーの言葉で明確にしなければならない
ユーザー
情報システムで何を行いたいのかを明確にしておく必要
自社の事業戦略の遂行方法を明確にする
情報システムがそれに対してどのような支援を行うものであるのかを十分に検討する
自社が何を行いたいのかきちんと理解してそれを具体化するようなベンダーを選択する
２．ベンダーがすべきこと
①売上高ではなく、利益の獲得できる受注を行うこと
→原価の作りこみが事前に十分できるような受注形態をとらなければならない
②要件定義に基いて、正確な契約書を作成すること
→契約には、想定しうるあらゆる例外事項、契約の追加事項および破棄に関する事項を盛り込んでおくことが必要
③ユーザーの答えを引き出すような「コンサルティング」としての機能を充実させること
→あくまでも取引の主体はユーザーであることを徹底させること
未だに多くの企業が売上高の競争を行おうとする
無理に売上高を拡大するよりも、確実に利益を獲得できるような経営を行わなければならない
適切な利益を獲得するため
個々の取引について適正な原価計算を行い、さらに事前に利益を確保できるような原価企画的発想を適用することが必要
→早期に詳細な契約を交わすことが必要
例）想定しうる例外事項や契約が破棄された場合における費用の負担方法の詳細等について明記しておかなければならない
ベンダー
システム開発において過去に生じたユーザーとの問題点を全て把握して整理し、事前に対処できるようなデータベースを作成しておく必要
→外資系企業を中心に現に行われている
情報システムであろうが、製品であろうが
ユーザーが何を求めているのか
何を解決しようとしているのか
ユーザーに明らかにさせつつ、それを適切に汲み取っていくことが何よりも重要
まとめ
会計
確定した事象、あるいは高い確率で確定するであろう取引・事象を写像するもの
→確定しない、あるいは確定する確立が小さい取引を写像することはできないか、行っても不適切なものとなる可能性が高い
製品の目的・仕様・構造などが明確でない場合
問題点は大きくなる
会計制度をいかに整備したところで、根本的な問題が解決されるものではない
→取引慣行を見直して、会計が正しく適用できるような形にすることが求められる
従来の取引慣行
市場において短期間に変更することは極めて困難
最大手のユーザー（省庁）
リーダーシップをとって、率先して明確な契約を行い、もって情報サービス産業の取引慣行を変化させるための嚆矢とすることも求められる
参考文献：清水孝「情報サービス産業における経営上の問題点」『企業会計』Vol.58,No.2、中央経済社、2006年2月