ソフトウェアIC化考案（０）

連載の背景）
ソフトウェアの開発手法や概念は今までに沢山の種類が出回っていて、思いついたのだけでも
モジュールの流用やオブジェクト指向、アスペクト思考、構造化手法、フレームワークなど
沢山のテクニックがあって、それぞれ書籍になって売られてる。
これらの手法は使える場面で最も効果が発揮されるように設計されていて、
１つの成功で１つの考えを突き通して手法の1元化などやってしまうとデメリットばかり出てきて
結論として「最初から作り直した方が早かった」、みたいな事になってしまう場合もある。

ISO9001やEMMIなど、開発標準化やレベルなどを示す基準がある。
この基準のハードルをあげれば開発業務の品質が上がるか？という観点で見ると決してそうではない。
なぜならば、開発内容に関する細部の取り決め、厳しい制約についての記述は業務側で決めていくものだからである。
つまり自由な枠組みの中は決められた基準を満たしていれば、表向きの評価は高くする事ができる。
言い換えれば車の免許で、免許持ってるから運転がずば抜けてうまいかといえばそうではなく、
毎日運転してるドライバーからサンデードライバー、ペーパードライバまで幅広くあるわけで、
あればいいというものでもない。
もし改善するならば、人によって10人10色になる部分をどれだけシステマチックにできるかがテーマになると思う。
そこで、この問題に対する解決策はあるのか？というテーマを書いていく予定です。
言い換えて、ソフト開発（職人）としての自分探しの為に連載していきますｗ