ティール組織

とんでもなく売れているのですね。
なぜでしょうか？？？？？

って感じですね。

『ティール組織』

気になり、購入しちゃいました。
まだ、野中さんの『直感経営』も読んでいる途中なのですが…

読んでみると読み易くて面白いです。
まだ半分くらいですが、夢中になって読んでしまいます。

アジャイルの実践でこれまで感じていた事などが
論理的に整理されていたり、痛快に表現されていたり
で、楽しいです。


ここまでで印象的だったのは、
オランダの地域密着型の在宅ケアサービス組織「ビュートゾルフ」
の例で、とても興奮しました。
この例だけでも、読む価値はあると思います。

成果として、ここまで圧倒的な差が出ると
これまでの組織や管理って何？
と思ってしまいます。

フレデリックさんの言い方では、
進化の過程として必要だったという事になるのかな。

ソフト開発でも圧倒的な成果となると思っていますので、
なんとかソフト開発で分かり易い成果を見える化したいと常々考えていますが…
ティール組織の実現となると、まだまだ先な感じはします。

しかしながら、これだけ売れているという事は、
日本でも、ティールな組織が増えていく可能性はあるのかもしれませんね。

ストーリーの複雑度が鍵？！

先月、久しぶりにセミナーに参加しました。
https://www.ogis-ri.co.jp/event/1273267_6738.html

CI&T社ではA3が定着している！

ソフト開発会社でA3が定着している会社は少ないだろうと想像していますが、
やっているところはやっているんですね。

昨今はスクラムはやっている！　
は当たり前になりつつありますが、
A3やセットベースをやっている！
という方にはなかなかお会いしません。

そして、メインテーマの定着についてですが、
アジャイル、リーンが定着した大きな要因は、
Business Complexity Point　
との事。

Business Complexity Point　

とは、ユーザーストーリーの複雑度との事

もちろん、相対値ではなく絶対値との事

つまり、見積もりの共通言語を作ったという事のようです。

この複雑度で大よその全体計画を作るという事なのでしょう。

対応工数とのデータを取れば比較も出来ますしね。

結局のところ、全体計画や比較が出来ないと定着しないって事ですかね…

この点がどうしても納得出来ないんですよね。
リーンやアジャイルやるなら計画や比較ではなく、提供価値を見ようよ！

って、どうしても思ってしまいます…
納得出来ますが、納得出来ないんですよね…

結局、管理する側の人達がついてこれてないだけって事だよなぁ
管理する側も今まで通りの管理では通用しない！
と気づかせる必要がありそうですね。う~ん…

TOCシンポジウム2019

時間が経つのは早いもので、
もう先週となるのですね。

TOCシンポジウム2019に初めて参加しました。
しかも2日間全て参加しました。

大きな期待を持って参加しましたが、期待以上に得るものがありました。
大満足です。

アラン・バーナード博士のお話は納得しまくりというか
「なるほど！」感じる事が多くありました。

特に2つの点が大収穫でした。

1つ目は、
我々の注意力がボトルネックとなり、判断ミスを引き起こしている
全てに集中して判断するのは確かに無理ですよね…
集中力がボトルネックだったとは！？　　でも確かに！
という感じでした。

2つ目は、
間違った事をするのは避けれないが、
・正しい事をしない
・正しい事を間違った方法で行う
は、回避可能で、その原因のほとんどが惰性か妥協である

更には、無知も原因の1つとして考えられるが、
それは教育すれば分かる。
教育しても変わらなければ、多くは惰性である

この説明は、とてもしっくりきました。
これまでのモヤモヤがすっきり晴れた感じがしました。
なんでやらないんだろう？？？　と感じる事は数多くありますので…

その他事例も身近というか、
同じ取り組み、同じ悩み、同じ考え
な事が多くあり、親近感を感じつつ
言われてみれば！　そういえば！　そうだった！
といった気づきも多く勉強になりました。

職場に戻り、関係者への展開はもちろんですが、
打合せや雑談の際に引用したりと、早速活用しまくっています！

CCPMとアジャイル（その３）

しつこいですが…もう少しだけ。

道具の使い方のような流れになっていますが、
やはり『管理』の考え方な気がしますね。

改めて、私がアジャイルを始めたきっかけとなった
『エクストリームプログラム入門』
を読んでみると、

12章に「管理戦略」という章がある。
ここでは、XPの原則に従って考えをまとめています。

先日のゴールシステムコンサルティングの村上さんのセミナーと同じです！！

やはり極めた人のアプローチは同じなのだと改めて感じます。

話しを戻して、
ケント・ベックは管理として
大きく、コーチとトラッキングの必要性を説明していますが、
随所にプログラマーの邪魔をしない事という感じの説明が出てくるので、

管理＝ケント・ベックは結局のところプログラマーの邪魔をしない事
と読み取れてしまいます。

ある意味では、何もしない事が究極の管理と言えるかも…

管理として何をするかは棚上げして、
ケント・ベックが言いたいのは、
管理＝プログラマーのパフォーマンスを最大限に出す事
なのでしょうね。

となると、村上さんの解説と全く同じになります。
という事は、
私は、何十年も前に管理が何かを知っていた事になりますね…

『エクストリームプログラム入門』
の最後に、またヒントがある気がしました。

27章に「結論」という章があり、
そこで、変化に備えない事が究極の備えである
と言っています。
全てに備えようとするのは無理なので、逆説的に何も備えない。
準備する事を諦める事が完璧な備えである。という事です。

この考え方がCCPMとの大きな違いなのかもしれません。
恐らく、バッファを準備して備える事が、
しっくりこなかったのだと思います。

最後の章を覚えていた訳ではありませんが、違和感の元はここな気がします。

しかししかし、バッファだけを監視して
バッファに問題がなければ何もしない。
バッファが危険になった場合の備えをしない
という考え方を取れば、こちらも究極の備えと言えますね！

ループに入った感じですね…

CCPMとアジャイル（その２）

前回の自問

価値がある事が大前提だと管理が必要？
価値がある事を疑うと、管理は不要？

恐らく、どちらでも無いというか、
単純に価値がある、無いだけの事では無いのでしょうね。

CCPMは、やはり管理が前提な気がしますね。

そもそもなぜ管理が必要か？
管理って何？
という感じです。

アジャイルでは、やはり管理を不要とするプロセスな気がします。
ただ、要求と価値は管理していると言えるかと思います。
しかも、関係者全員で。
そして、それ以外は管理していない。

本来管理する目的は、価値創造を最大限にする事な気がします。
CCPMもここは同じだと思います。

するとやはり、何を管理するか
が問題なのでしょうか？？？

大きくは今の状況を見える化して、対処すべき事を判断する
のが管理な気がしますが、
アジャイルでは対処ではなく、価値創造に集中している気がします。
これが管理となると、対処となり、
元に戻す（正常状態にする）事に集中している気がします。

ここが大きな違和感の元な気がします。

アジャイルでは
何をするかを決めるだけなので、あまり管理している感じはしません。
だから違和感となるのかもしれません。

CCPMもスケジュールやバッファを管理しているのではなく、
バッファにより変化した状況を把握して、価値創造の為に次に何をすべきかを管理する。
とも言えそうです。

そんな事を考えていたら、
本日、偶然にも「管理とは？」の1つの答えを得ました。
これはまた次回以降で紹介するとして、

CCPMでとてもしっくりくる事が1つあります。
それは「フルキットの」考え方えす。
これはアジャイルにとても近いと思うのです。
そして、CCPMのキーとなるのもフルキットだと思っています。

リーンの安価な実験と同じく、
いまある、もしくは近い将来整う最大限のフルキットで、
何が出来るかを考えて、実践する。

という事は、
要するに道具の使い方って事なのだろうか…

まだまだ自問自答が続きます…

CCPMとアジャイル（その１）

CCPMとアジャイル
知ったのは、アジャイルが先です。

アジャイルを知ってから10年以上たってTOCを知りました。
そして、ザ・ゴールのCCPMを読んだ時は何かが違う気がしました。

なんでしょう？！
バッファという概念は分からなくは無いのですが、
「遅れていい」という感覚が違う気がしました。

あっ、間違えました。今でも違うと思っています。

クリティカルパスではなく、クリティカルチェーンという
考え方も分かりますが、何かが足りない気がしています。

知れば知るほど、
アジャイルに、とても近いようで遠い感じがしていました。

なぜでしょう？？？

何かが確実に違うのです。

先日、ゴールシステムコンサルティングさんの
CCPMセミナーを受講して、
ますますアジャイルに、とても近いようで遠い感じを受けました。
セミナーの内容が悪い訳では決してありません。
ゴールシステムコンサルティングさんとは、これまで共に戦ってきています。
セミナーの内容はとても分かり易かったので、ますます違和感が大きくなったのかも！
しれません。

なぜでしょうか？？？

ずっと考えていたのですが、違和感の根本は「管理」だと思います。
管理しようとするからバッファという考えがある気がします。

アジャイルではバッファという考え方は無いと思います。
なぜか？

恐らく、先の事まで見積もらないからだと思います。
分かる範囲で見積もるからだと思います。
しかも、分かる範囲で、確実に価値に繋がるものだけを見積もるからだと思うのです。

CCPMでは価値がある事が大前提だと思います。
アジャイルでは、価値があるかを疑い続けているのだと思います。
ここが大きな違いでしょうか？

価値がある事が大前提だと管理が必要？
価値がある事を疑うと、管理は不要？

永遠と自問自答が続きそうです…
もっともっと考えてみたいと思います。

つながる快感

”直感”に引かれて衝動買いした
野中郁次郎さん、山口一郎さん共著の『直感の経営』は予想通り面白いです。

なかなか読み進みまないので、最近はもっぱら拾い読みですが、

事例や書籍の紹介なども多くあり、

拾い読みしても面白いです。

そして、なにより今回はいくつかの驚きがあります。

それは、今まで勉強してきた事と繋がったからです。

ここで繋がる？！

という感じです。

驚きましたが、今ではジワジワと快感に変わってきています。

ナラティブ、物語（ストーリー）

アブダクション

美意識、羽生善治、茂木健一郎

ナラティブや、羽生さんにまで繋がったのは快感ですね。

しかしながら、逆の視点で見ると、

全く違う視点からアプローチしたものと自分では思っていますが、

そう、違う事はなく、遠くも無く、実は近い！　

という事でもあるかもしれません。

全ては「考える」が根底にあるので、

当たり前といえば、当たり前なのですが…

繋がった事で、更にまた深くなりそうです。

視野を広げる為に

30年もソフト開発やっていると
なかなか考えなくなります。

長くやっていると「このケースでは、これ」
という感じで、パターン化されているからです。

パターン化しないように、常に、本当に今回のケースでも「これ」？
と疑うように心がけていますが、
考えなくなるのも癖のようなもので、
常日頃は、そうそう疑いません…

じっくりじっくり考えるような難題や、新たなチャレンジなどでは
比較的考える時間を取るので、疑う事も出来ますが、
日常となるとね…

その為、実践しているのは、
複数案とクラウドです。

複数案は、他にどんな方法があるか
と考えるだけなのですが、
他の案が無いかを考えるだけでも、考えていますので、いちおう立ち止まりますね。
考えないよりは、マシですね。

はじめから、セットベース設計をする！
と力まないで、他の案が無いかを考えるようにしていると、
そのうちセットベースとして複数案をしっかり検討出来るようになります。
まずは無いかを考える事から始まる感じですね。


クラウドはニーズや反対の行動からの視点で考えますので、
これまた、考える事になりますので、
考えないよりは良い筈かと。

時間があろうと無かろうと、
今ある時間の中で、常に考える事を「癖」にしたいですね。

ソフト設計にもTOC！

昨今は、何をするにも正解を求めようとする傾向がある気がします。
ツールを使うにも正しい使い方で、正解を求めようとする。

正解とは何？
という感じですね。

ソフト開発の世界では、正解が無い事の方が多いですよね。
もっと良い設計、もっと良いコードと求めればキリがありません。

その為、目的により何かを選択していく事の繰り返しになるかと思います。

品質基準や品質目標に従い、設計コンセプトやアーキテクチャーを選択する
設計方針やコンセプトに従い、抽象化する対象を選択する
などなど

正解という言葉を使うと、
目的により、正解を選択していく、
正解を変化させていくイメージでしょうか。

そして、TOC思考ツールは
選択や目的達成に向けた考えを整理する為、再認識する為に活用出来ます。

設計などでモヤモヤする事があれば、
クラウドが活用出来ます。

UDEには品質目標とのギャップや
現状のメトリクスなどを設定すれば良いかと思います。
現状のメトリクスよりも上げたいのであれば、
現状のメトリクスの値がUDEとなりますので。

新規であれば、前バージョンや似たシステムのメトリクスや
予想される（見積もった）テスト時間や開発期間などでよくある
顧客要求（予算）と見積りとのギャップをUDEにすると、
考えが整理されると思います。

よくあるモヤモヤは、
リファクタリングする／しない
新たな手法や技術にチャレンジする／しない

かと。

それぞれのニーズを考えるだけでも
考えが整理されます。

そして、結果的に考えが視覚化されます。
ツールとして中途半端であっても、使い方が間違えていても
考えが視覚化されるので議論が可能となります。
この効果はとても大きいかと思います。
議論出来る事も収穫であり、議論した結果が収穫となる事もあるかと思います。

TOCは、正しく使えなくても、
収穫が得られる素晴らしい思考ツールですね！
ソフト開発でモヤモヤしている時にも活用してみましょう！

考えるツールTOCその2 逆の行動が視点を変える

前回は、クラウドを使った考え方を紹介しました。

その後、いくつか似たようなクラウドを書いていますが、
改めて、逆の行動を考える事の重要性に気づかされます。

行動としては単純に逆の行動を記載するだけですが、
記載した瞬間から視点を変える思考が開始されます。

更にそのニーズ（図のC）を考えるとなると、
視点を切り替えて考える必要があります。

ここでニーズが思いつかない、出てこない事も多いですが、
その場合は、視点が切り替わっていない、思考が切り替わっていない
感じがしました。

思考が切り替わると、多くの気づきが生まれます。
図として完成しなくても、気づきが得られる事も多いのだと
改めて実感します。

今やっている行動から、逆の行動を考える！
単純ですが、協力なアプローチです！


話しは少しそれますが、
ソフトウェア設計でも複数案考えるセットベース設計は、
これと少し似ている気がします。
複数案＝複数の視点
複数の視点で設計を見る（見直す）事で、新たな気づきが生まれる。

複数の視点から見る事が、検証になり、品質が向上する。
こちらも広めていきたいです。

考えるツールTOC

これまでも普段使い出来るツールとして
TOCを活用してきましたが、

Jonah認定頂いて以降は、質を意識し過ぎて、
中途半端な活用になっている気がしています。

道具は使っていく事で磨かれていく筈ですよね。

あまり「質」を意識せず、
仲間とワイワイやりながら使っていこうと
やっと、最近思い始めました…

と、いう事で、まずは行動してみる。

気が付いたら、書いてみる。
まずは箱を埋めてみる。（クラウドでも4箱でもFRTでもCRTでもでも、何でもね）
埋まらないものはファイルに閉じておく。（いつでも見れるようにしておく）
埋まっても納得いかないものは分かるようにファイルに閉じておく。
納得いくものは、次のステップへ（これもファイルに閉じておいた方が良いね！）

今、展開しているお試しサービスの活用が低迷しているので、
それをクラウドにしてみました。
具体的な内容や数値は出せないので、かなり曖昧な表現ですが…

クラウドの質はさておき…
アサンプションの「ユーザーは好きな時間に試したい」
は疑ってみる価値がありそうです。

だいたい1時間くらいは悩んだでしょうか…
という事で、ざっとでも書いてみる価値は十分にありますね。

ホラクラシー、アンチフラジャイル、アジャイル

アジャイルを勉強していくと、
チームや組織について考えるようになります。

ちょっと前から、
ホラクラシー(holacracy）やティール(teal)、アンチフラジャイル(antifragile)
といった言葉を見聞きする事が多くなりました。

そして、最近、やっと人事評価、人事制度と絡めた話題が多くなってきた気がします。
アジャイルももはや普通になってきましたし、
数値化の難しい開発などの業界全体が進化している気がします。

しかし違和感も…

私が最初にホラクラシーを知った時には、
人事評価とは相容れないと感じました。
それから、人事評価は何故必要なのかを考えています。

そして、最近は人事評価は必要無い気がしています。

過去には、給料の高さがモチベーションになっていた事もあるとは思いますが、
今となっては、モチベーションを引き出すものは、
給料では無いケースも多くなっていると思います。

そうなると、
現状での人事評価は給料の金額を決める為のもの
という事になります。

であれば、給料の決め方を変えれば良い
つまりは、利益の分配方法を変えれば良い
と思うのです。

ふと、本質思考道場の成果報告の際に、
ある人事コンサルタントの方から頂いた助言を思い出します。
道場の成果や評価は、
「人事制度と一緒にしてはダメだ。
　人事制度に組み入れた瞬間から温度の無いものになる。冷たいものになってしまう」

と。

モチベーションには、温度が必要かと思います。
制度は、ある意味で冷たくなる必要があると思います。

やはり、相容れないのだと改めて感じます。
ホラクラシーやティールは、自律し続ける為の仕組みかと思いますが、
自律にはモチベーションが不可欠ですよね。

利益の分配方法を変えるのは、簡単では無いですが、
これまで進化してきたように、
考えていく事で、議論していく事で、実践していく事で進化していく筈です。

更に更に深く考えていきたいと思います。

分かり易い体験の効果

スマートグラスは、どんなふうに見えるのか
体験しないと分からない。
そして、体験しても伝えられない。

とにかく、言葉や映像などで伝えるのがとても難しいのです。

その為、アピールするのがとても難しいです。

となると、実際に体験してもらうのが早い
という事になります。

そして、いくつか仮説検証していくと
体験してもらうと事の効果は想像以上に大きい事に気づかされます。

しかも、より分かり易い体験を提供する事が重要なのだと実感します。

当たり前ですが、分かり易い事は、とても大事ですよね。

とにかく質問が減ります。
話題は、具体的な活用方法となります。


そしてそして、もっと重要なのが
『短時間で体験する』
かと思います。

短時間でないとお互いに負荷となりますし、
短時間であれば、その後の話が弾みます。

リズムだと思うのですが、
テンポよく、リズムよく、体験が終わる事は
その後に繋がると実感した次第です。

これからも、分かり易く、短時間の体験を模索していきます。

勘の見える化②

先日、不具合解析で
こんなやりとりがありました。

Aさん：あるプロセスでバスエラーが2回発生するとプロセスが死にます。
　　　　不具合の原因はXXXXにより、バスエラーが2回発生する事で、
　　　　プロセスが死んで致命的な不具合現象となります。
　　　　1回目のバスエラーではプロセスは死にません。
　　　　2回目でプロセスが死んで致命的な不具合となります。

Bさん：プロセスが死ぬのは、1回目のバスエラーでは？
　　　　2回発生しないと死なないなんてことは無いと思うけど…

Aさん：再現環境を用意して、確認していますが、
　　　　何度確認しても、1回目では死にません。
　　　　別の方法でバスエラーを発生させて確認しましたが、
　　　　別の方法でもバスエラーを2回発生させないと死にません。
　　　　1回目では、コマンドで確認してもプロセスは生きています

Bさん：ログ上でもバスエラーは2回出ているの？

Aさん：ログ上ではバスエラーは1回しか出力されていません。
　　　　でも、バスエラー後もプロセスは生きていて、
　　　　その後も動作ログが出力されています。
　　　　そして、その後に
　　　　強制的にバスエラーを発生させると
　　　　コマンドで確認しても死んでいますし、
　　　　動作ログも出力されなくなります。

Bさん：バスエラー表示が1回だけというのが気になるし、
　　　　2回発生しないと死なないなんて事はOSやソフト制御では
　　　　やっていないと思うけど…

Aさん：でも2回発生しないと死にません…
　　　　

Aさんが嘘を言っているようにも思えません。
Bさんの言っている事も分かります。
ログやコマンドでのプロセス確認は、2人で同じ画面で見ていたようです。
が、お互いに決めてが無い状況のようでした。

事実を整理すると、以下のようになるかと思います。

1）バスエラーはログ上では1回出力される

2）バスエラーが発生してもプロセスはログを出力している

3）バスエラーを2回発生させると、動作ログが出力されなくる

4）2回目のバスエラーはログには出力されない

この事実から、様々な仮説が考えらえれると思いますが

AさんとBさんのやり取りは、続きます。

Bさん：バスエラーが発生しているログをじっくり見たいから

　　　　ファイルで欲しい

Aさん：ログを送りました。

しばらく沈黙

Bさん：ゾンビだ！

　　　　バスエラー発生後、プロセスがゾンビになってる！

　　　　これで2回の謎が解けた！

Aさん：ほんとだ！　気が付かなかった。

2人の主張はどちらも正しかったようですね。

お互いに諦めずに、腑に落ちない点を探求し続けた事で、真因が掴めた

という事かと思います。

そして、Bさんの勘（しっくりこない点）を整理した事で

真因が掴めたとも言えるかと思います。

勘を勘で終わらせずに、追及していく姿勢が大事なのかもしれませんね。

　　　　

演習問題を考える

TOCのクラウド（対立解消図）
の演習問題を考えていますが、なかなか難しい。

可能な限り、新聞やニュースから拾おうとしているのですが、
なかなか演習に使えそう！　と感じるものが少ないです。
まだまだ視点が甘いからだとは思いますが…

最近は、それとも昔から？
新聞記事としても問題を取り上げる
というより、Actionを取り上げる方が多い気がします。

Actionであれば、ツリーの演習ネタにはなり易いです。

TrT（FRT）の演習問題として
以前紹介した通称4箱の演習問題にし易いです。

例えば、パナとトヨタのネタは、そのまま演習問題になりますね。
例えば、最近の銀行の店舗閉鎖ネタも、そのまま演習問題になりそうです。

でも、改めて考えてみると、
上記の例も、視点を変えれば、クラウド問題にもなりそうですね。

クラウドの場合は、
UDEとなり得るものが記事の中に見え隠れしているかが
ポイントになると思っています。
この点が、昨今の記事だと（昔から？）満足出来ないケースが多い気がします。

という事は、
記事を元に演習問題として仕立てる方が現実的なのかもしれませんね。
楽して演習問題を作成したくて、記事をそのまま使えるものが無いかを探していたのが、
そもそもの間違いなのかもしれません…
と、ツラツラと考えを出力する事で、気づきを得た気になります。

ARについて考える

AR（拡張現実）の価値とは何かを考えています。

ARサービスもいくつか市場にはありますが、
現状での活用頻度はあまり高く無い気がしています。

ARの価値は本当にあるのか？！
あるようで無い気がしていて、モヤモヤしています。

単純には、
今まで見えなかったものが見える事の価値はある気がします。
現実と過去のように、
今まで同時に見えなかったものが同時に見える価値もある気がします。
（今現在の街並みに、過去の街並みを重ねて見るなど）
一方で、今まで見えなかったのだから、見えなくても困らないのでは？
とも思います。

恐らく、多くの場合、困っている事は無いのでしょう。
ただ、今までは考えもつかない事が実現可能となる可能性もあるので、
価値が無い訳でも無さそうです。

もう少し具体的に考える為に
思いつく、
今まで見えなかったモノ、コト
同時に見れなかったモノ、コト
とは何かを列挙してみます。

花粉やチリ（空気の汚れ具合？）

未来、過去

人の気持ち、気分

体の中（血管や臓器、臓器の中）

脳、考えてる事、記憶、イメージ

疲れ具合、眠気

重さ、硬さ

味、臭い

風

発酵度、鮮度

微生物

見ようと思えば、見えなくも無いものがほとんどですね。

結局のところ、どのようなシーンで何が見えるか（表示されるか）？

という事かなぁ…

膨大な…を得る為に

前回、前々回に引き続き、ちょっと視点を変えて、
私がTEFCASで気に入っているランキングを紹介します。

No.1：E（Event）
No.2：FC（Feedback、Check）
No.3：T（Try all）

今回は、No.3のT（Try、Try-all）

やってみる、試してみる
という事が大事なのは、昨今よく見聞きします。

ただやってみる
のではなく、多くの事を得る為のポイントは、
以下の3点かと思います。

A:仮設を試す

B:100%完璧になるまで考えない

C:小さな仮設（実験）を多く実施する

仮設とする事で得る事も多くなります。
仮設を考え過ぎずに、仮設を完璧にするよりも、
小さな実験を繰り返しながら仮設を完璧にしていく。

体験（アクション）する事でしか
得られない事（情報、経験、アイディア、etc）があります。

考えるだけでは得られない事も多くあります。
経験する事で視野が広がったり、思いもよらぬ発見があったりと
得る事はたくさんあります。

考える事で、これらを得る事が出来ればベストかもしれませんが、
なかなか難しいですよね。

イメージとしては
成功に向けて、目的達成に向けて、小さな経験を積んでいく
小さなスキルアップしていく
という感じかと思います。

どんな経験を積む必要があるか、
仮設を考えて、全て経験してみる。
小さな経験に、成功も失敗もなく、
経験する事そのものが、成功や目的達成に向けて確実に近づく事になる
という事ですよね！

気付きを多くするサイクル

前回に引き続き、ちょっと視点を変えて、
私がTEFCASで気に入っているランキングを紹介します。

No.1：E（Event）
No.2：FC（Feedback、Check）
No.3：T（Try all）

今回は、No.2のFC（Feedback、Check）

FとCはセットである事が重要かと思っています。
それは、Feedbackをチェックする
という考え方はあまり無い気がするからです。

やった結果をチェックするなどはよくあると思うのですが、
TryAllの結果（Event）の更にFeedbackをチェックする

直接チェックしない事の効果はとても大きいと思うのです。
やった結果を受け止めて、そこから何を得るか（Feedback）
得たと思う事を列挙して、それをチェックする

という事かと思うのです。

Feedbackを得る為にも、Eventとして結果を素直に捉える事
フィルターなしで捉える事が重要で、（前回の内容）
そこからFeedbackを列挙して、列挙したFeedbackをチェックする。
Feedbackは本当に正しいのかをチェックする。

これだけで、とてもうまく行きそうですね。

だから、次のActionで確実に何かが変わるのかと思います。
このチェックが機能しないと次のActionで成長出来ない（何も変わらない）
もしくは、変わった事に気づかないのかと思います。

気付きを多くする為のサイクルとも言えそうですね。

素直になる

最近、社内でOODAが話題となりました。
同じようなサイクルとして、TEFCASを紹介しましたが、
TEFCASは、あまり知られてないようですね。

最近、ネット上ではOODA同様にTEFCASも良く見ると感じていたのですが、
まだまだのようですね。

なので、以前にも紹介していますが、
ちょっと視点を変えて、
私がTEFCASで気に入っているランキングを紹介します。

No.1：E（Event）
No.2：FC（Feedback、Check）
No.3：T（Try all）


EがNo.1なのは、
やってみた（Try）の結果を出来事として捉える
という考え方が他にはあまりないと感じているからです。

やった結果の事実を素直に受け入れる
という表現すると難しくなりますが、
試しにやってみた後を、素直にそのままを見るというか捉える

これ、すごく大事な気がしています。

考えてみると反抗期の我が娘にも、
人の言葉を素直に受け取った方が得だよ
と事ある毎に、小言をこぼすので煙たがられています。

なにをするにも成長する為には「素直」は重要な要素かもしれませんね。

仕事となると、成果が問われるので、
どうしても、自分に都合良く捉えたり、その逆だったりと
素直になるのが難しい状況なのだと思います。

そのような状況ではフィルター無しに、物事を真っ直ぐに見る事は
強く意識しないと出来ないのかもしませんね。

この続きは、また今度。

使われるモノと欲しいモノ

最近は、予測不可能なVUCAな世の中といわれますが、
本当に使われるモノも分かり難くなっている気がします。

ARやVRなども技術としては「欲しいモノ」なのかもしれませんが、
本当に「使われるモノ」になるのだろうか
と疑問に感じています。

というより、今後のARやVRビジネスを考えていく為に
疑問に感じるようにしています。

疑問に感じてないと
「使われるモノ」が見えてこないと思うのです。

「使われるモノ」にする為に、
「使われるモノ」を見極める為に、
常に疑問に感じるようにしています。

新しい技術の特徴なのかもしれませんが、
ARについては、一見すると「使われるモノ」になりそうな事は多くあるのですが、
代替え案が既にあって、置き換える価値が曖昧だったり、
技術を活用する効果が曖昧だったり、
と、「欲しいモノ」に留まる事が多いです。

使われるモノ　と　欲しいモノ
の溝はとてもとても深いのかもしれません。

LAMDA×2＝PDCA

LAMDAを2回実施すると、PDCAとなる？！

https://triz-journal.com/lamda-and-triz-knowledge-sharing-across-the-enterprise/

PDCAのP：LAMDAのLook,Ask,Model,Discuss までを実施

PDCAのD：LAMDAの最後のステップActkonを実施

PDCAのC：再度、LAMDAのLook,Ask,Model,Discuss までを実施

PDCAのA：LAMDAの最後のステップActkonを実施

という感じです。

PDCAとLAMDAの違いが分かり易い気がします。

学習サイクルを実施しながら改善サイクルを回す。

という感じが、とてもしっくりきます。

PDCAでは、Pに時間がかかるケースが多い印象なので、

Pに時間がかかる、Pが決められない場合は、

LAMDAで回してみる

って感じでしょうか。

LAMDAは、現地現物を意識するLook

から始まるのがなんといっても良いですし、

すぐに始められるポイントかと思います。

Look、Askまでは、確実に進みますよね。

Modelでは悩むところもあるとは思いますが、

とりあえず、列挙して、Discussする

という感じで回せると、徐々のペースがつかめるかと思います。

Discuss を明示しているので、相談もし易くなりますね。

そして、それが2回で改善サイクルとなる

もしくは、改善サイクルとする。

2回以上でも良いかとは思います。

とにかく、LAMDAで回して、改善サイクルとなるように

成果出しをしていく事が大事ですね。

CCPMはチェンジ・ザ・ルールの後に

2/5から久しぶりに展示会で東京に4日間も滞在しました。
長野に帰ってまず感じるのは空気の美味さですね。

空気の事はともかく、展示会では、
ザ・ゴール、ザ・ゴール2、チェンジ・ザ・ルール
を、こっそり並べていました。

少しでも反応してくる方がいると嬉しくなりますね。

並べるといえば、ザ・ゴールの並び順というか、
読む順番を聞かれる事がたまにあります。

私は、今回の並び順通りをお勧めしています。
1）ザ・ゴール
2）ザ・ゴール2
3）チェンジ・ザ・ルール
4）クリティカルチェーン

1，2は異論は無いと思います。
問題は3、4番目でしょうか。

なんとなく、3，4番目は逆という意見が多いような気がしますが、
私は、クリティカルチェーンは4番目ですね。

理由は、
「遅れても良い」などのルールの変更を徹底させないと
CCPMが機能しないと感じているからです。

もう一つの理由が
ルールの変更はとても難しいですし、
ルールを変えないと変わらないのは必然だと思うので。

この意味からも「チェンジ・ザ・ルール」
までは読むことを進めています。

通称4箱はグルグル回る

前回、通称「4箱」を紹介しました。

④が難しいのですが、
③も難しいですね。

特に新しい事にチャレンジするとなると、
③を何にするか、想像すら出来ない場合もありますね。

そのような場合は、
1週間後とか2週間後といった感じで、
期間を短く設定して、①と②を考えます。

①と②が具体化してくると、③が考え易くなります。

といった感じで、4箱をグルグル回って考え直していく事で、
より何をいつまでに達成するか
といった事が具体化されていきます。

具体化されれば、あとは「行動する」のみですね。

目標の前に、通称4箱

今年こそは！
と、目標を立てて気持ちを新たにする1月

ちょっと目標を見直してみませんか？！

目標を以下の4箱に当てはめてみると
より確実に目標達成出来るかもしれません！！
#通称、「4箱」です！

タイトルは「仮設を立てよう！！」
となっていますが、これは目標を検討する際に、
このワークシートに記入してチェックする為に活用していた為です。

チェックする為のシートですから、今回のような目標の検証にも活用出来ます。

コツは、まずは、あまり考えずに書き入れてみて
見直す事です。

見直ししながら、１つ１つ変更していきます。

恐らく、最も難しいのが④だと思います。
④には当たり前のような、分かり切った事でも記載する事と、
1つでは無く、思った事を次々に書き入れていくのがポイントです。

是非、活用してみて下さい！