Lab.(トレラボ)TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。この記事ではV字モデルの構造について説明します。V字モデルの構造を把握することで、各プロセスで力を入れるべきポイントが分かり、効果的にシステム開発を進めることができます。V字モデルの全体像と開発を組み立てる方法については以下の記事を参照してください。最後に各レイヤーの詳細説明記事システム開発プロセスの分類とその関係システム開発のプロセスは、大きく5つのプロセスに分けられます。上図のように左から右へ目的と手段の関係になっています。企画から見ると要件定義は企画を実現する手段であり、要件定義から見ると企画は要件定義の目的です。それぞれのプロセスの成果の品質を保証します。V字モデルへのマッピングこれらのプロセスの関係をV字モデルにマッピングすると下図のようになります。「Test(品質を保証する)」はV字モデルの右辺すべてにわたります。上図で示したV字モデルの各レイヤーについて順に説明します。「Why」のレイヤーシステム*1を開発する目的(Why)が関心事のレイヤーです*2。その目的が実現されているかを、V字モデルの右辺で検証します。各プロセスの概要は以下のとおりです。V字モデルの右辺の「運用・評価」は「運用」プロセスと「評価」プロセスに分かれます。「企画」プロセス解決すべき問題や取り組むべき課題、創出する価値を定義します。目的を実現するためのコンセプトや方向性、道筋や計画を構想します。「運用」プロセス開発したシステムを実際に運用し、事業を運営します*3。「評価」プロセス企画プロセスで定義した問題が解決され、価値が創出されているかを検証し評価します。業務やシステムで実現すること(What)が関心事のレイヤーです。この「業務やシステムで実現すること(What)」を定義することを、ここでは「要件定義」と呼びます。「システム要件定義」に分かれます。V字モデルの右辺では、大きく以下の2つの内容を検証します。プロセス具体的な業務の構成や業務の流れ、業務の中でのシステムの利用場面(ユースケース)など、業務に求める要件を定義します。「システム要件定義」プロセス業務要件定義で定義したシステムの利用場面(ユースケース)を詳細化し、機能要件や開発項目を抽出します。システム全体に求める性能やセキュリティなどの非機能要件やシステムのアーキテクチャを定義します。「運用テスト(受入テスト)」プロセス業務が実運用できるかどうか、業務要件定義で定義した要件が実現されているかを検証します。開発チームに開発を依頼した担当者が、依頼内容が実現されているかを確認する目的の場合、受入テストともいいます。「システムテスト」プロセスシステム内に配置される各ソフトウェアや外部システムが連携して動作し、システム要件(機能要件や性能、セキュリティなどの非機能要件*4)を満たしているかを検証します。業務要件やシステム要件を満たすために、ソフトウェアをどのような仕様で実現し、ソフトウェアの内部をどのようにを作るか(How)*5が関心事のレイヤーです。V字モデルの右辺では主にソフトウェアが仕様どおりに正しく動作するかどうかという観点で検証します。それに加えて、要件定義で定義した要件を満たすことができるかという観点でも検証します。各プロセスの概要は以下のとおりです。システム要件定義フェーズでリストアップされた開発項目(画面、API、機能など)の仕様を定義します*6。ソフトウェアアーキテクチャー設計、データ全体設計(リレーショナルデータベースを使用する場合、ER図等)などを設計します。「結合テスト」プロセス個々のモジュールやコンポーネント*7を結合し、ソフトウェア全体としての動作を検証します。画面や機能間のデータの連携などをテストします。「詳細設計」プロセス開発の最小単位であるコンポーネントやモジュールを設計します。詳細設計を完了するとプログラミングが可能になります。「単体テスト」プロセスコンポーネントやモジュール単位の動作を検証します。設計に基づき、ソフトウェアを実装すること(Make)が関心事のレイヤーです。V字モデルの右辺ではプログラミングしたコードが可読性や保守性に優れ、品質が高いかどうかを検証します。以下は各プロセスの概要です。「プログラミング」プロセス設計に基づいて具体的なコードを書き、システムの機能を実現します。「コードレビュー」プロセスプログラムコードを査読し、コードが可読性や保守性に優れているか、バグやセキュリティの脆弱性がないか、効率的に動作するかなどの品質を検証します。最後に本記事では、V字モデルの構造について説明しました。V字モデルの各レイヤーの関心事を把握することで、各プロセスの重要なポイントを理解し、力を集中させることができます。各プロセス間の関係を理解することで、他のプロセスの成果物を確認する能力が養われます。他のプロセスの成果物を確認するために必要となるプロセス間の関係についての知識や各レイヤーの詳細な内容は、別の記事で説明します。V字モデルの構造を理解することで、効果的にシステム開発を進められるようになるでしょう。ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。https://x.com/haru860*1:ここでのシステムは狭義のシステムを内包する「広義のシステム」を対象とする。詳細はシステム開発におけるシステムとは何かを参照のこと*2:企画プロセスでは、システムを開発する目的だけではなく、目的を実現するための構想や計画も立案する。システムを開発する目的が、企画プロセスの最大の関心事であり、起点となるため、ここではシステムを開発する目的のみをあげている*3:共通フレーム2013では、「運用」プロセスは運用テストと同じレイヤーに位置づけられている。これは、運用が業務担当者の責任と考えられているためと想定される。Requirements)は、ユーザー視点から見て、ソフトウェアシステムやアプリケーションがどのように動作すべきかを具体的に定義する要件のこと。Requirements)は、ソフトウェアシステムの性能、セキュリティ、使用性や信頼性、効率性など機能以外に関する要件である。*5:「ソフトウェアをどのような仕様で実現するか」=「外部設計」、「ソフトウェアの内部をどのようにを作るか」=「内部設計」と表現することもある。*6:共通フレーム2013では「ソフトウェア要件定義」に該当するが、本メディアでは「基本設計」に分類する*7:コンポーネントは、ソフトウェアシステムの機能的な単位で設計される。特定の機能やサービスを提供する部分であり、他のコンポーネントやシステムとインターフェースを通じて通信する。モジュールは、プログラムを構成するコードの単位で設計される。特定の機能やロジックのまとまりを表し、コードの整理と管理を容易にする。11:30このブログはTRACERY開発チームが運営しています。(トレーサリー)は、システム開発のためのドキュメントサービスです。クラウド上でサクサク設計、手軽に情報をつなぎます。情報共有の手間を減らし、チーム開発にトレーサビリティを導入します。Lab.(トレラボ)ではサービス利用時にも重要になる、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。システム開発が失敗する理由は多々ありますが、一番の理由は今も昔も要件定義です。要件定義を成功させることでシステム開発の成功に近づきます。要件定義の手法、要件定義における課題と解決策、要件定義や設計のアウトプット、モデリングなど、要件定義に役立つ情報を発信します。Lab.(トレラボ)システム開発が失敗する理由は多々ありますが、一番の理由は今も昔も要件定義です。要件定義を成功させることでシステム開発の成功に近づきます。要件定義の手法、要件定義における課題と解決策、要件定義や設計のアウトプット、モデリング、品質向上など、システム開発、ソフトウェア開発に関するさまざまな情報を発信します。5引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。