設計(≒デザイン)の話をしよう #nds35
DESCRIPTION
第35回勉強会(2013/01/18) & 新潟開発者新年会(NDS) - 長岡 IT開発者 勉強会(NDS) http://nagaoka.techtalk.jp/no35 の発表資料TRANSCRIPT
設計(≒デザイン)の話をしよう
2014/1/18 - #nds35
TAKANO Sho(高野 将)/ @masaru_b_cl
自己紹介
某SIerで働くDeveloper
そのかたわら執筆業も
#nds35 2
大前提
設計 ≒ デザイン
#nds35 3
今日お話すること
これまでの私の経験から
設計(≒デザイン)について
当たり前の話をします
#nds35 4
注意事項
本セッションの内容は
個人の見解であり所属する組織の
公式見解ではありません
#nds35 5
Agenda
設計(≒デザイン)とは何か
設計の進め方
設計の重要ポイント
設計する上での課題
#nds35 6
設計(≒デザイン)とは何か
#nds35 7
設計(≒デザイン)
とは
ソリューション
である
設計(≒デザイン)とは何か
#nds35 8
ソリューション(問題解決)
何らかの問題があり、その問題を
解決することを目的として行う
何を、どのように、どうやって
解決するか、決定する行為
#nds35 9
ソリューション(問題解決)の例
何を どのように どうやって
#nds35 10
アプリケーションの処理がUIのコードに散在している
GUIアーキテクチャ
問題
UIと処理の
コードを
別々に変更
できるように分離する
ソリューション(問題解決)の例
#nds35 11
アプリケーションの処理がUIのコードに散在している
GUIアーキテクチャ
問題
ソリューション(問題解決)の例
何を どのように どうやって
#nds35 12
ポスターで伝えたいことがうまく伝わらない
ポスタープレゼン
問題
伝えたいこと
の要点を目立つように
色・大きさを
変更する
ソリューション(問題解決)の例
#nds35 13
ポスターで伝えたいことがうまく伝わらない
ポスタープレゼン
問題
設計の進め方
#nds35 14
設計の進め方
1. 目的の明確化
2. ゴールの設定
3. 対応手段の決定
#nds35 15
a. 仮説
b. 実践
c. 評価
d. 改善
繰り返し
1. 目的の明確化
まず何が問題であるか考える
問題の付随情報を明確にする
原因 / 前提条件 / 利害関係者 / etc...
見出した問題の解決を目的とする
#nds35 16
2. ゴールの設定
目的を実現するために必要な、
具体的な条件を考える
その条件を満たすことで発生する、
新たな問題がないか検討する
新たな問題を解決する条件も同様に考える
条件を満たすことをゴールとして設定する
#nds35 17
ゴール達成のために必要な対応方法を考える
a. ゴール達成に何をどうすればよいか考える
b. 仮説に基づき実践してみる
c. 仮説が正しかったか検証する
d. 仮説が間違っていれば新たな仮説を立て、
1に戻る
小さく繰り返すことで洗練させていく
3. 対応手順の決定
#nds35 18
仮説
実践
評価
改善
設計の重要ポイント
#nds35 19
一貫性
設計には一貫性が必要
一貫性を意識することで、設計に一本芯が通る
“一貫性は使いやすさをもたらし、
それが好ましい感じをもたらし、
結果としてあなたはより多くの収入が得られる”
プログラマのためのユーザインタフェースデザイン
第5章: 一貫性とそのほかのゴブリンについて – Joel on Software
#nds35 20
トレードオフ
設計にはトレードオフがつきもの
例えばCAP定理
一貫性 / 可用性 / 分断耐性
目的、価値観、利害関係者など、
あらゆる条件をもとにバランスをとる
#nds35 21
アフォーダンス
良い設計はその対象ができることを
アフォードする
対象が期待するようにユーザーを誘導する
ユーザーは人とは限らない
例えばピタゴラ装置
#nds35 22
スキルである
スキルが蓄積することでセンスが磨かれる
良い/悪い設計のにおいを感じる、等
スキルなので誰でも習得可能
ただし向き/不向きはおそらくある
まずは先達に学ぶ
パターンやガイドラインを使ってみる
#nds35 23
設計する上での課題
#nds35 24
Q. どこから設計する?
A. フィードバックを得やすいところから
設計は一足飛びにはできない
フィードバックを繰り返し、
徐々に洗練させていく
フィードバックは早ければ早いほど良い
#nds35 25
Q. どこまで設計する?
A. ゴールを達成するまで
設計には正解はない
各種リソースには限りがある
問題はゴールの達成で解決される
#nds35 26
Q. ゴール設定はどうやる?
A. 思考ツールを活用する
TOC思考プロセス
5つのツリー
現状問題構造ツリー / 対立解消図 / 未来問題構造ツリー /
前提条件ツリー / 移行ツリー
GTDナチュラルプランニングモデル
5つを順に考える
目的・価値観 / 望むべき結果 / ブレインストーミング /
整理・準備 / 次にとるべき行動
#nds35 27
Q. 意識の外の問題はどうする?
A. あらゆる手を尽くして見出し、未然に防ぐ
一人だけではなく複数人でやる
様々な方法を使い確度を高める
#nds35 28
ブレインストーミング
デシジョンテーブル
類似ケースの分析、etc…
レビュー
ペアデザイン
一晩置く
Q. 完全には防げないよね?
A. 問題発生時の影響が少ない設計を目指す
それでも意識しない問題は発生する
発生しても大丈夫な余裕を持たせる
局所化して影響範囲を小さくする
安全側に動作するようにする
#nds35 29
まとめ
#nds35 30
まとめ
設計 ≒ デザイン
#nds35 31
設計(≒デザイン)
とは
ソリューション
である
まとめ
#nds35 32
まとめ
問題の解決を目的とする
何を、どのように、どうやってするか決定する
目的の実現に必要なゴールを設定し、
フィードバックを得ながら改善していく
一足飛びではなく小さいステップで
#nds35 33
まとめ
設計には一貫性が必要
設計に芯を通す
設計にはトレードオフがつきもの
あらゆる条件をもとにバランスをとる
アフォーダンスを考える
ユーザーを誘導する
#nds35 34
まとめ
設計はセンスではなくスキル
スキル向上にはまず先達に学ぶ
パターンやガイドラインを使ってみる
スキル向上がセンスを磨く
#nds35 35
設計(≒デザイン)の話をしよう
2014/1/18 - #nds35
TAKANO Sho(高野 将)/ @masaru_b_cl
ご清聴ありがとうございました!
Ask me any questions!
マサカリ歓迎
#nds35 37
参考資料
各ドメインにおける設計
インストラクショナルデザイン
伝わるデザイン|研究発表のユニバーサルデザイン
ソフトウェア設計とは何か?
データベース設計徹底指南!!
#nds35 38
参考資料
TOC
ザ・ゴール
ザ・ゴール2 ― 思考プロセス
GTD
はじめてのGTD ストレスフリーの整理術
ひとつ上のGTD ストレスフリーの整理術 実践編
#nds35 39
参考資料
パターン
オブジェクト指向における再利用のためのデザインパターン
エンタープライズアプリケーションアーキテクチャパターン(PofEAA)
xUnit Test Patterns
ガイドライン
アプリケーションアーキテクチャガイド 2.0
Windows ユーザー エクスペリエンス インタラクション ガイドライン
#nds35 40
参考資料
プログラマのためのユーザインタフェースデザイン(Joel Spolsky)
第1章 環境をコントロールできれば楽しく感じるもの
第2章 ユーザが何を期待しているかを知る
第3章 選択
第4章 アフォーダンスとメタファー
第5章 一貫性とそのほかのゴブリンについて
第6章 もっとほかにやることがある人々のためにデザインする
第7章 もっとほかにやることがある人々のためにデザインする、パート2
第8章 もっとほかにやることがある人々のためにデザインする、パート3
第9章 製品デザインプロセス #nds35 41
参考資料
すばらしいデザイン(Joel Spolsky)
イントロダクション
デザインとは何か?
何によってすばらしいものとなるのか?
#nds35 42
参考資料
先達の英知
ソフトウェアアーキテクトが知るべき97のこと
プログラマが知るべき97のこと
#nds35 43