オープン系の開発が増えたとは言え、現場では非オープン系のSE/PMさんが実権を握っている事が多いと思います。
「オブジェクト指向開発ってなんだ」と聞かれたのですが、仕組みや考え方を説明しても理解してもらえる可能性は低い。
過去の経験則では、継承などの3大要素を躍起になって説明しても、理解されたためしがありません。
相手は原理や仕組みを知りたいのではなく、開発効率の良し悪しの面のみを知りたいみたいです。
説明放棄すると、オブジェクト指向を否定されることが多い(経験則)ので最近は、説明の仕方を変えました。
彼らは「標準化」「共通部品化」「生産効率アップ」という言葉に弱い。そこで、システム全般を見回して、サブシステムを問わず、因数分解出来る部分を洗い出して、共通部品を作る。
サブシステムはその共通部品を使って構築する。同じソースは複数箇所に書かない。使いまわしの出来る部品が増えれば増えるほど生産効率が上がる。
例として、仕入システムと受注システムは、画面的には同一で裏返しになっていることが多いので、基本クラスを作りそこから派生させれば、製造は1個で済む。
サブシステムは仕入システムと受注システムの2つなので請求は2サブですればよい。...云々と説明した所、すんなり「理解できた」と言ってくれました。
実際には説明にもなってないのですが、彼ら的にはこのような理解でも前進なのかも知れません。アカンような気もしますが....orz;
納品物が問題だと指摘がありました。業務用件として仕入と受注があれば、仕入詳細設計,受注詳細設計の工程となり、製造物は仕入プログラム、受注プログラムの2本になる筈。
それが、仕入と受注を使い回ししたら、プログラムは1本になってしまう。契約と違う納品物になるのが問題だ。........??????
そもそも納品物の意識ってそんなものなの? 業務からみた機能本数と開発者からみた機能本数は別次元のものです。
外部設計から導いた本数と、機能分析して製造過程に立脚した詳細設計書から導いた本数は一致しなくてもいいと思うのですが。
用件定義=>外部設計 =>詳細設計=>製造 の各過程が 1:1 で結合するという意識は変えてくれませんかねぇ。