要件定義のデストロイヤー
鈴木雄介
グロースエクスパートナーズ(株)
JJUG/JSUG
http://www.arclamp.jp/



FOW!勉強会〜要求とか要件につ
いて一度みんなで語り合おう
要件定義すれば要
求が理解できる
なんてことはない
システムの出来るまで

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

        ←ここが要件定義


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




 良いITサービスは、良い要件から
たしかに要件定義
は重要だね
では、誰から要求
を聞けば正しい要
件定義ができる
の?
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/LOVE
     http://gitanez.seesaa.net/article/49500823.html




人間中心設計
人間中心設計

 ポイント
  ユーザーの声を聞くのではなく行動を観察することで、
   利用時のコンテキストとともにユーザーの利用行動を
   把握し、その背後にある潜在的なニーズを発見するこ
   と
  あくまで人間中心ですので、改善あるいは新たにつく
   りだすべき最終形は人間の経験そのものです。ですの
   で、モノをデザインするのではなく仕事をデザインす
   るという意識が必要です
  プロトタイプをいくつもつくり、ユーザーテストを繰
   り返し、ゴールにむかって「つくりながら考える」反
   復的な改善をベースにすること
 「モノを通してヒトを見る」アプローチとは逆
 の「ヒトを通してモノを見る」

         人間中心設計(Human Centered Design=HCD)で使う主な手法:DESIGN IT! w/LOVE
         http://gitanez.seesaa.net/article/49500823.html
エスノグラフィ

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

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

 ユーザー観察からITサービスのあるべき
 姿を見つけていく                潜在
                         要求
             ここがリサーチ→


要件   設計書   プログラム
                   ITS


             ここが分析評価→

 良いITサービスは、良いリサーチと分析
 評価の繰り返しから
それって、なん
てアジャイル
アジャイルとの関係性

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

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

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

 僕らは驚くほどユーザーの利用状況を知らな
  い
  ユーザーがシステムを使っている場面を見たこと
  がありますか?


 アジャイルとユーザー中心手法の組み合わせ
  は今後トライすべき領域
  ユーザーの生産性を上げるのが僕らの仕事だろ?
  良いデザインがあったうえで製造工程の効率化を
  すればいい
システムのための
要件定義から、
ユーザーのための
要件定義へ

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