設計者の発言

　業務システム開発の世界では、案件毎のプログラミング（従来の意味での、狭義のプログラミング）を減らすような工夫が発展し続けている。コードを自動生成させたり、設定ファイルの編集でシステムの動きを指定できる。そんな実装用フレームワークの発展が止まらない。コーディング量を減らすための工夫をしたがらないのは、工数ベースで稼ぐ派遣業の経営者くらいだろう。

　そのような技術革新の結果として、以前にも書いたように、システム開発での分業体制が変化する。ある種のプログラマは個々の開発案件ではとんと姿を見せなくなる。彼らは「別室」でフレームワークの開発に従事しているからだ。フレームワークは個々のシステムを生み出す「金型」とか「工作機械」のようなものなので、彼らを「金型プログラマ」と呼ぼう。いっぽうの、個々の開発案件のプロジェクトルームで働いているのは「製品プログラマ」だ。彼らは「金型プログラマ」が開発したフレームワークを用いて「出荷製品としてのシステム」をプログラミング（広義のプログラミング）しているのである。

　ある辣腕の「金型プログラマ」が言っていた。「このフレームワークを使うと新人がＳＱＬを覚えないんだよね。要らないから仕方ないことなのかなあ」つまり彼は、自分が作ったフレームワークを利用する「製品プログラマ」たちがＳＱＬを知らないままに仕事ができてしまうことを嘆いていたのである。

　これは、プログラミング言語の高級化の過程で、機械語レベルの動きを意識すべき機会が減っていったのと同じ話である。テクノロジーの発展は常に「何かを知らないままで高度なことができるようになること」を伴うものだ。

　ただし、必要な知識の量が減るばかりということにはならない。言語の高級化にともなって、それぞれの立場毎で求められる知識やスキルが変化する。「製品プログラマ」は、現実のビジネス要件を「金型（フレームワーク）」のスキーマに合わせて編集するという役割が期待されている。そのために、対話能力、それに会計や業務知識の理解などが求められる。いっぽう「金型プログラマ」には、データベース制御やネットワーク制御のための知識や専門的なプログラミング技術が求められるが、簿記の「分記法」と「三分法」の違いを知らずとも仕事はできる。

　「金型プログラマ」や「製品プログラマ」以外にも、いくつかのプログラミング分野を想定することは可能だろう。当然ながら、ひとりの技術者がそれらに必要とされる技能をひととおり兼ね備えているのであれば言うことはない。しかし、そんなスーパーマンみたいな人物の話をしてもしょうがない。

　自分の職業適性に合わせてこじんまりとまとまった職業能力を身につける。筆者も含めてほとんどの技術者は、その程度の凡庸な意欲と知力しか持ちあわせていない。だから、自分はどんな立場に向いているかに早めに気づくことこそが、フツーの技術者が経済的安定と職業的アイデンティティを得るための第一歩だ。