見える化の違い

前回、勘の見える化は
いわゆるタスクボードなどの見える化とは異なる気がしています。

タスクボードの見える化は、
次の行動を誘発する為が主な目的かと思います。
現在の状態を誰もが同じ認識となるように見える化する事で、
各自が次にすべき行動が何かを考え、行動する。

一方、勘の見える化は、行動の誘発というよりは、
ベテランの視点を掴む為のヒントというか、
ベテランの考えを知る1つのキッカケいう感じでしょうか。

伝統工芸などの職人だと技術が結果として見えるものとなります。
見えるので、自分との違いも明確になります。

しかし、ソフトウェア開発では、技術の結果が見えない（もしくは見難い）
ので、自分と何が違うのかが分かりません。
伝統工芸のように技術を見て盗む事も出来ません。

ソフトウェア開発において、同じような環境を作るのは難しいですが、
せめて、ヒントを与える事で、違いを考えるキッカケとする事は出来そうです。

日常的にいつでも技術を見える状態にする一つの案として、
常に予想される結果や成果を
具体的な数値としてホワイトボードなどに書き出してみる。

書き出すと議論も起こり易く、
チームの認識も、より具体的に合うようになります。
更には、若手技術者は、何を見て、何を考えて、
そのような数値を出しているのかを考えるキッカケとなる。
普段から意識して話を聞くようになる。
などの効果が予想されます。

抽象的な課題などは、違いが見え難いので、数値とする事がポイントとなります。
数値とする事に抵抗を感じる人も多いですが、これも一工夫かと思います。

例えば、
「このバグに関連するバグがまだありそうだ」
と感じた場合には、
「関連するバグが、あと3件はありそうだ」

とか

「まだ何件か、変更依頼がきそうだね」
と感じた場合には、
「あと2件は、変更依頼がきそうだね」

などと、まさしく勘を数値化してみます。

このようにちょっとした事を数値化する事を習慣にします。
そして、この数値の根拠は無さそうであるのがベテランです。
結果的に数値が異なるとしても、無さそうである根拠を伝えるキッカケにはなる筈です。
結果の数値が異なるよりも、伝えるキッカケの方が重要だと思っています。

確かに、説明するのは難しいケースもあるのですが、
そこは、それを面倒と思わずに、説明する努力も必要かと思います。

勘の見える化

先月のSWEST19にて大収穫がありました。

失敗プロジェクトのほとんどが開始時に失敗しそうな事がなんとなく分かる
という議論の中で、
「なぜ、分かるのか？」
「それは経験と勘」という事になるのですが、

議論はここで終わるのではなく、ここからヒートアップします。
勘は、経験に基づく根拠が必ずある筈。
そして、失敗しそうと感じる、きっかけや違和感が必ずあった筈。
そのきっかけや違和感を感じた後どーした？

それを放置したから失敗したのでは？！
しかも、違和感を感じるのは1度では無い筈、
ヤバイと気づいた時にはリカバリー出来ない状態だったのでは？！
と、大先輩から突っ込みが...

ぐうの音も出ません....

育成の為とか、なんとか理由をつけたりしますが、
放置していた事には変わりなく....

そして、クライマックスは、

違和感を感じたら、何か勘が働いたら、
それをそのまま放置せず、
それを追求して伝える事、見える化する事がベテランの役目では！

と、大先輩からお叱りを受けました...

しかし、しかし、これは大収穫です。

勘をキチンと伝える。
つまり、伝えられるように考えて行動する。

改めて、具体化し、見える化して、数値化して伝えていく事が
大事だと感じた瞬間であり、今も考え続けています。

その結果、今の2週間毎のふりかえり活動においても、
勘を仮説として数値化する事が可能だ！
という事に気づき、具体化を進めています。