要件定義（アプリ）タスクの進め方の概要

今回はアプリケーション開発の要件定義タスクの進め方の概要について解説します。

システム構築フェーズの最初の工程は要件定義工程です。
要件定義工程はアプリケーション開発、インフラ構築、移行、運用保守、ユーザー教育、それぞれの観点に対して各種要件を固め、後続作業の計画を具体化する工程です。
システム構築フェーズの一番最初の工程であり、お客様との密なコミュニケーションが必要で難しい工程でもあります。

今回は、要件定義工程の中でも、アプリケーション開発で実施する要件定義を解説します。
便宜上、要件定義（アプリ）タスクと呼びます。

要件定義工程は経験がものをいう上流工程ですので、上流工程に強くなりたいと思うなら、知識を吸収して機会があれば積極的にチャレンジしてみると良いと思います。

アプリケーションの要件定義では機能要件と非機能要件を定め、どんなシステムを作るかを具体化する

アプリケーション開発における要件定義の作業は、大きく以下の2つになります。

機能要件定義とは、新しい業務の流れや、システムが持つ機能（画面、バッチ、帳票、インターフェースなど）を定義することです。

非機能要件定義とは、システムに関する機能面以外の特性を定義することです。

それではひとつずつ詳しく見てみましょう

機能要件定義は業務フローを具体化してシステムに必要な機能を定義する

機能要件定義のゴールは、システムが具備する（＝持っている）機能は何かを定義することです。具体的に言うと、システムに対して

を明確にすることです。

なぜこれらを明確にする必要があるのかというと、

です。

構想立案フェーズで実施した見積は、システムに対する要件が詰められていない状態のため、システムに持たせる機能は想定（仮置き）の状態で見積しました。そのため、最終的に規模がブレるリスクが大きく、コスト・スケジュールも当たらずとも遠からずというレベルでした。

一方で、要件定義ではシステムにどんな機能やデータを持たせるかが具体化されるので、構想立案フェーズより精度の高い見積にすることができます。

もし構想立案フェーズより見積金額が大きくなれば、予算の範囲内に収めるために優先度の低い機能を諦めたり、予算やスケジュールの見直しが必要になります。

もし構想立案フェーズより見積金額が小さくなれば、予算減額（コスト抑制）やスケジュール短縮（リリース日の前倒し）をするのがフェアなやり方です。

システムの機能やデータとして何が必要かを洗い出すには、新しい業務の業務フローを作成し、業務フロー内の各所でシステムにどんなことをして欲しいかを定義していったり、必要なデータがいつどこで発生するかを追っていくことで洗い出すことができます。

尚、新しい業務の業務フローを作成する際は、現在の業務フローも合わせて可視化することをオススメします。
現在の業務フローと新しい業務フローのセットは、ユーザーに対して新しいシステムを導入する上で現在の業務がどのように変わるかを理解する上で非常に重要な情報だからです。
またプロジェクト作業の観点で言えば、システムテストやユーザー受入テストにおけるテストシナリオを作る際、またユーザーマニュアルにおけるシステムの使い方を説明する際に必要になります。

機能要件定義のアウトプット（成果物）としては、要件定義書になりますが、その中でも以下の項目が該当します。

非機能要件定義は「非機能要求グレード」などのガイドラインを基に機能以外の特性を定義する

非機能要件は、機能以外のシステムに対する特性を定義することです。

例えば、

• ユーザー数は何人いて、同時に何人が利用するか
  （例：ユーザー全体で100ユーザー、同時利用者数は40ユーザー）
• ユーザーがシステムを使える時間帯はいつか
  （例：平日の9:00-22:00、計画メンテナンスを除く24時間365日）
• システムが停止せずに利用できる稼働率
  （例：99.9%＝障害によるシステムダウンは1年間で計8.76時間以内）
• データが破損した場合にどのぐらいの期間でいつの時点まで戻せるか
  （例：復旧作業に8時間、一営業日前完了時点のデータに戻る）
• 東日本で大規模な災害が発生した場合、システムは継続して利用できるようにするか
  （例：西日本で待機している予備システムを稼働させ、システムを継続利用できるようにする）
• 画面の表示時間は何秒以内とするか
  （例：画面の表示時間は6秒以内を目標とする）
• セキュリティはどの程度厳密にするか
  （例：インターネットに公開する重要システムのため、社内セキュリティガイドラインの一番厳格な基準をクリアする）

などです。

これらはゼロから考えると非常に大変なので、一般的にはIT関連団体が公開しているガイドラインを土台に検討します。

私の経験では、独立行政法人のIPA（情報処理推進機構）が無償公開している「非機能要件グレード」を利用することが多いです。

非機能要件グレード
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

ガイドラインはボリュームが非常に多く、ITに明るくない方には読むのがしんどい専門資料なので、この中からプロジェクトの特性に応じて必要な項目に絞り、対象となる各項目に対する要件をお客様と詰めていきます。

基本的な進め方として、SIerがまずは仮説ベースで対象となる項目の選別と要件の仮置きを作成し、それをベースにお客様と協議が必要な点をすり合わせて、要件を固める方法がオススメです。（こうすることでお客様の負担が減り、お客様から喜ばれます）

各項目に対して、高いレベルの要件を設定すればより便利にはなりますが、コスト・スケジュールが増えてしまいます。身の丈にあわせたバランスのとれた要件を設定するとコスパが良くなりますので、こだわりがあるところ以外は必要最低限をベースに要件を選択していくと良いと思います。

また各要件を選定する際には、あわせてその要件をどのように実現するかを方針レベル（一言レベルの概要）で定義します。
これをする理由は、実現できない要件を設定して次の工程で行き詰まってしまうことを回避すること、実現方法によってコスト・スケジュールに影響が発生するので見通しを立てて見積に反映できるようにしておくこと、が理由です。

非機能要件定義のアウトプット（成果物）としては、要件定義書の内、以下の項目が該当します。

まとめ

要件定義（アプリ）タスクでは、

を行います。

次工程以降を見据えて、要件定義を通じて意識すべきことは、以下の2つです。

より詳しい内容を知りたい方は、以下の書籍をオススメします。

システム開発のプロセスを記載している書籍で、個人的にバイブルになるほど良い本は正直出会えていないのですが、以下は比較的全体像が書いてある印象です。
そのまま使えるほど具体的なところまで踏み込んではいないものの、参考にはなると思います。

プロジェクト実行大全 Kindle版

また、非機能要件定義については、以下のブログの記事が分かりやすかったのでご紹介します。
カテゴリーで非機能要件をクリックすると該当の記事の一覧に飛べます。

社内SEになりました

社内SEになりました

社内SEは本当に楽なのか？ユーザー系IT企業とSierとの違いは？これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに４０代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

systemengineers.hateblo.jp