この記事について
弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが生まれました。どうせレクチャーするなら、自分の知見をまとめなおすことも合わせてやってしまおうと、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめた一石二鳥な連載記事の 3 回目です。
過去の投稿は、こちら↓
RDRA って何？って人は、その１へ actier-coo.hatenablog.com
システム外部環境レイヤーの第一弾は、その２−１へ actier-coo.hatenablog.com
今回の「その２−２」では、システム外部環境レイヤーの業務フロー図、利用シーン図、バリエーション・条件図について、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。
システム外部環境レイヤー
おさらいしておくと、システム外部環境レイヤーは、以下のダイアグラムで構成されています。
- ビジネスコンテキスト図
- ビジネスユースケース図
- 業務フロー図
- 利用シーン図
- バリエーション・条件図
これらのダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったことを表現します。これらによって、システムを使う上での環境を表現するレイヤーとなります。
前回説明したビジネスコンテキスト図でビジネスの全体像を描き、ビジネスユースケース図で業務をブレークダウンしてビジネスで提供する価値を描いてきました。 今回は、ビジネスユースケース図を元に、業務の詳細を業務フローや利用シーンによって、より明確にすると共に、業務とシステムがどのように繋がっているか、どのようなビジネスルールがあるかを分析していきます。
あらためて繋がりを意識する
おさらいですが、システム外部環境レイヤー以降を進めていく中で、各 RDRA の要素やダイアグラムがどう繋がっているかを意識しておくと、連続性をもって要件を分析・整理していくことができます。 以下の図を意識しながら、常に繋がりを意識いただくと良いです。
繋がりを表現している矢印の色は、それぞれ次のような意味を持って表現しています。
- 水色：矢印の根元の対象要素が、矢印先のダイアグラムへ単純に引き継がれる
- 緑色：矢印の根元の対象要素ごとに、矢印先の新たなダイアグラムが作成される
- 黄色：矢印の根元のダイアグラムを作成している中で出てきた要素を抜き出したり、要素の内容について考えてまとめる
業務フロー図
「業務フロー図」は「ビジネスユースケース」単位に作成します。価値を実現する一連の仕事（アクティビティ）の流れを記述し、関わるアクターを明示します。価値をとどけるアクターは誰で、それを支援するアクターが誰なのかを示し、価値を届ける一連のフローがスムーズに連携していることを確認します。同時に仕事の中でシステムを使う部分に「ユースケース」をつなぎ、システムの使われ方を示します。
〜 RDRA2.0 ハンドブック から引用 〜
「ビジネスユースケース図」で抽出した「ビジネスユースケース」ごとに、この「業務フロー図」か後述の「利用シーン図」を作成していきます。 「業務フロー図」では名前の通り、フローで「ビジネスユースケース」がどのような業務の流れになっているかを記載していきます。 上記の図のように、その業務フローに関わるアクターごとにスイムレーンを用意して、そのアクターが実施すること（仕事＝アクティビティ）の連鎖をフローとして記述していきます。 開始から、各アクティビティを経て終了まで至るといった業務フローが描かれます。
また、その業務フローの中で、システムを使うアクティビティに「ユースケース」を紐付けて記載します。 ここで出てくる「ユースケース」は、ビジネスユースケースではなく「（システム）ユースケース」です。 「（システム）ユースケース」は、システムがどのように動作し、ユーザーに価値を提供するかを表す単位になります。 例えば、「見積を登録する」、「見積を参照する」、「見積を編集する」、「見積を削除する」といったようなシステムを意識したものになります。
業務として成り立っているかということを意識して業務フローを記載するので、ユースケースに紐づかない（システムを使わない）ところも記載します。 初学者の中には、システムに関連する部分だけを記述してしまう傾向がありますが、業務の全体像を理解するためには、システムが関与しない業務活動も含めて全てを記述することが重要です。
業務フローを記載してユースケースを紐付けることで、以下を明確にすることができます。
- 業務の一連の流れ
- 業務の中でシステムを使う所、使わない所が「ユースケース」と紐づくかで見える
業務の流れを捉えることはドメインの理解を促進するのと、システムが業務にどう絡むかが見えてくる図なので、RDRA で分析をする中でもかなり重要な図です。
システムが小規模である場合などに、システム全体を一覧で見ることが容易になるよう「ユースケース複合図」*1と合体した業務フロー図を作成することがあります。
業務フロー図 高崎Tips
分析をしている中で、一個一個のキーワードをそのまま落として作るのではなく、シナリオをイメージして書いていくのが良いです。 頭の中でシナリオとして業務の流れをイメージして、あれをやんなきゃ、これをやんなきゃを出していきます。 そのシナリオが出てこないということは、その業務について分かっていないということなので顧客に聞くなどして調べていく必要があります。
初学者のうちは、作成していく際に、上記の説明の通りに業務の流れをまずは意識して業務フローを記載する。 業務フローができあがった所に「（システム）ユースケース」を紐付けてシステムをどこで使うかを意識していくといった分離した進め方を徹底すると良いです。
業務の流れを捉えるという関心ごとと、その中のアクティビティでシステムを使用する所を捉えるという関心ごとの 2 つを実施しているので、関心ごとを分けて考えた方が考えることがシンプルになり捉えやすくなります。
業務フロー図を書くとき、業務の流れを一つの業務フローとしてまとめることが困難な場合があります。 よくある理由の一つとして、各ビジネスユースケースがうまく整理できておらず業務フローが描きにくい状態になっていることがあげられます。 ビジネスユースケースを抽出した際に、内容が抽象的すぎることでも業務フローに落とし込むことが難しくなります。 このような場合は、ビジネスユースケース図にも立ち戻り、まず業務を細かく見直します。あわせて業務フローの中で、別の業務が出ていないか、一連の業務として成り立っているかも確認します。 これらを踏まえ、業務が実施できるかを考えて業務フロー図を書くことが重要です。
業務フロー図をプログラマーが書いていると、ついついココで分岐があるはずとか、ココでループするといったような条件分岐や繰り返しを入れて複雑な業務フローを記載してしまいがちです。 各条件パターンをすべて網羅して書いていくとノイズになってしまうので、主要な業務フローについて記載するのが良いです。 条件分岐することが主要で重要なのであれば記載しますが、基本的には複雑になるのであまり描かないといった感覚です。 また、主要という程ではないけれど条件分岐や繰り返しがあることを伝えたいといった場合には、よくノート（注釈）として対象のアクティビティにコメントを付与して伝わりやすくするといったことを実施しています。
「（システム）ユースケース」を記載していく中で、具体的すぎることは記載しないというのもポイントの一つです。 細かい具体的なことまで書いてしまうと、システムでの実現方法が固定的になって縛られてしまうということに繋がっていきます。 ここで出てくる「（システム）ユースケース」は、「システムが提供する価値って何だろう？」といったレベルで書いていくことを意識します。 例えば、「連絡をする」といったものがあった場合に、連絡のやり方として「メールで」とか「チャットツールで」といったようなことまでは書かなくて良いといった感じです。 ただ、連絡をするという行為やシステム価値自体は必要なので、アクティビティやユースケースとして抽出するようにはしてください。
業務フローを記載していく中で AsIs （現状）の業務フローを完全踏襲する（縛られる）必要はないのですが、把握はしておいた方がよいです。 将来像だけを意識して作るべきものだけを聞いて作った業務フローだと、現状からの飛躍が大きくなりすぎたり、作ったものの納得感が無くなったり、業務が回らなくなってしまうことがあるためです。
初学者は、ビジネスユースケースと（システム）ユースケースをしばしば混同してしまいがちです。 これらは「ユースケース」という共通のキーワードを持っているためです。 これらが混じってしまうと分からなくなってしまうので、まずは違うものだという意識を持つことが重要です。 ビジネスユースケースは、ビジネスにおける提供価値で、システムユースケースは、システムが提供する価値です。
利用シーン図
「利用シーン図」は業務を仕事の流れとして表現できない場合に「業務フロー図」の代わりに使用します。「ビジネスユースケース」単位に一つの「利用シーン図」を作成し、その中に一つまたは数個の「利用シーン」を描きます。
〜 RDRA2.0 ハンドブック から引用 〜
「ビジネスユースケース図」に抽出した「ビジネスユースケース」ごとに、この「利用シーン図」を作成していきます。 「業務フロー図」は業務の流れについて図示していくものでしたが、そういった流れを表現できない際に「利用シーン図」にて図示します。
「利用シーン図」は、業務の中でシステムを利用するシーンである「利用シーン」を思い浮かべ、上図のように記載します。 その「利用シーン」は、どのような使われ方なのかといった詳細を「シナリオ」としてシナリオ形式で記載します。 また、その利用シーンの中では利用する対象者がいると思いますが、その対象者を「アクター」として紐付けます。 同様に、利用シーンの中で利用するシステムの機能＝「ユースケース」が出てくるので、それを紐付けます。
これらの要素（アクター、ユースケース、シナリオ）を組み合わせることで、
「誰（アクター）がどのように（シナリオ）何（ユースケース）を利用するか」
という形でシステムの利用シーンを明示することが可能になります。これにより、要件をイメージすることが容易になります。
利用シーン図 高崎Tips
RDRAで要求分析を実施するとき、全ての要求分析に同等の時間とリソースを投入するのではなく、重要なポイントに絞って要求分析を行うことが推奨されています。 これはRDRAが効率的に要点を把握することを目指す手法だからです。 利用シーン図については、全部の利用シーンを描きたくなりがちなのですが、RDRAの原則に従い、重要なポイントに絞って描くことが望ましいです。
重要なポイントに絞る際に、以下については記載した方が良いです。
- その利用シーンが、システム検討のなかで非常に重要である
- その利用シーンが、非常にフワっとしていて曖昧なので認識を合わせたい
- 将来的に対象のシステム機能を使うので、現在の知識からはイメージしにくいため将来像の認識を合わせたい
業務フローが書きにくいので、よく利用シーンで書くものとしてマスタ管理について記載することが多いです。 前述の「要点を絞って」といった点からすると、マスタ管理は別に書かなくてもいいといった対象にはなってくるのですが、
- 規模が小さいこともあり、ドキュメント記載の関係等からマスタ管理についても網羅的に要求分析しておきたい
- 対象となるマスタの使われ所が特徴的だったり、使われ方のイメージがつかないので定義しておきたい
といった点から利用シーン図を描く時があります。
初学者が利用シーン図を作成するとき、多くの時間を費やす割には内容が薄く、その効用について不安を感じることが多いです。 単純な登録・更新・削除のような基本的な利用シーンや、内容の薄い「シナリオ」を書くと、結果として意義の薄い内容ができあがることがあります。 そのため、前述の重要なポイントを絞ることを意識して基本的過ぎる利用シーンは避け、「シナリオ」には詳細と具体性を持たせることを意識しましょう。 これにより、具体的で役に立つ利用シーン図が完成します。
バリエーション・条件図
ユースケースはシステムとの接点を示し、画面やイベントで入出力が分かり、情報とつなぐことで操作対象が分かります。しかし、これだけではどのような条件で操作するのかが分かりません。入出力が分かり操作対象が分かれば、後はそれらの条件が示されればユースケースでやらなければならないことがほぼ類推できます。その条件がビジネスルールです。そのための出発点が「バリエーション」の分析です。そしてそれを組み合わせたものを「条件」として整理します。
〜 RDRA2.0 ハンドブック から引用 〜
「バリエーション・条件図」は、図っぽくないので、一見するとダイアグラムのように感じないかもしれません。しかし、これはビジネスルールを示すための非常に重要なものです。 なぜ重要かというと、上記のハンドブックの記載にもあるとおり、この「条件」や「バリエーション」がビジネスルールになるためです。 ビジネスルールはビジネスロジックとして、システムに記述されます。
システムを作る際に、どのようなビジネスルールを実装するべきかということがきちんと整理できていると、方々にビジネスロジックを書き散らすといったことがなくなります。 まとめてビジネスルールを把握することで、ビジネスロジックとして集中管理した状態で実装できるためです。 方々に書き散らしたビジネスロジックは、拡張や修正をする際に抜け漏れが発生しやすくなるので、集中管理できた方がシステムの保守性といった点でメリットが出てきます。
バリエーション・条件図として、システムに出てくる「条件」や「バリエーション」を集中管理していきます。
「条件」には、以下の 2 種類があります。
- 名前つけられた式
- 表形式の条件
「名前つけられた式」とは、「消費税計算」のように特定のビジネスロジックや計算方法に名前がつけられているものを指します。 「表形式の条件」は、「バリエーション」を組合せてマトリックスになったものです。例えば、「映画館の料金計算」という表は「年齢」と「上映時間帯」というバリエーションによってマトリックスが描かれ、金額が決まります。 条件を書く際には、実装上の条件を記載するのではなく、あくまでも仕事を進める上での業務的な条件を記載します。
「バリエーション」は、上記の「年齢」であれば「小学生」「中学生」「高校生」「大学生」「大人」「シニア」といったような形でバリエーションが形成されるものです。 「ビジネスコンテキスト図」や「ビジネスユースケース図」で「ビジネス要素」が出てきた際に、その要素にバリエーションが無いかを検討してあった場合は「バリエーション・条件図」へ記載していきます。 また、「情報」のバリエーションが無いか、取引先の種類など業務を進める上でのルール軸になるようなものが無いかといったことを検討して記載していきます。
「条件」や「バリエーション」が集まってくると、どのようなビジネスルールがあるかが可視化され、結果としてシステムの複雑度を掴むことに繋がっていきます。
バリエーション・条件図 高崎Tips
図っぽくないので、今までのダイアグラムと比べて描きにくいです。 ビジネスルールになっていくための「バリエーション」や「条件」がまとまってきているかということを意識しながら、ともかくそれらを集めていくようにしてください。
要求分析をしている会話の中で、「バリエーション」や「条件」になりそうというものがポロポロと出てきます。これは「バリエーション」や「条件」なんじゃないかな？と思ったものは、とにかく「バリエーション・条件図」に集めておいてください。後々、俯瞰して見た際に違っていたら消せばいいだけなので。それよりも、その会話の中でせっかく出ていたものをロストしてしまう方がもったいないです。
ビジネスルールの源泉は、その業務の説明資料である契約書やパンフレット、就業規則や約款などに記載されています。それらから、「バリエーション」や「条件」を抜いてくることもできますし、抜けるように練習しておくと良いです。
色々と「バリエーション・条件図」に集まってきたら、それらについてビジネスルールに関わりそうかどうかといった点で判断して要らないものは消したり、同じような分類になりそうなものは集めてみてグループを形成したりと、整理整頓していくと、どのようなビジネスルールがあるかというのをより掴みやすくなります。
今回は、ここまで。
次回は、「システム境界レイヤー」についてまとめていこうと思います。
