Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

2009年9月11日「FoW!勉強会〜要求とか要件について一度みんなで語り合おう」での発表資料です。

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

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

  1. 1. 要件定義のデストロイヤー 鈴木雄介 グロースエクスパートナーズ(株) JJUG/JSUG http://www.arclamp.jp/ FOW!勉強会〜要求とか要件につ いて一度みんなで語り合おう
  2. 2. 要件定義すれば要 求が理解できる なんてことはない
  3. 3. システムの出来るまで  要求からITサービスまでの変換をしてい く作業 ←ここが要件定義 要求 要件 設計書 プログラム ITS  良いITサービスは、良い要件から
  4. 4. たしかに要件定義 は重要だね
  5. 5. では、誰から要求 を聞けば正しい要 件定義ができる の?
  6. 6. http://www.flickr.com/photos/ivanomak/407372214/ 社長?
  7. 7. 社長だけが満足し てもダメ。多数の 利害関係者がいる
  8. 8. http://www.flickr.com/photos/chrys/3333486097/ 全ての社内ユーザーに聞く?
  9. 9. 利用者の少ないシ ステムならともか く、基本的には無 理
  10. 10. http://www.flickr.com/photos/infiltrators/3563197464/ 情報システム担当者?
  11. 11. 本当に彼らはユー ザーの代表?
  12. 12. http://www.flickr.com/photos/photographi_esc_/3096006749/ “ユーザーの代表者”は正しい? 僕が決めるよ。 (良く分かんないけど) http://ja.wikipedia.org/wiki/ディルバート
  13. 13. http://www.flickr.com/photos/--stromberg--/3411903994/ 実は情シスも悩んでいる みんなの役に立つシステム を作りたい でも、一生懸命考えても 「使えない」とか言われる どうしても現場のことは 分からないことがある
  14. 14. やっぱユーザー に聞こうよ。代 表者だけでも
  15. 15. http://www.flickr.com/photos/matthewfield/2306001896/ 公開サイトなら誰が代表者?
  16. 16. やっぱり要求を 聞きだす正しい 相手なんていな い
  17. 17. てか、そもそも 聞いて分かるこ となの?
  18. 18.  ユーザーは合理的ではない  ユーザーはイノベーションのジレンマの中に いる  ユーザーは知らない機能は評価できない  ユーザーの予測が当たるわけではない  ユーザーの自分のことを正しく説明できるわ けではない  結論:ユーザーに聞いても正しい要求を言う わけではない
  19. 19. ここまでのまとめ  要求はITサービスの原点  ところが  顧客内にも様々なステークホルダーがいる  社長、営業、製造、顧客担当、広報  ユーザー代表に聞いても正しいとは限らない  情報システム部門はユーザーではない  ユーザー全員に聞くのは不可能  間接ユーザーを含めれば、ユーザーは社外に拡がっ ている  ていうか、聞いたところで正しい要求とは限 らない
  20. 20. 要件定義すれば要 求が理解できる なんてことはない
  21. 21. では、どうする のか?
  22. 22. 聞いてもダメな ら観ればいい (正解ということではなくて、参考として)
  23. 23. 人間中心設計  ISO13407 "Human-centred design processes for interactive systems"(イ ンタラクティブシステムの人間中心設計 プロセス)  1.人間中心設計の必要性の特定  2.利用の状況の把握と明示  3.ユーザーと組織の要求事項の明示  4.設計による解決案の作成  5.要求事項に対する設計の評価
  24. 24. 人間中心設計(Human Centered Design=HCD)で使う主な手法:DESIGN IT! w/LOVE http://gitanez.seesaa.net/article/49500823.html 人間中心設計
  25. 25. 人間中心設計  ポイント  ユーザーの声を聞くのではなく行動を観察することで、 利用時のコンテキストとともにユーザーの利用行動を 把握し、その背後にある潜在的なニーズを発見するこ と  あくまで人間中心ですので、改善あるいは新たにつく りだすべき最終形は人間の経験そのものです。ですの で、モノをデザインするのではなく仕事をデザインす るという意識が必要です  プロトタイプをいくつもつくり、ユーザーテストを繰 り返し、ゴールにむかって「つくりながら考える」反 復的な改善をベースにすること  「モノを通してヒトを見る」アプローチとは逆 の「ヒトを通してモノを見る」 人間中心設計(Human Centered Design=HCD)で使う主な手法:DESIGN IT! w/LOVE http://gitanez.seesaa.net/article/49500823.html
  26. 26. エスノグラフィ  「エスノグラフィー」(ethnography、 民族誌学)  「人類学者が、人間の社会と文化を研究 する上で用いる質的調査法のひとつの形 態」(『質的調査法入門』S・Bメリア ム著)から転じたリサーチ手法  ユーザーの普段の利用環境でともに過ご し暮らすことで徹底的な観察を行う  フォーカスグループ/グルインとは違う  エクストリームなユーザー
  27. 27. ここまでのまとめ  聞いてもダメなら、観ればいい  デザイン分野では手法が確立している  人間中心設計、ユーザー中心設計、エスノグラ フィなど  モノ中心から人間中心へ  人間に関する研究を応用している。認知工学、 人間工学、社会工学  決定者は専門家。ユーザーから気づきを得る  ユーザー設計ではない
  28. 28. システムの出来るまで  ユーザー観察からITサービスのあるべき 姿を見つけていく 潜在 要求 ここがリサーチ→ 要件 設計書 プログラム ITS ここが分析評価→  良いITサービスは、良いリサーチと分析 評価の繰り返しから
  29. 29. それって、なん てアジャイル
  30. 30. アジャイルとの関係性  参加型デザイン(participatory design)  スカンジナビア70年代前後から行われ始めたモノ  ソフトウェア開発の設計段階に従業員代表として 労働組合員が参加する  AgileやXPと関連づける論文がたくさんあります  のちの住民参加型まちづくりである  そうなるとアレグザンダーの系譜ともいえる  ユーザー中心が掲げるユーザー参加や反復型 改善の考え方はアジャイルと親和性が高い
  31. 31. 最後に 1/2  要件定義の手法は大事だけど、要求を聞 くだけで満足してはいけない  要求どおりQCDを満たしても、使われないシ ステムはクズ  ユーザーに価値のあるシステムを提供す るためにはユーザーのこと、人間のこと を知らなくてはいけない  システムは(広義の)ユーザーインター フェースでしか評価されない
  32. 32. 最後に 2/2  僕らは驚くほどユーザーの利用状況を知らな い  ユーザーがシステムを使っている場面を見たこと がありますか?  アジャイルとユーザー中心手法の組み合わせ は今後トライすべき領域  ユーザーの生産性を上げるのが僕らの仕事だろ?  良いデザインがあったうえで製造工程の効率化を すればいい
  33. 33. システムのための 要件定義から、 ユーザーのための 要件定義へ

×