「コーディングというのはスキルの低い人がすること」
「仕様さえ決まっていればコーディングは誰でもできる」
「プログラムを書けるだけではこれからは食べていけない」
時々、こんな言葉を耳にします。しかし
それはありえない！！
のです。
誰でもできるというのは、決まりきった手順を踏む、きわめてロジックが簡単な場合のみだけです。あるいはＳＥが、ソースを日本語化したような詳細設計を作った場合のみです。ちょっと難しくなると、スキルのない人はドツボにはまります。上級者から見ればとんでもない実装をするものです。そういうソースは、メンテナンスがしにくく、ちょっとしたら例外的な操作でバグが発生するものです。
にもかかわらず、プログラマーの存在を馬鹿にしたような言い方をするのはあまりにも現場を知らなすぎるからです。低スキルのプログラマーと高スキルのプログラマーの問題解決能力は格段の差があります。
いくら設計があったとしても、そんなものは絵に描いた餅です。アプリケーションは、ソースコードがあってのものです。うまく設計したとしても、プログラマーのスキルが低ければその通りには実現できません。仕様をきれいに整理し、業務プロセスすら改善してシンプルにしたとしても、下手プログラマーのせいで、折角の苦労が台無しになることだってあるのです。
それから、オフショア開発が最近盛んで、今後は単価の安い外国に仕事を奪われていくだろうと予測している人もたくさんいます。そういうことをいまだに言っている人ははっきり言って、システムの構築がどんなものかを知らない人です。
私は、オフショア開発で失敗した人の話ならたくさん聞きますが、成功した人の話などほとんど聞きません。日本にいる外国人と仕事をしたことがありますが、彼らは日本人ほどまじめに仕事をしません。
第一、言語の壁があります。ソースコードは仕様と深く結びついています。仕様が完全に理解できなければ、正確なソースコードは作成できません。その仕様を決めたり、曖昧なものを明確にするために、徹底的な議論や打ち合わせがなされます。そういう内容を言語の違う国に伝えるのは並大抵ではありません。また面と向かって打ち合わせる方が効率的です。それでも誤解はあります。インターネットが発達したからといってメールで文書のやり取りをしたのでは、趣意が伝わりにくいし、海外であれば呼び寄せるのも難しいものです。
ＵＭＬがあれば共通言語として、外国人とも認識をあわせることができる、などと言う人もいます。これも正しくありません。ＵＭＬ（図）で表現できるのは仕様の１割にもなりません。肝心なところはすべて文章で表現する必要があります。ここで、言葉の壁によって食い違いが出る可能性があります。
第二に、文化の違いがあります。日本人は几帳面です。したがって、アプリケーションにも厳密性が要求されます。しかし、外国人はそれに比べて大雑把で、少々のバグやおかしなところは気にしませんし、基本的に無責任で言うことを聞きません。すべての外国人がそうではありませんが言葉の壁もあってそうなりがちです。また、要求したことしか作らないので、日本人のように気を回してくれるなどということはほとんどありません。
第三に、そういった問題をクリアした、スキルが高く責任感も強い外国人の給料は日本人並に高くなるということです。
オフショアを成功させるためには、間に入る日本人が相当な苦労をしなければならないでしょう。プログラムは、衣類や工業製品を作る作業とは違うのです。世界標準となっている規格を満たすアプリケーションなどであれば、話は通じやすいでしょうが、それでも細かい部分はかなり苦労するでしょう。
第四に、日本語のインターフェースは日本人が行う必要がある。ということです。そうした場合、結局また通訳の手間を取られるのです。日本語が話せなければ、客対応もできません。
ソースコードを作るのは人間の手です。定型化された業務の中で限定された内容を変えるのであれば、ソースを自動生成できるアプリケーションはありますが、それは、プログラムをカスタマイズする程度であり、大きく変更する場合はやはりソースコードに手を加える必要があります。
業務アプリケーションを作成する場合、人間の業務が単一化されない限り、仕様は多様であり、やはり手作りです。SAPを導入しても、自社流にカスタマイズを加えるか、あるいは仕事のやり方をＳＡＰにあわせるかということになるのです。もし、人間の仕事のやり方を、世界標準として規格化されたなら、自動化できるかもしれません。そういう方向に努力していくべきなのかもしれません。ただ、標準化してもおそらくケースが膨大すぎてあまり変わらないかもしれません。例外的なケースを認めれば、そこで結局ソースコードを生成する必要があります。
もしソースを自動生成できるようになった、と言って喜んでいるとしたら、単に今まで自動化できる部分を自動化していなかっただけです。自動化してできた部分というのは単なるスケルトンであって、内容は乏しいというか、ほとんどナイのです。
また既存のコンポーネントを使うと楽に作れます。ＶＢなどでは、GUIの部分はかなり楽に作れますが、それでもロジックの部分は自分で作らないといけないのです。既存コンポーネントの組み合わせだけで作れるなら楽ですが、そうぴったりはまったものがなければ自分で作成する必要があります。また既存コンポーネントの組み合わせといっても、その数が膨大であれば、それをモデレートするソースコードを結局書く必要があるのです。
なので、プログラマーという職業は、時代が進化し続ける限りなくならないでしょう。しかし、業務が単一規格化したり、人間のニーズが固定したりしたら、既存のものでまかなえるため、新しいソースコードを作成する作業などいらなくなります。まあ、そういう時代になれば、プログラマーに限らず、今あるほとんどの仕事がなくなるでしょうが。
プログラムとマクロの違いはその自由度にあります。あるアプリケーションが提供するマクロは、そのアプリケーション上で動き、できることが限られます。プログラム言語は柔軟性、自由を備えています。この自由度はプログラミング言語のメリットであり、なくなることはないでしょう。
したがって、その自由度を維持しつつ、かつ生産性を高める手法というのが、これからますますクローズアップされるでしょう。
アジャイル、オブジェクト指向、開発環境、アスペクト思考、フレームワーク、等々は、まさに生産性を高める試みです。生産性を高めるからといって、勉強することが少なくなるわけではありません。逆に多くなります。余計なソースを書く必要がなくなったり、同じソースは二度と書く必要がなくなったりしますが、ソースを記述する規則や、フレームワークの仕組み等については勉強する必要があるのです。
ただ、今後の方向性としては、今のような処理言語を書くよりも、設定をする部分が多くなるように思います。処理自体はパターン化されてできていて、それを組み合わせたりするような作業がメインになっていくと思われます。ただしシステム的な思考はやはり必須です。