先日、効率よい勉強方法の記事を書きましたが、言語続きでもう一つ。
今では、世の中には開発言語が溢れております。
時代、世代で流行り廃りもあって、トレンドを追うだけでも目が回ります。
こういう中で行う、サービス開発での言語選定。
私はいくつかの視点で「向いている・向いてない」を判定して言語を決めています。
・サービスが公開される環境にあっているか？
・開発維持コストは見合っているか？
・「早く」「速く」作れるか？
視点①今回のサービスの内容にあっているか？
サービスが公開されるのはWebだけではありません。スマホアプリのこともあれば、LINEのようなプラットフォーム上に作ることともあります。各環境に応じて基本的に使われる言語があり、私の方針では、最初はその言語を使うことにしています。
基本的な言語での開発はサンプルコードの種類多く、どういう仕組みで機能を作ることができるのかへの理解を深めることができ、理解が深まることで、開発できることの種類も増えると考えています。
今は、Webの技術でスマホアプリを作ることもできますが、最適な言語へコンバートしなおしているケースもあり、最新バージョンアップの機能を使えないこともあるので、そういう点でも注意は必要です。
視点②開発維持コストは見合っているか？
私が考える開発維持コストは
・メンテナンス人員を予算内で確保しやすいか
・開発環境（ローカル環境含む）の保持がしやすいか
・セキュリティ対策に代表されるようなバージョンアップがしやすいか
の3点で判定します。
特殊な言語だと、人員の確保は難しい。開発環境の維持にコストがかかるなら、開発人員を増やしにくい。セキュリティ対策のバージョンアップが逐次行われるフレームワーク、それに使われる言語であれば安心できますが、できない時は、自力で頑張るしかない。
開発したものは維持し続ける可能性が高いので、開発時点の目新しさやメリットだけで考えてないようにしています。
視点③早く・速く作れるか？
最後の1点。これが重要！
私と開発メンバー（弊社の開発グループ）の開発が、早く（リリース早く！）・速く（プログラムソースの積み上げが速く）できる言語か？
だって、最近は開発時間が短いんですもの・・・。
そんな時は「早く・速く」が重要です。これができるほど習熟しているから、急ぎ仕事でバグが出ても、原因追及が“はやい”のです。
テスト中に発見されるバグが少ないほうがいいけれど、急ぎであるほど、うっかりコーディングでバグを量産しちゃいます。でも、後からすぐにリカバリで、本番リリースには影響を与えません。
私にとっては「まずは予定のサービスイン」に近づけるかどうかが、一番の判定基準なのです。