今までは、価値検証には、もっぱらFRTの変形バージョン、4箱（G+4箱）を使っていましたが、
ソリューション活用ニーズの逆である非活用ニーズ（競合ニーズ含む）を
文章化、明確化、見える化することで、
ソリューション訴求ポイントや、顧客価値を改めて検証します。
今を変えたくないニーズは、どこにでもあるかとも思いますので、
それを打破するくらいの価値があるのか？
それらを打破する為の訴求ポイントは何か？
などなどを議論できることを期待してクラウドを活用してみます。
というか、今回始めてクラウドで検証してみます。
もしかすると、そこまで行かないかもしれませんが…
最近やってしまった失敗をSpeaker Deckに公開にしました！
アサンプションを全く疑えてない失敗事例です。
他人事だとツッコめるけど、自分だと甘々な事が露呈してしまいました。
お恥ずかしい…
改めて資料にしてみると、
失敗事例は分かり易いですが、
対処方法は1つではないので、どう表現するかが難しい…
この点も、もっと勉強が必要ですね。
最近は、資料で紹介している「G+4箱」を書くようにしていますので、
引き続き、事例資料も作っていこうと思います。
久しぶりにアプリ作成しました。
改めて、作り出すと夢中になってしまうなーと実感しています。
ある程度完成するまでは、他の事は考えたくなくなりますね。
いや、他の事は全く考えなくなります。
私だけでしょうか？！
大昔は、コンパイルに時間が掛かったりなど、
いろいろと隙間時間があり、
その時に、他の事を考えたり出来たのですが、
いまは、ほぼほぼPC上で完結する事が多いので、
テストもガンガン書きたくなるし…
ある程度のところまでは集中しちゃいますよね。
だから、こそ余計に小さく作る事が重要になると思っています。
特に私にとっては！
小さく作って繋げていく。
そして、小さく作るために必要なのが、
「何を作るか」
この「何」をいかに小さくするか
どう繋げていくか、
がとても重要になってきます。
この「何」を決めるには、
ソフトの事も知りつつ、目的もしっかり定めてフォーカスする必要があります。
そして、目的をフォーカスにするのは、やっぱりFRTですね！
このスキルは、今後もしばらく重要になってくると考えています。
CCPMのバッファだけを監視する
という考え方はシンプルで誰でも状況把握可能かと思います。
しかし、バッファという言葉が、どうもしっくりきません。
言葉というより「バッファを入れる、付加する」というアプローチがしっくりこない感じ。
自然に入るものであるべきというか…
ゆとりの法則も、何度も読んでいますが、
必要なのは納得なのですが、”ゆとり”という言葉がどうもしっくりきません。
こちらも、言葉というより「ゆとりを取り入れる」というような
敢えて、組み込むような感じがしっくりこない感じです。
こちらも、敢えてではなく、普通に”ある”ものであるべきな気がするのです。
そして、アジャイルのスモールリリースは、”ゆとり”やバッファとは対局のようですが、
同じ考え方だと思うのです。
価値を小さく短い期間で提供していく事が、”ゆとり“やバッファを作り出す。
これでは分かり難いですね。
”ゆとり”もバッファも価値定義の曖昧さに含まれると思うのです。
最初のリリースの価値定義、リリースするモノ（仕様）は、多少なりとも曖昧さがあり、
「まずは、ここまで作ってみましょう。」
というようなスタートになる事が多い気がします。
お互いの認識合わせをしながら形にしていくようなケースが多いかと。
そうなると、いい意味で探り合いしながら進めるので、
最初は曖昧となるが、リリースを重ねる事で、認識も、価値定義も合ってくる。
そして、この曖昧さが”ゆとり“であり、バッファと言えると思うのです。
当然、後半は”ゆとり”もバッファも、少なくなりますが、
後半は何が重要であるかという認識も、作業スペースも掴めている状況なのですし、
全ての認識合わせが出来ている状況で、たとえ、短期間で一気に作り上げるといような
いわゆる“ゆとり”が無い状況だとしても、
士気は最高潮、集中力も高くなるのでミスも少なくなります。
予算の関係から、何回のリリースで完成するのかが明確でないと受け入れられない！
という事も言われますが、
これも、完成品が見えてくれば、その後の回数は分かります。
完成品が見えるまでを試作評価期間と考えるなど、対応方法はいろいろあるかと。
そうそう。こういう時こそ、曖昧な価値定義や仕様を仮説検証FRTですね！
2つのFRT（曖昧なFRTと検証した結果を書き込むFRT）
にする事で、おおよその計画となります！
仮説検証FRTについては、改めて紹介したいと思います。
と、いう事で、
スモールリリースとバッファ監視。
対局のようで、実は同じでは！？
そして、スモールリリースはしっくりきます。
新たな企画での仮説を検証する為に検証リストを作成しました。
検証する事が、学習する事になるのですが、
ここ、モヤモヤしています。
仮設を立てて、検証して、結果が出る事で学習して、さらなる仮設につながる。
1つ目のモヤモヤ
LAMDAは学習サイクルであり、これまでも有効活用してきました。
しかし、価値検証の学習フェーズではLAMDAは向かない？！
うまく活用出来ていないだけ？
2つ目のモヤモヤ
ABテストもニーズ検証などで、これまでも有効活用してきました。
しかし、価値検証の学習フェーズでは、ABテストは向かない？！
うまく活用出来ていないだけ？
これまで、この3つのツールをごちゃごちゃに使っていたので、うまく学習した事を残せていません...
この3つのツールを適材適所に使うことで、
もっとスムーズに仮設検証が可能になる気がしていますし、学習した事を時間をかけずに資産化できるようにしたいと考えています。
と、整理した結果、
価値の検証の大きな流れはFRTで見える化。
FRTの中の分からない事、曖昧な事は、LAMDAで学習し、共有する。
LAMDAを使って明確になった事、
もしくは、既に明確になっている事の
さらに細かい手段の検証にABテストで共有する。
という感じかなぁ...
早く創る（ソフト）為の5箇条を考えてみました。
本当は八策にしたいのだけど... 5の方がシンプルですね。
価値定義が出来ている前提で、どうすれば早く創れるのか。
今回のプロジェクトではチームとして連携できて、
各ピースがうまく噛み合って早く創れたと思いますので、
早く創れたポイントをまとめてみました。
その①：分ける
価値と目的（機能）と手段を分けて考える事がまず第一歩かと。
価値を提供する為に、どんな機能（目的）が必要か。
その目的達成の為にどんな手段が考えられるか。
それぞれシンプルに必要な事を小さく列挙して、
カテゴリ分けするのが良いかと思います。
その②：流れにする
分けたものを繋げます。
可能であれば、提供する順番、検証する順番に繋げるのが良いです。
私はここでFRTを活用しました。
提供する機能、期待する状態（行動）、アサンプション（前提など）
の3つで流れを作りました。
これで方向性が定義されます。
その③：目的が達成される手段を組み込む
流れに手段を追加していきます。
手段で目的が達成される事を確認しながら追加します。
最短手段にこだわり、目的達成を忘れない事が重要です。
見た目が目的達成において重要な要素であるならば、見た目も含めて検討します。
また、目的に対して1つの手段であれば、その②の流れに記載すれば良いのですが、
目的の為に必要な手段が複数ある場合もあります。
その場合は、目的に必要な手段をグループ化して、そのグループで流れを作ります。
操作手順や時間軸で流れを組み立てます。
目的が達成される事を何度も確認する事が重要かと思います。
その④：「なぜ？」ではなく、「こうすると？」
手段を検討する上で、最も早い手段を検討する上で
なぜ時間がかかるのかを聞くのはタブーかと思います。
「なぜ？」と聞くより、次々提案する方が結果的に早い気がしています。
もちろん、時間がかかると思い込んでいる可能性もあるのですが
「こうすると早くなる？」といった議論の方が推進力が上がる気がします。
そして、議論する事で思い込みが解消される事も多いと感じています。
その⑤：とことんバトルする
早さを実現する為には、建設的なバトルをする事が欠かせないと思います。
「なぜ？」のバトルではなく、
「これは？」「こうしたら？」「このほうが」というバトルです。
チームでお互いに目的を達成する為の手段の案をぶつけ合うバトルです。
ときに、「そもそも」といった確認もよくあった気がしますね。
具体的な作り方、実装方法を議論するというより、目的達成のためのアプローチを議論する方がチームとして盛り上がる気がしています。
具体的な実装方法は実装する人（アサインされた人）に任せるというスタンスも重要かと思います。
バトルする上で①、②を共有、合意している事がとても重要になると思っています。
合意している事で、余計な発散を防ぐ事ができます。（と思っています）
もう少し整理する必要はありますが、この5つは重要かと思っています。
もう1点、「絵を描いて議論する」を入れようかと迷いましたが...
やっぱり、この5つかなぁ...
