プログラミングスキルを測る尺度
Updated Date: 2024/01/01 02:55
君はどのプログラミング言語が得意？
うちはバックエンドではJavaをやってるし、フロントエンドではAngularをつかってるよ。
周辺処理や業務効率化ツールはChefやGolangを使ったりもしているよ。
お客がどう思うかは知らないけど、僕らの強みはこれらの言語にあるんだ。
そういう会話がどこの企業、とくにソフトウェア開発を主体としている企業では採用面接や他企業との交流時に繰り広げられると思う。
企業の狙いとしてはスキルセットを一方方向に統一することで技術的負債を少なくしたり人材確保の利便性を得たりと色々メリットはある。
だけど、それってお客にとって一体何が嬉しいんだろうか。
言語？ 構築？ そんなものよりももっと大事な事を考えて欲しいと思っているお客がいるとしたら・・・？
受託開発の場合、特に1次受けと呼ばれる顧客から直接案件を請け負って開発する企業、
特定言語に特化した企業でそれを優先的に使うことを良しとする考え方だったとすると、
例えば顧客にある既存システムPHPだけど、そのシステムだけRuby on Rails になってしまうという可能性は否定できない。
顧客としては自分たちの意図した要望がシステムになってくれればそれでいいわけで、そこに言語の優位性は存在していないはずだ。
ともすれば、PHPでの文字エンコーディングがEUC-JPで、次期システムがUTF-8だった場合、
データ移行についても色々と考慮する必要があるし、システム間連携を図る場合の考慮だって色々面倒になるだろう。
しかしながら、そのプログラミング言語を選択することで、顧客がハッピーになれるのであればそれは最適解と考えることも可能だ。
上記の例であれば、Ruby on Railsとなることで、顧客の社内での保守性やメンテナンス性が上がってくれたらそれはそれで良いことだし、
実はEUC-JPの文字エンコーディングを利用しているのは既存システムだけだったとかだと尚更のことである。
昔自分がまだ大手SIerに所属していた頃に言われた一言として印象に残っているのは、
「プログラミング言語や利用するPC、デバイスの種別を選択するのは、要件の段階じゃなくて設計段階で考慮すべき問題じゃないの」というものだ。
今ならその理由がよくわかる。
僕らプログラマやSEは、システムの評価尺度を、目の前の測りやすい物事で判断することが往々にして存在する。
例えばそれはプログラミングスキルだったりインフラスキルだったり、
要するに手を動かしてシステムを実装・構築する術における作業効率性や正確さ、素早さとかだ。
僕の経験上、設計能力についてだとか顧客仕様の調整の正当性だとかを測ることって早々なかったと思う。
確かに、システム開発の一番の作業はプログラミング作業だ。請負契約だからといってそれは変わらない。
そこで「Javaができるか」とか、「インフラでOracleを扱えるか」とかいう会話が繰り広げられるのには一定の価値はあると思う。
ただ、本来それは設計した段階で結果的にそれがお客にとって最善であることが明確であるだけで、
プログラミングスキルの得意不得意でシステム構築の品質を測るのは違うんじゃないかとも思う。
確かに僕らの企業価値はRubyだとかGoだとかで決まるかもしれないけど、 それは全く個人のスキルをシステム開発の尺度として測るのには相応しくない。 「やるかやらないか」の違いであって、「言語をどうするか」という話は開発には関係ない。 例えばドクターXにみたいに外科医がメスを使って手術するかカテーテル手術をするか決まる理由には必ずまず「なぜ」がそこに存在しているはずだ。カテーテルのほうが成功率が高いからとか。 理由もなく医者が「カテーテルでやりますね」という理由だけで本当に患者は救われるのだろうか。 メスを使った切除のほうが適切だと分かっているのに「我々はメスを入れたくないお客さまに、最善の医療技術を提案できます。カテーテル手術は我が医院は得意なので」という説明だけでは説得力はあったとしても、真実を知った患者はなぜ先に言ってくれなかったのかと思うだろう。
ということで、このシステム開発だからこの言語で無ければダメだとか、 我々の強みはXXだからそれ以外は提案しないとかもう辞めたほうが良いと思う。 それってどう考えても自社のメリットしか説明できないし、お客からすれば対等な関係を築こうという意思はないことを示されているようなものだ。 僕らの作るシステムは、僕らの資産ではあるが、利用者は僕らじゃない。 多くの開発者にはその視点が漏れまくってると思う。
