身近なものからハカる

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

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

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

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

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

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

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

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


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

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

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

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

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

見える化の違い

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

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

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

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

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

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

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

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

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

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

とか

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

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

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

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

道具とタイミングと...

TOCやリーンには様々な道具があります。
これらを自身で使うの比較的容易ですが、

他人に、これらを提供するタイミングは非常に難しい...

タイミングを間違えると、間違えた使い方となり、
効果が無いなら影響も少ないですが、最悪の場合はマイナス効果となりかねません。
そして、更には、その道具の印象が最悪となります。
正しく使えば、効果はあるのですが....

これらは、全て見えない、見え難い事
が起因して起こるのかと考えてみました。


大工道具で考えると
切る、叩くなどでは大きく間違える事は無いですが、
具体的な「叩く道具」の使い方としては、間違える事はあるかもしれません。

より正確に叩く為に
より綺麗な仕上がりにする為に

など、目的により正しい使い方があると思います。

こちらも目的を明確にしていないと、ただ叩くだけの動作となり、
結果的に、釘が曲がったり、自身の指を叩いたり...
とムダが生じて、最悪は事故となる。

この点は、ソフトウェア開発でも全く同じですね。
見え易い、見え難い、に関係無く、
目的を意識して正しい使い方を考え、動作や考え方を修正していく。

では、見え易い、見え難い
が関係するのは、
他人の動作から学ぶ事が難しい点か！？

とも考えましたが、
これも違いそうです....

匠の動作、及び目的って
動作をまねる事はもちろんの事、理解する事も
とても難しい気がします。

ただ、結果が違う事だけは、見える事で分かり易い。
というより、これ以上の説得力はないですね。

結果が圧倒的なほど、
その結果から、動作、目的を考える事は比較的、容易なように思います。

更に、そこから動作をマネた時に、そのマネた動作を比べる事
も容易に出来そうです。
比較した結果の違いも見えるので、分かり易いですね。

見え難い事が起因して
このような段階を踏む事が難しい！
という事になるでしょうか。

そして何より問題なのは、ソフトウェア開発の「結果」が見え難い点ですね。
ここから始まるのに、
ここを圧倒的な結果として見せる事はとても難しい....

結果が明確で、圧倒的な説得力のあるものとして見せる！
う~ん...また悩む日々が続きます....

見える化はまず未来にフォーカス！

不確定要素の多く、状況変化の激しいソフトウェア開発
故に、見える化が進化しないのか、
見える化しないから、何も変わらないのか....

2年目となる本質思考道場にて
不確定要素の多いソフトウェア開発での改善方法が見えてきました。

そして、改めてアジャイルやリーンのやり方が理に適っていると実感します。
なので、似たような事が既に体系化されているかもしれませんが...

ポイントは見える化！
しかも、現状の問題をフォーカスするのではなく、
まずは未来にフォーカスをあてます！

不確定要素が多く、見える化が進んでいないソフトウェア開発では
見える化していないので、誰もが見て分かる「事実」が非常に少ない事が多い
これが、現状の問題の特定や原因特定する上で、大きな障害となります。

問題の本質を！　といっても事実が少ないので、とても時間が掛かります。

その為、問題は軽めに共有して
目指す姿や、目指す状態を共有し、定義します。
今のところ、TOCの簡易FRTを作成するのがベストな感じです。
（FRTだと、FRTがそのままスケジュールになります！）

すると、ここから問題が見えてきます。
問題が見えてくれば、あとは目指す姿や状態に向かって行動するのみ！

行動した結果の見える化では悩む事も多くありますが、
目指す姿は共有出来ているので、そこに向かって
能動的に見える化を進める事が出来ます。

問題点の見える化となると、後ろ向きになりがちですが、
この手順で進めると、不思議なくらい自然と見える化を進める方向に流れていきます。

まだまだ事例は少ないですが、
行動喚起のポイントは抑えられている気がしています。

五輪書の水之巻にある
「遠きところを近く見、ちかき所を遠く見る事」
という感じですね。
「遠く」を先にしている点には、重要な意味があったりして！？

見える化と活性化

最近、見える化する事の重要性が、やっと分かってきた気がします。
これまでも、見える化が必要だとは思っていましたが、
恥ずかしながら、その重要性には気づいていなかった気がします。

今頃？！という感じですが、ソフトウェア開発では、見えない事、モノが多いので、
難しいし、ムリな事もある！　と決めつけていました。

ですが、これもアサンプション！
決めつけてはダメですね...

見える化する事で、コミュニケーションが活発になる
というより、コミュニケーションの質が変わる
という印象を受ける場面を何度か体験しました。

主に、本質思考道場で
TOCのクラウドや、未来構造ツリーの作成を支援している時なのですが、
書き出してあると、余計な事を議論せずに、
そこに集中出来る為に、質が変化する感じがします。

疑問や問題点もそうですが、
ちょっとホワイトボードに書くだけで、書かない時より議論が活発となる気がします。

という事は、
見える化した事、モノにより何かが活性化する筈！？
逆に、活性化したいのであれば、見える化すれば良い！？

という仮説を元に
ネットをふらふらしてみると、そんな書籍も多くあるようです。
他の人が実践している、実践してきた「見える化」を
もっともっと勉強する必要あり！

と、今更ですが、気づかされました。