モデルベース要件定義テクニック・RDRA2.0 ハンドブック - 読書感想文
はじめに
この記事はモデルベース要件定義テクニックとRDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法を最後まで読んだのでその感想文を記したものです。なので本の要約を求めてた方、本の内容について深い考察を求めていた方、ごめんなさい。きっと要望を満たせていません。あくまで感想文として見てください。
下記に注意事項を列挙しておきます。
- 読書感想文です。なので個人的な意見や感想が入ってます。
- 間違ったことを言ってる（書いてある）ことがあります。むしろ多くても不思議ではありません。
- 本の内容をしっかり知りたいなら本を買いましょう。
この本を読もうと思ったきっかけ
まずRDRAを学ぼうと思ったキッカケについて説明します。DDDを勉強していた時にドメインモデルを育てる重要性には気づきましたが、ドメインモデルの見つけ方に関しては分からないままでした。ドメインエキスパートと対話し要件定義を行う中でドメインモデルを見つけていくということは分かりました。しかし私はソフトウェアエンジニアとしても日が浅くそもそも要件定義とは何なのかよく分かっていません。そのため要件定義とは何かを学ぼうと思いました。
DDDにおける要件定義とはどういうモノなのか調べてみました。すると以下のようなスライドや資料を発見しました。
アジャイルは聞いたこともあるし社内の別部署でも実績はあるのでなんとなく知っていますが、RDRAに関して聞いたこともないし知りませんでした。またスライドをパッと読んでもRDRAにどれほどの価値があるかイマイチ掴みきれていませんでした。しかしDDDに関する達人たちがRDRAについて語っているということは何かしら大きな価値があるっと確証を持ちRDRAを学ぶことにしました。
随分と安直ですが何の手がかりもなく本を読み漁るよりはマシかなという判断です。
この本を読んだ感想
今回読んだのは以下の２冊です。この感想文ではこれらをRDRA本と呼ぶこととします。
まず最初にこれらの本を一気に通読しました（理論編だけは何回か読み直しました）。その後はRDRA2.0 ハンドブックにある図書館のサンプル[1]図を紙やパワーポイントなどで模写をするという作業をしました。なぜ模写を行ったかと言うと、絵は描かないとその効果を理解できないなっと感じていたためです。
また描くことで本の内容をどこまで理解していたかの確認も行っていました。案の定、描いてみると対して本を読めてないことが分かりました。何かを学ぶにはやはり五感に働きかけるのが一番だと再認識しました。
以下は感想文の目次です。長いです。
以降は各項目について細かく書いていきます。
要件定義に必要な３つの特性
まずRDRAに関して私が気になったのは「RDRAとその他の要件定義手法との違い」です。あまり熱心に調べはしませんでしたが、要件定義に関する書籍や手法は他にも沢山ありました。これら多くはユースケース記述をどう書くかやUMLの書き方のコツなどHowに関する本が多い気がしました。一方でRDRAはユースケースやモデルなどの設計がユーザに対して何の価値に繋がっているのか、つまりWhatやWhyを重要視しています。
なぜ繋がりが重要なのでしょうか。これは本にも記載がありますが整合性と網羅性そして表現力の3点が要件定義では必要だからです。モデルベース要件定義テクニックのChapter-1に次のように説明されています。
一言で言うと定義された要件がもれなく、重複なく、そして各々の要件が整合しており、それが分かりやすく表現されているものが、適切な要件定義と考えます。
この説明を別な見方で解釈すれば「要件定義では漏れや重複があり、また整合性がなく分かりづらい」ということが起きやすいのだと思います。何故こういうことが起きてしまうのかについてもモデルベース要件定義テクニックに説明があります。
要求の整理、既存システムの調査、問題解決策の検討など、一見、彼らは妥当な作業をしているように見えます。各担当者の作業成果が提出され、プロジェクトで作成したドキュメントの量も順調に増えていきます。（中略）これは一見作業が進んでいるようですが、実態としては着手できる作業をとりあえず行っているだけです。結局要件定義をしている「つもり」になっているだけです。
この説明は私の心にグサっと刺さるものがありました。私が経験した業務開発もとりあえずは割り振られた調査を行い、調べた結果をWikiに纏めるという作業でした。機能一覧を作った後、いざ開発に移行すると機能一覧に書かれた通りに実装するのが困難であったり、必要なAPIが仕様書から漏れていたりっと何のための調査だったのかっと思うことが多々ありました。RDRAはこのような経験をされた方に大きな魅力を与えてくれます。
著者が述べているように、調査結果や資料をどれだけ分かりやすい文章や図で作成しても、漏れや不整合は発生します。なのでRDRAでは如何に要件を分かりやすく表現するかではなく、要件やユースケース、ドメインモデルなどがそれぞれどういう関係性を持っているかに着目しています。要件定義に登場する様々な要素に関係性を持たせることでドメインモデルがどのようなシステム価値を生み出すのか把握することができます。実際にRDRAで設計してみると地図を指でなぞるようにその関係性をたどることができたので非常に面白いと感じました。
モデリングをやってみた
RDRAを使って要件定義を行うと整合性と網羅性そして表現力の3点がどのように実感できるのか確認すべく実際にモデリングをしてみました。RDRA本の図書館サンプルで模写した時にモデリングしたので、今回は自分で適当なシナリオを用意してみました。私はラーメンが好きなので「ラーメンの注文受付や売上管理を行うシステムの要件定義を行う」という設定にします。
RDRA本では各種グラフの作成にPower Pointを推奨していてテンプレートも用意されています。しかし今回はmiroでグラフを作成しています。理由は２つで、１つ目は１から作ってみたかったというのと、２つ目はパワポで作成していたら仕事している感が出てしまい、気が滅入ってしまったので断念しました。逆に言うならば、テンプレートがあるので業務で使う時はパワポが良いと思います。
miroで書いた後に気づきましたが、RDRA発案者の神崎さんが以下の記事をオススメしていました。PlantUMLも今度試してみようと思います。
システムコンテキスト図
システムコンテキスト図は以下の通りです。アイコンは用意するのが面倒くさかったので手書きです。RDRAではアイコンの表記方法に規定が無いのでこういうのもアリだと思います。
今回はモデリングの練習のため、かなり雑な設定にしています。個人経営のラーメン屋を想定して、登場人物は店員と店主に限定しています。
システム化の目的はざっくりと言うと注文や会計業務の効率化です。システム化の目的は図に記載していますが、この内容は抽象的でやりたいことがイマイチみえてきません。なので実際に真面目にモデリングする時は、ユビキタス言語もしくは用語集を用意し、その語を使って目的がハッキリとした文章を書くと良さそうな気がしました。
実際にシステムコンテキスト図を書いた感想としては、この程度の内容なら省略していいかな？っと思いました。ただ登場人物がもっと多くて外部システムとの連携などもある場合は、この図は有効だと思います。なぜなら、ドメインモデルの洗い出しをしている段階で外部システムとの連携に漏れなどがあると全て工程で見直しが発生すると思うので、開発の規模が大きいならやるべきだと思います。
要求モデル
要求モデルは以下の通りです。
ここで出てくる要求は全て妄想です。「要望適当過ぎない？」という意見が聞こえてきそうですが、現実のヒアリングで発生する要望はもっと不鮮明で一貫性がないので、むしろかなりマシなほうではないかと思います[2]。ここを上手に引き出すのがエンジニアに求められる技術の１つなのだと思います。
モデリングした感想としては、要望の一覧を整理して要件として纏める作業は間違いなく複数人でやるべきだと思いました(要求モデル図に限った話ではないですが)。というのも自分の認識の正しさに１人だと全く気づけ無いからです。実際この要件であっているか全く自信がありません。現実の業務においてはこの工程は時間を使ってでも、複数人で実施し共通認識を獲得できるように務めるべきだと思いました。
ビジネスユースケース図
ビジネスユースケース図は以下の通りです。
店員は注文の登録をお会計をし店主は注文内容の確認と売上の確認を行います。実際にビジネスユースケース図を描いてみると店員は売上を確認しないし店主は会計業務をやらないことが分かります。またビジネスユースケースを文章で表現するとこれらの情報は行間に埋もれてしまうのでしっかりと文章を読み込まないと気づきにくいだろうなっと思いました。図にするとアクターとユースケースが線で繋がっているのでこのような埋もれやすい情報に気づきやすくとても有用な図だと思います。
業務フロー図
業務フロー図は以下の通りです。この業務フローは「注文登録」のビジネスユースケースに対応するものです。
実際に業務フローを書いてみて気づきましたが、業務をしっかりと理解していないとうまく描くことができませんでした。何を当たり前のことを言っているんだ？と思うかもしれません。しかし、要求モデルで箇条書きした要件を文章から図へ変換する時、予想外にも手が止まっていました。これは具体的な業務内容を脳内でイメージできていないことに起因していると思います。
要件を書いた時点ではわかったような気になっていました。しかし実際は全然理解できてないことが描いてみると良く分かりました。図を書くのは業務理解を深める上で大事なプロセスの１つだと思います。
バリエーション図
バリエーション図は以下の通りです。
いくつか図を描いてきましたが個人的にはこのバリエーション図が一番興味深かったです。なぜなら、実際にお客さんは１グループあたり何人で来るのか？替え玉は何回注文するのか？など具体的なシチュエーションをイメージできたからです。
最初はこの図を書く意味がよく分からなかったですが、条件や区分を洗い出すことができることので、ドメインオブジェクトを実装する時に非常に参考になる情報だと思いました。
UC複合図
UC複合図は以下の通りです。この辺りになると疲れが見え始め、図がより手抜きになってきています。体を休めることも大事ということが図からもよく分かります。
実際のユースケースでユーザがどういうインタフェースと紐付いているのかを確認することができます。またユースケースに紐づく情報モデルなどもここで紐付けます。
モデリングをやってみた感想
感想です。何回かRDRAを試してみましたが、「整合性」、「網羅性」、「表現力」の３点は確かに実感できるなっと思いました。
１点目の整合性では、前述のような雑なモデリングでも「麺という情報モデルが必要なのは注文登録の業務において必要だから。また店主は麺の残数を確認しながら調理する必要があるから」っと図を見ると頭にスッと入ってきました。
２点目の網羅性も各種ダイアグラムが４つのレイヤーに分類できるので、実際の打ち合わせで要件を確認する時にどのレイヤーで確認が漏れているか、またどこの部分が分析が甘いのか、などにすぐ気づけるだろうなっと思いました。
なによりも３点目の表現力が素晴らしいと思いました。実際の業務でRDRAで要件定義を行って、その図を関係者に見せても、おそらく受け入れてもらえると思ったからです。UMLやICONIXのロバストネス図のようなものは正確に表現はできるもの、図が複雑なので打ち合わせなどで見せると相手の顔が曇ります。
「あーそういう細かいのはそっちで決めてもらってOK!ようはやってほしいことは・・・」
のようなことをよく言われますがRDRAぐらいのシンプルな図であれば、ちょっとした解説を足しながら議論をすればスムーズに対話できると思います。なのでRDRAは要件分析のためのツールでもあると思いますが、対話の時に役に立つコミュニケーションツールの１つでもあるなっと思いました。
「システム価値」の根拠
RDRA本を読み進めて感じたのはユーザの考える「システム価値」そのものについての分析はRDRAの範囲外なのだろうなっと思いました。
例えば、ショッピングサイトを運営している会社があったとし、私がそこでエンジニアとして働いていたとします。冬の商戦に向け売上を伸ばしたいので割引クーポンを配布する機能を作ってくれ！っと偉い人から言われたとします。その時に思うのが「なぜ割引クーポンを配ることが売上増に繋がるのか」という疑問です。もちろん過去の実績からある程度の数字を予想できたり、経験則からそのアプローチに対して自信を持っているのだと思います。しかし、それをこういうケースににおいて、それを最善手と捉えていいのか常々疑問に思っています。
もし売上が伸びない理由がシステムのUI/UXが悪いのだとしたら、割引クーポンをくばるよりそちらを先に改善したほうが大きな効果があるかもしれません。もし品揃えが悪いが原因であれば、取り扱い品目を増やしたり、広告を増やしたほうが効果があるかもしれません。いずれの場合においても、ユーザの要望のシステムを作ることをエンジニアには求められているので、「価値」そのものを考えることはエンジニアの仕事ではないのかもしれません。考えると泥沼なのでほどほどにしておきます。
RDRAはユーザが解決したい課題に対して「システム価値」を提供するための分析手法ですが、「システム価値」そのものの分析はおそらくまた別な話なのだと思いました。
RDRAは必要なものを取捨選択しても良さそう
前述したラーメン屋モデリングではRDRAで紹介されているダイアグラムを全て使っていません。描くのがめんどくさかったっというのはありますが、全部描くかは要件定義の進め方次第ではないかと思いました。
RDRAで大事なのは図をキレイに描いたりすることではなくて、各ダイアグラムを線で結び、その関係性を確認することだと思います。そのため業務フロー図からいきなり描き初めて「この業務って何でやらないといけなかったんだっけ？」という疑問からシステムコンテキスト図を描き始めることもできます。「システム価値」レイヤーから愚直に図を描いていくより、要件定義を行う対話の流れから自然と図を描くほうが描きやすいと思いました。
「設計の難しさ」は組織で大きく違う
ここまでRDRAの感想や体験をつらつら書いてきましたが、私が業務でRDRAを利用する機会は少ないような気がしています。なぜなら私の場合では要件定義は利害関係者との対話で決まるのでなく天から舞い降りてくるからです。
「今期の目標はコレ！納期はコレ！スケジュールに線を引いて進捗管理するように！」
こういう現場では上の方へ「RDRAで要件定義してみましょう！」っと意見を通すことは中々難しいです。上の方は業務命令はするものの対話は望んでいないのです。つまり、まず最初に、神々を地上に降臨させて同じ円卓に座らせて議論を要求しないといけないのです。
要件定義の重要性、ドメインエキスパートとの会話から見つかるコアドメイン、アジャイル開発におけるスプリントレトロスペクティブの重要性、など神々にそれらの重要性を認識させるのがRDRAを始める前にやるべき私の仕事だと思っています。
おわりに
プログラミングやネットワークなどの書籍と異なり、今まで馴染みのない領域の書籍だったので読むのに苦労しましたが、非常に楽しい内容でした。非エンジニアの方でもきっとタメになる内容だと思うので購入して損はないかなっと思いました。
また図を描いていて感じたのは、頭で理解しても体が動かないようなもどかしさです。これは当たり前で実戦経験と反復練習が必要だと思います。サッカーのシュートのやり方を覚えても急にうまくなるはずもないのと同じことです。暇な時にラーメン屋モデリングをもうちょっとやったり、現場で使う機会があればそこで経験値を稼ぎたいと思います。しかし、まず自分が始めないと行けないのは実戦経験を積むためにも設計やるための環境づくりです。道が果てしなすぎる。
RDRAは使いこなせるようになったらまた別な世界が見えてきそうな気がします。その時はまた感想文を追記するかもしれません。
-
JavaのサンプルコードがGithubにあったりします - https://github.com/system-sekkei/library ↩︎
-
「G○○gleみたいな見た目でよろしく！」とか言われます。どうしろというのだ... ↩︎
Discussion