今までは、価値検証には、もっぱらFRTの変形バージョン、4箱（G+4箱）を使っていましたが、
ソリューション活用ニーズの逆である非活用ニーズ（競合ニーズ含む）を
文章化、明確化、見える化することで、
ソリューション訴求ポイントや、顧客価値を改めて検証します。
今を変えたくないニーズは、どこにでもあるかとも思いますので、
それを打破するくらいの価値があるのか？
それらを打破する為の訴求ポイントは何か？
などなどを議論できることを期待してクラウドを活用してみます。
というか、今回始めてクラウドで検証してみます。
もしかすると、そこまで行かないかもしれませんが…
先月、とある店舗の”実践躬行”な店長さんとお話する機会がありました。
店舗や、その周囲も含めて盛り上げたいという熱い思いのある方で、
いろいろと提案するだけでなく、実際に自らも動く方で、
先々月も一緒にとあるチャレンジをしました。
まさしく”実践躬行”な方なのです。
そんな、素敵な人なのですが、
一部では、煙たがれれている…らしいのです。
どうやら「熱い思い」と「行動力」が原因のようです。
恐らく「熱い思い」だけであれば、
煙たがられるまではいかないと思うのですが、
実際に、行動を起こすので、「また…」
みたいな反応となるようなのです。
現状に甘えず、現状維持では納得せず、
常に前へ、常にチャレンジする姿は、
煙たがられる事もあるかもしれませんが、
それ以上の引力にもなり、人々を引き付ける気がしました。
私も惹きつけられた一人ですね。
口だけではなく、行動に、その行動が人を巻き込み、更に大きな動きに！
その結果は、必ず成果となるのだと実感しました。
今回、共にチャレンジさせて頂き、勉強にもなりましたし、
何より勇気を頂きました。
ありがとうございました！！
先日、スピード感の違いを痛感しました。
こちらとしては、仮説検証を可能な限り早く実施したいのですが、
協業パートナーさんは、１つ１つ、じっくり検証したい
というコトが分かりました。
直感で、この速度感の違いは、共存出来ないだろうと感じました。
これは、仮説検証内容を具体化する事で浮き彫りになりました。
具体化する事で、このような事も浮き彫りになるのだと、
改めて実感しています。
具体化は重要ですね。
直感で感じた事を、再度、本当に共存出来ないかを再考してみます。
目指す方向性は同じです。
検証したい内容も同じです。
違うのは、時間軸だけです。
優先項目が違うという感じでしょうか。
時間軸というより、パートナーは確実性を重要視している。
我々は、スピードを重要視している。
となると、
パートナーに合わせつつ、早く出来る事を提案していく
という感じでしょうか。
また、今後加速する可能性も無くは無いとも思うので、
まずは、
パートナーに合わせつつ、早く出来る事を提案していく
観光や、xR関連でいくつかの実験が始動しています。
顧客開発モデルでいう、顧客発見＆顧客実証のループが、いくつか開始されました。
今年の春に、小さなデモから始めた活動ですが、
やっとこ、ここまで来ました。
小さなデモをベースにTOCやリーンの考え方を盛り込んだデモプランシートなどを活用し、
仮説検証を繰り返し、活動してきました。
これまで、仮説検証は様々な場面で実施、実験してきましたが、
今回、大きく異る１点あります。
それは、他社、他の団体と連携した実験である事
です。
これが、ここまで漕ぎ着けた、推進力が落ちなかった
大きな要因でもあると思っています。
連携する事で、やるべき事は増えますが、
それ以上に、連携している方達の「熱」を感じる事も多くあり、
ソフトを創る以外のアクションにおいても突破力が落ちなかったと思っています。
ここまで、とても有意義な連携が出来ていると感じています。
しかし、ここからが本番です。
VUCAな昨今、何がどのように受け入れられるか、
どのような顧客が発見出来るのか、
は、全く予見出来ません。
分からないからこそ、実験で終わらせない為にも、
仮設とその検証が重要です。
仮説検証を繰り返して、
進化するループになるかが、勝負です！
手段の目的化はよくある事なのですが、
これを回避するのは一筋縄ではいきません。
改善活動なども、限られた時間の中での活動となるので
どうしても、手が付けやすい手段に走ってしまい、手段が目的化してしまいます。
その多くは、イメージが無い為なのだろうと想像しています。
手段を実施する事はイメージし易いですし、アピールもし易い。
ですが、もう一歩、いや、もう３歩踏み込んで、踏み出して？
考える事が出来れば、変われるのかな。と思います。
その１：その手段の結果をイメージする
その２：結果イメージを見える化する
その３：目的の確認＆他の手段と比較する
しかししかし、「その２」「その３」が難しい…
イメージまではしても、見える化や比較までは
「時間が無い」という魔法の言葉で消されてしまいます…
そうなると、時間を作るのは現実的では無いので、
時間を無くても出来る、という方向に向けるしかないのですが…
何かを仕掛けても、時間が無いと断られるので、手の出しようがなくなります。
そうなると、「時間が無い」魔法に対抗するのではなく
時間が無い魔法が効かなくなる文化、風土を作るしかない気がします…
先日の社外の方との議論で、思わぬ発見がありました！
6月に紹介した、デモプランシートについて、
デモで得たい情報が何かを１つに絞る事で、
どんな状況にも対応出来るというか、
方向性がぶれないというか、
聞きたい事が聞ける、得たい情報が得ている状況が作れている気がしました。
ここでいう１つに絞る内容は、具体的なものではありません。
例をあげると、
「何かしらのアイディアを引き出す」
や、
「具体的な期待している効果を聞き出す」
などです。
そのためデモプランシートの内容は、
聞き出すタイミングが複数ある傾向にあります。
この何度も聞くタイミングを事前にシミュレーションする事が
また、タイミングを見て仕切り直せるというか、
想定と違っても方向性がブレない対策になってるのかもしれません。
このあたりも、もう少し分析すると、
何が、どのように効果があるのかが見えてきそうですね。
「フォーカスする」
という観点で見ると、また違うように見えるのが興味深くもあり、楽しく思います。
これでまた、デモプランシートが成長しますね。
先日、社内で
プロジェクト成功の定義は？
という議論をしました。
アジャイルやリーンとしては「価値提供」かと思います。
素早く、価値を提供出来る事が成功かと。
これをもっと具体化した目標値が達成出来れば、
成功かと思います。
議論では、
問題があっても対応出来ていれば成功
イテレーションが回せていれば成功
などなど。
どれも成功だと思いますが、
議論になるという事は、
成功基準をプロジェクト開始前に決めていない証明でもありますね…
しかし、プロジェクトとしては成功しても、
エンジニアとしては納得行かない点も多くありそうですね。
あそこは、あーしておけばよかったー
とかとか
設計視点や、コード視点など、
それぞれ視点を変えると、後悔が無い事の方が少ない気もします。
プロジェクトとしての成功
個人としての成功
などなど、複数の定義はあってイイ気がしますね！
しかししかし、改めて考えると目標達成と後悔は違いそうですね。
目標は達成しても後悔する事はありそうです。
目標値はあくまで目標値で
完璧な仕事というか、完璧な業務というか、
後悔のない仕事というか、後悔のない業務
は難しいですね。
改めて、
目標以外の視点で「ふりかえる」事も大事ですね。
仮説を立てて、聞くではなくて、
仮説を立てて、見せて、見る
昨年あたりから、
ヒアリングは何かが違う気がしています。
単純にインタビューのテクニックが無いだけとも言えますが…
何か、違和感がずっとある状態です。
そして、最近、再度『アントレプレナーの教科書』を読んで、
顧客開発のファーストステップである
顧客発見フェーズでのヒアリングが違うのかな
って、思い始めました。
顧客発見フェーズにて、
発見できた顧客や支援者に対してのヒアリングは問題無い？
いや、ここはまだ分かりません。
発見した顧客へのヒアリングは
相手も本気で回答する可能性は高い気がします。
ただ、これまでのヒアリング経験では、
相手が本気で考えていないというか、本気で答えていない気がしています。
フォーカスも合っていない感じがありました。
いまは、それよりも、
動くものを見せて、相手の反応を見る
方が収穫が多いと感じています。
相手の本気度も分かり易くなるというか、
事実が発見し易くなるというか、
フォーカスも合っている感じがします。
いや、フォーカスが合っているか、ずれているかが分かり易いだけかもしれません。
具体的な話になり易い気もします。
この点ですかね。
違和感は。
もちろん、どちらも仮説があるのは前提条件です。
ヒアリングより、見せる＆見る
問いかけるより、見せる事、
聞くより、見る事
そのほうがフォーカスも合い、具体的な話になり易い。
もしかすると、ヒアリングも基本は、聞いて、相手の反応を見る
という事なのかもしれませんが…
この違和感、もう少し考えたいと思います。
県内の方とは、対面でのミーティングが増えつつありましたが、
再び、オンラインでのミーティングが増えています。
対面で何度かお会いしているので、
オンラインでもスムーズにコミュニケーションが取れています。
一度対面していると、その後がオンラインでも
対面と変わらない成果となるといったデータもありますが、（参考：職場の人間科学）
それも納得です。
どちかというと、この状況に
生気を取られているというか、元気が奪われている感があります。
この状況に負けない為に
なんとか元気を取り戻そうと、熱量を取り戻そうと
いま出来る形でのアクションやイベントを作っています。
ただ、いまひとつ盛り上がらない感じがします。
オンラインでは熱伝導率が悪い？！
などとも思います。
オンラインでなくても、いちど下がったものを再び盛り上げるのは難しいですね。
アクションやイベントだけでなく、
オンラインで熱伝導率を上げる方法を考えなくては！
先日、とある高校の「総合的な探求の時間」の社会人講師として
お話しました。
当初は、教室でAR体験などしてもらいながらお話する予定でしたが、
前日に急遽オンラインとなりました。
当然、準備していた体験は出来ません！
全90分（質問で15分くらい）の中で、体験で40分くらいで考えていましたので、
まるまる75分、お話しをする事になりました！
オンラインで、高校生を飽きさせないようにしながら
何をお話するか？！
しかも、準備する時間はほとんどありません！
頭の中にUDEクラウドが浮かびます…（納期と内容充実のジレンマですね！）
考え、悩んだ末、
やっぱりオンラインでも、高校生達とインタラクティブにやりとりしたい！
対話、会話をする事で、飽きない時間に出来るのでは？！
という事で、
お話する小テーマをいくつか作っていたので、
小テーマ（言葉）１つだけを1スライドに大きく記載したスライドを作成し
学校で印刷＆黒板に貼り出してもらいました。
そして、当日は、そこに投票してもらい、話をしました。
投票などで、体を動かす事や、何に投票するかを考える事、
投票理由を聞く事などで、
興味を引く事は出来た気がします。
このようなちょっとした工夫がオンラインでは重要な気がしました。
同じ釜の飯を食う ではないですが、
オンラインでも同じものを見て、持って、触る
事で、一体感というか、共同体的な感じが出る気がしました。
工夫、大事ですね！
以前、簡単なマルチタスクのテストで、
私は非マルチタスクよりマルチタスクの方が早い結果が出たのですが、
それと、最近、チャットで仕事を進める事が多く、
複数プロジェクトが走っている状態での指示、確認に
チャットが向いているなー
と実感する事が多々あり、
活用するツールで、マルチタスクの負荷や効率はある程度改善出来る？！
と、ふと思いました。
マルチタスクが効率悪いのは疑う余地はなく、
私のテスト結果は、たまたま だと思っています。
チャットの短いコミュニケーションは、短い故に
ちょこちょこアドバイスする程度であれば、
比較的マルチタスクの状態でも、脳の切り替え負荷も小さくなる気がしました。
ドキュメントチェックなども
ちょこちょこ追加、変更して共有してもらえると
確認も短時間で終わるので、切り替え負荷が小さく感じました。
となると、やはり使い方も関係しますね。
結局、どんな事も、状況に応じた活用ツールの選択と使いかたですね！
先々月、とある活動にて、高校生二人から相談を受けました。
こんな事したいのですが、出来ますか？
という相談で、「こんな事」は、以下の通り。
1）文化祭で音楽を流したい。
2）時間で流す音楽を変えたい。それまでは同じ音楽を流し続けたい。
ソフトウェアで出来る事、
ARで出来る事のデモ活動で人が繋がっています。
我々も技術で何が出来るかを知ってもらう為にデモしていますが、
こんなにも繋がるものかと驚いています。
最も大きい要因は、人の力だと思います。
人が人へ伝える力が大きいのだろうと想像しています。
しかし、それだけでは繋がらないと思います。
どんな要因の影響が強いのでしょうか？
デモの内容が伝え易い？面白い？
エンジニアがやっているから興味を持ってくれる？
珍しい事していると思われている？
我々の「活用してもらう為に、知ってもらう」が刺さった？
実は、知りたいと思っていた潜在ニーズがあった？
たまたま？
などなど考えますが、どれもしっくりきません。
となると、やはり、人の力のみ
という事でしょうか。
活動を知ってくれた人、繋げてくれた人のみなさんの力でしょうか。
今年の4月から開始して、ここまで繋がるのは、一人一人の力ですね。
以前、次をつくる
で、実施したデモプランシート
以前紹介した内容は、以下です。
・背景（デモ実施の背景）
・狙い（今回のデモで狙うこと、その後に狙うこと）
・誰にデモするか
・デモの内容
・デモ後にどうなる事を期待しているか
・何に注力するか
何回か実施していますが、デモ後の期待が実現出来ています。
かつ、この為に実施したのですが、次へ繋げられています。
大きくは変わっていませんが、
今は、こんな感じのシートになっています。
・背景（デモ実施の背景）
・狙い（今回のデモで狙うこと、その後に狙うこと）
・WHO：誰にデモするか
・DEMO：デモの内容（実施内容、手順、どうやって次に繋げるか）
・AFTER：デモ後にどうなる事を期待しているか
・POINT：AFTERを確実にする為のポイント、何を引き出すか
背景、狙いはヘッダーのような形で、
WHO以降がA4を縦半分にして、実施後の結果を書き込むようにしています。
今のところ、
これまで、デモを実施する事に囚われていたのが
見せた人から何を引き出すか！
に注力出来ていて、Afterの内容が全てでは無いですが、達成出来ています。
もう少しシートは進化しそうですね。
また進化したら公開します。
デモのネタ作りの為に、試作に励む日々が続いていますが、
試作でも、セットベースは有効！
という事件が起こりました。
新たなチャレンジや、知識が浅い技術を活用すると
何かとトラブルにお会いします。
その回避策を複数案上げておくだけで、セットベース開発と言えるかと。
もしくは、はじめから仕様として実現案を複数準備しておくのも
セットベース開発と言えるかと。
この2つが早く動かす事、早くデモを見せる事に大きく寄与します。
これが、ダメなら、次はこれ！
と、次々にアタックする事で早くなる。
という感じをイメージするでしょうか。
それもありますが、違うパターンもあります。
これがダメなら、次はこれ！
と試す中で、あれ？
前のこれは、こうすればトラブル回避になる！
といった新たな案が出るのです。
そして、その案で、見事にトラブル回避に成功した事例が、先日ありました。
こういう事例があると、モチベーションも上がりますね。
モチベーションが上がると、更に早くなる！
セットベース開発で、開発が早くなる！！
最近、デモの機会が増えています。
製品のデモではなく、
新たな技術を活用する為のデモです。
アイディアレベルなので、デモを継続して進化させる必要があります。
進化させる為にも、
せっかく頂いたデモの機会を最大限に活かす＝次のデモへと繋げる必要があります。
その為の試行錯誤が続いています。
誰にデモするか、どのような背景か
などなど、状況により、目的や見せ方を変える必要があります。
そして、何より、次のデモへと繋げる必要があります。
事前に様々なケースを想定していないと、当日の対応がはちゃめちゃになります…
やはり、キチンと言語化しておこう！
という事で、デモプランシート作成し、試行中です。
記載内容は、こんな感じ。
・背景（デモ実施の背景）
・狙い（今回のデモで狙うこと、その後に狙うこと）
・誰にデモするか
・デモの内容
・デモ後にどうなる事を期待しているか
・何に注力するか
いまのところ、事前に話すべき事、議論すべき事は出来ている感じです。
さてさて、狙いどおりの結果が出る確率はどうでしょうか？？？
次のデモに繋がる確率はどうなるでしょうか？？？
昨年から「スピード感」という言葉に振り回されている気がします。
自分でも良く使ってしまう気がしますが、この言葉は、とても曖昧でやっかいですね。
「遅れている」は、必ずといっていいくらい、
具体的にどのくらい遅れているかをハカろうとしますが、
「スピード感」は、ハカろうとしない傾向にある気がします。
なぜでしょうか？
大きくは、使い方、活用シーンが違いそうですが、
聞いてる側としても、
漠然と「今より早く」、「更に早く」、などなど
それぞれが、漠然とした認識を持つので、
あまり数値化する意識にならない気がします。
それぞれ違う認識である可能性が非常に高いと思うのですが、
結果的に、それぞれがレベルアップ、スピードアップすれば、
特に問題は無いですね。
問題となるのは、スピード感が無いなどと否定された時ですね。
スピードアップしたと感じる人と、
スピードアップしていないと感じる人がいる
場合には、具体化が必要かと思います。
しかし、このようなギャップがある場合でも、数値化しない傾向にある気がします。
漠然とした課題となっているからでしょうか。
となると、
今起きている事の把握、現状把握が必要な気がしますね。
現在状況の共通認識という方が分かり易いですね。
つくづく、現状把握、現状認識、
いやいや、現在状況の共通認識は大事ですね。
少し前ですが、
現状を知る為のヒアリングをしました。
ほとんど何も知らない業界の現状把握だった事もあり、
あちこち話が飛ばないように、時間の流れにそって話が出来るように
業務の流れを想像し、資料にしました。
更には、間違ってても指摘してもらう事で、話のとっかかりとなりますし
それがそのまま現状把握になると考えました。
すると、当日、驚く結果となりました。
とっかかりは資料なので、まずは間違い、相違点があれば指摘して下さい
とお願いしたのですが、
その回答は「この資料の通りです。」
という事でした。
ところが、１つ１つ資料を確認していくと、
大きく異る点がありました！
先方は、大きく違うとは認識していません。
あぶなく、気付きを逃すところでした！！
結果として、大きく2つの収穫となりました。
1）相違点については、気にもとめない些細な事という認識である
2）こちらの認識と手順が違う事
それともう一つ。
手順を分解するのは、JOBS法（Jobs to be done)
のアプローチで、細かく分解しないと効果は無いものだと思っていましたが、
分からない事が多い状況でも、分解の粒度が大きくても、
効果があるものだという気づきを得ました。
最近やってしまった失敗をSpeaker Deckに公開にしました！
アサンプションを全く疑えてない失敗事例です。
他人事だとツッコめるけど、自分だと甘々な事が露呈してしまいました。
お恥ずかしい…
改めて資料にしてみると、
失敗事例は分かり易いですが、
対処方法は1つではないので、どう表現するかが難しい…
この点も、もっと勉強が必要ですね。
最近は、資料で紹介している「G+4箱」を書くようにしていますので、
引き続き、事例資料も作っていこうと思います。
久しぶりにアプリ作成しました。
改めて、作り出すと夢中になってしまうなーと実感しています。
ある程度完成するまでは、他の事は考えたくなくなりますね。
いや、他の事は全く考えなくなります。
私だけでしょうか？！
大昔は、コンパイルに時間が掛かったりなど、
いろいろと隙間時間があり、
その時に、他の事を考えたり出来たのですが、
いまは、ほぼほぼPC上で完結する事が多いので、
テストもガンガン書きたくなるし…
ある程度のところまでは集中しちゃいますよね。
だから、こそ余計に小さく作る事が重要になると思っています。
特に私にとっては！
小さく作って繋げていく。
そして、小さく作るために必要なのが、
「何を作るか」
この「何」をいかに小さくするか
どう繋げていくか、
がとても重要になってきます。
この「何」を決めるには、
ソフトの事も知りつつ、目的もしっかり定めてフォーカスする必要があります。
そして、目的をフォーカスにするのは、やっぱりFRTですね！
このスキルは、今後もしばらく重要になってくると考えています。
最近はデモする機会がめっきり減りました。
オンラインでの交流はあるものの、デモの機会は少なくなりました。
そんな中で、久しぶりにデモの機会があり
改めて、誰かに見せる事は大事だと実感しました。
まず、「見せる」と決めた時点で変化があります。
デモ作りのモチベーションが圧倒的に違いました。
内部デモなどと違い、外部の人に見せるとなると、いろんな事が一気に加速しました。
みんな飢えてただけ？？？
創る側（プログラム作成する側）が
「見せる」ターゲット（人）をイメージ出来ると、加速するのでしょうか？！
イメージ出来るからモチベーションが上がるのでしょうか？
結果、2週間弱で、簡単な3つのデモアプリを作成しました。
簡単とはいえ、スピード感はあったと思います。
「見せる」事が決まると、加速した貴重な体験でした。
前回に引き続き、
三現主義とソフトウェア開発について、モヤモヤと考えています。
すると、1つの仮設が。
タスクボードやバーンダウンチャートが
現状、今を表しているのであれば、三現主義の考え方が浸透している（実践されている？）
といって良い気がする。（仮設）
であるならば、この場合の三現は…
現場：動作環境（PCや評価基盤、試作機などなど）
現物：ソースコード、バイナリ
現実：いま動作している状況、この後の残りの何にフォーカスすべきかの共通認識
という感じ？
現実が、いまいちな感じがします。
現場：動作環境（PCや評価基盤、試作機などなど）
現物：ソースコード
現実：自動テスト結果（CIや単体）
バイナリは見ても分からないので、現物から削除しました。
現実が曖昧だったので、誰が見ても同じ認識となるテスト結果にしてみました。
現場は、開発環境も含むかと思いましたが、曖昧さは排除出来ないと思うので、
曖昧さは残りますが、いちおう動作環境は定義しますし、
誰もが同じ認識となるので動作環境としました。
しかし、これだと創るものが定義された状態が前提となる気がします。
価値提供を前提とするのであれば、
現場：動作環境（PCや評価基盤、試作機などなど）
現物：ソースコード
現実：価値検証結果
という感じでしょうか？？？
しかし、これだと現実が曖昧かな…
う～ん…
「なぜ？」という質問がNG（NLPではNG）な事と「なぜなぜ分析」を考える上で、
三現主義は「なぜなぜ分析」とセットだと思いますので外せません。
という事で、
ソフトウェア開発では具体的に、何になるのか考えてみました。
しかし、生産と開発の違いがありすぎて、全く、まとまりません…
まとめようとすると、違いが次々に上がってくるのでフォーカス出来ません…
そんな中、気づいた事が１つ。
ソフトウェア開発でも、事実を掴む、把握する為の手段として三現主義を活用しています。
それは、不具合分析、解析です。
ソースコードデバッグが出来ない場合において、最も効果的に活用されていますね。
不具合分析をする場合、現象を何度も再現させて確認します。
再現させながら、
ソフトウェアがどんな動きをしているかを頭で考えて、想像してシミュレーションします。
つまり、現象から「現実」を掴む為に、ソースコードを見ながら想像します。
ソースコードは「現物」ですね。
「現場」は再現可能であれば、実際の「現場」に行く事はないですが、
再現不可能な場合は、「現場」で分析、解析します。
何度も再現させる事や、不具合の症状や現象から考えるのは、
まさしく、三現主義だと気づきました。
意外と身近で使ってるのだと、改めて感じた次第です。
CCPMのバッファだけを監視する
という考え方はシンプルで誰でも状況把握可能かと思います。
しかし、バッファという言葉が、どうもしっくりきません。
言葉というより「バッファを入れる、付加する」というアプローチがしっくりこない感じ。
自然に入るものであるべきというか…
ゆとりの法則も、何度も読んでいますが、
必要なのは納得なのですが、”ゆとり”という言葉がどうもしっくりきません。
こちらも、言葉というより「ゆとりを取り入れる」というような
敢えて、組み込むような感じがしっくりこない感じです。
こちらも、敢えてではなく、普通に”ある”ものであるべきな気がするのです。
そして、アジャイルのスモールリリースは、”ゆとり”やバッファとは対局のようですが、
同じ考え方だと思うのです。
価値を小さく短い期間で提供していく事が、”ゆとり“やバッファを作り出す。
これでは分かり難いですね。
”ゆとり”もバッファも価値定義の曖昧さに含まれると思うのです。
最初のリリースの価値定義、リリースするモノ（仕様）は、多少なりとも曖昧さがあり、
「まずは、ここまで作ってみましょう。」
というようなスタートになる事が多い気がします。
お互いの認識合わせをしながら形にしていくようなケースが多いかと。
そうなると、いい意味で探り合いしながら進めるので、
最初は曖昧となるが、リリースを重ねる事で、認識も、価値定義も合ってくる。
そして、この曖昧さが”ゆとり“であり、バッファと言えると思うのです。
当然、後半は”ゆとり”もバッファも、少なくなりますが、
後半は何が重要であるかという認識も、作業スペースも掴めている状況なのですし、
全ての認識合わせが出来ている状況で、たとえ、短期間で一気に作り上げるといような
いわゆる“ゆとり”が無い状況だとしても、
士気は最高潮、集中力も高くなるのでミスも少なくなります。
予算の関係から、何回のリリースで完成するのかが明確でないと受け入れられない！
という事も言われますが、
これも、完成品が見えてくれば、その後の回数は分かります。
完成品が見えるまでを試作評価期間と考えるなど、対応方法はいろいろあるかと。
そうそう。こういう時こそ、曖昧な価値定義や仕様を仮説検証FRTですね！
2つのFRT（曖昧なFRTと検証した結果を書き込むFRT）
にする事で、おおよその計画となります！
仮説検証FRTについては、改めて紹介したいと思います。
と、いう事で、
スモールリリースとバッファ監視。
対局のようで、実は同じでは！？
そして、スモールリリースはしっくりきます。
