2020-07-22 テレワーク下の要件定義（RDRA：ラドラ）
2020/07/22 に開催された テレワーク下の要件定義（RDRA：ラドラ） のイベントレポートです。
●イベント概要
チェンジビジョンWEBセミナー第2回目は、テレワーク下でもスムーズに高品質の要件を定義する手法として、要件定義用のモデリング手法(RDRA)に基づくモデリングとダイアグラム活用法を、株式会社バリューソース 代表取締役 神崎 善司様からご紹介いただきます。
■雲の上の要件定義
神崎 善司さん [バリューソース]
●要件定義あるある
・精度の低い要件定義
概要、一覧、詳細
フォーマットを埋めるのが要件定義だ
・時間切れになる要件定義
最初から全速で走らないと時間がない
1ヶ月で週2回の打ち合わせなら8回しかない
・曖昧な要件
アジャイルでよくある
とりあえずつくって考える進め方
調達や物流どうしますか？決まってない
実装すると仕様は見えるけど
要件って見えますかね？
●テレワークあるある
・伝わらない
・集中力が続かない
・結局なにか決まったの？
・私は何をすれば？
●ビデオ会議の議論を促進する
・大型案件での概要、一覧、詳細
残念ながらテレワークにマッチする
今まで以上に精度が下がる
・話が散らばる
RDRAのモデルに要件をすべて込める
可視化して、細かい話にならないように俯瞰
・えっ、そういう意味だったの
ダイアグラムで用語を定義
・結局なにか決まったの？
ダイアグラムに議論の結果を反映する
・私は何をすれば？
「このダイアグラムのここをつくる」
・個人作業が全体とつながらない
ダイアグラムがつながっているので
個人の作業が全体につながる
・伝わらない雰囲気、細かい話だけで時間切れ
可視化することで、ビデオ会議でも
要件定義がうまく進むのでは？
●RDRAが解決したい世界
・管理指向が強いプロジェクトの精度が低い
20年くらい前からある
大きなプロジェクト
概要、一覧、詳細とガントチャート
精度が悪い
・アジャイル開発 いつ終わるんだ問題
機能追加の新規開発はスムーズ
実装済みが増えてくると関わる部分が手戻り
手戻りに手が回らない
・保守開発のリリース後トラブル
関係者が多い
関係者が関心がある所しかカバーできない
誰も関心がない部分に障害が落ちる
●RDRAの立ち位置
・システムの要件はこうだ！だけ
→ 詳細な仕様が決められない
・システムを取り巻く環境まで含めて要件
→ 詳細な仕様を決められる
・実装のためには
システムのことだけ決めても進められない
●RDRAレイヤー
・システム価値
どういう価値をもたらすものか
・システム外部環境
システムの使われ方を示す視点
・システム境界
システムの入出力を明らかにする
・システム
システムの上で実現したい情報と状態
・依存の方向
システム
→システム境界
→システム外部環境
→システム価値
・アイコンをつないで行く
左に行くとWhyを示す
この画面がいる/いらないの議論は
入出力を整理して決まる
・いかに効率的に進めるか
要件定義はすぐに時間が過ぎてしまう
●ダイアグラムで要件を定義
・システム価値
要求
アクター
外部システム
これらがビジネスを構成する
・システム外部環境
業務
ビジネスユースケース
業務フロー
利用シーン
ツールのようなフローを形成しない場合
販売管理業務
コンビニ向け、大手流通向けなど
チャネル別のフロー
チェネル別にビジネスユースケース
ビジネスにはバリエーションと条件がある
・システム境界
業務フローにユースケースが紐づく
人が関わる場合画面がある
システムが係る場合イベントがある
・システム
情報
銀行から100万引き出す場合
口座番号、100万
情報を利用して作業する
状態
システムで再現する状態はなにか
出荷したら出荷指示済み→出荷済み
状態遷移にユースケースをはめる
画面、イベントからユースケースに統一
・ダイアグラムで要件を定義する
●RDRAの構造
・読みやすさ、わかりやすさで整理
・ビジネス要素を書くようにしている
イメージはリッチピクチャ
・業務に対してビジネスユースケースが1枚
業務がどのビジネス要素と絡んでいるか
・関わるものでビジネスユースケースが決まる
●ダイアグラムの関係
・システム価値
システムコンテキスト
要求モデル
・システム外部環境
ビジネスコンテキスト
ビジネスユースケース
業務フロー、利用シーン
フローがなければ利用シーン
ビジネスルールが出てくれば
バリエーション/条件
・システム
情報モデル、状態モデル
・システム境界
UC複合図
ユースケースとつなげて要件にする
・細かく見えるが、大した情報は書いていない
大抵の要件定義ではこれを長々と書いている
・ビジネスユースケースは価値、責務の単位
１つのBUCを１枚で俯瞰できる
ナラティブフローを縦に書いている
・RPAでは人とロボットが混ざってわかりにくい
業務フローでは何をやっているかわからない
最近は業務フローではなくBUCごとに
UC複合図１枚で描いている
●ビジネスルールを表現する
・条件
名前付けられた式
表形式で表現されたもの
・大事なのは、表の軸になるバリエーション
会員種別：大人、子供
・条件になるのは
バリエーションの組み合わせ
バリエーションと状態の組み合わせ
・要件ではバリエーションを明確にする
ビジネスを変化させる
変えるパラメータを持っている
パラメータはバリエーション
意識していないが
条件で表現される
バリエーションが明示されていない
●ASTAHでも表現できる
・図書館システム ASTAH
全てクラス図
ステレオタイプで形を変えている
図書館システム自体はRADRA2.0ハンドブックで紹介
●RDRAの関心
・素早く定義する
決定するというよりも、その場で決める
会議の場でどんどん直す
個人でドキュメントを作るのではなく
会議の場でつくっていく
・精度を高める
整合性が取れていないのが一番の問題
信用できる要件
要件定義工程の時点での網羅性を確保
・プロジェクトの特性に応じて使い分ける
要件定義を精度を高く
アジャイル開発の入力
BUCまでを素早く導出
ビジネスルールの明示
バリエーション、条件の整備
状態モデルの整備
→仕様が決まる
実装できる
・保守開発の品質を上げたい
関係者の認識を合わせる
システムの今を表す
品質を上げようにも、システムが
どんなものかわからなければできない
複数の保守案件が並行しても最新を維持
とある単位で差し替える運用
●RDRAは何を変えるのか
・物事のつながりで詳細を語る
・成果物作成よりも合意を重視
・成果物ではなく要件を組み立てる
・複数視点の構造がWhyを語る
●QA
・終わりの見極めポイントは？
プロジェクトの状況に応じて
精度を上げるなら、全部つくる
アジャイル開発しながら精度を決めるなら
BUCがあればPBLは出せる
ちゃんとした仕様で作っていきたいなら
バリエーションの抽出はしっかり
そのプロジェクトで要件をどこまでやるか
使う側で見極めていく
・規模が大きいときに、どう一枚に抑える？
ビジネスコンテキストの業務の数が最初
通常、そんなに多くの業務は出てこない
せいぜい4,5個
ここから階層の中で規模が広がっていく
システムの規模はユースケースの数
ビジネスユースケースの数
ビジネス価値から考えると
そこまで発散しない
・ICONIXやDDDとの組み合わせはどう思う？
情報モデルや状態はドメインに直結する
DDDの親和性は高い
RDRAは画面を細かく出さないので
ICONIXを使ったほうが詳細化できる
RDRAの情報とICONIXのエンティティ
RDRAの情報のほうが粒度が粗い
・何を持って要件定義の完了？
政治的に期限が決められている
どこまでやるかを決めていく
決めたデッドラインがあるなら
それを守ったほうが良い
間に合わないなら粒度を上げていく
その日を迎えて、この粒度で良いか？
信用を失うと、その後の仕事がやりにくい
・複数のシステムを考える場合の進め方は？
大きなシステムをやる場合
何かしらのチームに分かれる
別れた単位でRDRAのモデルを作る
他チームは外部システムのイベントと捉える
チームの切り方がおかしければ
途中で切り方を変えまる議論は必要
●ダイアグラムを使って仕事を定義
・ゴールに繋がる仕事を定義する
要件定義のゴールを明確にする
要件の組み立て方を共有する
RDRAのダイアグラムで仕事を定義する
・要件定義のゴール
システム化のスコープを決める
関わるアクターはこれとこれ
→ 一旦スコープを切っていることになる
もう少しちゃんと定義しましょう
→ 実現するユースケースはこれとこれ
どこまで明確にするか
仕様の土台を作る
単独で仕様を決められることはない
他の仕様に必ず依存する
わかっていない仕様の部分を類推
仕様の土台を作って進める
●ビデオ会議と個人作業の役割分担
・ビデオ会議
認識合わせ
方向性の検討
考え方の共有
作業内容の確認
・個人の作業は、ダイアグラムの一部を作る
ビデオ会議の中で一緒に作ってみて
どんな感じで作るのかを共有
その後で個人で作る
●ダイアグラムごとの役割
・階層化してスコープを決める
ビジネスコンテキスト
ビジネスユースケース
UC複合図
・ビジネスコンテキスト
ビデオ会議
・ビジネスユースケース
何をおいて何を置かないかを議論
・UC複合図
議論に基づいて作成
・システムの詳細化が個人作業
・コア表現はビデオ会議で共通認識をつくる
●ビジネスとダイアグラムの対応
・メンバー全員がRDRAの構造を理解して議論
ビジネスがどうシステムに落ちていくのか
●ビデオ会議・個人作業とダイアグラムの対応
・進め方
ビデオ会議 セッション※要件定義メンバー
個人作業
ビデオ会議 個別
・流れ
要件の方向性を検討
コアの洗い出し
ここがDDDとの親和性
要件の組み立て
●仕事の候補：要件の方向性検討
・ビジネスコンテキストをみんなで議論
・ビジネスユースケース１つか２つビデオ会議
→個人で
・UC複合図
BUCのアクティビティを考えておく
現場のヒアリングは大変なのでスコープ外
一旦はアクティビティごとに
ビジネス要素とのインタラクションを
ざくっと置く
ビジネス要素とのインタラクションを
時系列で並べたものがユースケース
●仕事の候補：コアの洗い出し
・ビジネスを駆動する用語を構造化したのが情報
・思いつく主要な用語をポンポンと挙げる
銀行から100万引き出す
銀行、口座、引き出し金額
・ビデオ会議で挙げてみて、誰かがたたきを作る
・状態モデル、バリエーションも同様に進める
量が多いところは個人で
ビデオ会議の中でやり方を共有したあとで、個人作業
・ガントで線を引いて進める感じではなく
次のビデオ会議までに進めて
次はどうするか、を繰り返していく
●仕事の候補：要件の組み立て
・UC複合図
アクティビティとビジネス要素との
インタラクションのつながり
・ちゃんと書こうとすると手が止まる
まずは書いてみる
・ビデオ会議でみんなで書いてみて、個人作業へ
個人作業は、調べてみてたたき台を作る感覚
書いてみると課題、問題が見えてくる
・ビデオ会議で、出てきた課題、問題を考える
●階層表現とコア表現で整合を保つ
・ビジネスを階層化してUCにつなぐ
頭の中
ビジネスコンテキスト
BUC
UC複合図
・コア表現でUC横断に整合性を確保
情報は、UCで変更する
情報は構造を持っている
状態は、UCで遷移する
情報を操作して、状態を変える
状態は、情報で保持される
状態の繋がり方が、状態を示している
つじつまが合うようにしていくと
精度が上がっていく
・最初から正しく書こうとすると時間がかかる
まずは、とにかく洗い出す
つじつまを合わせていけば精度が上がる
●QA
・情報モデルとクラス図との違いは？
多重度を気にしだすと、正確に分析か必要
情報モデルは多重度を考えない、ラフなもの
クラス図にすると詳細化しすぎる
ものすごく単純なクラス図が情報モデル
・情報モデルとER図との違いは？
情報の構造よりも、どんな項目があるのか
概念モデルを書いても良いが
RDRAには混ぜない
●どうやってスムーズに進めるか？
・要件定義は話がぶれます
どうやってブレさせずに
決められた時間の中で組み立てていくか
・フォーカスを合わせる
・要件を組み立てることに意識を向ける
誰かの中にあって
ヒアリングしたらできるものではない
・要件を分析して精度を上げる
・要件定義の立ち位置
ウォーターフォール
要件定義→後続
繰り返し開発
要件定義だけはやってから、繰り返し
要件は別で進めながら、繰り返し
実装を進めていくと仕様は決まる
実装を進めても要件は固まらない
●仕事をスムーズに進めるために
・3フェーズをどんどん繰り返す
議論のベースを作る
要件の形を作る
ビジネスルールの明示
・定義データを加工して精度を高める
要件定義したものはデータ
開発工程の自動化は進んでいるが
要件定義でもツールを活用して、効率的に
●スムーズに進めるための進め方
・フェーズ1：議論のベースを作る
穴だらけでもまずはつくれるところを書く
メンバーの知識レベルがわかる
2,3日で
議論がブレにくく、空中戦がなくなる
・フェーズ２：要件の形を作る
階層とコアの繋がりを回していく
・フェーズ３：ビジネスルールの明示
単純なレビューはビデオ会議だと眠い
モデルをエクセルに抽出
ピボットテーブルで分析
別視点で洗練していく
●もう少し詳しい手順
・フェーズ1：議論のベースを作る
Step1
１日
業務、ビジネス要素
Step2
１週間
BUC、アクター、外部システム
２，３日
アクティビティ
はじめはエクセルで一覧でも良い
Step3
情報モデル
ツール化してしまっても良さそう
Step4
状態モデル
ツール化してしまっても良い
・フェーズ２：要件の形を作る
Step1
トップダウンで組み立て
Step2
情報、状態でUCを組み立てる
・フェーズ３：ビジネスルールの明示
Step1
トップダウンでバリエーションを洗う
Step2
ボトムアップでバリエーション、条件を洗う
アイコンのつながりで議論を噛み合わせる
・定義ができてくるとデータになる
データを加工して、ビデオ会議で使う
・こういう視点で分析、明確化しましょうが
ないとふわふわしてしまう
・できたものを単純に説明すると眠くなる
複数を組み合わせて議論する
●しくみ：ビジネス表現からシステムにつなぐ
・アイコンのつながり
BUCとUC複合図のつながり
UC複合図と情報モデルのつながり
など
・議論を噛み合わせることに注力
ここはどうなっているの？の会話
●しくみ：難易度からシステム特性を分析する
・複雑度と数量で、難易度のレベルを決める
要素数
形を目視でチェック
UCたくさんあるけど単純
UC少ないけど、接続が多数
など
●しくみ：ユースケースの特徴を分析
・一つ一つのUCを見ていくのではなく
UC、情報、条件、状態の関わりを分析
条件と状態に結びつくUCは重要
情報と状態につながるUCは連携が必要なUC
など
・システムの特徴を捉えていく
アジャイルに回すにしても
どう攻めるのかに直結
●しくみ：システムの偏りを分析
・そのシステムに詳しい人の会話
規模は大きいけど、出力が多い
殆どの出力は一部の情報から出力されている
ほとんどの出力には対応する情報がある
・出力と情報が対になっている
システムにとって枝葉の存在
・一部の情報から出力されている
イテレーションで出力を増やすと後で辛い
・UC、情報、条件、状態の関連から傾向を見る
難しく見えるが
詳しい人の会話の内容と同じこと
●しくみ：ビジネス要素の関わりから正しさを検証する
・アクターや外部システムがどんなものかわかっている
・担当者はBUCを細かくつくっている
・業務に詳しい人が、関連を確認
一つ一つを見ていくのではなく関連に違和感があるものを
ビデオ会議の中で確認していく
●各ダイアグラムの状態で状況を把握する
・３フェーズでダイアグラムを書いていく
・時間とともに、ダイアグラムの網羅率と精度が上がっていく
決められた期間の中でどこまでやるかを調整する
・ダイアグラム間の関係を俯瞰して、状況を把握する
●まとめ
・ビデオ会議は空気がつかめないので難しい
・RDRAで議論を進める土台を作る
・ビデオ会議で議論しながらダイアグラムを書く
・個別にダイアグラムを書くときに見つけた問題をビデオ会議で検討する
・決められた期間の中で網羅率、精度をどこまで上げるかを調整する
■感想
ダイアグラムで要件を定義することで、システムの傾向を分析できるようになる。改めてRDRAの強さを感じました！
モブワークで方向と進め方の認識を揃えてから、非同期に個別作業。個別作業はあくまで問題の洗い出しの扱いで、同期するタイミングで検討する。要件定義でこのプロセスを確立できるのはすごいですね。
定義の型をつくることで、プロセスも型をつくることができる。定義、プロセスの型があることで、テレワークなどチームの状況に合わせて、型から拡張したプロセスをつくることができる。今回は単一タイムゾーンでのテレワークでしたが、複数タイムゾーンやコアタイムが異なるテレワークでも、今回と同様に拡張できそうですね！
とてもワクワクするセミナーでした！神崎さん、運営の皆さん、ありがとうございました！！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。