ソフトウェアタグ

6/12のSEA関西プロセス分科会で聞いたソフトウェアタグに関するメモ書き。

【元ネタ】
第38回　SEA関西プロセス分科会のご案内

StagEプロジェクト

ソフトウェアタグとは、受託システムへ開発時のプロジェクト情報を付けて、トレーサビリティ(追跡性)とアカウンタビリティ(説明責任)を持てるようにすること。
イメージは、工業製品や食品のタグのように、原産地はどこで、品質は保証されていることを開示できるようにする。

ソフトウェアタグは経済産業省のプロジェクトの一つとして研究されているらしく、規格が決まってようやくタグの利用方法について議論が始まった状態らしい。

ソフトウェアタグが利用される状況は、SIerとユーザ企業の間で受託システムを契約して納品する時に使うことを想定している。
そのために、ソフトウェアタグの規格には、システム情報だけでなく、進捗に関する工数や、設計やソースコードに関するメトリクス、品質に関するメトリクスも含まれている。
ソフトウェアタグを使うことによって、SIerとユーザ企業の間で法的な争いごとが起きても、その資料として使える状況も想定しているらしい。

僕としては、システムの品質や開発の進捗に関するメトリクスをいつでも見れるから面白そうだと思ったが、実際のSIerのビジネスとしては複雑な問題がある。
質問タイムでの議論が面白かった。

現在の請負契約の元では、進捗情報を元に元請やユーザ企業が指示を出すと、違反になるらしい。
だから、あくまでも参考資料としてしか使えない。
そもそもSIerが工数をユーザへ出すのは抵抗感があるので、規格では必須ではなく、任意であるようにしているらしい。

このソフトウェアタグに興味を持つ企業は、中国やインドのオフショア先の企業。
彼らはこのソフトウェアタグを逆手に取り、逆に開発効率や品質の良さを他企業との差別化戦略に使いたいらしい。

ソフトウェアタグの話を聞いて、ソフトウェア開発に必要なメトリクスがある観点で提示されたのは面白いと思うと同時に、現場で使いこなすにはハードルが高いだろう、という感想も持った。
ソフトウェア工学にも同様の問題があるが、ソフトウェアタグもそもそもメトリクスの基準がはっきりしていないのだ。

バグ数と言っても、プロセスが安定していなければ、ばらつきが大きすぎて定量的にならない。
バグの検出基準も、会社だけでなくプロジェクトごとにバラバラであれば定量的にならない。

質疑応答時にもあったが、単体テスト時のバグ数のカウント方法も、一通りの単体テストが終わった後で別の人が単体テストでバグをカウントするやり方もあれば、実装完了後に開発者自身がバグをカウントするやり方もある。
当然両者の数は異なるし、後者のやり方で押し付けることはプロジェクトによっては難しい。

ソフトウェア工学では「計測できないものは制御できない」という根本思想の元でメトリクスを採取しプロセス改善していく手法を取るが、エンジニアリングの土壌が存在する仮定がそもそも難しい。

とはいえ、ソフトウェアタグが農産物や工業製品のように、要件からモジュールまでの追跡性、更には、品質に関する説明責任まで保証できるならば、非常に役立つ。
日本以外では規格がないらしいので、品質保証に強い日本発の技術になれば面白いだろうと思う。