この記事について
弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが生まれました。その中で、どうせレクチャーするなら、自分の知見をまとめなおすということも合わせてやってしまおうということで、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめておこうという一石二鳥な連載記事の 2 回目です。
その１は、こちら↓
その１を書いてから、すっかり1年ちょっと経ってしまいました。。。 最近、また別の社員にもガッツリと時間取って教えているというのもあり、その２から先はサクッと連載していきたいと思います。
今回の「その２−１」では、システム外部環境レイヤーについて書いていたら長くなったので、まずはビジネスコンテキスト図とビジネスユースケース図について、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。RDRA って何？って人は、↑のその１へ
要件定義で意識したいこと
最近、1日1金言的な感覚で、バルタザール・グラシアンさんという聖職者の人生訓をまとめた本を読んでいたら、これは要件定義、そして RDRA を進める上で意識した方が良い言葉だなと思った一節があったので紹介します。
083 よく考える
何かをいつも考えるくせをつけよう。無分別な人が手に負えないのは、物事をあらゆる側面から検討しないために全体像が理解できないからだ。理性的に考えることで、状況は正しく判断できる。
ただし、さほど重要ではない細部にこだわりすぎると、判断や行動を誤ることになる。深く隠れていた真実が表面化するのを待っていれば、やがてすべてが理解できるようになることも多い。
〜バルタザール・グラシアンの賢人の知恵 エッセンシャル版 プレミアムカバーから抜粋〜
上記人生訓と同様に、要件を定義したり、設計をしたりといった中では、いろいろな側面から考えを巡らせ、全体像を掴むことが重要です。
その全体像を掴もうとする中で、重要ではなくただ気になってしまった所だけを深掘りしたり、網羅的にすべてを洗い出そうとすると、時間の無駄へと繋がっていきます。枝葉の部分も含めて、一度にすべてを知ろうとすると時間がかかるので、進めていく中で少しずつ見ていく方が周辺理解もしているため効率よく内容を把握することができます。
RDRA での要件定義・設計は、作り上げていく中で全体像を複数のモデルダイアグラムで関連付けながら掴めるようになります。進める際には、あるモデルダイアグラム一つで深掘りや網羅して考えようとせず、先のモデルダイアグラムに進んで分析をして、そこでの気づきを元のモデルダイアグラムに反映してといったように、行ったり来たりしながら精度を高めていくのが良いです。まさに、この人生訓の考え方が重要になってきます。
これを意識して、この先の RDRA のレイヤーやダイアグラムを理解して進められるようになっていると良いかと思います。
今回は、システム外部環境レイヤーについて意識しながら見ていきましょう。
システム外部環境レイヤー
システム外部環境レイヤーは、以下のダイアグラムで構成されています。
- ビジネスコンテキスト図
- ビジネスユースケース図
- 業務フロー図
- 利用シーン図
- バリエーション・条件図
これらのダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったことを表現します。これらによって、システムを使う上での環境を表現するレイヤーとなっています。
前回説明したシステム価値レイヤーで、システムの最上位のオーバービューを捉えましたが、それをベースにビジネスの全体像を描きシステムへと細部を描きます。 システムを活用しようとしているビジネスや業務がどのようになっていて、その中でシステムをどこで、どう使うかといったことを整理して表現していきます。
それぞれの要素やダイアグラムの繋がりを意識する
システム外部環境レイヤー以降を進めていく中で、各 RDRA の要素やダイアグラムがどう繋がっているかを意識しておくと、連続性をもって要件を分析・整理していくことができます。 以下の図を意識しながら、ここから先に紹介するものの繋がりを捉えていただくと良いかと思います。
繋がりを表現している矢印の色は、それぞれ次のような意味を持って表現しています。
- 水色：矢印の根元の対象要素を矢印先のダイアグラムへと単純に引き継ぐ
- 緑色：矢印の根元の対象要素ごとに、矢印先のダイアグラムを作成する
- 黄色：そのダイアグラムを作成している中で出てきた要素を抜き出したり、要素の内容について考えながらまとめていく
ビジネスコンテキスト図
「ビジネスコンテキスト図」はシステムが使われる環境を明らかにするための最上位のダイアグラムです。システム化対象の「業務」を明らかにし、「ビジネスユースケース」へと分割することで「業務フロー図」、「利用シーン図」の作成単位とします。同時に業務に関わるビジネス要素（商品、取引先...）を明示し、ビジネスルールを整理するための源泉とします。
〜 RDRA2.0 ハンドブック から引用 〜
ビジネス全体を一番ざっくりとまとめたものが、ビジネスコンテキスト図です。 システムコンテキスト図で描いたアクターや外部システムが、どのようにビジネス要素や業務に関わってくるのかといったことも、この図の中で表現していきます。
ビジネスの全体像をざっくりとまとめていく中で、
- 業務としてどのようなものがあるか
- 業務にアクター（組織や人）や外部システムがどのように関わるのか
- どのようなビジネス要素が絡んでくるのか
- 業務やアクター、ビジネス要素は、どのような組織や範囲で使われるのか
といった開発するシステムを使用するビジネスを俯瞰してみることができる様になっていきます。
システム外部環境レイヤーの起点となってくるダイアグラムなので、これをしっかりと抑えて、ビジネスイメージを高められる様にしておくと、後々の他の図でも統一感を持って要件定義や設計をしていくことができる様になります。
ビジネスコンテキスト図 高崎Tips
システム外部環境レイヤー以降で分析・整理していく各図は、繋がっていきます。ビジネスコンテキスト図で描いたものを踏まえてビジネスユースケース図を描いたり、検討をしている中でバリエーション・条件図に出てくる「バリエーション」や「条件」、システムレイヤーに出てくる情報モデル図の「情報」などが出てくるのでメモしておいた方が効率が良かったりします。それぞれの繋がりを意識して体得していくと、より深い要件分析ができるようになっていきます。
ビジネスコンテキスト図ぐらいから、「アクターやビジネス要素と業務の関係はどうなっているか？」といった様に関係性をしっかりと分析していきます。 そうすると、途端に完璧な関係性を描きたくなってくるので、「これとこれは繋がっているかなー？」と考え込み時間がどんどんと経っていきます。 この先のステップである業務フローなどで細部を考えた際に、この繋がりがあったというのが見えてくるものなので、ここで時間をかけてすべてを洗い出そうとせずに、先に進んで戻ってきて反映するといったように行ったり来たりしながら関わりを明確にしていくといった進め方にすると効率が良いです。
分析・整理していく中で、気づいた「情報」などの各要素をメモ*1しておくと効率が良くなります。ただ、一方で、その進め方をすると、どれが「アクター」でどれが「情報」でといったことが初学者のうちは混乱してしまいがちです。
出てきた名詞が何の役割をはたしているのかといった観点で整理することが多いのですが、その際に、その名詞の適切な役割を理解することが重要です。たとえば、「営業部」という名詞が出てきた場合、それがシステムを操作する「アクター」として扱われるべきか、それとも「情報」として扱われるべきかを判断します。どのような文脈で話に出てくるかにもよって変わりますが、「営業部」はシステムを操作する人々を表していることが多いので、「アクター」として扱います。「アクター」は、システムを操作する人や組織だからです。 一方、「注文情報」や「商品リスト」という名詞は、システムで扱う「情報」です。これらの区別は、ビジネス全体の理解と要件の明確化に不可欠です。
RDRAでは、作図をして当てはめていく中で、その明確化を行っていきます。 最初は「アクター」として扱っていたものの分析を進める中で、図の中のおさまりが悪くて「情報」なのかもと気づくといったように、よりビジネス全体を理解した中では要素の位置付けが変わっていったりします。 やはり、分析を進める中で、細かくこだわりすぎずに進めてみて反映するといったことが重要になってきます。
ビジネスユースケース図
「ビジネスユースケース図」は「ビジネスコンテキスト図」で明示された「業務」をブレークダウンした「ビジネスユースケース」を洗い出すダイアグラムです。「ビジネスユースケース」は価値を届ける単位になり、「業務フロー図」、「利用シーン図」の記述単位となります。
〜 RDRA2.0 ハンドブック から引用 〜
ビジネスコンテキスト図で洗い出した「業務」ごとに、ビジネスユースケース図を書き、ビジネスユースケース*2を洗い出していきます。 ビジネスユースケースは、基本的には業務を細分化することで洗い出していくことができます。 また、関係者によってフローが変わる様な会社の中身のプロセス*3だと別のものとして表現します。関わる人によって価値が変わってくるためです。
「業務」をブレークダウンして細分化することで、「ビジネスユースケース」、「アクター」、そして「ビジネス要素」がその「業務」の中でどのように絡み合っているかを図示します。 その「業務」が、どの様なことを実施しているかをオーバービューで捉えられるようになります。
ここで定義したビジネスユースケースごとに、この後紹介する「業務フロー図」や「利用シーン図」を記載するので、その繋がりも意識しながら整理していきます。
ビジネスユースケース図 高崎Tips
初学者にとって、この「ビジネスユースケース」が分かりにくいです。以下の Tips も意識して貰いながら、「ビジネスコンテキスト図」、「業務フロー図」、「利用シーン図」を何度も行ったり来たりしながら実践していただくと掴んでいけると思います。
「ビジネスコンテキスト図」の「業務」とほぼ同じ場合は、作成しないことも可能です。
ほぼ同じであれば作らなくて良い
〜 RDRA2.0 ハンドブック から引用 〜といった様にハンドブックにも記載されている通りで、規模が小さいシステムだと「業務」と「ビジネスユースケース」が、ほぼイコールなので「業務」＝「ビジネスユースケース」として扱います。 いきなり規模の大きいシステムについて初学者が RDRA トライすることは少ないので、「ビジネスユースケース図」や「ビジネスユースケース」の必要性が分からなくなりがちですが、規模の小さいシステムだと必要ないことが多いといった点がハマりポイントの一つです。
「ビジネスユースケース」の粒度をどの程度に設定するかは難しい問題で、また、「業務」との違いを意識しつつ適切な言葉を使用して表現することも難しいです。
といった粒度の関係性を意識しておくと、ビジネスユースケースの粒度を捉えていきやすいです。
例えば、「販売管理」といった「業務」で考えてみましょう。「販売管理」は大枠の業務で、具体的な価値を生む「ビジネスユースケース」は「見積作成」、「注文受付」、「売上計上」等です。 より具体的な作業として、「見積作成」には「見積依頼」、「見積書作成」、「見積書送付」といったアクティビティが出てきます。
「ビジネスユースケース」レベルで整理する際に、登録、編集、削除、確認といったシステム機能を直接的に示唆するような表現を用いると、粒度が細かすぎる可能性がありますので注意してください。
今回は、ここまで。
次回は、「システム外部環境レイヤー」における「業務フロー図」、「利用シーン図」、「バリエーション・条件図」についてまとめていきます。
