立場によって異なる「もどかしさ」

システム開発を発注するユーザー側でも、受注する側でも、ほとんどの方は業務の中で日常的に、何かしらのもどかしさを感じていることでしょう。

とはいえ「~がもどかしい」の「~」の部分に込められる悩みは人それぞれで、当然ながら立場によっても異なるはずです。

例えば、同じ悩みでも発注者と受注者との間で、相手に対するもどかしさの表現は、上のように変わってくると思います。

発注者側のもどかしさ

受注者側のもどかしさ

  • はなからサービスインに間に合わせようという意気込みが伝わってこない
  • システム開発のプロであるはずなのに、「欲しいシステム」を提案してくれない
  • 機能として十分な実装ができてないのに、修正を要求すると機能追加や変更扱いにしたがる
  • いつまでたっても仕様を確定させないから、サービスインに間に合わなくなる
  • システムに何が必要なのか、ユーザー自身が整理しきれていない
  • 「あって当然」という理由で、後から無茶な機能追加を要求してくる

こういった多くのもどかしさを感じたままシステム開発が進んでしまった場合、たとえ発注者による受け入れテストの段階までたどり着けたとしても、きっと山あり谷ありの末でしょうからスケジュールは遅れ、工数がかさんでしまっていることは珍しくありません。 ……と、これだと何やらこの先、現場の実態を反映しているとはいえ、悲観的な話ばかりになると思われるかもしれません。それだと読んでいる方も書いている方も辛いですから、少し角度を変えてみましょう。

実際には、発注者、受注者の双方とも苦労した甲斐はあるようで、稼働後の不具合の数という観点で見ると、思ったほど世間一般のデータ(※1)の内容は悪くないということがわかりました(図1)。

※1:ソフトウェア開発データ白書2007(情報処理推進機構 ソフトウェアエンジニアリングセンター、日経BP社)

N

最小

P25

中央

P75

最大

平均

標準偏差

623

0

0.0

2.0

10.0

1.262

18.5

79.1

    

N=623(未回答:1,151件)
※集計対象データ:以下のデータの最大値。
 5267_発生不具合現象数(合計)_1ヵ月、5268_発生不具合現象数(合計)_3ヵ月、5269_発生不具合現象数_6ヵ月

図1 稼働後の不具合数(現象数)
出典:ソフトウェア開発データ白書2007(情報処理推進機構 ソフトウェアエンジニアリングセンター、日経BP社)

    

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST'08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.1(2007年11月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。