WirelessWire Newsで掲載されている『日本でプログラマが少ない理由は正当な対価を支払わないからである』が話題となっています。

ですが、この記事のタイトルに釣られて対価の少なさに対する不満が表面化しているに過ぎないのでは？と筆者は考えます。

事実、この記事にはプログラマの業務に触れることはなく、完結しています。

日本でプログラマが少ない理由は正当な対価を支払わないからである

プログラマとは

そもそも、プログラマというものは、製品やサービスのアイデアを練り上げる職業ではなく、そのアイデアを現実化するプロセスを実行する職業です。

製品やサービスが多大な利益を生んだ時には、貢献の度合いの高いプログラマに相応の対価が支払われるべきだとは筆者も思います。

ですが、現実の業務の中では、ひとつの製品やサービスに多くのプログラマや請負の開発会社が関わり、その中でも製品やサービスを他者のものと違ったものとする部分を担うのは「設計」と呼ばれる工程です。

この設計を行えるプログラマは殆どいません。プロジェクトチーム構成にもよりますが、設計を行うのはシステムエンジニアであったりプロジェクトマネージャーであったり、別の人間を配置する場合が殆どだからです。

プログラマにも設計と呼ばれる工程はありますが、これはシステムの中の小さな動きひとつを上手く効率的につくるためのコード設計、クラス設計というものです。

もちろん、プログラマの中にはサービス設計やシステム設計といわれる上位の設計作業を行う人もいます。ですが、これは本来プログラマの範疇ではないので、別途料金が発生していたり、売名のために行われていたりします。

プログラマの業務

あくまで、プログラマの本業は設計の「現実化」なのです。そして、この工程の中には、①分析、②調査、③コーディング、④動作検証、⑤デバッグ、⑥調整、⑦バグ修正といった工程があります。

⑤〜⑦の工程は品質管理部門と協力して行ったり、外部委託したデバッグ会社などのデバッグ専門の部隊と共同で行ったりします。

そして、プログラマの対価として考えられる、算出方法は大きく分けて２つあります。ひとつは実績ベース、書いたコードの量やルーチンやロジックの数によって算出する方法です。そして、もうひとつは工数ベース。実績に関係なくタイムカードベースで考える方法です。

このふたつを組み合わせた、もしくはどちらかの考え方で算出されますが、工数ベースだと、実際に成果があがっていなくても料金が発生してしまいます。実績ベースでは成果の良し悪しが考慮される比率が低いという問題があります。

そして、①や②の分析や調査といった工程はプログラマが業務知識をつけるという工程なので、目に見える成果がない場合が殆どです。これをコーディングに結び付けられないと成果は出ないのです。下手なプログラマはこの①と②の工程に時間がかかり、③のコーディングに到達するまでに多くの時間を使います。また、④の動作検証に時間をかけすぎて、⑤〜⑦で協力して行う部隊を待たせて無駄なコストを産みます。④の動作検証はあくまで、自分の思ったとおりに動いているかを確認するに留めるべきで、自分の想定外の動作は⑤の工程で行うべきなのです。

プログラマの対価

そして、他のプログラマとの差別化をプログラマはどこに見出すかというと、知識量に他なりません。この知識量を得る作業を工数に含められてしまうと正当な依頼の業務に対する対価は、プログラマのアイデンティティにすり替えられてしまいます。

一言に対価を上げろというのも、難しい職業だということはおわかりいただけましたか？

こうして、正確にプログラマの業務を把握した上で話題となっている記事を読むとこうあります。

明らかに違う職業です。プログラマとしてプロジェクトに関わった人だとしても、やっていることはプログラマではない業務を行っています。

製品やサービスの全体像

実際のプログラマに人たちは、こうして、システムの一部のみを深く考えさせられるといった業務が多く、サービスや製品の全体像を把握していない場合が多くあります。そこで、「こういう作りの方がいいから」といって勝手に変更してしまうと、サービス全体の方針と齟齬を起こして問題とされることが多くあるのです。

縦社会でいうなら、まずはプロジェクトを作る側の人間になること、横社会でいうなら、プログラマに留まらずにプロジェクト全体を作る肩書にすること、どちらにしても、サービスや製品の全体像を見てなにをすることが大事なのかを見極められるようになることが大事なのではないでしょうか？

過去のプログラマとして偉大な製品を作ってきた人たちも、プログラムだけに拘っていたわけではなく、製品としてものをみて、設計やマーケティングに積極的に関わってきたから名前が出るようになったんだと思いますよ。