ディレクター2年目が構築案件で気づいたこと
こんにちは。web系企業のディレクター2年目をしているのすけです。
今回は一般的なソフトウェア開発の流れの説明に合わせて、私が構築案件に携わった中で実際に感じたことをシェアしたいと思います。
上記V字モデルに沿って開発の流れを説明します。
要件定義
顧客の要望を詳細までとことん詰めていきます。
実際に案件に携わった中でプロジェクトで一番重要なのはこの要件定義の流れだと実感しました。
顧客の要望を詳細まで把握しきれていないと、要件定義まで落とし込むことができず、実装漏れが生じるからです。先輩ディレクターは、「炎上するプロジェクトは絶対に要件定義がきちんと出来ていない」とおっしゃってました。
実装漏れが生じると想定外のスケジュール遅延が起き、予算が跳ね上がりデリバリーもおろそかになってしまいます。
基本設計
ここでは要件定義で詳細まで詰めた顧客の要望を元に、具体的にどのような機能が必要かまで詰めていきます。システム全体の大まかな設計を行います。
詳細設計
基本設計で詰めた設計をさらにシステムに落とし込んでいきます。筆者目線では基本設計まで理解はできるのですが、詳細設計まで行くと開発関連の話が多く苦しみました、、、。
この辺の話についていくには、ITパスポートなど基本的なITの用語と意味は分かっておくべきだと実感しました。
プログラミング(単体テスト)
さて、いよいよ詰めまくった機能を実装していきます!詳細設計をもとに開発の方に実際いただき、
最小単位のテスト(単体テスト)を行います。
結合テスト
単体テストが終われば次は結合テストです。
V字モデルで詳細設計と結合テストがくっついていますが、結合テストでは詳細設計通りに機能が出来ているかを確認します。単体テストを終えた各モジュールを組み合わせて、意図した通りの挙動になっているかを検証します。バグがあれば都度修正します。単体では正しく動いていたモジュールも、組み合わせればバグが起こってしまう場合が沢山ありました。
システムテスト
V字モデルを見ていただくと、システムテストは基本設計と結びついています。ここでは、基本設計通りに機能が成り立っているかを検証します。単体テスト、結合テストでテストした項目は確認する必要はありません。
運用テスト・ユーザー受け入れテスト
顧客の要件定義通りに機能が成り立っているかを検証します。筆者はこの段階からテストに関わり始めました。筆者のプロジェクトでは、以下の流れでテストを行いました。
1.要件定義をもとに、テストシナリオを作成する
「この前提条件のもと、この操作をしたら、期待結果としてこの挙動になる」と言ったシステムの使い方通りに操作して、期待通り動くのかの項目書を作成します。筆者のプロジェクトでは300パターン弱あり、全部1人で作成することになりました…
2.テストを行う
テストシナリオをもとにテストしていきます。
まとめ
このように構築案件はV字モデルに沿って行われ、
要件定義ー運用テスト・ユーザー受け入れテスト
基本設計ーシステムテスト
詳細設計ー結合テスト
と言うように各工程がしっかりと結びついています。
そして最後のテストは要件定義をもとに行われるため、要件定義がしっかりしていないと納期に間に合わず、コストは増大し、成果物の質も悲惨なことになってしまいます。。
みなさん構築案件に携わる際は、要件定義に命をかけてくださいね!
のすけ
この記事が気に入ったらサポートをしてみませんか?