ソフトウェアの設計に関しての意思決定の進め方が細かく載ってる本。UXとは、ユーザーエクスペリエンスの略です。 集団でどう意識の共有をしていくかとか、なかなかわかりやすかった。

• 開発者は構造全てを表現したがるが、ユーザーはわかりやすさのみ求める。 →開発者は用いた機能や技術のことを伝えたがる、しかしユーザーは使えればなんでもいい。相手の視点に立った思考を心がけるべき。

• 開発者はユーザーを理解できない →そもそも理解し切ることはムリ。そこは謙虚に意見を取り入れる必要がある。なので現場の声を聞くのは必須。

• UXデザインの対象はあくまでユーザー →ユーザー（使用者）は顧客（購買決定者）と異なる場合もある。UX（UI）はあくまでユーザーにとっての使いやすさを。

• 顧客のメリットと合致させる →そうは言っても売れなければ意味が無い。ユーザーの使いやすさを、顧客の得なように伝える。（ユーザーの生産性を上げる。サポート・キャッチアップ費用の削減など）

• デザイン調査は、ユーザーの現状を５W１Hで抑える。根底のニーズを把握する。

• 構想初期段階ではあえて抽象的にしておき、可能性を狭めない。 →何気ない言葉でも、知らないうちにバイアスがかかり思考を狭めてしまうことがある。

以上がざっくりとした内容です。ペルソナとか以降は説明がややこしいので割愛。

で、開発の現場でよくある例と、その利点・問題点についてちょっと考えてみます。 大きく、

• 言われたとおりに作るSIer型
• 独断でニーズを想定するベンチャー型

で書いていきます。

言われたとおりに作るSIer型

利点： 人材を選ばなくても同じクオリティに仕上がる 工数見積など想定しやすい

問題点： ユーザーの声を聞きすぎて思想のないものになる。ガラパゴス化する 差別化出来ないためデスマーチになる（早く安くが求められる）

独断でニーズを想定するベンチャー型

利点： イノベーティブな製品が生まれやすい

問題点： 工数が読みにくい 保守がしにくい（設計者のコーディング能力に依る） 顧客ニーズとずれてコケる可能性もある。

実際の開発にあたっては、この２つのバランスを取ることが大切かと思います。ベンチャーとかで、自称優秀な人たちが集まって革新的な製品を考える際に、顧客の声を一切聞かないで自分の考える理想の製品を考えてしまう例が多々あるようです。で、実装もままならずバグが多く保守も事実上不可能、おまけにニーズとずれてる、なんて悲劇にならないように気をつけなきゃいけない。現場のユーザーの声ももっと聞かなくてはいけない。

基本的にソフトウェアは改良を加えて長く使うものなので、保守性が高いことはかなり重要。オブジェクト指向とか、DBの正規化とかも保守性を高めるためです。

最後に、人は技術に金を払うのではなく、それでできるメリットやストーリーにカネを払うものです。開発者も、何でその技術を使うのか、を非エンジニアにもわかるように説明出来る必要があるかと思います。