したっぱプログラマーの日記(The diary of a minor programmer)

様々なものを「見える化」することによって、企業の底力が上がる。
という話。

中身は、良い悪いは別として、学問色が強いなと感じた。
「見える化」の４つのバリエーションや、５つのカテゴリーといったものが提示されており、個人的には、「う、覚えられん。」とか「違いが、ようわからん」といった感想。

僕にとって、この本を読む理由は、あくまで現場で活かすということ。
現場で活かすときは、細かいカテゴリー分けを意識する必要性はあまりないよね。と納得することにした。

読後、僕が、思った大事なことは、

• 情報を視覚化することで、直感的に、現状把握 →（目的とする感情、行動の誘起）


• 失敗を憎んで、人を憎まず

最初の項目について
「目的とする感情、行動」とは、モチベーションＵＰだったり、問題への対応だったり。
例えば、毎日の体重の変化をグラフ化によって「見える化」した時のことを考える。
毎日、体重が減っているのがグラフにより確認できれば、ダイエットのモチベーションもＵＰ。
また、体重が増えているのがグラフにより確認できれば、よりハードなトレーニングをしようとするはずである。

2個目の項目について
失敗という情報は、失敗を繰り返さないために有益な情報であり、「見える化」することが重要だが、たいてい人は失敗を隠したがる。
隠したがる、主な原因は、自分の責任を問われるからである。しかし、それにより失敗が見えなくなってしまうことは、チーム全体にとっては、あまりよろしくない。
そこで、「失敗を憎んで、人を憎まず」という文化が必要。
（ただ、それによって「失敗は、別にたいしたことではない」という誤認識が生まれると、逆に失敗が多発するという暗黒面もあると思う。）

2個目に関して、ソフトウェア開発で肝に銘じているのは、
「誰の責任のバグか追求する前に、そのバグをつぶす方法を考えよう。」
ということ。

しかし、この考えに安住し過ぎているためか、僕のコードにはバグが多い…。
周りの人をイライラさせていること、この上ない。きっと。