キャラ設定がカギ：TOC+全脳思考

未来からの現状把握やってみました。

3ヶ月後の目指す姿、なりたい姿を設定し、
今から、3ヶ月後の目指す姿になるまでの波乱万丈物語を作る！

手法としては、TOCのUDE、DE、FRT(状態を設定するだけの簡易FRT)
全脳思考のフューチャーマッピング（こちらは本を読んだだけですが、ぶっつけチャレンジ）
を使いました。

まずは、毒出し含めたグチ＆UDE出し。
UDEの厳密なチェックはせずに、とにかく吐き出させる

次に簡易FRTの作成
3ヶ月後の「なりたい姿」、「目指す姿」を設定し、
そこから、1ヶ月後、2ヶ月後を設定する

プロジェクトの状態により、1ヶ月後から設定し、
その後2ヶ月後、3ヶ月と設定した方がスムーズな場合もありそう

次に1ヶ月後を目指したTryとその予想結果（仮説、仮説Event）を設定

ここで区切り。
ここまでの結果は1枚の紙に付箋紙でペタペタ貼ってある。

その後、フューチャーマッピングの作成
いろいろ考えましたが、やり方は書籍には従わず、ところどころ変えました
ですが、チームの状態に合わせて、やり方はスタンダードからフルカスタムまで
臨機応変に対応していきたいと思っています

まずは、キャラ設定
例を3つほど提示し各チームでチーム全員が知っているキャラに設定する

次にFRTに設定した3つの状態を
マップの各3ブロックに当てはめて、サブタイトル、概要を記載

次に、記載した概要やタイトルを元に、
ストーリーを考えつつ、予想される波乱万丈の線を記載

次に、変化点に起こりそうな障害や問題を記載

次に、全体ストーリーを作成し、書き込み

ここまでを1枚の紙に書き込み＆付箋

最後に、2枚の図を見直し、調整＆修正

ここまでで、各45分弱ずつで90分弱で全て終了
2チーム合同で実施しましたが、TOCを知っているのは一人だけ
ほぼ全員が、ここで活用する手法は一切知りません。

で、差が出そうなのは、キャラ設定
ここがスムーズに行くと、ストーリー作成は盛り上がる
割り込むのが申し訳ないくらい盛り上がってました。

キャラ設定に難航すると、その後の線も書けない
で、今回は、無理にキャラ設定せずに、
どんな感じで進みそうかを検討し線を書いてもらいました。

振返って考えると、キャラ設定する方が、俯瞰できている感じがしました。
目指す姿になるまでの障害や対策を、
ストーリーとしてあれこれアイディア（意見）が飛び交う感じです。

意見が沢山出た結果、
最後の見直しでは、キャラ設定したチームは2ヶ月後、3ヶ月後のTryが設定されました。
これだけで、かなりFRTっぽくなります。

結果的に、2つの図は補間し合う感じで、好感触でした。
あとは、振返りで足元（現状把握）が定まる事を期待して、2週間後を待ちます。

失敗を達成する？！

先日、GEの「ファストワークス」の話を聞きたくて、
とある無料セミナーに参加してきました。

顧客価値を中心に
MVPなどによる「学び」を生かす為のサイクルが実践されているようです。

Feedbackを得てそれを顧客価値に繋げる仕組み作り。
「仕組み」というより、「考え方」という感じですね。
現在取り組んでいる本質思考道場とまさに同じ考え方なのですが、
取り組み方が徹底していて、その本気度に圧倒されました。

圧倒される中、今更ながらの発見がありました。
「Feedbackを得てそれを顧客価値に繋げる考え方」
を、そのまま人事制度に取り入れている点です。

新たな人事制度といっていますが、
「Feedbackを得てそれを生かす考え方」を
そのまま取り入れているだけだと気が付きました。
なぜ、そんな当たり前の事に気が付かなかったのか？！

考えてみれば当たり前な感じもします。
個人やチームで価値創造する事がミッションとなるので、
価値創造に繋がる学びや気づきを評価しないと、その先に繋がりませんよね。

これまでは、顧客に価値を提供する仕組みと
個人やチームを成長させる仕組みの人事制度が相反していると感じていたような気がします。

ビジネスそのものが不確実性が高い現代では、
チームや個人の成果も不確実性が高く計画出来ないのが実情かと。
それを無理に計画しても、
『リーンスタートアップ』に記載されている通り、
「計画を忠実にかつ的確に実行する事に成功した結果、失敗を達成してしまう」
事になってしまいますよね。

良いものはなんでも取り入れるのがGEらしいですが、
当たり前の事にも気づいて、それも当たり前のように取り入れていく点も流石ですね。

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

また出会いが！

前回のブログを書き終わり、

社内ブログを記載する為に、とある古本屋に行くと、

なんと！？

やはり、前回のネタは体系化されていた！

https://www.amazon.co.jp/dp/4478008361

この中には「TEFCAS」という方法について記載されていて

更にそれを補完する「全脳思考モデル」により強力に結果を出す方法として提唱されています。

私は「TEFCAS」も「全脳思考」も全く知りませんでした。

「TEFCAS」は脳が本来持っている特性を最大限に生かす方法という事なので、

意識している事はほぼ同じですが、TEFCASは想像以上に強力なアプローチのようです。

「TEFCAS」を簡単に紹介すると、

Trials（Try-alls）：思い付く小さな実験を全てやる

Event：小さな実験の結果（事実として捉え、成功／失敗とは捉えない）

Feedback：結果から成功に到達する為のインプット

Check：インプットの信頼性をチェック

Adjust：目標実現に向けての調整

Success：具体的な成功イメージ（脳へのインプットであり、ここが起点）

という感じです。

Eventのところがまさしく悩んでいた事で、

失敗と受け取らせる事が良いのか悪いのかを、今年の4月頃から悩んでいました。

「失敗」の捉え方が人により違うと思うのですが、

TEFCASでは、成功、失敗で一喜一憂するのではなく、

目標達成へのインプットとして捉える事が重要との事ですので、

純粋にインプットとして捉えるには「成功」も「失敗」も言葉としては使わない方が良い

という事なのでしょうね。

サッカーの名将の言葉から「思考」の違いを次のように表現しています。

『名将は未来に勝利することから逆算して現在の事象の意味を自分に問う。

　それに対して、多くは現在の事象の成否を延長して未来を調整してしまう。』

過程（試合中）では、成功も失敗もなく、何があっても

最終的な結果（試合終了時）を成功（勝利）に導く考え方

という感じでしょうか。

これから、これらの事も取り入れて少しずつ実践していく予定です。

この出会いに感謝！

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

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

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

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

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

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

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

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

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

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

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

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

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

見える化と活性化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と紹介しています。

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

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

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