第35回勉強会(2013/01/18) & 新潟開発者新年会(NDS) - 長岡 IT開発者 勉強会(NDS) http://nagaoka.techtalk.jp/no35 の発表資料

1. 設計 ≒デザイン）
（
の
話をしよう
2014/1/18 - #nds35
TAKANO Sho
（高野 将）/ @masaru_b_cl

2. 自己紹介
某SIerで働くDeveloper
そのかたわら執筆業も
#nds35
2

3. 大前提
設計 ≒ デザイン
#nds35
3

4. 今日お話すること
これまでの私の経験から
設計 ≒デザイン）
（
について
当たり前の話をします
#nds35
4

5. 注意事項
本セッションの内容は
個人の見解であり所属する組織の
公式見解ではありません
#nds35
5

6. Agenda
設計 ≒デザイン）
（
とは何か
設計の進め方
設計の重要ポイント
設計する上での課題
#nds35
6

7. 設計 ≒デザイン）
（
とは何か
#nds35
7

8. 設計 ≒デザイン）
（
とは何か
設計 ≒デザイン）
（
とは
ソリューション
である
#nds35
8

9. ソリューション
（問題解決）
何らかの問題があり、
その問題を
解決することを目的として行う
何を、
どのように、
どうやって
解決するか、
決定する行為
#nds35
9

10. ソリューション
（問題解決）
の例
GUIアーキテクチャ
問題
アプリケーションの処理が
UIのコードに散在している
何を
どのように
#nds35
どうやって
10

11. ソリューション
（問題解決）
の例
GUIアーキテクチャ
問題
アプリケーションの処理が
UIのコードに散在している
UIと処理の
別々に変更
コードを
できるように
#nds35
分離する
11

12. ソリューション
（問題解決）
の例
ポスタープレゼン
問題
ポスターで伝えたいことが
うまく伝わらない
何を
どのように
#nds35
どうやって
12

13. ソリューション
（問題解決）
の例
ポスタープレゼン
問題
ポスターで伝えたいことが
うまく伝わらない
伝えたいこと
の要点を
目立つように
#nds35
色 大きさを
・
変更する
13

14. 設計の進め方
#nds35
14

15. 設計の進め方
1. 目的の明確化
2. ゴールの設定
3. 対応手段の決定
a. 仮説
b. 実践
c. 評価
繰り返し
d. 改善
#nds35
15

16. 1. 目的の明確化
まず何が問題であるか考える
問題の付随情報を明確にする
原因 / 前提条件 / 利害関係者 / etc...
見出した問題の解決を目的とする
#nds35
16

17. 2. ゴールの設定
目的を実現するために必要な、
具体的な条件を考える
その条件を満たすことで発生する、
新たな問題がないか検討する
新たな問題を解決する条件も同様に考える
条件を満たすことをゴールとして設定する
#nds35
17

18. 3. 対応手順の決定
ゴール達成のために必要な対応方法を考える
a.
仮説
ゴール達成に何をどうすればよいか考える
b.
実践
仮説に基づき実践してみる
c.
評価
仮説が正しかったか検証する
d.
改善
仮説が間違っていれば新たな仮説を立て、
１に戻る
小さく繰り返すことで洗練させていく
#nds35
18

19. 設計の重要ポイント
#nds35
19

20. 一貫性
設計には一貫性が必要
一貫性を意識することで、設計に一本芯が通る
“一貫性は使いやすさをもたらし、
それが好ましい感じをもたらし、
結果としてあなたはより多くの収入が得られる”
プログラマのためのユーザインタフェースデザイン
第5章: 一貫性とそのほかのゴブリンについて – Joel on Software
#nds35
20

21. トレードオフ
設計にはトレードオフがつきもの
例えばCAP定理
一貫性 / 可用性 / 分断耐性
目的、価値観、利害関係者など、
あらゆる条件をもとにバランスをとる
#nds35
21

22. アフォーダンス
良い設計はその対象ができることを
アフォードする
対象が期待するようにユーザーを誘導する
ユーザーは人とは限らない
例えばピタゴラ装置
#nds35
22

23. スキルである
スキルが蓄積することでセンスが磨かれる
良い/悪い設計のにおいを感じる、等
スキルなので誰でも習得可能
ただし向き/不向きはおそらくある
まずは先達に学ぶ
パターンやガイドラインを使ってみる
#nds35
23

24. 設計する上での課題
#nds35
24

25. Q. どこから設計する？
A. フィードバックを得やすいところから
設計は一足飛びにはできない
フィードバックを繰り返し、
徐々に洗練させていく
フィードバックは早ければ早いほど良い
#nds35
25

26. Q. どこまで設計する？
A. ゴールを達成するまで
設計には正解はない
各種リソースには限りがある
問題はゴールの達成で解決される
#nds35
26

27. Q. ゴール設定はどうやる？
A. 思考ツールを活用する
TOC思考プロセス
 5つのツリー
現状問題構造ツリー / 対立解消図 / 未来問題構造ツリー /
前提条件ツリー / 移行ツリー
GTDナチュラルプランニングモデル
 5つを順に考える
目的・価値観 / 望むべき結果 / ブレインストーミング /
整理・準備 / 次にとるべき行動
#nds35
27

28. Q. 意識の外の問題はどうする？
A. あらゆる手を尽くして見出し、未然に防ぐ
一人だけではなく複数人でやる
様々な方法を使い確度を高める
レビュー
ブレインストーミング
ペアデザイン
デシジョンテーブル
一晩置く
類似ケースの分析、etc…
#nds35
28

29. Q. 完全には防げないよね？
A. 問題発生時の影響が少ない設計を目指す
それでも意識しない問題は発生する
発生しても大丈夫な余裕を持たせる
局所化して影響範囲を小さくする
安全側に動作するようにする
#nds35
29

30. まとめ
#nds35
30

31. まとめ
設計 ≒ デザイン
#nds35
31

32. まとめ
設計 ≒デザイン）
（
とは
ソリューション
である
#nds35
32

33. まとめ
問題の解決を目的とする
何を、
どのように、
どうやってするか決定する
目的の実現に必要なゴールを設定し、
フィードバックを得ながら改善していく
一足飛びではなく小さいステップで
#nds35
33

34. まとめ
設計には一貫性が必要
設計に芯を通す
設計にはトレードオフがつきもの
あらゆる条件をもとにバランスをとる
アフォーダンスを考える
ユーザーを誘導する
#nds35
34

35. まとめ
設計はセンスではなくスキル
スキル向上にはまず先達に学ぶ
パターンやガイドラインを使ってみる
スキル向上がセンスを磨く
#nds35
35

36. 設計 ≒デザイン）
（
の
話をしよう
2014/1/18 - #nds35
TAKANO Sho
（高野 将）/ @masaru_b_cl
ご清聴ありがとうございました!

37. Ask me any questions!
マサカリ歓迎
#nds35
37

38. 参考資料
各ドメインにおける設計
インストラクショナルデザイン
伝わるデザイン｜研究発表のユニバーサルデザイン
ソフトウェア設計とは何か？
データベース設計徹底指南!!
#nds35
38

39. 参考資料
TOC
ザ・ゴール
ザ・ゴール2 ― 思考プロセス
GTD
はじめてのGTD ストレスフリーの整理術
ひとつ上のGTD ストレスフリーの整理術 実践編
#nds35
39

40. 参考資料
パターン
 オブジェクト指向における再利用のためのデザインパターン
 エンタープライズアプリケーションアーキテクチャパターン（PofEAA）
 xUnit Test Patterns
ガイドライン
 アプリケーションアーキテクチャガイド 2.0
 Windows ユーザー エクスペリエンス インタラクション ガイドライン
#nds35
40

41. 参考資料
 プログラマのためのユーザインタフェースデザイン（Joel Spolsky）
 第1章 環境をコントロールできれば楽しく感じるもの
 第2章 ユーザが何を期待しているかを知る
 第3章 選択
 第4章 アフォーダンスとメタファー
 第5章 一貫性とそのほかのゴブリンについて
 第6章 もっとほかにやることがある人々のためにデザインする
 第7章 もっとほかにやることがある人々のためにデザインする、パート2
 第8章 もっとほかにやることがある人々のためにデザインする、パート3
 第9章 製品デザインプロセス
#nds35
41

42. 参考資料
すばらしいデザイン（Joel Spolsky）
イントロダクション
デザインとは何か?
何によってすばらしいものとなるのか?
#nds35
42

43. 参考資料
先達の英知
ソフトウェアアーキテクトが知るべき97のこと
プログラマが知るべき97のこと
#nds35
43