2017年04月22日makopi23のブログmakopi23が日々の生活で感じたことを気ままに綴るブログです。ワークショップ!」に参加してきました。Night!」」というイベントがありました。そんとき書いたブログはこちら。Night!」に参加してきたのでブログにメモ。今回はその続編ということで、ワークショップを通じて実際に手を動かしてRDRAの勘所を体験する、というインベントです。ブログを書いてネタバレにならないか、と神崎さんにお聞きした所、「問題ない」とのことだったので、自分の復習用にメモを書いてみる。Kanzakiワークショップをやる前に、RDRAの概要について説明がありました。前回イベントでもブログに書いたけど、今回もさらっとメモ。要件定義には何を定義すればいいのか要件定義を「システムだけでなくシステムをとりまく環境」まで考える。要件定義の構造を定義する何が定義されていないといけないのか。4つの視点で構造化する。価値を与えているものは何かを見る。人と外部システムをとらえる。価値は人がきめるので、誰がかかわるのか決める。システムの外部環境は、業務フローか、書けないならシーンを明確にする。人と外部システムとの連携部分。機能とデータとドメイン構造を書く。RDRAでは、モデルも状況によって使い分けするが、4つの視点は変わらない。視点ごとに作るモデルを省いたりする。要件分析の枠組みRDRAでは、4つは依存関係が大事。依存関係があるから要件が早く決まる。「システム」を決めるためには「システム境界」が決まってないといけないし、「システム境界」は「システム外部環境」が決まってないといけない。外側に視点をずらしていく。外側がWhyになっている。「6.外部システムとのプロトコルを整理」では、はビジネス上認識しているユーザの状態を整理する。オブジェクト指向のクラスではまだ見えてないので、それに対する状態遷移図ではない。「未出荷リスト」を出してくれ、という要求に対して、「未出荷」という状態を捉える。「7.ユースケースに関わるユーザーインタフェースを洗い出す」では、業務フローからユースケースが出てきて、それに画面をひっつけてインタフェースを出す。画面のレイアウト考えましょう、という話ではない。必要に応じて画面のラフスケッチを書く。DDDでは「機能モデル」はほとんど書かない。「9.アクションを機能に対応付ける」で、イベントを機能に結びつける。今回は機能はないのでやらない。「11.機能とデータを突き合わせる」で、機能とドメインを結ぶ。DDDは深く分析する部分をdddにまかせている。「システム境界」は、ユースケースを中心に画面とイベントとアクターがくっついてる。今回のワークショップでは、システム地図を作成する。DDDで4領域を分けて書くのと、あんまりかわらない。4領域を全部ひっつけるとシステム地図になる。今回は時間がないので、システム地図を書く。Kanzaki今回は、実案件よりは簡単な題材でRDRAを実践してみるとのこと。纏まったドキュメントを作る、というよりも、2時間で要求定義として形をまとめることが目的。繋げてものを考えると、ある程度形になることを経験する。Maker」というツールを使いました。参加者にはツールのURLが公開され、3人1チームで、各チームにPC1台、このツールをインストールしました。「会議室.com」という、会議室を貸したい人と借りたい人をつなぐサイトを作りましょう。貸会議室を営む会社から開発依頼を受けた想定で、マッチングビジネス用のサイトを開発する。アクターに対する利用シーンを繋げて、情報まで洗い出すところまでやって完了。ホワイトボードの左にあるとおり、「アクター」から「情報」まで順に洗い出していきます。「アクター」と「要求」うちのチームは「アクター」と「要求」は以下のように洗い出しました。アクターの洗い出しは比較的すんなりいったけど、ステークホルダーをどこまで考えればよいのかは気にする必要ありそう。あと、「要求」は別画面に洗い出すように、との指示でした。この理由は後述の質疑応答にて。利用シーンは「どういうふうに使えると嬉しいのか」を書くとのこと。どのチームも「利用シーン」を出すのに苦労してたようです。いうのも、この次の「ユースケース」との違いがわからなくて・・・ウチのチームも苦労しました。神崎さん曰く、「利用シーン」より先に「ユースケース」を考えても問題ないとのこと。「ユースケース」が安定すれば「利用シーン」はいらなくなるとのこと。いうわけで、うちのチームも「ユースケース」と「利用シーン」を同時に考えるように進めました。左が「アクター」、真ん中が「利用シーン」、一番右が「ユースケース」。次は外部システムを洗い出しました。うちのチームでは、「認証システム」と「決済システム」を外部システムとしました。次に、外部システムとユースケースをイベントで結びます。「イベント」は「入金」と「認証」としました。赤枠が「外部システム」で、青枠が「イベント」。最後に、「画面」と「情報」を分析します。こんな感じで出来上がり。四苦八苦しながらもなんとなく形になりました。今回、3人チームで5チームあったので順に発表していき、随時、質疑応答がありました。ピザとビールが届いたので、美味しく戴きながらの発表w質疑応答や意見交換で出た、神崎さんや増田さんや参加者からのコメントメモ。重要なやつだけ覚えておいて図にする。図を作ってるといろいろ見えてくる。すると、「こうしよう」と決められる。「要求」に戻って、「~~できること」と決める「要求」だけ違うシートに書いたのは、その要求でコントロールするため。要求を出していって、それでコントロールする。矢印の向きは考慮しない。(考慮してもよいが)ユースケース「利用シーン」と「ユースケース」の違いがしっくりこないという意見が多い印象。「予約をする人」と、「その予約を見ている人」は別のユースケース。イベントRDRAはシステムを使った仕事の単位で考える。「入出金」は入金と出金の両サイドあるが、自社の立場でどちらになるのかを考えるほうがよい。UML的には外部システムをアクターと捉えることもあるけど、RDRAでは外部システムとアクターを分ける。「バッチ処理」とかは「手段」なので、RDRAの地図では表現しない。外部システムがイベントに繋がって、そのイベントがユースケースに繋がる。イベントは外部のシステムの何とつながるのか、の「何と」を表す。アクターとユースケースの間に利用シーンを挟むのは?アクターとユースケースを直でつなぐのはあり。ユースケースが安定してるなら、利用シーンはいらない。ユースケースは「システム境界」。まとまらないなら「システム外部環境」を置きましょう。それが利用シーンになる。ユースケースを利用シーンより先に考えるチームが多い。そのあとロジック洗い出しをする。計算ロジックとか判断ロジック。ここまでに機能と情報は洗い出せてる。いうロジックが独自性なんだ、と探していく。DDDDDDはコアのロジックを探していく。DDDはシステム全体をどうつくるか、というのにはフォーカスしてない。RDRAで全体地図を作り、どこから攻め込むかを広く浅く見て、コアの部分をDDDで攻める。最後に洗い出した「情報」は、DBテーブルやクラスではない。付箋で出すと発散方向に向かうので、どう収束させるか考える必要がある。粒度を決めたらそのままうまくいくか、というと、うまくいかない。網羅しているか、とかわからない。いういうのをもうちょっと網羅してるとか、タイミングがどうあればいいのか、とか考え始めるとユースケースとか考えないと見えてこない。シーケンス図ではダメなのかシーケンス図とRDRAは対比できない。シーケンス図はあんまり書かない。シーケンス図を書くくらいなら、状態遷移図を書くかな。まとめ「画面」と「ユーザーストーリー」の関係を結びつけてみると、いろいろわかる。違う視点の要素をつなげてみる。それをチェックするのはSIでもWebサービスでも価値がある。今回伝えたかったのは、「繋げると議論ができる」という点。アクターとか利用シーンはシステム境界の外で、価値に関わる。ユースケースとかはシステム境界。そんなこんなで発表や質疑応答が22:00まで続きました。お菓子やおつまみも追加され、23:00頃まで懇親会。美味しくいただきながら、神崎さんや増田さんといろいろ会話させていただきました。先日の講演ベースのイベントに加え、こーゆうワークショップが別に設けられ、手を動かす機会があるのは凄く良いですね。短い時間ではありましたが、手と頭を使ってチームで意見交換しながら1つの成果物を作るのは良い経験になりました。RDRAは初めてだったのでシステム地図の作成には四苦八苦しましたが、議論を重ねつつとりあえず書いてみると、いろいろ見えてきて、更に議論が活性化される。線で繋ぐと異なる視点間の関係性が見えてきて、更に議論が活性化されます。関係性(リレーションシップ)で駆動するシステムの地図作り。RDRAの真髄と、実用性を実感できる良いワークショップでした。見ず知らずのメンバーが集まったチームで、短い時間のなかで、ユビキタス言語がみるみる育っていく光景は、感動的ですらあった。2017年4月19日あと、図書館で本を借りてきました。165,064Amazon.co.jpで詳細を見る体系的に学ぶのと復習を兼ねて、読んでみたいと思います。関係者の皆様、ありがとうございました。コメント(0)|-->プロフィールAuthor:makopi23某メーカーでソフトウェアエンジニアやってます。趣味はバスケ、筋トレ、プログラミングなどなど。