Hello Ecomott!
こんにちは、あるいはこんばんは。
お久しぶりのクラウドソリューション開発部 伊藤です。
以前執筆した記事からもう2年も経ちました。かなりの遅筆っぷりでございます。
おかげ様で前回記事はぶっちぎりのバズりっぷり。2年経った現在でもまだそれなりに数字が回っている次第です。本当にありがとうございます。
気づけば、もう8月も終わりですね。
新人エンジニアの皆さんも、プロジェクトに配属されて少しずつ慣れてきた頃でしょうか。
中には、クライアントの要求を誤解してしまい全く違う機能を実装したり、重要な要件を見落として怒られたり……そんな「洗礼」を受けた方もいらっしゃるでしょう。
「こんな自分はITの仕事に向いてない！」と落ち込んでいる方もいらっしゃるかもしれません。
まあ辞表を出すのはお待ちなさい。今回は、そんな悩める皆さんに、「向いてない！」と絶望する前にぜひ読んでいただきたい「要件定義」についての入門記事をお届けしましょう。
この記事を読むのにかかる時間は 約8分 くらいです！
この記事でわかること
はじめに：
まず、最初に断っておくことがひとつあります。
要件定義に、明確な「答え」は存在しません。
なぜなら、要件定義こそが「答え」を作る工程となるからです(名言のつもり)。
すなわち、どんなプロジェクトにおいても、0から1を生み出す作業となるのです。
よって、よりよい要件定義の実現のために必要なテクニックは、イコールで「原理原則」の理解と「思考法」をモノにすることになります。
というわけで、本記事ではまず、要件定義の「原理原則」とねっとりと向き合っていきましょう。
原理原則：要件定義の第一歩「要件」を理解する
要件定義の解説に入る前に、まずはその前段階である「要件」そのものについて理解を深めましょう。
原理原則：「要件」とは？
これからの話題は、弊社TechBlogを欠かさずチェックしているような凄腕エンジニアの皆さんにとっては、わかりきった話かもしれません。
しかし、新人だった頃、その意味するところの複雑さを思い出してみていただきたい！
実装内容が二転三転したり、仕様変更が頻発したりで炎上したあのプロジェクトを。
あの日の怒りを思い出しましたね？
まずは今一度基本に立ち返り、普段どのようなことを意識しながら「要件」を成果に落とし込んでいるか整理してみましょう。
「要件」とは、システムやソフトウェアが満たすべき条件や機能のことです。
経済産業省のIT政策実施機関であるIPA（独立行政法人情報処理推進機構）が「要件定義ガイドライン」で定義しているところによると、「要件」は具体的に以下の3つに分類されます。
| 要件 | 定義 | 例 |
|---|---|---|
| 機能要件 | システムが提供すべき具体的な機能やサービス。 | 商品の検索、チャットでの問い合わせなど |
| 非機能要件 | 性能、信頼性、セキュリティなど、システムの品質に関する要件。 | ページの表示速度、個人情報保護など |
| ビジネス要件 | ビジネスプロセスや業務フローに関連する要件。 | 売上の増加、コスト削減、顧客満足度の向上など |
こうして見ると、まだピンとこない方もいらっしゃるかもしれませんね。それでは、もう分解して考えてみましょう。
「要件」は「どこから」来るのでしょうか？
答えは簡単です。システムを望む「ユーザー」です。つまり、多くの場合、開発を行うシステムを必要とする「ユーザーの要求」について、必要なものを細分化して定義したものが「要件」となります。
「ユーザー目線で」要件を考える
システムやソフトウェアが提供すべき具体的な機能やサービス、品質に関する「ユーザーの」期待やニーズのことです。ユーザーの視点から、先ほどの3つの要件をわかりやすく整理してみましょう。
機能要件 = 期待される機能
ユーザーがシステムを使用する際に必要とする具体的な操作やサービスのことです。
例えば、オンラインショップであれば、商品検索機能やカートに追加する機能がこれに該当します。ユーザーが目的を達成できるようにするための条件といえるでしょう。
非機能要件 = 品質の期待
システムの性能、信頼性、使いやすさなど、ユーザーが求める品質基準のことです。
例えば、システムの応答時間が短い、操作が直感的でわかりやすい、データの保護やシステムの安定性などが該当します。ユーザーが安心してシステムを利用できるようにするための条件といえます。
ビジネス要件 = ビジネス価値
システムがユーザーの業務やビジネスプロセスにどのように貢献するか、ということです。
業務効率の向上やコスト削減、顧客満足度の向上などが挙げられます。システムがビジネス価値を高めること、ユーザーがそのシステムを利用する意義を感じるために必要な条件といえます。
このように「ユーザー目線で」言い換えてみると、「要件」というものがどういうものなのか、ぼんやりと見えてきますね。
端的に言ってしまえば、「要件」とは、ユーザーのニーズと、その実現に至るまでの道のりをできる限り細かく細分化したものだと言っていいでしょう。こうした「要件」を明確化していく中で、プロジェクトの方向性が定まり、「どういうサービスを作り上げるか」という共通理解が生まれます。
すなわち、「要件定義」とは、本当に書いて字のごとく、こうした「要件」について明確に定義付けを行い、明文化していく作業に他ならないということです。
原理原則：要件定義とは？
前述で「要件」とはどのようなものか掴んでいただけたと思いますが、要件の明確化はプロジェクトの成功において、非常に重要な要素です。
明確な要件がなければ、プロジェクトは方向性を見失い、最終的な成果物がユーザーの期待に応えられない可能性があります。
IPAの「要件定義ガイドライン」にも、プロジェクトの失敗の原因の過半数が、要件定義に起因するという研究結果が掲載されています。
要件定義は技術ではなく、本質の部分です。
どのようなツールやフレームワークが生まれても、失敗の割合の大半を占める状況は未来永劫変わらないでしょう。ここを解決できたらノーベル賞はほぼ確定レベルです。
話を戻すと、「要件」とは、「ミスったらプロジェクトが破綻する」要素であることがデータとしても立証されているわけです。
上述を踏まえると、つまり「要件定義」とは、そんな「要件」を万が一にも取り違えたり、取りこぼしたりすることがないように、要件を明確に「定義」し、「明文化」することで、各ステークホルダー間で共通認識を持つ工程、それこそが「要件定義」となります。
要件定義の目的
要件定義は、以下の3つの効果を期待して行われる工程です。
- プロジェクトの方向性を明確にする
- ステークホルダー間の共通理解をつくる
- リスクを最小限に抑えるための基準の明確化
これらが不十分であれば、エンジニアにとってはできれば起きてほしくない、炎上の火種になるのは必至です。
要件定義が不十分な場合におきる悲劇
- プロジェクトの方向性の迷走: プロジェクトの目標が曖昧になり、チームが異なる解釈で作業を進めてしまう。
- リソースの無駄: 無駄な作業や不要な機能の開発に時間的・人的・金銭的リソースが費やされる。
- スケジュール遅延: 方向性が定まらず、プロジェクトが予定通りに進まない。
- つらい：つらい(迷走しているプロジェクトは本当に精神的につらい)
これらの結果、プロジェクトはグダグダになる原因となります。エンジニアにとっては本当に怖い話です。こうならないためにも、要件定義は真剣に行うべきなのです。
実践演習！ざっくり要件定義してみよう
初心者向けに、IPAの「要件定義ガイドライン」に準拠する形で、要件定義の基本ステップを見ていきましょう。
要件定義の基本ステップ
- ヒアリング: クライアントやユーザーから直接話を聞き、ニーズや期待を把握するプロセスです。SEが技術者の観点から、より詳細な定義を行うためのヒアリングを行うのが一般的です。
- 現状分析: 現在の業務プロセスやシステムを分析し、改善点を見つけます。収集した情報を整理し、具体的な要件に落とし込むフェーズです。
- 要件の整理: 集めた情報を整理し、要件を分類します。重要度や緊急度に基づいて、実装の優先順位を決定するために重要なフェーズです。
- 要件定義書の作成: 整理した要件を文書化し、クライアントやチームと共有します。関係者全員が理解できる形にまとめるフェーズです。
- レビューと合意: 要件定義書をクライアントと確認し、合意を得ます。レビュー会議を開催し、フィードバックを受け取ります。
これらの基本ステップは、社内文化や事情で順番が前後することもありますが、大きく変わることはないでしょう！！
ーーいや、やっぱり少しイメージしにくいので、身近な「レストランとお客様」の例で考えてみましょう。
レストラン・エコモットの例で考える要件定義
【前提】
お腹を空かせたある食いしん坊ーー男性かもしれないし女性かもしれない。若いかもしれないし年配かもしれない。特にお金持ちという雰囲気はないーーが、「美味しいものが食べたい。できるだけお財布にはやさしく」と考えています。
これは、要件定義の前段階である「要求定義」と捉えることができます。
- ユーザーのニーズ: お腹が空いている、美味しいものが食べたい、財布にやさしい価格
- ユーザのペルソナ：
- ①かなりお腹がすいている = 出来るだけ急ぎで食べたい
- ②食いしん坊である = しっかり食べて満足したい
- ③お金持ちではない = 価格は手ごろに抑えたい
- 制約条件: 価格が高すぎないこと
レストラン・エコモットに入店した時点で判明している要件を落とし込むと、以下のようになります。
- ビジネス要件: 美味しい料理を手頃な価格で食べて満足感を得たい
- 機能要件: メニューに美味しい料理が含まれている、価格が手頃である
- 非機能要件: 提供時間が短い、サービスの質が高い
- 制約条件: 予算内に収まること
レストラン・エコモットは柔軟なオーダーが売りです。早速ウェイターがお客様にヒアリングに伺います。
【1. ヒアリング】
ウェイターが「今日は何を召し上がりますか？」と尋ね、お客様の好みやアレルギーなどの情報を収集します。これは、クライアントやユーザーから直接話を聞き、ニーズや期待を把握するプロセスに相当します。
一方、厨房では敏腕シェフの伊藤さんが、冷蔵庫とにらめっこしながら現状分析に勤しんでいました。
【2. 現状分析】
伊藤シェフは、「今ある材料でこの料理を作れるか？」と考え、在庫や調理設備を確認します。これは、現在の業務プロセスやシステムを分析し、改善点を見つけるプロセスに相当します。
【3. 要件の整理】
ウェイターが注文内容を厨房に伝えます。「お客様はステーキをミディアムレアで、サラダはドレッシングを別にしてほしいと言っています」。これは、要件を分類するプロセスです。ウェイターは情報を整理し、キッチンスタッフに伝えるためのメモを作成します。
シェフは、受けた注文を機能要件、非機能要件、制約条件に分類します。
- 機能要件: ステーキの焼き加減（ミディアムレア）、サラダのドレッシング（別添え）
- 非機能要件: 提供時間（迅速に）、サービスの質（高品質）
- 制約条件: 予算（財布にやさしい価格）
これら整理できた要件を踏まえ、シェフは調理手順を考えます。
【4. 要件定義書の作成】
伊藤シェフは、「まずステーキを焼いて、その間にサラダを準備しよう」と、具体的な調理手順（優先順位）を決めます。これは、整理した要件を文書化し、チームと共有するプロセスに相当します。
【5. レビューと合意】
料理ができあがり、盛り付けを終えた後、お客様にお持ちする前にレビューを行います。
- 内部レビュー: シェフとキッチンスタッフで、要件通りにできているか確認します。「ステーキはミディアムレアで、サラダはドレッシング別添えです。要件通りですか？」と確認します。
- クライアントレビュー: 料理をお客様に提供し、「ご注文の品でお間違いございませんでしょうか？」と確認します。
- 最終承認: お客様が召し上がって「美味しかった」「また来るよ」と言ってくれることを「最終承認」とします。
この例では、オーダーミスなく、ご要望通りの料理を提供できたようです。お客様は非常に満足し、SNSにもアップされ、レストランは絶賛の嵐。プロジェクトとSNSは燃やさず、鉄板を燃やす。シェフ伊藤は明日も料理を続けていくのです。
いやー、いい話ですね。エンジニアの皆様が把握しやすいように図示するのであれば、以下のような流れを踏んでいることがわかります。
この例はかなりデフォルメしていますが、ITプロジェクトにおいても「お客様（ユーザー）」と「サービス提供者（例でいうレストラン）」が存在し、両者間で合意した要件に則り、ニーズの実現のためにプロジェクトを進めていくという構図は変わりません。
日々の仕事を通して、「要件定義」の思考法を鍛えよう
ここまで読んで、「あれ？これって上流工程の話で、俺たちには関係なくない？」と思われたかもしれません。
そう考えたあなた、シゴデキになりたければ、今すぐその考えは捨てましょう。
「要件定義」に一番重要なのは思考法です。スケールを最小単位まで落とせば、皆さんの日々の仕事にも応用でき、仕事の「質」を向上させることにつながります。そしてそれが、「要件定義」を行なうための思考トレーニングとなっていくのです。いやホントに。
- 1. 機能要件: 具体的なタスクの達成条件や成果物を明確化する
自分が抱えているタスクについて、具体的なタスクや成果物を明確に定義することは、立派な「要件定義」です。
例えば、「特定の機能を実装する」「バグを修正する」といったタスクに対し、何を達成すべきかを明確にし、必要な作業を逆算することで、効率的に作業を進めることができます。 - 2. 非機能要件: 作業の品質や効率について、基準を明確化する
作業のパフォーマンスやセキュリティ、メンテナンス性など、ユーザーが求める品質基準を明確化します。
単に動作するコードを書くのではなく、品質の高いコードを書くことを意識したり、内部的な期限を決めておくことも、かなり広義にはなりますが「要件定義」の第一歩と言えるでしょう。 - 3. ビジネス要件: 自分の作業がビジネスにおいてどんな役割を果たしているか明確化する
今の自分の仕事がどのようにビジネスに貢献するか、リーダーに尋ねてみたり、調べてみたりしましょう。
自分の作業が具体的にどう役に立っているのかわかれば、案外楽しくなってくるものです。自分の作業の重要性を理解し、その責任を意識することは「ビジネス要件」の最小単位と言えます。
要は、自分の仕事を「要件」と捉えて細分化し、自分の中で管理しやすいように落とし込んでいくことで、仕事の理解を深めることができます。「小手先の技術」は決して「本質の考え方」に勝るものではありません。正直、技術は一番どうにでもなる部分です。「誰のための」「何のための」仕事であるかを理解し、ユーザーに喜んでもらえるシステム・サービスを提供できるエンジニアを目指しましょう。レストランの例のように、日頃から少しでも意識していけば、決して難しいことではありません。まずはできる範囲で試してみてください。
まとめ
- 要件とは、システムやソフトウェアが満たすべき条件や機能のことである。
- 要件定義とは、要件を明確に定義し、合意するものである。
- 要件定義は、プロジェクトの方向性を明確にし、ステークホルダー間の共通理解をつくり、リスクを最小限に抑えるための基準を明確化する。
- 要件定義は仕事の本質の部分であり、自身のタスクにも落とし込んで理解を深めることができる。
レストラン・エコモットの例からも学べるように、要件定義を成功させるためのポイントは、ステークホルダーとの密なコミュニケーションと、要件の優先順位付けです。また、常にユーザーのニーズを第一に考え、柔軟に対応することが重要です。
本記事を読んだ新人SEの皆さんが、これらのポイントを押さえて効果的な要件定義を行い、プロジェクトを成功に導けるエンジニアに成長していく一助となれましたら幸いです。
次回はより実践的な内容で、お会いしましょう！
【Appendix】
今回の内容は『IPA 要件定義ガイドライン』を参考にしています。
より詳細な情報が必要な方は、そちらも併せてご覧ください。
ちなみに公文書は長くて堅苦しいので、睡眠不足の方にオススメ
【採用情報】
エコモットでは、共に「未来の常識を創る」スタッフを随時募集しています。
弊社に興味がある方はぜひ下記の採用ページをご覧ください！
