失敗事例公開！！

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

失敗から学ぶ！（見える化と　ふりかえり）

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

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

お恥ずかしい…

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

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

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

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

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

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

小さく何を作る？

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

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

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

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

私だけでしょうか？！

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

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

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

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

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

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

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

特に私にとっては！

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

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

「何を作るか」

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

どう繋げていくか、

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

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

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

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

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

「見せる」と「加速」

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

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

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

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

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

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

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

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

創る側（プログラム作成する側）が

「見せる」ターゲット（人）をイメージ出来ると、加速するのでしょうか？！

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

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

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

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

ソフトウェア開発での「三現」とは？（その2）

前回に引き続き、

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

すると、1つの仮設が。

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

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

といって良い気がする。（仮設）

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

現場：動作環境（PCや評価基盤、試作機などなど）

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

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

という感じ？

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

現場：動作環境（PCや評価基盤、試作機などなど）

現物：ソースコード

現実：自動テスト結果（CIや単体）

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

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

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

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

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

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

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

現場：動作環境（PCや評価基盤、試作機などなど）

現物：ソースコード

現実：価値検証結果

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

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

う～ん…

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

「なぜ？」という質問がNG（NLPではNG）な事と「なぜなぜ分析」を考える上で、

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

という事で、

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

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

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

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

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

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

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

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

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

再現させながら、

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

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

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

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

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

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

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

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

バッファとゆとりとスモールリリースとFRT

 CCPMのバッファだけを監視する

という考え方はシンプルで誰でも状況把握可能かと思います。

しかし、バッファという言葉が、どうもしっくりきません。

言葉というより「バッファを入れる、付加する」というアプローチがしっくりこない感じ。

自然に入るものであるべきというか…

ゆとりの法則も、何度も読んでいますが、

必要なのは納得なのですが、”ゆとり”という言葉がどうもしっくりきません。

こちらも、言葉というより「ゆとりを取り入れる」というような

敢えて、組み込むような感じがしっくりこない感じです。

こちらも、敢えてではなく、普通に”ある”ものであるべきな気がするのです。

そして、アジャイルのスモールリリースは、”ゆとり”やバッファとは対局のようですが、

同じ考え方だと思うのです。

価値を小さく短い期間で提供していく事が、”ゆとり“やバッファを作り出す。

これでは分かり難いですね。

”ゆとり”もバッファも価値定義の曖昧さに含まれると思うのです。

最初のリリースの価値定義、リリースするモノ（仕様）は、多少なりとも曖昧さがあり、

「まずは、ここまで作ってみましょう。」

というようなスタートになる事が多い気がします。

お互いの認識合わせをしながら形にしていくようなケースが多いかと。

そうなると、いい意味で探り合いしながら進めるので、

最初は曖昧となるが、リリースを重ねる事で、認識も、価値定義も合ってくる。

そして、この曖昧さが”ゆとり“であり、バッファと言えると思うのです。

当然、後半は”ゆとり”もバッファも、少なくなりますが、

後半は何が重要であるかという認識も、作業スペースも掴めている状況なのですし、

全ての認識合わせが出来ている状況で、たとえ、短期間で一気に作り上げるといような

いわゆる“ゆとり”が無い状況だとしても、

士気は最高潮、集中力も高くなるのでミスも少なくなります。

予算の関係から、何回のリリースで完成するのかが明確でないと受け入れられない！

という事も言われますが、

これも、完成品が見えてくれば、その後の回数は分かります。

完成品が見えるまでを試作評価期間と考えるなど、対応方法はいろいろあるかと。

そうそう。こういう時こそ、曖昧な価値定義や仕様を仮説検証FRTですね！

2つのFRT（曖昧なFRTと検証した結果を書き込むFRT）

にする事で、おおよその計画となります！

仮説検証FRTについては、改めて紹介したいと思います。

と、いう事で、

スモールリリースとバッファ監視。

対局のようで、実は同じでは！？

そして、スモールリリースはしっくりきます。

なぜ削れないのか

ソフトウェアを早く作るには

目的を決める事、仕様を決める事

しかも、早く決める事が

大きく影響します。

そして、シンプルにする事

なのですが、

究極までに機能を減らす事

と表現した方が良いでしょうか。

先日、こんな相談がありました。

「余計な機能はいらない。〇〇だけが出来ればいい。そんなソフト作ってよ」

実は、この、〇〇だけが出来るソフト

の企画を数年前にしたメンバーがいたのです！

もちろん、今回のようなユーザーがいる

という仮説を立てて、サンプルを作成しました。

私含めて、周囲は全員賛同し、一気に作成しました。

競合は多くありますが、ここまでシンプルなものは

当時も今も無いのですが、

サンプル作成で終わってしまいました。

今からでも遅くない？！

と、いろいろ考えてしまいます。

競合が機能を削るのは簡単だと思いますし、

製品ラインナップにあっても良い気がします。

なぜ機能を削ったものが世の中に無いのか。

なぜ機能を削る事が出来ないのか？！

幅広いユーザーを獲得するには、機能が豊富である必要がある？

同じ開発費用で多くの機能を盛り込む必要がある？（コスト削減？）

削る理由がない？

削って売れなければ、大目玉？！

多くのアサンプションがありそうですね。

根拠は全く無いですが、ちょっとしたきっかけで変わる気もします。

どうすれば、削る方向に向かうのか。

売れれば問題無いのでしょうが、それは結果ですからね。

創る段階、企画の段階で「削る」決断となる、何かが必要ですよね。

ん？！

そもそも企画にする必要がある？

ある企画の中に潜り込ませれば、イケル？？？

これだと決断にはならないか…

削ってみようと思わせる何か。

何か手はありそうな気がしてきました。

更に考えてみたいと思います。