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

前回に引き続き、

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

すると、1つの仮設が。

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

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

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

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

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

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

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

という感じ？

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

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

現物：ソースコード

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

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

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

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

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

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

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

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

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

現物：ソースコード

現実：価値検証結果

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

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

う～ん…

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

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

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

という事で、

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

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

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

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

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

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

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

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

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

再現させながら、

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

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

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

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

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

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

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

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