twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ 未来のいつか テストは誰が書くのか

テストは誰が書くのか

昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト(実装のしやすやしにくさ、実装工数の大きさ)はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交わせられる。開発期間中に仕様の変更はさらなるコストアップになるので、行われない。行うことは悪であるというパラダイムになる。工程を別業者に発注する以上、契約という形で縛らないといけないので、これはある意味、必要悪の世界である。顧客のビジネス上の利益の最大化というのはお題目としてはあっても、構造上それを実行するのは、難しい。 このような構造にあるので、テスト容易なコードを書くというのは、現場のインセンティブとして生じにくい。テストを書く人とコードを書く人が分離されていれば、そのようなことになる。受託開発の場合、かかった工数に人月単価をかけて売上になるので、人月単価がかわらなければ、工数がかかればかかるほど売上がたつので、ここでも、工数削減というインセンティブは生じない。 結局のところ、ウォータフォール型の受託開発モデルでは競争力のあるソフトウェア開発を実践することは非常に難しいことになる。 一方で自社開発の場合は、仮に要求を出す部門と開発する部門が社内的には別々部門であったとしても、同じ会社なので同一の目標に向かって同じ目線で語ることができる。テストを書くことによって生産性が向上するとしたらそれは開発部門だけではなく、事業部門にとっても利益がある。事業部門にとってみれば、テストを書こうが書くまいが、提供されるサービスによって利益が上がればいいわけで、その意味で、必要な機能が提供されさえすれば満足度は高い。 アジャイルな開発方法論は、より素早く、品質の高いソフトウェアを生み出す方法論としてウォーターフォールモデルよりも優れている。少なくとも自社開発の場合は、ウォーターフォールモデルを利用する必然性はないと言ってもいい。 要求分析、設計、実装、テスト、運用など一つの組織が一貫して行うことで競争力を持つ。そのような環境の中ではプログラマの責任範囲は広いし、やりがいもある。 一人が要求分析から、設計、実装、テスト、そして運用についても見通せると、効率のよい実装、テストしやすい実装、運用に負荷がかからない実装というような観点から実装を見直す機会ができる。...

昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1

テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。

ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。

要求分析をして、仕様にまとめるわけであるが、実装のコスト(実装のしやすやしにくさ、実装工数の大きさ)はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交わせられる。開発期間中に仕様の変更はさらなるコストアップになるので、行われない。行うことは悪であるというパラダイムになる。工程を別業者に発注する以上、契約という形で縛らないといけないので、これはある意味、必要悪の世界である。顧客のビジネス上の利益の最大化というのはお題目としてはあっても、構造上それを実行するのは、難しい。

このような構造にあるので、テスト容易なコードを書くというのは、現場のインセンティブとして生じにくい。テストを書く人とコードを書く人が分離されていれば、そのようなことになる。受託開発の場合、かかった工数に人月単価をかけて売上になるので、人月単価がかわらなければ、工数がかかればかかるほど売上がたつので、ここでも、工数削減というインセンティブは生じない。

結局のところ、ウォータフォール型の受託開発モデルでは競争力のあるソフトウェア開発を実践することは非常に難しいことになる。

一方で自社開発の場合は、仮に要求を出す部門と開発する部門が社内的には別々部門であったとしても、同じ会社なので同一の目標に向かって同じ目線で語ることができる。テストを書くことによって生産性が向上するとしたらそれは開発部門だけではなく、事業部門にとっても利益がある。事業部門にとってみれば、テストを書こうが書くまいが、提供されるサービスによって利益が上がればいいわけで、その意味で、必要な機能が提供されさえすれば満足度は高い。

アジャイルな開発方法論は、より素早く、品質の高いソフトウェアを生み出す方法論としてウォーターフォールモデルよりも優れている。少なくとも自社開発の場合は、ウォーターフォールモデルを利用する必然性はないと言ってもいい。

要求分析、設計、実装、テスト、運用など一つの組織が一貫して行うことで競争力を持つ。そのような環境の中ではプログラマの責任範囲は広いし、やりがいもある。

一人が要求分析から、設計、実装、テスト、そして運用についても見通せると、効率のよい実装、テストしやすい実装、運用に負荷がかからない実装というような観点から実装を見直す機会ができる。

テストを書けないのは、テストを書きやすい実装になっていないからである。組込みやリアルタイム系でテストが難しいという話もあるが、それでも、テストしやすさを前提とした実装と言うのは絶対にあるはづである。*1

プログラマにとってテストを書くことが重要なスキルの一つなのである。

*1:実際OSの開発でブートローダが立ち上がる以前のテストやデバッグはJTAGというハードウェアデバッガを使って行うが、そのような低レベルの実装のテストというのも不可能ではない

Read more at 未来のいつか
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!