だいたい毎月1回実施している「やさしくわかるBABOK」読書会に今月も参加した。大遅刻してしまったので参加者の議論のまとめを聞く程度だったのだけど、いくつか興味深いキーワードはあった。その中から「顧客の権利」について少し書いてみようと思う。
「やさしくわかるBABOK」で紹介されている顧客の権利
今回の読書会は「第三章 引き出し」が対象である。この章で取り上げられている「顧客の権利」がなかなか良いという意見が出ていた。
- 顧客の責任：
- 要求を提供し、明確にし、繰り返して細部をつめていくために必要な時間を費やさなければならない
- システムの要求について情報を提供するときは、明確かつ正確でなければならない
- 求められた場合は、要求についてタイムリーに決断を下さなければならない
- 顧客の権利：
- 開発者にあなたがわかる言葉で話してもらえる
- 開発者にあなたの業務と目的について学んでもらえる
- 開発者は、あなたと一緒に仕事をする間、協力的かつ専門家としての姿勢を保ってくれる
K. Wiegers「ソフトウェア要求」より引用
引用モトの「ソフトウェア要求」はこちら。自分は大昔に読んだかもしれないが、あまり記憶には残っていなかった。
基本的には異論は無いのだけれども、イマドキとしては「変化」に関する条項が足りていないような印象。
他の「顧客の権利」
同じような考え方としては、個人的にはハイスミスの定義のほうが好みである。ここで「例」とされているのは、こういった参加者の権利を定義したほうが良いという文脈で紹介されているから。
＜マネジャーや顧客の権利(例)＞
- マネジャーや顧客には、全体の計画に対する権利があり、何が、いつ、どれだけのコストで完成できるのかの見積もりを知る権利がある。
- マネジャーや顧客には、動作するシステムを目にすることで、進捗を知る権利がある。そのシステムは、マネジャーや顧客が指定した再現可能なテストを通り、動くということが証明されている。
あと、アラン・M・デービスが「成功する要求仕様 失敗する要求仕様」で語っていたことも思い出される。
ステークホルダーには、考えを変える権利がある。今、重要ではない要求が、明日には不可欠な要求になるかもしれない。また、その逆もありうるのだ。柔軟に対処できるようになろう。
成功する要求仕様 失敗する要求仕様
現代的な「顧客の権利」とは何か
いろいろな定義が考えられると思うのだけれども、
- 状況を知る権利
- 方向転換や中断を行う権利
がより重視されるべきでは無いかと考えている。もちろんSIer等のビジネス上は大いに問題があるのだけれども、ビジネスの都合とソフトウェア開発プロジェクトの都合は異なる。
私自身がプロジェクトに参加している場合は、よくお客様にこんなことを言うようにしている。
「契約や費用の問題はあるものの、皆さんは常に一度決めた要求や要望を撤回したり、変更する権利があります。それがプロジェクトにどのような影響があるかは別にして、気づいたことはすぐ相談いただくことによって、よりよいソフトウェアを作るのがこのチームのゴールです。」
