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

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

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

という事で、

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

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

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

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

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

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

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

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

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

再現させながら、

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

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

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

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

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

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

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

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

なぜなぜ分析では言い訳となる？

 「なぜ？」と聞かれると本能的に言い訳を考える。

また、否定的なニュアンスがある。

と。

NLPの本を読んでいて目についた。

（『手にとるようにNLPがわかる本』）

納得するところはある。

つい、言ってしまいがちな「なぜ？」

とても便利な「なぜ？」

では、どうするか。

「どうしたの？」と言い換えるなど、

いくつか言い換えの例があったが、

場面毎に変える必要がありそう。

ソフト開発業務のありそうな場面を思い浮かべると

書籍の例ではしっくりくるものは無かった。

というか、「なぜなぜ分析」はNLPとしてはNGって事か！

ずっと、ソフト開発には馴染まないと思っていました。

不思議な感じはありません。

理由のひとつは、今回の「否定的なニュアンス」かと思う。

ソフト開発での不具合混入原因などに活用すると、

どうしても、担当者を否定する方向になってしまう。

うまく、人ではなく、仕組みやプロセスの方向に誘導しても、

どうしても、担当者を否定している感じが残る気がしていました。

その答えが見つかった気がします。

ソフト開発は人以外の製造工程はないのですが、

製造などでは、人以外にも関係するモノや工程、過程などがあるので

人を否定している感じにはなり難いのだと思っています。

TOCを知ってからは、TOCの方が分析が早かった実績などもあり、

なぜなぜ分析は活用していませんが、

それでも、「なぜ？」は便利ですよね。

日常で、けっこう言ってる気がします。

これを言い換える為には、一回飲み込む必要がありそう。

しかも、場面毎に変えるのも難しそう…

どの場面でも活用可能な言葉はないだろうか？？？

う～ん…

場面毎に変えるしかなさそうですね…