プログラミングを単純労働と捉える3つの理由

int128殿の会社では、
>プログラミングは誰でもできる、頭を使わない作業
と思う方が多くいるのかしら？
http://d.hatena.ne.jp/int128/20080414/1208181589

うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。

（1）プログラミングは業務をプログラムに落とし込む単純労働

SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。

30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。

（2）プログラマは取替えが利く

プログラミングの専門家は取替えが利くが、業務の専門家は取替えが利かない。言い換えると、業務の専門家は付加価値の高い仕事をしていると言えます。この論理が正しいかはともかく、組織のトップには、労働集約と知識集約を分ける境目を「プログラマは取替えが利く」ことに見出している人が多いです。

（3）アーキテクチャ設計が不要な分野では技術者の役割が小さい

業務系システムは、他では目にしないようなフレームワークや言語が多く使われる。COBOLやRPGで書かれたシステムは減ってはきたもののいまだに現役だし、新規システムでもSAPのABAP言語なんかは需要が高い。メジャーなアプリケーションはWebSphereとかPeopleSoftだったりするし、ジョブの実行はcronではなくて、JP1、千手、A-AUTOのような運用管理ソフトを使う。XMLの非同期通信を憶えるくらいなら全銀手順やHULFTを知っておいた方が役に立つ、というような世界だ。
http://d.hatena.ne.jp/aike/20080615

例えば金融のように、業務が決まれば実装方式が決まる（実績がある）分野はあります。業務を実現するアーキテクチャはすでに確立されているため、その中身を埋める作業が中心になります。プログラミングからアーキテクチャ設計を除くと単純作業になってしまうのは自明です。