2021年4月20日火曜日

スピード感

昨年から「スピード感」という言葉に振り回されている気がします。

自分でも良く使ってしまう気がしますが、この言葉は、とても曖昧でやっかいですね。


「遅れている」は、必ずといっていいくらい、

具体的にどのくらい遅れているかをハカろうとしますが、

「スピード感」は、ハカろうとしない傾向にある気がします。

なぜでしょうか?


大きくは、使い方、活用シーンが違いそうですが、

聞いてる側としても、

漠然と「今より早く」、「更に早く」、などなど

それぞれが、漠然とした認識を持つので、

あまり数値化する意識にならない気がします。


それぞれ違う認識である可能性が非常に高いと思うのですが、

結果的に、それぞれがレベルアップ、スピードアップすれば、

特に問題は無いですね。


問題となるのは、スピード感が無いなどと否定された時ですね。

スピードアップしたと感じる人と、

スピードアップしていないと感じる人がいる

場合には、具体化が必要かと思います。


しかし、このようなギャップがある場合でも、数値化しない傾向にある気がします。

漠然とした課題となっているからでしょうか。

となると、

今起きている事の把握、現状把握が必要な気がしますね。

現在状況の共通認識という方が分かり易いですね。

つくづく、現状把握、現状認識、

いやいや、現在状況の共通認識は大事ですね。

2021年4月9日金曜日

気づきを掴む!

 少し前ですが、

現状を知る為のヒアリングをしました。

ほとんど何も知らない業界の現状把握だった事もあり、

あちこち話が飛ばないように、時間の流れにそって話が出来るように

業務の流れを想像し、資料にしました。

更には、間違ってても指摘してもらう事で、話のとっかかりとなりますし

それがそのまま現状把握になると考えました。


すると、当日、驚く結果となりました。

とっかかりは資料なので、まずは間違い、相違点があれば指摘して下さい

とお願いしたのですが、

その回答は「この資料の通りです。」

という事でした。


ところが、1つ1つ資料を確認していくと、

大きく異る点がありました!

先方は、大きく違うとは認識していません。


あぶなく、気付きを逃すところでした!!

結果として、大きく2つの収穫となりました。

1)相違点については、気にもとめない些細な事という認識である

2)こちらの認識と手順が違う事


それともう一つ。

手順を分解するのは、JOBS法(Jobs to be done)

のアプローチで、細かく分解しないと効果は無いものだと思っていましたが、

分からない事が多い状況でも、分解の粒度が大きくても、

効果があるものだという気づきを得ました。




2021年3月24日水曜日

失敗事例公開!!

最近やってしまった失敗をSpeaker Deckに公開にしました!

失敗から学ぶ!(見える化と ふりかえり)

アサンプションを全く疑えてない失敗事例です。

他人事だとツッコめるけど、自分だと甘々な事が露呈してしまいました。

お恥ずかしい…


改めて資料にしてみると、

失敗事例は分かり易いですが、

対処方法は1つではないので、どう表現するかが難しい…

この点も、もっと勉強が必要ですね。


最近は、資料で紹介している「G+4箱」を書くようにしていますので、

引き続き、事例資料も作っていこうと思います。

2021年3月8日月曜日

小さく何を作る?

久しぶりにアプリ作成しました。

改めて、作り出すと夢中になってしまうなーと実感しています。

ある程度完成するまでは、他の事は考えたくなくなりますね。

いや、他の事は全く考えなくなります。

私だけでしょうか?!


大昔は、コンパイルに時間が掛かったりなど、

いろいろと隙間時間があり、

その時に、他の事を考えたり出来たのですが、

いまは、ほぼほぼPC上で完結する事が多いので、

テストもガンガン書きたくなるし…

ある程度のところまでは集中しちゃいますよね。


だから、こそ余計に小さく作る事が重要になると思っています。

特に私にとっては!


小さく作って繋げていく。

そして、小さく作るために必要なのが、

「何を作るか」

この「何」をいかに小さくするか

どう繋げていくか、

がとても重要になってきます。


この「何」を決めるには、

ソフトの事も知りつつ、目的もしっかり定めてフォーカスする必要があります。

そして、目的をフォーカスにするのは、やっぱりFRTですね!


このスキルは、今後もしばらく重要になってくると考えています。



2021年2月19日金曜日

「見せる」と「加速」

最近はデモする機会がめっきり減りました。

オンラインでの交流はあるものの、デモの機会は少なくなりました。

そんな中で、久しぶりにデモの機会があり

改めて、誰かに見せる事は大事だと実感しました。


まず、「見せる」と決めた時点で変化があります。

デモ作りのモチベーションが圧倒的に違いました。

内部デモなどと違い、外部の人に見せるとなると、いろんな事が一気に加速しました。

みんな飢えてただけ???


創る側(プログラム作成する側)が

「見せる」ターゲット(人)をイメージ出来ると、加速するのでしょうか?!

イメージ出来るからモチベーションが上がるのでしょうか?


結果、2週間弱で、簡単な3つのデモアプリを作成しました。

簡単とはいえ、スピード感はあったと思います。


「見せる」事が決まると、加速した貴重な体験でした。





2021年2月8日月曜日

ソフトウェア開発での「三現」とは?(その2)

前回に引き続き、

三現主義とソフトウェア開発について、モヤモヤと考えています。


すると、1つの仮設が。


タスクボードやバーンダウンチャートが

現状、今を表しているのであれば、三現主義の考え方が浸透している(実践されている?)

といって良い気がする。(仮設)


であるならば、この場合の三現は…

現場:動作環境(PCや評価基盤、試作機などなど)

現物:ソースコード、バイナリ

現実:いま動作している状況、この後の残りの何にフォーカスすべきかの共通認識


という感じ?

現実が、いまいちな感じがします。


現場:動作環境(PCや評価基盤、試作機などなど)

現物:ソースコード

現実:自動テスト結果(CIや単体)


バイナリは見ても分からないので、現物から削除しました。

現実が曖昧だったので、誰が見ても同じ認識となるテスト結果にしてみました。

現場は、開発環境も含むかと思いましたが、曖昧さは排除出来ないと思うので、

曖昧さは残りますが、いちおう動作環境は定義しますし、

誰もが同じ認識となるので動作環境としました。


しかし、これだと創るものが定義された状態が前提となる気がします。

価値提供を前提とするのであれば、


現場:動作環境(PCや評価基盤、試作機などなど)

現物:ソースコード

現実:価値検証結果


という感じでしょうか???

しかし、これだと現実が曖昧かな…

う~ん…

2021年1月18日月曜日

ソフトウェア開発での「三現」とは?

「なぜ?」という質問がNG(NLPではNG)な事と「なぜなぜ分析」を考える上で、

三現主義は「なぜなぜ分析」とセットだと思いますので外せません。

という事で、

三現主義、「現場」「現物」「現実」ですが、

ソフトウェア開発では具体的に、何になるのか考えてみました。


しかし、生産と開発の違いがありすぎて、全く、まとまりません…

まとめようとすると、違いが次々に上がってくるのでフォーカス出来ません…


そんな中、気づいた事が1つ。

ソフトウェア開発でも、事実を掴む、把握する為の手段として三現主義を活用しています。

それは、不具合分析、解析です。


ソースコードデバッグが出来ない場合において、最も効果的に活用されていますね。


不具合分析をする場合、現象を何度も再現させて確認します。

再現させながら、

ソフトウェアがどんな動きをしているかを頭で考えて、想像してシミュレーションします。

つまり、現象から「現実」を掴む為に、ソースコードを見ながら想像します。

ソースコードは「現物」ですね。


「現場」は再現可能であれば、実際の「現場」に行く事はないですが、

再現不可能な場合は、「現場」で分析、解析します。


何度も再現させる事や、不具合の症状や現象から考えるのは、

まさしく、三現主義だと気づきました。

意外と身近で使ってるのだと、改めて感じた次第です。