ソフトウェア開発でありがちな失敗

皆さんはこんな経験をしたことはないでしょうか？

• 実装後の結合テスト／システムテストでバグが大発生した。
• 実装フェーズがずるずると押してしまい，結局バグだらけのまま納品した。
• 納期直前になって仕様の勘違いが判明して作り直しになった。

ソフトウェアというものが誕生して以来，ソフトウェアの開発はバグとの戦いでもありました。開発手法や言語・ライブラリなどは時代が進むにつれ強力になっていますが，ソフトウェアの複雑度も年々増していくばかりです。ソフトウェア開発とは多かれ少なかれ，必ず何かしら予想できない事態が発生するものだと言っていいでしょう。

開発手法に目を向けるとき，上手くコーディングすることだけに気を取られがちですが，組み立てただけできちんと動かなければ何の意味もありません。努力が正当に報われるためには，フィニッシュまでしっかり駆け抜けることができなくではいけないのです。

どんなに徹夜をしプライベートを犠牲にしても，残念ながらソフトウェア開発に「頑張ったで賞」はありません。IT産業が現代の3K仕事といわれる所以がここにあるように思います。

品質を重視した開発スタイル

前の2つの章では開発のしやすさからソフトウェア開発スタイルについて考えてみました。それでは180度方向を変えて，「⁠いかにトラブルを起こさず確実に開発を終えるか」について考えてみましょう。

もちろんコーディングがしやすいことや管理の行き届く開発スタイルというのも重要ですが，フィニッシュに視点を変えてみるとまた新しい気づきがあるものです。

開発終了の時には品質のよいソフトウェアができており，プロジェクトチームの皆が笑顔でいられることを目標として，成すべきことを終わりから逆算して開発のスタイルを考えてみましょう。

ゴール地点から逆に辿って考えよう

どんな開発手法でもゴール地点の手前にあるのがテスト（検証）の作業となります。そしてテスト・フェーズはソフトウェア開発において最も軽く見積もられがちです。

皆さんのプロジェクトは要件定義とコーディングでスケジュールが埋まってしまっていませんか？ テストの予定があっても，コーディングの予備日と同じ期間にテストのスケジュールが引かれていたりしませんか？ 多くの場合，受託開発であれば「顧客都合に合わせて無邪気に設定された納期」から，SEやプログラマの主張する作業時間を引いたものがテストに充てられているでしょう。個人か小規模の社内プロジェクトであれば，開発最後の2，3日かβリリースの前にわずかな隙間を設けて実施されるでしょう。

ソフトウェアエンジニアリングの古典の名著，ブルックスの『人月の神話―狼人間を撃つ銀の弾はない』では，業務用開発は趣味のプログラムの9倍の手間が掛かるとしています。思考回路のアマチュアなエンジニアがコーディングの手間だけを考えて「その実装は一日で出来そうだ」と思うなら，それを業務開発で行うと9日かかると見積もるべき，ということです。なぜならば要件決めにかかる手間やドキュメント作成などの「雑事」がすっかり抜け落ちているからです。

そこまで愚かでなくとも，見積りというものは大概甘くなりがちです。正しくスケジューリングをし，確かな工数を割り当てなければなりません。こうした意識は後回しになるテスト工程ほど重要になっていきます。

それでは，品質を重視する開発スタイルにおいてテストフェーズにはどのくらいの時間を割いたらいいでしょうか？ブルックスは自己の経験と調査結果から全開発期間の1／2という回答を出しています。要件定義1／6，コーディング1／3，テスト1/2というのがその割合です。もちろんこれは開発する対象によって変わります。OSか基幹システムかWEBアプリかによって大いに差はあるでしょうが，とても興味深い数字です。

また，テストフェーズで何を確認するかは事前に顧客と相談しておきましょう。「⁠仕様書通りに動くこと」で済ませてしまうのはとても危険です。細かい部分など暗黙のものとして書かれていないことが多いため，仕様書は全ての役には立ちません。

受け入れテストの基準が明らかになれば，実装もそれに合わせれば良いので楽になります。