気づきを掴む！

 少し前ですが、

現状を知る為のヒアリングをしました。

ほとんど何も知らない業界の現状把握だった事もあり、

あちこち話が飛ばないように、時間の流れにそって話が出来るように

業務の流れを想像し、資料にしました。

更には、間違ってても指摘してもらう事で、話のとっかかりとなりますし

それがそのまま現状把握になると考えました。

すると、当日、驚く結果となりました。

とっかかりは資料なので、まずは間違い、相違点があれば指摘して下さい

とお願いしたのですが、

その回答は「この資料の通りです。」

という事でした。

ところが、１つ１つ資料を確認していくと、

大きく異る点がありました！

先方は、大きく違うとは認識していません。

あぶなく、気付きを逃すところでした！！

結果として、大きく2つの収穫となりました。

1）相違点については、気にもとめない些細な事という認識である

2）こちらの認識と手順が違う事

それともう一つ。

手順を分解するのは、JOBS法（Jobs to be done)

のアプローチで、細かく分解しないと効果は無いものだと思っていましたが、

分からない事が多い状況でも、分解の粒度が大きくても、

効果があるものだという気づきを得ました。

設計コンセプトはシンプルに！

 SWEST22に参加しました。

昨年は参加出来なかったので、今年は楽しみにしていました。

ですが、今年はオンライン開催！

どうなるのか不安いっぱいでしたが、

スタッフのみなさんの頑張りで

SWESTらしいオンラインワークショップとなった気がします。

スタッフのみんさんに感謝です！

今回の目的は、いつも通りの議論する為はもちろんですが、もう1つあり、

社内検証中のサービス（今までに無い気づきがあるGrowth Mirror）を社外でも検証する為の参加でもありました。（※リンクをクリックすると無料でお試し出来るWebサービスです。IEでは動作しません。）

毎度、SWESTでは勉強となる事が多いのですが、

今回も勉強になりました。

最も印象に残ったのは、あるセッションでの安全性に関する議論です。

設計思想、コンセプトは大事だと常々意識し、実践してきましたが、

何を優先すべきかを1つにフォーカスする事がとても重要だと改めて感じました。

今回は、プログラムの実行速度を最優先としたうえで、

どのように安全性を担保するかという内容でしたが、

実行速度を優先するという設計思想があった上での安全性の確保

相反する事でもありますが、バランスを取る事が重要で、

そのバランスを保つためにも、シンプルなコンセプトが重要となると感じました。

実行速度を犠牲にせずに実現できる最大限の安全性の担保。

担保の仕方はいろいろです。

臨機応変に対応し、進化させる必要があると思います。

進化させる為に、議論を深める為にも思想、コンセプトはシンプルである必要があるのだと思います。

TOCシンポジウム2019

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

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

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

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

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

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

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

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

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

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

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

分かり易い体験の効果

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

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

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

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

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

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

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

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


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

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

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

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

事実を分ける事に気づく

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

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

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

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

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

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

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

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

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

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

プロセス思考の弊害

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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