概要
要件定義→基本設計→詳細設計→製造→単体テスト→結合テスト→総合テスト→ユーザ受入テスト(いわゆる典型的なウォーターフォール)の流れでしか開発経験がない、それ以外の開発プロセスは許容しない、というお客様の案件に、テストファーストを一部導入した話。
前提
俺氏:とあるSIerにSEとして勤務する2年目。
案件:とある大手企業のサービス開発案件。
経緯:実装終了後、「設計書通りだけど、実際動かしてみるとなんかイメージと違う」と大きな仕様変更のご要望を頂く。納期的に厳しいことをお伝えしたところ、「これでは業務が回らないので困る」とのこと。また、予算追加は厳しいとのことで要員増も難しい。以前、サービスの戦略的な理由からリリースを伸ばしているので、さらに延期するのはできない。結果、プチ炎上。(プチ炎上で済んだのは案件自体の規模がそこまで大きくなかったからではないかと思う)
その後、追加開発を行うことになった。
背景
もともと、お客様側のプロジェクトメンバーが、IT系のプロジェクト未経験で、要件を期日までにまとめきるのが難しいという理由から、アジャイル開発を提案していた。しかし、お客様の社内の事情からウォーターフォール型の開発以外は許容できないとの回答があったので、ウォーターフォールでの開発を行った。しかし、要件が変わることもよくあり、また、開発側の負荷がつかみにくい(ITプロジェクトの経験がないため)ので、大きな仕様変更が頻繁に入る状況になっていた。
問題点
今回の案件でプチ炎上になってしまった問題点は、プロセスの進め方以外に、度重なる仕様変更にメンバーのモチベーション低下、コミュニケーションの齟齬、技術的な問題等があったが、開発プロセスに限定して考えることにした。
というのも、上記の問題の根元には「実装後に仕様変更が数多く入る」ということがあるが、それは開発プロセスに問題があると考えたからだ。具体的には、「設計書通りだけどイメージと違う」、この一言に集約されるように、設計書でのイメージと、業務要件を満たすためのイメージが乖離していることが原因だと考えた。経緯については詳細に記憶していないが、詳細設計書を元に実際の動作イメージを話し合う、という進め方をしていた。(これが一般的なことかどうかは経験が浅いこともありわかりません。)詳細設計書は技術者が実装を進めるための、いわゆる内部仕様書なので、動作イメージが実際のイメージと違ってきてしまうのかなと感じた。
解決案
もともと自分がテスト駆動開発に興味を持っていたこともあり、プロジェクトにテスト駆動開発的なエッセンスを持ち込めないかなと思っていた。単体テスト仕様書を、実際のユーザの動作１つ１つを想定して作成していたので、これをもとにすれば動作イメージが思っていたのと違う、という状態を防げそうだと感じた。そこで、詳細設計書と単体テスト仕様書を同時に作成し、単体テスト仕様書をもとに動作イメージを決定すれば良いのではないかと考え、提案した。
導入
ということで、上記の解決案をもとにPMに提案を相談。そこで、下記の２つの問題を指摘された。
・詳細設計書と単体テスト仕様書を同時に書くということは、(仕様を決定する段階である詳細設計時に)変更があった場合、修正コストが２倍になる
・プロジェクトの進め方が変更になることで顧客サイドに混乱が起こらないか
しかし、上については実装後に再度仕様を決定するコストの方が高いため、許容できる、と判断。また、下については混乱が起きてもカバーできるように追加開発のうち小さい要件で実施することにした。
お客様の反応
「一つ一つの動作ベースの方がわかりやすい気がするけど、正直よくわからない」という反応
実施してみてどうだったか
今回実施してみて、仕様変更がほとんどなく、実装の負担もかなり小さかったので、成功なのかな、とは思いますが、要件自体が小さいことが原因だったかもしれませんので、まだ未知数な部分が大きいです。しかし、この進め方を了承・理解してもらえたので、今後続けていく中でよりはっきり成果が上がるのではないかと考えています。
最後に
そもそもウォータフォールがどうなんだ、とかそんなんテストファーストとは言えない！などなどあると思います。なにか言ってやりたい！という方はぜひコメントをいただきたいです。
この記事を読んでやっぱこれだからSIerはダメ、というご意見もあるかもしれません。ただ、SIerのいいところは、業務知見がある顧客と組んで、技術を提供することでその業界の人でなければ思いつかないようなサービスを開発できることだと思いますし、とても面白い仕事だと感じています。技術的にバリバリやっていきたい！という人にとっては遅れているように感じられる部分があるのは確かですが、それ以外の面でいいところもあるよ、というのを知っておいていただきたいなと思います。