日経コンピュータの2004年12月13日号特集「日本のソフト開発力を取り戻せ」でソフトウエア・エンジニアリングを見直す動きについてレポートし，IT Proに掲載した記事に読者の方々から多くのご意見をいただいた。

　目立ったのは，「ソフト開発を製造業的な観点で見直しても成果は期待できない」「欧米の研究を後追いしても現状の問題は解決できない」など，疑問を投げかける意見。「日本のソフト業界もやっと問題を認識するようになった」といった，この動きに期待する意見は，むしろ少数だった。

　記事を担当した筆者としては，正直残念ではある。ただ，ソフト業界の問題はソフトウエア・エンジニアリングだけでは解決できないという読者の声には，感じるところも多かった。これまでのソフトウエア・エンジニアリングが現場のためのものではなかったとか，ソフトウエア・エンジニアリング以前に業界構造や教育など解決すべき問題があり過ぎる，といった意見は筆者もその通りだと思うからだ。

　確かに，これまで筆者が取材してきたなかで聞いた，仕様変更の多発によって納期が遅れる問題や，それによって開発者が疲弊している問題などは，従来のソフトウエア・エンジニアリングである方法論や技術，ツールなどとは別な面が大きな原因となっていると感じている。

　それでも筆者は，今回のソフトウエア・エンジニアリングを見直す動きが，これまで手付かずだった業界の問題にメスを入れるきっかけになると期待している。実は，数年後に振り返ってみて，この動きが日本のソフト業界を改革する発端になったと言われるのではないかとまで，ひそかに思っている。先の記事の範囲でうまく伝えられなかったのは力不足だったが，新たなソフトウエア・エンジニアリングの動きは単に開発生産性の向上のためだけではないことを，ここであえて補足しておきたい。

　「生産性の向上」以外で筆者が最も期待しているのは，ユーザーとベンダーの責任範囲があいまいだったり，見積もり価格の根拠があいまいだったりする現状を改める機会になるのでは，ということだ。実際に，請け負い開発におけるソフトの価格についての妥当性を考える活動が進んでいる。以下では，筆者の考えを交えながら，この活動を紹介したい。

生産性や価格の“相場”を示す試みが始まる

　記事に対する読者の意見には「ソフト工学うんぬんよりも，ソフトの価値・価格を明確にすべき」というものがあった。この意見はシステム・インテグレータの方からいただいたもので，ソフトの適正価格が明確でないままユーザー側がコストや納期の面で無理な発注をする，といった問題を指摘されている。

　実は，先の記事で取り上げたソフト開発の研究組織である「ソフトウェア・エンジニアリング・センター（SEC)」がこの問題に取り組んでいる。SECの「定量データ分析部会」の活動がそれだ。実際のプロジェクトにおけるデータを約300項目にわたって収集する。具体的な項目は，開発フェーズごとの工数や不具合件数，作業スペースの広さ，要求決定者の人数などである。国内インテグレータ13社が協力し，約1000プロジェクトのデータを集めるという。

　このデータを使って，開発生産性の“相場”を示すのが狙いだ。データを統計処理し，例えば，1人月当たりの平均プログラム行数や，100ファンクション・ポイント（ソフトの規模を示す指標）当たりの平均不具合数などをはじき出す。

　ただ，残念ながら実際の受注金額については，データ提供をベンダーが拒んだために集まっていない。ここで注目すべきは，ユーザー企業側からのデータ収集を，SECのプロジェクトの一部として日本情報システム・ユーザー協会（JUAS）が進めていることだ。こちらは規模や工数だけでなく，かかった金額の実績値も収集している。

　この分析結果は，今年6月に公開する計画だが，アンケート協力者には，一般には公開しない詳細な情報まで提供するという（ただし回答企業の名称は秘匿する）。価格の相場がズバリでるのかどうかは分からないが，価格の妥当性を見極めるための何らかの指標は示されるだろう。

課題も多いが，まずは“相場”が明らかになることに意味がある

　では，こうした数値が実際にソフトの適正価格を判断する指標になり得るのかを，少し考えたい。データの分析結果で明らかにされるのは，ソフトの規模に対する平均工数，平均不具合数，平均納期などである。調査が十分なサンプル数を集めれられば，ある程度の指標になると思う。

　もちろん，検討すべき点は数多く残っている。まず，システムの規模として何を指標とすべきなのかは，難しい問題である。昔から使われており，いまだに最も一般的な指標であるプログラム行数については，ツールがコードを自動生成するなどの現状から，あまり妥当ではないのは周知のとおり。次に，機能の量を測るファンクション・ポイント法も徐々に浸透しているが，まだ一般的とは言えず，さらに規模として妥当なのかも，まだ見極められていない。そもそも規模とは何をもって規模とすべきかも難しい。ユーザーが得られる機能の量なのか，開発者の作業量なのか・・・

　また，規模や品質，納期だけではなく，保守性，拡張性，セキュリティ，性能などの要件に対して，どのように評価して価格に反映すべきか，も今後検討しなければならないだろう。システム開発全体で見れば，要求定義や設計といった工程の価格も考える必要がある。さらに言えば，ソフトの“価値”を指標に盛り込むべきだとする考えもある。新しい技術やアイデアで投資効果を高めたソフトなど，作業量だけでは測れないものがあるからだ。

　このように検討課題はたくさんある。それでも，まずは相場価格，つまりどんなシステムにどれだけの金額が支払らわれているのかが明らかになる意味は大きい，と筆者は考えている。これが，適正なソフト開発価格に関する議論の取っ掛かりになるのではないだろうか。多くのデータを集めて分析していく必要があるが，全国のユーザー企業やベンダーがデータを出し合って共有できれば，ソフトの相場価格が明らかになっていくのは間違いない。

　SECが出す生産性の指標は最初の一歩に過ぎない。それでさえも，日本で初めて相場価格に当たるものが公開されることもあり，SEC参加者の間での期待は高い。あるベンダーの担当者は「まずは日本での基準値を明らかにすることが重要。それが出てくれば，買いたたきが少なくなり，仕事がやりやすくなるだろう」と述べる。

　システムの規模や業務種類によって分類して分析するため，統計的に有意とするには1000件以上のデータを収集する必要がある，という見方もある。ユーザー側からのデータ提供は，2004年12月の時点で80件程度であり，まだまだ少ない。JUASのWebサイトで1月21日まで公募しているので，ユーザー企業の方はぜひ参加していただきたい。

（森側　真一＝日経コンピュータ）