RDRA 2.0 をたしなむ - 4つのレイヤーの取り扱い方①

どうも、RDRAの経験が2週間ぐらいになったエンジニアです。

前回のRDRAの記事では、「4つのレイヤーの役割を明確にし、その役割に必要な事柄を定義することで要件を決めていくこと」という定義を確認しました。

今回は、この4つレイヤーの中でビジネスサイドの状況をまとめる2つのレイヤーについて大まかにどのような要素を取り扱えばいいのかを確認していきます。

このレイヤに関して、書籍では下記のように定義されています。

「誰に価値を与え、そのために誰が関わるのか？　同じく価値を与える外部システムとそのために必要な外部システムはあるか？」を明らかにします。

その上でシステムに関わる人の要求を整理し、システム化の方向性を明示します。

そして取り扱うものは下記の範囲となります。

対象業務に関わる人(アクター)を洗い出す

関係する外部のシステムを洗い出す

システム化への要求を捉える

個人的には、このレイヤーに対して下記の解釈をしています。

2つ目の解釈の補足をしておきますと、具体化した要求だと変更がかかりやすくなると思います。

例えば「スマホの画面からワンタップで出勤の登録をしたい」みたいな要求だと、「Amaoznダッシュボタンのようなワンプッシュで出勤を登録できる機器を使いたい」みたいに簡単に要求が置き換わってしまします。（そして要件定義の途中、もしくは終わったあたりでこれが発生すると、目も当てられません・・・）

なので、要求を抽象化して方法を幅広く模索できるようにしておくことも求められるのかなと考えてます。

ここではビジネスサイドでの仕事の流れを具現化するフェーズになります。

書籍を引用すると、下記が取り扱う範囲になります。

システム化対象の業務を捉える(業務)

業務を実現する価値の単位を明らかにする(ビジネスユースケース)

価値を実現する業務の流れを捉える(業務フロー)

価値を実現するシーンを明らかにする(利用シーン)

ビジネス価値を出すための業務をもれなく挙げ、その業務に必要な行動をビジネスユースケースとして洗い出します。

例えば、ECサイトの業務では「商品の管理」という業務をあげ、この業務に対して「商品を登録する」「商品の情報を変更する」「商品を削除する」といったビジネスユースケースが紐づく形になります。

こうして挙げたビジネスユースケースに対して、その業務のフローや利用シーンを具象化します。

このような流れを取ることで

業務->ビジネスユースケース->業務フロー・利用シーン

というような階層化を行いながら、業務を具象化していくのだと読み取れました。

この段階だと業務フロー・利用シーン程度の具象化までしかかいていないのですが、実際のビジネスシーンでは前提条件の組み合わせで業務フローが変わることもあるので、前提条件のバリエーションも一緒につくっていたりします。

次回は、システム境界とシステムの範囲の目的について確認していこうと思います。

今回はここまで

不夜城のオアシス