生き残るためのプログラミング言語選び

フリーランスとして生き残るためにはどんなプログラミング言語、またはその言語を使う案件を選べばいいのか考察してみます。

フリーランスエンジニアにおすすめのエージェント

ITエンジニア専門 高額報酬案件【TechClipsフリーランス】

作業自動化のためのPython

作業の自動化とは以下のようなものです。

  • makefileを生成する
  • 開発に必要な情報を解析する
  • ビルド後、自動テストをし結果を社内Webサイトに掲載する
  • Excelの作業レポートを生成する

こういうことを手作業でやっているようではフリーランスプログラマーとして生き残れません。

シェルスクリプトからPythonへ

この手の自動化処理は昔はよくシェルスクリプトで書いていました。

bashとか、Windowsのバッチとかです。

自動化のために時間をかけていては本末転倒になります。

そのため、「片手間で手早く自動化処理が書ける」が言語選択の条件になるのですが、昔はシェルスクリプト以外にほとんど選択肢がなかったためです。

ただ、ちょっとでも凝ったことをしようとするとトリックめいたコードを書かないといけませんでした。

そのため、自分で書いたスクリプトですら1ヶ月後に見ると理解するのに時間を要します。

まあ、所詮はシェルスクリプトであり、汎用言語ではないので仕方がないのですが。

Pythonが普及しだしてからは、この手の自動化処理はほとんどPythonで書くようになりました。

Pythonは汎用言語であるにもかかわらず、シェルスクリプトに匹敵する少ないコードと少ない時間で自動化処理が書けます。

そしてコードの読みやすさ(=メンテナンスし易さ)は汎用言語の中でもトップクラスなのではないでしょうか。

プログラマーとして生き残るためには作業自動化が必須であり、そのための言語は現在ならPythonが筆頭候補です。

ライブラリでPythonが選ばれる

そんな書きやすいPythonですが、最近は特定のライブラリが存在するという理由で選択されることも多いようです(特によく聞くのは機械学習系)。

それらのライブラリには職業プログラマーでない人によって書かれたものも多数あります。

そうしたライブラリの存在はPythonの書きやすさの証明でもあります。

ハードウエア操作ができるC/C++

いわゆる「プログラミング言語ランキング」などに登場するような言語の中でハードウエア操作ができるのはC言語とC++言語だけです。

その代わり、ちょっとした処理を書くにもたくさんのコードが必要ですし修正困難なバグに悩まされることも多いです。

C++言語はC言語よりちょっとだけ高級そうですが、C言語にオブジェクト指向要素を追加しただけであり本質は同じです。

前述のPythonなどと違って専業プログラマーでなければ「とてもつきあいきれない言語」と言えます。

そんな問題があるにもかかわらず

C/C++はたくさんの案件(仕事)があります。

こんなものC++で書くのは面倒なだけなんじゃ・・・?

って案件も多数あります。

そういう案件に参画しC/C++で大量のコードを書き、メモリ破壊やメモリリーク等のC/C++特有のバグを追い続ける泥沼のゲリラ戦を戦っていては遅かれ早かれ戦死するでしょう。

ハードウエア操作できるプログラマーは貴重

C/C++で単価も高くおすすめなのはドライバ開発などハードウエアが絡む案件です。

ハードウエア操作できるプログラマーは貴重なため高単価になります。

クリティカルなハードウエア周りではスパゲッティコード相手のゲリラ戦など無縁です。

そんなハードウエア操作ができるC/C++プログラマーとしての生存戦略はおすすめです。

細く長くのCOBOL言語

COBOL(Common Business Oriented Language)は事務処理用のプログラミング言語です。

その言語仕様はかなり古く、「プログラミング言語ランキング」などにはまったく登場しません。

主にメインフレーム(大型コンピューター)で実行されていました。

50代でも案件がある

COBOLプログラマーは「コボラー」と呼ばれることがあります。

コボラーには「古臭い人」という否定的なニュアンスがあります。

そんなコボラーですが、そのイメージとは裏腹に仕事には困りません。

たとえ、50代でも案件があります。

メインフレームなど絶滅したと思われる現在でもCOBOL案件は細く長く生き残っています。

根強いCOBOLの需要に対し、コボラーは減り続ける一方なのが原因と思われます。

あまり前向きとは言えないかもしれませんが、コボラーとして細く長くも一つの生存戦略です。

Web特化のPHP/JavaScript

あるパッケージソフト会社の採用担当者からこんな言葉を聞いたことがあります。

最近はHTMLをいじるのがプログラムだと思っている人ばかりで困る

そんなHTMLをいじるのに特化した非汎用言語がサーバーサイド用のPHPとクライアントサイド用のJavaScriptです。

その他大勢の中の1人として

おそらく今現在、最も早く安くWebシステムを開発できるのがPHP/JavaScriptだと思われます。

実際、世界で稼働しているWebサイトの半分以上はこの組み合わせではないでしょうか。

PHP/JavaScript案件はいくらでもあり、プログラマー数も多いです。

現在のところ、PHP/JavaScript以上に早く安くWebシステムを開発できる言語が登場する兆しもありません。

ただし、気になるが以下の2点です。

  • 高齢プログラマーをほとんど見かけない。
  • 単価が低い案件が多い気がする。

残念ながらどちらも僕の主観でしかなく客観的資料を示せません。

しかし、(ある年齢までは)その他大勢のPHP/JavaScriptプログラマーの中の1人として(高単価でないかもしれませんが)生き残れる可能性は高そうです。

リッチクライアントに特化するとか

そんな「その他大勢」に埋もれないための戦略としてPHP/JavaScriptの特定領域にフォーカスするのはありだと思います。

例えば、早く安く作られたWebサイトによくある「操作性をなんとかして欲しい」というニーズです。

いわゆるリッチクライアントで「HTMLをいじくれるだけのプログラマー」では対応できない話です。

そんな「HTMLをいじるだけ」以上の案件に特化した高単価プログラマーとして生き残りをはかるのはおすすめです。

Javaは生き残るのか?

Java言語の登場時、すばらしいプログラミング言語が登場したと思ったものでした。

プログラムの実行パフォーマンスを追い求めるとどうしてもコンパイル方式の言語にいきつきます。

しかし、代表的なコンパイル言語であるC/C++言語の生産性の低さは前述の通りです。

Javaの夢

JavaはそんなC/C++の問題をある程度解決していました。

少なくともメモリ破壊やメモリリークの問題はJavaではありえません。

そしてJavaコードはJavaバイトコードにコンパイルされます。

JavaバイトコードはJava VM(Java仮想マシン)で実行されます。

Java VMはどんどん最適化され、ゆくゆくはJavaバイトコードを直接実行するCPUも登場するだろう・・・。

つまり、Java言語で開発しておけば将来安泰。

この「Javaの夢」が多数のJava案件とJavaプログラマーを生み出したように思います。

幻のJavaバイトコード対応CPU

そんなJavaのバイトコードを直接実行するCPUは過去に開発されたことがあるようです。

奥歯にものが詰まったような言い方なのは詳細を知らないからです。

つまり、早い話そんなCPUは普及しませんでした。

まあ、Java VMが実用的なパフォーマンスを出せているのも普及しなかった理由かもしれません。

ただ、パフォーマンス向上はインタプリタ型言語でも進んでいるのです。

パフォーマンスに問題がなければJavaなどのコンパイル言語より生産性の高いインタープリタ言語が選択されるのは当然と言えます(逆に言えば理由もないのにC/C++を選択してるような案件に首を突っ込むとロクなことになりません、経験上)。

スタンドアロンはAndroid頼み

WindowsやMacのスタンドアロンプログラムもJavaで書いておけば安泰だよね、

・・・と考えるプログラマーはもういないかと思います。

JavaでGUIを実装するのは大変すぎるからです。

また、WindowsについてはJavaをパクったにインスパイアされたC#の存在も原因の1つかと思います。

WindowsスタンドアロンでJavaでなくC#が選択される理由は以下です。

  • 優れたGUIフレームワーク(.NET Framework)
  • 使いやすい開発環境(Visual Studio)

JavaかC#かといったプログラミング言語の選択にはフレームワークや開発環境がいかに大事かってことですね。

まあ、「EclipseとVisual Studioのどちらで開発するのが楽ですか?」って聞かれたら答えは明白ですから・・・。

そんな中、スタンドアロンJavaが生き残る唯一の望みがAndroid開発です。

AndroidアプリはDalvik VMと呼ばれる仮想マシン上で実行されます。

Dalvik VMはJava VMにかなり似ており、今のところ主流な開発言語はJavaです。

ただ、ライバル(?)のiOSアプリ開発はより生産性の高いSwift言語が主流であり、Androidアプリ開発でもKotlin言語などが模索されています。

いずれにしてもAndroidでのJava開発が下火になればスタンドアロンのJavaも絶滅の道を辿りそうです。

サーバーサイド案件はたくさんありますが・・・

サーバーサイドであれば前述のGUIフレームワークの問題もなく、多数の案件もあります。

ただ、かつてのような、

  • (プログラマーにとって)Javaのスキルは他でも活かせる
  • (顧客にとって)Javaで作っておけば安泰

といった夢はもはや期待できません。

せいぜい、スキルをAndroidアプリ案件に使い回せる程度です。

そのAndroidも前述の通り将来は怪しい状況です。

有償化

そんな怪しい将来に追い打ちをかけると思われるのがOracleのJDK(Java Development Kit) 11以降の有償化です。

有償化自体はたいした問題ではないと思います。

OracleのJDKを商用利用したければお金を払えばいい話です。

どうしてもお金を払うのが嫌なら無償のものに替えればいい話です。

・・・と、ここまでは顧客の立場での話です。

Javaプログラマーにとっての危機は有償化を契機に顧客が、

そもそもJavaで開発するメリットって何だっけ?

とかいらぬ事を考え始めることです。

Javaが生き残れなければ、ただ「Javaが書けます」だけのウリのプログラマーも淘汰されることになります。

かかわりたくないVBA

VBA(Visual Basic for Applications)とはExcelやWordなどマイクロソフトOfficeアプリの組み込み言語です。

VBAの土台となったのは汎用言語であるVisual Basicです。

Visual BasicがWindowsで広く使われた時代もありましたが、既にサポートは終了しています(Visual Basic .NETが一応現役ですがこれはもうVisual Basicとは別言語です)。

そんな汎用言語として既に終わったVisual Basicが未だに使われているのがマイクロソフトOfficeです(一応、VBAはOffice以外のアプリにも組み込み可能ですが)。

その理由はおそらく「過去の膨大なVBAコード」だと思わrます。

僕もVBAで散々書きました。

Excelだけでなく、Word文書の自動生成とか、ブラウザベースでないAccessのDBクライアントとか。。。

VBA開発の難しいところは操作対象のOfficeアプリに想定外の挙動があることです。

つまり、Officeアプリの挙動を見ながらの試行錯誤が必要で開発工数が読めませんでした。

そうした試行錯誤で書かれたプログラムのメンテナンスは困難を極めます。

さらにVBAはPythonのように誰が書いても読みやすいコードが書けるようなモダンな言語ではありません。

そんなわけでVBAのメンテナンスにはかかわりたくありません。

VBA辞めてOfficeファイルを直接操作するように変更、とかならいいんですけどね。。。

スポンサーリンク
スポンサーリンク
フリーランスのプログラマー
フリーランスのプログラマー

コメント