フルスペックと流れ

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

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

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

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

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

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

となると、その何かを知る必要があります。
その何かを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をイメージしています。

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

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