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

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

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

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

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

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

癖ですかね...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なぜでしょうね？？？

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

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

アジャイルはCool過ぎるぅ！！！！

最近、またアジャイルが凄いと思う。
XPはやっぱりすごい！　と以前も思ったが、

いま、改善を進めていく中で、
アジャイルはとても軽くて確実に成果の出るやり方（考え方）だと
強く感じている。

改めて「アジャイル宣言」を見て納得する（何度も納得している...）

ドキュメントに関する考え方も書く事による弊害を上手に避けている気がする。
ドキュメントが無くても
問題が起こらないように、メリットがあるように工夫をしている。

それが「プロセスとツールよりも個人と対話を」かと思います。
こう考えると、ここのツールにはドキュメントも含まれている気もしてきます。

当然必要なドキュメントは作成するのですが、
「必要なもの」の判断基準が何か？　が問題ですよね。

価値あるソフトウェアを早く提供する為に必要なドキュメントは作成する　
という事ですよね。

常に不要なものは何かを考える。
常に価値あるソフトウェアを早く作る事に集中する。
結果的に、そこ向かわない全ての無駄が排除される。

更に、アジャイルはプロセスやレビューなどの形骸化をも
上手に回避していると思うのです。

形骸化すると、何も考えずにプロセスを実施する事が目的となる。
形骸化とドキュメントは強い関係にあり、
ドキュメントに頼らない事、細かいルールを決めない事で、
無駄の発生源を上手に断っている。

とヒシヒシと感じています。

そして、なんともカッコイイのが、
このような事をウダウダと語るのではなく、
「常に価値あるソフトウェアを早く作る事に集中する」
とシンプルに表現している事！　

多くを語らずシンプルに宣言している事が、
たまらなくカッコイイ！！！

本家フューチャーマッピングを体験

ついに本家フューチャーマッピングを体験出来ました。

最大のメリットは2つでしょうか
①短時間でお手軽にメタ認知出来る
②短時間で苦しまずにアサンプションを超えられる
　（アサンプションを出さずにサンプションに対する対策が出る）

メタ認知もそこそこ時間がかかりますし、
アサンプションを出さなくて良いのは
最大のメリットかと思います。

アサンプションを出すのに苦しみますし、
最悪の場合は自分を否定する事に近い場合もあるので、
この2つを1,2時間で出来るのは、最強と言えそうです。

苦しまずに短時間で、というのは他には無いのでは？！
と思います。


メタ認知の効果が大きいと思うのですが、
メタ認知により、アナロジーのようなアブダクションのような
ストーリーとの無意識なマッチングがなされ
結果的に、アサンプションを出さずに思いもよらない解決策が出てくる
という感じでしょうか。

アサンプションを出さないので、
苦しい思いをする事も、自分を否定する事もなくてラクで良いのですが....

それで良いの？！
という感じもします。

解決策の理由づけ、因果関係は明確にしておきたいところですが
解決策が出れば、すぐにでもやってみたいと思っちゃいますよね。

それで期待する結果がでなければ、TEFCASでAdjustすれば良いのですが、
ここは、ちょっと危険な感じです。
そこまでしっかりと実行出来るのかが大きなポイントとなりそうです。

実施するには、実行計画をFRTとして作成し直すのが安全な気がします。


そして、鍵は課題と期間の設定ですね。

どちらも同じく、課題が曖昧だとマップもブレます。
期間の制約も無いと無理なゴールを設定してしまいそうです。

更に、今回は、ポジティブな行動のみが出ていましたので、
現場では、ネガティブな障害や課題なども出させると、
よりアサンプションに近くなり、
ポジティブな行動の根拠にも繋がる気がしています。

いずれしても、
メタ認知したアクション設定と、明日からの行動に結びつけるには
今まででは最強のツールと言えそうです。
 

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

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

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

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

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

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

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

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

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

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

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

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

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

6時に帰る仕事術とカンバン

最近、「6時に帰る」、「定時に帰る」などをキーワードに
書籍をあさっています。

もちろん、図書館を最大限に活用しています。

あさった中の１つ
『フィンランド流　6時に帰る仕事術』

で、なんと「トヨタのカンバン」についての記載がありました！

しかも、ソフトウェア開発に導入した事例の紹介でした。
これが、6時に帰る仕事術の1つとして記載されています！

考えてみれば、当たり前で、
あさったどの書籍も、ムダを省く事で6時に帰る事を実現する内容が多く、
ムダを省く為の具体的な工夫や
時間に対する考え方、取り組み方などの紹介が主なので、
本質的には、トヨタ方針と同じ「現場改善」です。

ですが、このような書籍では、ソフトウェア開発に関する例の紹介は
ほとんど無い印象があるのと
本質的には同じでも、具体的な生産系のトヨタ方式との接点がある事は
全く予想していなかったので、少し驚きました。

しかも、「考える」事から始めて、残業が減ったのはもちろんですが、
職場が活発化された効果の方が大きい　

と紹介しています。

強力なトップダウンで実施されたらしいのですが、
結果的には、やらされ感のある改善ではなく、
活発化したポジティブループ＆反対者にも伝染となる改善となったようです。

数値データよりも、
職場の活性化、活発化は大きな原動力、影響力となる！
って感じですね。

その他、フィンランド流は、共感する事が多くあり、
お勧め書籍の1つになりそうです。