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

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

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

という事で、

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

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

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

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

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

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

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

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

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

再現させながら、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と、いう事で、

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

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

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