就職して駆け出しのエンジニアとなった頃、システム開発ってどのように行われるのだろうか？と思って、インターネットで色々と情報を検索したことがある。
そのときに開発プロセスとして良く検索にヒットしたのが、いわゆるV字型開発モデル(ウォーターフォール開発、アジャイル開発でも使われるモデルである)というものであった。
V字モデルとは何か
エンジニアの方はもちろんご存じだと思う。要件を定義して、基本設計(外部設計)をして、詳細設計(内部設計)をして、実装をして、単体テストをして、結合テストをして、システムテストをして、受入テストをして、運用テストをして、、、というもので、V字モデルというのは、作りこみのフェーズと品質確保のフェーズをV字型に配置したものだ。
なるほど、と思ったものだが、調査を進めるにつれて、困惑し始めた。各工程に関する説明が、WEBサイトによって異なるのである(V字モデルというキーワードでgoogle画像検索すると、何を言いたいのかわかると思う)。
設計工程においては、基本設計/詳細設計と表現するWEBサイトや外部設計/内部設計とするWEBサイトがあったり、テスト工程においては、V字の前半に対応するテスト工程の名称がWEBサイトごとで異なっていたり、結局のところ、どのように開発を進めればよいのか結論が出なかった。
あれから時間が経過した。色々な開発現場を経験する中で、自分なりにあるべきV字モデルを確立したので紹介する。
あるべきV字モデル
上図は、筆者が考える、あるべきV字モデルである。作りこみの工程における表現を可能な限りシンプルにした。
作りこみフェーズですべきことは、要件定義、設計、実装の3点だ。要件定義フェーズでは、機能要件定義と非機能要件定義を行う。設計フェーズでは、外部設計と内部設計を行う。基本設計と詳細設計という言い方はしない。何が基本で何が詳細なのか、境界の区別が難しくなるためだ。実装フェーズでは、実装(システムが実際に機能するように装うこと)を行う。
品質確保フェーズですべきことは、要件通りに動くかの確認と、設計通りに動くかの確認だ。要件通りに動くかを確認するフェーズでは、受入テストを行う。要件を出した側が、システムが受入可能な状態なのかを判断するという意味で、受入テストとしている。設計通りに動くかを確認するフェーズでは、システムテスト/結合テスト/単体テストを行う。テストの内容については別の機会で紹介する。
図中に番号(①～④)付きの矢印が振ってある。矢印の意味合いとしては、前工程(矢印の元)の成果物が、後工程(矢印の先)の作業に活用されることを意味しており、
- ①では、要件定義書に基づいて、設計(設計書の作成)が行われる
- ②では、設計書に基づいて、実装が行われる
- ③では、設計書に基づいて、設計通りに動くかの確認が行われる
- ④では、要件定義書に基づいて、要件通りに動くかの確認が行われる
ということを意味している
あるべきV字モデルにおいて、伝えたいこと
あるべきV字モデルで伝えたいことが3点ある。
1点目は、作ったドキュメントは、余すことなく活用されるべきである、という点だ。システム開発においては、無駄なドキュメントが作成されることがある。時にそれは、仕様を解釈するためのドキュメントであったり、システム概要を偉い人に説明するための資料であったりする。このような作業がどこかのタイミングで発生するため、世間一般のエンジニアは、ドキュメント作成が無駄と考えるようになる。あるべきV字モデルでは、作ったドキュメント通りにシステムが動くかどうかを確認する。品質確認フェーズでは、要件定義書/設計書が最大限参照されるのである。書いたとおりに確認するし、書いてないことは確認しない。無駄なドキュメントは一切存在してはいけないのである。これが目指すべきところであり、少しでも多くの開発現場が、このような形で開発が行われることを望む。
2点目は、V字モデルにおいて、設計フェーズに対応するテストの種類は一つではないという点だ。設計工程でシステムの設計をしているのだから、システムテストは実施されるべきだ。また、設計工程でモジュールの設計書を作成しているのだから、モジュールの単体テストや結合テストも実施されるべきだ。V字モデルの中には、詳細設計と単体テストを対応させているようなものもあるが、筆者の考えとしては、詳細設計で設計したモジュールが相互に関連して動作するのだから、結合テストも詳細設計フェーズに対応するものとしてテスト実施されるべきと考える。難しいのは、外部設計と内部設計、基本設計と詳細設計の間の線引きをどうすべきかというところだ。正直なところ、厳密な線引きは難しい。だからこそ、筆者は、設計というフェーズをひとくくりで表現している。
3点目は、書いたら、書いた通りに動くことを確認せよ、それを常に意識せよ、という点だ。色々な開発現場を見てきたが、後工程を意識してドキュメント作成が行われることは少ない。上流工程のエンジニアは、要件定義や設計作業を終えたら次の現場にいってしまう。実力がなかったからいなくなったのか、上流工程しかやりたくないからいなくなったのかはわからないが、後工程の作業は別の者が行う。そのような背景もあり、書かれてあることを確認しない/書かれてないことを確認する、ということが、往々にして行われる。書いたら書いたとおりに動くか確認されるのだから、テスト仕様書を書きやすい要件定義書や設計書を書くべき、というのが、あるべきV字モデルで開発を進めるうえで、意識したい目標と考えている。
まとめ
長々と書いたが、V字モデル自体もただのモデルであって、現場に沿ったモデルがあってしかるべきだ。要件をしっかり定義し、しっかり設計し、その通りに動くかどうかをしっかり確認すれば、システム開発の現場というのはそんなに炎上しないのではないかと考えている。そういう現場を少しでも増やせればと思う。
関連記事
関連記事を掲載しておく。
要件定義書の作り方に関しては、下記を参照
レビューの実施タイミングについては、下記を参照
V字モデルについてもう少し詳しく知りたい場合は、下記を参照
分業方法については、下記を参照
