身近なものからハカる

最近、お気に入りの言葉です。
「身近なものからハカる」

昨今のソフトウェア開発では、静的解析ツールがだいぶ進化し、
ツールの種類も選べる状況にありますが、
そんな状況でも、あまりハカる習慣は無い気がします。

日々の業務において、身近な事、物をお手軽にハカる事で
当たり前ですが、現状が見える化できます。

そして、もう一つの鍵は「量」です。
「質」をハカるのは難しいので、まずは「量」からハカる。

しかしながら、量も細かくなっていくと、質に近くなります。

例えば、ドキュメントの量を測るとして、
最初は、大まかなページ数から宣言し
徐々に、ページ内の記載項目数や表や図などと
細かく宣言していけば、
1ページ内の項目数が分かると、1項目の大まかな粒度が分かります。
粒度は質に関係します。

正式なドキュメント以外でも、ちょっとした調査でも
メモ程度は残す事が多いと思います。
すると、それはドキュメント同様にハカれます。

メモを残さない場合でも、何をどのくらい調査するかは
ハカれると思います。


更に、それを宣言すると、より多くの気づきを得らると思っています。

身近な事、物の量を宣言して結果を比べる。

今日は何をどのくらい作成する
と宣言し、結果、どのくらい作成出来た　
とふりかえり、結果を検証するのではなく、次の宣言に生かす。

これを繰り返すと「量」の意識が徐々に「質」になっていくと考えています。

質を意識する為にも、
身近なものから量を宣言する！

起きた事（事実）を言葉にするには？

状態と行動を分けるには、どうすれば良いかを考えている中で、
起きた事（事実）を捉える事が、一つのキッカケになると思い始めています。

その理由は、状態がそのまま、成果、結果と結びつけてしまい、
結果が出ない、成果が出ない事（つまり査定が悪くなる事）
を回避したい思いから、
成果、結果が出し易い行動だけを意識してしまう。
と考えたからです。

昨今は技術者のステータスみたいなものが、あまり無いのでしょうか？！
忙し過ぎて、そんな事を語り合う場も時間も無いのかもしれません...

結果や成果ではなく、起きた事（事実）を捉え、
そこから気づきを得る。
その為には、起きた事を言葉にする、表現する事が必要なのでは？！

その為には、言葉にする場、表現する場が必要ですね。

朝会などで、そんな場が作れると良いと思いますが、
いきなり「昨日、やった事ではなく、起きた事を話そう」
といっても、なかなか難しい気がします。

恐らく「やった事（行動）」を話す癖が出来ている気がするので、
難しい気がしています。

もっとワクワクするような仕掛けが必要では？！
と考えると、アイスブレイク的なアプローチが思い浮かびます。
しかし、毎日アイスブレイク？！
という疑問も...

などと考えながら、ネットをうろついていると、
Good&New　なるものを見つけました。
米国の教育学者ピータークラインさんが提唱している
アイスブレイク、チーム活性化の手法という事です。

日本でもいろんな方が紹介していますね。

フューチャーマッピングでも登場するクシュボール
そろそろ必要なのかなぁ...

見える化の違い

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

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

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

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

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

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

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

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

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

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

とか

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

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

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

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

勘の見える化

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

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

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

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

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

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

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

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

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

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

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

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

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

事実を分ける事に気づく

前回、A3作成に時間がかかっている事を紹介しました。
時間がかかっているのは事実を中心にまとめる事が出来ず
何度も修正する為なのですが、

指摘する前に、事実を中心にまとめる事が出来ない事、
これまで、いかに事実をもとに考える事をしていなかったか
という事に気づく人も出てきました。

こういう瞬間があると、活動を継続して良かったと思います。

そして、不思議な事に、こんな瞬間に閃きも生まれます。
事実を分ける事もせずに、ただただ、やった事を記載してしまうのは
まさしくプロセス思考の強さでは？！　との仮説がふっと湧き出てきました。

プロセスを実施していけば、成果となる。
という思い込みというか、習慣、慣習が、資料にも表れ、
とにかく、やった事を記載する。

やった事（行動、プロセス）は、結果、成果に必ずつながっている筈
というアサンプションだと思うのですが、
最近は、このアサンプションは癖の域となっていて、かなり根深い気がしてなりません。

繋がっている理由や根拠を明示していれば問題無いと思うのですが、
明示している事はとても少ない気がします。

しかし、それがA3を作成する事で気づく人もいる
この事実は勇気となり、モチベーションとなりますね。

恐らく、A3だけで気づいたのではなく、
それまでの布石があっての気づきかと思います。

このような人を増やす為に、もらった勇気を力にして
地道な布石活動を継続しつつ、
気づける仕掛けをもっともっと考えていく必要がありそうです。

やっぱりA3は難しい？！

ふりかえり活動の3ヶ月の結果をA3プロセスとして
A3一枚に記載する各項目をパワポの各スライド一枚にまとめています。

やった事をまとめるだけなのですが、
A3をまとめるのには時間がかかっています。

パワポにした事で、比較的前半（背景から目標まで）
は、比較的早く、順調に仕上がります。
問題は、この後ですね。
一枚になっていないからか、各スライドが繋がらない...

恐らく「やった事」を書いてしまうので、繋がらない気がしています。

アクションした結果（事実）を中心に
ストーリーとして繋げる必要があるのですが、
どうしてもやった事を中心にまとめようとしてしまう...

そう考えるとA3が難しいのではなく、事実を中心にまとめる力の問題？！
なんとなく他の資料も同じ傾向がある気がしてきます...

ですが、A3にまとめる事で3ヶ月が見えてきます。
新たな気づきも多くあります。

ここがA3の魅力ですね。
現状では時間はかかりますが、やる価値は十二分にあります。

慣れてくれば必ず早く書けるようになるので
しばらくは辛抱ですね。

プロセス思考の弊害

本来のプロセス思考とは違うと思うのですが、
ソフトウェア開発において、手順（プロセス）が染みついていると
弊害がありそうです。

問題解決などでは、
How思考から脱却する必要がある事は広く知られていると思います。

ソフトウェア開発では、
そのHow思考が更に手順として積み重ねられ、
開発プロセスとして定義されているように感じます。

もちろん、各プロセスの目的、インプット、アウトプット(成果)や
質に関する指標値などが定義され、それがチェックされていれば問題はありませんが、
ほとんどがプロセスとして、行動や手段だけが分岐の無いフローチャートのように、
ただただ実施されている気がします。

このような状態では何も変わらないし、価値創造は程遠いですよね...

このように行動や手段が独り歩きしている事で、
2つの弊害があると考えています。

１つは、気づきを得れない

TEFCASを活用して、事実(Event)を上げて、気づき(Feedback)を得る
という、ふりかえりを実施していますが、
事実から気づきを得る事が課題となっています。

当初は事実を上げる事が課題となっていましたが、
これは予想していましたし、ある程度対応策は考えていました。
そして、事実が上がれば、気づきは自然と得られ、そこから改善が回り出す。
と簡単に考えていたのですが...

そう簡単には行かないようです。
気づきが無いので、何も変える必要が無く、
ふりかえりの時間がムダに感じる　という悪循環となります。

2つ目は、状態定義が手順になる

気づきを得る為に、How思考から脱却する為に
FRTを活用して細かく状態定義をしていく事をTEFCASと合わせてやっていますが、
なぜか定義した状態が手段や手順となります。

状態が手段や手順なので、
ふりかえりでは、出来た出来ないといった、OK/NGの結果となってしまい、
このケースでも気づきが得れません。

この2つの弊害は、プロセス（手順）ありきの思考によるものでは
と考えています。
プロセスを疑わない、思い込みであり、アサンプションかと思うのです。

こんなところにもアサンプションが？！
という感じですが、さて、このアサンプションをどう打破していくか！？
手掛かりはまったくありません...