はじめに
Wemotionでは「スキル向上による給与UPの好循環サイクル」という持続的な給与UPを実現するため、全社的な取り組みとして学習支援を行っています。学習支援の一要素として定期的な社内勉強会を開催しています。
そんな社内勉強会の第2回目として開催した「要件定義 前編」について、社外向けにも概要を公開します。（第1回 社内勉強会 「セキュアプログラミング」はこちら）
※ ページ下部に勉強会で使用した実際の資料（全ページ）を入手する方法も記載しています。
要件定義 前編の学習内容
ウォーターフォール モデルのシステム開発の全体像について理解を深め、一般的に上流工程と呼ばれる要件定義と設計について数回に分けて詳しく学んでいきます。今回は要件定義の前編（前半）で扱った概要を紹介いたします。
システム開発の全体像
ウォーターフォール モデルのシステム開発では、以下の流れでシステム開発を行うのが一般的です。
要件定義 → 設計 → 開発 → テスト → リリース → 保守運用 フェーズがあり、システム開発と聞いて多くの方が一番に連想する開発フェーズは、工数で全体の3~4割程度になります。そして開発の前の要件定義と設計のフェーズを一般的に上流工程と呼ぶことが多いです。
Vモデル
ウォーターフォールの各フローを以下のように細分化し、要件定義からシステムテストまでV字型に配置したVモデルという考え方があります。
Vモデルでは左右がペアになっており、左側で作成したものを右側でテストするというモデルになります。
例えば、詳細設計に不備がある場合は開発後の単体テストで比較的すぐに発見できます。
一方で、要件定義の不備は開発後の単体テスト、結合テストと進んだ先の最終段階のシステムテストでテストされるため、不具合が発見された時にはプロジェクトとして非常にまずい状況になります。
故に要件定義は不備がないように設計に入る前にしっかりと確認を行う必要があります。
要件定義の内容（前編/後編）
要件定義 前編で扱った内容は 「要件定義について」〜「業務要件」で、次回の勉強会の後編で「システム要件」〜「非機能要件」を扱います。
- 要件定義について
- 下調べと段取り
- 業務要件
- システム要件
- 機能要件
- 非機能要件
要件定義について
要件定義とは、システム利用者（ユーザー）と提供者（ベンダー）が協力して行う最初の取り組みで、開発するシステムにおける「要件（求められる条件）」を「定義する（言葉で明確に範囲を定める）」ことです。この「要件」と「定義する」について詳しく見ていきます。
要件と定義
「要件（求められる条件）」に似た言葉人「要求」と「要望」があります。
それぞれの関係性は以下のようにオニオン チャートのような図として表すことが出来ます。
「要望」には単なる夢やわがままが含まれ、「要求」には限られた予算・期間で実現できないものが含まれます。
システムを開発する目的に対して、「要望」から取り組む価値があるものを絞り込み、「要求から」本当に必要なものを絞り込んだ上で、最後に残るものが「要件」となります。
そして要件定義の「定義する（言葉で明確に範囲を定める）」とは、まさにこの「要望の中から取り組む価値のあるものを吟味し要求を絞り込み、実現する範囲を定める（定義する）」という意味になります。
要件定義の目標
要件定義の目標は、ユーザーから網羅的に要求を引き出した上で合理的に判断し、「事業目標の実現のためにシステムに求められることを定義する」ことになります。
要件定義のゴール
要件定義のゴールは、「システム規模の見積ができた上で『設計』作業に必要な情報の引き継ぎができる状態にすること」になります。
要件定義を行ったベンダーが引き続き「設計」を請け負うケースだけではなく、他のベンダーが途中参加で「設計」を行うケースもあるため、引き継ぎが出来る状態に仕上げる必要があるのです。
下調べと段取り
要件定義を行う際には、ユーザーの状況についての下調べを行い、段取りを決めて要件を定義することが大切です。
下調べ
ユーザーの状況についての下調べでは、具体的には以下の要素についてリサーチ&共有を行うと良いとされています。
- 事業目標
- プロジェクトの目標をユーザーと同じ視点理解する
- 対象範囲の確認
- プロジェクトを取り巻く環境や背景を理解し、プロジェクトの対象範囲を確認する
- ステークホルダーの認識
- 直接関係するステークホルダーだけでなく、間接的に関わり影響を与えたり与えられたりする人やグループを認識する
段取り
要件定義の基本的な進め方を決め、以下の段取りを整えて明文化するようにします。
- 進め方の策定
- ジャッジのための基準作り
- 計画書の作成
要件定義作業の進め方の策定
要件定義作業の進め方では以下の2要素が大切です。
- やるべきこと（ToDo）
- 具体的に何を、いつ、誰がやるかのスケジュールと役割分担を決め、ToDoごとに工期と工数に無理がないか点検してガントチャートに落とし込む
- コミュニケーションの取り方
- インタビュー、討論、レビュー会、報告会などで、誰に集まってもらうか・いつどこでどのように実施するかを決めておく
ジャッジのための基準作り
優先順位付の判断基準などを決めておく
- 優先順位付け
- 例）効果が早く顕れる選択肢を優先する
- 例）コストが低い方を優先する、など
- 合意と承認
- 例）多数決で決める
- 例）役員会に一任する、など
計画書の作成
進め方やコミュニケーション方法など、さまざまな領域で段取りを事前に策定し、計画書にまとめて関係者の間で共有して合意を得るようにします。
業務要件
業務要件は以下の3つの要素に分類することができます。
- 業務フロー
- 業務の組み立て（処理の順番）に注目
- ビジネス ルール
- 業務に適用する枠組み（規則や基準）の整理
- 入出力情報
- 入出力される情報の種類や性質の洗い出し
また、これらを1つの図で表すと以下のようになります。
業務フロー: プロセスとしての処理の順番、組み立て部部分
ビジネス ルール: プロセスとしての処理のルール
入出力情報: プロセスの前後
業務要件の調査
資料を入手する
以下のフォームを送信すると、入力いただいたメールアドレス宛に資料の共有リンクを自動でお送りします。
※ 資料の共有リンク以外に、WemotionのPRメールをお送りする場合があります。