RDRA 2.0 をたしなむ - 4つのレイヤーの取り扱い方②
RDRAの導入も進んで、ダニングクルーガー効果の「なんもわからん」の状態になってきました。
成長していればいいなぁ・・・。
今回は、４つのレイヤーのうちのシステム境界とシステムについてやっていきたいと思います。
システム境界
このあたりからはシステムが行うことを具体化していく流れになります。(ただし、実装は書かないことがポイントらしいです）
まずシステム境界レイヤーの定義は、下記のようになっています。
システムとどう関わるかを明らかにするのがこのレイヤーです。システム境界には人との境界とシステムとの境界の２つがあります。
システムの利用する立場を「外部システム」か「人」のどちらかであるとして、その2つのシステムとの関わり方を示すレイヤとなる・・・と考えていきます。
そして取り扱うものは下記の範囲となります。
- システムを使った作業単位を明らかにする(ユースケース)
- ユーザーインターフェースを明らかにする(画面（帳票含む）)
- 外部システムとのインターフェースを明らかにする(イベント)
「ユースケース」ですが、「外部システム」か「人」かの区別はなく、どちらの場合でも同じように情報を処理する場合に出力していきます。
個人的にはこのユースケースが上げるのがRDRAの中で難しいと考えているのですが、「情報を状態Aから状態Bに変換するトランザクション処理」に着目して、そこに「〜〜する」のような命名をつけていってます。
プログラミングの参考書でよく出る銀行系の「Aさんの口座から5,000円をBさんの口座へ振り込むケース」の場合、「銀行口座での振り込み」とのユースケースが提示され、そこにAさんとBさんのような「ユーザー」が紐づく感じですね。
なお、業務分析でRDRAを使っている現状だと「状態Bが多すぎる場合に、ユースケースを日本語でまとめにくくなる」と感じます。（ステータス遷移が多すぎて、一言でまとめにくくなります）
おそらくですが、次の「システム」で説明する「状態」を整理することでまとまっていくのではないかなぁ・・・という印象を受けています。
システムレイヤー
まずシステムレイヤーの定義は、下記のようになっています。
システム化する情報とその情報が取り得る状態でシステムを明示します。
システムレイヤーは要件の要として整合性を維持するために存在します。
そして取り扱うものは下記の範囲となります。
- システムが扱う情報（概念）を明らかにする。(情報)
- 情報が取りうる状態を明らかにする。(状態)
わかるような・・・わからないような・・・と所見でなったので、上にでてきた銀行の例で例えると、下記のようになりますね。
情報->銀行口座
状態->(Aさんの口座) 5,000円の減額、(Bさんの口座) 5,000円の増額
銀行口座という情報の中で減額・増額という状態を扱っていく感じですね。
こうした状態をまとめれたら、ユースケースに紐付けて情報の変化を見ていくことを行うレイヤのようです。
本日はここまでにします。
RDRA 2.0 をたしなむ - 4つのレイヤーの取り扱い方①
どうも、RDRAの経験が2週間ぐらいになったエンジニアです。
前回のRDRAの記事では、「4つのレイヤーの役割を明確にし、その役割に必要な事柄を定義することで要件を決めていくこと」という定義を確認しました。
今回は、この4つレイヤーの中でビジネスサイドの状況をまとめる2つのレイヤーについて大まかにどのような要素を取り扱えばいいのかを確認していきます。
システム価値
このレイヤに関して、書籍では下記のように定義されています。
「誰に価値を与え、そのために誰が関わるのか？ 同じく価値を与える外部システムとそのために必要な外部システムはあるか？」を明らかにします。
その上でシステムに関わる人の要求を整理し、システム化の方向性を明示します。
そして取り扱うものは下記の範囲となります。
- 対象業務に関わる人(アクター)を洗い出す
- 関係する外部のシステムを洗い出す
- システム化への要求を捉える
個人的には、このレイヤーに対して下記の解釈をしています。
- 要件定義を始める現在時点での資産と要求をまとめるフェーズであり、作成するシステムの仕様は含まれない。
- 要求といった抽象度の高いもの、外部システムなどの自発的に変更ができないものを取り扱うため、このレイヤーでの変更は起こりにくい。
2つ目の解釈の補足をしておきますと、具体化した要求だと変更がかかりやすくなると思います。
例えば「スマホの画面からワンタップで出勤の登録をしたい」みたいな要求だと、「Amaoznダッシュボタンのようなワンプッシュで出勤を登録できる機器を使いたい」みたいに簡単に要求が置き換わってしまします。（そして要件定義の途中、もしくは終わったあたりでこれが発生すると、目も当てられません・・・）
なので、要求を抽象化して方法を幅広く模索できるようにしておくことも求められるのかなと考えてます。
システム外部環境
ここではビジネスサイドでの仕事の流れを具現化するフェーズになります。
書籍を引用すると、下記が取り扱う範囲になります。
システム化対象の業務を捉える(業務)
業務を実現する価値の単位を明らかにする(ビジネスユースケース)
価値を実現する業務の流れを捉える(業務フロー)
価値を実現するシーンを明らかにする(利用シーン)
ビジネス価値を出すための業務をもれなく挙げ、その業務に必要な行動をビジネスユースケースとして洗い出します。
例えば、ECサイトの業務では「商品の管理」という業務をあげ、この業務に対して「商品を登録する」「商品の情報を変更する」「商品を削除する」といったビジネスユースケースが紐づく形になります。
こうして挙げたビジネスユースケースに対して、その業務のフローや利用シーンを具象化します。
このような流れを取ることで
業務->ビジネスユースケース->業務フロー・利用シーン
というような階層化を行いながら、業務を具象化していくのだと読み取れました。
この段階だと業務フロー・利用シーン程度の具象化までしかかいていないのですが、実際のビジネスシーンでは前提条件の組み合わせで業務フローが変わることもあるので、前提条件のバリエーションも一緒につくっていたりします。
次回は、システム境界とシステムの範囲の目的について確認していこうと思います。
今回はここまで
RDRA 2.0 をたしなむ - RDRAってなにをつくるの？
RDRAの採用にあたって、社内ドキュメントの整備の意味も込めてRDRAハンドブックの内容をちょっとまとめてみたいと思います。
今回の記事は「RDRA2.0 ハンドブック」を参考に書いております。
そもそもRDRAとは
定義は大事です。
書籍から引用すると、
コミュニケーションが円滑になる構成や整合性を担保する仕組みをまとめたモデリング手法です。
というところを出発点にすればよいようです。
あとはスクラムなどのアジャイルソフトウェア開発の文脈でも、ある程度全体を見通して拡張性と保守性を担保するために「システム化しなくてはいけないものは何かを明らかにすること」を重視してほしいということが序文で読み取れました。
この「システム化しなくてはいけないものは何かを明らかにすること」という工程を要件定義としており、要件定義のための手法を以降の章で解説しているという流れですね。
ではどうやってRDRAで要件定義を進めていくのか？
書籍を参考にすると、「下記の4つのレイヤーの役割を明確にして、その役割に必要な事柄を定義することで要件を決めていくこと」がRDRAのモデリング手法になるようです。
- システムが実現する価値
- システムが使われる環境
- システムとの接点
- システム
システムの実現する価値はシステム開発の際の「Why」に相当する箇所となり、これに加えてシステム外部環境などの影響を受ける部分を記載していき、最後にそれらの影響を踏まえた上でシステムの要件を決定する、という概要になっているようです。
このあたりの詳細については、次回以降で書いていきたいと思います。
今日はここまで
0からはじめるSpring Boot 2.4.2（プロジェクト開始)
Spring Boot でのプロジェクトの始め方について
主な題材として、Spring Bootについての学習をまとめたりしようかと思います。
今回は、Spring Bootでのプロジェクトの始め方についてまとめます。
1. Spring initializr でプロジェクトを作る
Spring boot 用にプロジェクトを作成してくれるWebのツールです。
設定できるものとしては、下記のものを変更できます。（このあたりは、Spring Bootを習熟してきたときに設定を変更していくといいと思います）
- Project: ビルドツールにを使うか？(Maven、Gradleが選択できます）
- Langage: どの言語でつくるか？（Kotlin、Java、Groovyが選択できます)
- Spring Boot: Spring Bootのバージョン
- Project Metadata: プロジェクトの識別子やどういった形式でモジュールをまとめるかの指定ができます。
- Dependencies: プロジェクトに取り込むライブラリを設定します（これはあとからでもいくらでも追加できます）
2021/01/31時点で、下記のように設定して始めてます。(Javaのバージョンとかに変更があったら変えたりしようかな・・・・と思います。）
2. IntelliJ IDEA CE でプロジェクトを取り込む
3. build.gradle へ下記の記述を追記する。
Spring-starter を使って以降の開発を進めたいので、いつも下記の設定を追加しています。
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
implementation 'org.springframework.boot:spring-boot-starter-web'
書籍などの2.4系を使っているサンプルはだいたいこんな感じで設定して動かしてます。
本日はここまで
