￥1,890
Amazon.co.jp
前半のイシューとは何か、なぜそこから考えるべきなのかということは頭に入ってきたけれども、
後半のイシューを立証するための方法については、いまいち頭に入ってこなかった。
何故かというと、普段の仕事の中でイシューは（なるべく）意識していたけれども、
リサーチ・分析という仕事にはあまり関わっていないからイメージしにくかったのだと思う。
イシューの定義は下記２つを満たすものとある。
・２つ以上の集団の間で決着のついていない問題
・根本に関わる、もしくは白黒はっきりしていない問題
システム屋として仕事をしていく上で、顧客やパートナーと曖昧な問題を整理していくことは多々ある。
だから、資料を作っていくうえでも、その資料で何を言いたいのかは意識している。
けれども、システムにおいてイシューを説明するためには、
リサーチしたデータや情報からではなく、
現状のシステムはAという結果で、新たにA＋Bという結果になり、
結果、既存Cにどういった影響があるのかということで説明することが多い。
もしくは、こういった理由（影響調査結果）から、こう作るべき（実装方法）だと判断する。
こういったビジネス書を読んだときに常々思うのだけれども、一回読んだだけでは身につかないなと。
読みながらメモを取って自分なりに解釈していかないと身につかないとは分かっていても
なかなか面倒で実践できない。
ポメラとか使いやすいのかなあ。
近いうちに読み直してみよう。