システム価値の整理 - 神崎コンサルノート

前回は４つの視点毎にどのような情報を定義するかを示しました。
今回はシステム価値についてもう少し掘り下げて説明したいと思います。

RDRAで定義したモデルのイメージは以下にあります。

http://k-method.jp/sample/sample_info_site/index.htm

　●コンテキストモデル　左のツリーを以下の順番で展開してください
　　　ビュー
　　　　→システム価値
　　　　　　→コンテキストモデル
　　　　　　　　→運用時コンテキスト
　　　　　　　　　　→運用時コンテキスト（クリック）

　●要求モデル　左のツリーを以下の順番で展開してください
　　　ビュー
　　　　→システム価値
　　　　　　→要求モデル
　　　　　　　　→機能要求モデル
　　　　　　　　　　→機能要求モデル（クリック）

今回はシステム価値の視点について説明します。
ここではシステムに価値をもたらす情報を明らかにします。
そのために以下の４つの事を明らかにします

　・システムの目的、役割
　・システムに関わる人
　・システムと連携する外部システム
　・要求の把握

このうちコンテキストモデルを使ってシステムの目的、役割、関わるアクター、連携する外部システムを整理します。
要求は要求モデルを使って整理します。

システム価値は最終的にシステムに関わる人（役割）を明らかにし、その人たちの要求を整理、分析するところです。
同時に連携する外部システムを明らかにし、それらのシステムに対してどのように関わるかを考察します。

最初の段階ではコンテキストモデルは要件定義の出発点として、システムに関わる人との外部システムを洗い出し、要件定義チーム内での意識合わせ（このシステムにはどのような人が関わるの？）に使います。
そしてこれを出発点に他のモデルを作成していきます。

ある程度分析が進んできた段階ではコンテキストモデル本来の目的である、人と外部システムを明確化するために使用します。
そのために他のモデルを作成する中でコンテキストモデルに影響が出た場合は逐次修正することになります。

例えば業務フローを作成する中で関わるアクターが抜けていたことが発覚したり、逆に関わると思っていた人が関係なかったことが判明したりなど、徐々に明らかになる要件をもとにコンテキストモデルを洗練化します。

上記のサンプルではコンテキストモデルを開発時と運用時で二つ用意しています。
開発時のコンテキストモデルは開発体制などで合意が得られていない場合などに、このモデルを作成し意識を合わせます。
通常のコンテキストモデルは運用時コンテキストモデルです。
また、この例ではシステムの目的、役割が抜けていますが、本来は真ん中のユースケースアイコンにつながるノートとしてシステムの目的を記述します。

要求モデルは要望、要求、要件に分類して整理します。

要望はヒアリングしたときに出てきたものをそのまま要望として作成します。
それを元に粒度を調整し内容を精査して、整理したものを要求として整理します。
最後にステークホルダーが認識しておくべき事を要件として整理します。

要望は記録としてヒアリングした内容をそのまま保持するものです。逆に要求はゴール分析や分類、統合、衝突の把握など、様々なテクニックを使用して粒度を均一にし、網羅的に整理します。
そして、システム化で求められていることを明らかにし、システムの目的、役割につなげていきます。

上記サンプルの要求モデルは要望としてまとめている例です。
要求、要件を別ホルダーでまとめます。

システム価値は要件定義メンバーの意識を合わせるための出発点になり、同時にシステムの目的、役割を明らかにし以後の要件定義のブレを少なくする役割を果たします。