Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

ユーザビリティエンジニアリング原論

お盆休み中に最低5冊はUI/UXの本を読もうと考えて、その第三弾。 ユーザビリティエンジニアリング原論

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

面白かった。

本書で述べるユーザビリティのスローガンは以下のように要約される。

  • 最高の考えでは十分と言えない
  • ユーザはいつも正しい
  • ユーザはいつも正しいわけではない
  • ユーザはデザイナーではない
  • デザイナーはユーザではない
  • 副社長はユーザではない
  • 少ないほど良い
  • 詳細にこだわる
  • ヘルプにならない
  • ユーザビリティエンジニアリングはプロセスである

監訳の篠原さんは、ソシオメディアの代表取締役の方で、以前エンタープライズアジャイル勉強会でご一緒させていただいた記憶がある。 懇親会のときにもみなさんの座席を確認し、メモし名前を忘れないようにされていたのが印象に残っている。非常にお話しやすい方であった。

www.sociomedia.co.jp

ちなみにデザインの本読んでたら無性にiPad Proが欲しくなったので買ってしまった。 どういった理由かはわからない。衝動買い。

HCDライブラリー第1巻 人間中心設計の基礎

お盆休み中に最低5冊はUI/UXの本を読もうと考えて、その第二弾。 HCDライブラリー第1巻 人間中心設計の基礎

人間中心設計の基礎 (HCDライブラリー (第1巻))

人間中心設計の基礎 (HCDライブラリー (第1巻))

正直これにはがっかり。 どのページを読んでも、「ISOxxxxxによると」みたいな感じで書かれている。 デザインは、プロセスなのか。プロセスなのかも知れない。でも決まったプロセスを忠実に守れば良いデザインができるのか? と言ったらそんなことはない。

エンジニアリングからの側面でデザインを見ると、書いてあることは役にたつのかもしれない。 私はそもそもエンジニアリングがあまり好きではないので、読んでてもすっと入ってこない。 (研究寄りの)理系な感じなんだよね。

ノンデザイーナズ・デザインブック(第4版)

お盆休み中に最低5冊はUI/UXの本を読もうと考えて、その第一弾。 ノンデザイーナズ・デザインブック(第4版)

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

この本は非常に素晴らしい。 文章が入る成果物に対して、この本で紹介されている4つのデザインの原則はとても有効だと思う。

  1. 近接
  2. 整列
  3. 反復
  4. コントラスト

読み手にとっては、読みやすく、わかりやすく、記憶に残りやすくなる。 見栄えもよくなるし、自身の満足度も高めることもできると思う。

効果的なブレストのやり方

良いアイディアを出すためにブレストをやることがあると思います。

ブレストって実はすごい難しいです。

大抵、お通夜みたいなブレストだったり、全然効果的な意見がでなかったりして、時間の無駄だったなぁなんてことになることもあります。

どうやったら効果的なブレストができるのでしょうか?

以下のような方法でやると良いアイディアが出やすいです。

準備

  • ホワイトボードを用意する。
  • 9人以内でやる。(10人以上だと発言できない人が出てくる)
  • ファシリテータを用意する。

ルール

  • 時間を決める。1時間なら1時間できっかり終わる。
  • 手の意見やアイディアを批判しない。
  • パソコンは持ち込まない。
  • 本当にどうしようもないバカでアホでめちゃくちゃで非常識な意見を言うというルールを周知する。真面目な話はしない。
  • 一人づつ意見を順番に言ってもらう
  • 意見を言った瞬間、全員で褒めまくる。(意見を言ったあと、間があるとだめ)。これで緊張がときほぐれてさらに良いアイディアが出しやすくなる。
  • 各人の意見出し1~2週してから自由意見を言っても良い。

こんな感じでブレストすると、和気あいあいで非常に良い意見が出ます。 とんでもない解決策が飛び出すことも様々。

visual studio 2017 で msbuildのpathが可変になった

visual studio 2017でmbbuildのpathが可変になりました。 どのpathが真なのか調べるためにvswhereというツールがmsから提供されています。

github.com

バイナリは以下。 github.com

powershellで呼び出すと簡単でした。

でもvswhere.exe配置しなくちゃだめでインフラ的には面倒。

製品の市場性評価 プロダクトマネージャー(プロダクトオーナー)への10の質問

引き続きInspiredから引用です。 この本は新たな気付きがたくさんあって非常に良いです。なぜKindleだけなんだろう。。物理本が欲しい。。

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

プロダクトマネージャー(プロダクトオーナー)への10の質問

製品の市場性評価のために、プロダクトマネージャー(プロダクトオーナー)へ以下の質問をします。

  1. 製品化によって、具体的にどんな問題を解決するのか?(バリュープロポジション)
  2. 誰のためにこの問題を解決しようとしているのか?(ターゲット市場)
  3. 市場の大きさは?(市場規模)
  4. 製品化の成功をどうやって評価するのか?(指標、収益戦略)
  5. 現在、他に競合する製品はあるか?(競合の見通し)
  6. なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか?(差別化要因)
  7. なぜ今なのか?(市場投入の時期)
  8. どうやって製品を市場に出すのか?(市場投入戦略)
  9. 成功のために絶対に必要な要素は何か?(ソリューションの要件)
  10. これらを前提とした上で、最終的な提案は何か?(やるかやらないか)

これらに簡潔に答えられなければならないとのこと。
答えられないなら、製品の市場性評価ができていないことになります。
一番むずかしいのが1と3。

優れたプロジェクトマネージャーの7つの条件

最近は、製品価値、利益、商流など、プロダクトオーナーの学習を継続しています。 その中で、 Inspired:顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

に辿り着き、読み進めています。

この中で、優れたプロジェクトマネージャーの7つの条件があって、 これはスクラムマスターにも当てはまるなと思いました。

優れたプロジェクトマネージャーの7つの条件

緊迫感

優れたプロジェクトマネージャーが入ってくるだけで、中にはたちまち緊迫感が流れる。ミーティング前のおしゃべりはたぶん60秒くらい。

立案者たること

会議の目的や課題は何かを明確にする。

問題を明確かつ簡潔に特定して整理する。

建設的な会議を運営する方法を心得ている。

明晰な思考力

個々の問題を解きほぐして感情やしがらみから切り離す。

根底ある問題を明らかにし、みんなが問題の解決に集中できるようにする必要がある。

データ指向

データを求めデータの背後にある事実に裏付けられた意思決定をする。

決断力

どの組織モデルを使うにしろ、実際のところ、製品開発チームのメンバーたちは、プロジェクトマネージャーの直属の部下ではない。

それでも、プロジェクトマネージャーはどんどん意思決定をし、それを実行しなければならない。

緊迫感を伝え、問題を明確にし、合理的で透明性のある理由付けをして、データに基づいた意思決定をしなければらない。

プロジェクトマネージャーは、チーム内からのデータや意見をいつ集めれば良いか、いつ問題を経営陣に報告すればよいかを知っておく必要がある。

判断力

いつ、メンバーのお尻をたたくのか。 いつ経営陣に報告するか。 いつ追加情報を集めるか。 いつプライベートなおしゃべりをすればいいか。 これらは経験がモノを言う。

姿勢

優秀なプロジェクトマネージャーは、問題を解決するのが上手な人である。

言い訳をしない、やり遂げる、粘り強く、立ち止まらない。

これらに当てはまれば優秀なプロジェクトマネージャーだと、著者のマーティ ケイガンは述べています。 その代表として、当時eBayのリーン・リーディー(Lynn Reedy)を挙げています。

ecorner.stanford.edu