『シナリオに基づく設計』
John M. Carroll 著、郷 健太郎 訳『シナリオに基づく設計 -ソフトウェア開発プロジェクト成功の秘訣-』, 共立出版（2003）
この本について：
システム情報科学における「デザイン」を考える際にこれは外せないのではないかと言われている一冊。
読んだきっかけ：
この本における「シナリオ」という用語の意味するところと使われ方について知りたかったから。（私の言いたい「世界観」とどのような位置づけの違いがあるのかなど。）
→→→ 読んだきっかけに対する回答：
サイズ感的として、私の表現したい「世界観」＞「シナリオ」である（世界観よりシナリオのほうがより具体的）。「シナリオ」は開発（アイデアを収束させる／現実に落とし込む／実装可能にする／迷ったときの道標にする）のために用いられるものである。
この本が主張していること：
コンピュータがうまく機能しないのは、それがうまくデザインされていないからである。これは、単に良いアイデアが欠けているせいではなく、開発の過程で混乱しているさなかに突然出される悪いアイデアが、良いアイデアを台無しにするからである。または、良いアイデアの寄せ集めにしても、統率が取れていないせいで全体として悪いアイデアに仕上がってしまうからである。これらを防ぐのに「シナリオ」の使用が有効である。開発において設計プロセス、チームワーク、開発手段などに様々な問題があったとしても、「シナリオ」をうまく利用すれば回避できる。誰にでも使用可能な設計手法としての「シナリオ」について述べている。
方法：
大学の工学教育に用いるための、とある学習管理システム（LMS: Learning Management System）の開発における失敗事例を分析することで、プロジェクト成功の秘訣を述べる。
「シナリオ」とは：
使用状況（situations of use）に関する具体的な物語である。
例えば、「ある人がコンピュータの電源を入れた。そのスクリーンにはスタートとラベル付けられたボタンが表示された。その人はマウスを使ってそのボタンを選択した。」など。
つまり、機能やコードモジュールのリストを積み重ねてソフトウェアをデザインするかわりに、そのソフトウェアが現在あるいは将来実現可能なシナリオを、観測・記述・発想・開発することで、ソフトウェアをデザインする。
具体的には、
●とある一日を記録したビデオ（video of a day-in-the-life）
●将来のシステムとその利用方法を記述したもの
「シナリオ」には状況設定として以下が含まれる。（p.41）
●エージェントやアクター（各々にゴールや目的をもつ）
●プロット：アクションとイベント（アクターが行うこと、アクターに起きるイベント、状況設定の変化） ※シナリオのゴールを変えてしまう可能性が大きい
→→→ シナリオはHCIのデザインに基づく科学的フレームワークとなる
「シナリオ」の効果として重要なのが内省である。（「もし〜ならどうなる？」思考／"What-if?" thinking を促すため）
「シナリオ」はデザインの可能性と結果を記述するモノである。
→"問題空間"を決定し、目標と最終状態を定めるために利用できる。
この本で言う開発プロセスとは：
1. 人々の要求、好みを理解する（観察・分析）
2. 未来の活動とテクノロジーを想像する（アイデア出し）
3. システムとソフトウェアをデザインする（プロトタイピング・開発）
4. 開発後に使用する（テスト）
5. システムから一般的な教訓を評価して導く?（テスト・評価）
各章の構成：
第1章では本書の概要を、第2章ではデザイン問題解決の概要について述べている。
第3章では、デザインにおける5つの重要課題がシナリオに基づく設計ではどう扱われるか示す。（p.40-）
課題1. 設計行動は内省と行為のパラドックスを引き起こす
→敢えてシナリオにより内省を引き起こすことで解決できる
課題2. 設計状況は流動的である
→シナリオは具体的に・柔軟に変えていくことができる
課題3. 外部要因（開発組織、作業手順など）が設計に制約を加える
→ステークホルダー全員がシナリオの言語で語るため作業を促進する
課題4. 設計が進展すると数多くの解決方法が出てきてしばし競合が生じる
→シナリオにより多視点から検証できる
課題5. 技術的な知識がデザインを遅らせる
→シナリオにより抽象化・類型化することで解決できる
要するに、実際に開発する前に、シナリオ言語による記述の段階で複数回のプロトタイピング＆検証を行うのがよいだろう。ということかな。
第4章では、シナリオに基づく設計に対する具体的アプローチを紹介する。例としてビデオ情報システムを挙げる。さらに、第5,6章では「シナリオ」を物語風の記述（narrative descriptions）から、より具体的なデザインツールへ発展させる方法について述べている。「シナリオ」を用いることでユーザインタフェースデザインのエラーを発見できる。
第7章では、デザインを科学的手法として用いる方法を示す。
第8章では、デザインの評価とデザインの理論化の可能性について示す。
第9章では、ユースケース:use caseとシナリオの関連性について示す。
第10,11章では、デザインシナリオを分析し発見するための具体的な手法と技術を紹介する。
第12章では、シナリオに基づく設計に関する現状と今後の発展について述べる。
その他、ポイントとなるテキスト抜粋：
（※日本語訳が原文に忠実すぎて読みにくいものは◎→●に変換した。）
●何が問題なのかを決定することが、デザイン問題の核心である。（p.12）
●問題解決における"問題空間"は予め決まってはいない。同様に目標と最終状態も決まっていない。つまりデザインとは、"問題空間"を定めながら同時に目標と最終状態を決定していく、問題解決の活動である。デザインは最終的に人間の活動に影響を与える。「チームワーク、問題分割、そして多くの管理」においてデザインの知識と経験が要求される。（p.12-13）
（◎さらに、許容され取りうる「処置」（move）の問題空間は前もって決定されない。しかも、目標あるいは最終状態が分からない。実際に、目標を明らかにすることとその問題を解決することは、概して単一で同一のものである。デザイン問題は特徴的に多くのトレードオフを含んでいる。またすべての処置は副作用を生み出す。デザインとデザインの処置に対する、最も重要で最も相互に依存する結果の多くは、人間の活動に影響を与える。デザインには多くの種類の知識と経験が要求される。一般的に、チームワーク、問題分割、そして多くの管理が必要になるといえる。（p.12-13））
その他、関連研究につながるもの：
●一般的なデザイン活動では「抽象化: abstraction」する。（↔シナリオに基づくデザイン活動では「具象化: concretization」する。）
・パズルやおもちゃの問題として扱い問題解決につなげる（Simon 1973）
・科学的演繹法によりデザイン空間を分割し問題解決につなげる（Newell and Card 1985）
以上。
2018-12-26