ドナルド・C・ゴースのレビュー一覧
-
-
-
-
Posted by ブクログ
# 問題と向き合う上で認識しておきたい事例集
## 面白かったところ
* 主人公が問題に対して失敗を冒す小話を例にとって、問題の捉え方を説明している点
* 相手にとっての問題であることを自分自身が認識していないケースが特に面白くて、色んな漫画の適役を想起させた
## 微妙だったところ
* ちょっと分かりづらい例が多々あった。もともと洋書だからしょうがないけど
* 「問題」という抽象的な分野に対するアプローチであるが故に、一回読んだだけでは理解が難しい。
## 感想
この本を読んで、短い仕事人生や歴史・漫画鑑賞で培った見聞に色々当てはまって面白かった。
自分が人間である限り問題がなくなることは決してないのだけれど、だからといって問題から逃げたりすることは正しい行いではないとワインバーグ先生も仰っていた。
裏を返せば、「いつかは `真実` という答えにたどり着くことができる」可能性が秘められていることを示唆している。
これはジョジョ第5部でアバッキオの元同僚が告げていた「真実に向かおうとする意思」の話を思い出した。
また時を経て読み直したい一冊。 -
-
-
Posted by ブクログ
ロジカルシンキングやクリティカルシンキングの文脈で今考えていること・話していることのそもそもの問いは何か？何を解決するべきか？という問題発見の考え方を学ぶ。
良書として有名だが、個人的には読みづらかった。全体的に主張は良いものが多く、問題発見というテーマも実用的で良いのだが、表現が難解な上に冗長だと思う。原作が海外のものであり、しかも1982年と古いので、現代の日本人から見てわかりづらいのは仕方がないかもしれない。
58ページ
設計家はビルの持ち主と同様、自分たちがやったことのもたらす結果を経験するということのまずないものである。だから設計家は不適合を作り出す。
→わかる。エンジニアがユーザの立場で考えるべきと言われるのは、このギャップが実際に悪影響を及ぼすから。要件定義で丁寧にヒアリング結果を言語化するのも、このギャップを減らしたいから。
127ページ
ところがどうも彼らは、試験問題はコウノトリが持ってくると思っているようなのだ。
→わかる。同じような話として、システムのエラーメッセージや監視通知メッセージを見て自然発生的に書かれたかのように認識してしまうことがある（特に自分自身でシステムを設計したことのないような経験の浅いエンジニアによく見られる）が、そんなわけはない。人工的なメッセージは事前に誰かヒトの手によって作られており、作成者が作成した時点の理解・解釈・気づき・気配りが反映されている。もし作成者が気づいていなかったことの監視はできないし、不親切な人が作った場合はメッセージを見ても何をすれば良いか読み取れないし、気配りができる人が作った場合は丁寧すぎるほどに手順が示される。そして、もしメッセージに不満があるなら、自分でメッセージを作れば良い。
130ページ
実際それらは問題を見ないでも「解けた」のである！
やってみてほしい。典型的な選択肢は次のようなものだった。
(a) 31938
(b) 31929
(c) 31928
(d) 32928
(e) 31828
→わかる。出題者の意図を読むことが大事。話し手の意図は本来はメインメッセージとして（ここでいう問題文として）表されるはずだが、聞き手はメインメッセージ以外の情報から読み取ることもできる。一見すると関係のないような発言・表記・表情・所作に現れるだろう。 -
-
-