要求定義や要件定義の基礎を知ろう
システムを作るときや製品を作るときに、何をしたいかを考えた後に、で、どうしたらいいのかなと考えます。
要するに目的が何か、そのしたいことは何か、実際に実現することは何かを可視化する。これが要求定義と要件定義です。発注者と開発者との合意を形成するための基本中の基本の機能です。
それなのに、要求定義や要件定義の本はたくさん出ていますが、残念ながら、多くのものが発想法の域を出ていません。
そこで要求定義や要件定義について改めて整理していきます。
ソフトウェア開発において、AIによるコーディング、ノーコード、AIによるテスティング、さらに、プロンプトエンジニアリングなどが注目されていますが、要求、要件の定義はその基盤をなすものです。基礎中の基礎を押さえておきましょう。
要求とは何か
IEEEでは「要求（Requirement）」を以下のように定義しています。
問題解決または目的達成のためにユーザが必要とする条件や能力
契約、標準、仕様、あるいは他の正式文書を遵守するために、システムやシステムコンポーネントが満たす、または保持しなければならない条件や能力
上記のような条件や能力を文書で表現したもの
そもそも、要求に近い言葉に要望や要件がありますがその違いは何でしょうか。
要望とは、関係者が望んでいるもの
要求とは、関係者の誰かが望んでいて、何とかしなければならないもの
要件とは、実現しなければいけないもの
ということで、要求は各種制約で実現できないことがありますが、要件は仕様に記述され、プロジェクトの中で管理されていきます。もちろん、環境変化により、要求事項がプロジェクト中に要件化されることもありますし、要件であったものが要望化されることもあります。
ここが、きちっとしていないとシステムは作れません。よく、ブランコの風刺画で要求定義の難しさを伝えていますが、製造においては以下のイメージで表すことができます。
機械工学であれば、要求は図面（モデル）で表現され、設計とシミュレーションなどによる検証を繰り返されます。そして、ロボットで製造し、イメージ通りのものを作ることができます。
一方、ソフトウェアでは、発注者が「こんなイメージ」と発注し、その隙間を想像しながら物を作っていくので、手戻りも発生し、最後にイメージと異なるものができたりします。
しかも、機械工学のように正確な図面（モデル）が存在せず、その工程にきちんと管理する方法も確立していないため、作る人によって違うアウトプットになります。
これは、ソフトウェア業界を批判しているわけではありません。機械工学は、数百年の歴史があり、それがゆっくりと進化してきたので方法論の確立ができていますが、ソフトウェアエンジニアリングは、100年足らずの間に急速に進歩したので、開発方法論が追い付いていけていないという事情があるのでしょうがありません。
要求定義の考え方を学んでいきましょう
要求定義の方法論の中で、個人的にわかりやすいなと感じているのが、Wiegersのソフトウェア要求で説明される以下の考え方です。
上半分の要求開発で、マーケットや関係者の声を集め要求としてまとめ、そのうちの実現するものをベースライン要求として決定します。そして、下半分の要求管理において、プロジェクト期間を通じた要求変更プロセスを管理していきます。そして常にベースライン要求が明確になっていればよいのです。
このような要求定義をまとめた考え方にBABOK（Business Analysys Body of Knowredge）があります。
外側のループで、要求の計画や全体管理を行うとともに、要求を顧客から引き出し、協調します。そして、内部のサイクルで定義や要求管理をしていきます。
具体的な作業に興味のある人はBABOKを読んでみてください。
実際の要求管理はどのように行われていますか
要求管理は、以下の条件を満たす必要があります。
誰もが共通の理解ができる表記であること
記述や変更がシンプルにできること
組織横断でも理解しやすい手法であること
様々な観点から検討できること
国内では多くの場合、要求リストにして独自の方法で管理しており、こんな感じの表もよく見かけます。
そして概要設計として業務プロセスなどのモデルが書かれています。
国内のモデリング導入状況
2023年のIPAのソフトウェアの調査では、多くの企業が要件定義でモデリングツールを使っています。
一方、モデリングを使っているのに、モデリングツールではなく、オフィスツールにお絵かきしている気配が見られます。
そこで、IPA調査のCSVデータを使ってさらに分析してみました。SysMLやUML等のモデリングを使って要件定義をしている人が、その後、どのように用件を管理しているか見てみると、そのあとの要件管理についてはタスク管理ツールの活用やドキュメント管理など、若干意識が高いことがわかります。
一方、その後の設計についてみてみると、機能、プロセス、データともにオフィスソフトのような汎用ツールや簡易ツールの活用をしていて、高度なモデリングツールと使っているところは少なく、モデリングを効率的に活用できていないことがわかります。
その理由を探るためモデリングの課題について確認すると、モデリングできる技術者が不足していることがわかります。
これは、需要が多すぎてモデリングできる技術者が欠けているというよりも、日本ではこれまでモデリングを重視してこなかったから基本的母数が少ないということではないでしょうか。
要求管理はモデリングが必須です
要求を正しく伝えるにはモデリングが必須です。しかも標準化されているものが望ましいです。標準的なモデリング手法を使うことで、同じ手法を様々なプロジェクトで適用し、エンジニアの能力が向上しやすくなり、教育コストも削減されます。
要求定義には、機能モデル、プロセスモデル、データモデルの3点が必要です。この3つでソフトウェアの骨格がわかります。また要求を直接表すモデルは、SysMLやarchimateに記述できる図があります。
システム構成図などの実装方式は要求定義後の設計で作ればよいものです。
要求モデル（Requirement Model）
OMGが推進するUMLを拡張したモデリング言語のSysMLにはRequirement diagramがあります。要求を詳細化したり階層化したり、関係性を明確にしたりすることができます。制約条件も記述できます。
ユースケース図で示す利用パターンやブロック図による機能構成などと合わせて使いことで要求を明確化することができます。一方、多くのツールに搭載されているもののSysMLのバージョン２の正式版がなかなか出ないなど普及が進んでいません。
要求モデルではないですが、アーキテクチャ記述言語であるarchimateは、モチベーション要素の記述として要求モデルを記述することができます。
このように、ゴール、関係者、原則、制約を明確に記述できます。
以下はサービス提供の利益改善について分析した例です。
この図で、右上にひし形がついているのが要求です。上の図は一番上にあるゴールを実現するアウトカム、そのための原則と要求を表しています
機能モデル（Function model，Activity model）
日本では機能モデルが省略され、機能一覧のような簡易な図やツリー図で示されることが多いですが、機能モデルは業務を根本から整理、改革する上で非常に大事な役割を担っています。
基本的考え方はIDEF０に表されており、古典的な手法ですが考え方を学んでおくと役に立ちます。
機能は、Input、Control、Output、MecanismのICOMといわれる要素で構成され、機能名は動詞で記述されます。
要するにこの機能で処理をされる情報は何で、機能の活動を行うことで何の情報が生成されるかが記述されるだけでなく、それはどのような制約条件で、何（人やシステムなど）を使ってその活動をするかを表記できます。
対象をほぼ最大6個のアクティビティで構成し、それを以下のように階層化する構成になっています。
機能モデルを考えることで、全体業務の組み換え、情報やリソースの洗い出しをすることができます。
SysMLでは、ブロック図を使うことで、各機能やその関係性を表すことができます。
Archimateでも、機能モデルをBusiness Layerで記述することができます。
プロセスモデル（Process Model）
プロセスモデルは、業務のプロセスを流れで示します。業務改善に使われるとともに、マニュアルに掲載したり、プロセスモデルを使ったシミュレーションも行われたりします。
プロセスモデルは、国内では自由にフローを書く人もいますが、BPMNやUMLのアクティビティ図が使われることも多いです。
UMLのアクティビティ図は、少し技術よりという人もいます。また概要プロセスであれば、archimateで記述することも可能です。
データモデル（Data Model，Information model）
データモデルは、データがどのような項目で構成されているかを示します。データの明確化というと、一覧表でデータを定義しようとする人が多いですが、構造を明確にして使いやすいデータにするため、昔からER図（Entity-Relation）で表記されることもあります。しかし、ER図にはいくつかの記法の流派があるので、最近ではクラス図をER図代わりに使用することが増えています。
要件定義においては、システムの中核となるマスターデータの管理が重要になります。国際的に参照モデルといわれるひな形があるので、そういうものを活用することも重要です
このような要求明確化への課題は何でしょう
このように要件定義は重要で、手法論もあるのですが、なぜ、モデリングを使った進め方がされてこないのでしょうか。
モデリングに対する正しい理解の不足
モデリングには記述制約があって使いにくいという人がいます。それはそうではなく、誰もが使いやすく理解しやすくするためにシンプル化していることを理解する必要があります。設計者が勝手なルールで注書きとかした場合、それが相手に正確に伝わらないリスクが発生してしまいます。
印刷を前提に考えている
モデリングツールは印刷できないという人もいます。確かに、多くのモデリングツールは画面で全体把握することが難しい面があります。しかし、モデリングというのは画面の中でブレイクダウンして検証したり、シミュレーションしたり、印刷ではできない有効な機能があります。よって、サブディスプレイをつけて作業エリアを広げることが重要です。
さらには、それらも活かしつつプロッターで印刷したり、ツールと紙をうまく組み合わせていくことがポイントになります。
ユーザーを馬鹿にしている
よく、「モデリングはユーザーに理解できないから」とモデリングを入れない理由をいう人がいます。ユーザー側も「そんな、わけのわからない図を持ってくるな」と言っている場合も多いです。そのため、政府などではDMM（Diamond Mandara Matrix）という簡易な記述法をいまだに使っているところがありますが、このため要件管理ができず失敗プロジェクトになっている事例もよく見かけます。
海外では、ユーザ向けのモデルの読み方のトレーニングコースを用意するのが一般的で、ベンダ・ユーザ双方の合意形成ツールとして使われています。そのような、要求定義を高度にしようとする前向きな姿勢が必要ではないでしょうか。
ツールの費用を出さない
ツールを使うことで論理チェックや齟齬をなくすことができるのに、多くの企業が、無料の簡易ツールやオフィスツールで作っています。
品質や生産性向上のためにツールへの投資を惜しんではいけません。図面を書くのにCADを入れたりするのと同じように専用ツールできちんと管理する必要があります。このようなツールが短期開発や部品の再利用にもつながっていきます。
これからに向けて
調達時に要件を固めて発注していくわけですが、要件の明確化、そのあとのタスク管理等を組み合わせ、企画から運用まで要件を管理していく必要があります。
そうすることで、DevOpsも進めやすくなるし、改善時のプロセス確認、改善効果の事前シミュレーションも可能になります。AIやノーコード／ローコードを使いこなすにも必須の知識です。
ポエムのような仕様書からの脱却はもちろんですが、独自の手法で手書きで書いた矛盾や抜けだらけ、しかも硬直的な要件から脱出していきましょう。
この記事が気に入ったらサポートをしてみませんか？