要件定義すれば要求が理解できる、なんてことはない

FOW!勉強会〜要求とか要件について一度みんなで語り合おう

要件定義のデストロイヤー

鈴木雄介グロースエクスパートナーズ(株)JJUG/JSUGhttp://www.arclamp.jp/

要件定義すれば要求が理解できるなんてことはない

要求からITサービスまでの変換をしていく作業

良いITサービスは、良い要件から

システムの出来るまで

要求 要件 設計書 プログラムITS

←ここが要件定義

たしかに要件定義は重要だね

では、誰から要求を聞けば正しい要件定義ができるの？

社長？

http://www.flickr.com/photos/ivanomak/407372214/

社長だけが満足してもダメ。多数の利害関係者がいる

全ての社内ユーザーに聞く？

http://www.flickr.com/photos/chrys/3333486097/

利用者の少ないシステムならともかく、基本的には無理

情報システム担当者？

http://www.flickr.com/photos/infiltrators/3563197464/

本当に彼らはユーザーの代表？

“ユーザーの代表者”は正しい？

僕が決めるよ。（良く分かんないけど）

http://www.flickr.com/photos/photographi_esc_/3096006749/

http://ja.wikipedia.org/wiki/ディルバート

実は情シスも悩んでいる

みんなの役に立つシステムを作りたい

でも、一生懸命考えても「使えない」とか言われる

http://www.flickr.com/photos/--stromberg--/3411903994/

どうしても現場のことは分からないことがある

やっぱユーザーに聞こうよ。代表者だけでも

公開サイトなら誰が代表者？

http://www.flickr.com/photos/matthewfield/2306001896/

やっぱり要求を聞きだす正しい相手なんていない

てか、そもそも聞いて分かることなの？

ユーザーは合理的ではない

ユーザーはイノベーションのジレンマの中にいる

ユーザーは知らない機能は評価できない

ユーザーの予測が当たるわけではない

ユーザーの自分のことを正しく説明できるわけではない

結論：ユーザーに聞いても正しい要求を言うわけではない

ここまでのまとめ

要求はITサービスの原点

ところが 顧客内にも様々なステークホルダーがいる 社長、営業、製造、顧客担当、広報

ユーザー代表に聞いても正しいとは限らない 情報システム部門はユーザーではない

ユーザー全員に聞くのは不可能 間接ユーザーを含めれば、ユーザーは社外に拡がっている

ていうか、聞いたところで正しい要求とは限らない

要件定義すれば要求が理解できるなんてことはない

では、どうするのか？

聞いてもダメなら観ればいい（正解ということではなくて、参考として）

人間中心設計

ISO13407 "Human-centred design processes for interactive systems"（インタラクティブシステムの人間中心設計プロセス）

1.人間中心設計の必要性の特定

2.利用の状況の把握と明示

3.ユーザーと組織の要求事項の明示

4.設計による解決案の作成

5.要求事項に対する設計の評価

人間中心設計

人間中心設計（Human Centered Design＝HCD）で使う主な手法：DESIGN IT! w/LOVEhttp://gitanez.seesaa.net/article/49500823.html

人間中心設計

ポイント ユーザーの声を聞くのではなく行動を観察することで、利用時のコンテキストとともにユーザーの利用行動を把握し、その背後にある潜在的なニーズを発見すること

あくまで人間中心ですので、改善あるいは新たにつくりだすべき最終形は人間の経験そのものです。ですので、モノをデザインするのではなく仕事をデザインするという意識が必要です

プロトタイプをいくつもつくり、ユーザーテストを繰り返し、ゴールにむかって「つくりながら考える」反復的な改善をベースにすること

「モノを通してヒトを見る」アプローチとは逆の「ヒトを通してモノを見る」

人間中心設計（Human Centered Design＝HCD）で使う主な手法：DESIGN IT! w/LOVEhttp://gitanez.seesaa.net/article/49500823.html

エスノグラフィ

「エスノグラフィー」（ethnography、民族誌学）

「人類学者が、人間の社会と文化を研究する上で用いる質的調査法のひとつの形態」（『質的調査法入門』Ｓ・Ｂメリアム著）から転じたリサーチ手法

ユーザーの普段の利用環境でともに過ごし暮らすことで徹底的な観察を行う フォーカスグループ/グルインとは違う

エクストリームなユーザー

ここまでのまとめ

聞いてもダメなら、観ればいい

デザイン分野では手法が確立している

人間中心設計、ユーザー中心設計、エスノグラフィなど

モノ中心から人間中心へ

人間に関する研究を応用している。認知工学、人間工学、社会工学

決定者は専門家。ユーザーから気づきを得る

ユーザー設計ではない

ユーザー観察からITサービスのあるべき姿を見つけていく

良いITサービスは、良いリサーチと分析評価の繰り返しから

システムの出来るまで

要件 設計書 プログラムITS

ここがリサーチ→

潜在要求

ここが分析評価→

それって、なんてアジャイル

アジャイルとの関係性

参加型デザイン(participatory design)

スカンジナビア70年代前後から行われ始めたモノ

ソフトウェア開発の設計段階に従業員代表として労働組合員が参加する

AgileやXPと関連づける論文がたくさんあります

のちの住民参加型まちづくりである

そうなるとアレグザンダーの系譜ともいえる

ユーザー中心が掲げるユーザー参加や反復型改善の考え方はアジャイルと親和性が高い

最後に 1/2

要件定義の手法は大事だけど、要求を聞くだけで満足してはいけない 要求どおりQCDを満たしても、使われないシステムはクズ

ユーザーに価値のあるシステムを提供するためにはユーザーのこと、人間のことを知らなくてはいけない システムは（広義の）ユーザーインターフェースでしか評価されない

最後に 2/2

僕らは驚くほどユーザーの利用状況を知らない

ユーザーがシステムを使っている場面を見たことがありますか？

アジャイルとユーザー中心手法の組み合わせは今後トライすべき領域

ユーザーの生産性を上げるのが僕らの仕事だろ？

良いデザインがあったうえで製造工程の効率化をすればいい

システムのための要件定義から、ユーザーのための要件定義へ