こんにちは！データサイエンティストの青木和也（https://twitter.com/kaizen_oni）です！
今回の記事では、これほど要件定義について分かりやすく解説してくれている本は他にないんじゃない？と思える1冊「はじめよう！要件定義 ビギナーからベテランまで」について、私が本書から得た学びについてご紹介していきたいと思います。
本書はイラスト付きであることもさることながら、要件定義がはじめて、もはやエンジニアリングに携わったことがはじめてという方でも理解しやすいようにスモールステップに分解されて要件定義を行うときの手順が書き表されている良書です。
本記事を読んで、本書の魅力が皆さんに伝わるとともに、本書からどのようなことが学べるのかを感じ取っていただけると幸いです！
本書の概要
本書は要件定義について超スモールステップかつ分かりやすい例えをこれでもかと盛り込んだ、要件定義初心者、なんなら要件定義ベテランの方にも多くの気づきが得られるのではないかと思われる良書です。
本書では随所にITの概念をアナロジーに置き換える場面が多用されており、「インプット→処理→アウトプット」のことを「卵→調理→目玉焼き」と置き換えてみたり、
データベースのことを「卵を保管する冷蔵庫」として例えて、人to人で直接卵のやりとりをしなくても冷蔵庫を挟むことで自由なタイミングで出し入れができるということを理解させてみたりと、アナロジーを通じて要件定義周りの概念が非常に分かりやすくなっています。
また、実際に要件定義の手順を進める前に、要件定義までに何を行っておくべきかということまで説明しているおかげで、実際の要件定義のステップが非常に分かりやすくなっていることも大変評価できます。
本書の章立ては以下のようになっています。
- 要件定義って何だろう？
- 要件定義=要件を定義すること
- 要件定義の基本的な流れ
- 定義すべき要件の内訳
- 3つの要素の定め方
- 要件定義の詳細
- 要件定義、その前に
- 企画を確認する
- 全体像を描こう
- 大まかに区分けしよう
- 実装技術を決めよう
- 実現したいことを整理整頓しよう
- 利用者の行動シナリオを書こう
- 概念データモデルを作る
- UIを考えよう
- 機能について考えよう
- データについて考えよう
- 要件定義の仕上げ
- 要件定義、その後に
本書から得た学び
本書全体を通して、要件定義という営みの全体像について理解が進んだことは言わずもがなです。
その上で、要件定義の対する大きな学びや、要件定義以外でも活用できそうな学びについて3点ほどご紹介させていただきたいと思います。
- 要件定義とは必要な「UI」「機能」「データ」を定義すること
- 無茶な要求、衝突する要求の先にある本質的な要求を考えよう
- いい企画とは「利用者便益の観点から精査されている」企画
順を追って説明していきたいと思います。
要件定義とは必要な「UI」「機能」「データ」を定義すること
プログラマがソフトウェアを完成させるために必要な情報が要件として必要な内容ということになります。それが揃えば、プログラマがソフトウェアを作ることができるようになるはずです。
ではその「必要な情報」とはどういうものなのでしょうか。それはケースにもよるのですが、基本的には次のようになります。
羽生章洋『はじめよう！要件定義』(技術評論社/2023) Chapter-03 定義すべき要件の内訳 P19
- UI
- 機能
- データ
本書を読むまでの私の認識では「要件定義とは、顧客と開発者の認識に齟齬がないようにゴールイメージを固めること」ぐらいの認識でした。
一方で、本書では要件定義に必要な情報について上のような3つの要素をあげて説明していますし、「要件」「定義」等の言葉についても厳密に確認をしながら読者を先へと進めています。
これら3つの要素が決まっていれば、確かにプログラマは「どういう見た目で、どのような処理をして、どのようなデータを保持するシステムを構築すればいいのか」がわかるので実際の開発ができそうだ、とイメージすることができます。
本書では上記3つの要素が要件として定義すべきものであることを念頭においた上で、どのように何を定義していけばいいのかまで詳細すぎるほど詳細に、かつ分かりやすく解説をしてくれています。
最終的に本書に沿った要件定義を進めると出てくる要件定義の成果物は以下のようになります。
- 企画書
- 全体像（オーバービュー）
- 利用する実装技術
- 実現したいこと一覧（要求一覧）
- 行動シナリオ一覧
- 行動シナリオ
- ワークセット一覧
- 概念データモデル
- ラフイメージまたはモックアップ
- 画面遷移図
- 項目の説明
- 機能の入出力定義
- 機能の処理定義
- 統合ERD
なお、このうちのUI・機能・データに関わる成果物はそれぞれ以下になります。
- ラフイメージまたはモックアップ、画面遷移図
- 機能の入出力定義、機能の処理定義
- 概念データモデル、統合ERD
要件定義に係る要素はUI・機能・データだけで十分であるはずなのに、なぜこれほどまでに成果物が多いのかというと、それは要件定義段階で必要となる企画段階・アーキテクチャ設計段階で考えるべきことまで踏み込んで解説をしているからになります。
要件定義というのはシステム/アプリ開発の一連の流れにあるからこそ、その前工程での検討が不十分であった場合に、十分な要件定義ができないまま開発工程に進んでしまい、確認漏れや手戻りが発生してしまう可能性が高まります。
そのような要件定義における不備を回避するために、前工程まで考慮した上で本書では解説をしているのです。
無茶な要求、衝突する要求の先にある本質的な要求を考えよう
今回のスコープからあまりにもかけ離れているものや、要求同士の間で矛盾やコンフリクトを起こしているものなどについては分析・整理を行って、本当に実現すべきは何かということについてしっかりと検討すべきです。一見、無茶に思える要求も丁寧に話を分析していくと、その要求の先に本質的な要求があったりするものです。
羽生章洋『はじめよう！要件定義』(技術評論社/2023) Chapter-10 実現したいことを整理整頓しよう P63
このTipsは要件定義に入る前の企画工程の話なのですが、非常に示唆に富んでいると認識しています。
この章では、「やりたいことを書き出す」という工程について説明しているのですが、その中には上記のような矛盾・衝突するような要求も出てくるはずですし、「おいおい、それの実現は無理だろ」と思われるような要求も出てくるはずです。
本来的にいえば、矛盾・衝突するような要求についてはトレードオフの関係について説明して丁重にお断りしたり、無茶な要望については予算・期限感を盾に突き返すこともプロジェクトを健全に進め、しっかりとビジネスに貢献するものをリリースするためには重要になってきます。
一方で、「やりたいことを書き出す」という工程で出てきたということは当然ながらそれらは実現したいことであったり、困り事であったりするわけです。
となった場合に考えるべきは、その要求を叶えることは不可能とすぐさま結論づけることではなく、「その要求が出てくる原因となったオペレーションや困りごとは何だろう」と思いを馳せ、追求することが重要であると本書では指摘をしています。
表面的な要求を掘って掘って出てきた本質的な要求は、表面的な要求とは異なる手段で実現可能かもしれません。
矛盾すると思われた要求も、本質的には同じ方向を向いていたため、両方を叶える別の実現方法に思い至るかもしれません。
本書で指摘している「要求の先の要求」が要求の裏返しだけで考えない、必要な批判的思考だと私は考えています。
いい企画とは「利用者便益の観点から精査されている」企画
企画の良し悪しの差はどこに起因するのか。それは「利用者便益（ベネフィット）の観点から精査されているかどうか」です。
よく混ぜて議論されがちなのですが、成果と評価と効果は違います。成果というのはアウトプットであり、作り手が生み出すものです。目玉焼きの例で言うと、目玉焼きそのものは成果です。
それに対して、それを受け入れる側、つまり「目玉焼きを作って」と依頼した側はその成果、つまりできあがった目玉焼きに対して「美味しい！」とか「イマイチ」などと評価するわけです。その結果として「嬉しい」だったり「満足した」などの効果を引き起こすことになります。
筋の悪い企画は、この中の成果にばかり目がいってしまっていて、評価や効果に対する狙いが非常にあやふやなのです。
羽生章洋『はじめよう！要件定義』(技術評論社/2023) Chapter-06 企画を確認する P42
上記の指摘は非常に考えさせられる指摘です。
顧客の要望から要件（UI・機能・データ）に落とし込み、開発を行って成果物ができたとします。
その間に顧客からフィードバックを得ずに作っていけば確かにプロダクトは完成するはずです。
ですが、そのプロダクトは本当に顧客から良い評価を得られるプロダクトなのでしょうか。
そのプロダクトは本当に顧客が使って業務上の効果を得られるプロダクトなのでしょうか。
この発想は「コンサルが『最初の3年間』で学ぶコト 知らないと一生後悔する99のスキルと5の挑戦」に登場する「タスクバカ」の発想に似ています。
上から降りてきた開発すべきUI・機能が「顧客にどのような便益をもたらすのか」まで考えきれていなければ、当然ながら顧客に便益をもたらすのかどうかは偶然の産物になってしまいます。
そのために、たとえばアジャイル開発においていえば、デモをプロダクトオーナーに見てもらうことで、「このUI・機能は本当に顧客・ユーザーにとって便益をもたらすのか」の視点を適宜確かめながら開発の方向性を修正したりするわけです。
アジャイル開発における「デモをプロダクトオーナーに見せることの重要性」については以下記事でも解説しておりますので、合わせてご覧ください。
ウォーターフォール型の開発についていえば、常に顧客に対する効果を念頭に置きながら、成果物としてのUI・機能・データを考えていく必要があります。
要件定義段階で顧客と効果について会話を進めるためには、最終的な成果物のイメージがつきやすいようにモックアップを作成する必要もあります。
そのようにして顧客の便益を常に見据えて仕事をすることこそが、顧客にとっても開発者にとってもWin-Winな仕事になるのではないでしょうか。
まとめ
今回の記事では、要件定義のビギナー書「はじめよう！要件定義 ビギナーからベテランまで」について、私が本書から得た学びについてご紹介しました。
本書は要件定義のビギナー書としても優れていますが、「開発という活動を通じて、いかに顧客のビジネスに貢献するか」についても考えさせられる良書でした。
皆さんもぜひ本書を手に取って、みんなが幸せになる要件定義について学んでみてください！
コメント