mizzsugar’s blog

日々感じていることや学んだことを書きます。エンジニアリング以外にも書くかもしれません。

「 RDRA2.0 ハンドブック」を読んで

要件定義がうまくいかず憤っていた所、一緒に仕事している人から紹介してもらいました。 影響範囲の調査にヌケモレがあって手戻りが多いことが悩みでした。 読んで見た結果、「なんか要件定義うまくいかない」状態から 具体的に何が良くなくて次はどうすべきなのか見えてきました。

https://www.amazon.co.jp/dp/B07STQZFBX/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

目次

  • この本を読む上での前提知識
  • オススメの読者
  • この本から得た学び

この本を読む上での前提知識

前提知識というか経験になりますが、システム開発(本著でのサンプルがソフトウェアなのでソフト寄りなイメージだけど、ハードにも当てはまるのかな?)における要件定義の経験がないとこの本がピンとこないかもしれません。

オススメの読者

  • 要件定義の手法をなんかしら知りたい人
  • 要件定義に課題感を感じている人(ふわっとしている、手戻りが多いなど)

この本から得た学び

RDRA2.0 とはどんな手法か

文章ではなく図で表現することと、機能だけでなく要求から定義することが特徴です。

  • 図を使って要件を表現する。
    • 要求、システムを使う業務での登場人物、外部システム、情報などをアイコンで表現する。
    • アイコンで関連するもの同士を線でつなげる。
  • 定義するのは、開発する機能だけではない。以下のレイヤーに分けられる
    • そのシステム自体が提供する価値。いわゆる「要求」というやつ。
    • そのシステムが使われる業務。これはシステム使わない仕事も含めて定義する、
    • 業務内でシステムが使われる場面。
    • システム内で扱われる情報。情報の項目・その情報の状態(ex: 未予約、予約中)・条件を定義。

アイコン同士の繋がりで表現した図は、各レイヤーのつながりが一度に見れること・つながりによって関連箇所が見えるので影響範囲がすぐ分かるのが良いです。整合性の担保も楽になりそうです。 また、すべての根本である要求につながるので、新しく何か開発する時に「要求を満たすのか?」という問いに集中できそうだと思いました。

本著では、図書館の司書業務を支援するソフトウェアをサンプルに要件定義しています。要件定義によって出来た図と実装のサンプルが公開されています。 実際の図や実装はこちらを見るとイメージしやすいです。 github.com

自分の要件定義の方法とRDRA2.0の比較

新しく開発する機能について文章化する方法をとっていたのですが、良くない点が明らかになりました。 特に影響範囲の調査でヌケモレがあって手戻りが多いのに悩んでいたので、アイコンのつながりをたどるアイデア目から鱗でした。

開発する機能についてだけ文章化する方法は、影響範囲の調査が個人の能力や知識に左右されがちですが、 図で可視化すると影響範囲の調査でやることが明確(関連する線をたどればいい)なのでそのギャップが解消されそうです。 特に、条件や状態を追加する際の影響範囲の調査が難しいと感じていましたが、条件や状態を表現する項目が使われる箇所もアイコンで表現されているので良いと思いました。

従来 RDRA2.0
機能の定義 機能についてだけ書く。使われる業務については必要なら書く 業務だけでなく要求にも言及
影響範囲 技術者としての勘とその人が持っているシステムに対する知識に頼る アイコンの繋がりでたどる

分からなかった箇所

  • 「システム価値」レイヤーにある「外部システム」に当てはまるものは何か。SlackなどのチャットツールやEmailは「外部システム」なのか判断出来なかった。ひとまずは、SlackやEmailは他社から提供されているので外部システムとみなして図を書いてみようと思う。
  • 自動で行われる定期処理は「システム境界」の「イベント」にあてはまる認識でOK?