プログラマの思索

さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーに行ってきた。
要件定義の考え方がすごく参考になった。
感想をラフなメモ書き。

【元ネタ】
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper

要件構造の見える化 #RDRAセミナー: ソフトウェアさかば

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】要件定義の問題。
いつまで経っても、システムの全体像が見えない。
大量のドキュメントばかりで、肝心のシステムが説明されない。
分析と言う名の転記作業ばかりで、要件定義が完了しない。

では、どうすればいい？

要件定義、要件分析では、個人作業は非効率。
レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。

その場で皆で合意を積み上げて進める方がいい。
ステークホルダーの合意のベースを作る方が重要。

議論を積み重ねる時に、使われる手法として、リレーションシップ駆動要件分析RDRAがある。

リレーションシップ駆動要件分析RDRAでは、要件定義書の元ネタとしてモデルを作る。
その時、システムよりも、システムを取り巻く環境に注目する。

システムは、エンジニアがこだわりがち。
その中身の説明は、最終的にはプログラムであり、ユーザは理解しにくい。
エンジニアの立場では、システムの設計は自力で何とかなる。

しかし、システムを取り巻く環境の方が要件定義では重要。
先に、システムを取り巻く環境から、要件を先に固める。
いかにプログラムレスで表現して、エンジニアがユーザと会話できるようにするか？

【2】リレーションシップ駆動要件分析RDRAの構造は、「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」の４つ。

【2-1】システムの価値は、例えば、システムリプレースでは語られない時が多い。
AsIsは分かるが、ToBeが分からない。
ユーザから見れば、既に動いているシステムが要件そのもの、と言うが、実際は何のために作ったのか、その理由や背景が忘れ去られている。

【2-2】システム外部環境は、業務フロー、概念モデル(または用語集)、利用シーンから成る。
利用シーンは、業務フローがない場合に使う。
例えば、初めて作るユーティリティツールのように、まだ実際のシステムがない場合に、そのシステムがどのように使われるのか、という利用状況を描き出す。
業務フローがない場合、誰がどう使うのか、というイメージが湧きにくい。

利用シーンは、ユースケースとは違う。
ユースケースは、アクターとシステムの相互作用を表すから、システム境界に含まれる。
利用シーンは、システムを使って何が嬉しいのか、を表す。
利用シーンは、ユースケースが何故存在するのか、という理由や根拠になる。

【2-3】システム境界は、UIのような画面・帳票、外部I/Fのような外部システム連携などがある。

【2-4】リレーションシップ駆動要件分析RDRAは、モデル同士のリレーションに注目する。
リレーションシップ駆動要件分析RDRAでは、モデル同士の依存関係を表したい、という目的がある。

問題意識としては、混乱している要件定義フェーズを収束させたい。
その鍵は、モデルの依存関係にある。

よくある問題は、いきなり機能一覧を洗い出すものの、要件が発散してしまうこと。
特にリプレース案件で多い。
現状のシステムから、機能一覧はすぐに洗い出せるが、それだけでは要件定義は終わらない。

何故、その機能やデータがいるのか？
AsIsではなく、本来のあるべきシステム像は何なのか？
例えば、昔は汎用機やCobol、10年前はVBでガリガリ作られたデスクトップアプリだったろうが、現代では、クラウドの上のWebシステムや、工場でも作業者がタブレットを持って歩きまわるように実現すべきではないか？
AsIsの要件にひきずられると、高い費用を払ったのに、昔と変わり映えしないシステムになってしまい、ユーザにとって価値がない。

まずは、システムそのものではなく、システム境界を定めよう。
システムのスコープは何か？
システムとユーザのインターフェイスは何か？

システム境界の話で要件定義がまとまらないなら、システム外部環境に話を移そう。
どんな業務フローでシステムが必要なのか？
どんな利用シーンでシステムが使われると嬉しいのか？

それでも駄目なら、システムの価値を探ろう。
なぜ、システムは必要なのか？
誰にとって、システムは必要なのか？

「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」という4つの視点が重要。
でも文章では分かりにくい。
だから、図ないしモデルで描こう。

但し、リレーションシップ駆動要件分析RDRAで描いたモデルは、ユーザ向け資料の元ネタであり、ユーザ向け資料は別途作成する必要がある。

【3】Q.価値を考える人とシステムを考える人は別々になりがちだが、リレーションシップ駆動要件分析RDRAではどのように対応すべきか？

価値を考える人＝ユーザ、ドメインエキスパート。
システムを考える人＝アーキテクト、エンジニア。

あるいは、価値を考える人＝元請けSE。
システムを考える人＝下請けPG。
日本のIT業界では、多段階下請構造によって、要件定義とシステム開発の工程が分断されがち。

A.攻め方が違う。
初めての新規システム案件なら、システムの価値→システムの外部環境→システム境界→システムのようにブレイクダウンしていく。

リプレース案件なら、AsIsのシステムがあるから、システム境界(or システム)→システム外部環境→システムの価値のように、リバースエンジニアリングしてシステムの構造やシステム境界を明確にしてから、システムの価値を探っていく。
リプレース案件では、機能一覧は普通にあるはずなので、そこからシステムの価値へ登っていく。

どちらにせよ、4つの観点のブレイクダウンやボトムアップで双方向に行き来する。

【4】コンテキストモデルでは、アクターとしてステークホルダーを洗い出す。
要求モデルでは、アクターの要求を洗い出す。

お金の権限を持つステークホルダーとその要求を洗い出せているか？

業務フローは作業フローではない。
業務フローは、普通、システムに大きく依存する。
作業フローは不要。
担当者の作業はコロコロ変わるから。
ロールや業務を洗い出したい。

ユースケースは機能分割しない。
ユースケースは機能ではない。
リレーションシップ駆動要件分析RDRAにおける「機能」とは、パッケージ製品のカタログの機能一覧の項目と同じレベル。
例えば、MSWordなら、こんな機能があります、というイメージ。

イベントモデルは2種類ある。
例えば、GoogleMapsのように、1回のやり取りでデータが確定するもの。
それは、機能モデルで表現できる。

一方、外部システムとのバッチ連携のように、データを何度もやり取りする場合がある。
それは、プロトコルモデルで、状態遷移図として表す。
イベントが発生したら、次の状態へ移る、という内容をプロトコルモデルで表す。

【5】リレーションシップ駆動要件分析RDRAでは、モデルをEnterprise Architectで描きます。

設計開発を強力に支援するUMLモデリングツール Enterprise Architect 概要と特徴

Enterprise Architectの良さは、設計情報がリポジトリに格納されるので、モデルの関連付けが自動付与されること。
また、モデルを描けば、設計リポジトリから機能一覧をすぐに出力できる。
機能一覧を元に、ユーザにヒヤリングして、要件を深堀りできる。

さらに、依存関係が不十分なモデルがある場合、クエリを使って設計リポジトリから対象モデルをすぐに検索できる。
要件定義レビューの前に、担当者にモデルを修正するように作業指示も出せる。

他に、Enterprise Architectはリバースエンジニアリングが強い。
JavaやC#だけでなく、RubyやActionScriptなどの軽量言語もサポートしているのが強み。

Enterprise Architectで、現状のシステムのソースを全部読み込み、クラス同士の関連をリバースエンジニアリングした後、モデルを整理していけば、システムの構造が見えてくる。
そこから、システム境界、システムの外部環境、システムの価値を探っていく。

【6】リレーションシップ駆動要件分析RDRAで作成したモデルでは、網羅性と整合性の根拠を説明できる利点がある。

アクター→要求→利用シーン→ユースケース→画面→機能→データ　のように関連付けていくので、なぜその機能やデータが必要なのか、という根拠を説明することはできる。
つまり、ある要求に基づく画面や機能が網羅されているか、という根拠を説明はできるだろう。

また、モデルの整合性は、モデル同士のリレーション、依存関係で語れる。
例えば、機能一覧にあるこの機能は、このユースケースを実現したものであり、それはこの設計書に書かれている、など。

要件定義では、要件の網羅性、要件の整合性を語ることができれば、ステークホルダーを説得することができる。

【7】要件定義プロセスはタイムボックスで作業すると良い。
つまり、イテレーションごとに、要件定義を進めていく。

最初のイテレーションでは、荒い粒度のモデルしか作れないが、速く作れる。
3回ぐらいのイテレーションで、まずはシステムの全体像を把握できる。

その後のイテレーションで、モデル同士のリレーションを正しく書いていく。

つまり、前半のイテレーションでは、システムの全体像をつかむために速く成果物を作り、後半のイテレーションで成果物の品質を向上させていく。
すなわち、前半は漸進型開発、後半は反復型開発に切り替える。

【7-1】お客様は大量の成果物を好む。
詳細は見ないけれど。
お客様は根拠を聞きたがる。

お客様の打合せに合わせて、イテレーションを組み立てる。
お客様の打合せに合わせて、資料を作り、ブラッシュアップしていく。

まず、システム地図や機能一覧を作る。
そして、詳細を詰めていく。

マイルストーン(イテレーションの区切り)の単位で、成果物の範囲を決める。
そうすれば、要件定義が成果物の転記作業の繰返しにはならない。

【7-2】Q.リレーションシップ駆動要件分析RDRAでは、システムの実現可能性はどこで行うのか？

A.リレーションシップ駆動要件分析RDRAでは、要件定義とアーキテクチャの話を分けている。

・要件定義フェーズでアーキテクチャ設計は並行して行うが、要件定義とアーキテクチャ設計は別チームで行う

・要件定義チームから非機能要求を渡し、アーキテクチャチームでアーキテクチャ候補を返す

・二つのチームは手段で話をせずに非機能要求で話をする。

・後付けでもいいので「非機能要求があってアーキテクチャがある」という形は崩さないことが重要。そうすればアーキテクチャ決定の根拠が明確になる

要件定義チームとアーキテクトチームに分けた理由は何か？
アーキテクトが要件定義チームに入ると、ブレーキをかけがち。
例えば、その要件は、現在採用しているフレームワークやアーキテクチャでは実現できませんよ、とか。
あるいは、リプレース案件では、AsIsのアーキテクチャに引きずられて、ToBeのアーキテクチャを考えにくくなる。

【8】今日は、システム地図を書きます。
システム地図とは、アクター、ユースケース、画面、機能、データ、外部システムなどの項目を関連付けて、システムの全体像を表したもの。
システム地図は数時間で書ける。

RDRAのモデルは種類が多いので、丸一日かかる。
だから、今日はシステム地図を書きます。

【8-1】僕達のチームで作ったシステム地図はコチラ。
@spring_kumaさんのおかげで、かなり品質の高い成果物が作れたと思う。
@spring_kumaさんに感謝。

【9】システム地図を書いた感想：
僕の感想と、発表後に聴衆の方からあがった質問も書いておく。

【9-1】利用シーンとユースケースの使い分けが難しい。
混乱した。

利用シーンは、システムを使って嬉しいこと。
利用シーンは、ユースケースの根拠になる。
なぜ、そのユースケースは必要なのか、その理由は、こんな利用シーンが必要だったから、と。

【8-2】ユースケースは出しやすい。
ユースケースはアクターとシステムのインターフェイスになるから。

ユースケースは普通は画面で実現される。
つまり、ユーザがシステムとやり取りするI/Fが画面だから。
そして、画面のボタンが「機能(Function)」になる。

【8-3】要求が結びつくアイコンは？
それはアクターまたは利用シーン。

機能に要求を結びつけても説明しにくい。
モデルが複雑になる。

【8-4】メール送信や決済代行システムのモデルが表現しにくい。
バッチ処理で描こうとして、上手く書けない。
僕らのチームは、画面から予約ボタンを押したら、予約確認メールが飛ぶような仕組みで表現して逃げた。

神崎さんの回答は、バッチかどうかはアーキテクチャの話。
要件定義では、アーキテクチャの話は不要であり、システムと機能やデータがどのように関連付けられているか、が分かれば十分。

【8-5】システム地図を描く利点は、自分たちが弱い部分が判明するのが良い。
例えば、決済代行システムの部分が描きにくい、など。

システム地図が描きにくい部分のモデルを特定できれば、ユーザのヒヤリングをその部分に集中することで、ヒヤリングの精度を上げることができる。
不明点に重点を置いてヒヤリングすればいい。

【8-6】システムの地図の粒度は？

粒度はケースバイケース。
イテレーションごとに詳細化していく。
最初から細かく書く必要はない。

最初のイテレーションでは粗い粒度で、システム地図を描き、システムの全体像を把握し、自分たちの弱点を見出す。
その後のイテレーションで、ユーザにヒヤリングしながら、モデルを詳細化していけばいい。

【8-7】他チームのシステム地図で面白かった点は、利用シーンから考えたので、良い議論ができた、ということ。
例えば、貸会議室.comのお題は、利用者と貸主のマッチングサイトを作ること。

その利用シーンとして、貸主が空いている貸会議室を登録するだけでなく、貸会議室.comでは儲からないから、貸し会議室.comから貸会議室を予約取り消しする機能が必要だね、という議論があったらしい。
僕達のチームでは、そんな発想は出なかった。

つまり、利用シーンを元に、メンバー同士で議論していたら、そんな機能が必要である可能性まで深く議論できたことになる。

【8-8】貸会議室.comのお題というリッチピクチャがあったから、システム地図が描きやすい。
実際の要件定義では、貸会議室.comのお題のようなリッチピクチャは存在しない。
真っ白な所から、システム地図を描き出す必要がある。
要件定義は、そういうもの。

【9】リレーションシップ駆動要件分析RDRAの全体感想：

「モデルベース要件定義テクニック―要件定義書がスラスラ作れる」を読んでいたから、4つの観点やモデルは理解していたが、実際の話を聞いてかなり理解できた。
神崎さんの話を聞くと、要件定義でよくある失敗を踏まえたノウハウがたくさん散りばめられている。

【9-1】要件定義フェーズでは、少人数の担当者が限られた期間で要件を収集し、ステークホルダーの合意を得て、要件を確定しなければならないプレッシャーがある。
また、作成した要件定義書は、その後の設計・開発フェーズの元ネタになるので、開発チームにとって非常に重要だ。

例えば、要件定義書で既に要件が漏れていたら、開発チームは対処できない。
受入テストになって初めて、要件漏れが発覚して、デスマーチになりがち。

あるいは、システムの価値は要件定義フェーズでしか得られない。
要件定義フェーズでシステムの価値を明確に定義できなければ、開発チームは、システムの価値を気にせず、ひたすら作ることだけに集中してしまいがち。
受入テストになって初めて、ユーザからこんなシステムが欲しいのではなかった、と言われる。
でも、開発チームにとって、そんなことを言われても、自分たちの責任ではないよ、と言いたくなる。

【9-2】リレーションシップ駆動要件分析RDRAのポイントは、二つあると思う。

一つ目は、モデル同士の依存関係に着目することで、要件の網羅性や整合性の根拠を説明しやすくなること。
ユーザからの質問や要件定義ビューで、要件の網羅性や整合性の根拠を語ることが出来れば、スムーズに要件分析できる。

2つ目は、要件定義もアジャイル開発のようなタイムボックス型の作業にすることで、要件定義の成果物をブラッシュアップしやすくなること。
最初から完璧な要件定義書を作るのではなく、イテレーションに応じて、粒度を変えて、詳細化するタイミングを設定すればいい。
例えば、2ヶ月間で要件定義を終わらせるならば、1週間毎にユーザヒヤリングの場を設けてマイルストーン化し、最初はシステム地図で全体像を把握し、機能一覧を作り、詳細化していけばいい。

このテクニックを実際の現場でも使ってみようと思う。