ユーザー（発注企業）側からみた課題
業務の機械化を中心にコンピュータが活用された時代
情報サービス企業に技術依存をしながらも、社内システムを計画し、開発し、運用する基本構造
→十分機能してきた
1990年代半ば頃から
PCの高性能低価格化
インターネットの普及
情報通信の技術革新
→情報活用のあり方を根本から変えてしまった
供給側
大型汎用コンピュータを供給する企業が中心的な役割を担ってきた時代
↓
多くのベンチャー企業が参画し、ソフトウェアの需要も倍増する
発注者と受注者の関係
受発注者間の意思疎通の悪さ
→情報サービス産業の不適切な会計処理に影響している恐れは否めない
Ⅰ 情報サービス産業の「特殊性」は本当に特殊なのか？
2つの特殊性
ソフトウェアという財が容易に見えない「無形の財」であるということ
ソフトウェアの製造過程において要件定義が変化しやすいという「変化の財」であること
特質が特殊であるがゆえに取引上の問題や会計上の問題を引き起こしている
論理性において妥当とは言えない
Ⅱ 契約における合意形成の不備
プログラムが作られていく過程や完成したプログラムがコンピュータを制御している様など
容易に視認されるものではない
→財についての共通認識の形成
何らかの工夫が必要
共通化された契約の手順や手続きなどが存在していない
一般の商慣習に基づいて企業が独自に定めたやり方で進められる
情報サービス企業との契約
基本契約と個別契約などに分類
基本契約
守秘義務の遵守や支払条件など基本的な契約共通事項について合意が形成
個別契約
開発されるソフトウェアについての使用や金額や納期などの個別要素についての合意形成
→合意形成の不備が起こりやすい
合意形成の不備
仕様確認や責任分担の曖昧さから起こる
発注側
開発側が正確な開発計画を立てられるように、どのような業務プロセスにしてどのようなソフトウェアを開発して欲しいかを要件定義という形で伝達しなければならない
要件定義
ビジネスプロセスモデリングに基づくもの
プロセスシナリオや数値化が重要
機能面ばかりでなく、品質や性能や運用についても要求を可視化した形でまとめる必要
責任分担
契約の範囲を明確にし、契約外のものについての取り決めや追加仕様が発生したときの取り扱いなどの合意が必要
要件定義が詰めきれてない場合
要件定義までについて個別契約
要員を派遣してもらって支援を受け、確定させた後に本契約に進める方法
→プロセス毎に区切って契約
フェージング契約
要件定義まであるいは基本設計までを部分契約することによって、発注者にとっても受注者にとっても手戻りリスクを回避するのに効果的
契約内容について十分な合意が形成できていない状態で未契約着手することがある
作業工程がタイトになることを避けるため
契約確定を急ぎすぎたため
→基本設計までを勧めながら契約を確定するなどの覚書を交わし、曖昧性を排除する必要
SLCP
ソフトウェアの契約と開発プロセスに関わる共通フレーム
→活用されている事例が少ない
Ⅲ 取引慣行における不具合な問題
１．もたれ合い体質
会計を巡る諸問題の要因
取引慣行における問題
ユーザー企業における情報サービス企業依存の体質
情報サービス企業の囲い込み体質によるもたれ合いの構造
情報通信技術の導入や情報システムの開発
ユーザー企業と情報サービス企業のパートナーシップは必須
典型的
要件定義段階におけるもたれ合い
ユーザー企業
要件定義を確定しなければならないが、ユーザー部門が業務モデルをデザインできない
システム部門がその支援を果たせない
→情報サービス産業に支援を求める
当事者意識の薄い発注者の要件定義
容易に確定しないまま、ずるずるとシステム開発に移行
→開発過程での手直しなどが発生
情報システム会社
手戻りを見込んだ見積を提示し、契約する
開発費は割高になり、工程も延伸することが多い
→発注者はこれらを容認
もたれ合い体質
→丸投げ体質
不適切な要件定義のままシステム開発が行われ、進捗管理も不十分なまま発注者の要求とは齟齬が生じた納品が行われる
後処理となる手直しの費用負担も曖昧
→費用負担を巡って係争になる
２．曖昧な検収
請負契約で委託した場合
検収は契約の簡潔を意味する重要なプロセス
ソフトウェア開発
納品に先立って機能や性能を確認するためのテストという工程
・単体テスト
部品単位のテスト
・結合テスト
部品間を連動させたテスト
・総合テスト
実環境に近い環境で行う
検収
テストが全て完了し、要求し要所に示した機能と性能と開発設計書などの納品物を確認できたとき
→検収書を交わして完了
実態
曖昧な検収が行われる
・
契約時期や支払いの都合で検収を決める
システムの運用開始を急ぐために検収が疎かにされる
曖昧な検収
検収後に発覚した不具合について状況を複雑にする
プログラムのミス
瑕疵担保期間については無償で修正
仕様との不一致
検収前の確認が曖昧であることによって複雑化
→１．契約は完結しているにもかかわらず、無償修正要求が出る
→２．仕様との不一致を理由に研修をしないため、契約がいつまでたっても完結しない
総合テストの段階
必ずしも予測できないこともあり、発注者と受注者のどちらかが責務を負うべきなのか明確にされていないことが多い
３．請負契約と労務契約
ソフトウェア開発
システム設計から、製造（プログラミング）、テストまで
→請負契約で締結することが多い
要件定義が確定できていない場合
コンサルティングなどが含まれてくることがある
→一括して契約した場合
条件を明確にしておかな限り、要件定義に予想以上の時間がかかったりする
→受託側にコスト負担がかかる
＊ 開発技術者を待機確保しておかなければならない場合
作業量に不確定な要素がある場合
一括請負契約は不適当
請負契約
正確な見積のもとに締結されるべき
作業量が不確定な場合
労務契約によって要員派遣を受ける
単価契約による出来高払いにする
→別途に契約するのが双方にとって望ましい
Ⅳ 情報サービス産業の抱える内部統制問題
１．プロセス管理について
プロセス管理
リソースやリスクや情報伝達などが統合的に管理されながら、プロジェクトのなかで目的とする製品を、品質、工程、原価の要素でマネジメントしていく
原価管理のもとになるもの
精度の高い積算
ソフトウェア受託業務
コストプラスフィーで構成される積み上げ形
→適切な単価や積算規準によって原価構成がされなければならない
→ユーザー企業にはこのどちらも示されることがない
労務単価
経費などが含まれた大まかな業種別（SEとかPGとか）の月額報酬が示されるだけ
スキル別の基準も明確でない
積算基準
どういう手法や計算式で算出されるか明示されないため
→標準積算という概念ができてこない
プロジェクト管理のもとになる原価構成が明確でない
原価管理を曖昧にしている
品質
品質管理基準に従って管理されなければならない
ISO9000の浸透
管理基準の設定はされているよう
→プログラムミスが散見されることから、実行実態については定かでない
ユーザー企業側
中間の出来型検査ができないことが難点
＊ 見えにくい財の管理の難しさ
工程
WBSと作業時間管理によって比較的容易に進捗を把握し管理されるものと思われる
→変化を理由に遅延することが多い
→工期遵守についての意識は希薄
２．建設業界との比較
情報サービス産業
多重階層請負型産業
建設業と比較されることが多い
建設業との類似点や相違点
業
労働集約産業
許可制
情報サービス産業
許可制ではない
建設業
建設業法で定められた許可制の事業
許可
一定の条件を満たす必要
水準が担保
評価制度
建設業
経営事項審査という企業の評価制度
経営実績や技術者数などでランク付け
→経営努力を求められる
工事
工事成績評定
品質確保の推進に関する法律など
→一定の品質を確保し、不良不適格業者の排除を促す仕組み
ある規模の下請けを行う場合
官民工事を問わず施行体制台帳の提出を義務付け
→下請け構造の透明化
プロジェクト･マネジメントによる生産管理
工期の遵守に対する意識は建設業が高い
情報サービス産業は決して高いとは言えない
遅延に対するペナルティ意識
情報サービス産業は低い
① 労働単価
標準労務単位が明確でない
スキル別単位などの取り決めもない
→労務コストに対する合意が形成しにくい
経費等が含まれた月額で提示されることが多い
企業規模などによって単価のばらつきは大きい
→プロジェクト管理費や一般管理費などとは切り離して、標準積算に供することが出来る共通の標準労働単価必要
② 積算基準
標準労務単価の明示がない
積算基準が明確でない
各社は独自の積み上げ方式でコストの見積をしていると思われる
→発注者と受注者が共有できる標準積算方式があれば、契約時における合意形成も容易になる
③ 出来高払い
建設業
工事専門業者などの下請企業
→月々の出来高に応じて支払いを行う出来高管理
情報サービス産業
完成払いが一般的
出来高払いを行うには
進捗管理、品質管理を行わなければならない
ソフトウェアは見えにくい財であるから出来高管理ができない
→理由にならない
⇒進捗管理や品質管理ができない
④ 進行基準
建設業
平成16年4月から50億円以上（工期2年以上）の大型工事
→進行基準を義務付け
＊大企業
より小規模の工事についても進行基準を採用しようとする動き
情報サービス産業
進行基準を採用している企業が少ない
進行基準
進捗や原価管理を的確に行うプロジェクト管理精度向上に有効
＊ 収益計上を進行に伴って伊湖なうことにより、コスト意識を醸成することや見積能力を向上させ収益改善にも寄与する
Ⅴ 改善のための提言
１．取引慣行の改善
契約や発注に蹴る問題の根源
発注者となるユーザー企業の姿勢
要件定義を確定しないまま、受注者に依存してリスクを添加する発注姿勢を改める必要
受注者となる情報サービス産業
契約実績を求めるあまり使用未確定のまま着手したり契約を急いだりすることなく、要件定義を確定できるようにフェージング契約を勧めるなどの対応も必要
発注段階でのユーザー企業の甘さ
プロセス管理や検収においても尾を引くことになり、双方の甘えの悪循環を引き起こす
→断ち切るのはユーザー企業の責務
厳格な発注と明確な契約、そして進捗のチェック
→工期延伸の責任も明確にし、契約時には工期延伸に対するペナルティ条項を盛り込み、遵守意識を高めさせる必要
２．可視化努力による改善
ソフトウェア
見えにくい無形の財である
産業界として可視化努力が十分にされているとは思えない
優れた情報サービス企業
要件定義が未確定の場合
サンプル画面やプロセス繊維でビジネスプロセスの確認を行うなどの努力
ER図によって、扱うデータの相互関連や必要な属性項目の確認
→基本をきちんと可視化しながら進めている
ソフトウェア開発における重要な可視化
ユーザーが主体となるビジネスプロセスモデルの可視化
→ユーザーからシステム開発者に要件定義を伝えるのに有効
システム開発側が主体となるデータモデルの可視化
→効率的な開発とシステム機能をユーザーに伝えるのに有効
可視化の手法
いろいろなものが提唱
双方が共有でき、理解しやすいものでなければならない
可視化の表記方法
BPMN、UMLなどの標準化の動き
ユーザー企業と情報サービス企業がこのような可視化手法を共有
相互理解の向上を図ることが、契約時の合意形成の改善につながるもの
＜参考文献＞木内里美「ユーザー（発注企業）側からみた課題」『企業会計』Vol.58、No.2、中央経済社、2006年2月