【読書メモ】みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解!

ゴールデンウィークだけど外出もできないのでだらだら1冊だけ読みました。

目次

  • 第1章 AWSの基礎知識
  • 第2章 AWSで作るWebサービス
  • 第3章 サーバーレスプラットフォームで作る モバイル向けアプリケーション
  • 第4章 AWSで作るデータの収集・可視化基盤

ざっくりですが、第1章はAWSというよりクラウド(インフラ)の歴史から責任共有モデル、Well-Architectedフレームワークについて、IAMのアカウント管理やCloudWatchのモニタリングに関して触れています。
第2章でネットワーク、コンテナ、CI/CD環境...といったカテゴリー別にAWSサービスの紹介。
第3、4章でサーバーレスアプリ、データ収集基盤を実際に構築するハンズオン形式の解説となっています。

良かった点

ポイント・概要的なことはまとめるとキリないので良かった点だけ。

実際の構築に近い視点でAWSサービスを理解できる

これまで認定試験のAWS勉強だけだったので表層的な知識習得だったと思うのですが、この本では

  • どのような考えでアーキテクチャを設計するのか
  • 運用やセキュリティ目線ではどのようなことを考える必要があるのか

等、実際の案件に近そうな感じでシミュレーションができ理解が深まったように思います。

たぶん、他のAWS本でも同じ方向性の内容だとは思うのですが、特に良かったのはタイトルに「みんなの」って書いている通り、初学者の人にとっても学びやすい内容だったことです。
例えば、第2章でコンテナの説明を扱っていますが、ECRやECS、EKSの説明の前にそもそもコンテナとはなにか、向いているケースはどのようなケースかみたいな話が丁寧に説明されています。
解説されていることのほとんどは何となくは知っていたけれど、背景的な話や実際の構築に近い話が出てくるのでこれまでの本とは違う観点でAWSやそのサービスを見れるようになったかなと思います。

コンソールのキャプチャが多い

3、4章のハンズオンの中でキャプチャ多用されているので、実際にいじってなくても本の中だけで完結できるのはよかったです。寝る前とかに読めるので。

情報が新しい

試験本は若干古い情報が載ってたりするのですがこの本は新しいので、この比較表は内容古そうだからググって調べなきゃな的なバイアス抜けれるだけでだいぶ読むの楽だった感じがします。特にS3のストレージクラスなど。

まとめ・感想

もっとAWSのこと試験対策だけじゃなくで理解しようというふうに思いました。
1年ほど前からプラクティショナーの勉強始めて、そう思えるまでに時間かかってしまいましたが他の本なども読んでみたいと思います。

2020年4月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 2 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

なんででしょう。あれだけ欲しいと思っていた時間がすぐそこにたくさんできたはずですが、インプットもアウトプットもペースが落ちてしまっています。

来月に向けて

長い目でみてもう少し状況に慣れて、あまり無理せずやっていきたいと思います。

【読書メモ】他者と働く──「わかりあえなさ」から始める組織論

技術本ではないですが気になっていてほしいものリストにずっと入れてた本。
前回 読んだチーム・ジャーニーでハンガーフライトの解説で、対話に関して詳しく理解したい人におすすめの本として挙げられていたので、次に読んでみようと思っていました。

目次

  • はじめに 正しい知識はなぜ実践できないのか
  • 第1章 組織の厄介な問題は「合理的」に起きている
  • 第2章 ナラティヴの溝を渡るための4つのプロセス
  • 第3章 実践1.総論賛成・各論反対の溝に挑む
  • 第4章 実践2.正論の届かない溝に挑む
  • 第5章 実践3.権力が生み出す溝に挑む
  • 第6章 対話を阻む5つの罠
  • 第7章 ナラティヴの限界の先にあるもの

2章までが枠組みや、本で扱う問題や解決方法について、3章以降は事例を元に解説されています。

概要・ポイント

対話

知識として正しいこと、でも実践でもそれが正しいとは限らない。その問題を解決するために行うのが対話。
本の中での定義としては「新しい関係性を構築すること」
そもそもそのような問題が起こる要因、解決法としての対話のステップと方法はこうですよという話がこの本の大

技術的問題

既存の方法で解決できる問題

適応課題

既存の方法で一方的に解決ができない複雑で困難な問題
他の部署に協力を求めることが必要な課題を例とした関係性の中で生じる問題

関係性の改善

「私とそれ」という道具的な関係から「私とあなた」という固有の関係へシフトする。
自分の中に相手を見出すこと、相手の中に自分を見出すことが対話の意味である。

適応課題のタイプ

  • ギャップ型 価値観と実際の行動にギャップが生じるケース
  • 対立型 互いのコミットが対立するケース
  • 抑圧型 言いにくいことを言わないケース
  • 回避型 痛みを伴う行動に向き合わないケース

ナラティブ

物語、つまりその語りを生み出す「解釈の枠組み」のこと。それぞれ人がみんなもつもの。
ビジネス上では「専門性」「職業倫理」「組織文化」などに基づいた解釈が一般的。その人にとっての一般常識。
ナラティブ・アプローチとは、「どう相手に話をするか」よりも「どう相手を捉える私の物語を対話に向けていくか」を主軸にしたもの。

解釈

相手のナラティブにおいても意味があるようにするにはどうしたらよいのかを考えること
できれば信頼のおける仲間や相棒と一緒にやるのが望ましい

対話のプロセス

  • 準備 「溝に気づく」
    • 自分から見える景色を疑う
    • あたりを見回す
    • 溝があることに気づく
  • 観察 「溝の向こうを眺める」
    • 相手との溝に向き合う
    • 対岸の相手の振る舞いをよく見る
    • 相手を取り巻く対岸の状況をよく見る
  • 解釈 「溝を渡り橋を設計する」
    • 溝を越え、対岸に渡る
    • 対岸からこちらの岸をよく見る
    • 橋を架けるポイントを探して設計する
  • 介入 「溝に橋を架ける」
    • 橋を架ける
    • 橋を往復して検証する
    • 橋を補強したり、新しい橋を架ける

「準備」段階は歯がゆく勇気がいる。一度自分のナラティブを脇においてみることが大事。

対話の罠

  1. 気づくと迎合になっている
  2. 相手への押しつけになっている
  3. 相手と馴れ合いになる
  4. 他の集団から孤立する
  5. 結果が出ずに徒労感に支配される

読みながら1.は自分もそうなりそうだよなと感じていたが、迎合(忖度)は相手へ隷属すること、自ら気づいた課題意識や問題点を見ないようにすること、すなわち、諦めることを意味しているので、そこが対話との違い。(プロセスでいえば橋を渡ったまま帰ってこないのといっしょ)

あとは最後の辞めたり、休んだりすることも重要というのは大事な気がしました。

良かった点

  • 最後エモかった
  • インテル、レッドハットなどIT企業の例が多い

惜しかった点

  • 特になし

まとめ・感想

大学のときにメディア学すこしかじってて、ナラティブとか物語性(人は物語をつけたがる・求める)みたいな話に通ずるところがあり、今になってこういうテーマを見ることになるとはなあという感じでした。
例えば第3章の新規部門と既存部門の話など結構いまの仕事というか会社内でも関連する話がありました。
去年結構売れている本のようなのですが、こういう類の本が売れる(みんなが関心を持つ)っていうのはいいなあと思いました。

【読書メモ】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

市谷聡啓さんの上記2冊に続いて、チーム・ジャーニーを読みました。
カイゼン・ジャーニーの続編ぽい感じだったので(実際には単体でも読める)2月の発売から楽しみにしており、3月に内容も多めだったのですが、ちょっとだらだらしながらになってしまいましたが読みました。

目次

第1部 僕らが開発チームになるまで─1チームのジャーニー

  • 単一チーム 基本編
  • 単一チーム 応用編

第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー

  • 複数チーム 基本編
  • 複数チーム 応用編

カイゼン・ジャーニーは、1人から始められるカイゼンを繰り返しチームが遷移していく(だけど焦点は個人に合っている)物語でした。
対してチーム・ジャーニーは、チームマネジメントやチームづくりについて、よりチーム全体に焦点を当てた内容になっています。
物語方式にて、まず問題(ストーリー・問題編)、次に課題(ストーリー・解決編)、最後に解説が各章にておかれています。
基本編で4章、応用編で4章、それが1部+2部なので全16章というボリュームになっています。

概要・ポイント

大枠として、度々書かれていたこと

  • なめらかに進める
  • 解像度を意識する
  • 状況によってフォーメーションを組む

チームマネジメントにおいて、一気に状況を変えようと思っても無理は利かないので段階的に予定を立て進めていく。
人によってその情報や状況に対する捉え方(視座=高低/視野=広狭)が違うので念頭におく。
ひとつの固定の役割、既存の概念に囚われず状況に応じて柔軟に配置転換、役割の創出などを行なう。

その他、気になったこと、なるほどと思ったことなど。

コンウェイの法則

プロダクトやシステム設計が、組織構造(チーム分割等)を反映したものになることをいう。
逆にプロダクトの機能などから組織構造を作ることを逆コンウェイの法則という。

取引コスト

もとは経済学の言葉で、違う文脈を持っている相手に対してコミュニケーション取ることは取引コストが高い、などという。

「リード」という役割

「リーダー」とは別の「リード」という役割
・リーダー => 組織上の職位として定義
・リード => ある状況において前進を先導する「役割」。例)テクニカルリード、仮説検証リード、テストリード

情報の解像度

レイヤーによって粒度分けて展開するのが望ましい。
例えばPOなどのレイヤーで細かな機能についてまで話を展開してしまうと、開発者メンバー側では情報を受け取って「ただそれを実装する人」になってしまう。
ある程度は余白もたせて PO => リード => 開発者 などに受け渡ししていき細部を詰める流れがよい。

番頭の輪番化

担当をローテーションすることで、トラックナンバー1問題(誰々しかこのコードを触れない問題)につながらないようにすること。

ただし、チームメンバーの専門性や関心などで、あるメンバーに依存する領域が生まれてしまうこと自体は悪いことではありません。むしろメンバーの多様性がいきている状態ともいえます。属人性を排除することを過度に目指すのではなく、何かが起きたときに他の人でプランB(本人ほど最適ではないが、他の人でもなんとか対応できる作戦)が立てられるかどうかを明らかにしましょう。

事前に許可を求めるより、後でゆるしを得たほうがたやすい

先に動いてしまって後でゆるしを得にいくということ
これ結構メンバー側目線で自分も意識していて、ケースバイケースではあるものの決裁権持っているひとにいちいち確認しても時間もったいない(=ボトルネックになる)と判断したら答え確定して出した方がいいなと

視座と視野で決まる視点

物事をどこからどこまでを見るようにするか、「どこから」というのは「視座」、「どこまで」とは「視野」にあたる。
その上で
・視座や視野への偏りをつくらないこと
・視座の高低と視野の広狭を自分たちの意思で行き来できること
が重要。

良かった点

  • 少し登場人物の名前が分かりづらいが、相変わらずストーリーがおもしろい。
  • 問題:課題:解説の割合、1:1:1 くらいですが、ある問題に対して内容割いている本も少ないように思うのでためになる。

惜しかった点

  • 特になし

まとめ

本に解説してある内容でも実際の現場では状況も違うので、その都度ベストな選択や考えを結局自分自身がしたり持ったりしなくてはいけないのだけれど、その幅が広がったり選択がしやすくなるような内容の本だと思う。

いっぽうで結局正解はないので読者の主観に後は委ねられる部分も多くある、そういう不確定要素を好まないひとには向いていないかもしれないが、筆者の「正しいものを正しくつくる」でさんざん語られていたように今の時代そういう開発形態も考えも主流になっていくなかでうまく自分も適用できるようにならないとと感じた。

最近発売されたオライリーみんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた の説明にも

本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、...

と書かれています。
自分も今の会社に入って分かったのですが、結構クライアント側の方が開発に入ってくることが多く、その良い面みたいなのはすごく感じています。それでいて知識も豊富だと後ででてくる要件も出づらいのでやりやすいなと。

今回の本はチームビルディング的な観点だったので、いちメンバーである自分には適用しづらい内容も多かったですが、そういう視点も持ちながら働く/働かないではわりと違うんでは、と思っているのでもちょっと視野広げてやっていきたいと感じられました。

2020年3月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 15 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

ブログ前半は調子良かったが後半失速気味になってしまった。
仕事の業務でフロントエンドできているのが収穫です。

来月に向けて

新たにコレを勉強する、っていうのが今のところない..
Vue or Nuxt もうちょっと勉強でもするか、この機会にAWSのSAP勉強するか悩み中です。

3月からフルでリモートでした。
当初の慣れのなさからは落ち着いてできるようになったので、もう一度もとに戻すところは戻してやっていきたい。

Netlify で $ gulp build がビルドエラーになってしまう

f:id:jotaki:20200318200015j:plain

いつもどおりNetlifyでGulp使ったプロジェクトをデプロイしようとしたらエラーが出てちょっと詰まったのでメモ。

管理画面側でDeploy Settingsからもビルドコマンドなど設定してましたがログに

Error running command: Build script returned non-zero exit code: 127

みたいに出て、ググってみるとビルドコマンドがないよ的な内容らしい。
ただローカルでは $ gulp build でうまくいってるのでイメージのバージョンとかかなと思いつつ公式見てみると、

Eleventy starter with serverless functions というのがあり、
https://templates.netlify.com/template/eleventy-starter-with-functions/

リポジトリ内に netlify.toml てのを見つけました。
https://github.com/philhawksworth/eleventyone

この netlify.toml は設定ファイルをコードベースで管理できるそうなので、

netlify.toml の中身

[build]
  command = "gulp build"
  publish = "dist"

とりあえずこれだけ書いてルート階層に置いてプッシュしてみました。
結果、うまくいった。

f:id:jotaki:20200318200027p:plain

厳密な原因分からずですが、とりあえずGulp使って自動デプロイまでの調査結果でした。

【読書メモ】ユーザビリティエンジニアリング(第2版)

前回前々回 に続いてUXの知識をつけるべく ユーザビリティエンジニアリング(第2版) ―ユーザエクスペリエンスのための調査、設計、評価手法― を読みました。

目次

  • Chapter1 ユーザ中心設計概論
  • Chapter2 インタビュー法
  • Chapter3 インタビューの実践
  • Chapter4 データ分析法
  • Chapter5 発想法
  • Chapter6 プロトタイプ
  • Chapter7 ユーザビリティ評価法
  • Chapter8 ユーザテスト
  • Chapter9 ユーザテストの準備
  • Chapter10 ユーザテストの実施
  • Chapter11 分析と再設計
  • Chapter12 ユーザ中心設計活動

概要・ポイント

  • イントロダクション(1章)
  • 調査(2章〜4章)
  • 設計(5章〜6章)
  • 評価(7章〜11章)
  • エンディング(12章)

の大区分の中で、優れたUXを実現するためのユーザ中心設計(人間中心設計)プロセスや手法について解説されています。
Webやスマホアプリのような限られた端末に限らず、組込みシステム等でも活用できるような内容になっています。

ポイント

ユーザビリティとは

前提として、「ユーザビリティ = 使いやすさ」ではない。
ユーザビリティに問題がある = 使えない」という意味でもある。

国際規格ISO9241では、ユーザビリティを「特定のコンテキストに置いて、特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際の、効果、効率、ユーザの満足度合い」と定義しています。

  • 効果は、ユーザが目標を達成できる
  • 効率は、なるべき最短経路で目標を達成できる
  • 満足度とは、ユーザに不愉快な思いをさせない

これら3つをあらゆるコンテキスト(前後関係や状況)において阻害しないことが重要。

ユーザーエクスペリエンス

仮にユーザビリティが満点であっても、その製品への評価は中程度にとどまる

ユーザ中心設計

優れたUXを実現するために、ユーザ中心設計(UCD: User Centered Design)、もしくは人間中心設計(HCD: Human Centered Design)を用いて、技術優先の考えや勝手な思い込みを排除して、常にユーザの視点に立った製品開発が行える。

骨格となるプロセスを反復することによってUXの完成度を上げていく。(評価と改善を繰り返すのが重要)

  1. 調査:ユーザの利用状況を把握する。
  2. 分析:利用状況からユーザニーズを把握する。
  3. 設計:ユーザニーズを満たすような解決案を作る。
  4. 評価:解決案を評価する。
  5. 改善:評価結果をフィードバックして、解決案を改善する。
  6. 反復:評価と改善を繰り返す。

ユーザの声

「ユーザの声に応えればユーザは満足する」という前提は間違いで、鵜呑みにせず暗黙的な要求まで満たす必要性がある。例:医者
アンケート、グループインタビュー(グルイン)のメリット、デメリット

コンテクスチュアル・インクワイアリー

インタビューアを弟子、ユーザを師匠と見立てて、師匠の体験を弟子に "継承" します。

コンテクスチュアル・インクワイアリーという手法。

  • 心得 教えを乞う → 根掘り葉掘り → 確認する → フォーカス移動 の手順を繰り返す
  • 師匠は気難しい / 話を要約する / 例外には触れない
  • 良い弟子と悪い弟子 / 用意する質問は1つだけで、2つ目以降は質問を1つ目の会話から見つける
  • リクルートやインタビュー準備

質的データ分析

インタビューや観察で得られる情報は「質的データ」
加減乗除のような演算をしない、編集(切り貼り)できる、KJ法での分析が可能。

ペルソナ

決して "架空" のユーザではない

事実に基づいたフィクションを目指す
プライマリーペルソナ、セカンダリーペルソナを設けプライマリーペルソナの要求を完全に満たすことを目的にプロジェクトを進める。

ブレインストーミング

  1. 批判厳禁
  2. 自由奔放
  3. 量より質
  4. 便乗歓迎
  5. 視覚化
  6. 脱線禁止
  7. 1度に1人

・Yes And 話法

何を言われても、まず「イエス」と肯定した後に、そこに「それに加えて」「では次に」と自分の意見を追加しながら会話を進めます。

KJ法、ポジショニングマップ、ドット投票などで結論の収束を行なう。

キャンバス

ビジネスモデルキャンバス、それを元に新サービスなどゼロから発想するためのリーンキャンバスがある。
顧客・課題・ソリューションが解決しても、コスト・収益が成り立たないなどなりがち。説得力のある内容でキャンバスを埋めることが大事。

プロトタイプ

制作者が作るために作ったものではなく、ユーザに使ってもらうために作るため「試作品」というよりも「試用品」。
ローファイとハイファイ。Tプロトタイプ、オズの魔法使い

プロトタイプとは、全体を大雑把に作ることではなく、必要最小限に絞って作ること。

ペーパープロトタイプ、パワポの使用も場面により有益。
階層構造の設計にはカードソートが有効で、クローズド(見出しあり)、オープン(見出しなし)がある。

評価

評価は目的に依って『統括的評価』と『形成的評価』に大別できます。

統括的評価とは、学習成果の総合的な度合いを "測定" することを目的とした評価です。
形成的評価とは、小さい学習ごとに、どれくらい理解できているか、理解するためには何をしなければならないかをフィードバックするための評価です。

具体例としてTOEICは典型的な統括的評価。英会話に通って発音矯正したり、文章添削するような継続性のあるものは形成的評価。

ユーザビリティ評価も2つに区分できる。
統括的評価の代表は「パフォーマンス測定」(タスク達成率、達成時間など)
形成的評価は『思考発話法』を使ったテスト。

原則として、統括的評価は設計プロセスの "前後" で用い、形成的評価は設計プロセスの "途中で繰り返し" 用います。
もう一つ、忘れてはいけない重大な原則があります。それは、「統括的評価しか行わないのならば、それは全く無駄な投資である」ということです。

ヒューリスティック評価

ユーザビリティ評価のための分析的手法の総称を『ユーザビリティ・インスペクション』といいます。

これは評価者自らの知識や経験に基づいて行なう評価だが、客観性を持たすたせるために様々なガイドラインが考案されてきた。

そのなかでヤコブ・ニールセンがユーザビリティ問題を分析して、原則を抽出したガイドラインを『10 ヒューリスティックス(10 heuristics)』という。ヒューリスティックスとは『経験則』という意味。

ヒューリスティック評価』とは、この10ヒューリスティックスを根拠として、評価対象の製品が犯している "ルール違反" を探索するという手法です。

参考: Jacob Nielsen の「ユーザビリティに関する10のヒューリスティクス (問題解決に役立つ知見) / Ten Usability Heuristics」 — Website Usability Info

実施手順として、評価者は

とし、合議制ではなく単独で評価、発見した問題点をどんどんリストアップしていく。その後評価者ミーティングでディスカッション、レポートに取りまとめる、という流れ。
ただ検出過多やコストの問題などがあり、ヒューリスティック評価は意外と贅沢な方法である。

認知的ウォークスルー

「人間の認知モデル」に基づいて評価を行う手法。
ユーザの技能や経験/タスク/操作手順/画面を定義し、そのなかで4つの質問(目標設定/探査/選択/評価)の探査学習ステップの内容を分析していく。

認知的ウォークスルーではユーザインタフェース上の問題点を詳細に検討するだけでなく、ユーザのとりうる行動を推測することで新たな要求開発にもつながります。

設計の初期段階で用いると有効な手法で、設計者自らがデザインを客観的に再検討するために用いることも可能。

ユーザテスト

ユーザが参加した評価手法の総称で、

  1. ユーザにタスク(作業)を実行するように依頼する。
  2. ユーザがタスクを実行する過程を観察、記録する。

がユーザテストの基本。そのなかで、

  • 思考発話法と回顧法(形成的評価/質の評価)
  • パフォーマンス測定(総括的評価/量の評価)

など代表的なテスト手法がある。

・思考発話法
考えていることを話しながら操作してもらう。

・回顧法
操作が終わってから質問に答えてもらう。
ただ複雑な状況は回顧が難しいなどの短所もある。

・パフォーマンス測定
数値データ(タスク達成率や達成時間)が必要な場合、量的なデータ収集を目的とした代表的手法が「パフォーマンス測定」
ユーザビリティ3要素(効果・効率・満足度)に関係した量的データを計測する。
効果 → タスク達成率
効率 → タスク達成時間
満足度 → 主観的評価

主観的評価はフレームワーク(質問セット)を使うのが一般的。日本語版はWUSがメジャー
https://u-site.jp/usability/evaluation/web-usability-scale/

原則としてプロジェクトの前後で実施して、目標値を設定したり、目標の達成度や改善度合いを把握したりすることが目的です。
短期間にテストと改善を繰り返しながら、徐々に製品の完成度を上げていく反復デザインに適した手法ではありません。

ユーザテストは「反証」を目的としている。
そもそも問題点を見つけようとしているテストなので、予め問題が発生している製品などは対象にできない。(事前にヒューリスティック評価を行なうなどが必要)
被験者としては5名x3回のテストをするのが理想。(15人x1回よりも小規模なテストを繰り返し実施したほうが利用品質が向上する)

その他ユーザテストの準備としてスケジュールの勘所 / リクルートやリソースに関して / スクリーナ(該当者選別のための判定質問) / テスト設計についてなど。

ユーザ中心設計活動

・原始期
・黎明期
・揺籃期(前期/後期)
・躍動期
・拡充期
・完熟期

成熟度モデルとして6段階あり、例えば原始期は

ユーザエクスペリエンスは開発者やデザイナの個人的技量に委ねられている。標準的なUX/UIガイドラインなどは参照しているが、実際のユーザと対話する活動は行っていない。
UX/UCDの専門家はプロジェクトに参加していない。

という筆者が考えるモデルがある。
飛び級は無理なので、まずユーザテストからやってみるのが良い。ただ黎明期レベルでも成果は上がりづらい。

やりやすいのは、「既存製品の改善プロジェクト」。
リリース直前ではなく、改善プロジェクト開始前のテストからはじめる。プロトタイプを作って事前に有効性を検証できる。

調査と評価

ウェブサイトのユーザビリティ調査でも様々な手法を考える必要がある。

・既存のウェブサイトの問題点の把握とその改善策
→ ユーザテスト

・リニューアルに向けたユーザニーズの把握
→ インタビューなどの質的調査

・競合サイトの比較
→ パフォーマンス測定などの量的なアプローチ

またそれらは同時に行なうものではなく、設計プロセスのステップに応じて行なう必要がある。

①ユーザを "調査" して真のニーズを把握
②そのニーズを満たすような製品を設計
③その製品を "評価" して改善する

良かった点

  • 前回読んだ虎の巻よりも各手順や手法が網羅されている感と内容が詳細なので、深い知識がつく(気がした)。
  • 参考文献とかも王道(っぽい)ものを参照しているのでなんだか内容に信頼感があるように感じた。
  • UXの向上を目的とした色々な手法が解説されているが、単にビジネス上でも役立つようなコミュニケーション術、アイデア出し手法などを知ることができた。

惜しかった点

  • 目次を見れば分かるには分かりますが、本の最初に 調査〜設計〜評価 のおおまかな流れと概要について触れたほうが頭に入っていきやすい気がします。

そこの知識ある前提で書かれている本ではあるかもしれないのですが。

まとめ

最後の「調査」と「評価」の使い分けにも書いてあったのですが、これまで読んだ本は触りの触りで、この本は深いところまで解説してあるなあという感想です。
1つ1つの手法についてもそうですが、組織の成熟度モデルについても実態に合っているような気がするので参考になりました。