イベント参加レポ：RDRA＋プロトタイピングおよび仕様化事例紹介
こちらに参加してきました。最近ちょっとRDRAを調べていたので、興味がわき。内容としては、RDRAと他の技法を使って要件定義をうまくやる、という話でした。
RDRAを使った要件定義の流れ
・全体像をつくる
・BUCのフロー（大きな流れ）
・アクティビティ図で業務の流れを決める（BUC）
・それぞれのアクションに対してユースケースを紐づける
・ユースケースと画面を紐づける
Relationshipと命名されているだけあって、上から下まで流れがきれいですよね。画面を詳しく書いてFBをもらって、業務フロー自体を見直す、という活動はいいな、と思いますが、ディスカッション中にでていた「画面で議論すると意見が出すぎる」という話も理解できます。（実感があります）
まぁうまく意見調整ができるだけのファシリテーションスキルがあるのであれば、意見の爆発的なのは怖くないのかな、とも思います。
RDRAだけでは困る点
モデルをいきなり見せても意外と要望が出てこない、とのこと。確かにそうですねー。難しい話をいきなり出すと、結構ひかれちゃうことはよくあります。難しい。で、合意したつもりで進めていくとどんでん返しが起きるという。
画面イメージでは「本気の意見」が出てこない、というのもありました。本気の意見、という表現けっこうすきです。これも実感があって、ある程度ちゃんと動いたりしないと、自分の使っているところまで想像が進まないんです。本気にならないんじゃなくて本気になれない感じですね。そのために、ある程度精度の高いプロトタイプを使う、と。よくわかるなぁ。
その他Tips
「業務を実現する、と、業務を効率化する、を分けないとつらいことが起きる」というのもあまり意識してはいなかったですが、あるなぁと思いました。業務を実現するのと効率化をするのでは使う脳が違う気がするんですよね。前者は左脳的、後者は右脳的、みたいな。（脳科学の専門家ではないので適当発言ご容赦を）
それを同時に話すと議論がうまくいかない、というのは納得感がありますね。
道具の引き出しを持つことが大事、というのもすごくよくわかります。ロジカルに考える力を持っていても道具立てがないと時間が何倍もかかってしまう。自分が考えるようなことなんて誰かがどこかで考えているんだから、使えるネタを勉強してたくさん持っておいて、組み合わせだけオリジナルにするというのが良いんだな、と今日の話を聞いていても改めて思いました。
勉強させていただきありがとうございました。