仮説に挑戦！

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

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

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

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

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


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

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


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

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

脳は失敗が嫌い？！

「失敗の理由を学ぶ事は、ほとんど心理的に出来ない

　人間の脳の性質は成功というのは勝手に強化されるが、

　失敗から学ぶ事は非常に難しい」

『考える力』より抜粋

すごく納得しました。

振返りで失敗を認知させる事が難しいと感じていたところに、

偶然、この書籍と出会いとてもラッキーでした！

これで、改めて、

難しい事にチャレンジしている事

出来なくて当たり前だった事

を認識出来ましたので、

改めてチャレンジしていく決意が固まりました。

だから、失敗ではなく、

なんでもかんでも問題解決という表現をするんですね。

なるほど！

で、更に、羽生さんの書籍で面白いのが無いかと探していたら、

『捨てる力』

を発見！

これは、まさしくセットベースの事では無いか！？

という事で、夏休みの読書用として早速購入！

セットベース思考を浸透させるヒントを多く得られる事を期待しています！

何が無くてもフィードバック！

最近、フィードバックについて考えています。

常にフィードバックがあれば、失敗開発などない
デスマーチなど無いのでは！？
とさえ、考えるようになりました。

しかしながら、”常に”が問題です。

ソフトウェア開発では特に、
フィードバックが無いに等しい作業が多いですよね。

だから短いサイクルでの振返りが重要！
という事だと思うのですが、

もちろん、アジャイルでは当たり前の事で、
これまでも、そのように取り組んできたのですが、

最近、この振返りが機能していない気がしています。
イテレーションや、スモールリリースしていても
振返りが、今一つな感じがしています。

今一つなのは、
振返りで上がる”問題”が、問題では無く、解決策だったり、
誰が困る問題なのかが不明な問題が上っている事
つまり、問題として上がるべき内容が上げられていない点ですね。

当然、問題が問題で無いのであれば、
改善も的外れとなります。

なぜ、そうなるのか？！

実は、これが受託と深い関係があるのでは？！
と、最近思うようになりました。

オンサイト顧客など、顧客と近くで（場所ではなく意識）
やれていると、比較的常にフィードバックを得られやすいのですが、
顧客との意識が遠くなると、フィードバックが極端に少なくなる傾向にある気がします。

単純には、顧客を意識すれば良い！
という事なのですが、これがなかなか難しく
意識するだけでは、結果的にフィードバックは得られない事も多く、

常に先読みして、こちらから仕掛けていかないと
フィードバックは得られないような気がしています。

常に先読みするのも、疲れますよね....

そんな複雑な事ではなく、もっと単純な事のような気がするのですが....
これって、やはり作るソフトウェアが複雑になり過ぎている為に、
複雑化しているのでしょうか？？？

ちょっとした意識の仕方、共有に仕方で
ものすごく変わる気がするのですが....

う～ん...

フィードバックを常に得る為に何が必要なのか。
悩み続けています。