ベンダー（受注企業）側からみた課題
問題の多くを克服する上での課題
「要件定義の確立」
情報サービス産業
売上高：14.5兆円
就業者数：57万人
我が国の基幹産業といわれる他産業と遜色ない規模にまで成長を遂げた
情報サービス
経済社会の基盤、あらゆる産業の価値実現のインフラストラクチャーとしての役割の質が深化
情報サービス産業
これらを提供するエンパワーインダストリーとして不可欠の存在
現在の情報サービス産業
コスト、品質、生産性、セキュリティなど産業競争力や信頼性の観点から懸念される課題が山積
2004年には情報サービス産業において不正な取引
会計処理のあり方が再検討
情報サービス企業の会計
収益認識に関する基準の具体化
期間損益計算における恣意性を排除した期間帰属の決定
費用･原価の合理的な見積計算
ソフトウェアおよびサービスの価値を反映した新たな価格設定方式等
課題の検討
ソフトウェア開発の実態を把握することが前提
Ⅰ 情報サービス産業の概要
IT産業
ITを創出・利活用して事業活動を営む産業
含まれる業種
情報通信業、電機、精密、商業など相当幅広く捉えられている
総務省の「日本標準産業分類」
情報通信業に分類
証券市場における公開企業等に設定される業種別の分類
大分類：運輸･情報通信業
売上高14兆円
情報サービス専売業者：7兆円
コンピュータメーカー等の兼業者5兆円
情報サービスの事業
① コンピュータ・ソフトウェアを制作する事業
受注制作ソフトウェア（SIサービス、ソフトウェア開発）
市場販売目的ソフトウェア
自社利用ソフトウェア
② 制作したソフトウェアをもとに展開する事業
アウトソーシングサービス、情報処理サービス
③ その他
本稿
SIサービス、ソフトウェア開発
ソフトウェア受託開発
ユーザーの要求に合った性能を満たす情報システムの構築を行うためのハードウェアの選択や構成、サイジングを含む
Ⅱ ソフトウェア受託開発における取引形態と開発プロセス
１．ソフトウェア受託開発における取引の構図
情報サービス産業
建設業との類似性が指摘
垂直的な多重下請け構造
徐々に消滅し始めている
情報サービス企業の規模や特徴
受注した開発案件の種類や当該案件におけるベンダーの開発工程（プロセス）の関与の仕方
→発注企業であるユーザー及び受注企業であるベンダーならびにベンダー間（業界内委託取引）の構図は相当異なる
２．ソフトウェア受託開発における取引形態
ソフトウェアの受託開発委託取引
請負、委任（準委任）、派遣
請負
受注企業である番だーが成果物（プログラム等）の完成あるいは業務（運用・保守等）の完了を約束し、発注企業がその結果に対して報酬を支払うことを約束する形態（民632条で定められた典型契約）
契約対価の支払い
受注企業が成果物を完成･納品し、あるいは業務の完了を報告し、発注企業がこれを検収（受入検査･確認）して合格であると受注企業に通知して始めてなされる
委任
発注企業が法律行為をなすことを受注企業に委任し、受注企業がこれを承諾する形態
「法律上にあらざる事務の委託はこれを準用する（民656条の「準委任」の規定）」
対価
業務（事務）の遂行に要した時間を月末等一定の期日毎に締めて受発注企業両者で確認し、契約で定めた工数単価に時間を乗じて算定して支払われる（工数請負）
派遣
受注企業が雇用する労働者を発注企業の命令を受けて、当該発注企業のために労働に従事させる契約
対価
「委任（準委任）」と同様に時間を基準として支払われる
「派遣」と「請負」と「委任」の違い
受注企業に「指揮命令権」があるか否か
情報サービス取引
「請負」と「委任（準委任）」と中間的な存在である業務委任契約（SES契約）
SES
発注企業の社内に常駐して技術者のもつ専門的な知識･経験をもとに様々な業務を行う形態
SES契約
成果物の品質保証責任（瑕疵担保責任）は問われない
委任（準委任）契約でもとめられる、善管注意義務違反に問われて作業のやり直しが求められるケース
下請法
情報サービス企業は適用対象外
下請取引の公正化と下請事業者の利益保護を目的
資本金3億円超の親事業者と資本金3億円以下の下請事業者ならびに資本金1千万円超3億円以下の親事業者と資本金1千万円以下の下請事業者における情報成果物の作成委託を新たに適用対象
情報成果物
プログラム（同法第2条第6項第1号）、文字、図形もしくは記号もしくはこれらの結合またはこれらと色彩の結合により構成されるもの（同法第2条第6項第3号）
３．ソフトウェア受託開発における開発プロセス
ソフトウェアの性質
不可視であること、物理的制約がないこと等
作成
有形物の開発･製造とは異なって整然とした製造工程がないため、作成に従事する人への依存度が高い
→作成者の能力次第という特徴
ソフトウェア分野におけるプロセスへの基本的な着眼点
製造工程自体を技術の対象として捉え、その合理的な配置や必要な作業内容の確定が試みられる
ウォーターフォール･モデル
古典的なプロセスモデル
企画、設計、開発とフェーズ毎に工程を分けて上流から順番に開発する手法
＊ ユーザーの情報システムに対する要求を正確に定義
→大規模な開発を効率よく進めることができる
要求を正確に定義できなければ
開発の進捗の見積が狂い、前工程等への手戻りが生じ、納期やコストに問題が生じる
受託ソフトウェア開発
ユーザーの要求をソフトウェアの仕様として定義することが最大の課題
ソフトウェアの品質の良し悪し、ソフトウェアの規模及び開発の進捗に伴って発生する原価の見積り、見積原価に基づく価格の設定、ユーザーが求める納期の遵守、これらにそれぞれ欠陥・不具合の発生、見積りの誤り、赤字の発生、納期遅延
↓大抵の原因
「要求定義の確定」が不十分である
要求仕様の確定が課題
ユーザーがソフトウェアの仕様に盛り込む内容を書面等で明らかにし、それをベンダーが整理して使用として固めなければ確定できるとは必ずしもいえない
ex）ITを活用した新たな事業展開や業務改革
企業合併によってシステムの統合を図る場合
↓ユーザー自身
未知、未体験の取り組み
自社内での企画段階において、開発の最終成果物である情報システム、さらには導入した情報システムの運用状態の概要を相当程度まとめることはできても
→実際の運用を充足するだけの具体的かつ詳な説明は困難
ユーザー
自らが導入を予定する情報システムに関する認識が不十分な状態
→開発するソフトウェアの仕様をベンダーに伝える
ユーザー
自らが導入する対象物について未知、未経験
→本来要求すべき内容をベンダーに的確に伝えることができない
ユーザー
ベンダーとの間でソフトウェアの仕様を詰めていくなかで、本来要求すべき内容を自覚する
→開発の企画･設計プロセスを進めるなかで、要求内容自体が変化してしまう
会計
確実に発生もしくは発生する可能性の高い事象を写像する
ソフトウェア開発がもつ「変化」という特質
克服すべき課題の一つ
＊発注内容が固まらない段階での開発作業の問題点
ユーザー
ソフトウェアの仕様に関する要求が変化するため
→開発プロジェクトの立ち上げの度合いに比べて証憑のやり取りが遅れがちとなる
→ベンダーだけが一方的にその責めを負う
→実態にそぐわない
ウォーターフォール・モデル
ユーザーの要求仕様の変化に伴う開発の手戻りが生じるという欠点
プロジェクトの特性に適したプロセスモデル
開発されている
Webベースの開発案件
画面のデザイン性や操作性などが重視
＊ユーザーからの要求
感覚的・抽象的
要求定義の段階
ソフトウェアを試作
ユーザーの評価を得て、これを開発にフィードバックしながら改良を行う「プロトタイピングモデル」
スパイラルモデル
プロジェクトを分割して独立性の高い部分毎に、設計･プログラミング･テストを繰り返しながらシステムの完成度を高めていく
段階的（Incremental）モデル
全体の構成を明確にした上でプロジェクトを分割し、独立性の高いサブシステム毎に開発してリリースする
進化的（Evolutionary）モデル
最初はコアとなる一部だけを完成させ、段階的にユーザーの要求を追加して開発し完成させる
開発手法
スクラッチ開発
一から手作りで開発する方法
業務系のソフトウェア開発
第三者が権利を有するパッケージ･ソフトウェアをベースに、ユーザーの要求に合わせて手直し（カスタマイズ）や追加の開発（アドオン開発）を行って情報システムを構築するのが一般的
スクラッチ開発
クラスライブラリ、コンポーネント、フリーソフト、さまざまな開発ツールを利用してソフトウェア開発を行うことがごく普通
開発したソフトウェア
それ自身の欠陥（バグ）、ミドルウェア、基本ソフト（OS）との相性に起因する不具合
→検証作業が膨れ上がる傾向
開発プロセスに占めるテスト工程の工数比率：30.3%
Ⅲ 今後の課題
「要求定義の確定」が不十分
ソフトウェアの品質、規模や原価の見積等に悪影響が生じる
経済産業省の研究会報告書
契約の分割や進行基準による収益の認識において指摘
情報サービス産業の会計上の問題を克服する前提としてのベンダーの課題
要求定義あるいは要求的儀を含めたプロセスの高度化を工学的なアプローチ、すなわちソフトウェア･エンジニアリング（工業化）のなかで実現していくことが上げられる
要求定義に関連するソフトウェア･エンジニアリングの取り組み
エンピリカル・ソフトウェア・エンジニアリング、要求工学
要求定義を行うプロセス
開発するソフトウェアのタイプによって全く異なる
E（evolutionary）タイプ
要求が時間とともに進化（変化）する
エンタープライズ系ソフトウェア
S（specify）タイプ
ハードウェアの一部として機能する組み込み型のように与えられた稼働環境が懸隔に規定されるソフトウェア
ユビキタス･コンピューティングの進展
Sタイプの重要性が高まりつつある
受注制作のソフトウェア
「請負工事の会計処理に準じて処理する（同基準四１）
＜参考文献＞田中岳彦「ベンダー（受注企業）側からみた課題」『企業会計』Vol.58,No.2、中央経済社、2006年2月