2020年11月5日木曜日

FRTとABテストとLAMDA

新たな企画での仮説を検証する為に検証リストを作成しました。

検証する事が、学習する事になるのですが、

ここ、モヤモヤしています。

仮設を立てて、検証して、結果が出る事で学習して、さらなる仮設につながる。


1つ目のモヤモヤ

LAMDAは学習サイクルであり、これまでも有効活用してきました。

しかし、価値検証の学習フェーズではLAMDAは向かない?!

うまく活用出来ていないだけ?


2つ目のモヤモヤ

ABテストもニーズ検証などで、これまでも有効活用してきました。

しかし、価値検証の学習フェーズでは、ABテストは向かない?!

うまく活用出来ていないだけ?


これまで、この3つのツールをごちゃごちゃに使っていたので、うまく学習した事を残せていません...

この3つのツールを適材適所に使うことで、

もっとスムーズに仮設検証が可能になる気がしていますし、学習した事を時間をかけずに資産化できるようにしたいと考えています。


と、整理した結果、

価値の検証の大きな流れはFRTで見える化。

FRTの中の分からない事、曖昧な事は、LAMDAで学習し、共有する。

LAMDAを使って明確になった事、

もしくは、既に明確になっている事の

さらに細かい手段の検証にABテストで共有する。

という感じかなぁ...

2020年10月21日水曜日

早く創る為の5箇条?

早く創る(ソフト)為の5箇条を考えてみました。

本当は八策にしたいのだけど...  5の方がシンプルですね。

価値定義が出来ている前提で、どうすれば早く創れるのか。


今回のプロジェクトではチームとして連携できて、

各ピースがうまく噛み合って早く創れたと思いますので、

早く創れたポイントをまとめてみました。


その①:分ける

価値と目的(機能)と手段を分けて考える事がまず第一歩かと。

価値を提供する為に、どんな機能(目的)が必要か。

その目的達成の為にどんな手段が考えられるか。

それぞれシンプルに必要な事を小さく列挙して、

カテゴリ分けするのが良いかと思います。


その②:流れにする

分けたものを繋げます。

可能であれば、提供する順番、検証する順番に繋げるのが良いです。

私はここでFRTを活用しました。

提供する機能、期待する状態(行動)、アサンプション(前提など)

の3つで流れを作りました。

これで方向性が定義されます。


その③:目的が達成される手段を組み込む

流れに手段を追加していきます。

手段で目的が達成される事を確認しながら追加します。

最短手段にこだわり、目的達成を忘れない事が重要です。

見た目が目的達成において重要な要素であるならば、見た目も含めて検討します。

また、目的に対して1つの手段であれば、その②の流れに記載すれば良いのですが、

目的の為に必要な手段が複数ある場合もあります。

その場合は、目的に必要な手段をグループ化して、そのグループで流れを作ります。

操作手順や時間軸で流れを組み立てます。

目的が達成される事を何度も確認する事が重要かと思います。


その④:「なぜ?」ではなく、「こうすると?」

手段を検討する上で、最も早い手段を検討する上で

なぜ時間がかかるのかを聞くのはタブーかと思います。

「なぜ?」と聞くより、次々提案する方が結果的に早い気がしています。

もちろん、時間がかかると思い込んでいる可能性もあるのですが

「こうすると早くなる?」といった議論の方が推進力が上がる気がします。

そして、議論する事で思い込みが解消される事も多いと感じています。


その⑤:とことんバトルする

早さを実現する為には、建設的なバトルをする事が欠かせないと思います。

「なぜ?」のバトルではなく、

「これは?」「こうしたら?」「このほうが」というバトルです。

チームでお互いに目的を達成する為の手段の案をぶつけ合うバトルです。

ときに、「そもそも」といった確認もよくあった気がしますね。

具体的な作り方、実装方法を議論するというより、目的達成のためのアプローチを議論する方がチームとして盛り上がる気がしています。

具体的な実装方法は実装する人(アサインされた人)に任せるというスタンスも重要かと思います。

バトルする上で①、②を共有、合意している事がとても重要になると思っています。

合意している事で、余計な発散を防ぐ事ができます。(と思っています)



もう少し整理する必要はありますが、この5つは重要かと思っています。

もう1点、「絵を描いて議論する」を入れようかと迷いましたが...

やっぱり、この5つかなぁ...

2020年10月9日金曜日

会話⇒やらない事が決まる⇒早く作る

 早く作るには技術はもちろん必要ですが、

要求や目的がシンプルである事が大きい!

と、今回、改めて実感しています。


そして、要求や目的をシンプルにする

とは、

こちらも改めて、やらない事を決める事

と改めて。

やらない事が多く確認出来れば

いや、違いますね。

やらない事を、チームで多く、たくさん、常に、都度、話す事で、

フォーカスが絞られていく。

という感じでしょうか。


もしかすると、この ”たくさん話をする” 事が

フォーカスを絞る事、やらない事を決める事に、

大きく作用するのかもしれません。


結果的に後戻りになったり、余計なものが作られてしまうのは、

やらない事についての話が少ないのかもしれません。


話をしていると、「そこまでいらない」といった言葉も

よく出ていたような気もします。


とすると、チームでどんな話をしているかで、

早く作れるチームかが分かるのかも?!


これって、既に分かっている事だったりして…

2020年9月18日金曜日

仮説定義VS早く試す

リーン、リーンスタートアップやアジャイルでは

顧客に価値を早く届ける為に

短いサイクルで継続的に顧客に動くものをリリースします。


しかし、動くモノ、リリースしたモノ

に価値が無いのでは意味がありません。

リリースするモノの価値について考えてみました。


リーンスタートアップでは価値があるかを検証する

という事になり、検証して学ぶことが目的なので、

検証する事、そのものに価値がる。

だから、検証する為にリリースする。


一方アジャイルは、ユーザーストーリーに価値がある事が前提かな?

と思ったのですが、

こちらもリーンスタートアップと同じ考え方が出来ますね。

ユーザーストーリーが仮説であれば、

こちらも検証する事を目的とすると、仮説であっても価値がある事となり、

価値がある事が前提でなく、検証する事が目的であれば、

リリースする動くものに価値がある事になる。


結局、価値定義が重要という事ですね。


価値定義の合意形成の中では、

考えても分からないから、とりあえず作って、試しに使ってもらう。

という葛藤があります。(ありました。)


価値定義を曖昧にしたまま、とりあえず動くものを作るとどうなるか。

定義が曖昧なので、シンプルで明確なユーザーストーリーにならない。

恐らく、仕様化、具体化のところが遅くなるのでしょう。

単純な比較は出来ないので、正確には分かりませんが。


今回、価値定義が重要だと実感する機会があったので、

再度、考えてみました。



2020年9月10日木曜日

オンラインとオフライン

オンラインミーティングが増えています。

初対面の方とのオンラインミーティングも慣れてきました。

しかし、久しぶりにオフラインで顔を合わせると、ほっとしますね。

なんでしょうね。この感覚は…


オンラインミーティングは慣れてきたとはいえ、

オンラインミーティングのやり方というか、進め方は

まだまだ試行錯誤な感じです。


どうしてもオンラインでもオフラインと同じようにやろうとしてしまう。

オフラインの時のホワイトボードと同じように

オンラインのホワイトボードを使ってみますが、同じようにはいきません。


考えてみれば、明らかに違うものなので、

そもそも同じように使う事に無理がある気もします。


頭を切り替える必要があるのだとは思うのですが…

オンラインの良いところ、悪いところをピックアップして

じっくり考えた方がイイのかな?!

いや、そもそも何が問題なのか。


あれ?!

つまり、

何を変えるのか

何に変えるのか、どのように変えるのか

って事ですね!


いつものとおり、TOCを活用しろって事ですね。





2020年8月24日月曜日

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

 SWEST22に参加しました。

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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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





2020年8月4日火曜日

なぜ、Howに夢中になるのか?!

LAMDAやTEFCAS、FRTを使って仮設検証を進めていますが、
やっぱり作り込みに夢中になってしまいます…

おっと、はっきり認識しないとダメですね!
どんなHowがイイかを常に考えてしまい、
仮設検証の意識は、どこえやら…

How思考に陥るなんてダメダメですね。

FRTも作ってるのに!

なぜでしょうね?

作る事に夢中になると、
作るモノを
 意識してしまう。
 想像してしまう。
 もっと良くしたいと思ってしまう。
 etc...

作る事に夢中になってはいけない???

仮設検証にフォーカスすべき?!
う~ン

そう意識していたつもりなのですが…

いつのまにかHowの呪縛に…
How思考、恐ろしや…

じゃくて、なんとか対策を考えなければなりませぬ…