量の数値化

ハカるのは嫌いなのですが、
見える化するには、数値化が必要な事もありますので、
数値化出来るものは、数値化して、
ハカる事を推進しています。

具体的には、
2週間後の目指す状態と、その達成条件を定義するのですが、
達成条件として、数値化する事を推進しています。

このような数値化をお願いすると、
必ず達成しなければならない　という意識が大きく働き、
なかなか数値化出来ないようです。

ここでの数値化は2つの意味があります。
1つ目は、やる事を具体化する為の数値です。

何をどのくらい作るのか、といった量を数値化するだけでも、
大よその内容が見えてきます。
これを事前に擦り合わせる為です。

例えば、ある状態を達成する為に課題リストを作成する場合、
いくつくらいの記載項目のリストに、何行埋めるのか
といった数値が見えてくると、自身でのセルフチェックにもなり、
チーム内でのより具体的な認識合わせとなります。
また、セルフチェックする事で、
この数値を達成する為の必要な行動が発見出来たりする事にもなります。

2つ目は、確実に前進している事を見える化する為です。
課題リストでいうと、達成条件を「課題10個入力」とした場合、
もし、結果が3であっても、確実に前進している事が分かります。
ゼロでなければ、確実に前進しています。
なぜ、3個だけなのかを追求するのではなく、
次は、5個にする為に、どうすべきかを考えます。

可能であれば、質も数値化したいところですが、
まずは量からでも、得るもの（気づき）はあります。

強制せずに...

改善活動は何かと後回しにされがちですが、

後回しとならない、必要な事に置き換える事が出来れば、

そもそも強制する必要がなくなります。

それを自然に促せると完璧ですよね。
先日、促す感じがちょっと掴めるような事がありました。

この経験をふりかえってみると、
キーワードは、
・実施する人達が興味のある事
・準備不要で、すぐに出来る事
・結果がすぐに分かり、分かり易い事

改めて並べてみると、当たり前な気がしますね...
しかし、このキーワードを引き出して揃えるのが、なかなか出来ない
という事が分かりますね。

今までは、
後回しになりそうな時は、3つのポイントを押さえたアクションを
どんどん提案していた気がします。

しかし、そうではなく、
やりたい事、興味のある事を具体化して、
やってみたいと思うよな事まで落とし込む。

落とし込むところを良く分からないフリして
促せると良いのでしょうね...

1ヶ月後どうなっていたいか？

TOCのFRT（未来構造ツリー）を書く事で、
状態を捉える訓練を実施しました。

「状態を捉える」とは、
行動（Action）した結果、どうなるか、どう良くなるか
という状態を定義する事です。

ソフトウェア開発技術者の傾向でしょうか？
身近な人の傾向でしょうか？
How思考が強い為でしょうか？

状態の表現が行動から離れていないというか、
行動と状態が分けられないというか...

2週間後の状態と
それを達成する為の行動を記載してもらうと、

レビューが完了した状態
など、プロセスが完了している状態
が記載されます。

完了した状態って具体的にどんな状態？
といったツッコミを入れると、成果物が完成している状態
となります。

ただ、これでも成果物の「完成」の基準が不明確ですし、
成果物の目的も曖昧なので、
まだ行動の表現からは離れていないと思うのです。
もちろん、成果物の基準や目的が具体的に定義されていれば何の問題もありません。

説明が長くなりましたが、という事で、

行動と状態を明確分ける。

状態を捉える為に、

1ヶ月のFRT（未来構造ツリー）をじっくり作成する訓練を実施しました。

まずは、

1ヶ月のなりたい姿、目指す状態を設定し、（これは少し抽象的でもOKとする）

そこに向かう為のスタートインジェクション（まず始めに行動する事）

を決めて、スタートインジェクションから
1ヶ月後に向けて、状態と行動の仮説を立てていきます。

これを1日じっくりやりました。

結果としては、状態の捉え方が、少し掴めるようです。
あと、2，3回やると習得してもらえそうです。
基本的には具体化だと思うのですが、なかなか難しいようです。

プロセス定義でも、同じ事する筈なんですけどね...

インプロはジャムセッション！

インプロ（Improvisation）体験してきました！

それは、まるでジャムセッション！

体を動かし、リズムを作り、
次々に無責任に他人に無茶振りしていく

振られるので否定する間もなく、
その瞬間に思い付いた事を表現していきます。
すると、新しいものが次々に生まれ、自然と共創になっていく。

「表現」が「演奏」になれば、ジャムセッションそのものですね。


これは活用出来そうです。
フューチャーマッピングと同じように活用しようと思っています。

全く関係の無いストーリーをインプロで作成後、
現実のアイディアソンなり、アイディア出しを実施する。
という感じですね。
ストーリーのテーマくらいは決めておこうかな。

インプロは体を動かしているうちに、
チームで自然と違う事が生み出されている不思議な感じです。

身近なものからハカる

最近、お気に入りの言葉です。
「身近なものからハカる」

昨今のソフトウェア開発では、静的解析ツールがだいぶ進化し、
ツールの種類も選べる状況にありますが、
そんな状況でも、あまりハカる習慣は無い気がします。

日々の業務において、身近な事、物をお手軽にハカる事で
当たり前ですが、現状が見える化できます。

そして、もう一つの鍵は「量」です。
「質」をハカるのは難しいので、まずは「量」からハカる。

しかしながら、量も細かくなっていくと、質に近くなります。

例えば、ドキュメントの量を測るとして、
最初は、大まかなページ数から宣言し
徐々に、ページ内の記載項目数や表や図などと
細かく宣言していけば、
1ページ内の項目数が分かると、1項目の大まかな粒度が分かります。
粒度は質に関係します。

正式なドキュメント以外でも、ちょっとした調査でも
メモ程度は残す事が多いと思います。
すると、それはドキュメント同様にハカれます。

メモを残さない場合でも、何をどのくらい調査するかは
ハカれると思います。


更に、それを宣言すると、より多くの気づきを得らると思っています。

身近な事、物の量を宣言して結果を比べる。

今日は何をどのくらい作成する
と宣言し、結果、どのくらい作成出来た　
とふりかえり、結果を検証するのではなく、次の宣言に生かす。

これを繰り返すと「量」の意識が徐々に「質」になっていくと考えています。

質を意識する為にも、
身近なものから量を宣言する！

起きた事（事実）を言葉にするには？

状態と行動を分けるには、どうすれば良いかを考えている中で、
起きた事（事実）を捉える事が、一つのキッカケになると思い始めています。

その理由は、状態がそのまま、成果、結果と結びつけてしまい、
結果が出ない、成果が出ない事（つまり査定が悪くなる事）
を回避したい思いから、
成果、結果が出し易い行動だけを意識してしまう。
と考えたからです。

昨今は技術者のステータスみたいなものが、あまり無いのでしょうか？！
忙し過ぎて、そんな事を語り合う場も時間も無いのかもしれません...

結果や成果ではなく、起きた事（事実）を捉え、
そこから気づきを得る。
その為には、起きた事を言葉にする、表現する事が必要なのでは？！

その為には、言葉にする場、表現する場が必要ですね。

朝会などで、そんな場が作れると良いと思いますが、
いきなり「昨日、やった事ではなく、起きた事を話そう」
といっても、なかなか難しい気がします。

恐らく「やった事（行動）」を話す癖が出来ている気がするので、
難しい気がしています。

もっとワクワクするような仕掛けが必要では？！
と考えると、アイスブレイク的なアプローチが思い浮かびます。
しかし、毎日アイスブレイク？！
という疑問も...

などと考えながら、ネットをうろついていると、
Good&New　なるものを見つけました。
米国の教育学者ピータークラインさんが提唱している
アイスブレイク、チーム活性化の手法という事です。

日本でもいろんな方が紹介していますね。

フューチャーマッピングでも登場するクシュボール
そろそろ必要なのかなぁ...

見える化の違い

前回、勘の見える化は
いわゆるタスクボードなどの見える化とは異なる気がしています。

タスクボードの見える化は、
次の行動を誘発する為が主な目的かと思います。
現在の状態を誰もが同じ認識となるように見える化する事で、
各自が次にすべき行動が何かを考え、行動する。

一方、勘の見える化は、行動の誘発というよりは、
ベテランの視点を掴む為のヒントというか、
ベテランの考えを知る1つのキッカケいう感じでしょうか。

伝統工芸などの職人だと技術が結果として見えるものとなります。
見えるので、自分との違いも明確になります。

しかし、ソフトウェア開発では、技術の結果が見えない（もしくは見難い）
ので、自分と何が違うのかが分かりません。
伝統工芸のように技術を見て盗む事も出来ません。

ソフトウェア開発において、同じような環境を作るのは難しいですが、
せめて、ヒントを与える事で、違いを考えるキッカケとする事は出来そうです。

日常的にいつでも技術を見える状態にする一つの案として、
常に予想される結果や成果を
具体的な数値としてホワイトボードなどに書き出してみる。

書き出すと議論も起こり易く、
チームの認識も、より具体的に合うようになります。
更には、若手技術者は、何を見て、何を考えて、
そのような数値を出しているのかを考えるキッカケとなる。
普段から意識して話を聞くようになる。
などの効果が予想されます。

抽象的な課題などは、違いが見え難いので、数値とする事がポイントとなります。
数値とする事に抵抗を感じる人も多いですが、これも一工夫かと思います。

例えば、
「このバグに関連するバグがまだありそうだ」
と感じた場合には、
「関連するバグが、あと3件はありそうだ」

とか

「まだ何件か、変更依頼がきそうだね」
と感じた場合には、
「あと2件は、変更依頼がきそうだね」

などと、まさしく勘を数値化してみます。

このようにちょっとした事を数値化する事を習慣にします。
そして、この数値の根拠は無さそうであるのがベテランです。
結果的に数値が異なるとしても、無さそうである根拠を伝えるキッカケにはなる筈です。
結果の数値が異なるよりも、伝えるキッカケの方が重要だと思っています。

確かに、説明するのは難しいケースもあるのですが、
そこは、それを面倒と思わずに、説明する努力も必要かと思います。

勘の見える化

先月のSWEST19にて大収穫がありました。

失敗プロジェクトのほとんどが開始時に失敗しそうな事がなんとなく分かる
という議論の中で、
「なぜ、分かるのか？」
「それは経験と勘」という事になるのですが、

議論はここで終わるのではなく、ここからヒートアップします。
勘は、経験に基づく根拠が必ずある筈。
そして、失敗しそうと感じる、きっかけや違和感が必ずあった筈。
そのきっかけや違和感を感じた後どーした？

それを放置したから失敗したのでは？！
しかも、違和感を感じるのは1度では無い筈、
ヤバイと気づいた時にはリカバリー出来ない状態だったのでは？！
と、大先輩から突っ込みが...

ぐうの音も出ません....

育成の為とか、なんとか理由をつけたりしますが、
放置していた事には変わりなく....

そして、クライマックスは、

違和感を感じたら、何か勘が働いたら、
それをそのまま放置せず、
それを追求して伝える事、見える化する事がベテランの役目では！

と、大先輩からお叱りを受けました...

しかし、しかし、これは大収穫です。

勘をキチンと伝える。
つまり、伝えられるように考えて行動する。

改めて、具体化し、見える化して、数値化して伝えていく事が
大事だと感じた瞬間であり、今も考え続けています。

その結果、今の2週間毎のふりかえり活動においても、
勘を仮説として数値化する事が可能だ！
という事に気づき、具体化を進めています。

事実を分ける事に気づく

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

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

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

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

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

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

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

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

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

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

やっぱりA3は難しい？！

ふりかえり活動の3ヶ月の結果をA3プロセスとして
A3一枚に記載する各項目をパワポの各スライド一枚にまとめています。

やった事をまとめるだけなのですが、
A3をまとめるのには時間がかかっています。

パワポにした事で、比較的前半（背景から目標まで）
は、比較的早く、順調に仕上がります。
問題は、この後ですね。
一枚になっていないからか、各スライドが繋がらない...

恐らく「やった事」を書いてしまうので、繋がらない気がしています。

アクションした結果（事実）を中心に
ストーリーとして繋げる必要があるのですが、
どうしてもやった事を中心にまとめようとしてしまう...

そう考えるとA3が難しいのではなく、事実を中心にまとめる力の問題？！
なんとなく他の資料も同じ傾向がある気がしてきます...

ですが、A3にまとめる事で3ヶ月が見えてきます。
新たな気づきも多くあります。

ここがA3の魅力ですね。
現状では時間はかかりますが、やる価値は十二分にあります。

慣れてくれば必ず早く書けるようになるので
しばらくは辛抱ですね。

プロセス思考の弊害

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事実、気づき、ナラティブ、マインドセット

以下のセミナーに参加しました
『サービスデザインシンキング セミナー 〜最新動向と組織への浸透〜』
今回は講義がメインでしたが、改めて気づく事も多く、
とても有意義で楽しい時間でした。

強く感じたのは、以下の２点。

１つは、事実(Facts)から気づきを得る！

TEFCASも同じアプローチです。
TEFCASに出会ったときに、ソフトウェア開発にもこの考え方は必要！
っと思ったのでTEFCASにて取り組んでいるのですが....

事実(Facts)　と　気づき　の間には、
とても高い壁か、大海原があるようです...
とてもとても、この間が遠いのです。

もちろん、気づける人もいますが、
プロセス思考というかフローチャート思考というか、
手順思考というか、

行動のみで、やる事が組み立てられていると
これが遠い気がします。

一方で、行動と状態が、ある程度分けられていると、
気づき易い気がしています。


それともう１点は、ナラティブとマインドセット

マインドセットは必要ですが、押し付けるものでもないので、
具体的にどうやって作っていくのか、悶々としていましたが、
今回のセミナーで、

ナラティブにより、マインドセットが醸成されていくのだろう

と、ふと繋がりました。

DialogicODでは、
ナラティブから生成的イメージという流れですが、
その間にマインドセットが入る方がしっくりくる感じです。
ナラティブからマインドセットを醸成し、生成的イメージへ

そのためにも、いよいよナラティブを実践する場を作る必要がありそうです。

さて、ナラティブの実践まで考え続ける日々の始まりです。

 

決断の積み重ね

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

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

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

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

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

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

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

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

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

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

自分の言葉

Dialogic OD　のワークショップに参加して、
ナラティブ(Narrative)を知り、
それ以降、自分の言葉で話す、語る
という事について考えています。

ソフトウェア開発業務の中で
自分の言葉を使っている人
自分の言葉を使ってコミュニケーションしている技術者は少ない気がしています。
誰もが使う、抽象的な表現で曖昧なまま開発が進んでいる気がするのです。

多くの人が自分の言葉で表現するだけで、
認識違いが明確になり、齟齬なく開発が進むのではないかとも思います。

メタファーのように同じ言葉を使う事も重要ですが、
そのメタファーを作り上げる事がもっと重要な気がします。

自分の言葉で表現して、
互いにぶつかりながら、コンフリクトしながら創り上げるメタファーだからこそ、
意味があるのだと思うのです。

「自分の言葉」がなんだか分かり難い気もしますが、　
あまり難しい事ではなく、
具体化する事、細分化する事、詳細なイメージを造る事
で、自分の言葉が創られていく気がします。
はじめは、教えられた言葉、人が使っている言葉を使っていても、
それを少しずつでも具体化していく事で、少しずつ自分の言葉になる気がします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

イノベーションとリスク

少し前になりますが4/21の朝日新聞に「イノベーションへの道」
という記事がありました。

見出しには、『「何もしない」がリスク最大』とあり、
イノベーションに取組む際のリスクかと思いきや、
全く逆で、時代の激しい変化に対応する為にも
イノベーションに焦点を定めた戦略に取り組む必要があり、
「何もしない、先送り」は最大のリスク！

という事でした。

とても力強い言葉で、強く共感しました。

それと、驚いたのが「技術革新力ランキング」です。
そんなランキングがある事も知りませんでしたが、
2007年は日本が4位だった事に驚きました。
10年前は4位だったなんて！　という感じです。

更には、2012年は25位　なんと5年で急降下。
2016年は16位と、なんとか持ち直してきている感じですね。
16位と持ち直してきているのも底力を感じます。

話を戻して、リスクについですが、
企業では流石に「何もしない」という状況は少ない気がします。
それぞれ危機感を感じて何かはし始めている状況だと思うのです。
一方で「先送り」の可能性は高い気がしています。
記事で指摘しているような環境変化、環境改善を
「先送り」にしている可能性は高いと感じています。

改善した結果としてイノベーションが100％起こるのであれば
誰も躊躇しないと思うのですが、何から始めるにも不確実な事ばかりですので、
これまでのマネージメントも変えていく必要がありそうです。

こう考えていくと、GEとリーンスタートアップが頭に浮かびます。
マネージメントも含めて一気に変革させているGEは流石という事でしょうか。

GEのようにはなかなか実践出来ませんので、頭を切り替えて、
少しずつ変革を起こしていくと考えて、
頭に浮かぶのは、リーンスタートアップの企業内スタートアップとDialogic OD
と『「微力」だけど「無力」じゃない』
(朝日新聞の「私の折々のことばコンテスト」受賞作）

が思い浮かびました。

リスク回避の鍵は微力かも！
という事で、今日も微力を重ねいきます！

フルスペックと流れ

多様なユーザへの対応方法が、なぜフルスペックとなるのでしょうか？

その背景には、
全てのユーザ要望を対応していないと売れない
なんでも出来ないと売れない
出来ない事があると使わない(買わない）

といったアサンプションがある気がします。

出来ない事があると使わない　

というアサンプションは、
出来ない事があっても売れているものと比べる事で除外出来そうです。

出来ないのであれば、出来ないなりに使う
というより、そう思わせる何かがあるから使われる。
使い易い、イライラしない、心地よい、自慢になる、見た目がイイ
から、○○が出来なくても気にならない。
出来ない事よりも、充足度が高い何かがあれば使われる。

となると、その何かを知る必要があります。
その何かをJOBと定義するとJTDBの考え方が活用出来そうです。
中でも情緒的JOBは今後、ますますポイントとなる気がします。

更には、一時的に製品を売って終了ではなく、
その何か（体験）を連続的に提供する為の接点や仕組み、体制を作り込む
と考えるのがリーンUXかと思います。

となると、体験と連続的にする為の流れを知る必要がある。
という事になります。

これまでの考え方と対比すると
機能よりも体験　
フルスペックよりも連続性、流れ　

という感じでしょうか？

必要なのは体験と流れ
となりますが、どちらも具体的にどのように作りだすのか
が問題です。

単一的な体験は観察する事である程度見える気がしますが、
流れも観察で見えるのか？！
という感じです。

「流れ」とは手順などと違い、恐らくユーザも意識していない流れ
という気がしています。

そんな雲のようなものを、どうやって掴むのか？！

観察するしかない気もしますが、
ただ観察しても分からない気もします。

具体的な着眼点を定めて見る必要がある気がしますし、
逆に先入観なしに俯瞰して見る必要がある気もしてきます....

更には、ケースバイケースでもあると思うので、
とにかく悶々としながら観察するしかないかなぁ....
いずれにしても観察しないと何も始まらないですね。

書類上の合意は幻想

春休みに家族と古本屋に出かけ、また出会いがありました！

以前から気になっていたのですが、
手に取って読んでみると、これは購入せずにはいられない内容でした。

今回のタイトルは書籍の節タイトルそのままです。

ちょっと紹介しますと

ビジネスの世界には
役に立たないどころか自分達の時間をムダにする用済みの書類が散乱している。
~中略~
これらの書類を作成するのには果てしなく時間がかかるが、
忘れるのには数秒しかかからない。

最後の「忘れるのには、数秒しかかからない」

というのが、これまでにない着眼点と感じ、購入する決め手となりました。

果てしない時間がかかる点や、役に立たない点を指摘する事は多い気がしますが
「忘れる」という観点は、あまり無い気がします。

更に、書類のような抽象物は合意したという幻想を生み出す。
何百人もの人が同じ言葉を読む事は出来るが、
頭の中では何百もの異なった事を想像している　

と続きます。
イメージが異なる点についてはアジャイルなどでも良く指摘されますが、
「合意という幻想を生み出す」という表現がお気に入りです。
で、この書籍の正体ですが、
『小さなチーム、大きな仕事　働き方の新スタンダード』
です。

アジャイルやリーンとの共通点も多くあり
小さな節に区切られているのでとても読み易く、
なんといっても、着眼点と表現が少し変わっていて楽しいです。

そしてこの書籍は、同じタイトルで「完全版」というのがあります。
気になりますね....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

仮説に挑戦！

振返りを小さく繰り返していますが、
気づきを生むのは難しいです。

当人達も、目標達成に向けて、何をすべきかを考え始めて
思考が少しずつ変化したような、しないような...
といった感じなので、
ここまでの気づきは順調といえます。

しかし、この先の気づきがなかなか手強いです。

どうなれば達成なのか、
どういう状態が達成に向かう中間状態なのか
が、深い霧の中で見えてきません。

足元である振返りで決めたTry(やる事)の結果が曖昧なので、
先に進みたいのに、足踏みしている状態です。
ですが、なかなかこの状態に気づく事は出来ないようです。
小さなTryを確実に成果に繋げないと、
振返りをやる事が目的となり、何も変わらない”振返り”という印象となり、
みるみるモチベーションが低下していく事は目に見えています。
そうなってしまっては目標達成どころではありません....


であれば、Tryを設定する時に、本来のやり方でもある
Tryの結果状態を仮説として見える化する！

もちろん、最初は仮説を立てるのは難しいと思いますが、
先の状態になるよりは、少しだけ難しい事をやる方が
モチベーションへ、いい影響となるのではと考えました。


いざ、実施すると想定通り！
これまではTryの数は複数上がっていたのですが、
仮説を立てると、1人1個がやっとな感じです。

それでも1個は上げられているので、まずは第一ステップクリアですね。
曖昧でも仮説を立てて、その結果何に気づけるか！？
少なくとも、曖昧な事は認識出来る筈。
そうなれば、あとは少しずつ修正していくだけな筈！

何をハカるか！？

いつもいつも
何をするにしても、毎回毎回長い時間悩むのが

”何をハカるのか？！”

今回のTEFCAS振返りももちろん何をハカるか悩み続けています。

ハカる事で、現場のモチベーションアップに繋がり、
現場も管理する側にも成果として見える必要がある。

しかも、それを簡単に時間をかけずに集めて、
更に、集計も簡単に時間をかけずにやりたい！
ハカる事を目的化しない為にも簡単にする必要があると信じています。
それは何か？！

しばらくは、実際に思い付いた事をハカりながら模索しようと思うのですが、
ハカる事は、ついつい忘れてしまいます...

一方で、あるレビュー記録のエクセルファイルを１日毎にバックを取り、
そのバックアップから各列、各行の変更回数を数えたら、
数に比例する”事象”がある事が分かってきました。
計測方法も集計方法シンプルなので、継続可能ですし、
何よりシンプルな事が説得力に繋がるように感じました。

これが分かるまで約4ヶ月。
もちろん、この間、これに専念していた訳ではありません。
数字とのにらめっこはあまり得意では無いので、実質は8日～12日くらいかと思います。
レビュー記録のバックアップでは何も分からないのかなぁ
と諦めかけた時に光が見えました。

諦めずに地道にデータと向き合う事で見えてくるものがある
という事ですよね....

自分でも以前に書きましたが、
因果関係を明確にして、忘れずにハカらなくては...

Event と Adjustがイイ！

振返りもTEFCASで実施してみると、なかなかいい感触です。
以前も少し紹介しましたが、

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

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

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

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

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

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

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

という感じです。

この何が良いか？！
というとEventとAdjustです。

まずはEventから

Event：事実を捉える　
これがかなりお気に入り。

振返りだと、Tryの結果をどうしても良かった／悪かった　で捉えがちですが、
結果を事実として捉えると、そこを一度俯瞰する事になり、
Tryの結果を少し深堀する結果となります。

その事実から、Feedbackとして、現在は「分かった事」「得た事」
として実践しています。
「成功に到達する為のインプット」だと少し分かり難いかと思ったので
このように説明してやっていますが、
結果的には、得た事がインプットとなる筈だと考えています。
ここでも良い、悪いではなく、何を得たのかを議論する事で、
次の目標達成に向けたTryに繋がり易くなる印象です。

面倒でもEventを入れる事で、
チームとして、Tryの結果の捉え方が少し変わった感じがしました。

次にAdjustですが、
ここも次のTryに行きたいところですが、
Adjustを入れる事で、目標を再度確認し、チームとしての方向性が定まる印象です。
目標って意外と忘れがちな気がしますが、そこを立ち返る一手間という印象です。

実は、現状では、その次にもう一手間「Pivot」を入れています。
なので、正確には、TEFCAPSですかね。

言葉としては、適当では無いかもしれませんが、
調整後、明示的にPivot：意味としては「判断」を入れました。
いわゆるリーンスタートアップのPivotをイメージしています。

方向性を定めて集中する事でより、チーム力が上がる事を期待しています。
「こうしよう！」とチームでシンプルな事に集中すると
想像以上のチーム力が発揮される事がありますよね。
これを毎回でなくとも、よりチーム力が発揮し易いように
との思いを込めて、判断する　というアクションを入れました。

今のところ、これが作用している感じは全くありません....
目標によっては、チームによっては作用する事があるかも？！
と期待しつつ、引き続き実践していきます。 

あぶり出し

TOCのFRT(未来構造ツリー）
と
FM（フューチャーマッピング）

の取り組み、もう少しだけ実施チームが増えました。

いずれも時間制限を設けて実施しているだけに
思うように気づきを引き出せなかったと反省していました...

しかし、改めて全てを見直すとチームのカラーや
プロジェクトの状態が炙り出されているようです。

ポイントは2つありそうです。
まだまだ仮説ですが、
1つは、FRTのターゲットを3ヶ月後に置いた事
3ヶ月は現実的でもあり、遠過ぎない未来でもあり、
やりたい事、現実的に出来そうな事、目指したい事などなど
が、交錯するようです。

多くは現実的な面に引っ張られますが、
ありたい姿が見え隠れします。
しかも、この「ありたい姿」は、現状の不満の裏返しとなる傾向がありそうです。

もう1つは、キャラ設定ですね。
キャラ設定する事で無意識な思いやアサンプションが自然と出てくるようです。
まさに「あぶり出し」という印象です。

この炙り出し効果は、思わぬ副産物です。
そこに気づかせてくれた、道場関係者のみなさんに感謝です！