設計(≒デザイン)の話をしよう #nds35

43
設計(デザイン) 話をしよう 2014/1/18 - #nds35 TAKANO Sho (高野 将)/ @ masaru_b_cl

Upload: sho-takano

Post on 07-Jul-2015

1.212 views

Category:

Technology


0 download

DESCRIPTION

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

TRANSCRIPT

Page 1: 設計(≒デザイン)の話をしよう #nds35

設計(≒デザイン)の話をしよう

2014/1/18 - #nds35

TAKANO Sho(高野 将)/ @masaru_b_cl

Page 2: 設計(≒デザイン)の話をしよう #nds35

自己紹介

某SIerで働くDeveloper

そのかたわら執筆業も

#nds35 2

Page 3: 設計(≒デザイン)の話をしよう #nds35

大前提

設計 ≒ デザイン

#nds35 3

Page 4: 設計(≒デザイン)の話をしよう #nds35

今日お話すること

これまでの私の経験から

設計(≒デザイン)について

当たり前の話をします

#nds35 4

Page 5: 設計(≒デザイン)の話をしよう #nds35

注意事項

本セッションの内容は

個人の見解であり所属する組織の

公式見解ではありません

#nds35 5

Page 6: 設計(≒デザイン)の話をしよう #nds35

Agenda

設計(≒デザイン)とは何か

設計の進め方

設計の重要ポイント

設計する上での課題

#nds35 6

Page 7: 設計(≒デザイン)の話をしよう #nds35

設計(≒デザイン)とは何か

#nds35 7

Page 8: 設計(≒デザイン)の話をしよう #nds35

設計(≒デザイン)

とは

ソリューション

である

設計(≒デザイン)とは何か

#nds35 8

Page 9: 設計(≒デザイン)の話をしよう #nds35

ソリューション(問題解決)

何らかの問題があり、その問題を

解決することを目的として行う

何を、どのように、どうやって

解決するか、決定する行為

#nds35 9

Page 10: 設計(≒デザイン)の話をしよう #nds35

ソリューション(問題解決)の例

何を どのように どうやって

#nds35 10

アプリケーションの処理がUIのコードに散在している

GUIアーキテクチャ

問題

Page 11: 設計(≒デザイン)の話をしよう #nds35

UIと処理の

コードを

別々に変更

できるように分離する

ソリューション(問題解決)の例

#nds35 11

アプリケーションの処理がUIのコードに散在している

GUIアーキテクチャ

問題

Page 12: 設計(≒デザイン)の話をしよう #nds35

ソリューション(問題解決)の例

何を どのように どうやって

#nds35 12

ポスターで伝えたいことがうまく伝わらない

ポスタープレゼン

問題

Page 13: 設計(≒デザイン)の話をしよう #nds35

伝えたいこと

の要点を目立つように

色・大きさを

変更する

ソリューション(問題解決)の例

#nds35 13

ポスターで伝えたいことがうまく伝わらない

ポスタープレゼン

問題

Page 14: 設計(≒デザイン)の話をしよう #nds35

設計の進め方

#nds35 14

Page 15: 設計(≒デザイン)の話をしよう #nds35

設計の進め方

1. 目的の明確化

2. ゴールの設定

3. 対応手段の決定

#nds35 15

a. 仮説

b. 実践

c. 評価

d. 改善

繰り返し

Page 16: 設計(≒デザイン)の話をしよう #nds35

1. 目的の明確化

まず何が問題であるか考える

問題の付随情報を明確にする

原因 / 前提条件 / 利害関係者 / etc...

見出した問題の解決を目的とする

#nds35 16

Page 17: 設計(≒デザイン)の話をしよう #nds35

2. ゴールの設定

目的を実現するために必要な、

具体的な条件を考える

その条件を満たすことで発生する、

新たな問題がないか検討する

新たな問題を解決する条件も同様に考える

条件を満たすことをゴールとして設定する

#nds35 17

Page 18: 設計(≒デザイン)の話をしよう #nds35

ゴール達成のために必要な対応方法を考える

a. ゴール達成に何をどうすればよいか考える

b. 仮説に基づき実践してみる

c. 仮説が正しかったか検証する

d. 仮説が間違っていれば新たな仮説を立て、

1に戻る

小さく繰り返すことで洗練させていく

3. 対応手順の決定

#nds35 18

仮説

実践

評価

改善

Page 19: 設計(≒デザイン)の話をしよう #nds35

設計の重要ポイント

#nds35 19

Page 20: 設計(≒デザイン)の話をしよう #nds35

一貫性

設計には一貫性が必要

一貫性を意識することで、設計に一本芯が通る

“一貫性は使いやすさをもたらし、

それが好ましい感じをもたらし、

結果としてあなたはより多くの収入が得られる”

プログラマのためのユーザインタフェースデザイン

第5章: 一貫性とそのほかのゴブリンについて – Joel on Software

#nds35 20

Page 21: 設計(≒デザイン)の話をしよう #nds35

トレードオフ

設計にはトレードオフがつきもの

例えばCAP定理

一貫性 / 可用性 / 分断耐性

目的、価値観、利害関係者など、

あらゆる条件をもとにバランスをとる

#nds35 21

Page 22: 設計(≒デザイン)の話をしよう #nds35

アフォーダンス

良い設計はその対象ができることを

アフォードする

対象が期待するようにユーザーを誘導する

ユーザーは人とは限らない

例えばピタゴラ装置

#nds35 22

Page 23: 設計(≒デザイン)の話をしよう #nds35

スキルである

スキルが蓄積することでセンスが磨かれる

良い/悪い設計のにおいを感じる、等

スキルなので誰でも習得可能

ただし向き/不向きはおそらくある

まずは先達に学ぶ

パターンやガイドラインを使ってみる

#nds35 23

Page 24: 設計(≒デザイン)の話をしよう #nds35

設計する上での課題

#nds35 24

Page 25: 設計(≒デザイン)の話をしよう #nds35

Q. どこから設計する?

A. フィードバックを得やすいところから

設計は一足飛びにはできない

フィードバックを繰り返し、

徐々に洗練させていく

フィードバックは早ければ早いほど良い

#nds35 25

Page 26: 設計(≒デザイン)の話をしよう #nds35

Q. どこまで設計する?

A. ゴールを達成するまで

設計には正解はない

各種リソースには限りがある

問題はゴールの達成で解決される

#nds35 26

Page 27: 設計(≒デザイン)の話をしよう #nds35

Q. ゴール設定はどうやる?

A. 思考ツールを活用する

TOC思考プロセス

5つのツリー

現状問題構造ツリー / 対立解消図 / 未来問題構造ツリー /

前提条件ツリー / 移行ツリー

GTDナチュラルプランニングモデル

5つを順に考える

目的・価値観 / 望むべき結果 / ブレインストーミング /

整理・準備 / 次にとるべき行動

#nds35 27

Page 28: 設計(≒デザイン)の話をしよう #nds35

Q. 意識の外の問題はどうする?

A. あらゆる手を尽くして見出し、未然に防ぐ

一人だけではなく複数人でやる

様々な方法を使い確度を高める

#nds35 28

ブレインストーミング

デシジョンテーブル

類似ケースの分析、etc…

レビュー

ペアデザイン

一晩置く

Page 29: 設計(≒デザイン)の話をしよう #nds35

Q. 完全には防げないよね?

A. 問題発生時の影響が少ない設計を目指す

それでも意識しない問題は発生する

発生しても大丈夫な余裕を持たせる

局所化して影響範囲を小さくする

安全側に動作するようにする

#nds35 29

Page 30: 設計(≒デザイン)の話をしよう #nds35

まとめ

#nds35 30

Page 31: 設計(≒デザイン)の話をしよう #nds35

まとめ

設計 ≒ デザイン

#nds35 31

Page 32: 設計(≒デザイン)の話をしよう #nds35

設計(≒デザイン)

とは

ソリューション

である

まとめ

#nds35 32

Page 33: 設計(≒デザイン)の話をしよう #nds35

まとめ

問題の解決を目的とする

何を、どのように、どうやってするか決定する

目的の実現に必要なゴールを設定し、

フィードバックを得ながら改善していく

一足飛びではなく小さいステップで

#nds35 33

Page 34: 設計(≒デザイン)の話をしよう #nds35

まとめ

設計には一貫性が必要

設計に芯を通す

設計にはトレードオフがつきもの

あらゆる条件をもとにバランスをとる

アフォーダンスを考える

ユーザーを誘導する

#nds35 34

Page 35: 設計(≒デザイン)の話をしよう #nds35

まとめ

設計はセンスではなくスキル

スキル向上にはまず先達に学ぶ

パターンやガイドラインを使ってみる

スキル向上がセンスを磨く

#nds35 35

Page 36: 設計(≒デザイン)の話をしよう #nds35

設計(≒デザイン)の話をしよう

2014/1/18 - #nds35

TAKANO Sho(高野 将)/ @masaru_b_cl

ご清聴ありがとうございました!

Page 37: 設計(≒デザイン)の話をしよう #nds35

Ask me any questions!

マサカリ歓迎

#nds35 37

Page 38: 設計(≒デザイン)の話をしよう #nds35

参考資料

各ドメインにおける設計

インストラクショナルデザイン

伝わるデザイン|研究発表のユニバーサルデザイン

ソフトウェア設計とは何か?

データベース設計徹底指南!!

#nds35 38

Page 39: 設計(≒デザイン)の話をしよう #nds35

参考資料

TOC

ザ・ゴール

ザ・ゴール2 ― 思考プロセス

GTD

はじめてのGTD ストレスフリーの整理術

ひとつ上のGTD ストレスフリーの整理術 実践編

#nds35 39

Page 40: 設計(≒デザイン)の話をしよう #nds35

参考資料

パターン

オブジェクト指向における再利用のためのデザインパターン

エンタープライズアプリケーションアーキテクチャパターン(PofEAA)

xUnit Test Patterns

ガイドライン

アプリケーションアーキテクチャガイド 2.0

Windows ユーザー エクスペリエンス インタラクション ガイドライン

#nds35 40

Page 41: 設計(≒デザイン)の話をしよう #nds35

参考資料

プログラマのためのユーザインタフェースデザイン(Joel Spolsky)

第1章 環境をコントロールできれば楽しく感じるもの

第2章 ユーザが何を期待しているかを知る

第3章 選択

第4章 アフォーダンスとメタファー

第5章 一貫性とそのほかのゴブリンについて

第6章 もっとほかにやることがある人々のためにデザインする

第7章 もっとほかにやることがある人々のためにデザインする、パート2

第8章 もっとほかにやることがある人々のためにデザインする、パート3

第9章 製品デザインプロセス #nds35 41

Page 43: 設計(≒デザイン)の話をしよう #nds35

参考資料

先達の英知

ソフトウェアアーキテクトが知るべき97のこと

プログラマが知るべき97のこと

#nds35 43