ハトすけ

要件定義により以下のことを明らかにする

システムそのもの(システム)
システムとのユーザーとの接点(システム接点)
システムをとりまく環境(外部環境)
最終的に生み出されるビジネス的な価値(システム価値)

要件定義とはシステムの価値を示し、その価値を生み出すシステムの外部環境を明らかにします。そしてその外部環境とシステムとの接点を明確にし、その接点を実現するシステムを定義することです。

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 754-756). Kindle Edition.

流れは

ビジネス的な価値をきめる
外部ステークホルダーや外部リソースを含めそのビジネスにおいて関係するヒト・モノ・コトを列挙する。
それらヒト・モノ・コトにおいて、価値を実現するさいのシステムの立ち位置や、作業フローを決める。
作業フローにおいて、システムとの接点が存在する(存在しなければそのビジネス価値を達成するのにシステムはいらない)。その接点の詳細を決める。
その接点を実現するために、どのようなデータや機能が必要なのかを決める。これがシステム本体。

ハトすけ

システム価値

サービス価値、ビジネス価値においてそのシステムが担う価値。
サービス価値などは、value-proposition などビジネスツールが有効。エンジニアがここを０から考えることはないと思うが、ビジネスサイドが作ってあるものを理解し対話することで、そこからシステムが担うべき価値を考えることができる。

システム価値はその先にサービス価値、ビジネス価値を暗示している。

システムの外部環境

システムの外部環境を決めるには、2つの捉え方があります。一つは業務の一連の流れを支援する場合、もう一つは個々の作業を支援する場合です。前者は業務フローとしてシステムの外部環境を表現します。後者はツールやユーティリティなどの、個別の作業を支援するものを対象とし、システムを利用するシーンを捉えます。

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 797-800). Kindle Edition.

上記のように業務全体の一連のプロセスをサポートするものもあれば、ちょこちょこと電卓のような便利ツールを提供するものがある。

しかし、外部環境が明らかであればよいが、新規サービス開発などは明らかでない場合が多い。この場合はある程度の仮定が必要になる。ここはビジネスサイドとの相談のしどころ。ユーザーストーリーマッピングやペルソナを活用し、想定業務フローを考えないといけない。また、ここでこのドメインにおける固有の概念が出てきたりするので、ドメインモデル分析も有効。

システム境界

このシステム境界で明らかにすることは、以下の3つです。
・システムとの接点としての入出力情報
・その情報の入出力タイミング
・入出力情報とタイミングのルール化

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 852-854). Kindle Edition.

システム境界はユーザーインターフェースとシステムインターフェースに分かれ、ユーザーインターフェースはユーザーとの接点を示し、画面・帳票・ユースケースで表します。システムインターフェースは外部システムとの接点となり、イベントとして表します。

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 856-858). Kindle Edition.

つまり、人(アクター)もしくは外部サービスとそのシステムのインプット・アウトプットをどのようにするのか決める。また、同期的に瞬時に反映されることをが望まれるのか、それとも非同期的に処理されてもよいのかを決める。

アクターとのやり取りは比較的ビジネスサイドにも理解しやすいが、外部サービスとのやりとりは技術よりの言葉遣いになり、共通理解がとりにくそう。

システム

システムは機能とデータから構成される。

機能は「システム境界で洗い出されたユースケースから利用されるもの」と「外部システムからのイベントに対応するもの」の2種類に分かれます。ユースケースやイベントはこれらの機能を使って実現されます。

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 877-879). Kindle Edition.

データは、機能から必要になるものと、UIで必要になるものがある。必要なものから考えるボトムアップ・アプローチ。これだと、得てしてUIや機能は今後拡張される可能性が高いので、拡張したいときにデータが保存されていないというのになりがちな気がする。

データは、どちらかというとドメインモデルから推測するトップダウン的アプローチのほうがいいのでは？

とおもったらちゃんとそれについても書いてあった。

データ集約的なシステムではなくツールのような複雑なシステムの場合は、ソフトウェアの情報構造(ドメインモデル)を作成します。こうすることでシステムで扱う情報の構造や制御構造を表現することができます。

神崎善司. モデルベース要件定義テクニック (Japanese Edition) (Kindle Locations 888-891). Kindle Edition.

ハトすけ

ここまでの感想。シンキングハット法から

白帽子: 客観的事実
要件定義をシステムにまつわる４つの側面(システム価値、外部環境、システムの接点、システム)をきめるものと定義。

黄色帽子: 肯定的意見
要件定義というよくわからないものが4つから成り立つことを理解した。またそれぞれをモデリングするのに適したモデル図が存在するのも理解した。いままではシステムしか見てなかったが、システムの外部環境という新しい視点を手に入れた。

黒帽子: 批判的意見
根幹をシステム価値としおり、それをさも揺らがない絶対的なものみたいな扱いをしている気がする。どちらかというと、現実のサービスは逆で、一番ゆらぎやすいと思う。そのゆらぎやすいものを根幹として、これだけの量の定義をするのは単純に時間の無駄では？

緑色帽子: アイディア
RDRAは既存のオフライン業務をオンラインにするのに使えそう。

ハトすけ

４つのステージの境界をつなげるもの

４つ(システム価値、外部環境、システムの接点、システム)が決まってもそれぞれが独立していたら整合性からすると意味がない。