プログラマが直面する２つの「世界」

プログラマというのはとてつもなく難しい仕事だ。

職業的なプログラムは、それが会社であれ、個人であれ、顧客の何らかのニーズを満たすために存在している。プログラマは、顧客の要求を満たすように、プログラムを設計・実装する。ここで注意しなければならないのは、「顧客の要求」と「プログラムの設計・実装」という全く異質な 2つの仕事を同時にこなさなければならないということだ。

顧客の要求は、社会というシステムに属し、プログラムは、技術というシステムに属する。この2つは全く似ていないし、何の関係もない。それが、「顧客要求を表現したプログラム」という一つの場で切り結ぶ。異質な2要素がぶつかり合い、プログラムコードはまさに戦場と化す。

書かなければならないプログラムの種類によって、この緊張度は異なってくる。たとえば、組み込みソフトウェアや科学技術計算などの場合は、要求自体がかなり技術的であるから、プログラムという技術的世界との相性は比較的よい。

ところが、ビジネス・ソフトウェアの場合、実装されるロジックは完全に異質な社会的要素に基づく。「顧客の要求」と「プログラムの設計・実装」の二つの世界を完全に両立させるのは難しい。

カネを払う顧客の立場に立てば、プログラムの中身はどうでもよい。完全なブラックボックスにすぎない。それが Java だろうが、PHP　だろうが、Perl だろうが、C# だろうが、Ruby だろうが、そんなものは全く関係ない。サーバーの中に天才猫が入っていて、正しい応答を返す、というのだってかまわないのだ。

ところが、実際にプログラムを書くプログラマの立場に立つと、どの技術を選択するかは自分の仕事の負荷を大きく変化させる死活問題となる。ウェブプログラムを C で書けといわれたら泣くかもしれないし、デバイスドライバを Cobol で書くことはそもそも不可能かもしれない。

仮に、顧客要求寄りと実装寄りの二種類のエンジニアがいると考えるなら、顧客にとってありがたいのは、顧客要求寄りのエンジニアである。実装寄りのエンジニアの言っていることは、顧客にはちんぷんかんぷんだし、理解する必要もないのだ。顧客が求めているのは、予算・納期内で自分の要求が満たされることにすぎないのだから。

したがってビジネスソフトウェアの場合、それが受託開発であれパッケージ開発であれ、客と話す機会の多い顧客要求寄りのエンジニアの力が強くなる。カネをくれるお客様は神様、だからね。顧客要求寄りエンジニアと実装寄りエンジニアが同一人物であってもかまわないし、むしろ望ましいのだが、この二つの完全に異質な世界に対して同時に同量の関心を注ぎ、同等に習熟するのは、非常に難しい。実装寄りエンジニアは、技術の海に遊ぶことに夢中になり、社会的諸要素に対して関心を失うことが多い。

顧客要求寄りエンジニアと実装寄りエンジニアは、いきおい別々の人物になることが多い。日本では前者は SE、後者は PG と呼ばれ、PG は SE より低く見られている。たしかに、顧客＝カネからの距離で、エンジニアの序列を測るなら、PG は SE より顧客から遠い。ビジネスソフトウェアでは、顧客の要求をすばやく満たすことが優先され、実装上の効率性・保守性が後回しにされる。これが、ビジネスソフトウェアのソースコードが醜くなりがちな最大の原因の一つだろう。

私は、これがどうしても許せなかった。ソフトウェアの魂は、ソースコードに宿る。私は、顧客要求寄りエンジニアに舵を切るチャンスは人生で何度もあったのに、醜いソースコードを捨てておけず、実装寄りエンジニアをやめることができなかった。これは私の業（ごう）である。抵抗しながらも、どうしても実装へ実装へ流されていってしまうのである。これは一種の病気のようなものかもしれない。

総合的なソフトウェアのコストパフォーマンスを考えるなら、実装寄りエンジニアはいまより重要視されるべきだ。コストが安く品質の高いソフトウェアが作れる可能性が高まるからだ。だが、実装寄りエンジニアにしか、技術的な世界は理解できないので、利害関係者を説得するのは容易ではない。彼らの仕事をわかりやすく、素人にも可視化できる方法があるとよいのだが。他者のすべての失敗のしわ寄せが行く実装寄りエンジニアは、損な役回りになってしまっている。