「見える化」は2章を読め

　いきなり結論というか自戒→いきなりamazonで買わずに、実物を手にすること。普段は「書店でパラ読み→amazon発注」が、今回はチェックせずに買ってしまったorz。いや、ダメ本というわけではなく、表層的だったので、ガッカリしただけ。

　これは「見える化ってなーにー?」 という人で、かつgoogle先生を知らない連中のための入門書。実際に「見える化」に取り組んでるならば、200ページの半分（1章と3章）を読む必要なし。1章と3章には、お約束の「見える化とは何か?」といった定義づけやコトバ遊びが並んでいて、仕事中にビジネス書を読むような経営者向けのネタがある。例えば、

　　・観える化
　　・見える化
　　・視える化
　　・診える化

上記の違いや、問題解決のためのPDCA
　　Problem-Finding（問題発見）
　　Display（「見える化」）
　　Clear（問題解決）
　　Acknowledge（確認）

のネタは、「見える化」の実施に何の役にも立たないだろうが、エラい人向けの作文に混ぜておくと喜ばれる（オヤジはオヤジギャグが好き、という法則）

　それでも本書のキモである34の「見える化」事例は興味深い（2章）。会社によって「目で見る管理」や「可視化」、「視える化」と名前は違えど、見えないものを目に飛び込ませる試行錯誤は面白い。「あらあら、こんなことやってるのね～」てな感じで楽しめる（あらあら禁止！）。

　内部情報を公開することになるため、取組みの詳細が簡略化・断片化されていたり、ともすると企業名すら明かされていないものもある。それでも業界横断的にまとめられているのはありがたい。日経○○の記事を「見える化」で検索した方が沢山採れるだろうが、本書の方が体系づけてまとめられているため、さらりと読めるとこがマル。なんだか胸が一杯になったトコは次の一文。

　問題発見・問題感知は担当者の責任だが、問題の発生を未然に防いだり、対策を講じたりするのは、チームの仕事。解決まで個人で背負う必要はない

　そう、確かにその通り。問題という厄介ごとを見つけた人が犯人扱いされしまう理不尽さが、プロジェクトを殺す（キジも鳴かずば、撃たれまい）。鳴かなくなったキジがなんと多いことか。

　「不具合は、その対策を考えてから報告すること」
　「不具合を見つけた人が詳しいから、そいつに修復させろ」
　「throw しても誰も catch してくれない例外処理を自分で書く」

ﾟ(ﾟ´Д｀ﾟ)゜｡　　…あ、あれ。目から水が出てくるのはなぜだろう。

　気を取り直してと。エラい人から「見える化って何?」と訊かれたらこいつを推しておけば無問題。ソフトウェア開発をなりわいとされる方なら、本書よりも↓を強力に推す。見えないものを見る方法は、ソフトウェア開発にこそ渇望されているっしょ。

　　　「見える化」でソフトウェア開発！ : オージス総研
　　　「見える化」の実践を「見える化」 : 角谷HTML化計画