失敗事例公開！！

最近やってしまった失敗をSpeaker Deckに公開にしました！

失敗から学ぶ！（見える化と　ふりかえり）

アサンプションを全く疑えてない失敗事例です。

他人事だとツッコめるけど、自分だと甘々な事が露呈してしまいました。

お恥ずかしい…

改めて資料にしてみると、

失敗事例は分かり易いですが、

対処方法は1つではないので、どう表現するかが難しい…

この点も、もっと勉強が必要ですね。

最近は、資料で紹介している「G+4箱」を書くようにしていますので、

引き続き、事例資料も作っていこうと思います。

思込み設計からセットベース設計へ

最近、デザインパターンの議論がありました。

Aさんは、△というケースでは、Zパターンの設計が良い
Bさんは、△というケースでは、Zではなく、Yのような設計にすべき
といった議論でした。

こういった議論はとても大事ですね。

重要なのは、「Xというケースでは、Zパターンの設計」
の根拠かと。

設計はそのときの環境や状況にも左右されるので、
何を優先すべきかはケースバイケースとなります。

実現する機能面だけを見て、これがベスト！
というのも、もちろん大事ですが、
これは、ある意味で諸刃の剣となります。

それがいつ、いかなる時でも必ず良い！
と思い込んでしまう可能性も高い為です。
TOCでいうアサンプションですね。

私は思い込みが激しいという事もありますが、
自ら幅を狭くする事になってしまうので、
可能な限り複数の回答を持つように心掛けています…
#実際に出来ているかは別ですが…

△というケースでは、
XかYかZパターンの設計が良いといった感じで、
2つ以上の選択肢をもつ事で
状況や環境に応じて選ぶ事が可能となり、幅広がります。

複数の解決案を持つ事、これはいわゆるセットベース開発ですね。
決めつけるのではなく、複数の解決案を比較する事で、ベストの解決策を決める

自身の幅を広げる意味でも、
セットベース開発（この場合はセットベース設計？）は効果的ですね。

セットベース設計で幅を広げましょう！！

数値と明確化

とある計画をしていて、改めて
明確化する上で数値は重要だと感じました。

目指す姿や中間状態、などを具体化する上で数値が無いと
どこまで行っても曖昧な部分が残ります。

ですが、
数値が入ると、現実的なアクションや
現実的なアクションを実施する上での不明点が明確になります。

当たり前の事なのですが、自分自身では気づき難い事なのだと
改めて認識しました。

数値化しないと、曖昧な事に気づけない。
自分では具体化、詳細化しているつもりなので、気づけない。
つまり、思い込みであり、アサンプションですね。

数値化したとたんに、今まで具体化していたのは何だったのだろう！
と思ってしまいました。（つまり、今までの検討が無駄だった！）

しかも、数値はある程度大きくする事が重要だとも感じました。

実現出来そうな数値よりも、大きめにする設定する事で、
見えていなかった部分が見えるようになります。
見ないようにしていた部分にまで、踏み込んでいく必要があるので、
より確実に目標値の達成に近づくと思います。

数値化する。大きめの数値を設定する。
この2点は、昨年から周囲に推奨していたやり方なのですが、
自分では気付き難い事なのだと、改めて認識しました。
さて、自分で気付く為に、どうしたら良いものか…

事実を分ける事に気づく

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

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

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

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

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

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

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

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

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

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

プロセス思考の弊害

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

決断の積み重ね

ソフトウェア開発においても
事実を積み重ねようと取り組んでいますが、なかなか積み重なりません...

事実を積み重ねて、中間状態を達成し、３ヶ月後の目標達成する
というシナリオで事実を積み重ねようとしているのですが、
それなりに中間状態を達成していく場合でも、
事実の積み上げになっていない感じです。

イメージの問題かもしれませんが、
現状は、事実を元に決断を積み重ねている感じです。

よくよく考えてみれば、それは当然の事で、
これまで事実を上げる事も
明確な状態定義もする事なく、
大きくはプロセスに従って行動してきた為、
思考錯誤しながら事実を上げたり、明確な状態定義をしている状態です。

こんな状態では、積み重ねるどころではなく、
なんとか、具体化する事で状態を明確にして、事実をひねり出し、
それを振り返って修正している状態です。

修正出来ていれば、積み重なっているとも言えると思いますが、
まだまだ横道に外れる事も多く、重ねるイメージにはほど遠い感じです。

しかしながら、こんな状態でも、決断を積み重ねてはいる気がするので、
決断の軌跡を後から見ても分かるように、かつ簡単に残せないかと考え始めました。

多くは、気づきから決断している筈なので、
この2つをペアにして、分かり易く、かつ簡単に残せるのが良いのですが...

TOCでいえば、アサンプションを疑って得た事、それにより決断した事を残したい。
現状では、アサンプションは書き出しているが、疑った結果は残せていない。
アサンプションを記載するフレームを変更する事で残せるだろうか...

具体的な例を元に考え直す必要がありそうです。

仮説検証とアサンプション

ソフトウェア開発現場での改善策（仮説）を
検証する為にFRTを活用しています。

検討したインジェクション（改善策）でDE（改善された状態）となる事
を仮説として検証するのですが、
検証する為に、インジェクション（改善策）の
アサンプションを「なぜならば」の続きを記載する形にして
書き出し、書き出されたアサンプションを疑う事で検証します。

疑うのですが、
アサンプションが出る事で、他のインジェクション（改善策）も検討可能となります。

疑うよりも、他のインジェクションを検討する方が
建設的で前に進めやすい気がしています。

疑うと、それを確かめる方向となるので、
前段階の仮説検証が必要となってきます。

こうなると、最悪は、更に前段階、更に前段階
と深くなり、結果的に何がなんだか分からなくなってきます。

アサンプションの大きさにもよりますが、
多くは他の策を考える方が自然かもしれません。（現在実験中）

これって、考えて見ると、リーンのLAMDAでもあり、
セットベース思考でもありますよね。

不確実な事には、LAMDAやセットベースが有効な事が
ここからも見えてきます。
それをフレーム化するには、TOCのツリーがハマるという感じでしょうか！？

更には、LAMDAやセットベースを考える上では
アサンプションが有効という事も見えてきます。

リーンをフレームワーク化するには、TOCが有効
という事にもなりそうです。
このあたりを意識しつつ、今後も実験を進めていきます。
 

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

アサンプションと羽生さん

今年もSWEST参加しました。

今回のSWEST18では、
TOCの可能性をまたまた感じました。
一言でいうと、アサンプションを破壊してイノベーションを創出する！
というアプローチなのですが、
この話を聞いていて、よくよく考えてみると
世の中はアサンプションだらけだな
と感じました。

アサンプションだらけ！
と思うと、TOCの活用範囲が広がるのは必然ですね。


そして、セットベース思考を定着させるヒントがありそう
と思って読んだ『捨てる力』にも「アサンプション」が...

「ある程度の知識や経験はプラスに働く事もあるが、
　反対に先入観なしに物事を見る事が難しくなってしまう事もある」

まさしくアサンプションですよね。
そして、羽生さんは、
このアサンプションを打破する為に何をするのか？！

それは、
「思い切って自分の経験や知識を捨てて考えること」

だそうです。
さらっと書いてありますが、
とても難しいですよね。

ですが、新しい発想得る為に、自分を大きく変化させる為に
未練は残る事もあるが、思い切って捨てる！

との事です。

勝つために変化し続ける
という事なのでしょうが....
ますます難しいぃぃって感じますね。

社内でもアサンプション活用は少しずつ広がっています。
これを打破し続けて、
開発を成功し続ける為にも、深化し続けたいですね！