1.
要件定義のデストロイヤー
鈴木雄介
グロースエクスパートナーズ(株)
JJUG/JSUG
http://www.arclamp.jp/
FOW!勉強会〜要求とか要件につ
いて一度みんなで語り合おう

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

3.
システムの出来るまで
 要求からITサービスまでの変換をしてい
く作業
←ここが要件定義
要求 要件 設計書 プログラム
ITS
 良いITサービスは、良い要件から

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

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

6.
http://www.flickr.com/photos/ivanomak/407372214/
社長？

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

8.
http://www.flickr.com/photos/chrys/3333486097/
全ての社内ユーザーに聞く？

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

10.
http://www.flickr.com/photos/infiltrators/3563197464/
情報システム担当者？

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

12.
http://www.flickr.com/photos/photographi_esc_/3096006749/
“ユーザーの代表者”は正しい？
僕が決めるよ。
（良く分かんないけど）
http://ja.wikipedia.org/wiki/ディルバート

13.
http://www.flickr.com/photos/--stromberg--/3411903994/
実は情シスも悩んでいる
みんなの役に立つシステム
を作りたい
でも、一生懸命考えても
「使えない」とか言われる どうしても現場のことは
分からないことがある

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

15.
http://www.flickr.com/photos/matthewfield/2306001896/
公開サイトなら誰が代表者？

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

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

18.
 ユーザーは合理的ではない
 ユーザーはイノベーションのジレンマの中に
いる
 ユーザーは知らない機能は評価できない
 ユーザーの予測が当たるわけではない
 ユーザーの自分のことを正しく説明できるわ
けではない
 結論：ユーザーに聞いても正しい要求を言う
わけではない

19.
ここまでのまとめ
 要求はITサービスの原点
 ところが
 顧客内にも様々なステークホルダーがいる
 社長、営業、製造、顧客担当、広報
 ユーザー代表に聞いても正しいとは限らない
 情報システム部門はユーザーではない
 ユーザー全員に聞くのは不可能
 間接ユーザーを含めれば、ユーザーは社外に拡がっ
ている
 ていうか、聞いたところで正しい要求とは限
らない

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

21.
では、どうする
のか？

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

23.
人間中心設計
 ISO13407 "Human-centred design
processes for interactive systems"（イ
ンタラクティブシステムの人間中心設計
プロセス）
 1.人間中心設計の必要性の特定
 2.利用の状況の把握と明示
 3.ユーザーと組織の要求事項の明示
 4.設計による解決案の作成
 5.要求事項に対する設計の評価

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

25.
人間中心設計
 ポイント
 ユーザーの声を聞くのではなく行動を観察することで、
利用時のコンテキストとともにユーザーの利用行動を
把握し、その背後にある潜在的なニーズを発見するこ
と
 あくまで人間中心ですので、改善あるいは新たにつく
りだすべき最終形は人間の経験そのものです。ですの
で、モノをデザインするのではなく仕事をデザインす
るという意識が必要です
 プロトタイプをいくつもつくり、ユーザーテストを繰
り返し、ゴールにむかって「つくりながら考える」反
復的な改善をベースにすること
 「モノを通してヒトを見る」アプローチとは逆
の「ヒトを通してモノを見る」
人間中心設計（Human Centered Design＝HCD）で使う主な手法：DESIGN IT! w/LOVE
http://gitanez.seesaa.net/article/49500823.html

26.
エスノグラフィ
 「エスノグラフィー」（ethnography、
民族誌学）
 「人類学者が、人間の社会と文化を研究
する上で用いる質的調査法のひとつの形
態」（『質的調査法入門』Ｓ・Ｂメリア
ム著）から転じたリサーチ手法
 ユーザーの普段の利用環境でともに過ご
し暮らすことで徹底的な観察を行う
 フォーカスグループ/グルインとは違う
 エクストリームなユーザー

27.
ここまでのまとめ
 聞いてもダメなら、観ればいい
 デザイン分野では手法が確立している
 人間中心設計、ユーザー中心設計、エスノグラ
フィなど
 モノ中心から人間中心へ
 人間に関する研究を応用している。認知工学、
人間工学、社会工学
 決定者は専門家。ユーザーから気づきを得る
 ユーザー設計ではない

28.
システムの出来るまで
 ユーザー観察からITサービスのあるべき
姿を見つけていく 潜在
要求
ここがリサーチ→
要件 設計書 プログラム
ITS
ここが分析評価→
 良いITサービスは、良いリサーチと分析
評価の繰り返しから

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

30.
アジャイルとの関係性
 参加型デザイン(participatory design)
 スカンジナビア70年代前後から行われ始めたモノ
 ソフトウェア開発の設計段階に従業員代表として
労働組合員が参加する
 AgileやXPと関連づける論文がたくさんあります
 のちの住民参加型まちづくりである
 そうなるとアレグザンダーの系譜ともいえる
 ユーザー中心が掲げるユーザー参加や反復型
改善の考え方はアジャイルと親和性が高い

31.
最後に 1/2
 要件定義の手法は大事だけど、要求を聞
くだけで満足してはいけない
 要求どおりQCDを満たしても、使われないシ
ステムはクズ
 ユーザーに価値のあるシステムを提供す
るためにはユーザーのこと、人間のこと
を知らなくてはいけない
 システムは（広義の）ユーザーインター
フェースでしか評価されない

32.
最後に 2/2
 僕らは驚くほどユーザーの利用状況を知らな
い
 ユーザーがシステムを使っている場面を見たこと
がありますか？
 アジャイルとユーザー中心手法の組み合わせ
は今後トライすべき領域
 ユーザーの生産性を上げるのが僕らの仕事だろ？
 良いデザインがあったうえで製造工程の効率化を
すればいい

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