要件定義の素人なら、とりあえずRDRAをやった方が良いと思う
タイトルは、最近システムを開発する業務でサラリーを頂く身になって感じる事。
RDRAとは、神崎善司さんが考案した Relationship Driven Requirement Analysis = 関連により駆動される要求分析のことである。
やり方は、↓この本に書いてあるから読んでください。
システムを使う理由
システムを使うのは、人間の活動(業務)の中で、人間がシステムを使う事によりメリットがあるからだと思っている。
メリットとは、時間の短縮、脳への負荷の軽減、情報伝達などである。
具体的にシステムは、人間の機能のうち下記のような代替が得意だと考えられる。
- 人間による記憶の代替
- システムによる記録
- システムによる記録した情報の参照
- 人間による計算の代替
- システムによる計算
- 人間による論理的判断の代替
- システムによる判断
- 人間によるコミュニケーションの代替
- システムによる情報伝達(文字情報、画像情報、音声情報、動画情報など)
システムによる代替の問題点
人間の活動(業務)の広範囲を上記のようなシステムによる代替に置き換える事が出来る。
結果として、不要なシステムによる代替も作ろうと思えばたくさん作る事が出来る。
要件定義???
僕の観測範囲では、要件定義と言われる活動は、要件定義というフェーズを謳った上で、要件定義では無い行為をするケースが多いと感じる。
僕の経験で語れば、要件定義というフェーズを謳ってFigmaなどのツールでワイヤフレームを作成するようなケースもあった。
デザインのプロであるデザイナーがそれっぽいワイヤフレームを作り、ワイヤフレームを叩き台にして、要件定義の素人同士(例えばデザイナーとプロダクトマネージャーやら)で、素人達が今まで使った事のあるアプリの経験による暗黙知から、「●●みたいな機能がココにあったら良い気がする!」・「ここに会員情報として名前と年齢と住所を表示しよう!(何となく)」みたいな会話でシステムに必要な機能が生まれる。
これを要件定義と呼ぶのは、システムに本当に必要な機能が埋もれてしまい、あまりよく無いと思っている。
何故なら、画面イメージから素人の経験やセンスを根拠にしてシステムに組み込む機能が生まれているからである。
では、何を根拠にすると良いのか?
僕は、「システムの利用者が利用するかどうか」を根拠にすべきだと考える。
とにかくシステムの利用者を第一に考えなければいけないと考える。
システムの利用者の声を聞く または システムの利用者の声を根拠にしようと努力しなければいけないと考える。
なぜならシステムを利用するのは利用者だからである。
当然の事なのに、実際の意識は利用者ではなく、イケてる度であったり、マネタイズであったり、経営者を納得させる資料をどう作るかだったりに向いている事が多いと感じる。
RDRAが解決してくれる事
僕は要件定義の素人である。
だからRDRAを使う。
RDRAは、まずシステムの目的を定義する。
その目的に関連付けてシステムの利用者を定義する。
そのシステムの利用者に関連づけて、実際の利用者のコンテキストと大まかな業務(活動)を定義する。
その利用者の業務に関連づけて、業務(活動)の種類を定義する。
その業務(活動)の種類毎に関連づけて、業務の流れを定義する。
その業務の流れに出現する各業務(活動)に関連づけてシステムのユースケースを定義する。
これを素早く間違っていてもいいからドンドン作り上げる。
だから素人でも関連を辿っていけば、システムの利用者がシステムを使うとメリットがありそうな機能を発見する事が出来る。
素人がワイヤフレームを見ながらアプリの利用経験やセンスを頼りに何となく機能を定義していくより必要な機能が生まれやすいと思っている。
結論
タイトルどおり