システムの価値を見え化する[RDRA:システム価値]


私たちの会社では月1回の勉強会でRDRA/ICONIX/DDDを実践してみようと言うことになりました。
(実際は私が勉強会を仕切ることになったので勝手に実践することにしました。)

今回はRDRAのシステム価値について。

今回の勉強会では会議室の予約システムを作成しようと言う事になり、今まで紙で管理していたものをシステム化してみようと言う事になりました。
そこでまずはAS-ISからコンテキストを考え、その後TO-BEを作成しました。
コンテキストモデルは関係者(ロール)と外部システムをはっきりすることが目的です。実際のシステムの価値を定義するのは次の要求モデルの作成時です。

しかし、今回コンテキストモデルをAS-ISとTO-BEで考えていく中で、今回のシステムでの価値がよく見えるようになったという驚きがありました。

今回の例では(自社で役立つものを勉強会で作ろうとなっているのでちょっとこのブログでは自社の情報が出ないようにフィクションを加えて変えていますが・・・)AS-ISでは紙に記入(予約する)のも確認するのも総務の仕事でした。他の社員は総務部に出向いてまたは電話で予約や確認をしてもらっていました。TO-BEでは誰でも予約できるようにシステムと社員とを線で結びます。

AS-ISでは社員はシステムの外側にいたのがTO-BEでは内側になります。
ここで気がついたのは、システムが社員の誰でも予約ができるようになったという価値を与える事になったという事。そして、総務の会議室の予約・確認の仕事がなくなったというシステムがもたらすであろう価値が出てきてそれがはっきりと見えたと言う事です。

この後、お客様から予約はいままでどおり総務が行い社員は予約状況を確認でき、予約申請だけをできるようにしたい、と言われたとします。
そうすると社員はシステムから線が引かれている事に変わりがないもののその意味が異なってきます。

社員から見たシステムの価値はどこからでも予約状況が見れる事にとどまり、総務から見ると価値は確認作業の仕事だけがなくなった事になります。
最初の方が価値が高いようにも見えますがそこはお客様の会議室の管理の方針やセキュリティーなどを考えて決まって行くのだろうと思います。

こうしてみるとシステムの価値というのはシステムありきで付与されるのではなく、要件定義の段階で決定していくものでそれはとても重要で省略できないものだと思いました。

そして、RDRAではシステムの価値を簡単に見える化する事ができます。

コンテキストの後に作成する要件の洗い出しもコンテキストがないとできません。それは要件の洗い出しはコンテキストに登場する役割・役割から引かれている線(システムとの関わり)ごとに洗い出していくものだからです。

もうひとつ、この先要件定義が進むことによってシステム価値も変わる可能性が高いなと思いました。
実際、要件の洗い出しの段階で少しコンテキストを変更しました。
そこで役にたつのはタイムボックスの考え方です。この部分はAgileに通じるところなのでAgileなチームには取り入れやすいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です