要求定義の双子プロセスについて

 
 
要求の作成は、アジャイルだろうと、ウォーターフォールプロセス的なシーケンシャルアプローチだろうと必要だ。要求開発をソフトウェア開発と並列して進行する別のプロセスとして管理することを提案している。
ワインバーグは、どのような製品であったり、組織として採用しているプロセスがどうあれ、
  • 製品の使用者からのフィードバック
  • 開発者からのフィードバック
  • ビジネス目標の変化
などが恒常的に発生しているという観察した。
 
そのため、プロダクト開発のプロセスとは「別」に要求開発のプロセスも管理しようというのがワインバーグの双子プロセスの提案である。（正確にはParnasとClementsの記事に基づく。下記の図は『ワインバーグのシステム変革法』 図15-5からの図を少し改変したもの。）



たとえば、Scrumなどでは要求はPOが定義し、開発者に提示することになっているが、開発者に説明できる要求をPOが手にするまでには複雑なプロセスが必要だ。それには、多くの場合、政治的な交渉も含まれる。
 
 
要求開発プロセスを別のプロセスとして定義することは、ブラックボックスとなっていいるプロセスを明確なものにし、政治力などによって左右されるのではなく、要求開発のプロセス改善を可能にする、という意味がある。政治力というのは、ビジネスサイドのことばかりではなく、自分の判断で要求を取り込む開発者もある面では政治力がある。ようは、ソフトウェア開発プロセスに対する影響力を持つ人が要件を決めてしまうということになる。
 
 
詳細な要求開発のプロセスは例えば、次のようなものだ。（『ワインバーグのシステム変革法』 図16-5からの図を少し改変したもの。）
 

 
要求開発には開発者もステークホルダーとして参画する。主に開発することで得た知見をもとにした要求アイデアの提示、一部の開発者は要求定義のレビューにも参画する必要があるだろう。シーケンシャルプロセスで同一リリースに要求が追加されるのなら、変更管理となる。
 
アジャイルプロセスにおいては分類、高次設計、優先度設計などはソフトウェア開発プロセスに含めてもいいだろう。Scrumなどのソフトウェア開発プロセスの中で仕様化するプロダクトバックログリファインメントで行うから。
 
要求開発のプロセスそのものを管理し、様々な情報を基に最終的な意思決定を行うのは、ワインバーグはマネージャーだといっている。おそらく、プロダクトの真のオーナーであるプロダクトマネージャーだと思う。彼らはプロダクトに対する最終的な意思決定を行い、おそらく、その結果とプロセスについて、ステークホルダーに対して説明責任を持つ。日本の組織の場合はこのロールが不在のため、うまくいかないことが多いように思う。
 
現在では、どういうプロセスモデルでソフトウェアを開発するにせよ、プロジェクトが継続的に立ち上がるってことは避けられないように思う。こうした要求開発プロセスを切り出すことができ、そしてプロセス改善を行うことがおそらく、アジャイル開発にするか、、柔軟なウォーターフォールにするか、という選択よりも意味のあるものなのではないかと感じている。