自分の事は見えていない...

必要条件から因果関係への変換が難しい！

最近、ずっぽりとTOC漬けです。

先日、3つのクラウド（ジレンマ）からコアクラウドを作成し、
そこから、更に中核問題行動を導き出す！　筈でしたが、

一筋縄ではいかず、
かなりの回数、行ったり来たりを繰り返しています。

必要条件（コアクラウド）は完璧と思っていたのですが、
必要条件を因果関係にすると矛盾がある事に気づくのですから、
必要条件に矛盾があるという事になります。

つまり、必要条件は満たせていない...
自分の事は見えていないのだと痛感します。

一度矛盾が気になると、更なる深みに入ってしまう感じです。
見ようとしていないのか、決めつけているのか、
どうにもスッキリしない状態で、時間だけが過ぎていきます。
しかしながら、この考える時間がとても重要なのだと思います。

必要条件から因果関係にするだけで、矛盾が一目で分かる感覚は
ちょっとした不思議体験でした。
視点が変わるので、当たり前といえば当たり前ですが、
視点を変える難しさを感じずに簡単に出来る感じでしょうか。
想像以上の効果を体感出来ました。

単体テストと理想のサイクル

最近、社内で単体テストについて話題となり、
過去の資料をあさってみました。

eXtreme Programming の白本を読んでから
単体テストにハマり、取り組みはじめてから20年弱くらいでしょうか。
2002年の資料に久しぶりに再開し、少し感動してしまいました。

取組み始めた当初はテクニック的な内容が多いですが、
徐々に考え方的な内容が盛り込まれているようです。

そこで、いま資料を作成するなら、
何を伝える資料に仕立てるか？！

と考えてみました。

リボンモデルと同じで単体テストを中心としたサイクル
ですね。

単体テスト以外（結合テストなど)で検出された不具合、
及び危険性のある構造を発見した際に
それらの再発防止の為に、単体テストに引き上げる
単体テストに引き上げる為にリファクタリングする
というサイクルです。

リファクタリングは構造を良くしていく為、
良い構造を維持する為、という事は比較的言及されている気はしますが、
継続的に単体テストに引き上げる（より上流工程で検出可能にする）
事は、あまり言及されていない気がします。

良い構造にする為の1つの例でしか無いのですが、
常に単体テストで検出可能に出来るか？！
と問い続ける事は、とても重要なポイントだと思っています。

曖昧な表現と事実とデバッグ

問題表現も改善成果の表現も事実を示す事が重要です。
ですが、なかなか事実が表現出来ません...

「多い」、「少ない」、「増える」、「減る」、「早く」、「遅い」
などは、当たり前ですが曖昧な表現ですね。

「多い」であれば、
具体的にどのくらい多いのかを明確に示す為に数値を入れる。
更に何に対して多いのかを明確にする。
こうする事で、誰もが同じ認識となる事実として表現される。

これも当たり前な事だとは思いますが、

意識しないと、問題提起や改善成果の表現は
ついつい曖昧な表現になってしまいます。

癖ですかね...

今は、2段階で変換しています。

まずは曖昧表現で見える化し、

自分で「具体的に！」とツッコミを入れて数値を入れる。

ソフトウェア開発（特に受託開発）では、

事実を意識する機会が少ないのが原因かと思っていたのですが、

考えてみると、デバッグ時は発生する環境や症状、その時の状態

など、事実を集めて原因を突き止めます。

つまり、事実を意識しています。

新人さんがベテランに「たまにエラーとなります」

などと報告すると、
「”たまに”ってどういう事？」
「エラーってどんなエラー？」
と突っ込まれる光景は良くありますよね。

まさに曖昧表現を無くすように指導していきます。

となると、ベテランは曖昧表現などしない筈！

ですが、問題表現となると別なようです。

私含めて、曖昧な表現だらけ....

なぜでしょうね？？？

なぜかは、分かりませんが、

癖では無く、出来る筈！　ですね。

繰り返しは簡単？

先日、FRT(未来構造ツリー）を作成していて、
繰り返す、継続する
といった事をFRTで、どのように表現するか？！

という議論になりました。

しかしながら、表現方法より、
本当に繰り返し？
本当に同じ事を継続するの？

繰り返しや継続で本当にDEが達成されるか
と、疑い始めました。

中間状態として明確に、ある指標や数値が確実に良くなる
繰り返し、継続であれば問題無いとも思うのですが、
ただ繰り返すだけで良くなる事って、あまり無い気もしています

繰り返す、継続する為の「何か」が常に必要な気がします。

実は、繰り返しているようで、繰り返していない。
継続しているようで、継続していない。
そんな事も多くありますよね。

FRTを見直す観点として、
徐々に、着実に良くなっていくツリーとなっている事
はポイントかもしれません。

ナラティブは未来を変える？

最近、ナラティブに関する記事や論文などを読んでみましたが、
未来に向かう感じがとてもしっくり来ています。

しかし、その一方で、ちょっと不思議な感じがします。

それは、ナラティブは過去を語るのですが、未来が変わる。

過去を語る事で、過去の出来事の意味づけが変わり、
意味づけが変わる事で、価値観が変わるので行動が変わり、未来が変わる。

とても納得するのですが、やっぱり不思議です。
過去を語るだけ！　なのに、未来が変わる！

という感じです。

語るだけ！ではなく、語る事による効果で未来が変わる
という事なのだと思うのですが、

その効果が分かり難く、見え難いものなので、
不思議感が払拭出来ない感じです。

どのように認識すると未来が変わるのか？！
どのように意味づけが変わると未来が変わるのか？！

実際にやってみないと分からない気がしますので、
試してみながら、平行して勉強していく必要がありそうです。

量の数値化

ハカるのは嫌いなのですが、
見える化するには、数値化が必要な事もありますので、
数値化出来るものは、数値化して、
ハカる事を推進しています。

具体的には、
2週間後の目指す状態と、その達成条件を定義するのですが、
達成条件として、数値化する事を推進しています。

このような数値化をお願いすると、
必ず達成しなければならない　という意識が大きく働き、
なかなか数値化出来ないようです。

ここでの数値化は2つの意味があります。
1つ目は、やる事を具体化する為の数値です。

何をどのくらい作るのか、といった量を数値化するだけでも、
大よその内容が見えてきます。
これを事前に擦り合わせる為です。

例えば、ある状態を達成する為に課題リストを作成する場合、
いくつくらいの記載項目のリストに、何行埋めるのか
といった数値が見えてくると、自身でのセルフチェックにもなり、
チーム内でのより具体的な認識合わせとなります。
また、セルフチェックする事で、
この数値を達成する為の必要な行動が発見出来たりする事にもなります。

2つ目は、確実に前進している事を見える化する為です。
課題リストでいうと、達成条件を「課題10個入力」とした場合、
もし、結果が3であっても、確実に前進している事が分かります。
ゼロでなければ、確実に前進しています。
なぜ、3個だけなのかを追求するのではなく、
次は、5個にする為に、どうすべきかを考えます。

可能であれば、質も数値化したいところですが、
まずは量からでも、得るもの（気づき）はあります。

強制せずに...

改善活動は何かと後回しにされがちですが、

後回しとならない、必要な事に置き換える事が出来れば、

そもそも強制する必要がなくなります。

それを自然に促せると完璧ですよね。
先日、促す感じがちょっと掴めるような事がありました。

この経験をふりかえってみると、
キーワードは、
・実施する人達が興味のある事
・準備不要で、すぐに出来る事
・結果がすぐに分かり、分かり易い事

改めて並べてみると、当たり前な気がしますね...
しかし、このキーワードを引き出して揃えるのが、なかなか出来ない
という事が分かりますね。

今までは、
後回しになりそうな時は、3つのポイントを押さえたアクションを
どんどん提案していた気がします。

しかし、そうではなく、
やりたい事、興味のある事を具体化して、
やってみたいと思うよな事まで落とし込む。

落とし込むところを良く分からないフリして
促せると良いのでしょうね...