IT部門に求められる「標準化」と「開発現場の統制」
http://d.hatena.ne.jp/tonotonotono/20051214/1134561966
http://itpro.nikkeibp.co.jp/as/nri4/index.html
メモ．
たしかに，こりゃ酷いわ．*1
開発技術マネジメントの必要性は、自動車製造の現場で行われている生産技術管理と比較すれば、明確に理解できるはずだ。
論外．
http://d.hatena.ne.jp/JavaBlack/20050602#p1
http://d.hatena.ne.jp/JavaBlack/20050605#p2
http://d.hatena.ne.jp/JavaBlack/20050613#p2
http://d.hatena.ne.jp/JavaBlack/20050619#p2
しかし多くのシステム開発現場では、このようなアプローチは成功していない。それは何故か。最大の理由は自動車製造に比べ、ソフトウェアの製造の自由度が高いからである。
つまり，「ソフトウエアの保つ本質的な複雑さゆえ」である．遙かに複雑なものを設計するのだから，単純なものを設計するより遙かに困難である．至極当然．
自動車製造ではすでに作成されたパーツを、組み立て段階で修正することは考えられない。これに対してソフトウェア製造では、ソフトウェア部品を組み立てる際に、その内部コードを修正してしまう、といったことが日常茶飯事のように行われている。これによってコードとドキュメントの差異が生じたり、予想もつかなかい障害が発生するという問題を引き起こしているのだ。
これはあながち嘘ではない．ただし，間違えてはいけないのは，このような修正は悪ではなく，これこそがソフトウエア開発の本質部分であるということだ．*2
ソフトウェア製造における開発技術マネジメントを成功させる鍵は、このような“現場の自由度”を、どのようにして制限（適正化）するかにある。つまり標準化と開発現場の統制が求められるのである。
論外だな．何も分かってない．「非定型作業の定型化」のようなものは誰も求めてない．そんなことをすれば生産性や品質は低下し，納期遅延や赤字プロジェクトが多発するぞ．*3
NRIが提案したいのは、アプリケーション構造を3層に分けた上で、汎用性の低い部分だけに開発者の自由度を与え、さらに開発ノウハウの可視化を可能にする開発標準を策定する、というアプローチである。
三層に分離という概念自体は何ら目新しいものでも，画期的なものでもない．変更部分と非変更部分を切り離し，変更されない部分をカプセル化してフレームワークとして独立させて再利用する．変更される部分についてもソフトウエア部品を用意して，開発の簡単化(いわゆるEoD)を図るという考え方だ．
分割方法についても様々な分割方法があるし，分割すべきだという話なら何度も出ている．ただし成功事例は，さほど多くはない．*4最適な分割法の提案は，一般的に非定型的でヒューリスティックなものなので，一筋縄ではいかない．そのベストプラクティス集がGoFとして知られている．
