要件定義について

課題管理のチケット駆動開発: プログラマの思索 http://forza.cocolog-nifty.com/blog/2010/05/post-b032.html を読んで、ちょっと振り返り。

要求のとりまとめ

要求のとりまとめは、図のような感じで行った。

それぞれの四角はドメイン。
それぞれの丸は打ち合わせの場。
実際には、主管部門が「い」、「ろ」、「は」を主導しているけれど割愛。
「い」、「ろ」、「は」で集めた要求は、おそらく「い」なら「い」と「Sys」の中でしか共有していない。「い」の要求を「A」、「B」、「C」に持ち帰って、それぞれの「ろ」、「は」とも共有されていれば良いのだが、そこまではできていないはず。
「A」、「B」、「C」の要求は、「A」、「B」、「C」間で共有しているつもりだが、大部分が理解されていないと思う。
また、すべての要求は、それぞれのドメイン内でとりまとめているが、本当の担当者の要求を取り込めているかは不明。
さらに、ここでの要求は残念ながら ToBe になっていない。
「A」、「B」、「C」は、「い」、「ろ」、「は」に ToBe を示せと言うが、それができない。
まぁ、「い」、「ろ」、「は」が ToBe を出しても、「A」、「B」、「C」の AsIs を変えるには金がかかるという意見に押されてぽしゃるんだろうけれど。
とりあえず AsIs でもいいので IT システムを作り上げて、それを使わなければ仕事が回らない状況を作り出し、IT システムを ToBe の形に変えることで無理矢理業務を変えさせるというお粗末な計画（？）で進める。

要求の取捨選択

まとめた要求に優先度をつけて取捨選択。
それぞれのドメインで必須の要求は明らかになっているが、それ以外の要求は優先度付けができていない。
Sys が優先度の低いと思われる要求をえいやっと切った。結果をそれぞれのドメインのお偉いさんと協議して合意を取り付ける。お偉いさんとの協議なので、担当者レベルの優先度とは合致していないはずだけど、そのレベルで協議を行っても時間がかかりすぎるという判断のもと断行。

要件定義

要求をもとに要件定義（ほとんど仕様レベルまで落としてしまっているけれど……）。
図のような感じで要件化したものから各ドメインの人間を集めて説明。

各ドメインに持ち帰って協議の上、フィードバックしてもらう。説明からフィードバックまでは一週間。
フィードバックをもとに要件をブラッシュアップ。一度のフィードバックで、ほぼ要件を確定。
ここで要件をチケットにして、ステータス管理しようと思ったんだけれど挫折。要件案の作成だけで手一杯になってしまっし、管理は別の人間がやるようだったので、そっちに丸投げ。

ウォークスルー

「それぞれの要件はわかったけれど、業務の中で実際にシステムを使うとどうなるのかわからん。」ということなので、業務のワークフローの中でどんな作業や画面遷移になるのか説明することになるはず……。
しかしウォーターフォール開発のため、この時点で「おかしいよ」という話が出てきても、多分直せない (;_;)