はじめに
本エントリは第35回勉強会(2013/01/18) & 新潟開発者新年会(NDS) – 長岡 IT開発者 勉強会(NDS)にて発表したセッションを再構成したものです。セッションの中や後で考えた内容も反映してあります。
ライセンス
この 作品 は クリエイティブ・コモンズ 表示 – 継承 4.0 国際 ライセンスの下に提供されています。
設計（≒デザイン）の話をしよう
大前提
「デザイン」というと小奇麗な見た目のWebページなどを思い浮かべる人もいるかもしれませんが、本エントリでは本質的に設計とデザインは同じものとして扱います。設計もデザインも英語で表せばdesignになることからも、これは明らかです。
設計（≒デザイン）とは何か
設計とは何か？一言で表すのは案外難しいと思います。私もいったい何なんだろうと考えた結果、次の結果にたどり着きました。
設計（≒デザイン）とはソリューションである
ソリューションであるとはどういうことか説明しましょう。
まず、目の前に何らかの改善したい「問題」があったとします。設計とはこの問題の解決を目的として行います。目的のない設計はあり得ません。そして、目的を実現するのに「何を」、「どのように」、「どうやって」解決するかを決定する行為、これが設計です。
少し例を見てみましょう。
例としてGUIアプリケーションを考えましょう。いろいろなプラットフォームがありますが、Windowsフォームアプリケーションのように、GUIのコードに直接処理ロジックを記載できてしまうものも少なくありません。こういった構成は、仮にGUIだけ、処理ロジックだけ変更を加えたかったとしても、どこに処理があるのか分かりにくく、しかも再利用がしにくいものです。
そこで、この問題を解決するため、「何を」、「どのように」、「どうやって」対処すればよいのでしょうか。一つの例が「UIと処理のコードを」、「別々に変更できるように」、「分離する」方法です。これはPDS（Presentation Domain Separation、プレゼンテーションとドメインの分離）とも呼ばれるアプローチです。
また別の例を見てみましょう。
学生であれば、研究成果をポスターセッションで発表することがあるでしょう。こういったとき、どうもうまく伝わらないと感じているとします。この問題を解決するにはどうすればよいのでしょう？
その方法の一つが「伝えたいことの要点を」、「目立つように」、「色・大きさ（スタイル）を変更する」というものです。このスライドでも「ソリューション（問題解決）の例」、「ポスタープレゼン」などのページタイトル、見出しは本文より目立つようスタイルを変えています。
設計の進め方
設計は次の手順で行います。
- 目的の明確化
- ゴールの設定
- 対応手段の決定
「3. 対応手段の決定」はさらに次のステップを繰り返し行います。
- 仮説
- 実践
- 評価
- 改善
それぞれの手順を詳しく見ていきましょう。
1. 目的の明確化
設計はソリューションであると本エントリでは定義しました。したがって、最初に考えるべきは「何が問題であるか」です。解決したい問題を明確にした上で、その問題が発生している原因や前提条件、ステークホルダーや制約などの「問題の付随情報」も明確にします。
このように明確にしていった問題の解決を目的として、設計を進めていきます。
2. ゴールの設定
次のステップは目的を実現するために必要な「ゴール」を設定することです。ゴールは「目標」とも言い換えることができますが、「目的」と「目標」の違いで混乱しないよう、あえて「ゴール」という言葉を使います。
前のステップで目的と付随条件が明確になっています。したがって、まずは目的を実現するためには何が必要なのか、具体的な条件を考えていきます。中にはその条件を満たすことで、新たに問題が発生しそうだということがわかることもあります。こういったときは、新たな問題についても、解決に必要な条件も一緒に考えていきます。
このように考えていき、洗い出した条件を満たすことを、ゴールとして設定します。もちろん、一つの目的を実現するために複数のゴールが必要なこともあります。また、ゴールには依存関係があり、あるゴールを達成しないと、次のゴールが達成できない、ということもよくあります。
3. 対応手段の決定
ここまでのステップで、問題について何をどのようにするかが決まったので、あとは実際にどうやって対処するか考えていきます。このステップでは、仮説、実践、評価、改善を小さく繰り返して、対処方法を洗練させていきます。
仮説ではゴール達成のために何をどうすればよいか仮説を立てます。そして、仮説に基づいて実際に対応してみます。対応することで結果がわかりますので、その結果を評価し仮説が正しかったかどうか検証します。そして、検証の結果仮説が間違っていれば新たな仮説を立てたり、少し修正して、再び実践、といったように繰り返します。
したがって、前のステップで設定するゴールは「評価できる」ようにすることが大事です。例えば数値、割合などで評価したり、TDD（テスト駆動開発）のように期待する動作を先に定義しておく、などです。Webデザインのようなものは評価しにくいと感じるかもしれませんが、やろうと思えばABテストなどの手法を使うこともできます。
さて、こういった手順をすべてのゴールについて行い、全部達成されれば目的が実現する、ということになります。
なお、何を、どのように、どうやって、についてはゴール設定でも考えますし、ゴール達成の手順を検討するときにも考えます。つまり、入れ子構造やフラクタルのようになっています。
また、後のステップを考えることで前のステップについて、改善が必要なこともあるでしょう。設計という作業は、本質的にフィードバックを繰り返しながら育てていくものだということが肝心です。
設計のポイント
設計とは何か、そしてどのように進めていくかを明らかにしたところで、実際に設計を行う際に気をつけるべきポイントを、いくつか紹介します。
一貫性
設計には一貫性が必要です。一貫性を考えることで、設計に一本心が通り、ユーザー、設計者双方がメリットを享受できます。
ここで、Joel Spolskyの文章を引用してみましょう。
一貫性は使いやすさをもたらし、それが好ましい感じをもたらし、結果としてあなたはより多くの収入が得られる
プログラマのためのユーザインタフェースデザイン 第5章: 一貫性とそのほかのゴブリンについて – The Joel on Software Translation Project
では、一貫性とは具体的にどんなものかというと、そのケースによって違うため、一言では表せません。わかりやすいところでいえば、UI設計時にダイアログのOKボタンとキャンセルボタンが常に同じ位置関係であるとか、n階層のアプリケーションアーキテクチャ設計においてクライアント側から直接データベースにアクセスしないようにする、といったことも一貫性ですし、コーディング標準に沿って作成されたソースコードも一貫性を持っているといえます。ただ、勘違いしてはいけないのは、標準化を守れば一貫性が出るのではなく、一貫性を保つために存在するのが標準化だということです。
トレードオフ
一貫性とともに設計に欠かせないのがトレードオフです。設計を進めていると、互いに相反する条件を満たさないといけないことがよくあります。
トレードオフの例として、CAP定理を取り上げてみましょう。CAP定理とは分散システムの特性について一貫性、可用性、分断体制の3つすべてを高いレベルで実現することはできないとする定理です。
可用性を成立させるには単一障害点をなくさないといけないが、すると、ネットワーク分断が発生した際、システムがバラバラに分裂してしまい、単一障害点があればそこを基準に一貫した応答ができるが、単一障害点をなくしてしまうとシステムの応答の一貫性が成立できなくなるという定理。
CAP定理 – Wikipedia
こういったトレードオフに対峙するときは、前提や価値観、利害関係者などのあらゆる条件を考慮し、それぞれのバランスをとることが重要です。「バランスをとること」が設計の本質であるといっても過言ではありません。
なお、「バランスをとる」というのは非常に便利な言葉ですが、これも一貫性と同じようにその時々で基準が違うので、こういうしかないのです。
アフォーダンス
良い設計は、ユーザーをこちらが期待するとおり振る舞うように誘導します。これを「アフォードする」と言ったりもします。これは、例えばWebページのボタンがいかにも押せそうな見た目をしていたり、レバーのついたドアは、「引く」ようにアフォードしています。
なお、ユーザーは人とは限りません。その設計対象物が影響を与える「モノ」をユーザーととらえることができます。例えば、Eテレのピタゴラスイッチに出てくる「ピタゴラ装置」にとっては、パチンコ玉などの「物体の流れ」がユーザーと考えることができます。
アフォーダンスはユーザーが持つ特性によって決まるものです。人はボタンのようなものを見たら押したくなりますし、物体は重力によって地面に向かって落ちるのです。
スキルである
最後のポイントは、設計力とは「センス」ではなく「スキル」であるということです。
一般にセンスと呼ばれるものは、スキルが蓄積した結果、磨かれたものだと私は考えます。プログラマーは良く、設計の良し悪しを「におい」と表現したりしますが、これも積み重ねた経験により、一瞬にして状態の把握、検証が展開された結果なのです。
そして、スキルであるということは、誰でも習得可能であるとことです。ただ、なんでもそうですが、向き/不向きはあるとは思います。
では、習得するにはどうすればよいか。まずは先達（せんだち）に学ぶのが良いでしょう。幸い、あらゆる分野での設計については、パターンやガイドラインという形でまとめられていますので、そういった資料を基にいわゆる「守破離」の段階を踏んで精進していくのが良いと思います。
設計する上での課題
本エントリの最後に、設計を行うに当たって課題となることについて、私なりにQ&A形式でまとめてみます。
Q. どこから設計する？
A. フィードバックを得やすいところから
設計はその性質からフィードバックが欠かせません。それならフィードバックは早ければ早いほど、対応が楽になります。
フィードバックを得やすいのはどういったところか、という具体例ですが、例えば文章であれば大まかなプロット、プログラムであればプロトタイプやモックアップといったところが該当するかと思います。
Q. どこまで設計する？
A. ゴールを達成するまで
設計には「正解」はありません。許されるのであれば、いつまでも改善を行っていくことができます。
しかし、我々の世界のリソースは有限です。特に時間、お金といったものは、シビアに限度が定められていることが多いです。そのため、事前に設定したゴールを達成した段階でそのゴールに対する作業は終わりにし、次のゴールへの対処へと移るべきです。
そのうえで、後でもし時間に余裕ができれば、また再開すればよいのです。そんなことはめったにありませんが……
Q. ゴール設定はどうやる
A. 思考ツールを活用する
ゴール設定には各種思考ツールが役に立ちます。たとえばTOC（制約の理論）の思考プロセス、これは問題解決のために5つのツリーを利用するやり方で、問題に付随する情報や構造を視覚的に理解するのに役立ちます。
- 現状問題構造ツリー
- 対立解消図
- 未来問題構造ツリー
- 前提条件ツリー
- 移行ツリー
Amazon.co.jp： ザ・ゴール 2 ― 思考プロセス: エリヤフ・ゴールドラット, 三本木 亮: 本
他にもGTDのナチュラルプランニングモデルもお勧めです。目的・価値観から望むべき結果を想像し、関連する事象をブレインストーミングして洗い出したのち、整理・準備して次にとるべき行動を決める、といったプロセスで、まさにゴールの設定プロセスそのものです。
- 目的・価値観
- 望むべき結果
- ブレインストーミング
- 整理・準備
- 次にとるべき行動
Amazon.co.jp： はじめてのGTD ストレスフリーの整理術: デビッド・アレン, 田口 元: 本
Q. 意識の外の問題はどうする？
A. あらゆる手を尽くして見出し、未然に防ぐ
思考ツールを活用して設計を進めていても、自分では意識していない問題というものがどうしても出てきます。こういった問題についても、できるだけ早い段階で洗い出し、未然に防ぎたいところです。
そのためには、できれば複数人で設計することをお勧めします。これは、一人でやっているとどうしても視野が狭くなってしまうためです。
そしてその上で、考えられる様々な方法をいくつも使い、確度を高めます。
例えば、レビューやペアでの作業、どうしても一人でやるならできたものを「一晩置く」、何人か集めてブレインストーミング、デシジョンテーブルを使った条件の洗い出し、設計対象の類似ケースの分析、などがあります。
Q. 完全には防げないよね？
A. 問題発生時の影響が少ない設計を目指す
それでも、もちろん人は間違う生き物なので、完全には防げません。ではどうするかというと、予期せぬ問題が発生しても、その影響をなるべく少なくするように設計するのです。そのためにはある程度の「余裕」を持った設計にすることです。
例えば、設計対象物の各部分を独立させ、組み合わせるようにすれば問題を局所化できます。また、問題が発生しても「安全側」に動作するようにするのも有効です。これらの考えは、フェールセーフやフールプルーフなどとも呼ばれますね。
例えば、信号機は障害が発生した場合、赤信号が点灯するように設計されています。これは、赤にすることで一時停止を促し、安全に運航させるためです。
まとめ
「設計とはソリューションである」を切り口として、「設計」という行為について考えてきましたが、いかがでしたか？
本エントリはあくまで概念論として、ひたすら抽象的な話をしています。したがって、それぞれの分野で実際に設計を行おうとすれば、どうしてもわからないところが出てくるはずです。それでも、概念を知りその理想を目指すのとそうでないのとでは、結果がまったく違ってきます。
ぜひ設計、デザインするときに、一度基本から考えてみてほしいと思います。本エントリが、皆さんにとっての「設計」というものを考えるきっかけとなれば幸いです。
参考資料
設計やデザインを扱ったもの
TOC
GTD
パターン
ガイドライン
プログラマのためのユーザインタフェースデザイン（Joel Spolsky）
すばらしいデザイン（Joel Spolsky）
be free 