Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

4 803 vues

Publié le

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

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

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

  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. システムのための 要件定義から、 ユーザーのための 要件定義へ

×